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, urlFROM [httparchive:har.2016_04_15_chrome_requests_bodies]WHERE REGEXP_MATCH(LOWER(body), r'<track\s(?:[^>]+\s)?kind\s*=\s*["\']?subtitle[^s]')
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 signalsLow (0.001% according to httparchive search [source: Mozilla Intent-thread above])
--
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.