Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On Fri, Apr 10, 2015 at 7:15 PM, Boris Zbarsky wrote: > On 4/10/15 7:43 PM, Jonas Sicking wrote: >> >> One option is to make the xpidl interface always return a File, but >> make the .webidl interface return files or blobs. > > Why, exactly? If we want to do this, just have them both return a Blo

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On 4/10/15 10:15 PM, Boris Zbarsky wrote: I'm more worried about internal C++ consumers, honestly. Have to audit them all to make sure they're not assuming they can get a filename and such. For example, HTMLInputElement::GetValueInternal or HTMLInputElement::AfterSetFiles will do mFiles[0]->G

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On 4/10/15 7:43 PM, Jonas Sicking wrote: One option is to make the xpidl interface always return a File, but make the .webidl interface return files or blobs. Why, exactly? If we want to do this, just have them both return a Blob in terms of the IDL. If it happens to be a Blob that's also a

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On Fri, Apr 10, 2015 at 4:31 PM, Boris Zbarsky wrote: > On 4/10/15 6:23 PM, Jonas Sicking wrote: >> >> Is there a reason to upgrade to File? > > Yes. FileList claims to return Files. > > We could change that to have it return Blobs, of course, and then make sure > that various consumers (at least

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On 4/10/15 6:23 PM, Jonas Sicking wrote: Is there a reason to upgrade to File? Yes. FileList claims to return Files. We could change that to have it return Blobs, of course, and then make sure that various consumers (at least the internal ones) can deal. -Boris

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On Fri, Apr 10, 2015 at 11:24 AM, Boris Zbarsky wrote: > 1) The setter treats its single argument as a sequence. Any Blobs > that are not already Files get upgraded to Files, identical to how > https://xhr.spec.whatwg.org/#create-an-entry behaves. Is there a reason to upgrade to File? I thought

Re: Intent to Implement and Ship: UI Events (formerly DOM Level 3 Events) EventModifierInit

On 2015/04/09 16:41, Ms2ger wrote: What are other browsers planning to do? Not sure. We're the first implementer around new KeyboardEvent. > Do we have any tests in wpt that could show interop? I think, no. I don't know if tests of DOM Level 3 Events are included in wpt. (of course, mochites

Re: Intent to Implement and Ship: UI Events (formerly DOM Level 3 Events) EventModifierInit

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2015 03:27 AM, Masayuki Nakano wrote: > EventModifierInit is a dictionary to initialize modifier state at > creating untrusted event. This allows to initialize "AltGraph", > "CapsLock", "Fn", "FnLock", "Hyper", "NumLock", "OS", > "ScrollLoc

Intent to Implement and Ship: UI Events (formerly DOM Level 3 Events) EventModifierInit

EventModifierInit is a dictionary to initialize modifier state at creating untrusted event. This allows to initialize "AltGraph", "CapsLock", "Fn", "FnLock", "Hyper", "NumLock", "OS", "ScrollLock", "Super", "Symbol" and "SymboleLock" state of creating events and it has been no way to initializ

Re: Intent to implement and ship: document.origin

On 3/19/15 3:16 AM, Anne van Kesteren wrote: That is in our implementation Yes, because it was a security bug as specified, iirc. Of course no one else implements searchParams at all, or plans to. But as long as we're talking implementations, last I checked no one else even implemented URLUt

Re: Intent to implement and ship: document.origin

>>> I think it would be weird if the >>> invariants that hold for and new URL() don't hold for Location. >> >> That's already the case for tons of invariants. > > I don't think so. The various component attributes all return what you'd > expect. I still think the value added by making window.loc

Re: Intent to implement and ship: document.origin

On Wed, Mar 18, 2015 at 2:18 PM, Boris Zbarsky wrote: > On 3/18/15 2:39 AM, Anne van Kesteren wrote: >> Other than the location object tracking a URL you might not expect > > And not having .searchParams. That is in our implementation and still an outstanding issue in the specification. > And h

Re: Intent to implement and ship: document.origin

On 3/18/15 2:39 AM, Anne van Kesteren wrote: On Wed, Mar 18, 2015 at 1:09 AM, Jonas Sicking wrote: I think making the location object match URLUtils is futile. There's so much weirdness about the location object that I think we should treat it as the special flower that it is. Other than the

Re: Intent to implement and ship: document.origin

On Wed, Mar 18, 2015 at 1:09 AM, Jonas Sicking wrote: > I think making the location object match URLUtils is futile. There's > so much weirdness about the location object that I think we should > treat it as the special flower that it is. Other than the location object tracking a URL you might no

Re: Intent to implement and ship: document.origin

Pinging this old thread since nothing seems to have happened since it was last discussed. My recommendation is still to make location.origin return the "origin of the document" rather than "the origin of the URL". I would be surprised if that didn't fix many more pages than it broke. I think maki

Re: Intent to implement and ship extended FormData methods

On Thursday, January 29, 2015 at 4:57:00 PM UTC-5, nsm.n...@gmail.com wrote: > Summary: FormData[1] has been an append only interface since it was > introduced. The WHATWG version of the XHR spec added several methods to > has/get/set/delete on the entries and introduced iteration support. This p

Intent to implement and ship: vertical text support (CSS writing-mode and related properties)

We are working on support for v e r t i c a l text in Gecko. This will allow web content (and eventually complete web apps, if desired) to use vertical writing, as traditionally used in East Asia. In addition to the CSS writing-mode property, this will involve support for te

Re: Intent to implement and ship FormData on workers

On Fri, Jan 30, 2015 at 7:13 AM, Boris Zbarsky wrote: > On 1/30/15 1:30 AM, nsm.nik...@gmail.com wrote: >> >> Well my work on getting FormData on workers was because Fetch uses it, and >> there doesn't seem to have been demand for it on workers before. > > > That's fair, but it seems like exposing

Re: Intent to implement and ship extended FormData methods

On 1/30/15 1:25 AM, nsm.nik...@gmail.com wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=1127703 Thanks. The fetch spec states that FormData is immediately serialized when send() is called (send defers to Fetch's "extract body" routine) https://fetch.spec.whatwg.org/#concept-bodyinit-ex

Re: Intent to implement and ship FormData on workers

On 1/30/15 1:30 AM, nsm.nik...@gmail.com wrote: Well my work on getting FormData on workers was because Fetch uses it, and there doesn't seem to have been demand for it on workers before. That's fair, but it seems like exposing it separately, if it's going to be ready before the rest of Fetch

Re: Intent to implement and ship FormData on workers

On Thursday, January 29, 2015 at 6:41:53 PM UTC-8, Boris Zbarsky wrote: > On 1/29/15 5:10 PM, nsm.nik...@gmail.com wrote: > > Pref: I intend to hide this behind dom.fetch.enabled, which also controls > > the Fetch specification. > > May I ask why? This seems like a totally reasonable thing to ex

Re: Intent to implement and ship extended FormData methods

On Thursday, January 29, 2015 at 6:39:22 PM UTC-8, Boris Zbarsky wrote: > On 1/29/15 4:56 PM, nsm.nik...@gmail.com wrote: > > The proposed patch does not add iterator support. > > Is there a bug tracking adding this? https://bugzilla.mozilla.org/show_bug.cgi?id=1127703 > > > https://xhr.spec.wh

Re: Intent to implement and ship FormData on workers

On 1/29/15 5:10 PM, nsm.nik...@gmail.com wrote: Pref: I intend to hide this behind dom.fetch.enabled, which also controls the Fetch specification. May I ask why? This seems like a totally reasonable thing to expose independently of Fetch, and might be good to have it in a release before Fet

Re: Intent to implement and ship extended FormData methods

On 1/29/15 4:56 PM, nsm.nik...@gmail.com wrote: The proposed patch does not add iterator support. Is there a bug tracking adding this? https://xhr.spec.whatwg.org/#interface-formdata I assume something defines what happens if you delete() while sending the formdata and that we implement wh

Re: Intent to implement and ship FormData on workers

On Fri, Jan 30, 2015 at 8:34 AM, Xidorn Quan wrote: > Personally, I don't think it needs to be hidden behind a pref. Given that > FormData has been exposed on window, and the usage is mostly identical, I > suggest it be shipped directly. > > - Xidorn > > On Fri, Jan 30, 2015 at 9:10 AM, wrote: >

Re: Intent to implement and ship FormData on workers

Personally, I don't think it needs to be hidden behind a pref. Given that FormData has been exposed on window, and the usage is mostly identical, I suggest it be shipped directly. - Xidorn On Fri, Jan 30, 2015 at 9:10 AM, wrote: > Summary: The FormData interface allows sending forms directly vi

Intent to implement and ship FormData on workers

Summary: The FormData interface allows sending forms directly via XHR. It has previously been exposed on window. This intent is to expose it on workers and allow the same usage, i.e: - Creating FormData objects and adding string values or blobs to them - Sending FormData objects via a call to xhr

Intent to implement and ship extended FormData methods

Summary: FormData[1] has been an append only interface since it was introduced. The WHATWG version of the XHR spec added several methods to has/get/set/delete on the entries and introduced iteration support. This puts it in the same class as URLSearchParams and Headers. The proposed patch does

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

I feel a lot less embarrassed about not finding that bug number now that I know how long this thread has been running. :) Eric Shepherd Developer Documentation Lead Mozilla http://www.bitstampede.com/ > On Dec 30, 2014, at 12:25 PM, L. David Baron wrote: > > From the message at the start of th

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

On Tuesday 2014-12-30 12:14 -0500, Eric Shepherd wrote: > Is there a bug for the changes being discussed here, and is it marked with > dev-doc-needed? Sounds like there will be, at a minimum, a few tweaks to the > discussion about how this stuff works. From the message at the start of the thread

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

Is there a bug for the changes being discussed here, and is it marked with dev-doc-needed? Sounds like there will be, at a minimum, a few tweaks to the discussion about how this stuff works. Thanks! Eric Shepherd Developer Documentation Lead Mozilla http://www.bitstampede.com/ > On Dec 27, 20

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

On Sunday 2014-12-28 03:04 +0900, Michael[tm] Smith wrote: > So as long as the spec is going to require UAs to resort to magic behavior, > I think the magic could instead just be "autohide any ruby annotations for > kana characters". And then you could just have simpler markup like this: > > 振り仮

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

On Sun, Dec 28, 2014 at 5:04 AM, Michael[tm] Smith wrote: > Xidorn Quan , 2014-12-27 10:12 +1100: > > > On Sat, Dec 27, 2014 at 12:23 AM, Michael[tm] Smith wrote: > ... > > > Xidorn Quan , 2014-12-26 04:41 -0800: > > > ... > > > > The difference in expression ability becomes more important when

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

On 2014/12/28 3:04, Michael[tm] Smith wrote: > Further, I don't know of any typical case where if a base character > is kana, why you'd ever want to display furigana/yomigana for it. Ruby is not used only for furigana/yomigana. I know one example from a very popular Japanese novel: 赤眼の魔王ルビーアイ Th

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

Xidorn Quan , 2014-12-27 10:12 +1100: > On Sat, Dec 27, 2014 at 12:23 AM, Michael[tm] Smith wrote: ... > > Xidorn Quan , 2014-12-26 04:41 -0800: > > ... > > > The difference in expression ability becomes more important when there > > > are words mixed with kanji and kana, such as "振り仮名". For this

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

On Sat, Dec 27, 2014 at 12:23 AM, Michael[tm] Smith wrote: > Hi Xidorn, > > Xidorn Quan , 2014-12-26 04:41 -0800: > ... > > If you want the word "明朝体" to be marked in ruby in separate form, with > > the WHATWG rules, you must write it as: > > > > 明みん朝ちょう体たい > > > > It is incompatible with the

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

Hi Xidorn, Xidorn Quan , 2014-12-26 04:41 -0800: ... > If you want the word "明朝体" to be marked in ruby in separate form, with > the WHATWG rules, you must write it as: > > 明みん朝ちょう体たい > > It is incompatible with the inline form, which means, if an author wants > to switch between the inline f

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

On Tuesday, July 8, 2014 3:34:50 AM UTC+10, ian.h...@gmail.com wrote: > On Tuesday, July 1, 2014 12:58:45 PM UTC-7, Koji Ishii wrote: > > Summary: > > > > Two recent HTML changes improve ruby support: > > > > 1) Addition of the rb and rtc elements (but not rbc); and > > > > 2) Matching update to

Re: Intent to implement and ship: document.origin

On Wed, Dec 3, 2014 at 7:58 AM, Boris Zbarsky wrote: > Indeed. Bringing us back to "why would someone ever care about the latter?" I don't think you should use that unless you want to know the origin of the URL of the corresponding href in question. E.g. similar to why you might want to inspect

Re: Intent to implement and ship: document.origin

On 12/3/14, 6:30 AM, Anne van Kesteren wrote: Correct. I thought that was added a long time ago. location.origin has existed in Firefox since Firefox 21, I guess (and Firefox 29 for Workers). I guess that does make it hard to remove. That sucks. :( Anyway, the difference between a docume

Re: Intent to implement and ship: document.origin

> On 2014-12-03, at 02:50, Boris Zbarsky wrote: > > I can't think of sane use cases for location.origin. Afaict the only reason > it's on there is that all URLUtils things have a .origin... I think that you will find that there are a few uses of location.origin already. I’m willing to bet t

Re: Intent to implement and ship: document.origin

On Wed, Dec 3, 2014 at 11:50 AM, Boris Zbarsky wrote: > I can't think of sane use cases for location.origin. Afaict the only reason > it's on there is that all URLUtils things have a .origin... Correct. I thought that was added a long time ago. Anyway, the difference between a document's origin

Re: Intent to implement and ship: document.origin

On 12/3/14, 2:28 AM, Jonas Sicking wrote: This difference seems really esoteric to me. Do we really expect developers to understand this difference and use the right one? Especially given the very similar names? I don't. Hence my proposal to remove location.origin. Are there use cases for bo

Re: Intent to implement and ship: document.origin

On Dec 2, 2014 1:41 PM, "Boris Zbarsky" wrote: > > On 12/2/14, 8:17 AM, Kevin Grandon wrote: >> >> We currently use location.origin quite frequently in gaia, and we also use it in workers. > > > So the difference between location.origin and document.origin is that the latter is the origin of the d

Re: Intent to implement and ship: document.origin

On 12/2/14, 8:17 AM, Kevin Grandon wrote: We currently use location.origin quite frequently in gaia, and we also use it in workers. So the difference between location.origin and document.origin is that the latter is the origin of the document and the former is the origin of the document's UR

Re: Intent to implement and ship: document.origin

first glance something like `location.documentOrigin` would make more sense to me - then we could use it in workers I assume? Best, Kevin - Original Message - From: "Mounir Lamouri" To: dev-platform@lists.mozilla.org Sent: Tuesday, December 2, 2014 3:43:08 AM Subject: Re: Inte

Re: Intent to implement and ship: document.origin

On Tue, 2 Dec 2014, at 02:09, Boris Zbarsky wrote: > Summary: document.origin returns the Unicode serialization of the > document's origin. The returned value does not depend on what > document.domain was set to. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=931884 > > Spec: http://dom

Intent to implement and ship: document.origin

Summary: document.origin returns the Unicode serialization of the document's origin. The returned value does not depend on what document.domain was set to. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=931884 Spec: http://dom.spec.whatwg.org/#dom-document-origin Platform coverage: All of

Re: Intent to implement and ship: StereoPannerNode

This looks good to me! On 2014-11-26 5:14 PM, Paul Adenot wrote: Summary: This is a new Web Audio API node that allows authors to simply pan a sound source in a 2d space (left/right). Rational for inclusion in the standard are outlined in blink-dev [0] (look for the second message from me there)

Intent to implement and ship: StereoPannerNode

Summary: This is a new Web Audio API node that allows authors to simply pan a sound source in a 2d space (left/right). Rational for inclusion in the standard are outlined in blink-dev [0] (look for the second message from me there) and on the spec bug [1], but to summarize, it's a first step toward

Re: Intent to implement and ship: DOMRequest.then

On Sep 27, 2014 12:57 PM, "David Rajchenbach-Teller" wrote: > > Speaking only for myself: I have been waiting for this for, well, > basically since IndexedDB landed. I am a bit worried by this being > Mozilla-specific, though. > > If my memory serves, W3C specifies the IDBRequest interface which,

Re: Intent to implement and ship: DOMRequest.then

Speaking only for myself: I have been waiting for this for, well, basically since IndexedDB landed. I am a bit worried by this being Mozilla-specific, though. If my memory serves, W3C specifies the IDBRequest interface which, in the scope of IndexedDB, is essentially the same as DOMRequest. Is thi

Intent to implement and ship: DOMRequest.then

Summary: DOMRequest is an API that we implemented before DOM promises were available, and it is superseded by Promise. It is, however, incompatible with the Promise API in three main ways: its API surface is completely different, it uses DOM events to dispatch success/error events, and its events

Re: Restricting gUM to authenticated origins only (was: Re: Intent to implement and ship: ImageCapture)

On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen wrote: > On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan > wrote: > > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen > wrote: > >> Is current gUM restricted to authenticated origins? If it isn't, is it > >> realistic to restrict it to authenticate

Re: Restricting gUM to authenticated origins only (was: Re: Intent to implement and ship: ImageCapture)

On Fri, Sep 5, 2014 at 1:47 PM, Robert O'Callahan wrote: > On Fri, Sep 5, 2014 at 10:34 PM, Henri Sivonen wrote: >> >> On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan >> wrote: >> > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen >> > wrote: >> >> Is current gUM restricted to authenticated ori

Re: Restricting gUM to authenticated origins only (was: Re: Intent to implement and ship: ImageCapture)

On Fri, Sep 5, 2014 at 10:34 PM, Henri Sivonen wrote: > On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan > wrote: > > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen > wrote: > >> Is current gUM restricted to authenticated origins? If it isn't, is it > >> realistic to restrict it to authenticat

Restricting gUM to authenticated origins only (was: Re: Intent to implement and ship: ImageCapture)

On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan wrote: > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen wrote: >> Is current gUM restricted to authenticated origins? If it isn't, is it >> realistic to restrict it to authenticated origins? > > That's a good idea but it's a separate issue. Is it

Re: Intent to implement and ship: ImageCapture

On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen wrote: > Does this have the same privacy protections as current gUM? > Yes. You can only use this on a stream you've already acquired (e.g. via current gUM, but other APIs also produce streams). You can already shunt a MediaStream to a element and

Re: Intent to implement and ship: ImageCapture

On Wed, Sep 3, 2014 at 12:15 PM, Alfredo Yang wrote: > Summary: > Allow web authors to take photo via gUM video track. Does this have the same privacy protections as current gUM? Is current gUM restricted to authenticated origins? If it isn't, is it realistic to restrict it to authenticated orig

Re: Intent to implement and ship: ImageCapture

On Fri, Sep 5, 2014 at 11:58 AM, Jonas Sicking wrote: > On Thu, Sep 4, 2014 at 4:45 PM, Robert O'Callahan > wrote: > > On Fri, Sep 5, 2014 at 11:39 AM, Jonas Sicking wrote: > >> Looking at the API though, why is it based on Events rather than > >> Promises? > > > > > http://w3c.github.io/mediac

Re: Intent to implement and ship: ImageCapture

On Thu, Sep 4, 2014 at 4:45 PM, Robert O'Callahan wrote: > On Fri, Sep 5, 2014 at 11:39 AM, Jonas Sicking wrote: >> Looking at the API though, why is it based on Events rather than >> Promises? > > http://w3c.github.io/mediacapture-image/#promise-extensions-to-imagecapture That seems super stran

Re: Intent to implement and ship: ImageCapture

On Fri, Sep 5, 2014 at 11:39 AM, Jonas Sicking wrote: > Ooh, that is great! Though surprisingly the API doesn't seem to have > any support for focus or flash control? Was that intentionally left > out? > I think it's just a case of not wanting the spec to get too far ahead of implementations. L

Re: Intent to implement and ship: ImageCapture

On Thu, Sep 4, 2014 at 4:22 PM, Robert O'Callahan wrote: > On Fri, Sep 5, 2014 at 11:01 AM, Jonas Sicking wrote: >> >> What's the use case here? Note that in order to build even a >> half-decent camera app just for taking selfies you need some amount of >> control over of focus. For more advanced

Re: Intent to implement and ship: ImageCapture

On Fri, Sep 5, 2014 at 11:01 AM, Jonas Sicking wrote: > What's the use case here? Note that in order to build even a > half-decent camera app just for taking selfies you need some amount of > control over of focus. For more advanced camera apps you also want > control over backlight compensation,

Re: Intent to implement and ship: ImageCapture

On Wed, Sep 3, 2014 at 2:15 AM, Alfredo Yang wrote: > Summary: > Allow web authors to take photo via gUM video track. > > Bug: > Main tracking bug, https://bugzilla.mozilla.org/show_bug.cgi?id=888177 > > Spec: > https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/ImageCapture.html > >

Re: Intent to implement and ship: ImageCapture

I've been steering the underlying ICameraControl implementation (dom/camera) towards better support for ImageCapture's usage model for a while. If we can fill in support for the missing features we currently use (see CameraCapabilities.webidl) then I

Re: Intent to implement and ship: ImageCapture

It seems like this API addresses at least some of the use cases of our Camera API for Firefox OS (things such as being able to display a preview video stream, being able to adjust some picture quality parameters, etc.). I am wondering if you know how much of the Camera API use cases this is g

Intent to implement and ship: ImageCapture

Summary: Allow web authors to take photo via gUM video track. Bug: Main tracking bug, https://bugzilla.mozilla.org/show_bug.cgi?id=888177 Spec: https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/ImageCapture.html Platform coverage: All platforms. Target release: late 2014. Pref:

Intent to implement and ship: Element.matches

Summary: This is an unprefixed form of Element.mozMatchesSelector, which we've been shipping for a long time. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=886308 Link to standard: http://dom.spec.whatwg.org/#dom-element-matches (though note

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

On Tuesday, July 1, 2014 12:58:45 PM UTC-7, Koji Ishii wrote: > Summary: > > Two recent HTML changes improve ruby support: > > 1) Addition of the rb and rtc elements (but not rbc); and > > 2) Matching update to the tag omission rules to make ruby authoring easier. > > By implementing these chan

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

On Wednesday 2014-07-02 10:05 +0300, Henri Sivonen wrote: > On Tue, Jul 1, 2014 at 10:58 PM, Koji Ishii wrote: > > Platform coverage: all platforms (parsing only, layout will be in separate > > intents) > > The parsing change is the easy part. Is there a plan to get the layout > part implemented

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

On 02/07/14 17:05, Henri Sivonen wrote: On Tue, Jul 1, 2014 at 10:58 PM, Koji Ishii wrote: Platform coverage: all platforms (parsing only, layout will be in separate intents) The parsing change is the easy part. Is there a plan to get the layout part implemented? My general take on this iss

Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

On Tue, Jul 1, 2014 at 10:58 PM, Koji Ishii wrote: > Platform coverage: all platforms (parsing only, layout will be in separate > intents) The parsing change is the easy part. Is there a plan to get the layout part implemented? My general take on this issue is: 1) As far as assigning the time

Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules

Summary: Two recent HTML changes improve ruby support: 1) Addition of the rb and rtc elements (but not rbc); and 2) Matching update to the tag omission rules to make ruby authoring easier. By implementing these changes, Gecko supports the parsing side of all the ruby use cases required for the int

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 21.05.2014 01:27, Rik Cabanier wrote: Likewise here. I don't think anyone is saying that "hardwareConcurrency" is failing on the grounds of exposing too much system information alone. The way I read this thread, people either aren't convinced that it's the right compromise given its usefulness

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 4:16 PM, Daniel Holbert wrote: > On 05/20/2014 04:06 PM, Daniel Holbert wrote: > > On 05/20/2014 03:50 PM, Rik Cabanier wrote: > >> I agree that there's a risk since this will make it super easy to get to > >> the core count. > >> I don't have the exact number but I suspect

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 5:20 AM, Benoit Jacob wrote: > > > > 2014-05-19 23:37 GMT-04:00 Rik Cabanier : > > >> >> >> On Mon, May 19, 2014 at 6:46 PM, Benoit Jacob >> wrote: >> >>> +1000! Thanks for articulating so clearly the difference between the >>> Web-as-an-application-platform and other appl

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 05/20/2014 04:06 PM, Daniel Holbert wrote: > On 05/20/2014 03:50 PM, Rik Cabanier wrote: >> I agree that there's a risk since this will make it super easy to get to >> the core count. >> I don't have the exact number but I suspect that very few machines will >> have more than 8 cores which makes

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 05/20/2014 03:50 PM, Rik Cabanier wrote: > I agree that there's a risk since this will make it super easy to get to > the core count. > I don't have the exact number but I suspect that very few machines will > have more than 8 cores which makes them valuable for targeted marketing. (To be clear

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 11:10 AM, Gavin Sharp wrote: > On Tue, May 20, 2014 at 10:46 AM, Eli Grey wrote: > >> Gavin: The fingerprinting entropy exposed by Rik's patch is actual >> *magnitudes* less than the entropy exposed on >> http://renderingpipeline.com/webgl-extension-viewer/ >> > I didn't

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 3:26 PM, Daniel Holbert wrote: > On 05/20/2014 03:13 PM, Rik Cabanier wrote: > > On Tue, May 20, 2014 at 9:16 AM, Gavin Sharp > wrote: > >> Arguing that the incremental fingerprinting risk > >> is negligible is reasonable, but you lose credibility if you suggest > >> it do

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 6:22 AM, Joshua Cranmer 🐧 wrote: > On 5/20/2014 1:02 AM, Rik Cabanier wrote: > >> That is unlikely. The OS scheduler (I assume that will still exist), will >> take care of that problem. At the end, more work will be done which is all >> we're looking after. >> > > I'm not s

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 05/20/2014 03:13 PM, Rik Cabanier wrote: > On Tue, May 20, 2014 at 9:16 AM, Gavin Sharp wrote: >> Arguing that the incremental fingerprinting risk >> is negligible is reasonable, but you lose credibility if you suggest >> it doesn't exist. > > > I don't follow. Where did I say that the finger

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 9:16 AM, Gavin Sharp wrote: > I think it might help your case to acknowledge the often significant > difference between "technically possible, but expensive and > unreliable" and "extremely simple and 100% reliable". That something > is already technically possible does no

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/20/2014 1:58 PM, Eli Grey wrote: In practice, this is what parallel applications *currently* do as they have no other choice without this API. The OS scheduler can handle balancing the load fine to keep your system responsive, but it can't optimize your algorithm to more efficiently take adv

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 2:10 PM, Joshua Cranmer 🐧 wrote: > And it also presumes that all of the CPUs are going to be more or less > available Please clarify what you are referring to by "more or less available". "more or less" makes me think you're referring to a fractional value, such as load.

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 10:46 AM, Eli Grey wrote: > Gavin: The fingerprinting entropy exposed by Rik's patch is actual > *magnitudes* less than the entropy exposed on > http://renderingpipeline.com/webgl-extension-viewer/ > I didn't claim otherwise - personally I don't think the fingerprinting ar

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/20/2014 12:46 PM, Eli Grey wrote: Your worker threadpool will always stay the same size, but it will have different performance characteristics throughout it's lifetime based on varying system load. This is okay. The OS scheduler balances your load with everything else. If you want constant

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-15, 4:26 AM, Rik Cabanier wrote: On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2014-05-13, 9:01 PM, Rik Cabanier wrote: ... The problem is that the API doesn't really make it obvious that you're no

Re: Intent to implement and ship: navigator.hardwareConcurrency

Gavin: The fingerprinting entropy exposed by Rik's patch is actual *magnitudes* less than the entropy exposed on http://renderingpipeline.com/webgl-extension-viewer/ I don't need the extra less-than-a-bit of entropy from my proposal to reliably fingerprint you, as the above URL + Panopticlick is a

Re: Intent to implement and ship: navigator.hardwareConcurrency

I think it might help your case to acknowledge the often significant difference between "technically possible, but expensive and unreliable" and "extremely simple and 100% reliable". That something is already technically possible does not mean that making it easier has no consequences. Arguing that

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/20/2014 1:02 AM, Rik Cabanier wrote: That is unlikely. The OS scheduler (I assume that will still exist), will take care of that problem. At the end, more work will be done which is all we're looking after. I'm not sure what you're trying to argue any more. When pointed out that the not

Re: Intent to implement and ship: navigator.hardwareConcurrency

2014-05-19 23:37 GMT-04:00 Rik Cabanier : > > > > On Mon, May 19, 2014 at 6:46 PM, Benoit Jacob wrote: > >> +1000! Thanks for articulating so clearly the difference between the >> Web-as-an-application-platform and other application platforms. >> > > It really surprises me that you would make this

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 12:29 AM, Jonas Sicking wrote: > On Mon, May 19, 2014 at 8:14 PM, Rik Cabanier wrote: > > On Mon, May 19, 2014 at 6:35 PM, Jonas Sicking wrote: > >> > >> On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier > wrote: > >> > I don't see why the web platform is special here and w

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 12:24 AM, Jonas Sicking wrote: > On Mon, May 19, 2014 at 7:14 PM, Mike Hommey wrote: > > On Mon, May 19, 2014 at 06:35:49PM -0700, Jonas Sicking wrote: > >> On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier > wrote: > >> > I don't see why the web platform is special here and

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 8:14 PM, Rik Cabanier wrote: > On Mon, May 19, 2014 at 6:35 PM, Jonas Sicking wrote: >> >> On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier wrote: >> > I don't see why the web platform is special here and we should trust >> > that >> > authors can do the right thing. >> >> I

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 7:14 PM, Mike Hommey wrote: > On Mon, May 19, 2014 at 06:35:49PM -0700, Jonas Sicking wrote: >> On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier wrote: >> > I don't see why the web platform is special here and we should trust that >> > authors can do the right thing. >> >> I'

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 9:32 PM, Joshua Cranmer 🐧 wrote: > On 5/19/2014 6:10 PM, Rik Cabanier wrote: > >> Other platforms offer an API to the number of CPU's and they are able to >> use it successfully. (see the ten of thousands of examples on GitHub) I >> don't see why the web platform is special

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/19/2014 6:10 PM, Rik Cabanier wrote: Other platforms offer an API to the number of CPU's and they are able to use it successfully. (see the ten of thousands of examples on GitHub) I don't see why the web platform is special here and we should trust that authors can do the right thing. By

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 6:46 PM, Benoit Jacob wrote: > +1000! Thanks for articulating so clearly the difference between the > Web-as-an-application-platform and other application platforms. > It really surprises me that you would make this objection. WebGL certainly would *not* fall into this "We

<    2   3   4   5   6   7   8   >