Re: Intent to implement and ship: DOMTokenList.prototype.supports

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[Karl Dubost]

Boris,

Le 7 mai 2016 à 02:49, Boris Zbarsky  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 



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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[Boris Zbarsky]

On 5/4/16 4:23 AM, zcor...@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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[zcorpan]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[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  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=DOMTokenList=Repositories=%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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[Karl Dubost]

Le 4 mai 2016 à 05:24, Boris Zbarsky  a écrit :
> In practice, this is the set of  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=DOMTokenList=Repositories=%E2%9C%93

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


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[Domenic Denicola]

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

> In practice, this is the set of  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".
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[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  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
, , and , "sandbox" on , and "dropzone" on all elements.  Most 
of these definitions are sane, but the  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  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform