Intent to Implement and Ship: Update fallback content's behavior for ImageInputType and HTMLImageElement

[Yu Han]

Contact emails yuzh...@chromium.org Explainer https://github.com/whatwg/html/issues/5309 Design docs/spec Specification: https://github.com/whatwg/html/pull/5315/ TAG review Very small change, TAG review not needed Summary Previously, there have been inconsistencies on the implementation of fallback content and its treatment as a replaced element for ImageInputType and HTMLImageElement. This led to interoperable issues between implementors. Example in: <input style="display: inline;" type=image alt="ALT text"> <img title="foo"> <img src="https://0" width=10 height=10 alt> The above issues are being resolved with this I2S. Motivation The behavior of ImageInputType's and HTMLImageElement's fallback content was not very interoperable, and not clearly specified. With this HTML spec PR (https://github.com/whatwg/html/pull/5315) the behavior has been more completely specified. Chrome will implement this modified behavior starting in M85. See https://github.com/whatwg/html/issues/5309, https://bugzilla.mozilla.org/show_bug.cgi?id=1196668, and tracking bugs for more details and conversation. Risks

Interoperability and Compatibility As discussed on the spec issue and its linked bugs, the current situation shows that only Chromium is not spec compliant with respect to its handling of fallback content and treatment of replaced element for ImageInputType and HTMLImageElement. Mozilla has updated the html spec and has, along with Safari, fixed their issues. Interoperability will improve once the tracking bug has been fixed on Chromium. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=1196668) Edge: No public signals Safari: Shipped (https://bugs.webkit.org/show_bug.cgi?id=207740) Web developers: No signals Ergonomics This makes the behavior of fallback content for <input type="image"> and <image> more sane and tractable, and reduces interop differences. So this should be a net win. Activation N/A Security N/A

Debuggability This should be fully debuggable. 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? No https://wpt.fyi/results/?label=master&label=experimental&aligned&q=img-no-alt-replaced.html Tracking bug https://crbug.com/1094763 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5428567112417280

[Chris Harrelson]

LGTM1

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABgHHk4cWmx0Y7FHa1_63hmfzNS8cUXWG0b1FwJRgO2i2DLtHw%40mail.gmail.com.

[Yu Han]

I've updated the feature status page to include a doc showcasing the differences between browsers.

https://github.com/yuzhe-han/images-fallback-content-1094763

Thanks,

Han

[Manuel Rego Casasnovas]

On 15/06/2020 21:16, Yu Han wrote:
> I've updated the feature status page to include a doc showcasing the
> differences between browsers.
> https://github.com/yuzhe-han/images-fallback-content-1094763

The screenshots reflect the current status of things, or how they would
end up being in the future once Chromium is modified?
I guess it's the current output, it seems there is no interop between
Firefox and Safari on those examples already, so Chromium would match
only one of them I guess.

> On Mon, Jun 15, 2020 at 9:19 AM Yu Han <yuzh...@chromium.org
> <mailto:yuzh...@chromium.org>> wrote:
>
> Example in:
> <input style="display: inline;"type=image alt="ALT text">
> <img title="foo">
> <img src="https://0" width=10 height=10 alt>
> The above issues are being resolved with this I2S.

Which issues are resolved? Would these 3 examples be interoperable after
this intent?

> Is this feature fully tested by web-platform-tests?
> No
> https://wpt.fyi/results/?label=master&label=experimental&aligned&q=img-no-alt-replaced.html

That test is already passing in all browsers, so not very useful for
this intent I guess.

Are there plans to add more WPT tests during the implementation?

Bye,
Rego

[Yu Han]

Comments inlined.

On Mon, Jun 15, 2020 at 11:30 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 15/06/2020 21:16, Yu Han wrote:
> I've updated the feature status page to include a doc showcasing the
> differences between browsers.
> https://github.com/yuzhe-han/images-fallback-content-1094763

The screenshots reflect the current status of things, or how they would
end up being in the future once Chromium is modified?
I guess it's the current output, it seems there is no interop between
Firefox and Safari on those examples already, so Chromium would match
only one of them I guess.

Right. Chrome's rendering for image fallback content isn't spec compliant. Firefox is the most correct.

After the issues have been fixed in the tracking bug, chrome will match Firefox.

 

>     On Mon, Jun 15, 2020 at 9:19 AM Yu Han <yuzh...@chromium.org
>     <mailto:yuzh...@chromium.org>> wrote:
>
>         Example in:
>           <input style="display: inline;"type=image alt="ALT text">
>           <img title="foo">
>           <img src="https://0" width=10 height=10 alt>
>         The above issues are being resolved with this I2S.

Which issues are resolved? Would these 3 examples be interoperable after
this intent?

 

Yes, the three examples are problems in chrome that's being addressed by this intent. 

In the link https://github.com/yuzhe-han/images-fallback-content-1094763, I provided links to test files that showcase problems listed in the example.

<input style="display: inline;"type=image alt="ALT text">.

    -  https://crbug.com/948066  

    - https://html.spec.whatwg.org/multipage/rendering.html#images-3:represents-5

    - It should be treated as replaced element with the "display: inline" taking effect.

<img title="foo">

   - https://crbug.com/958250

 <img src="https://0" width=10 height=10 alt>

  - https://crbug.com/753868

Both the examples have null or empty alt tag and should be treated as a replaced element with its intrinsic dimensions.

https://html.spec.whatwg.org/multipage/rendering.html#images-3:represents-2

>         Is this feature fully tested by web-platform-tests?
>         No
>         https://wpt.fyi/results/?label=master&label=experimental&aligned&q=img-no-alt-replaced.html

That test is already passing in all browsers, so not very useful for
this intent I guess.

Are there plans to add more WPT tests during the implementation?

Yes, more tests will be added. That test isn't through enough.

There was an offline email with Firefox to address these three issues in Chrome to improve interoperability.

Bye,
  Rego

[Manuel Rego Casasnovas]

**LGTM2**

This is moving towards improving interop so it looks like a good thing
to do. Anyway I added some more comments inline.

On 16/06/2020 20:43, Yu Han wrote:
> Right. Chrome's rendering for image fallback content isn't spec
> compliant. Firefox is the most correct.
> After the issues have been fixed in the tracking bug, chrome will match
> Firefox.

So after this work Chromium and Firefox would have interoperability but
some issues will be still present in WebKit? If that's correct please
make sure you report the problems on WebKit bugtracker.

> >         Is this feature fully tested by web-platform-tests?
> >         No
> >       
>  https://wpt.fyi/results/?label=master&label=experimental&aligned&q=img-no-alt-replaced.html
>
> That test is already passing in all browsers, so not very useful for
> this intent I guess.
>
> Are there plans to add more WPT tests during the implementation?
>
> Yes, more tests will be added. That test isn't through enough.
> There was an offline email with Firefox to address these three issues in
> Chrome to improve interoperability.

Please make sure you add new tests covering all the cases, and that they
are interoperable.

Bye,
Rego

[Yoav Weiss]

LGTM3

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/50caf77f-39d6-010d-c94c-04c95e6caf8b%40igalia.com.