Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Thanks for the update Casey!

Your understanding of how the change to using scroll-margin instead of
root-margin for lazy loaded images is correct.
The MRE provided is working as expected.
Given that images near the viewport will be loaded, changing the menu
implementation seems like the right path forward to me.

Regards,
Traian


On Tue, Dec 12, 2023 at 3:08 PM Casey Carroll  wrote:

> I'd like to correct my original post. I assumed lazy images did not
> download until their visibility toggled from hidden to visible. It turns
> out our implementation actually places those images in a child of a parent
> with a hidden x-axis overflow. The images are placed outside the parent
> element box and are clipped. When the lazy load's IO init dictionary uses
> rootMargin, these images do not download until they are moved into the
> parent's element box. Now that scrollMargin is used, they are downloaded as
> soon as the page loads because they are near the viewport.
>
> Here is a MRE of the behavior:
> https://statuesque-sheer-innocent.glitch.me/
>
> On chrome v120 the lazy image does not download until you open menu level
> 2. On Chrome 121+, the image will download on page load.
>
> At the end of the day, we should probably change our mega menu
> implementation. We know Safari downloads all of these off-screen lazy
> images on page load anyway.
>
> On Monday, December 11, 2023 at 3:52:38 PM UTC-8 Chris Harrelson wrote:
>
>> On Mon, Dec 11, 2023 at 3:58 AM 'Mateusz Krzeszowiak' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Hi all!
>>>
>>> We were considering removing the lazy-loading inside the slider on shop.app
>>> product pages
>>> <https://shop.app/products/1592892555351?variantId=15817397174359> because
>>> the images appeared too late when scrolling, even on fast connections.
>>> I tested the new behaviour in Chrome Canary and it works perfectly, we
>>> won't have to change anything! Also, I'm not sure how the margin is
>>> configured, but in our case only the next image is loaded. This seems like
>>> a really good balance between performance and saving data.
>>>
>>
>> This is great feedback, thank you! Glad it worked for you.
>>
>>
>>>
>>> Thanks!
>>>
>>> On Saturday, December 9, 2023 at 6:49:24 PM UTC+1 Casey Carroll wrote:
>>>
>>>> Hi all!
>>>>
>>>> This sounds like a great addition to lazy loading behavior. I'm
>>>> wondering if this change had an effect on a lazy loading strategy
>>>> implemented on REI.com.
>>>>
>>>> Prior to 121, images with loading="lazy" tucked away in our hamburger
>>>> menu did not download until the hamburger menu's visibility changed from
>>>> hidden to visible. In v121 and 122 the images now download on initial
>>>> render, ignoring visibility: hidden.
>>>>
>>>> I can achieve the old behavior by using display: none rather than
>>>> visibility: hidden. However, I wonder if there are other similar
>>>> implementations in the wild and if their lazy loading behavior will change
>>>> as people upgrade to v121.
>>>>
>>>> Expected behavior (v120 and older):
>>>> (Mobile viewports):
>>>> 1. With the network panel open and filters set to images and
>>>> "merch-zones", visit www.rei.com
>>>> 2. Notice empty network panel
>>>> 3. Click the hamburger menu
>>>> 4. Notice all merch-zones images download
>>>>
>>>> (Desktop viewports):
>>>> 1. With the network panel open and filters set to images and
>>>> "merch-zones", visit www.rei.com
>>>> 2. Notice empty network panel
>>>> 3. Click on "Gifts"
>>>> 4. Notice merch-zones/gifts/live.jpg image downloads
>>>>
>>>> I have also attached videos to explain the change.
>>>>
>>>> Thank you!
>>>>
>>>> On Tuesday, December 5, 2023 at 12:23:51 PM UTC-8 PhistucK wrote:
>>>>
>>>>> Well, that is debatable... Because the image is 0x0 before it is
>>>>> loaded and centered, it is technically not in the viewport, but I am not
>>>>> sure why it would be 0x0. I am changing the original snippet to this
>>>>> (untested, just more like what I have) -
>>>>> 
>>>>>  >>>> src="some-image.jpg">
>>>>> 
>>>>> That extraneous  seems to cause this... I need to look into it.
>>>&

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Thanks for the feedback Mateusz!

Also, I'm not sure how the margin is configured, but in our case only the
> next image is loaded.
>
 The margin is configured
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/settings.json5;drc=bacaa805e405b7571f6e73be3649965a59c7e738;l=980>
based on the connection type.


> On Saturday, December 9, 2023 at 6:49:24 PM UTC+1 Casey Carroll wrote:
>
>> Hi all!
>>
>> This sounds like a great addition to lazy loading behavior. I'm wondering
>> if this change had an effect on a lazy loading strategy implemented on
>> REI.com.
>>
>> Prior to 121, images with loading="lazy" tucked away in our hamburger
>> menu did not download until the hamburger menu's visibility changed from
>> hidden to visible. In v121 and 122 the images now download on initial
>> render, ignoring visibility: hidden.
>>
>> I can achieve the old behavior by using display: none rather than
>> visibility: hidden. However, I wonder if there are other similar
>> implementations in the wild and if their lazy loading behavior will change
>> as people upgrade to v121.
>>
>> Expected behavior (v120 and older):
>> (Mobile viewports):
>> 1. With the network panel open and filters set to images and
>> "merch-zones", visit www.rei.com
>> 2. Notice empty network panel
>> 3. Click the hamburger menu
>> 4. Notice all merch-zones images download
>>
>> (Desktop viewports):
>> 1. With the network panel open and filters set to images and
>> "merch-zones", visit www.rei.com
>> 2. Notice empty network panel
>> 3. Click on "Gifts"
>> 4. Notice merch-zones/gifts/live.jpg image downloads
>>
>> I have also attached videos to explain the change.
>>
>> Thank you!
>>
>> On Tuesday, December 5, 2023 at 12:23:51 PM UTC-8 PhistucK wrote:
>>
>>> Well, that is debatable... Because the image is 0x0 before it is loaded
>>> and centered, it is technically not in the viewport, but I am not sure why
>>> it would be 0x0. I am changing the original snippet to this (untested, just
>>> more like what I have) -
>>> 
>>>  >> src="some-image.jpg">
>>> 
>>> That extraneous  seems to cause this... I need to look into it. I
>>> got confusing results.
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Tue, Dec 5, 2023 at 12:57 AM Traian Captan 
>>> wrote:
>>>
>>>> Thanks for the update!
>>>>
>>>> Since this involves a lazy loaded image, and you mentioned this is a
>>>> reduced test case, I wanted to check if the image is in viewport or out of
>>>> viewport in your test page?
>>>>
>>>> Regards,
>>>> Traian
>>>>
>>>>
>>>> On Sun, Dec 3, 2023 at 10:01 AM PhistucK  wrote:
>>>>
>>>>> When trying to generate a reduced test case, I found the underlying
>>>>> issue that explains the issue I was having -
>>>>> The image is centered and has a container with a fixed width with the
>>>>> image itself having a 100% width.
>>>>> This is just a snippet for illustrating the structure -
>>>>> 
>>>>>  
>>>>> 
>>>>>
>>>>> Issue - the image does not actually use the fixed width of the
>>>>> container (= 100%) until it is loaded.
>>>>> As a result, a 0x0 image is centered and it is not within the
>>>>> viewport, therefore not loaded.
>>>>>
>>>>> Chrome as well as Safari exhibit this behaviour, while Firefox gets it
>>>>> right.
>>>>>
>>>>> I will file an issue with the reduced test case for the
>>>>> no-dimensions-until-loaded issue.
>>>>>
>>>>>
>>>>>
>>>>> ☆*PhistucK*
>>>>>
>>>>>
>>>>> On Thu, Nov 30, 2023 at 5:33 PM Traian Captan 
>>>>> wrote:
>>>>>
>>>>>> Will do.
>>>>>> Would you mind sharing an example of the case you encountered so that
>>>>>> I can test it locally?
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 30, 2023 at 2:34 AM PhistucK  wrote:
>>>>>>
>>>>>>> I hit a case where even when 5 - 10 pixels of the image is in the
>>>>>>> scrolling viewport, it is still not loaded, so hopefully it will t

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Thanks for the update!

Since this involves a lazy loaded image, and you mentioned this is a
reduced test case, I wanted to check if the image is in viewport or out of
viewport in your test page?

Regards,
Traian


On Sun, Dec 3, 2023 at 10:01 AM PhistucK  wrote:

> When trying to generate a reduced test case, I found the underlying issue
> that explains the issue I was having -
> The image is centered and has a container with a fixed width with the
> image itself having a 100% width.
> This is just a snippet for illustrating the structure -
> 
>  
> 
>
> Issue - the image does not actually use the fixed width of the container
> (= 100%) until it is loaded.
> As a result, a 0x0 image is centered and it is not within the viewport,
> therefore not loaded.
>
> Chrome as well as Safari exhibit this behaviour, while Firefox gets it
> right.
>
> I will file an issue with the reduced test case for the
> no-dimensions-until-loaded issue.
>
>
>
> ☆*PhistucK*
>
>
> On Thu, Nov 30, 2023 at 5:33 PM Traian Captan 
> wrote:
>
>> Will do.
>> Would you mind sharing an example of the case you encountered so that I
>> can test it locally?
>>
>>
>> On Thu, Nov 30, 2023 at 2:34 AM PhistucK  wrote:
>>
>>> I hit a case where even when 5 - 10 pixels of the image is in the
>>> scrolling viewport, it is still not loaded, so hopefully it will take care
>>> of it as well. Let me know when this is in canary and I can try and test it
>>> out (at the moment I am not using lazy loading as a result). :)
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Thu, Nov 30, 2023 at 10:27 AM Traian Captan 
>>> wrote:
>>>
>>>> Hi Rick,
>>>>
>>>> Yes. I uploaded a CL that increases the spacer size by 30px:
>>>> https://chromium-review.googlesource.com/c/chromium/src/+/5075126
>>>>
>>>> The tests are now failing as expected on Safari:
>>>>
>>>> https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=pr_head=1=43446
>>>>
>>>>
>>>> On Thu, Nov 30, 2023 at 12:14 AM Rick Byers 
>>>> wrote:
>>>>
>>>>> Interesting. Could you try to improve the tests to capture the interop
>>>>> difference and ensure passing reflects full conformance to the spec? We
>>>>> rely on WPTs as our quantifiable measure of interoperability...
>>>>>
>>>>> Rick
>>>>>
>>>>> On Thu, Nov 30, 2023 at 5:07 PM Traian Captan 
>>>>> wrote:
>>>>>
>>>>>> Thank you Rick!
>>>>>>
>>>>>> I did some investigating into why WebKit is passing some of the new
>>>>>> WPTs for lazy loaded images.
>>>>>> I think it might be because WebKit is considering the edge as
>>>>>> inclusive, while Blink and Gecko do not.
>>>>>> In the following example if the spacer height is 100px Safari will
>>>>>> report intersecting as true while Chrome and FireFox would report it as
>>>>>> false.
>>>>>> If the height is increased to 101px, all 3 browsers will report the
>>>>>> intersection as false.
>>>>>> 
>>>>>> 
>>>>>> #scroller { width: 100px; height: 100px; overflow: scroll;
>>>>>> background-color: gray; }
>>>>>> #spacer { width: 50px; height: 100px; }
>>>>>> #target { width: 50px; height: 50px; background-color: green; }
>>>>>> 
>>>>>>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>
>>>>>> 
>>>>>> let entries = [];
>>>>>>
>>>>>> window.onload = function() {
>>>>>> const observer = new IntersectionObserver(
>>>>>> callback,
>>>>>> {
>>>>>> rootMargin: "0px"
>>>>>> }
>>>>>> );
>>>>>> observer.observe(target);
>>>>>> };
>>>>>>
>>>>>> function callback(entries) {
>>>>>> console.log(`isIntersecting = ${entries[0].isIntersecting}`);
>>>>>> }
>>>>>> 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 27, 2023 at 11:40 PM Rick Byers 
>>>>>> wrote:
>>>>>>
>>>&g

[blink-dev] Intent to Ship: Auto Sizes for Lazy Loaded Images with Srcset

[Traian Captan]

Contact emailstcap...@chromium.org

Explainerhttps://github.com/whatwg/html/issues/4654

Specificationhttps://html.spec.whatwg.org/#sizes-attributes

Summary

Auto Sizes allows developers to set the sizes attribute to auto
(sizes=auto) for lazy loaded image elements with srcset. For this use case
the image's width and height should be provided. The browser will use the
layout width of the image in order to select the source url from the srcset.


Blink componentBlink>Image


Search tagssizes , sizes=auto
, autosizes
, srcset


TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None since all major browsers (Chrome, Safari and Firefox) indicate that
they would be willing to implement it.


*Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/650
)

*WebKit*: Positive (https://github.com/WebKit/standards-positions/issues/9)

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?



Debuggability



Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Yes

PR for current tests pending merge:
https://github.com/web-platform-tests/wpt/pull/34427 Rendering wpt.fyi
tests will be included with the prototype CL.


Flag name on chrome://flagsAutoSizeLazyLoadedImages

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1359051

Estimated milestones
DevTrial on desktop 122
DevTrial on Android 122

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5191555708616704

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/AYoqvNluyeA

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/CAFxahvuCb7xXip6nqDAykaRGXy5uX3%2BXZsuPY62s9ntV03PDqw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Thank you Chris!


On Thu, Nov 30, 2023 at 10:57 AM Chris Harrelson 
wrote:

> LGTM3
>
> On Thu, Nov 30, 2023 at 10:54 AM Mike Taylor 
> wrote:
>
>> LGTM2
>> On 11/30/23 9:33 AM, Traian Captan wrote:
>>
>> You're welcome Rick!
>>
>>
>> On Thu, Nov 30, 2023 at 5:33 AM Rick Byers  wrote:
>>
>>> Thank you Traian!
>>>
>>> On Thu, Nov 30, 2023 at 7:27 PM Traian Captan 
>>> wrote:
>>>
>>>> Hi Rick,
>>>>
>>>> Yes. I uploaded a CL that increases the spacer size by 30px:
>>>> https://chromium-review.googlesource.com/c/chromium/src/+/5075126
>>>>
>>>> The tests are now failing as expected on Safari:
>>>>
>>>> https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=pr_head=1=43446
>>>>
>>>>
>>>> On Thu, Nov 30, 2023 at 12:14 AM Rick Byers 
>>>> wrote:
>>>>
>>>>> Interesting. Could you try to improve the tests to capture the interop
>>>>> difference and ensure passing reflects full conformance to the spec? We
>>>>> rely on WPTs as our quantifiable measure of interoperability...
>>>>>
>>>>> Rick
>>>>>
>>>>> On Thu, Nov 30, 2023 at 5:07 PM Traian Captan 
>>>>> wrote:
>>>>>
>>>>>> Thank you Rick!
>>>>>>
>>>>>> I did some investigating into why WebKit is passing some of the new
>>>>>> WPTs for lazy loaded images.
>>>>>> I think it might be because WebKit is considering the edge as
>>>>>> inclusive, while Blink and Gecko do not.
>>>>>> In the following example if the spacer height is 100px Safari will
>>>>>> report intersecting as true while Chrome and FireFox would report it as
>>>>>> false.
>>>>>> If the height is increased to 101px, all 3 browsers will report the
>>>>>> intersection as false.
>>>>>> 
>>>>>> 
>>>>>> #scroller { width: 100px; height: 100px; overflow: scroll;
>>>>>> background-color: gray; }
>>>>>> #spacer { width: 50px; height: 100px; }
>>>>>> #target { width: 50px; height: 50px; background-color: green; }
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> let entries = [];
>>>>>> window.onload = function() {
>>>>>> const observer = new IntersectionObserver(
>>>>>> callback,
>>>>>> {
>>>>>> rootMargin: "0px"
>>>>>> }
>>>>>> );
>>>>>> observer.observe(target);
>>>>>> };
>>>>>> function callback(entries) {
>>>>>> console.log(`isIntersecting = ${entries[0].isIntersecting}`);
>>>>>> }
>>>>>> 
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 27, 2023 at 11:40 PM Rick Byers 
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Nov 22, 2023 at 2:37 PM Yoav Weiss 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks, that sounds like a strict improvement.
>>>>>>>>
>>>>>>>> On Wed, Nov 22, 2023 at 6:25 AM Traian Captan 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Yes, that's correct.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Do I understand correctly that currently lazy-loaded images in
>>>>>>>>>> CSS scrollers have suboptimal behavior and this would improve that 
>>>>>>>>>> without
>>>>>>>>>> potentially harming other cases?
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 22, 2023 at 1:55 AM Traian Captan <
>>>>>>>>>> tcap...@chromium.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Contact emails tcap...@chromium.org
>>>>>>>>>>>
>>>>>>>>>>> Explaine

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Thank you Mike!

On Thu, Nov 30, 2023 at 10:54 AM Mike Taylor  wrote:

> LGTM2
> On 11/30/23 9:33 AM, Traian Captan wrote:
>
> You're welcome Rick!
>
>
> On Thu, Nov 30, 2023 at 5:33 AM Rick Byers  wrote:
>
>> Thank you Traian!
>>
>> On Thu, Nov 30, 2023 at 7:27 PM Traian Captan 
>> wrote:
>>
>>> Hi Rick,
>>>
>>> Yes. I uploaded a CL that increases the spacer size by 30px:
>>> https://chromium-review.googlesource.com/c/chromium/src/+/5075126
>>>
>>> The tests are now failing as expected on Safari:
>>>
>>> https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=pr_head=1=43446
>>>
>>>
>>> On Thu, Nov 30, 2023 at 12:14 AM Rick Byers  wrote:
>>>
>>>> Interesting. Could you try to improve the tests to capture the interop
>>>> difference and ensure passing reflects full conformance to the spec? We
>>>> rely on WPTs as our quantifiable measure of interoperability...
>>>>
>>>> Rick
>>>>
>>>> On Thu, Nov 30, 2023 at 5:07 PM Traian Captan 
>>>> wrote:
>>>>
>>>>> Thank you Rick!
>>>>>
>>>>> I did some investigating into why WebKit is passing some of the new
>>>>> WPTs for lazy loaded images.
>>>>> I think it might be because WebKit is considering the edge as
>>>>> inclusive, while Blink and Gecko do not.
>>>>> In the following example if the spacer height is 100px Safari will
>>>>> report intersecting as true while Chrome and FireFox would report it as
>>>>> false.
>>>>> If the height is increased to 101px, all 3 browsers will report the
>>>>> intersection as false.
>>>>> 
>>>>> 
>>>>> #scroller { width: 100px; height: 100px; overflow: scroll;
>>>>> background-color: gray; }
>>>>> #spacer { width: 50px; height: 100px; }
>>>>> #target { width: 50px; height: 50px; background-color: green; }
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> let entries = [];
>>>>> window.onload = function() {
>>>>> const observer = new IntersectionObserver(
>>>>> callback,
>>>>> {
>>>>> rootMargin: "0px"
>>>>> }
>>>>> );
>>>>> observer.observe(target);
>>>>> };
>>>>> function callback(entries) {
>>>>> console.log(`isIntersecting = ${entries[0].isIntersecting}`);
>>>>> }
>>>>> 
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 27, 2023 at 11:40 PM Rick Byers 
>>>>> wrote:
>>>>>
>>>>>> On Wed, Nov 22, 2023 at 2:37 PM Yoav Weiss 
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks, that sounds like a strict improvement.
>>>>>>>
>>>>>>> On Wed, Nov 22, 2023 at 6:25 AM Traian Captan 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yes, that's correct.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Do I understand correctly that currently lazy-loaded images in CSS
>>>>>>>>> scrollers have suboptimal behavior and this would improve that without
>>>>>>>>> potentially harming other cases?
>>>>>>>>>
>>>>>>>>> On Wed, Nov 22, 2023 at 1:55 AM Traian Captan <
>>>>>>>>> tcap...@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>>> Contact emails tcap...@chromium.org
>>>>>>>>>>
>>>>>>>>>> Explainer None
>>>>>>>>>>
>>>>>>>>>
>>>>>>> A short (inline) explainer would help reviewers to understand e.g.
>>>>>>> if this involves changes to the API surface that developers need to care
>>>>>>> about.
>>>>>>> Can you write a few words on the impact on developers?
>>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Speci

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

You're welcome Rick!


On Thu, Nov 30, 2023 at 5:33 AM Rick Byers  wrote:

> Thank you Traian!
>
> On Thu, Nov 30, 2023 at 7:27 PM Traian Captan 
> wrote:
>
>> Hi Rick,
>>
>> Yes. I uploaded a CL that increases the spacer size by 30px:
>> https://chromium-review.googlesource.com/c/chromium/src/+/5075126
>>
>> The tests are now failing as expected on Safari:
>>
>> https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=pr_head=1=43446
>>
>>
>> On Thu, Nov 30, 2023 at 12:14 AM Rick Byers  wrote:
>>
>>> Interesting. Could you try to improve the tests to capture the interop
>>> difference and ensure passing reflects full conformance to the spec? We
>>> rely on WPTs as our quantifiable measure of interoperability...
>>>
>>> Rick
>>>
>>> On Thu, Nov 30, 2023 at 5:07 PM Traian Captan 
>>> wrote:
>>>
>>>> Thank you Rick!
>>>>
>>>> I did some investigating into why WebKit is passing some of the new
>>>> WPTs for lazy loaded images.
>>>> I think it might be because WebKit is considering the edge as
>>>> inclusive, while Blink and Gecko do not.
>>>> In the following example if the spacer height is 100px Safari will
>>>> report intersecting as true while Chrome and FireFox would report it as
>>>> false.
>>>> If the height is increased to 101px, all 3 browsers will report the
>>>> intersection as false.
>>>> 
>>>> 
>>>> #scroller { width: 100px; height: 100px; overflow: scroll;
>>>> background-color: gray; }
>>>> #spacer { width: 50px; height: 100px; }
>>>> #target { width: 50px; height: 50px; background-color: green; }
>>>> 
>>>>
>>>> 
>>>> 
>>>> 
>>>> 
>>>>
>>>> 
>>>> let entries = [];
>>>>
>>>> window.onload = function() {
>>>> const observer = new IntersectionObserver(
>>>> callback,
>>>> {
>>>> rootMargin: "0px"
>>>> }
>>>> );
>>>> observer.observe(target);
>>>> };
>>>>
>>>> function callback(entries) {
>>>> console.log(`isIntersecting = ${entries[0].isIntersecting}`);
>>>> }
>>>> 
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Nov 27, 2023 at 11:40 PM Rick Byers 
>>>> wrote:
>>>>
>>>>> On Wed, Nov 22, 2023 at 2:37 PM Yoav Weiss 
>>>>> wrote:
>>>>>
>>>>>> Thanks, that sounds like a strict improvement.
>>>>>>
>>>>>> On Wed, Nov 22, 2023 at 6:25 AM Traian Captan 
>>>>>> wrote:
>>>>>>
>>>>>>> Yes, that's correct.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Do I understand correctly that currently lazy-loaded images in CSS
>>>>>>>> scrollers have suboptimal behavior and this would improve that without
>>>>>>>> potentially harming other cases?
>>>>>>>>
>>>>>>>> On Wed, Nov 22, 2023 at 1:55 AM Traian Captan 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Contact emailstcap...@chromium.org
>>>>>>>>>
>>>>>>>>> ExplainerNone
>>>>>>>>>
>>>>>>>>
>>>>>> A short (inline) explainer would help reviewers to understand e.g. if
>>>>>> this involves changes to the API surface that developers need to care 
>>>>>> about.
>>>>>> Can you write a few words on the impact on developers?
>>>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>> Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin
>>>>>>>>>
>>>>>>>>
>>>>>> The spec doesn't mention anything specific around root margins or
>>>>>> scroll margins (other than the algorithm name).
>>>>>> Are these concepts interoperable?
>>>>>>
>>>>>
>>>>> I dug around a little to try to better understand this. The HTML spec
>>>>> does me

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Will do.
Would you mind sharing an example of the case you encountered so that I can
test it locally?


On Thu, Nov 30, 2023 at 2:34 AM PhistucK  wrote:

> I hit a case where even when 5 - 10 pixels of the image is in the
> scrolling viewport, it is still not loaded, so hopefully it will take care
> of it as well. Let me know when this is in canary and I can try and test it
> out (at the moment I am not using lazy loading as a result). :)
>
> ☆*PhistucK*
>
>
> On Thu, Nov 30, 2023 at 10:27 AM Traian Captan 
> wrote:
>
>> Hi Rick,
>>
>> Yes. I uploaded a CL that increases the spacer size by 30px:
>> https://chromium-review.googlesource.com/c/chromium/src/+/5075126
>>
>> The tests are now failing as expected on Safari:
>>
>> https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=pr_head=1=43446
>>
>>
>> On Thu, Nov 30, 2023 at 12:14 AM Rick Byers  wrote:
>>
>>> Interesting. Could you try to improve the tests to capture the interop
>>> difference and ensure passing reflects full conformance to the spec? We
>>> rely on WPTs as our quantifiable measure of interoperability...
>>>
>>> Rick
>>>
>>> On Thu, Nov 30, 2023 at 5:07 PM Traian Captan 
>>> wrote:
>>>
>>>> Thank you Rick!
>>>>
>>>> I did some investigating into why WebKit is passing some of the new
>>>> WPTs for lazy loaded images.
>>>> I think it might be because WebKit is considering the edge as
>>>> inclusive, while Blink and Gecko do not.
>>>> In the following example if the spacer height is 100px Safari will
>>>> report intersecting as true while Chrome and FireFox would report it as
>>>> false.
>>>> If the height is increased to 101px, all 3 browsers will report the
>>>> intersection as false.
>>>> 
>>>> 
>>>> #scroller { width: 100px; height: 100px; overflow: scroll;
>>>> background-color: gray; }
>>>> #spacer { width: 50px; height: 100px; }
>>>> #target { width: 50px; height: 50px; background-color: green; }
>>>> 
>>>>
>>>> 
>>>> 
>>>> 
>>>> 
>>>>
>>>> 
>>>> let entries = [];
>>>>
>>>> window.onload = function() {
>>>> const observer = new IntersectionObserver(
>>>> callback,
>>>> {
>>>> rootMargin: "0px"
>>>> }
>>>> );
>>>> observer.observe(target);
>>>> };
>>>>
>>>> function callback(entries) {
>>>> console.log(`isIntersecting = ${entries[0].isIntersecting}`);
>>>> }
>>>> 
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Nov 27, 2023 at 11:40 PM Rick Byers 
>>>> wrote:
>>>>
>>>>> On Wed, Nov 22, 2023 at 2:37 PM Yoav Weiss 
>>>>> wrote:
>>>>>
>>>>>> Thanks, that sounds like a strict improvement.
>>>>>>
>>>>>> On Wed, Nov 22, 2023 at 6:25 AM Traian Captan 
>>>>>> wrote:
>>>>>>
>>>>>>> Yes, that's correct.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Do I understand correctly that currently lazy-loaded images in CSS
>>>>>>>> scrollers have suboptimal behavior and this would improve that without
>>>>>>>> potentially harming other cases?
>>>>>>>>
>>>>>>>> On Wed, Nov 22, 2023 at 1:55 AM Traian Captan 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Contact emailstcap...@chromium.org
>>>>>>>>>
>>>>>>>>> ExplainerNone
>>>>>>>>>
>>>>>>>>
>>>>>> A short (inline) explainer would help reviewers to understand e.g. if
>>>>>> this involves changes to the API surface that developers need to care 
>>>>>> about.
>>>>>> Can you write a few words on the impact on developers?
>>>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>> Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin
>>>>>>>>>
>>>>>>>&g

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Hi Rick,

Yes. I uploaded a CL that increases the spacer size by 30px:
https://chromium-review.googlesource.com/c/chromium/src/+/5075126

The tests are now failing as expected on Safari:
https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=pr_head=1=43446


On Thu, Nov 30, 2023 at 12:14 AM Rick Byers  wrote:

> Interesting. Could you try to improve the tests to capture the interop
> difference and ensure passing reflects full conformance to the spec? We
> rely on WPTs as our quantifiable measure of interoperability...
>
> Rick
>
> On Thu, Nov 30, 2023 at 5:07 PM Traian Captan 
> wrote:
>
>> Thank you Rick!
>>
>> I did some investigating into why WebKit is passing some of the new WPTs
>> for lazy loaded images.
>> I think it might be because WebKit is considering the edge as inclusive,
>> while Blink and Gecko do not.
>> In the following example if the spacer height is 100px Safari will report
>> intersecting as true while Chrome and FireFox would report it as false.
>> If the height is increased to 101px, all 3 browsers will report the
>> intersection as false.
>> 
>> 
>> #scroller { width: 100px; height: 100px; overflow: scroll;
>> background-color: gray; }
>> #spacer { width: 50px; height: 100px; }
>> #target { width: 50px; height: 50px; background-color: green; }
>> 
>>
>> 
>> 
>> 
>> 
>>
>> 
>> let entries = [];
>>
>> window.onload = function() {
>> const observer = new IntersectionObserver(
>> callback,
>> {
>> rootMargin: "0px"
>> }
>> );
>> observer.observe(target);
>> };
>>
>> function callback(entries) {
>> console.log(`isIntersecting = ${entries[0].isIntersecting}`);
>> }
>> 
>>
>>
>>
>>
>> On Mon, Nov 27, 2023 at 11:40 PM Rick Byers  wrote:
>>
>>> On Wed, Nov 22, 2023 at 2:37 PM Yoav Weiss 
>>> wrote:
>>>
>>>> Thanks, that sounds like a strict improvement.
>>>>
>>>> On Wed, Nov 22, 2023 at 6:25 AM Traian Captan 
>>>> wrote:
>>>>
>>>>> Yes, that's correct.
>>>>>
>>>>>
>>>>> On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss 
>>>>> wrote:
>>>>>
>>>>>> Do I understand correctly that currently lazy-loaded images in CSS
>>>>>> scrollers have suboptimal behavior and this would improve that without
>>>>>> potentially harming other cases?
>>>>>>
>>>>>> On Wed, Nov 22, 2023 at 1:55 AM Traian Captan 
>>>>>> wrote:
>>>>>>
>>>>>>> Contact emailstcap...@chromium.org
>>>>>>>
>>>>>>> ExplainerNone
>>>>>>>
>>>>>>
>>>> A short (inline) explainer would help reviewers to understand e.g. if
>>>> this involves changes to the API surface that developers need to care 
>>>> about.
>>>> Can you write a few words on the impact on developers?
>>>>
>>>>
>>>>>>>
>>>>>>> Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin
>>>>>>>
>>>>>>
>>>> The spec doesn't mention anything specific around root margins or
>>>> scroll margins (other than the algorithm name).
>>>> Are these concepts interoperable?
>>>>
>>>
>>> I dug around a little to try to better understand this. The HTML spec
>>> does mention
>>> <https://html.spec.whatwg.org/#start-intersection-observing-a-lazy-loading-element>
>>>  setting
>>> the "scrollMargin" on the IntersectionObserver, a new property we recently
>>> shipped (I2S
>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Ax8rTBusZ4s/m/nogj-s-eGQAJ?utm_medium=email_source=footer>
>>> ).
>>> While WebKit and Gecko aren't yet passing the WPT tests
>>> <https://wpt.fyi/results/intersection-observer?label=master=experimental=scroll-margin>
>>> for this yet, interestingly WebKit is already passing
>>> <https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=master=experimental=image-loading-lazy-in->
>>> most of the newly added
>>> <https://chromium-review.googlesource.com/c/chromium/src/+/5023396>
>>> WPTs for lazy loaded images in particular. So perhaps their implementation
>>> already handled this?
>>>
>>> Seems reasonable to me -

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Thank you Rick!

I did some investigating into why WebKit is passing some of the new WPTs
for lazy loaded images.
I think it might be because WebKit is considering the edge as inclusive,
while Blink and Gecko do not.
In the following example if the spacer height is 100px Safari will report
intersecting as true while Chrome and FireFox would report it as false.
If the height is increased to 101px, all 3 browsers will report the
intersection as false.


#scroller { width: 100px; height: 100px; overflow: scroll; background-color:
gray; }
#spacer { width: 50px; height: 100px; }
#target { width: 50px; height: 50px; background-color: green; }








let entries = [];

window.onload = function() {
const observer = new IntersectionObserver(
callback,
{
rootMargin: "0px"
}
);
observer.observe(target);
};

function callback(entries) {
console.log(`isIntersecting = ${entries[0].isIntersecting}`);
}





On Mon, Nov 27, 2023 at 11:40 PM Rick Byers  wrote:

> On Wed, Nov 22, 2023 at 2:37 PM Yoav Weiss  wrote:
>
>> Thanks, that sounds like a strict improvement.
>>
>> On Wed, Nov 22, 2023 at 6:25 AM Traian Captan 
>> wrote:
>>
>>> Yes, that's correct.
>>>
>>>
>>> On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss 
>>> wrote:
>>>
>>>> Do I understand correctly that currently lazy-loaded images in CSS
>>>> scrollers have suboptimal behavior and this would improve that without
>>>> potentially harming other cases?
>>>>
>>>> On Wed, Nov 22, 2023 at 1:55 AM Traian Captan 
>>>> wrote:
>>>>
>>>>> Contact emailstcap...@chromium.org
>>>>>
>>>>> ExplainerNone
>>>>>
>>>>
>> A short (inline) explainer would help reviewers to understand e.g. if
>> this involves changes to the API surface that developers need to care about.
>> Can you write a few words on the impact on developers?
>>
>>
>>>>>
>>>>> Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin
>>>>>
>>>>
>> The spec doesn't mention anything specific around root margins or scroll
>> margins (other than the algorithm name).
>> Are these concepts interoperable?
>>
>
> I dug around a little to try to better understand this. The HTML spec does
> mention
> <https://html.spec.whatwg.org/#start-intersection-observing-a-lazy-loading-element>
>  setting
> the "scrollMargin" on the IntersectionObserver, a new property we recently
> shipped (I2S
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Ax8rTBusZ4s/m/nogj-s-eGQAJ?utm_medium=email_source=footer>
> ).
> While WebKit and Gecko aren't yet passing the WPT tests
> <https://wpt.fyi/results/intersection-observer?label=master=experimental=scroll-margin>
> for this yet, interestingly WebKit is already passing
> <https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=master=experimental=image-loading-lazy-in->
> most of the newly added
> <https://chromium-review.googlesource.com/c/chromium/src/+/5023396> WPTs
> for lazy loaded images in particular. So perhaps their implementation
> already handled this?
>
> Seems reasonable to me - LGTM1
>
>
>>>>>
>>>>> Summary
>>>>>
>>>>> Changes the lazy load intersection observer's init dictionary to use a
>>>>> scrollMargin instead of a rootMargin. This allows lazy loading images
>>>>> contained inside CSS scrollers, like carousels, to load as expected when
>>>>> near the viewport instead of the current behavior where these images load
>>>>> when at least one pixel is intersecting the viewport.
>>>>>
>>>>>
>>>>> Blink componentBlink>Image
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EImage>
>>>>>
>>>>> Search tagslazyload <https://chromestatus.com/features#tags:lazyload>
>>>>> , scrollmargin <https://chromestatus.com/features#tags:scrollmargin>
>>>>>
>>>>> TAG reviewNone
>>>>>
>>>>> TAG review statusNot applicable
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>> Overall low as scroll margin also applies to the root element thus not
>>>>> affecting lazy loading images that are currently loading with just a root
>>>>> margin.
>>>>>
>>>>>
>>>>> *Gecko*: Positive (
>&g

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

>
>
> Thanks, that sounds like a strict improvement.
>
Yes.

ExplainerNone
>>>>
>>>
> A short (inline) explainer would help reviewers to understand e.g. if this
> involves changes to the API surface that developers need to care about.
> Can you write a few words on the impact on developers?
>
Here's a link to the explainer I extracted out of the motivation section:
https://gist.github.com/tcaptan-cr/bf0ac25f77cb6b6c58c916e6577d91c3
I added it to the "Doc link(s)" section in Chrome Platform Status tool
since I didn't see a specific place label "Explainer".
This change is internal to how we set up the intersection observer for lazy
loaded images and no new API surface is exposed.
Developers only need to add the `loading="lazy"` attribute to the out of
viewport images like they did before, the only difference being that the
images now will load when near the viewport like expected instead of
loading late, when at least one pixel is intersecting the viewport.

Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin
>>>>
>>>
> The spec doesn't mention anything specific around root margins or scroll
> margins (other than the algorithm name).
> Are these concepts interoperable?
>
 It is mentioned in the intersection observer setup options:
"The options is an IntersectionObserverInit
<https://w3c.github.io/IntersectionObserver/#dictdef-intersectionobserverinit>
dictionary
with the following dictionary members: «[ "scrollMargin" → lazy load scroll
margin <https://html.spec.whatwg.org/#lazy-load-root-margin> ]»"
As for interoperability between them, you can think of scrollMargin as a
superset of rootMargin. In cases without nested scrollers, initializing an
intersection observer with either scroll or root margin will behave the
same. However, in cases with nested scrollers, using root margin will cause
images to load late while using scroll margin will cause them to load as
expected.


On Tue, Nov 21, 2023 at 9:37 PM Yoav Weiss  wrote:

> Thanks, that sounds like a strict improvement.
>
> On Wed, Nov 22, 2023 at 6:25 AM Traian Captan 
> wrote:
>
>> Yes, that's correct.
>>
>>
>> On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss 
>> wrote:
>>
>>> Do I understand correctly that currently lazy-loaded images in CSS
>>> scrollers have suboptimal behavior and this would improve that without
>>> potentially harming other cases?
>>>
>>> On Wed, Nov 22, 2023 at 1:55 AM Traian Captan 
>>> wrote:
>>>
>>>> Contact emailstcap...@chromium.org
>>>>
>>>> ExplainerNone
>>>>
>>>
> A short (inline) explainer would help reviewers to understand e.g. if this
> involves changes to the API surface that developers need to care about.
> Can you write a few words on the impact on developers?
>
>
>>>>
>>>> Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin
>>>>
>>>
> The spec doesn't mention anything specific around root margins or scroll
> margins (other than the algorithm name).
> Are these concepts interoperable?
>
>
>>
>>>>
>>>> Summary
>>>>
>>>> Changes the lazy load intersection observer's init dictionary to use a
>>>> scrollMargin instead of a rootMargin. This allows lazy loading images
>>>> contained inside CSS scrollers, like carousels, to load as expected when
>>>> near the viewport instead of the current behavior where these images load
>>>> when at least one pixel is intersecting the viewport.
>>>>
>>>>
>>>> Blink componentBlink>Image
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EImage>
>>>>
>>>> Search tagslazyload <https://chromestatus.com/features#tags:lazyload>,
>>>> scrollmargin <https://chromestatus.com/features#tags:scrollmargin>
>>>>
>>>> TAG reviewNone
>>>>
>>>> TAG review statusNot applicable
>>>>
>>>> Risks
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> Overall low as scroll margin also applies to the root element thus not
>>>> affecting lazy loading images that are currently loading with just a root
>>>> margin.
>>>>
>>>>
>>>> *Gecko*: Positive (
>>>> https://github.com/w3c/IntersectionObserver/issues/431)
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1864794
>>>>
>>>> *WebKit*: Positive (
>>>> https://github.com/w3c/Inters

Re: [blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Yes, that's correct.


On Tue, Nov 21, 2023 at 9:18 PM Yoav Weiss  wrote:

> Do I understand correctly that currently lazy-loaded images in CSS
> scrollers have suboptimal behavior and this would improve that without
> potentially harming other cases?
>
> On Wed, Nov 22, 2023 at 1:55 AM Traian Captan 
> wrote:
>
>> Contact emailstcap...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin
>>
>> Summary
>>
>> Changes the lazy load intersection observer's init dictionary to use a
>> scrollMargin instead of a rootMargin. This allows lazy loading images
>> contained inside CSS scrollers, like carousels, to load as expected when
>> near the viewport instead of the current behavior where these images load
>> when at least one pixel is intersecting the viewport.
>>
>>
>> Blink componentBlink>Image
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EImage>
>>
>> Search tagslazyload <https://chromestatus.com/features#tags:lazyload>,
>> scrollmargin <https://chromestatus.com/features#tags:scrollmargin>
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Overall low as scroll margin also applies to the root element thus not
>> affecting lazy loading images that are currently loading with just a root
>> margin.
>>
>>
>> *Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431
>> ) https://bugzilla.mozilla.org/show_bug.cgi?id=1864794
>>
>> *WebKit*: Positive (
>> https://github.com/w3c/IntersectionObserver/issues/431#issuecomment-930602435
>> ) https://bugs.webkit.org/show_bug.cgi?id=264864
>>
>> *Web developers*: Positive (
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1391989)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes
>>
>>
>> https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=master=experimental=image-loading-lazy-in-
>>
>>
>> Flag name on chrome://flagsLazyLoadScrollMargin
>>
>> Finch feature nameNone
>>
>> Non-finch justification
>>
>> This feature is behind an enabled-by-default flag that can be disabled if
>> needed.
>>
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1391989
>>
>> Estimated milestones
>> Shipping on desktop 121
>> DevTrial on desktop 121
>> Shipping on Android 121
>> DevTrial on Android 121
>> Shipping on WebView 121
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5106926245642240
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvtrmHkoOpTuD2eZYVOyFuAhP8ZFVoTuNBS8zYTVY%3DTaaQ%40mail.gmail.com
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.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/CAFxahvsUb0GEG9WNWRN7Akkowjm03gLj%2Biiq5rG8%2BzdAWMBTNA%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsUb0GEG9WNWRN7Akkowjm03gLj%2Biiq5rG8%2BzdAWMBTNA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAFxahvtwYuj4dukn%3DW5m%3D0f2CGipMw7JAugFt56kouPjfFp0Sw%40mail.gmail.com.

[blink-dev] Intent to Ship: Lazy load scroll margin

[Traian Captan]

Contact emailstcap...@chromium.org

ExplainerNone

Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin

Summary

Changes the lazy load intersection observer's init dictionary to use a
scrollMargin instead of a rootMargin. This allows lazy loading images
contained inside CSS scrollers, like carousels, to load as expected when
near the viewport instead of the current behavior where these images load
when at least one pixel is intersecting the viewport.


Blink componentBlink>Image


Search tagslazyload ,
scrollmargin 

TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Overall low as scroll margin also applies to the root element thus not
affecting lazy loading images that are currently loading with just a root
margin.


*Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)
https://bugzilla.mozilla.org/show_bug.cgi?id=1864794

*WebKit*: Positive (
https://github.com/w3c/IntersectionObserver/issues/431#issuecomment-930602435
) https://bugs.webkit.org/show_bug.cgi?id=264864

*Web developers*: Positive (
https://bugs.chromium.org/p/chromium/issues/detail?id=1391989)

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=master=experimental=image-loading-lazy-in-


Flag name on chrome://flagsLazyLoadScrollMargin

Finch feature nameNone

Non-finch justification

This feature is behind an enabled-by-default flag that can be disabled if
needed.


Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1391989

Estimated milestones
Shipping on desktop 121
DevTrial on desktop 121
Shipping on Android 121
DevTrial on Android 121
Shipping on WebView 121

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5106926245642240

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvtrmHkoOpTuD2eZYVOyFuAhP8ZFVoTuNBS8zYTVY%3DTaaQ%40mail.gmail.com

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/CAFxahvsUb0GEG9WNWRN7Akkowjm03gLj%2Biiq5rG8%2BzdAWMBTNA%40mail.gmail.com.

[blink-dev] Intent to Prototype: Lazy load scroll margin

[Traian Captan]

Contact emailstcap...@chromium.org

ExplainerNone

Specificationhttps://html.spec.whatwg.org/#lazy-load-root-margin

Summary

Changes the lazy load intersection observer's init dictionary to use a
scrollMargin instead of a rootMargin. This allows lazy loading images
contained inside CSS scrollers, like carousels, to load as expected when
near the viewport instead of the current behavior where these images load
when at least one pixel is intersecting the viewport.


Blink componentBlink>Image


Motivation

Currently the lazy load intersection observer is set up using a rootMargin.
This does not work well for pages that use images in CSS scrollers, like
carousels, causing the images to load too late, when they become visible
and the intersection with the root is detected. To work around this issue
some developers are choosing to not use lazy loading, thus increasing the
overall bandwidth usage for their sites. This problem was discussed in
github issue 431 (https://github.com/w3c/IntersectionObserver/issues/431).
Using scrollMargin for the lazy load intersection observer will allow lazy
loading images in scrollers to load when they are near the viewport as
expected.


Initial public proposalNone

Search tagslazyload ,
scrollmargin 

TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Overall low as scroll margin also applies to the root element thus not
affecting lazy loading images that are currently loading with just a root
margin.


*Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)
https://bugzilla.mozilla.org/show_bug.cgi?id=1864794

*WebKit*: Positive (
https://github.com/w3c/IntersectionObserver/issues/431#issuecomment-930602435
) https://bugs.webkit.org/show_bug.cgi?id=264864

*Web developers*: Positive (
https://bugs.chromium.org/p/chromium/issues/detail?id=1391989)

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

None


Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/html/semantics/embedded-content/the-img-element?label=master=experimental=image-loading-lazy-in-


Flag name on chrome://flagsLazyLoadScrollMargin

Finch feature nameNone

Non-finch justification

This feature is behind an enabled-by-default flag that can be disabled if
needed.


Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1391989

Estimated milestones
Shipping on desktop 121
DevTrial on desktop 121
Shipping on Android 121
DevTrial on Android 121
Shipping on WebView 121

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5106926245642240

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/CAFxahvtrmHkoOpTuD2eZYVOyFuAhP8ZFVoTuNBS8zYTVY%3DTaaQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Intersection Observer Scroll Margin

[Traian Captan]

Thank you all!


On Wed, Oct 11, 2023 at 9:07 AM Chris Harrelson 
wrote:

> LGTM3 that is :)
>
> On Wed, Oct 11, 2023 at 8:55 AM Alex Russell 
> wrote:
>
>> Given that the TAG didn't respond in two weeks, I'm going to LGTM1
>>
>> On Wednesday, October 4, 2023 at 10:50:14 PM UTC-7 Yoav Weiss wrote:
>>
>>> On Wed, Oct 4, 2023 at 10:27 PM Traian Captan 
>>> wrote:
>>>
>>>> Hi Yoav,
>>>>
>>>> I don't know of Gecko's and WebKit's concrete implementation plans for
>>>> Intersection Observer Scroll Margin.
>>>> However, based on their responses on the github issue they were
>>>> supportive.
>>>>
>>>
>>> Just wanted to note that we typically ask for official positions on the
>>> different vendors standard positions repo.
>>> But given the fact that this is a change Mozilla folks requested and
>>> Apple folks consistently supported on the issue, I think it's fine to not
>>> file those in this case.
>>>
>>>
>>>> Regards,
>>>> Traian
>>>>
>>>>
>>>> On Wed, Oct 4, 2023 at 3:46 AM Yoav Weiss 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tuesday, September 26, 2023 at 1:10:34 AM UTC+2 Traian Captan wrote:
>>>>>
>>>>> Contact emailstcap...@chromium.org
>>>>>
>>>>> ExplainerNone
>>>>>
>>>>> Specificationhttps://w3c.github.io/IntersectionObserver/#dom-
>>>>> intersectionobserver-scrollmargin
>>>>>
>>>>> Summary
>>>>>
>>>>> Intersection Observer scrollMargin allows developers to observe
>>>>> targets inside nested scroll containers that are currently clipped away by
>>>>> the scroll containers. This is achieved by expanding the container's
>>>>> clipping rect by the scrollMargin when calculating the intersection.
>>>>>
>>>>>
>>>>> Blink componentBlink
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>>>>>
>>>>> Search tagsIntersection Observer
>>>>> <https://chromestatus.com/features#tags:Intersection%20Observer>,
>>>>> scrollMargin <https://chromestatus.com/features#tags:scrollMargin>
>>>>>
>>>>> TAG reviewNone
>>>>>
>>>>> TAG review statusNot applicable
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>> None
>>>>>
>>>>>
>>>>> *Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/
>>>>> 431)
>>>>>
>>>>> *WebKit*: Positive (https://github.com/w3c/
>>>>> IntersectionObserver/issues/431)
>>>>>
>>>>>
>>>>> Do you know of Gecko and WebKit's implementation plans for this?
>>>>>
>>>>>
>>>>> *Web developers*: Positive (https://github.com/w3c/
>>>>> IntersectionObserver/issues/431)
>>>>>
>>>>> *Other signals*:
>>>>>
>>>>> Ergonomics
>>>>>
>>>>> N/A
>>>>>
>>>>>
>>>>> Activation
>>>>>
>>>>> N/A
>>>>>
>>>>>
>>>>> Security
>>>>>
>>>>> N/A
>>>>>
>>>>>
>>>>> WebView application risks
>>>>>
>>>>> Does this intent deprecate or change behavior of existing APIs, such
>>>>> that it has potentially high risk for Android WebView-based applications?
>>>>>
>>>>> None
>>>>>
>>>>>
>>>>> Debuggability
>>>>>
>>>>> N/A
>>>>>
>>>>>
>>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes
>>>>>
>>>>> Is this feature fully tested by web-platform-tests
>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>> ?Yes
>>>>>
>>>>> Flag name on chrome://flagsIntersectionObserverScrollMargin
>>>>>
>>>>> Finch f

[blink-dev] Re: Intent to Ship: Intersection Observer Scroll Margin

[Traian Captan]

Hi Yoav,

I don't know of Gecko's and WebKit's concrete implementation plans for
Intersection Observer Scroll Margin.
However, based on their responses on the github issue they were supportive.

Regards,
Traian


On Wed, Oct 4, 2023 at 3:46 AM Yoav Weiss  wrote:

>
>
> On Tuesday, September 26, 2023 at 1:10:34 AM UTC+2 Traian Captan wrote:
>
> Contact emailstcap...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://w3c.github.io/IntersectionObserver/#dom-
> intersectionobserver-scrollmargin
>
> Summary
>
> Intersection Observer scrollMargin allows developers to observe targets
> inside nested scroll containers that are currently clipped away by the
> scroll containers. This is achieved by expanding the container's clipping
> rect by the scrollMargin when calculating the intersection.
>
>
> Blink componentBlink
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>
> Search tagsIntersection Observer
> <https://chromestatus.com/features#tags:Intersection%20Observer>,
> scrollMargin <https://chromestatus.com/features#tags:scrollMargin>
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)
>
> *WebKit*: Positive (https://github.com/w3c/IntersectionObserver/issues/431
> )
>
>
> Do you know of Gecko and WebKit's implementation plans for this?
>
>
> *Web developers*: Positive (https://github.com/w3c/
> IntersectionObserver/issues/431)
>
> *Other signals*:
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> N/A
>
>
> Security
>
> N/A
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?Yes
>
> Flag name on chrome://flagsIntersectionObserverScrollMargin
>
> Finch feature nameNone
>
> Non-finch justification
>
> This feature is behind an enabled-by-default flag that can be disabled if
> needed.
>
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1469500
>
> Estimated milestonesShipping on desktop119DevTrial on desktop119Shipping
> on Android119DevTrial on Android119Shipping on WebView119
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
> feature/5091020593430528
>
> Links to previous Intent discussionsIntent to prototype: https://groups.
> google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsWGzF5au6c5%
> 2BfVrh1hOCq_Y0rY0VF_bsmO8VVysg3QTg%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status
> <https://chromestatus.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/CAFxahvuOnT-94DXwNTm%3DGu3qnjqK4yNMG2gamw%2BQTpRG%3D7tiaQ%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Intersection Observer Scroll Margin

[Traian Captan]

Hi Alex,

Just in case, I file a TAG review issue:
https://github.com/w3ctag/design-reviews/issues/905

Regards,
Traian


On Fri, Sep 29, 2023 at 2:22 PM Traian Captan  wrote:

> Hi Alex,
>
> The much larger intersection observer feature went through a TAG review in
> https://github.com/w3ctag/design-reviews/issues/197, and this is only a
> minor addition to that.
>
> Regards,
> Traian
>
>
> On Fri, Sep 29, 2023 at 12:43 PM Alex Russell 
> wrote:
>
>> This looks relatively non-controversial, but why wasn't a TAG review
>> requested?
>>
>>

-- 
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/CAFxahvujC4h6MHxdfFWZnXTa2_8bawUTk7%2B_XCUXC1d1aZFnJw%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Intersection Observer Scroll Margin

[Traian Captan]

Hi Alex,

The much larger intersection observer feature went through a TAG review in
https://github.com/w3ctag/design-reviews/issues/197, and this is only a
minor addition to that.

Regards,
Traian


On Fri, Sep 29, 2023 at 12:43 PM Alex Russell 
wrote:

> This looks relatively non-controversial, but why wasn't a TAG review
> requested?
>
>

-- 
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/CAFxahvtDUDVDDp-Y243DF2GP7GTOp-rW_zykvpc7ZJ3B%2BW0WWg%40mail.gmail.com.

[blink-dev] Intent to Ship: Intersection Observer Scroll Margin

[Traian Captan]

Contact emailstcap...@chromium.org

ExplainerNone

Specification
https://w3c.github.io/IntersectionObserver/#dom-intersectionobserver-scrollmargin

Summary

Intersection Observer scrollMargin allows developers to observe targets
inside nested scroll containers that are currently clipped away by the
scroll containers. This is achieved by expanding the container's clipping
rect by the scrollMargin when calculating the intersection.


Blink componentBlink


Search tagsIntersection Observer
,
scrollMargin 

TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None


*Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)

*WebKit*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)

*Web developers*: Positive (
https://github.com/w3c/IntersectionObserver/issues/431)

*Other signals*:

Ergonomics

N/A


Activation

N/A


Security

N/A


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

N/A


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flagsIntersectionObserverScrollMargin

Finch feature nameNone

Non-finch justification

This feature is behind an enabled-by-default flag that can be disabled if
needed.


Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1469500

Estimated milestones
Shipping on desktop 119
DevTrial on desktop 119
Shipping on Android 119
DevTrial on Android 119
Shipping on WebView 119

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5091020593430528

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsWGzF5au6c5%2BfVrh1hOCq_Y0rY0VF_bsmO8VVysg3QTg%40mail.gmail.com

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/CAFxahvvtjzdbMtPZ7e6Qc3%2BX%2B%3DedCQXLJp5AxZhXtGJHPznfXA%40mail.gmail.com.

[blink-dev] Intent to Prototype: Intersection Observer Scroll Margin

[Traian Captan]

Contact emailstcap...@chromium.org

ExplainerNone

Specification
https://w3c.github.io/IntersectionObserver/#dom-intersectionobserver-scrollmargin

Summary

Intersection Observer scrollMargin allows developers to observe targets
inside nested scroll containers that are currently clipped away by the
scroll containers. This is achieved by expanding the container's clipping
rect by the scrollMargin when calculating the intersection.


Blink componentBlink


Motivation

None


Initial public proposalNone

Search tagsIntersection Observer
,
scrollMargin 

TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None


*Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)

*WebKit*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)

*Web developers*: Positive (
https://github.com/w3c/IntersectionObserver/issues/431)

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

None


Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flagsIntersectionObserverScrollMargin

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1469500

Estimated milestones
DevTrial on desktop 119
DevTrial on Android 119

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5091020593430528

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/CAFxahvsWGzF5au6c5%2BfVrh1hOCq_Y0rY0VF_bsmO8VVysg3QTg%40mail.gmail.com.

[blink-dev] Intent to Prototype: Auto Sizes for Lazy Loaded Images with Srcset

[Traian Captan]

Contact emailstcap...@chromium.org

Explainerhttps://github.com/whatwg/html/issues/4654

Specificationhttps://github.com/whatwg/html/pull/8008

Summary

Auto Sizes allows developers to omit the sizes attribute (or set it to
sizes=auto) for lazy loaded image elements with srcset. For this use case
the image's width should be provided. The browser will use the layout width
of the image in order to select the source url from the srcset.


Blink componentBlink>Image


Motivation

The layout size information in sizes is redundant with layout information
in CSS, but for images that are critical to initial paint it's necessary to
have the information in the HTML. For lazy-loaded images, CSS will usually
be available before the image load begins. The browser could take the
actual width of the image as specified in CSS, and use that as if it was
the image's sizes.


Initial public proposalhttps://github.com/whatwg/html/issues/4654

Search tagssizes , sizes=auto
, autosizes
, srcset


TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None since all major browsers (Chrome, Safari and Firefox) indicate that
they would be willing to implement it.


*Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/650
)

*WebKit*: Positive (https://github.com/WebKit/standards-positions/issues/9)

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?



Debuggability



Is this feature fully tested by web-platform-tests

?Yes

Flag nameImgAutoSizes

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1359051

Estimated milestones
DevTrial on desktop 116
DevTrial on Android 116

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5191555708616704

Links to previous Intent discussions

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/CAFxahvsRYQ5-a3vA8jsVTXz%2B5A8_pNcL6GziV3hy5qGqF-FTXg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Thanks Daniel!


On Wed, Mar 8, 2023 at 2:39 PM Daniel Bratell  wrote:

> LGTM3 to ship image-set
>
> /Daniel
>
> On 2023-03-08 15:51, Manuel Rego Casasnovas wrote:
> > LGTM2
> >
> > Thank you very much for fixing the issues before shipping.
> >
> > On 08/03/2023 10:53, Yoav Weiss wrote:
> >> Even though wpt.fyi
> >> <
> https://wpt.fyi/results/css/css-images/image-set/image-set-computed.sub.html?label=experimental=master>
> is reddish, I'm seeing all the tests pass on ToT. Thank you!!
> > I guess that's because wpt.fyi is still using Chrome 112, when the last
> > patches have landed in 113.
> >
> > Cheers,
> >Rego
> >
>

-- 
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/CAFxahvuJiEEfiQrFCZbVjeT66UHC3JMpSYN%2BxVGmkGPAUQ6CLw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Thanks Rego!


On Wed, Mar 8, 2023 at 6:51 AM Manuel Rego Casasnovas 
wrote:

> LGTM2
>
> Thank you very much for fixing the issues before shipping.
>
> On 08/03/2023 10:53, Yoav Weiss wrote:
> > Even though wpt.fyi
> > <
> https://wpt.fyi/results/css/css-images/image-set/image-set-computed.sub.html?label=experimental=master>
> is reddish, I'm seeing all the tests pass on ToT. Thank you!!
>
> I guess that's because wpt.fyi is still using Chrome 112, when the last
> patches have landed in 113.
>
> Cheers,
>   Rego
>

-- 
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/CAFxahvsjgr0ApOJV7VSP8GjRbYC-3H%3DVPdc8oUQrpWV0ktOQhw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Thanks Yoav!


On Wed, Mar 8, 2023 at 1:53 AM Yoav Weiss  wrote:

> My LGTM1 still stands! :)
>
> On Wed, Mar 8, 2023 at 8:40 AM Traian Captan  wrote:
>
>> Hi,
>>
>> Following the previous conversation, we worked on adding support for the
>> missing functionality that is currently described in the image-set spec
>> <https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation>.
>>
>> Here is the updated intent:
>>
>> Contact emailstcap...@chromium.org
>>
>> ExplainerNone
>>
>> Specification
>> https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation
>>
>> Summary
>>
>> Unprefix -webkit-image-set to expose the current image-set functionality
>> without needing the '-webkit-' prefix, and add support for the
>> functionality currently described in the image-set spec.
>>
>>
>> Blink componentBlink
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>>
>> Search tagsimage-set <https://chromestatus.com/features#tags:image-set>
>>
>> TAG reviewSkipping because this is a straightforward interop fix.
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> The Interoperability Risk is Low. This change increases interop with
>> Gecko and WebKit which already support both '-webkit-' prefixed and
>> unprefixed image-set, and are also actively working on improving their
>> image-set implementations as part of Interop 2023 efforts. The
>> Compatibility Risk is Low.
>>
>>
>> *Gecko*: Shipped/Shipping (
>> https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2)
>>
>> *WebKit*: Shipped/Shipping (
>> https://trac.webkit.org/changeset/202765/webkit)
>>
>> *Web developers*: Strongly positive This issue has been Starred by 55
>> users.
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> No
>>
>>
>> Debuggability
>>
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes
>>
>
> Even though wpt.fyi
> <https://wpt.fyi/results/css/css-images/image-set/image-set-computed.sub.html?label=experimental=master>
> is reddish, I'm seeing all the tests pass on ToT. Thank you!!
>
>
>>
>> Flag nameCSSImageSet
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/630597
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5109745420075008
>>
>> Links to previous Intent discussionsIntent to Ship:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/JXcRP4MJc9I
>>
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.com/>.
>>
>> Regards,
>> Traian
>>
>>
>> On Mon, Jan 23, 2023 at 2:57 PM Traian Captan 
>> wrote:
>>
>>> Thanks Noam!
>>>
>>> I'll add support for the other cases behind the feature flag and we'll
>>> ship it when we are "interoperable enough".
>>>
>>> Regards,
>>> Traian
>>>
>>>
>>> On Wed, Dec 14, 2022 at 6:41 AM Noam Rosenthal 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Dec 14, 2022 at 2:28 PM Manuel Rego Casasnovas 
>>>> wrote:
>>>>
>>>>> If we have plans to fix issues on this feature later, why not fixing
>>>>> them before and then shipping when things look good?
>>>>>
>>>>> If we unprefix it, it'll kind of appear as a new Chromium feature that
>>>>> 

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Hi,

Following the previous conversation, we worked on adding support for the
missing functionality that is currently described in the image-set spec
<https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation>.

Here is the updated intent:

Contact emailstcap...@chromium.org

ExplainerNone

Specification
https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation

Summary

Unprefix -webkit-image-set to expose the current image-set functionality
without needing the '-webkit-' prefix, and add support for the
functionality currently described in the image-set spec.


Blink componentBlink
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>

Search tagsimage-set <https://chromestatus.com/features#tags:image-set>

TAG reviewSkipping because this is a straightforward interop fix.

TAG review statusNot applicable

Risks


Interoperability and Compatibility

The Interoperability Risk is Low. This change increases interop with Gecko
and WebKit which already support both '-webkit-' prefixed and unprefixed
image-set, and are also actively working on improving their image-set
implementations as part of Interop 2023 efforts. The Compatibility Risk is
Low.


*Gecko*: Shipped/Shipping (
https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2)

*WebKit*: Shipped/Shipping (https://trac.webkit.org/changeset/202765/webkit)

*Web developers*: Strongly positive This issue has been Starred by 55 users.

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

No


Debuggability



Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
?Yes

Flag nameCSSImageSet

Requires code in //chrome?False

Tracking bughttps://crbug.com/630597

Estimated milestones

No milestones specified


Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5109745420075008

Links to previous Intent discussionsIntent to Ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/JXcRP4MJc9I


This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.

Regards,
Traian


On Mon, Jan 23, 2023 at 2:57 PM Traian Captan  wrote:

> Thanks Noam!
>
> I'll add support for the other cases behind the feature flag and we'll
> ship it when we are "interoperable enough".
>
> Regards,
> Traian
>
>
> On Wed, Dec 14, 2022 at 6:41 AM Noam Rosenthal 
> wrote:
>
>>
>>
>> On Wed, Dec 14, 2022 at 2:28 PM Manuel Rego Casasnovas 
>> wrote:
>>
>>> If we have plans to fix issues on this feature later, why not fixing
>>> them before and then shipping when things look good?
>>>
>>> If we unprefix it, it'll kind of appear as a new Chromium feature that
>>> people can use, and they will expect it follows the spec.
>>
>>
>> I agree, for example people might (wrongfully) rely on
>> CSS.supports("background-image", "image-set(url(example.jpg) 1x)")
>> to mean that the full set of image-set features is supported.
>> I'm not sure people are more granular than that about feature detection
>> but we probably have data about that.
>>
>> It might be wise to support the cases behind the prefix, and
>> unprefix when the behavior is close to complete and interoperable enough.
>> We don't need to rely on people posting bug reports when we know the
>> issues today by looking at the WPT failures.
>>
>

-- 
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/CAFxahvtLP5TNkEoTgnibGoAmd0stjqqOzsKAiYmPd9wE6_Cyng%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Thanks Noam!

I'll add support for the other cases behind the feature flag and we'll ship
it when we are "interoperable enough".

Regards,
Traian


On Wed, Dec 14, 2022 at 6:41 AM Noam Rosenthal 
wrote:

>
>
> On Wed, Dec 14, 2022 at 2:28 PM Manuel Rego Casasnovas 
> wrote:
>
>> If we have plans to fix issues on this feature later, why not fixing
>> them before and then shipping when things look good?
>>
>> If we unprefix it, it'll kind of appear as a new Chromium feature that
>> people can use, and they will expect it follows the spec.
>
>
> I agree, for example people might (wrongfully) rely on
> CSS.supports("background-image", "image-set(url(example.jpg) 1x)")
> to mean that the full set of image-set features is supported.
> I'm not sure people are more granular than that about feature detection
> but we probably have data about that.
>
> It might be wise to support the cases behind the prefix, and unprefix when
> the behavior is close to complete and interoperable enough.
> We don't need to rely on people posting bug reports when we know the
> issues today by looking at the WPT failures.
>

-- 
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/CAFxahvt_2YFwe1rKbC3K-teScR9J8_VvHGEJd2rC_D1wM7p0nA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Hi Rego,

If we have plans to fix issues on this feature later, why not fixing
> them before and then shipping when things look good?

Sounds good. I'll fix the issues first, and then I will update the Intent.

Checking the tests results in wpt.fyi:
>
> https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master=chrome%5Bexperimental%5D=chrome%5Bstable%5D=firefox%5Bexperimental%5D=safari%5Bexperimental%5D=subtest
>
> I'm confused about the first examples there:
> * e.style['background-image'] = "image-set(url(example.png) 1x)"
>   is passing
> But:
> * e.style['background-image'] = "-webkit-image-set(url(example.png) 1x)"
> should set the property value
>   is not passing
>
That is a strange one that I was also confused by initially as well. It is
because the '-webkit-' prefixed 'image-set' is expected to serialize to the
same value as standard 'image-set':
"Implementations must accept -webkit-image-set() as a parse-time alias
of image-set(). (It’s a valid value, with identical arguments to
image-set(), and is turned into image-set() during parsing.)"
https://drafts.csswg.org/css-images-4/#deprecated.
Chrome is returning "*-webkit-*image-set(url(\"example.png\") 1x)" while
the expected is "image-set(url(\"example.png\") 1x)"
I fixed this in:
https://chromium-review.googlesource.com/c/chromium/src/+/4167006

Regards,
Traian

-- 
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/CAFxahvvcw%3D9vPauKowJsfpcCB1J9oG_ier-1HvHjPk0iUo1mQg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Thanks Stefan!

That makes sense.
We do plan to address some of the other issues.
Having bugs filed would be helpful in prioritizing what we should focus on
next.

Regards,
Traian


On Wed, Dec 7, 2022 at 2:12 PM Stefan Zager  wrote:

>
>
> On Wed, Dec 7, 2022 at 5:39 AM Manuel Rego Casasnovas 
> wrote:
>
>>
>> On 07/12/2022 12:37, Yoav Weiss wrote:
>> > LGTM1
>> >
>> > Thanks for working on this!! Looking at wpt.fyi, other implementations
>> > are passing the test suite for this to varying degrees. Does this intent
>> > cover full compliance with the test suite? (e.g. `type()`, `url()`, non
>> > `x` descriptors, and maybe other dimensions) Or does it only cover the
>> > unprefixing and further interop improvements will come later?
>>
>> I do wonder what's the goal of removing the prefix, if we're not also
>> improving the spec compliance and interoperability?
>>
>> If we ship "image-set" people would expect it's a complete feature, and
>> then they'll get confused when somethings don't work. How are we going
>> to explain which is shipping exactly, is there any kind of documentation
>> about that?
>>
>
> IMO, un-prefixing is an un-alloyed good thing, regardless of how spec
> compliant chromium's implementation is. If it is in fact as buggy as you
> suggest, then let the bugs flow!
>
>
>
>>
>> Cheers,
>>   Rego
>>
>> >
>> > On Tuesday, December 6, 2022 at 3:23:32 AM UTC+1 Traian Captan wrote:
>> >
>> >
>> > Contact emails
>> >
>> > tcap...@chromium.org <mailto:tcap...@chromium.org>
>> >
>> >
>> > Explainer
>> >
>> > None
>> >
>> >
>> > Specification
>> >
>> > https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation
>> > <
>> https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation>
>> >
>> >
>> > Summary
>> >
>> > Unprefix -webkit-image-set to expose the current image-set
>> > functionality without needing the '-webkit-' prefix.
>> >
>> >
>> >
>> > Blink component
>> >
>> > Blink
>> > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink
>> >
>> >
>> >
>> >
>> > Motivation
>> >
>> > Currently Blink only supports '-webkit-' prefixed image-set, while
>> > Gecko and WebKit support both prefixed and unprefixed versions. With
>> > this change interop with Gecko and WebKit will be increased by
>> > allowing web developers to use the current Blink image-set
>> > functionality both with and without the '-webkit-' prefix.
>> >
>> >
>> > Search tags
>> >
>> > image-set <https://chromestatus.com/features#tags:image-set>
>> >
>> >
>> > TAG review
>> >
>> > Skipping because this is a straightforward interop fix.
>> >
>> >
>> > TAG review status
>> >
>> > Not applicable
>> >
>> >
>> > Risks
>> >
>> >
>> >
>> > Interoperability and Compatibility
>> >
>> > The Interoperability Risk is Low. This change increases interop with
>> > Gecko and WebKit which already support both '-webkit-' prefixed and
>> > unprefixed image-set. The Compatibility Risk is Low. If both
>> > prefixed and standard versions are defined in the right order, and
>> > the standard version fails parsing, Blink will fallback to the
>> > prefixed version. The 'image-set-fallback' test has been added to
>> > verify this behavior.
>> >
>> >
>> >
>> > /Gecko/: Shipped/Shipping
>> > (https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2
>> > <https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2>)
>> >
>> > /WebKit/: Shipped/Shipping
>> > (https://trac.webkit.org/changeset/202765/webkit
>> > <https://trac.webkit.org/changeset/202765/webkit>)
>> >
>> > /Web developers/: Strongly positive - This issue has been Starred by
>> > 55 users.
>> >
>> > /Other signals/:
>> >
>> >
>> > WebView application risks
>> >
&g

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Hi Rego,


> I do wonder what's the goal of removing the prefix, if we're not also
> improving the spec compliance and interoperability?
>
It's an incremental step in the direction of spec compliance and
interoperability.
Further improvements will follow.
This is similar to how Firefox handled the implementation, splitting it
over several patches and releases (
https://bugzilla.mozilla.org/show_bug.cgi?id=1107646).

If we ship "image-set" people would expect it's a complete feature, and
> then they'll get confused when somethings don't work. How are we going
> to explain which is shipping exactly, is there any kind of documentation
> about that?

I would expect that if they find something that doesn't work, they would
open bug / feature requests, which we can use to prioritize what we should
look at implementing next.

Regards,
Traian

-- 
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/CAFxahvsO-axM0xi_E1bKQHk0_KgorSsJCQKmdA4EM_axOgm5hg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Thanks Yoav!

This intent only covers the unprefixing.
Further interop improvements will come later.

Regards,
Traian



On Wed, Dec 7, 2022 at 3:37 AM Yoav Weiss  wrote:

> LGTM1
>
> Thanks for working on this!! Looking at wpt.fyi, other implementations are
> passing the test suite for this to varying degrees. Does this intent cover
> full compliance with the test suite? (e.g. `type()`, `url()`, non `x`
> descriptors, and maybe other dimensions) Or does it only cover the
> unprefixing and further interop improvements will come later?
>
> On Tuesday, December 6, 2022 at 3:23:32 AM UTC+1 Traian Captan wrote:
>
>> Contact emailstcap...@chromium.org
>>
>> ExplainerNone
>>
>> Specification
>> https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation
>>
>> Summary
>>
>> Unprefix -webkit-image-set to expose the current image-set functionality
>> without needing the '-webkit-' prefix.
>>
>>
>> Blink componentBlink
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>> Motivation
>>
>> Currently Blink only supports '-webkit-' prefixed image-set, while Gecko
>> and WebKit support both prefixed and unprefixed versions. With this change
>> interop with Gecko and WebKit will be increased by allowing web developers
>> to use the current Blink image-set functionality both with and without the
>> '-webkit-' prefix.
>>
>> Search tagsimage-set <https://chromestatus.com/features#tags:image-set>
>>
>> TAG reviewSkipping because this is a straightforward interop fix.
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> The Interoperability Risk is Low. This change increases interop with
>> Gecko and WebKit which already support both '-webkit-' prefixed and
>> unprefixed image-set. The Compatibility Risk is Low. If both prefixed and
>> standard versions are defined in the right order, and the standard version
>> fails parsing, Blink will fallback to the prefixed version. The
>> 'image-set-fallback' test has been added to verify this behavior.
>>
>>
>> *Gecko*: Shipped/Shipping (
>> https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2)
>>
>> *WebKit*: Shipped/Shipping (
>> https://trac.webkit.org/changeset/202765/webkit)
>>
>> *Web developers*: Strongly positive - This issue has been Starred by 55
>> users.
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> No
>>
>>
>> Debuggability
>>
>> N/A
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes
>> https://wpt.fyi/results/css/css-images/image-set
>>
>> Flag nameCSSImageSet
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/630597
>>
>> Estimated milestones
>>
>> 110 Or 111
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5109745420075008
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.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/CAFxahvth292nfHhu8RhC9u5LhfQa3FBNZ-YtWxAjkymKHox7iQ%40mail.gmail.com.

[blink-dev] Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Contact emailstcap...@chromium.org

ExplainerNone

Specification
https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation

Summary

Unprefix -webkit-image-set to expose the current image-set functionality
without needing the '-webkit-' prefix.


Blink componentBlink

Motivation

Currently Blink only supports '-webkit-' prefixed image-set, while Gecko
and WebKit support both prefixed and unprefixed versions. With this change
interop with Gecko and WebKit will be increased by allowing web developers
to use the current Blink image-set functionality both with and without the
'-webkit-' prefix.

Search tagsimage-set 

TAG reviewSkipping because this is a straightforward interop fix.

TAG review statusNot applicable

Risks


Interoperability and Compatibility

The Interoperability Risk is Low. This change increases interop with Gecko
and WebKit which already support both '-webkit-' prefixed and unprefixed
image-set. The Compatibility Risk is Low. If both prefixed and standard
versions are defined in the right order, and the standard version fails
parsing, Blink will fallback to the prefixed version. The
'image-set-fallback' test has been added to verify this behavior.


*Gecko*: Shipped/Shipping (
https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2)

*WebKit*: Shipped/Shipping (https://trac.webkit.org/changeset/202765/webkit)

*Web developers*: Strongly positive - This issue has been Starred by 55
users.

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

No


Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Yes
https://wpt.fyi/results/css/css-images/image-set

Flag nameCSSImageSet

Requires code in //chrome?False

Tracking bughttps://crbug.com/630597

Estimated milestones

110 Or 111


Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5109745420075008

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/CAFxahvvZZpc5osC5XD_Zu6Lsz5%3Decp7%3DjM0ePgou8UQ-DRPTpQ%40mail.gmail.com.

Re: [blink-dev] Intent to Implement and Ship: Unprefixed -webkit-image-set

[Traian Captan]

Hi Rego,

Thank you for your message!

> This issue has been bugging devs since 2016.
> >
> > I'm landing a patch
> > <https://chromium-review.googlesource.com/c/chromium/src/+/4063134> to
> > unprefix -webkit-image-set which will expose the current image-set
> > functionality without needing the '-webkit-' prefix.
> I don't think this is the right way to move this topic. 3 LGTMs from
> 2016 shouldn't be enough to land the change without a previous notice on
> this thread.

Sorry about that, it was meant more as an FYI on the old thread since there
was no follow up after the LGTMs and the issue is still open.
I will create a new Chrome status entry and send out a brand new email
about it.



> > To address the compat issue, if both prefixed and standard versions are
> > defined in the right order,
> > and the standard version fails parsing, Chrome will fallback to the
> > prefixed version.
> > The `image-set-fallback` test has been added to verify this behavior.
> > Unprefixing image-set fixes 2 of the failing subtests of the
> > image-set-parsing WPT test
> > <
> https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master=experimental=subtest=image-set-parsing
> >
> >
> > As a follow up, I will investigate whether we can fix the remaining
> > compat issues.
>
> How is the interop with WebKit and Firefox implementations?
> According to MDN Firefox added support for -webkit-image-set() in
> version 90, so it'd be nice that this change is in alignment too.
>
WebKit and Firefox support both prefixed and unprefixed versions.
I am not removing the prefixed version, only adding the possibility of
using the current functionality without needing the `-webkit-` prefix.



> What's the status of WPT tests? Why only 2 subtests are getting fixed
> with this change? Are there plans to fix the rest?
>
For the image-set-parsing test, Firefox is passing 46/50, Safari 37/50 and
Chrome 20/50 (22 with my patch).
For the overall WPT tests for image-set
<https://wpt.fyi/results/css/css-images/image-set?label=master=experimental=subtest=image-set>,
Firefox is passing 71/77, Safari 50/77 and Chrome 23/77 (25 with my patch).
We only pass 2 more tests because we are only exposing the current
implemented functionality not adding any new functionality with this patch.
I will follow up with additional fixes for some of the other issues.


> Do we have use counters for both the prefixed and uprefixed versions to
> see if we can get rid of them in the future?
>
Yes, we have counters for both, but I don't think we can get rid of the
prefixed version, as there were talks about adding the prefixed version to
the spec: https://github.com/w3c/csswg-drafts/issues/6285

I guess we should also update things at:
> https://chromestatus.com/feature/5432024223449088

I'll send a brand new one.


> And probably notify MDN so it can get updated if the prefix is no longer
> needed in any browser.
>
Good idea.

Regards,
Traian


On Wed, Nov 30, 2022 at 11:57 PM Manuel Rego Casasnovas 
wrote:

> Hi,
>
> On 01/12/2022 00:59, Traian Captan wrote:
> > This issue has been bugging devs since 2016.
> >
> > I'm landing a patch
> > <https://chromium-review.googlesource.com/c/chromium/src/+/4063134> to
> > unprefix -webkit-image-set which will expose the current image-set
> > functionality without needing the '-webkit-' prefix.
> I don't think this is the right way to move this topic. 3 LGTMs from
> 2016 shouldn't be enough to land the change without a previous notice on
> this thread.
>
> > To address the compat issue, if both prefixed and standard versions are
> > defined in the right order,
> > and the standard version fails parsing, Chrome will fallback to the
> > prefixed version.
> > The `image-set-fallback` test has been added to verify this behavior.
> > Unprefixing image-set fixes 2 of the failing subtests of the
> > image-set-parsing WPT test
> > <
> https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master=experimental=subtest=image-set-parsing
> >
> >
> > As a follow up, I will investigate whether we can fix the remaining
> > compat issues.
>
> How is the interop with WebKit and Firefox implementations?
> According to MDN Firefox added support for -webkit-image-set() in
> version 90, so it'd be nice that this change is in alignment too.
>
> What's the status of WPT tests? Why only 2 subtests are getting fixed
> with this change? Are there plans to fix the rest?
>
> Do we have use counters for both the prefixed and uprefixed versions to
> see if we can get rid of them in the future?
>
> I guess we should also update things at:
> https://chromesta

Re: [blink-dev] Intent to Implement and Ship: Unprefixed -webkit-image-set

[Traian Captan]

Thank you Yoav!

That's a good idea.
I created a CL to place it behind a flag:
https://chromium-review.googlesource.com/c/chromium/src/+/4075225

And I will send out a new intent.

Regards,
Traian


On Thu, Dec 1, 2022 at 8:02 PM Yoav Weiss  wrote:

> Hey Traian,
>
> I'm excited about you taking on this area! At the same time, I agree with
> Rego that we should not be landing patches for this without a new intent
> that looks at the current compat landscape.
> Can you put this behind a flag and send a new intent? Thanks! :)
>
> On Fri, Dec 2, 2022 at 3:48 AM Traian Captan  wrote:
>
>> Hi Noam,
>>
>> Thanks for the heads up!
>> This patch only exposes the current `-webkit-` prefixed functionality
>> without needing the prefix, and the parsing strictness is the same.
>>
>> When I look at adding the extra functionality you mentioned I will port
>> your test case and look out for this issue.
>> For now, image-set without the url keyword as well as generated images
>> will fail parsing, Chrome will fall back to the `-webkit-` prefixed version
>> if defined and behave as it did before the patch.
>>
>> Regards,
>> Traian
>>
>>
>> On Thu, Dec 1, 2022 at 2:11 AM Noam Rosenthal 
>> wrote:
>>
>>>
>>>
>>> On Thu, Dec 1, 2022 at 1:59 AM Traian Captan 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> This issue has been bugging devs since 2016.
>>>>
>>>> I'm landing a patch
>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/4063134> to
>>>> unprefix -webkit-image-set which will expose the current image-set
>>>> functionality without needing the '-webkit-' prefix.
>>>>
>>>> To address the compat issue, if both prefixed and standard versions are
>>>> defined in the right order,
>>>> and the standard version fails parsing, Chrome will fallback to the
>>>> prefixed version.
>>>> The `image-set-fallback` test has been added to verify this behavior.
>>>> Unprefixing image-set fixes 2 of the failing subtests of the 
>>>> image-set-parsing
>>>> WPT test
>>>> <https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master=experimental=subtest=image-set-parsing>
>>>>
>>>> Hi Traian
>>> I implemented the same in WebKit 3 years ago, alongside other image-set
>>> improvements. At the time there were some strange backwards-compatibility
>>> issues, e.g. with empty strings,
>>> where I had to keep some non-standard behavior in -webkit-image-set
>>> around parsing :
>>> https://trac.webkit.org/changeset/255420/webkit
>>>
>>> Would be good to double check that we don’t repeat the same regression ☺️
>>>
>>> The other thing WebKit has since then is support for urls without the
>>> url() keywords and also generated images in an image-set. I am curious if
>>> we have a plan to implement that or if unprefixing without them can cause
>>> issues.
>>>
>>>
>>>> As a follow up, I will investigate whether we can fix the remaining
>>>> compat issues.
>>>>
>>>> Regards,
>>>> Traian
>>>>
>>>> On Tuesday, August 30, 2016 at 8:51:03 AM UTC-7 dgla...@google.com
>>>> wrote:
>>>>
>>>>> LGTM3 + investigate the syntax issue mentioned by PhistucK.
>>>>>
>>>>> :DG<
>>>>>
>>>>>
>>>>> On Monday, August 29, 2016 at 5:06:06 PM UTC-7, Dru Knox wrote:
>>>>>
>>>>>> Is this blocked on API owner feedback?
>>>>>>
>>>>>> On Mon, Aug 15, 2016 at 1:47 AM PhistucK  wrote:
>>>>>>
>>>>> It has come to my attention in comment 5
>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=630597#c5> that
>>>>>>> the standard syntax is a superset of the Blink syntax.
>>>>>>> https://drafts.csswg.org/css-images-3/#image-set-notation
>>>>>>>
>>>>>>> Blink supports -
>>>>>>> background-image: image-set( url("foo.png") 1x,
>>>>>>>  url("foo-2x.png") 2x,
>>>>>>>  url("foo-print.png") 3x );
>>>>>>>
>>>>>>> The standard supports this -
>>>>>>> background-image: image-set( &qu

Re: [blink-dev] Intent to Implement and Ship: Unprefixed -webkit-image-set

[Traian Captan]

Hi Noam,

Thanks for the heads up!
This patch only exposes the current `-webkit-` prefixed functionality
without needing the prefix, and the parsing strictness is the same.

When I look at adding the extra functionality you mentioned I will port
your test case and look out for this issue.
For now, image-set without the url keyword as well as generated images will
fail parsing, Chrome will fall back to the `-webkit-` prefixed version if
defined and behave as it did before the patch.

Regards,
Traian


On Thu, Dec 1, 2022 at 2:11 AM Noam Rosenthal 
wrote:

>
>
> On Thu, Dec 1, 2022 at 1:59 AM Traian Captan  wrote:
>
>> Hi,
>>
>> This issue has been bugging devs since 2016.
>>
>> I'm landing a patch
>> <https://chromium-review.googlesource.com/c/chromium/src/+/4063134> to
>> unprefix -webkit-image-set which will expose the current image-set
>> functionality without needing the '-webkit-' prefix.
>>
>> To address the compat issue, if both prefixed and standard versions are
>> defined in the right order,
>> and the standard version fails parsing, Chrome will fallback to the
>> prefixed version.
>> The `image-set-fallback` test has been added to verify this behavior.
>> Unprefixing image-set fixes 2 of the failing subtests of the 
>> image-set-parsing
>> WPT test
>> <https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master=experimental=subtest=image-set-parsing>
>>
>> Hi Traian
> I implemented the same in WebKit 3 years ago, alongside other image-set
> improvements. At the time there were some strange backwards-compatibility
> issues, e.g. with empty strings,
> where I had to keep some non-standard behavior in -webkit-image-set around
> parsing :
> https://trac.webkit.org/changeset/255420/webkit
>
> Would be good to double check that we don’t repeat the same regression ☺️
>
> The other thing WebKit has since then is support for urls without the
> url() keywords and also generated images in an image-set. I am curious if
> we have a plan to implement that or if unprefixing without them can cause
> issues.
>
>
>> As a follow up, I will investigate whether we can fix the remaining
>> compat issues.
>>
>> Regards,
>> Traian
>>
>> On Tuesday, August 30, 2016 at 8:51:03 AM UTC-7 dgla...@google.com wrote:
>>
>>> LGTM3 + investigate the syntax issue mentioned by PhistucK.
>>>
>>> :DG<
>>>
>>>
>>> On Monday, August 29, 2016 at 5:06:06 PM UTC-7, Dru Knox wrote:
>>>
>>>> Is this blocked on API owner feedback?
>>>>
>>>> On Mon, Aug 15, 2016 at 1:47 AM PhistucK  wrote:
>>>>
>>> It has come to my attention in comment 5
>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=630597#c5> that
>>>>> the standard syntax is a superset of the Blink syntax.
>>>>> https://drafts.csswg.org/css-images-3/#image-set-notation
>>>>>
>>>>> Blink supports -
>>>>> background-image: image-set( url("foo.png") 1x,
>>>>>  url("foo-2x.png") 2x,
>>>>>  url("foo-print.png") 3x );
>>>>>
>>>>> The standard supports this -
>>>>> background-image: image-set( "foo.png" 1x,
>>>>>  url("foo-2x.png") 2x,
>>>>>  "foo-print.png" 600dpi );
>>>>> Basically, you do not need url("..."), you can enter it as a string
>>>>> without the url() function. Also, the resolution part supports more
>>>>> than just #x.
>>>>>
>>>>> I do not have Safari, but according to the unprefixing layout test, it
>>>>> looks like it does not support the standard syntax as well.
>>>>>
>>>>> Should the standard syntax be dropped? Can you talk to WebKit and see
>>>>> if they intend to implement the standard syntax?
>>>>>
>>>>>
>>>>> ☆*PhistucK*
>>>>>
>>>> On Fri, Aug 12, 2016 at 11:47 PM, Chris Harrelson >>>> > wrote:
>>>>>
>>>> LGTM2
>>>>>>
>>>>>> On Fri, Aug 12, 2016 at 1:11 PM, Philip Jägenstedt <
>>>>>> foo...@chromium.org> wrote:
>>>>>>
>>>>> Easy LGTM1. Given that authors generally assume that prefixed things
>>>>>>> are aliases and that WebKit has made i

Re: [blink-dev] Intent to Implement and Ship: Unprefixed -webkit-image-set

[Traian Captan]

Hi,

I tested it out and Chrome does not currently support nesting.
Same for Safari, however Firefox does seem to support nesting.

Regards,
Traian


On Wed, Nov 30, 2022 at 9:06 PM 一丝  wrote:

> Does the current implementation of Chrome support nesting? I think nesting
> should be disabled. See: https://github.com/w3c/csswg-drafts/issues/7662
>
> 以上
> 一丝
>
>
> Traian Captan  于2022年12月1日周四 07:59写道：
>
>> Hi,
>>
>> This issue has been bugging devs since 2016.
>>
>> I'm landing a patch
>> <https://chromium-review.googlesource.com/c/chromium/src/+/4063134> to
>> unprefix -webkit-image-set which will expose the current image-set
>> functionality without needing the '-webkit-' prefix.
>>
>> To address the compat issue, if both prefixed and standard versions are
>> defined in the right order,
>> and the standard version fails parsing, Chrome will fallback to the
>> prefixed version.
>> The `image-set-fallback` test has been added to verify this behavior.
>> Unprefixing image-set fixes 2 of the failing subtests of the 
>> image-set-parsing
>> WPT test
>> <https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master=experimental=subtest=image-set-parsing>
>>
>> As a follow up, I will investigate whether we can fix the remaining
>> compat issues.
>>
>> Regards,
>> Traian
>>
>> On Tuesday, August 30, 2016 at 8:51:03 AM UTC-7 dgla...@google.com wrote:
>>
>>> LGTM3 + investigate the syntax issue mentioned by PhistucK.
>>>
>>> :DG<
>>>
>>>
>>> On Monday, August 29, 2016 at 5:06:06 PM UTC-7, Dru Knox wrote:
>>>
>>>> Is this blocked on API owner feedback?
>>>>
>>>> On Mon, Aug 15, 2016 at 1:47 AM PhistucK  wrote:
>>>>
>>> It has come to my attention in comment 5
>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=630597#c5> that
>>>>> the standard syntax is a superset of the Blink syntax.
>>>>> https://drafts.csswg.org/css-images-3/#image-set-notation
>>>>>
>>>>> Blink supports -
>>>>> background-image: image-set( url("foo.png") 1x,
>>>>>  url("foo-2x.png") 2x,
>>>>>  url("foo-print.png") 3x );
>>>>>
>>>>> The standard supports this -
>>>>> background-image: image-set( "foo.png" 1x,
>>>>>  url("foo-2x.png") 2x,
>>>>>  "foo-print.png" 600dpi );
>>>>> Basically, you do not need url("..."), you can enter it as a string
>>>>> without the url() function. Also, the resolution part supports more
>>>>> than just #x.
>>>>>
>>>>> I do not have Safari, but according to the unprefixing layout test, it
>>>>> looks like it does not support the standard syntax as well.
>>>>>
>>>>> Should the standard syntax be dropped? Can you talk to WebKit and see
>>>>> if they intend to implement the standard syntax?
>>>>>
>>>>>
>>>>> ☆*PhistucK*
>>>>>
>>>> On Fri, Aug 12, 2016 at 11:47 PM, Chris Harrelson >>>> > wrote:
>>>>>
>>>> LGTM2
>>>>>>
>>>>>> On Fri, Aug 12, 2016 at 1:11 PM, Philip Jägenstedt <
>>>>>> foo...@chromium.org> wrote:
>>>>>>
>>>>> Easy LGTM1. Given that authors generally assume that prefixed things
>>>>>>> are aliases and that WebKit has made it just so, whatever problems there
>>>>>>> might be with image-set, the only way to move forward is to consider
>>>>>>> -webkit-image-set as part of the compat constraint and navigate 
>>>>>>> accordingly.
>>>>>>>
>>>>>>> When it comes to tests, I guess this (like almost all) feature
>>>>>>> doesn't have a shared test suite that we actually use? Nothing in
>>>>>>> https://github.com/w3c/csswg-test/tree/master/css-images-3 and I
>>>>>>> don't know where else it would be?
>>>>>>>
>>>>>>> I suspect that contributing to csswg-tests is, like
>>>>>>> web-platform-tests, not streamlined enough to require it for shipping 
>>>>>>> new
>>>>>>> things

Re: [blink-dev] Intent to Implement and Ship: Unprefixed -webkit-image-set

[Traian Captan]

Hi,

This issue has been bugging devs since 2016.

I'm landing a patch 
 to 
unprefix -webkit-image-set which will expose the current image-set 
functionality without needing the '-webkit-' prefix.

To address the compat issue, if both prefixed and standard versions are 
defined in the right order,
and the standard version fails parsing, Chrome will fallback to the 
prefixed version.
The `image-set-fallback` test has been added to verify this behavior.
Unprefixing image-set fixes 2 of the failing subtests of the image-set-parsing 
WPT test  


As a follow up, I will investigate whether we can fix the remaining compat 
issues.

Regards,
Traian

On Tuesday, August 30, 2016 at 8:51:03 AM UTC-7 dgla...@google.com wrote:

> LGTM3 + investigate the syntax issue mentioned by PhistucK.
>
> :DG<
>
>
> On Monday, August 29, 2016 at 5:06:06 PM UTC-7, Dru Knox wrote:
>
>> Is this blocked on API owner feedback?
>>
>> On Mon, Aug 15, 2016 at 1:47 AM PhistucK  wrote:
>>
> It has come to my attention in comment 5 
>>>  that 
>>> the standard syntax is a superset of the Blink syntax.
>>> https://drafts.csswg.org/css-images-3/#image-set-notation
>>>
>>> Blink supports -
>>> background-image: image-set( url("foo.png") 1x,
>>>  url("foo-2x.png") 2x,
>>>  url("foo-print.png") 3x );
>>>
>>> The standard supports this -
>>> background-image: image-set( "foo.png" 1x,
>>>  url("foo-2x.png") 2x,
>>>  "foo-print.png" 600dpi );
>>> Basically, you do not need url("..."), you can enter it as a string 
>>> without the url() function. Also, the resolution part supports more 
>>> than just #x.
>>>
>>> I do not have Safari, but according to the unprefixing layout test, it 
>>> looks like it does not support the standard syntax as well.
>>>
>>> Should the standard syntax be dropped? Can you talk to WebKit and see if 
>>> they intend to implement the standard syntax?
>>>
>>>
>>> ☆*PhistucK*
>>>
>> On Fri, Aug 12, 2016 at 11:47 PM, Chris Harrelson  
>>> wrote:
>>>
>> LGTM2

 On Fri, Aug 12, 2016 at 1:11 PM, Philip Jägenstedt >>> > wrote:

>>> Easy LGTM1. Given that authors generally assume that prefixed things 
> are aliases and that WebKit has made it just so, whatever problems there 
> might be with image-set, the only way to move forward is to consider 
> -webkit-image-set as part of the compat constraint and navigate 
> accordingly.
>
> When it comes to tests, I guess this (like almost all) feature doesn't 
> have a shared test suite that we actually use? Nothing in 
> https://github.com/w3c/csswg-test/tree/master/css-images-3 and I 
> don't know where else it would be?
>
> I suspect that contributing to csswg-tests is, like 
> web-platform-tests, not streamlined enough to require it for shipping new 
> things, but it would be great if you wanted to take a look at how 
> feasible 
> it is in this case. Even just a few reftests testing the very basics 
> would 
> be valuable.
>
> Finally, I wouldn't assume that compat risk is low. When things (like 
> the Fullscreen API...) are prefixed only for a very long time, it's 
> actually possible that merely unprefixing can break things. Let's hope 
> this 
> one works out.
>
 On Fri, Aug 12, 2016 at 5:59 PM John Mellor  
> wrote:
>
 The CSS image-set spec is old, and has a major todo 
>> : it only 
>> supports variations in screen density (1x, 2x, etc), but doesn't yet 
>> allow 
>> for selecting images based on viewport width 
>> 
>>  like 
>> the more modern  srcset+sizes attributes 
>> .
>>  
>> Media queries aren't sufficient for this (though they nicely handle the 
>> art 
>> direction 
>> 
>>  use 
>> case, so CSS won't additionally need an equivalent to the  
>> and  elements 
>> 
>> ).
>>
>> That said, unprefixed image-set is perhaps already a defacto standard 
>> (due to websites preemptively unprefixing it, and soon Safari shipping 
>> it), 
>> so it's likely that when selecting images based on viewport width 
>> eventually gets added to CSS images, that will be done by extending the 
>> image-set syntax 

[blink-dev] Intent to Prototype and Ship: Snap border, outline and column-rule widths before layout

[Traian Captan]

Contact emails

tcap...@chromium.org

Explainer

Though not a formal explainer, Emilio has an excellent writeup of this
issue at https://crisal.io/words/2020/06/13/rounding-borders.html.

Spec

With this change to blink, all implementations will agree, and this can be
specified (see: https://github.com/w3c/csswg-drafts/issues/5210).

Summary

Snap border, outline and column-rule widths before layout to avoid gaps
between backgrounds and borders caused by paint-time snapping. With this
change, Blink will match Gecko and WebKit.

Blink component

Blink 

Motivation

Currently Blink snaps the border widths at paint time. This can cause a
visible 1px gap between a parent element's border and a child's background
when the border is rounded down during paint since the snapping floors the
value but the layout rounded it up to calculate the child’s s position (eg
border-width is set to 10.75 pixels, rounded to 10px at paint time, but 11
at layout time). By making this change Blink will also behave like Gecko
and WebKit and increase interoperability.

Search tags

border-width ,
outline-width ,
column-rule-width 

TAG review

Skipping because this is a straightforward interop fix.

TAG review status

N/A

RisksInteroperability and Compatibility

Gecko and WebKit already snap borders before layout.

This change would make Blink behave the same and increase interoperability
and compatibility.

The explainer section has a link to a blog post describing the differences
in more detail.

This issue and the proposed fix have been discussed in: Issue 1201762:
[Task] Investigate border snapping before layout ,
which is currently blocking 10 issues.



This issue was also discussed on:

https://github.com/w3c/csswg-drafts/issues/2114

https://github.com/w3c/csswg-drafts/issues/5210



Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Strongly positive - This has been reported in at least 10
separate bugs with a cumulative star count of 75.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

No


Debuggability

N/A


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests

?

New test will be added with the patch.

Flag nameRequires code in //chrome?

False


Tracking bug

https://crbug.com/1201762


Launch bug

https://crbug.com/1120347
Estimated milestones

M108
Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).

https://github.com/w3c/csswg-drafts/issues/5210
Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4651561863610368

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/CAFxahvsyqk3h2TZwDVJzb1KVgLjqmWDWMs3V9-1sZRA7pXkyOQ%40mail.gmail.com.