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,
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
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
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
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.
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
>
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
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
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
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
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.
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
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
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
14 matches
Mail list logo