On 2016-05-05 3:21 PM, Justin Dolske wrote:
How will a developer know when it would be worthwhile to mark their event
listener as passive? Do we perhaps log something to the console?
The Chrome devtools have two features to help with this: They have a
checkbox for "Show scrolling perf issues"
er to
>> read for those already familiar with DOM events.
>>
>> Platform coverage: all platforms
>>
>> Estimated or target release: Hoping to get it in Firefox 49. I wrote
>> the patches today (they were pretty small) hence combining the intent
>> t
https://github.com/WICG/EventListenerOptions which might be easier to
> read for those already familiar with DOM events.
>
> Platform coverage: all platforms
>
> Estimated or target release: Hoping to get it in Firefox 49. I wrote
> the patches today (they were pretty small) hen
e combining the intent
to implement and ship into this email rather than sending two separate
emails.
Preference behind which this will be implemented: none at the moment
Other browsers: See
https://github.com/WICG/EventListenerOptions#status-of-implementations
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 http
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. Basicall
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
> re
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
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
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 complicate
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 wi
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. Mos
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
https:
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
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 i
On 4/25/16 10:47 PM, Boris Zbarsky wrote:
Ah. Perhaps we should hold off on doing this until
https://bugzilla.mozilla.org/show_bug.cgi?id=1257849 is fixed then. And
the window.open thing would still not be detectable, so people would
probably start assuming the anchor bit implied the window thi
Thanks for the replies, Dan and Roy.
A first order filter node with AudioParam inputs seems a likely
future addition AFAIK.
Even with that though, having a way to apply a custom biquad
without needing to decompose into multiple textbook filters is
useful I think. And I agree that implementing th
On Wed, Apr 27, 2016 at 6:35 PM, Karl Tomlinson wrote:
> Daniel Minor writes:
>
> > Summary: This provides an alternative to using BiquadFilterNode when
> > odd-order filters are required or automation is not needed. It is part of
> > the Web Audio spec and is already implemented in Blink.
>
> Th
Daniel Minor writes:
> Summary: This provides an alternative to using BiquadFilterNode when
> odd-order filters are required or automation is not needed. It is part of
> the Web Audio spec and is already implemented in Blink.
Thanks for looking at this, Daniel.
I fear that high order filters are
Summary: This provides an alternative to using BiquadFilterNode when
odd-order filters are required or automation is not needed. It is part of
the Web Audio spec and is already implemented in Blink.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1265408
Link to standard:
http://webaudio.github
On 4/25/16 10:31 PM, Domenic Denicola wrote:
On Monday, April 25, 2016 at 2:09:07 PM UTC-4, Boris Zbarsky wrote:
1) This is not feature-detectible, as far as I can see. So it's not
clear to me that sites will know they can use this, short of relying on
browser sniffing.
If you implement DOMT
On Monday, April 25, 2016 at 2:09:07 PM UTC-4, Boris Zbarsky wrote:
> 1) This is not feature-detectible, as far as I can see. So it's not
> clear to me that sites will know they can use this, short of relying on
> browser sniffing.
If you implement DOMTokenList.prototype.supports, it should be
On 4/25/16 2:57 PM, Tanvi Vyas wrote:
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1267339
I think you meant to link to bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1222516 here.
Er... right you are. Too many identical-looking tabs. ;)
-Boris
__
Very cool! Thanks for implementing.
On 4/25/16 11:09 AM, Boris Zbarsky wrote:
Summary: The idea is to be able to write
Go
there
and not have "someone-I-don't-trust" be able to get hold of your
window via window.opener.
This is already possible with rel="noreferrer", but that also preve
Summary: The idea is to be able to write
Go
there
and not have "someone-I-don't-trust" be able to get hold of your window
via window.opener.
This is already possible with rel="noreferrer", but that also prevents
sending a referrer, which is undesirable in cases like search engine
result
Summary:
According to some people from Japanese ebook companies,
text-combine-upright (a.k.a horizontal-in-vertical, or tate-chu-yoko) is a
must for Japanese vertical layout. Without the proper support of this
feature, a book may not be considered complete, and thus cannot be sold
online. This is a
*Summary*: This API allows a web page to specify how the resources it
fetches interact with the browser HTTP cache.
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1120715
*Link to standard*: https://fetch.spec.whatwg.org/
*Platform coverage*: All platforms
*Estimated or target release*: Firefo
*Summary*: This simple API allows one to test whether a given key is
included in an IDBKeyRange
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1251498
*Link to standard*: http://w3c.github.io/IndexedDB/#dom-idbkeyrange-includes
*Platform coverage*: All platforms
*Estimated or target release*:
*Summary*: These APIs allow a web page to specify a referrer and a referrer
policy when fetching a resource.
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1184549
*Link to standard*: https://fetch.spec.whatwg.org/
*Platform coverage*: All platforms
*Estimated or target release*: Firefox 47
*P
By the way, I just got informed (from Google) that TLS Channel ID, even if
activated on Google servers (including appspot), is only enforced for few users
for now (even If I am not sure how they do that :) )
So Firefox users should not be blocked for that reason :)
They seem to agree you probab
On Monday, February 8, 2016 at 10:54:36 PM UTC+1, Ryan Sleevi wrote:
> On Mon, Feb 8, 2016 at 1:13 PM, Frederic Martin wrote:
> >
> > 1) From a security architect perspective. This is an official
> > recommendation that makes sens to prevent MITM attacks. FIDO U2F was
> > created to minimize/elim
On Mon, Feb 8, 2016 at 10:13 PM, Frederic Martin
wrote:
> Hi,
>
> thanx for the answer.
>
> Quoting Dirk Balfanz (one of the TLS Channel ID specifications author, a
> few days ago on FIDO DEV forum):
>
> "the new spec that replaces ChannelID is called "Token Binding", and is in
> the process of b
On Mon, Feb 8, 2016 at 1:13 PM, Frederic Martin wrote:
>
> 1) From a security architect perspective. This is an official recommendation
> that makes sens to prevent MITM attacks. FIDO U2F was created to
> minimize/eliminate that kind of risk.
U2F itself addresses phishing. Token Binding (attempt
Hi,
thanx for the answer.
Quoting Dirk Balfanz (one of the TLS Channel ID specifications author, a few
days ago on FIDO DEV forum):
"the new spec that replaces ChannelID is called "Token Binding", and is in the
process of being standardized by the IETF
(https://datatracker.ietf.org/wg/tokbind
On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir
wrote:
> Hi,
>
> Great news about you making progress on this !
>
> Since I read here and there that you are working with Firefox & Chrome U2F
> support consistency in mind, what's your take on TLS Channel ID (Token
> Binding) support inside Firefo
Hi,
Great news about you making progress on this !
Since I read here and there that you are working with Firefox & Chrome U2F
support consistency in mind, what's your take on TLS Channel ID (Token
Binding) support inside Firefox ?
It is a recommended feature for FIDO U2F client (Firefox here) in
All,
We're making progress on implementing FIDO U2F in Firefox. The effort is
split into a number of bugs at present. First, a quick rundown of where we
are:
* The tracking bug for U2F support is Bug 1065729.
* Bug 1198330 is to implement USB HID support in Firefox.
* Bug 1231681 implements the W
On Wednesday, December 2, 2015 at 2:23:28 AM UTC+1, Richard Barnes wrote:
> The FIDO Alliance has been developing standards for hardware-based
> authentication of users by websites [1]. Their work is getting significant
> traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
>
On 1/14/16 9:09 PM, L. David Baron wrote:
It seems to me this is important to have behind a preference that is
specific to new webkit-prefixed features, given the compatibility
risks of shipping support for some but not all webkit-prefixed
features.
(It's possible it could be the same preference
On Thursday 2016-01-14 14:06 -0800, William Chen wrote:
> *Summary*: WebKitCSSMatrix has been available for years in WebKit based
> browsers and has seen widespread usage on the web. This feature is
> currently available in Chrome, Safari and Edge. Mike Taylor has been
> working on standardizing th
Ship it!
On Thu, Jan 14, 2016 at 2:06 PM, William Chen wrote:
> *Summary*: WebKitCSSMatrix has been available for years in WebKit based
> browsers and has seen widespread usage on the web. This feature is
> currently available in Chrome, Safari and Edge. Mike Taylor has been
> working on standard
*Summary*: WebKitCSSMatrix has been available for years in WebKit based
browsers and has seen widespread usage on the web. This feature is
currently available in Chrome, Safari and Edge. Mike Taylor has been
working on standardizing the feature and it is being implemented in Gecko
to improve web co
I'm no longer directly involved with the FIDO Alliance, so I can't speak to the
FIDO 2.0 timelines, but my general experience there plus at the W3C tells me
that it will some time before the new APIs stabilize. I hope that this won't
dissuade Mozilla from beginning work on implementing U2F more
On 12/04/2015 06:56 PM, smaug wrote:
Looks like the spec could be made implementable by fixing
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api
"provide a namespace object u2f of the following interface" doesn't mean
a
Looks like the spec could be made implementable by fixing
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api
"provide a namespace object u2f of the following interface" doesn't mean
anything, so either there is supposed t
On 12/02/2015 11:37 PM, Frederic Martin wrote:
As I said in the other email,
I don't understand how this could be implemented when the spec has left the
>key piece undefined, as far as I see.
You are completely right ! For now, FIDO 2 is currently being written (far far
far from finished) and
Le jeudi 3 décembre 2015 01:28:51 UTC+1, Justin Dolske a écrit :
> On 12/2/15 6:48 AM, Richard Barnes wrote:
>
> > My initial intent was to propose implementing [1], then implementing [2]
> > when it's ready. After all, there's a lot in common, and as you say, >the
> > W3C version will be much n
> That said, I think we're in violent agreement that the specs are far, far,
> far from finished - and I'm unclear whether we're in agreement that one is
> under active development, while the other is a technological dead end which,
> through a series of unfortunate events, happened to have been
On 12/2/15 6:48 AM, Richard Barnes wrote:
My initial intent was to propose implementing [1], then implementing [2]
when it's ready. After all, there's a lot in common, and as you say, the
W3C version will be much nicer.
This seems like like a strange path to take. Why implement both?
From el
On Wednesday, December 2, 2015 at 3:08:44 PM UTC-8, Frederic Martin wrote:
> Sorry, but I don't understand why you are denying the evidence, anyone
> at Fido alliance will confirm that even non-public FIDO 2 drafts are far
> far far from finished. Regarding the glimpse that was published in W3c
>
Le mercredi 2 décembre 2015 23:43:00 UTC+1, Ryan Sleevi a écrit :
> On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote:
> > I don't understand how 1) could be implemented when the spec has left the
> > key piece undefined, as far as I see.
> > As the spec puts it "This specification d
On 12/2/15 5:42 PM, Ryan Sleevi wrote:
On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote:
I don't understand how 1) could be implemented when the spec has left the key
piece undefined, as far as I see.
As the spec puts it "This specification does not describe how such a port is
m
On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote:
> I don't understand how 1) could be implemented when the spec has left the key
> piece undefined, as far as I see.
> As the spec puts it "This specification does not describe how such a port is
> made available to RP web pages, as
On Wed, Dec 2, 2015 at 1:11 PM, Frederic Martin
wrote:
> > > There are probably other questions Mozilla Core Team should ask to
> > > themselves :
> > >
> > > - Having a greater/larger HID Support, outside the FIDO U2F scope ?
> > > (This allows web services to communicate with HID devices - i.e.
>As I said in the other email,
>I don't understand how this could be implemented when the spec has left the
>>key piece undefined, as far as I see.
You are completely right ! For now, FIDO 2 is currently being written (far far
far from finished) and can't be implemented, so let's focus on exis
On 12/02/2015 03:23 AM, Richard Barnes wrote:
The FIDO Alliance has been developing standards for hardware-based
authentication of users by websites [1]. Their work is getting significant
traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
Work has begun in the W3C to crea
On 12/02/2015 07:25 AM, ryan.sle...@gmail.com wrote:
On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:
Oh well. Bummer.
/ Jonas
If it cheers you up any, the 2.0 API that replaces the U2F API uses promises -
http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
R
> > There are probably other questions Mozilla Core Team should ask to
> > themselves :
> >
> > - Having a greater/larger HID Support, outside the FIDO U2F scope ?
> > (This allows web services to communicate with HID devices - i.e.
> > that's how some cryptocurrencies hardware wallets are using HI
On 2015-12-02 9:48 AM, Richard Barnes wrote:
On Wed, Dec 2, 2015 at 12:25 AM, wrote:
On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:
Oh well. Bummer.
/ Jonas
If it cheers you up any, the 2.0 API that replaces the U2F API uses
promises - http://www.w3.org/Submission/2
On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan
wrote:
> On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla wrote:
>
>> Are you thinking of something like WebUSB?
>> (https://reillyeon.github.io/webusb/)? This is something we've looked at
>> a bit but we're still trying to wrap our heads around the
On 02.12.2015 18:53, Robert O'Callahan wrote:
> On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla wrote:
>
>> Are you thinking of something like WebUSB?
>> (https://reillyeon.github.io/webusb/)? This is something we've looked at
>> a bit but we're still trying to wrap our heads around the security
>>
On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla wrote:
> Are you thinking of something like WebUSB?
> (https://reillyeon.github.io/webusb/)? This is something we've looked at
> a bit but we're still trying to wrap our heads around the security
> implications.
>
Where are we discussing that? I'd re
Hi Freddie, glad to see people so excited about it.
On Wed, Dec 2, 2015 at 8:22 AM, wrote:
>
> So, let's forget about 2 for now, it is not a real thing... and
> well.. let's forget it. (If you read both specs you should see
> real differences and problems...)
>
> There are probably other question
Hi All, great news !
TL;DR version:
--
I love U2F, I love Firefox
FIDO U2F is here to stay.
FIDO 2.0 do not exist and will not replace U2F.
FIDO U2F is really great.
Please implement FIDO U2F.
Please please please implement TLS Channel ID Binding support
(important part of FIDO U2F s
On 12/2/15 8:53 AM, Ms2ger wrote:
I don't remember what the current conventional wisdom about
prefixing is, but I would be open to shipping with a prefix if
people thought that would ease pain in the eventual transition.
No. Nonononononononono.
This is the conventional wisdom. Prefixes end up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/2015 03:48 PM, Richard Barnes wrote:
> I think we would treat this just like we treat other early-stage
> things that get shipped, gradually turning it off when the real
> thing shows up.
That would mean only shipping it on Nightly and maybe
On Wed, Dec 2, 2015 at 12:25 AM, wrote:
> On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:
> > Oh well. Bummer.
> >
> > / Jonas
>
> If it cheers you up any, the 2.0 API that replaces the U2F API uses
> promises - http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:
> Oh well. Bummer.
>
> / Jonas
If it cheers you up any, the 2.0 API that replaces the U2F API uses promises -
http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
Richard, it would help if you could clarify - are yo
Oh well. Bummer.
/ Jonas
On Tue, Dec 1, 2015 at 5:36 PM, Richard Barnes wrote:
> It's my understanding that U2F qua U2F is considered pretty much baked by
> the developer community, and there's already code written to it. But these
> concerns will be great for the W3C group and the successor AP
It's my understanding that U2F qua U2F is considered pretty much baked by
the developer community, and there's already code written to it. But these
concerns will be great for the W3C group and the successor API. I've got a
similar list started related to crypto and future-proofing.
On Tue, Dec
Any chance that the API can be made a little more JS friendly? First
thing that stands out is the use of success/error callbacks rather
than the use of Promises.
Also the use of numeric codes, rather than string values, is a pattern
that the web has generally moved away from.
/ Jonas
On Tue, Dec
The FIDO Alliance has been developing standards for hardware-based
authentication of users by websites [1]. Their work is getting significant
traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
Work has begun in the W3C to create open standards using FIDO as a starting
point
On Fri, Nov 20, 2015 at 9:49 AM, Jonas Sicking wrote:
> I'd be quite happy if someone else would :)
Filed https://github.com/w3c/hr-time/issues/22 on the general nested
worker problem. Filed https://github.com/w3c/hr-time/issues/23 on the
Client object thing.
--
https://annevankesteren.nl/
___
On Thu, Nov 19, 2015 at 5:38 PM, Boris Zbarsky wrote:
>> Though Service Workers do actually have a 'client' object which
>> represent window objects. So we could enable passing those as global
>> to the translate function.
>
> That's a good idea. Want to raise it with the webperf WG? Seems like
On 11/19/15 6:57 PM, Jonas Sicking wrote:
You can actually create a MessageChannel and then send one of the
ports to a sub-sub-worker.
Ah, good point.
Unfortunately the other port can't be used as something that
represents the sub-sub-worker since even after a port has started
getting used, i
On Thu, Nov 19, 2015 at 2:48 PM, Boris Zbarsky wrote:
> On 11/19/15 5:39 PM, Jonas Sicking wrote:
>>
>> This API doesn't seem to work for nested workers (which Blink doesn't
>> implement), does it? Since there's no way in the window to get hold of
>> a reference of a sub-sub-worker.
>
> While true
On 11/19/15 5:39 PM, Jonas Sicking wrote:
This API doesn't seem to work for nested workers (which Blink doesn't
implement), does it? Since there's no way in the window to get hold of
a reference of a sub-sub-worker.
While true, there is also no way to directly get a message from a
sub-sub-work
This API doesn't seem to work for nested workers (which Blink doesn't
implement), does it? Since there's no way in the window to get hold of
a reference of a sub-sub-worker.
It also doesn't seem possible for a worker to convert to the timeline
of a parent window, since there's no object representi
Summary: A new method on Performance that allows translating a timestamp
from one timeline to another. The idea is that you can take a
performance.now() value or performance mark from some other global and
convert them to the timeline of your global. It works like this:
var myTime = Perfor
Summary: Currently for a dedicated worker, we set its 0 time for
performance.now() purposes to the zero time of its parent worker or
window. The spec defines a different behavior, now that there is a spec
for this. Consumers that rely on the timebases matching right now can
use translateTime
Summary: It implements emphasis marks which are symbols next to each
character to emphasize a piece of text. It is mainly used in East
Asian documents.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1225012
Link to standard: https://drafts.csswg.org/css-text-decor-3/#emphasis-marks
Platform c
On 10/20/15 6:12 AM, Jonas Sicking wrote:
On Tue, Oct 20, 2015 at 2:49 AM, Mounir Lamouri wrote:
Should we add this to the Screen Orientation specification?
I think so yes.
I also think so. In my mind the Compat Standard should be transitional
in nature, rather than something we maintain f
On Tue, Oct 20, 2015 at 2:49 AM, Mounir Lamouri wrote:
> Should we add this to the Screen Orientation specification?
I think so yes.
/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
FWIW, this is the usage of window.orientation in the wild recorded by
Chrome:
https://www.chromestatus.com/metrics/feature/timeline/popularity/285
However, Google's internal tools allow me to see the repartition between
platforms and this seen a lot by Chrome Android users.
Should we add this to
As someone pushing for the ScreenOrientation API, I agree with this
intent nonetheless.
It *might* be worth warning about this property being inconsistent,
and that it's better for users to use the ScreenOrientation API. But I
think it's really only worth doing if this is something that other
brow
*Summary*: window.orientation returns a value corresponding to the screen
orientation. The orientationchange event is fired when the orientation of
the viewport is changed. These features are non-standard but have been
implemented by other browser vendors on mobile platforms leading to
widespread u
On Tue, Oct 20, 2015 at 1:18 AM, Ms2ger wrote:
> Please submit tests to web-platform-tests and create a pull request to
> the HTML standard.
>
Will do, after a decent interval to collect feedback. I wrote
web-platform-tests to land with our implementation.
Rob
--
lbir ye,ea yer.tnietoehr rdn
On 10/19/15 12:46 PM, Anne van Kesteren wrote:
On Mon, Oct 19, 2015 at 6:36 PM, Boris Zbarsky wrote:
Summary: The web more or less depends on one of the prefixed versions of
matchesSelector (being implemented).
I think you mean matches() is being implemented, while the web depends
on a prefix
On Mon, Oct 19, 2015 at 6:36 PM, Boris Zbarsky wrote:
> Summary: The web more or less depends on one of the prefixed versions of
> matchesSelector (being implemented).
I think you mean matches() is being implemented, while the web depends
on a prefixed version of matchesSelector(). matches() and
Summary: The web more or less depends on one of the prefixed versions of
matchesSelector (being implemented). We might as well implement the
webkit one and drop the moz one.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1216193
Standard: https://dom.spec.whatwg.org/#dom-element-webkitmatc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/19/2015 06:02 AM, Robert O'Callahan wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=264412
>
> Webkit, Blink and Trident have been shipping this for years without
> a spec and with poor interop. We held off on implementing it since
> you c
https://bugzilla.mozilla.org/show_bug.cgi?id=264412
Webkit, Blink and Trident have been shipping this for years without a spec
and with poor interop. We held off on implementing it since you can
polyfill a better implementation in JS without much difficulty, but we have
to implement something for
On Sun, Oct 18, 2015 at 12:59 AM, Jean-Yves Perrier wrote:
> On 16/10/2015 02:39, Xidorn Quan wrote:
>
>> Blink has shipped this pseudo-element unprefixed for modal
>> element (but not yet for fullscreen)
>>
> I have a side question here: do we plan to support ::backdrop for modal
> in the futur
On 16/10/2015 02:39, Xidorn Quan wrote:
Blink has shipped this pseudo-element unprefixed for modal
element (but not yet for fullscreen)
I have a side question here: do we plan to support ::backdrop for modal
in the future, or is it a Blink oddity.
--
Jean-Yves Perrier
Senior St. Project Ma
Summary: This pseudo-element is rendered immediately below every
fullscreen element, and covers the other part of the document by
default. This is part of the effort to update our Fullscreen API
implementation to the latest spec. And it is the last non-trivial part
before I'm going to unprefix the
On Wed, 2 Sep 2015, at 03:50, Ehsan Akhgari wrote:
> On 2015-09-01 9:57 PM, Jonas Sicking wrote:
> > But I agree that we should make it clear that we do not intend to
> > implement a request API.
>
> There is actually a valid use case for a request API. It has become
> clear that we need to expo
On 2015-09-01 9:57 PM, Jonas Sicking wrote:
But I agree that we should make it clear that we do not intend to
implement a request API.
There is actually a valid use case for a request API. It has become
clear that we need to expose pasting functionality to the Web, and the
most natural way o
On Mon, Aug 24, 2015 at 11:57 PM, Anne van Kesteren wrote:
> On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas
> wrote:
>> Summary: The Permissions API allows a web application to be aware of
>> the status of a given permission, to know whether it is granted,
>> denied or if the user will be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/2015 03:36 PM, Ehsan Akhgari wrote:
> Hmm, I see. Have you considered the implications of making the
> alias falsey in conditions, similar to document.all?
No. No. Nononononono.
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJV3dq3AAoJ
401 - 500 of 748 matches
Mail list logo
