Intent to Deprecate and Remove: Deprecate <param> element's functionality

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

https://github.com/whatwg/html/pull/7816
https://github.com/whatwg/html/issues/6003

Specification

https://github.com/whatwg/html/pull/7816

Summary

The <param> element can be used to specify parameters such as a URL (via params named "movie", "src", "code", "data", or "url") to a containing <object> element. Given the removal of plugins from the web platform, and the relative lack of use of this particular functionality, we would like to deprecate and remove it.

Blink component

Blink

Motivation

Given that plugins are gone from the web platform (with their full removal from the spec being tracked in https://github.com/whatwg/html/issues/6003), it is not useful. In some browsers it can be used to figure out the URL of an <object>, even when that <object> is not being used for a plugin, via params named "movie", "src", "code", "data", or "url". But we decided to remove this behavior from browsers instead of specifying it. This retains the HTMLParamElement interface, as well as the parser behavior of <param>.

Initial public proposal

Search tags

<param>, <object>

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Shipped/Shipping (https://github.com/whatwg/html/issues/387#issuecomment-1088331300) Issue was initially raised by Mozilla, and Gecko already does not process param at all.

WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=239188) No response on the bug yet.

Web developers: No signals

Other signals:

Ergonomics

Since this is a deprecation, there is a Web Compat risk. I added use counters for the situations that will be affected: - <param> that specifies a URL, inside an <object> that doesn't: 0.04%, https://chromestatus.com/metrics/feature/timeline/popularity/4010 - As above, but URL successfully resolves to a (supported) PDF resource: 0.00002%, https://chromestatus.com/metrics/feature/timeline/popularity/4110 - As above, but URL successfully resolves to an (unsupported) non-PDF resource: not measurable, https://chromestatus.com/metrics/feature/timeline/popularity/4111 So the vast majority (99.95%) of <param> URL usage appears to point to invalid resources - likely mostly Flash. A very small percentage (0.05% of <param>-with-URL usage, 0.00002% of web page loads) are likely to break when we deprecate this functionality.

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

Deprecation.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1315717

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6283184588193792

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

I clicked on the first 20 results from https://chromestatus.com/metrics/feature/timeline/popularity/4010 (careful, 1 is NSFW), and 18 contain busted SWFs. But two of them are embedding youtube videos via <param>:

https://jackrussell.forumattivo.com/ has an <object> that has a child param name="movie" value="https://www.youtube.com/v/_ikcScPyKUQ&hl=it&fs=1&">.

http://sextherapy.ru/ (SFW-ish, at least on the homepage)<param name="src" value="//www.youtube.com/v/7wQYLXBX2RQ?version=3&amp;hl=ru_RU&amp;rel=0" />

I had no idea that was possible - can we dig in some more to see how many params have a value with "youtube.com", to see if I got lucky and found the only 2, or if a lot of sites are relying on this behavior?

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

Deprecation.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1315717

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6283184588193792

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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhXTo%3Dg3scg7KF8g%3Dn5a4rA%3D6UD5cAxTBn9HetnAO%2BJ-A%40mail.gmail.com.

[Mason Freed]

Thanks for digging into the example sites there! So I looked further into the two examples you gave, and I think what's actually going on in both cases is that the <object> also contains fallback content which is what you're seeing:

For http://sextherapy.ru/, the full <object> looks like this:

  <object width="180" height="100"
          classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"
          codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0">
    <param name="allowFullScreen" value="true" />
    <param name="allowscriptaccess" value="always" />

    <param name="src" value="//www.youtube.com/v/7wQYLXBX2RQ?version=3&amp;hl=ru_RU&amp;rel=0" />

    <param name="allowfullscreen" value="true" />
    <embed width="180" height="100" type="application/x-shockwave-flash"
           src="//www.youtube.com/v/7wQYLXBX2RQ?version=3&amp;hl=ru_RU&amp;rel=0"
           allowFullScreen="true" allowscriptaccess="always" allowfullscreen="true" />
  </object>

The <param>s in this example aren't actually doing anything - you can remove them and still see the video, since it's provided by the fallback <embed>. It looks like those params were maybe meant to talk to an SWF object?

Similarly, for https://jackrussell.forumattivo.com/, the <object> is this:

  <object width="560" height="340">
    <param name="movie" value="https://www.youtube.com/v/_ikcScPyKUQ&hl=it&fs=1&"></param>
    <param name="allowFullScreen" value="true"></param>
    <param name="allowscriptaccess" value="always"></param>
    <iframe  width="560" height="315" src="https://www.youtube.com/embed/_ikcScPyKUQ"
           frameborder="0" allowfullscreen=""></iframe>
  </object>

Again, the <param>s aren't doing anything here, and the fallback <iframe> contains the "real" content.

I also confirmed that with the proposed behavior disabled (i.e. <param>s can't provide URLs), both example sites still work.

I'm happy to look further into other such examples if you like, but I think these two examples should be "ok".

Again, thanks for taking a look!

Thanks,

Mason

[Mike Taylor]

Oh cool, I didn't notice the fallback iframe or embed, thanks for pointing that out! I think just to be on the safe side, searching HTTP Archive for a list of sites that have an <object> with non-swf <param> values would be nice to look at, and we could spot check a small pile to ensure this fallback pattern holds and we're not breaking video playback on sites that may not be maintained.

[Mason Freed]

No problem! So here too, I think I have an answer for you. As part of the discussion around deprecating this functionality, I did exactly that: an HTTP Archive search for <object> containing <param>. See this comment, which links to this spreadsheet with results. Also, importantly, see this reply comment with more analysis.

The TL;DR is that in the end, we did not find any issues with the top ~20 sites we found. And while we were looking only for PDF-related params, that's all that Chromium currently supports anyway, so that should be all we're capable of breaking.

LMK if the above satisfies your desire to do more spot checking, or if you'd prefer I look deeper.

Thanks,

Mason

[Mike Taylor]

Fantastic - nice work on the compat analysis. LGTM.

[Mason Freed]

On Fri, Apr 15, 2022 at 2:17 PM Mike Taylor <mike...@chromium.org> wrote:

Fantastic - nice work on the compat analysis. LGTM.

Thanks!

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDg6ZHCp6Ty%2BOAJab8cC94aXK8k5z6yq7sq2eFvj_8S5xw%40mail.gmail.com.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_-EbcQjj4T%2Beoe_NybqSKHeaLSHc4bNA2bTsB3ZH-gqg%40mail.gmail.com.

[Mason Freed]

Thank you all!

[Joe Medley]

Mason,

In which version are you hoping to deprecate and in which are you hoping to remove?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--

[Mason Freed]

On Mon, Apr 18, 2022 at 8:04 AM Joe Medley <jme...@google.com> wrote:

Mason,

In which version are you hoping to deprecate and in which are you hoping to remove?

That's a good question. Given that our expectation is for this to be not very impactful, I was planning to do *both* starting in M102. My plan is to disable the functionality very slowly via Finch, and monitor carefully for reported bugs. Given that this will be in the long tail of sites, I had planned to do that very slowly over the next few months, meaning milestones between 102 and ~103/4 or so. Does that make sense? And if so, does it answer your question concretely enough?

Thanks,

Mason