[blink-dev] Intent to Prototype: 'blocking=rendering' attribute on scripts and link resources

2021-11-17 Thread Xiaocheng Hu 
Contact emails
xiaoche...@chromium.org

Explainer
https://gist.github.com/xiaochengh/fae2b549b3d37454beeb9028a829f4bd#explainer

Specification
https://gist.github.com/xiaochengh/fae2b549b3d37454beeb9028a829f4bd

Summary

This feature allows putting 'blocking=render' as an attribute and value to
a

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread K. Moon 
There's no generic way to do this, as it would leak information. I don't
think this route is worth exploring.

On Wed, Nov 17, 2021, 11:44 AM Tibor Goldschwendt 
wrote:

> We explored postMessages for a bit, too. IIUC, this would only solve the
> success case properly though. But how do we know the iframe is broken? Not
> receiving the postMessage could also mean the iframe hasn't completed
> loading yet.
>
> On Wed, Nov 17, 2021 at 11:34 AM Domenic Denicola 
> wrote:
>
>> The "error" event does not fire on iframes though, precisely because we
>> don't want to leak information cross-origin.
>>
>> Pages generally deal with broken iframes, in cases where they need to, by
>> noticing that the iframe has not sent them the message they expect. (Via
>> parent.postMessage() from inside the iframe.) That is, they use an opt-in
>> protocol where the iframed page must affirmatively decide what information
>> to send cross-origin.
>>
>> On Wed, Nov 17, 2021 at 2:24 PM Daniel Cheng  wrote:
>>
>>> The iframe element supports "load" and "error event listeners. Is the
>>> exact HTTP error needed? Or does the feature just need to know if it
>>> succeed or not?
>>>
>>> Daniel
>>>
>>> On Wed, 17 Nov 2021 at 11:19, Tibor Goldschwendt 
>>> wrote:
>>>
 +Nasko Oskov 

 Thanks, Kahmy. Adding custom code in the browser process is another
 avenue I'm exploring. Generally though, how do pages deal with broken
 iframes?

 On Wed, Nov 17, 2021 at 6:39 AM K. Moon  wrote:

> This would violate the same-origin policy, so I don't think you can do
> this within Blink, but given this is a chrome: page, maybe you could add
> some code in the browser to give this information to you.
>
> On Tue, Nov 16, 2021, 4:40 PM Tibor Goldschwendt 
> wrote:
>
>> Hi Blink Dev!
>>
>> Is there any way to get the HTTP return code of a cross-domain
>> iframe? FWIW, the hosting page has the chrome:// scheme while the iframe
>> has https:// scheme. From my limited testing I receive the load
>>  
>> event
>> in all scenarios but couldn't find a way to query whether the load
>> succeeded. I also tried window.addEventListener('error', ...) and
>> iframe.addEventListener('error', ...) without any luck.
>>
>> Best regards,
>> Tibor
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3n%2B8i%2BNQNSJY0DFab9JrXG0QTq3W473t-beRtPYbLn1XjA%40mail.gmail.com
>> 
>> .
>>
> --
 You received this message because you are subscribed to the Google
 Groups "blink-dev" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to blink-dev+unsubscr...@chromium.org.
 To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3nL-J4A0bQuXnU1Ns-eUYLNqVV65KZLeY3HuiPuBYQQmiQ%40mail.gmail.com
 
 .

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF3XrKpDqd9ixPDOFiOu7NjMpmMm62nD0JxzBxyHfLmTJhr0PA%40mail.gmail.com
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACwGi-76C_z5MJ%3D9PGMDOLj%2BuE01zni%2BtPY-aHHZmOO0j%2BA%2BGQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Remove font-family -webkit-standard

2021-11-17 Thread Mike Taylor 

On 11/17/21 6:02 AM, Frédéric Wang wrote:


I started to poke through 
https://github.com/search?p=5=%22-webkit-standard%22=Code out 
of curiosity and a few things stand out:


1) Some tools used for archiving / exports appear:

Evernote: 
https://github.com/karshih/Notes/blob/edf2d8658db898a4d993a22db62722e2d8e23ee8/accounts/www.evernote.com/100389449/content/ACFB7C02-6642-435C-B739-DBE738BDC66D/content.enml 



Some "HTTrack Website Copier": 
https://github.com/MicIOE/MicIOE.github.io/blob/533ac9fecef9e407b2f82061304fb2ee113c90a0/micioe/main/www.micioe.com/news/news2/2145.html 



It's possible the tools were generating the usage, or just capturing 
the result of certain pages already using it.


However, the results co-occur a lot with CJK fonts and mso- 
properties (MS Office docs saved to web? Outlook emails?). Do we have 
a guess at why Chinese documents might pick -webkit-standard over 
something else? Is there some kind of layout benefit that we might break?


i.e.,

https://github.com/huanyun-c/egg_linkingLeft/blob/36a00019d54219c07150bdf5fe07445d1d1a221a/app/view/rule/fwxy.ejs#L31-L37

https://github.com/english5-net/e5-ckeditor5-build/blob/a60acf23729ba6a48671cb3d0136294a26893360/packages/ckeditor5-paste-from-office/tests/_data/list/resume-template/normalized.safari.word2016.html#L3-L9

Thanks for taking a look. I'm not sure I have a proper answer to your 
question, but some comments below. In any case, maybe we want to be 
safer : analyze the pages reporting the counter and rely on a Finch flag?


I think looking at a few dozen random samples of affected pages by 
someone who can read these pages and discern (subtle?) breakage would be 
useful. If you found anything concerning there, perhaps a Finch flag 
would be wise before moving forward.


Regarding the proprietary -mso properties, they are not affected by 
this intent to unship AFAIK.


Right, just pointing out a co-occurrence that might hint at use cases or 
sources.


Links 1, 3, 4 has a font-family with a single -webkit-standard while 
link 2 has a quoted '-webkit-standard' value (whether the name is 
quoted or not should not make a difference for Blink). It's indeed 
possible these pages are affected by this intent if the inherited font 
is not the default.


Checking WPT test css/cssom/font-family-serialization-001.html and 
also the initial value, it does not seem that WebKit or Blink 
serialize "-webkit-standard" name (unless they were already specified 
in the document). So I guess authoring tools do that on purpose, 
although I can't explain the rationale. Doc 4 has "Safari" in its 
name, which suggests it's designed for webkit.


Regarding CJK, we have special behavior on Android for these 
characters. And bug 1252383 showed that an internal use of 
"-webkit-standard" allowed to work around a Skia bug 12503. Bug again, 
I can't explain why someone would need to do it explicitly...


The @font-face{ font-family:"-webkit-standard";  } in link 3 is also 
weird, I'm not sure what's happening when we don't specify an src...




--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c3ba13cd-65b7-ff5b-e088-6a3614258abd%40chromium.org.

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread Tibor Goldschwendt 
We explored postMessages for a bit, too. IIUC, this would only solve the
success case properly though. But how do we know the iframe is broken? Not
receiving the postMessage could also mean the iframe hasn't completed
loading yet.

On Wed, Nov 17, 2021 at 11:34 AM Domenic Denicola 
wrote:

> The "error" event does not fire on iframes though, precisely because we
> don't want to leak information cross-origin.
>
> Pages generally deal with broken iframes, in cases where they need to, by
> noticing that the iframe has not sent them the message they expect. (Via
> parent.postMessage() from inside the iframe.) That is, they use an opt-in
> protocol where the iframed page must affirmatively decide what information
> to send cross-origin.
>
> On Wed, Nov 17, 2021 at 2:24 PM Daniel Cheng  wrote:
>
>> The iframe element supports "load" and "error event listeners. Is the
>> exact HTTP error needed? Or does the feature just need to know if it
>> succeed or not?
>>
>> Daniel
>>
>> On Wed, 17 Nov 2021 at 11:19, Tibor Goldschwendt 
>> wrote:
>>
>>> +Nasko Oskov 
>>>
>>> Thanks, Kahmy. Adding custom code in the browser process is another
>>> avenue I'm exploring. Generally though, how do pages deal with broken
>>> iframes?
>>>
>>> On Wed, Nov 17, 2021 at 6:39 AM K. Moon  wrote:
>>>
 This would violate the same-origin policy, so I don't think you can do
 this within Blink, but given this is a chrome: page, maybe you could add
 some code in the browser to give this information to you.

 On Tue, Nov 16, 2021, 4:40 PM Tibor Goldschwendt 
 wrote:

> Hi Blink Dev!
>
> Is there any way to get the HTTP return code of a cross-domain iframe?
> FWIW, the hosting page has the chrome:// scheme while the iframe has
> https:// scheme. From my limited testing I receive the load
>  event
> in all scenarios but couldn't find a way to query whether the load
> succeeded. I also tried window.addEventListener('error', ...) and
> iframe.addEventListener('error', ...) without any luck.
>
> Best regards,
> Tibor
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3n%2B8i%2BNQNSJY0DFab9JrXG0QTq3W473t-beRtPYbLn1XjA%40mail.gmail.com
> 
> .
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3nL-J4A0bQuXnU1Ns-eUYLNqVV65KZLeY3HuiPuBYQQmiQ%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF3XrKpDqd9ixPDOFiOu7NjMpmMm62nD0JxzBxyHfLmTJhr0PA%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3nJzcGrJtpCvBavAcxokEA_0O_W9CznDQsR3wwUtZLAGMw%40mail.gmail.com.

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread Domenic Denicola 
The "error" event does not fire on iframes though, precisely because we
don't want to leak information cross-origin.

Pages generally deal with broken iframes, in cases where they need to, by
noticing that the iframe has not sent them the message they expect. (Via
parent.postMessage() from inside the iframe.) That is, they use an opt-in
protocol where the iframed page must affirmatively decide what information
to send cross-origin.

On Wed, Nov 17, 2021 at 2:24 PM Daniel Cheng  wrote:

> The iframe element supports "load" and "error event listeners. Is the
> exact HTTP error needed? Or does the feature just need to know if it
> succeed or not?
>
> Daniel
>
> On Wed, 17 Nov 2021 at 11:19, Tibor Goldschwendt 
> wrote:
>
>> +Nasko Oskov 
>>
>> Thanks, Kahmy. Adding custom code in the browser process is another
>> avenue I'm exploring. Generally though, how do pages deal with broken
>> iframes?
>>
>> On Wed, Nov 17, 2021 at 6:39 AM K. Moon  wrote:
>>
>>> This would violate the same-origin policy, so I don't think you can do
>>> this within Blink, but given this is a chrome: page, maybe you could add
>>> some code in the browser to give this information to you.
>>>
>>> On Tue, Nov 16, 2021, 4:40 PM Tibor Goldschwendt 
>>> wrote:
>>>
 Hi Blink Dev!

 Is there any way to get the HTTP return code of a cross-domain iframe?
 FWIW, the hosting page has the chrome:// scheme while the iframe has
 https:// scheme. From my limited testing I receive the load
  event
 in all scenarios but couldn't find a way to query whether the load
 succeeded. I also tried window.addEventListener('error', ...) and
 iframe.addEventListener('error', ...) without any luck.

 Best regards,
 Tibor

 --
 You received this message because you are subscribed to the Google
 Groups "blink-dev" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to blink-dev+unsubscr...@chromium.org.
 To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3n%2B8i%2BNQNSJY0DFab9JrXG0QTq3W473t-beRtPYbLn1XjA%40mail.gmail.com
 
 .

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3nL-J4A0bQuXnU1Ns-eUYLNqVV65KZLeY3HuiPuBYQQmiQ%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF3XrKpDqd9ixPDOFiOu7NjMpmMm62nD0JxzBxyHfLmTJhr0PA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-tHzRF80hfAQ0-_3Z8QghM%3D%2BXj2GKGtVywdq%2BsLfJZkQ%40mail.gmail.com.

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread Daniel Cheng 
The iframe element supports "load" and "error event listeners. Is the exact
HTTP error needed? Or does the feature just need to know if it succeed or
not?

Daniel

On Wed, 17 Nov 2021 at 11:19, Tibor Goldschwendt 
wrote:

> +Nasko Oskov 
>
> Thanks, Kahmy. Adding custom code in the browser process is another avenue
> I'm exploring. Generally though, how do pages deal with broken iframes?
>
> On Wed, Nov 17, 2021 at 6:39 AM K. Moon  wrote:
>
>> This would violate the same-origin policy, so I don't think you can do
>> this within Blink, but given this is a chrome: page, maybe you could add
>> some code in the browser to give this information to you.
>>
>> On Tue, Nov 16, 2021, 4:40 PM Tibor Goldschwendt 
>> wrote:
>>
>>> Hi Blink Dev!
>>>
>>> Is there any way to get the HTTP return code of a cross-domain iframe?
>>> FWIW, the hosting page has the chrome:// scheme while the iframe has
>>> https:// scheme. From my limited testing I receive the load
>>>  event
>>> in all scenarios but couldn't find a way to query whether the load
>>> succeeded. I also tried window.addEventListener('error', ...) and
>>> iframe.addEventListener('error', ...) without any luck.
>>>
>>> Best regards,
>>> Tibor
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3n%2B8i%2BNQNSJY0DFab9JrXG0QTq3W473t-beRtPYbLn1XjA%40mail.gmail.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3nL-J4A0bQuXnU1Ns-eUYLNqVV65KZLeY3HuiPuBYQQmiQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF3XrKpDqd9ixPDOFiOu7NjMpmMm62nD0JxzBxyHfLmTJhr0PA%40mail.gmail.com.

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread Tibor Goldschwendt 
+Nasko Oskov 

Thanks, Kahmy. Adding custom code in the browser process is another avenue
I'm exploring. Generally though, how do pages deal with broken iframes?

On Wed, Nov 17, 2021 at 6:39 AM K. Moon  wrote:

> This would violate the same-origin policy, so I don't think you can do
> this within Blink, but given this is a chrome: page, maybe you could add
> some code in the browser to give this information to you.
>
> On Tue, Nov 16, 2021, 4:40 PM Tibor Goldschwendt 
> wrote:
>
>> Hi Blink Dev!
>>
>> Is there any way to get the HTTP return code of a cross-domain iframe?
>> FWIW, the hosting page has the chrome:// scheme while the iframe has
>> https:// scheme. From my limited testing I receive the load
>>  event
>> in all scenarios but couldn't find a way to query whether the load
>> succeeded. I also tried window.addEventListener('error', ...) and
>> iframe.addEventListener('error', ...) without any luck.
>>
>> Best regards,
>> Tibor
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3n%2B8i%2BNQNSJY0DFab9JrXG0QTq3W473t-beRtPYbLn1XjA%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3nL-J4A0bQuXnU1Ns-eUYLNqVV65KZLeY3HuiPuBYQQmiQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Window Controls Overlay for Installed Desktop Web Apps

2021-11-17 Thread Diego González 
Hola,

See the updated spec here: https://wicg.github.io/window-controls-overlay. 

Thanks


On Monday, 15 November 2021 at 17:00:34 UTC Ajay Rahatekar wrote:

> cc: ajayra...@google.com
>
> On Monday, November 15, 2021 at 8:53:37 AM UTC-8 Diego González wrote:
>
>> Hola Yoav, I am looking at making the amendments listed on the github 
>> issues. I will update soon with the changes. Thanks 
>>
>> On Monday, 15 November 2021 at 08:44:41 UTC yoav...@chromium.org wrote:
>>
>>> Thanks Diego! The updates are a great improvement, but I suspect are not 
>>> sufficient for an interoperable implementation. I left a couple of comments 
>>> on the open issues.
>>>
>>> On Wed, Nov 10, 2021 at 5:11 PM Diego González  wrote:
>>>
 Hola Yoav,

 We've gone through several iterations of the WCO spec reviewed by 
 Joshua Bell from Google, and while we are still making changes to it, we 
 believe it is in a much better state and want to resubmit for 
 consideration 
 of the approvals needed for I2S.  See the updated spec below:
 https://wicg.github.io/window-controls-overlay/

 --Diego

 On Thursday, 21 October 2021 at 21:05:09 UTC+1 yoav...@chromium.org 
 wrote:

> On Thursday, October 21, 2021 at 9:31:23 AM UTC+2 Yoav Weiss wrote:
>
>> This is an exciting improvement to PWA parity with native apps! :) 
>>
>> On Wed, Oct 20, 2021 at 10:49 PM 'Diego Gonzalez' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Contact emails 
>>>
>>> amb...@microsoft.com, luig...@microsoft.com, hat...@microsoft.com, 
>>> c...@chromium.org
>>>
>>>  
>>> Explainer 
>>>
>>>
>>> https://github.com/WICG/window-controls-overlay/blob/master/explainer.md
>>>
>>>  
>>> Specification 
>>>
>>> https://wicg.github.io/window-controls-overlay/ 
>>>
>>
>> The spec looks like it could use some work. Beyond the editorial, it 
>> doesn't seem like it defines the novel concepts that it introduces, nor 
>> the 
>> relevant processing models.
>>
>
> Let me expand on that a bit. The spec introduces a new concept of a 
> "window overlay" without really creating it as a concept. 
> What I expect an interoperable spec to define the concept with as much 
> detail as possible without getting OS- or implementation-specific. 
> (Just to draw an example of what I have in mind, if I had to make 
> something up, I'd go with something like: "Window overlay is 
> an 
> interface element that the operating system uses consistently across 
> applications to enable the user to perform certain action to control the 
> application such as closing it, expanding it to full screen, etc. This UI 
> element takes fixed dimensions")
>
> Then, once you have that concept defined, you can start building on it 
> and define the processing of the different methods based on that.
>
> I'll open issues with other suggestions.
>
>  
>>
>>>  
>>> Design docs 
>>>
>>>  
>>>
>>>
>>> https://github.com/WICG/window-controls-overlay/blob/main/explainer.md
>>>
>>>  
>>> Summary 
>>>
>>> Window Controls Overlay allows a developer to create a custom title 
>>> bar UX by extending the installed app’s client area. The client area 
>>> now 
>>> covers the entire window except for the window controls (close, 
>>> maximize/restore, minimize), which are overlaid in their respective 
>>> position. 
>>>
>>>  
>>>
>>> The web app developer is responsible for drawing and input-handling 
>>> for the entire window except for the window controls overlay. This 
>>> includes defining which area of the window is draggable as well, with a 
>>> prefixed and non-prefixed version of a css property supported, as 
>>> implemented in: crrev.com/c/3094474.
>>>
>>>  
>>>
>>> Intended uses for the Window Controls Overlay are creating seamless 
>>> UX that can use the area that was reserved for the title bar before. 
>>> Many 
>>> modern applications include menus, search bars and other controls in 
>>> the 
>>> title bar, and this feature enables this on installed web apps.
>>>
>>>  
>>> Blink component 
>>>
>>> UI>Browser>WebAppInstalls 
>>> 
>>>
>>>  
>>> Search tags 
>>>
>>> PWA , web app 
>>> , title bar 
>>> , titlebar 
>>> , customization 
>>> , window 
>>> controls 
>>>

Re: [blink-dev] HTTP return code of iframe?

2021-11-17 Thread K. Moon 
This would violate the same-origin policy, so I don't think you can do this
within Blink, but given this is a chrome: page, maybe you could add some
code in the browser to give this information to you.

On Tue, Nov 16, 2021, 4:40 PM Tibor Goldschwendt 
wrote:

> Hi Blink Dev!
>
> Is there any way to get the HTTP return code of a cross-domain iframe?
> FWIW, the hosting page has the chrome:// scheme while the iframe has
> https:// scheme. From my limited testing I receive the load
>  event
> in all scenarios but couldn't find a way to query whether the load
> succeeded. I also tried window.addEventListener('error', ...) and
> iframe.addEventListener('error', ...) without any luck.
>
> Best regards,
> Tibor
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3n%2B8i%2BNQNSJY0DFab9JrXG0QTq3W473t-beRtPYbLn1XjA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACwGi-69bRB9OONTAURu7tWVrcfKkjcpO9kT4B0dMd4aPC0W4Q%40mail.gmail.com.

Re: [blink-dev] BlinkOn 15 is Today and Tomorrow

2021-11-17 Thread 'Thomas Steiner' via blink-dev 
>
> It looks like the talks from yesterday are already in the usual YouTube
> channel:
> https://www.youtube.com/playlist?list=PL9ioqAuyl6UL_1DiG1tPRHbGJlGQ_gQJW


Oh, nice! I looked on the event platform and it said there were no recorded
sessions. Thanks for the link!

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLk62vSJW%2Bp_dgkbpCb8FZdkW-v-f8jzHABsptN%3D8Mu5tQ%40mail.gmail.com.

Re: [blink-dev] BlinkOn 15 is Today and Tomorrow

2021-11-17 Thread Manuel Rego Casasnovas 



On 17/11/2021 11:38, 'Thomas Steiner' via blink-dev wrote:
> Does the event platform publish to YouTube in the background? If so,
> does anyone have the unlisted livestream links so I could follow up? Thanks!

It looks like the talks from yesterday are already in the usual YouTube
channel:
https://www.youtube.com/playlist?list=PL9ioqAuyl6UL_1DiG1tPRHbGJlGQ_gQJW

Cheers,
  Rego

> 
> On Tue, Nov 16, 2021 at 7:04 PM Vincent Scheib  > wrote:
> 
> https://www.chromium.org/events/blinkon-15
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+unsubscr...@chromium.org
> .
> To view this discussion on the web visit
> 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK-EfX%3Dn%3DDd4UUyBJZ%2BRoaYhuWkutgO8zny-sNrB0i9h0BfSQA%40mail.gmail.com
> 
> .
> 
> 
> 
> -- 
> Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com
> , https://twitter.com/tomayac
> )
> 
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> Registergericht und -nummer: Hamburg, HRB 86891
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.3.2 (GNU/Linux)
> 
> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/
> 
> -END PGP SIGNATURE-
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+unsubscr...@chromium.org
> .
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLnUpmXn_3eY_Aux506O8FmPFacs2DDUYv9QS9rRDU8RFw%40mail.gmail.com
> .

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bcd7e21d-a784-2fd1-9d3e-d50470495156%40igalia.com.

Re: [blink-dev] Intent to Ship: Remove font-family -webkit-standard

2021-11-17 Thread Frédéric Wang 
I started to poke through 
https://github.com/search?p=5=%22-webkit-standard%22=Code out 
of curiosity and a few things stand out:


1) Some tools used for archiving / exports appear:

Evernote: 
https://github.com/karshih/Notes/blob/edf2d8658db898a4d993a22db62722e2d8e23ee8/accounts/www.evernote.com/100389449/content/ACFB7C02-6642-435C-B739-DBE738BDC66D/content.enml 



Some "HTTrack Website Copier": 
https://github.com/MicIOE/MicIOE.github.io/blob/533ac9fecef9e407b2f82061304fb2ee113c90a0/micioe/main/www.micioe.com/news/news2/2145.html 



It's possible the tools were generating the usage, or just capturing 
the result of certain pages already using it.


However, the results co-occur a lot with CJK fonts and mso- properties 
(MS Office docs saved to web? Outlook emails?). Do we have a guess at 
why Chinese documents might pick -webkit-standard over something else? 
Is there some kind of layout benefit that we might break?


i.e.,

https://github.com/huanyun-c/egg_linkingLeft/blob/36a00019d54219c07150bdf5fe07445d1d1a221a/app/view/rule/fwxy.ejs#L31-L37

https://github.com/english5-net/e5-ckeditor5-build/blob/a60acf23729ba6a48671cb3d0136294a26893360/packages/ckeditor5-paste-from-office/tests/_data/list/resume-template/normalized.safari.word2016.html#L3-L9

Thanks for taking a look. I'm not sure I have a proper answer to your 
question, but some comments below. In any case, maybe we want to be 
safer : analyze the pages reporting the counter and rely on a Finch flag?


Regarding the proprietary -mso properties, they are not affected by this 
intent to unship AFAIK.


Links 1, 3, 4 has a font-family with a single -webkit-standard while 
link 2 has a quoted '-webkit-standard' value (whether the name is quoted 
or not should not make a difference for Blink). It's indeed possible 
these pages are affected by this intent if the inherited font is not the 
default.


Checking WPT test css/cssom/font-family-serialization-001.html and also 
the initial value, it does not seem that WebKit or Blink serialize 
"-webkit-standard" name (unless they were already specified in the 
document). So I guess authoring tools do that on purpose, although I 
can't explain the rationale. Doc 4 has "Safari" in its name, which 
suggests it's designed for webkit.


Regarding CJK, we have special behavior on Android for these characters. 
And bug 1252383 showed that an internal use of "-webkit-standard" 
allowed to work around a Skia bug 12503. Bug again, I can't explain why 
someone would need to do it explicitly...


The @font-face{ font-family:"-webkit-standard";  } in link 3 is also 
weird, I'm not sure what's happening when we don't specify an src...


--
Frédéric Wang

--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8011715d-426b-bd26-c549-25f3be41cc96%40igalia.com.

Re: [blink-dev] Intent to Ship: Supports keyword format in @font-face src descriptor

2021-11-17 Thread Dominik Röttsches 
Hi Eric,

in the context of enabling COLRv1 and the discussion on feature detection
in CSS WG issue #6520  we
need a) implementation changes to the src: descriptor and b) we need
a @supports font-technology function, which was recently defined in the
spec and which I am prototyping here
.

In addition to your proposed change of supporting the keyword syntax, which
is generally good, we also need to support the new syntax for the
technology() function syntax in the font descriptor, which was recently
introduced in the spec. I prefer to handle both at the same time, adding
support for keyword syntax for format() as well as support for the new
technology() function in the src: descriptor in the same intent to ship,
which I plan to publish once I clarified whether we can go ahead and ship
these new changes of the spec. I am somewhat hesitant to have a separate
change only for the string -> keyword addition for format in the meantime.

Once I get to that, I will try to find a way for incorporating and landing
your change for the keyword support
 as part
of that work.

Dominik




On Mon, Nov 15, 2021 at 8:33 AM Yoav Weiss  wrote:

> Hey Eric!
>
> You may want to talk to +Dominik Röttsches , who
> filed a similar intent
> 
> in the past.
>
> On Fri, Nov 12, 2021 at 8:37 PM Mike Taylor 
> wrote:
>
>> Hi Eric,
>>
>> On 11/11/21 8:18 PM, Eric Huang wrote:
>>
>> Contact emails ele...@gmail.com
>>
>> Explainer https://drafts.csswg.org/css-fonts/#src-desc
>>
>> Specification https://drafts.csswg.org/css-fonts/#src-desc
>>
>> Summary
>>
>> Adds support for keyword in format function of @font-face src descriptor.
>> Supported keywords are: opentype, truetype, woff, woff2.
>>
>>
>> Blink component Blink
>> 
>>
>> TAG review
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>> Gecko: No signal
>>
>> WebKit: No signal
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>> In https://bugs.chromium.org/p/chromium/issues/detail?id=1242683#c3 it
>> says this works in Safari - so, you can update WebKit to Shipped/Shipping
>> (I verified on my local machine).
>>
>> As for Gecko, bit.ly/blink-signals explains how to request that position
>> from Mozilla.
>>
>>
>>
>> Debuggability
>>
>> No specific DevTools support
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>> Flag name
>>
>> Requires code in //chrome? False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1242683
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://www.chromestatus.com/feature/6214741698543616
>>
>> This intent message was generated by Chrome Platform Status
>> .
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALDfb_oynVyQ6_R_XFBy7TbzefJW-HqD_bKsE_G3ighNLjC7vA%40mail.gmail.com
>> 
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/47547205-6860-99ba-6b45-cb2c06c8d232%40chromium.org
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBvUboitGKVUBoWcQOj3HL9ST4h5yLpNEsgECk%2BnyUgeKQ%40mail.gmail.com.

Re: [blink-dev] BlinkOn 15 is Today and Tomorrow

2021-11-17 Thread 'Thomas Steiner' via blink-dev 
Does the event platform publish to YouTube in the background? If so, does
anyone have the unlisted livestream links so I could follow up? Thanks!

On Tue, Nov 16, 2021 at 7:04 PM Vincent Scheib  wrote:

> https://www.chromium.org/events/blinkon-15
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK-EfX%3Dn%3DDd4UUyBJZ%2BRoaYhuWkutgO8zny-sNrB0i9h0BfSQA%40mail.gmail.com
> 
> .
>


-- 
Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com,
https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.3.2 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
hTtPs://xKcd.cOm/1181/
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLnUpmXn_3eY_Aux506O8FmPFacs2DDUYv9QS9rRDU8RFw%40mail.gmail.com.