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

108 views
Skip to first unread message

Mason Freed

unread,
Apr 13, 2022, 12:48:21 PMApr 13
to blink-dev

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

unread,
Apr 15, 2022, 2:06:15 PMApr 15
to Mason Freed, blink-dev

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

unread,
Apr 15, 2022, 2:31:39 PMApr 15
to Mike Taylor, blink-dev
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="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

unread,
Apr 15, 2022, 4:52:10 PMApr 15
to Mason Freed, blink-dev
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

unread,
Apr 15, 2022, 5:02:51 PMApr 15
to Mike Taylor, blink-dev
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

unread,
Apr 15, 2022, 5:17:08 PMApr 15
to Mason Freed, blink-dev
Fantastic - nice work on the compat analysis. LGTM.

Mason Freed

unread,
Apr 15, 2022, 5:20:26 PMApr 15
to Mike Taylor, blink-dev
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

unread,
Apr 15, 2022, 5:24:27 PMApr 15
to Mason Freed, Mike Taylor, blink-dev

Yoav Weiss

unread,
Apr 16, 2022, 1:22:20 AMApr 16
to Chris Harrelson, Mason Freed, Mike Taylor, blink-dev

Mason Freed

unread,
Apr 16, 2022, 11:54:26 PMApr 16
to Yoav Weiss, Chris Harrelson, Mike Taylor, blink-dev
Thank you all!

Joe Medley

unread,
Apr 18, 2022, 11:04:59 AMApr 18
to Mason Freed, blink-dev
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

unread,
Apr 18, 2022, 4:57:29 PMApr 18
to Joe Medley, blink-dev
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
Reply all
Reply to author
Forward
0 new messages