Intent to Implement and Ship: Invalid <track kind> values behave like "metadata", not "subtitles"

26 views
Skip to first unread message

Fredrik Söderquist

unread,
May 9, 2016, 8:38:24 AM5/9/16
to blink-dev
f...@opera.com https://html.spec.whatwg.org/multipage/embedded-content.html#attr-track-kind Invalid values for <track kind> are currently treated as "subtitles". This means that any new values will be treated as subtitles by old UAs. Instead use "metadata" as the "invalid value default", to avoid UAs showing <track>s with unrecognized values.
Better (future...) backwards compat story and hence improved abilities to experiment/tinker with new kinds of text tracks. Firefox: Shipped (https://groups.google.com/forum/#!topic/mozilla.dev.platform/42-W463M4Ig/discussion; https://bugzilla.mozilla.org/show_bug.cgi?id=1269712)
Edge: No public signals Safari: No public signals Web developers: No signals
Low (0.001% according to httparchive search [source: Mozilla Intent-thread above])
None
Yes https://bugs.chromium.org/p/chromium/issues/detail?id=608772 https://www.chromestatus.com/features/6401997133578240
Yes

Rick Byers

unread,
May 9, 2016, 8:04:55 PM5/9/16
to Fredrik Söderquist, blink-dev
Normally I think we'd want a UseCounter before making a breaking change like this (eg. in case there's one popular site that's creating such DOM dynamically, or is otherwise invisible to the HTTPArchive search).

For the known breaks (mostly use of "subtitle" instead of "subtitles"), can you check to see what the exact behavior of the affected pages (below) is?  Is it simply that subtitles are no longer available, or something more severe (even if the user doesn't request subtitles).  If you can do a bit of digging into the sites we know from HTTPArchive that are broken, and there are no surprises, then I'm OK with this.

Alternately I'd suggest adding the UseCounter to give us more confidence that this "subtitle" pattern isn't more common than HTTPArchive suggests.

---
Pages from HTTPArchive matching:
SELECT page, url   
FROM [httparchive:har.2016_04_15_chrome_requests_bodies]
WHERE REGEXP_MATCH(LOWER(body), r'<track\s(?:[^>]+\s)?kind\s*=\s*["\']?subtitle[^s]') 


Fredrik Söderquist

unread,
May 10, 2016, 5:46:16 AM5/10/16
to Rick Byers, blink-dev
On Tue, May 10, 2016 at 2:04 AM, Rick Byers <rby...@chromium.org> wrote:
Normally I think we'd want a UseCounter before making a breaking change like this (eg. in case there's one popular site that's creating such DOM dynamically, or is otherwise invisible to the HTTPArchive search).

For the known breaks (mostly use of "subtitle" instead of "subtitles"), can you check to see what the exact behavior of the affected pages (below) is?  Is it simply that subtitles are no longer available, or something more severe (even if the user doesn't request subtitles).  If you can do a bit of digging into the sites we know from HTTPArchive that are broken, and there are no surprises, then I'm OK with this.

What will actually happen is subject to settings. The default setting on Desktop platforms is "default" while on Android the setting will reflect the system captioning setting (IIR/UC) - which means it can assume a setting of "captions". For the "default" setting, only <track>s with the 'default' boolean attribute will be enabled. This did not appear to be the case for any of the the sites I looked at (i.e none specified the 'default' attribute), so there would be no change in behavior here. For Android however, these tracks would previously (w/o the proposed change) be subject to automatic selection based on language and kind if the system captioning setting is enabled, so depending on language settings the track(s) may or may not have been shown [1]. Additionally the user could force-enable controls and show tracks that way, but I'd consider that unlikely. (Only one site seemed to have UA controls enabled.)
 

Alternately I'd suggest adding the UseCounter to give us more confidence that this "subtitle" pattern isn't more common than HTTPArchive suggests.

---
Pages from HTTPArchive matching:
SELECT page, url   
FROM [httparchive:har.2016_04_15_chrome_requests_bodies]
WHERE REGEXP_MATCH(LOWER(body), r'<track\s(?:[^>]+\s)?kind\s*=\s*["\']?subtitle[^s]') 


(1 hit?) This leaves me at a login page. Looking at the JS file though, this appears to rely on a another script/framework (subtitles_html5.js) to handle the track file itself (assuming it's SRT and incompatible with WebVTT). All this appears to be conditional on |srt_exist| which I don't see get set to a truthy value (but context is obviously lacking here.)
 

(1 hit) Appears to be using some video player framework ("ELCVideoPlayer"; no luck finding more info about it) that creates <track> elements. It's not obvious that this functionality is used by the page, but if it did use the subtitles feature it might no longer show a track which it previous did (on Android.)
 

(1 hit) Conditionally adds a <track> and always sets language to "en-US". No visible use of this feature though (i.e nothing that sets |srtUrl|.)
 

(18 hits) No <track> here actually specify language so they would all score 0 and we wouldn't show them - before or after the change. (On Android.)
 

(1 hit) UK version of aveda.com. Uses the same framework (but not minified, and possibly not the same version). Same analysis as the .com version.


(18 hits) Same analysis as the .co.uk site.
 

(1 hit) Another ELCVideoPlayer. Essentially the same analysis result as the aveda sites (i.e no obvious use, but if there was it would no longer show a track.)


/fs

[1] This depends on scoring, but in all these cases the score would be solely based on the language, because with the Android captioning setting we'll still prefer 'captions' to 'subtitles'.



On Mon, May 9, 2016 at 8:38 AM, Fredrik Söderquist <f...@opera.com> wrote:
f...@opera.com https://html.spec.whatwg.org/multipage/embedded-content.html#attr-track-kind Invalid values for <track kind> are currently treated as "subtitles". This means that any new values will be treated as subtitles by old UAs. Instead use "metadata" as the "invalid value default", to avoid UAs showing <track>s with unrecognized values.
Better (future...) backwards compat story and hence improved abilities to experiment/tinker with new kinds of text tracks. Firefox: Shipped (https://groups.google.com/forum/#!topic/mozilla.dev.platform/42-W463M4Ig/discussion; https://bugzilla.mozilla.org/show_bug.cgi?id=1269712)
Edge: No public signals Safari: No public signals Web developers: No signals
Low (0.001% according to httparchive search [source: Mozilla Intent-thread above])
None
Yes https://bugs.chromium.org/p/chromium/issues/detail?id=608772 https://www.chromestatus.com/features/6401997133578240
Yes

--
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.

Rick Byers

unread,
May 10, 2016, 1:51:16 PM5/10/16
to Fredrik Söderquist, blink-dev
Thanks for the additional research!

dglazkov@ jochen@ slightlyoff@ and I discussed this in the API owners meeting and agree the risk is low.  LGTM x3
Reply all
Reply to author
Forward
0 new messages