Intent to implement and ship: DOMTokenList.prototype.supports

[Boris Zbarsky]

Summary: A way to feature-detect which values of various tokenlist
attributes actually do something. Useful for things like which iframe
sandbox tokens are supported, or what "rel" values for <link> are supported.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1257849

Link to Standard: If only it were so simple. The basic feature is
defined at https://dom.spec.whatwg.org/#dom-domtokenlist-supports but it
depends on consumers of token lists defining the set of "supported
tokens" for them. In practice that means HTML. HTML defines supported
tokens for "rel" on <a>, <area>, and <link>, "sandbox" on <iframe>, and
"dropzone" on all elements. Most of these definitions are sane, but the
<link> one includes a "yeah, just monkeypatch this" aspect that makes it
a bit hard to figure out what the actual set of supported tokens is.

Anyway, the relevant definitions are:
https://html.spec.whatwg.org/multipage/semantics.html#attr-hyperlink-rel

https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-sandbox

https://html.spec.whatwg.org/multipage/interaction.html#the-dropzone-attribute
https://html.spec.whatwg.org/multipage/semantics.html#linkTypes

In practice, this is the set of <link rel> values I'm claiming we
support: "import" (if IsImportEnabled()), "prefetch", "dns-prefetch",
"stylesheet", "next", "alternate", "preconnect", "icon". Anything else
I'm missing? Do we do anything useful with rel="feed" anymore?

Estimated or target release: Firefox 49

Preference behind which this is implemented: none.

DevToolks bug: none; I'm not sure we need anything special here.

Support in other browsers: Blink supports this, though only for
iframe@sandbox and link@rel (because its a@rel is not a DOMTokenList).
Not sure about others.

Security/privacy concerns: none.

-Boris

[smaug]

Ok to me, given that adding the API to the platform is supported by other browser vendors too.


(Though it is a bit mystery to me why DOMTokenList.supports is considered fine when it is pretty much similar feature to Node.isSupported and that one
was considered harmful to the platform. But I'm not going to reopen that question.)

On 05/03/2016 11:24 PM, Boris Zbarsky wrote:
> Summary: A way to feature-detect which values of various tokenlist attributes actually do something. Useful for things like which iframe sandbox
> tokens are supported, or what "rel" values for <link> are supported.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1257849
>
> Link to Standard: If only it were so simple. The basic feature is defined at https://dom.spec.whatwg.org/#dom-domtokenlist-supports but it depends on
> consumers of token lists defining the set of "supported tokens" for them. In practice that means HTML. HTML defines supported tokens for "rel" on
> <a>, <area>, and <link>, "sandbox" on <iframe>, and "dropzone" on all elements. Most of these definitions are sane, but the <link> one includes a
> "yeah, just monkeypatch this" aspect that makes it a bit hard to figure out what the actual set of supported tokens is.
>
> Anyway, the relevant definitions are:
> https://html.spec.whatwg.org/multipage/semantics.html#attr-hyperlink-rel
>
> https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-sandbox
>
> https://html.spec.whatwg.org/multipage/interaction.html#the-dropzone-attribute
> https://html.spec.whatwg.org/multipage/semantics.html#linkTypes
>
> In practice, this is the set of <link rel> values I'm claiming we support: "import" (if IsImportEnabled()), "prefetch", "dns-prefetch", "stylesheet",
> "next", "alternate", "preconnect", "icon". Anything else I'm missing? Do we do anything useful with rel="feed" anymore?

Do we need "import" ever? I guess that will be removed once we remove import related code.

>
> Estimated or target release: Firefox 49
>
> Preference behind which this is implemented: none.
>
> DevToolks bug: none; I'm not sure we need anything special here.
>
> Support in other browsers: Blink supports this, though only for iframe@sandbox and link@rel (because its a@rel is not a DOMTokenList). Not sure about
> others.
>
> Security/privacy concerns: none.
>
> -Boris

-Olli

[Boris Zbarsky]

On 5/3/16 4:38 PM, smaug wrote:
> Do we need "import" ever?

Is IsImportEnabled() ever true?

> I guess that will be removed once we remove import related code.

Seems plausible.

-Boris

[Domenic Denicola]

On Tuesday, May 3, 2016 at 4:24:26 PM UTC-4, Boris Zbarsky wrote:

> In practice, this is the set of <link rel> values I'm claiming we
> support: "import" (if IsImportEnabled()), "prefetch", "dns-prefetch",
> "stylesheet", "next", "alternate", "preconnect", "icon". Anything else
> I'm missing? Do we do anything useful with rel="feed" anymore?

Does Firefox support "next" in some interesting way? Maybe it is confusing to have it in the spec, but IIRC the idea was that this would be used for people trying to figure out if annotating their links with "next" would actually affect the user agent's processing or UI in some way.

I, uh, have no idea why we included "next" but not "prev".

[Boris Zbarsky]

On 5/3/16 7:20 PM, Domenic Denicola wrote:
> Does Firefox support "next" in some interesting way?

Yes. We treat it as an alias for "prefetch".

> I, uh, have no idea why we included "next" but not "prev".

The theory, presumably, is that people typically go forward through
things in order. Mostly. Or something.

-Boris

[Karl Dubost]

Le 4 mai 2016 à 05:24, Boris Zbarsky <bzba...@MIT.EDU> a écrit :
> In practice, this is the set of <link rel> values I'm claiming we support: "import" (if IsImportEnabled()), "prefetch", "dns-prefetch", "stylesheet", "next", "alternate", "preconnect", "icon". Anything else I'm missing? Do we do anything useful with rel="feed" anymore?

for feed, I guess, it is still in the menu and you can put it back on the main bar and I suspect add-ons are still using it. Also found
https://dxr.mozilla.org/mozilla-central/source/browser/modules/ContentLinkHandler.jsm#48

I also wonder in addition of "icon" about "favicon".
I don't think the browser does anything with "canonical" and "nofollow" (search engines).


fwiw
https://github.com/search?l=JavaScript&q=DOMTokenList&type=Repositories&utf8=%E2%9C%93

example
https://github.com/jwilsson/domtokenlist/blob/master/src/relList.js


--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Boris Zbarsky]

On 5/3/16 10:53 PM, Karl Dubost wrote:
> for feed, I guess, it is still in the menu

Hmm. Where?

> and you can put it back on the main bar

Ah, indeed. I guess we could try to do something where Gecko would
report "feed" as supported if that button is on the toolbar, but that
seems complicated.

> and I suspect add-ons are still using it.

Again, seems like that would require that we only claim it to be
supported if those addons are installed.

> Also found
> https://dxr.mozilla.org/mozilla-central/source/browser/modules/ContentLinkHandler.jsm#48

So this sends the "Link:AddFeed" message. Looks like this is what
updates the state of that toolbar button.

Looking at this code, there's also similar handling for "search", right?
Again, not sure whether that's exposed in the default UI.

> I also wonder in addition of "icon" about "favicon".

I don't see anything we do with <link rel="favicon"> anywhere...

> I don't think the browser does anything with "canonical" and "nofollow" (search engines).

I believe that's right

> fwiw
> https://github.com/search?l=JavaScript&q=DOMTokenList&type=Repositories&utf8=%E2%9C%93
>
> example
> https://github.com/jwilsson/domtokenlist/blob/master/src/relList.js

Doesn't seem to matter in this case, because we already have relList on
HTMLAnchorElement. I'm just adding another method to that DOMTokenList.

-Boris

[Matthew N.]

On 2016-05-03 9:01 PM, Boris Zbarsky wrote:
> Looking at this code, there's also similar handling for "search", right?
> Again, not sure whether that's exposed in the default UI.

A green plus sign appears above the magnifying glass in the search bar
for rel="search" and the menu allows you to add that engine to the
browser. You can test in a new profile with https://bugzilla.mozilla.org/

-MattN

[Boris Zbarsky]

On 5/4/16 12:06 AM, Matthew N. wrote:
> A green plus sign appears above the magnifying glass in the search bar
> for rel="search" and the menu allows you to add that engine to the
> browser. You can test in a new profile with https://bugzilla.mozilla.org/

Ah, so it does! OK, I'll add "search" to our list of supported values.

-Boris

[zco...@gmail.com]

On Wednesday, May 4, 2016 at 6:01:10 AM UTC+2, Boris Zbarsky wrote:
> On 5/3/16 10:53 PM, Karl Dubost wrote:
> > for feed, I guess, it is still in the menu
>
> Hmm. Where?
>
> > and you can put it back on the main bar
>
> Ah, indeed. I guess we could try to do something where Gecko would
> report "feed" as supported if that button is on the toolbar, but that
> seems complicated.

"feed" was removed from the spec some years ago, see
https://github.com/whatwg/html/commit/2e3e7a8fd2441e28c43cf2b588db448821d581a4
https://blog.whatwg.org/the-road-to-html-5-link-relations#rel-feed

[Boris Zbarsky]

On 5/4/16 4:23 AM, zco...@gmail.com wrote:
> "feed" was removed from the spec some years ago, see
> https://github.com/whatwg/html/commit/2e3e7a8fd2441e28c43cf2b588db448821d581a4
> https://blog.whatwg.org/the-road-to-html-5-link-relations#rel-feed

Yes, but see the bit about monkeypatching. Basically anyone who feels
like can define a link type.

-Boris

[Boris Zbarsky]

On 5/4/16 12:13 AM, Boris Zbarsky wrote:
> Ah, so it does! OK, I'll add "search" to our list of supported values.

Actually, that would technically be a spec violation for the moment,
since HTML does define this link type and doesn't list it in the
possible supported types list.

See also https://github.com/whatwg/html/issues/1184

-Boris

[Boris Zbarsky]

On 5/4/16 9:36 AM, Boris Zbarsky wrote:
> Actually, that would technically be a spec violation for the moment,
> since HTML does define this link type and doesn't list it in the
> possible supported types list.

I landed this without "search" in the list for the moment, pending the
outcome of the spec issue at https://github.com/whatwg/html/issues/1184

-Boris

[Karl Dubost]

Boris,

Le 7 mai 2016 à 02:49, Boris Zbarsky <bzba...@MIT.EDU> a écrit :
> I landed this without "search" in the list for the moment, pending the outcome of the spec issue at https://github.com/whatwg/html/issues/1184

(re) thinking about that issue this morning. Not sure if I have a firm idea about it, just thinking out loud.


I was wondering if it makes to add in the supports() list all keywords which have influences to the Chrome of browser, aka no effect on navigation context.

For example,

* link rel="feed" has an effect on the chrome UI, by enabling the possibility to subscribe to the feed.
* link rel="icon" by adding a favicon on the bookmarks, etc, or the add to screen icon,

but they don't have direct benefits for the Web developer in the context of supports(), prefetch on the other hand has a direct influence for the site as we have seen for Amazon.


PS: rel values have benefits for semantics, creating meaning, etc for search engines, and add ons tools but already provided by things like DOMTokenList https://developer.mozilla.org/en-US/docs/Web/API/DOMTokenList

[Boris Zbarsky]

On 5/8/16 10:18 PM, Karl Dubost wrote:
> I was wondering if it makes to add in the supports() list all keywords which have influences to the Chrome of browser, aka no effect on navigation context.

That depends on what the goal is, obviously.

> * link rel="feed" has an effect on the chrome UI, by enabling the possibility to subscribe to the feed.

Or not, depending on the UI setup.

The key question for me in this sort of situation is this: if a page
wants to provide a link to a feed, how can it tell whether the UA
provides such UI on its own already or whether the page should add a
visible link in the content area? This seems like a job for supports().

-Boris