Re: Should MutationObservers be able to observe work done by the HTML parser?
On Tue, Jun 19, 2012 at 10:52 PM, Olli Pettay olli.pet...@helsinki.fi wrote: end-of-microtask or end-of-task everywhere. And yes, some parsing / networking details may unfortunately be exposed, but in a way which should be quite random. Web devs just can't really rely on network packages to be delivered to parser in some exact way. I think the original solution we had to not expose parser mutations was better. Exposing this can lead to all kinds of subtle bugs that are hard to detect for developers. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fiwrote: Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? end-of-microtask or end-of-task everywhere. And yes, some parsing / networking details may unfortunately be exposed, but in a way which should be quite random. Web devs just can't really rely on network packages to be delivered to parser in some exact way. That randomness seems undesirable. Can we delay the delivery until DOMContentLoaded is fired so that we can have more consisnte behavior here? - Ryosuke
Re: [IndexedDB] Origins and document.domain
On Wed, Jun 20, 2012 at 6:06 AM, Kyle Huey m...@kylehuey.com wrote: By my reading, the spec does not clearly specify what the 'origin' should be. IDBFactory.open/deleteDatabase say Let origin be the origin of the IDBEnvironment used to access this IDBFactory. The IDL states Window implements IDBEnvironment; The HTML5 spec, as far as I can tell, does not define the concept of an origin for a window, but only for a document. Window/Document do effectively have a 1-1 relationship (unless you navigate) but making it more explicit would not hurt probably. There is another related question here: how should IndexedDB behave in the presence of modifications to document.domain? Since it is talking about the origin and not the effective script origin (and it shouldn't, as Adam indicates) it has no effect. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: Should MutationObservers be able to observe work done by the HTML parser?
On 06/20/2012 10:36 AM, Ryosuke Niwa wrote: On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? end-of-microtask or end-of-task everywhere. And yes, some parsing / networking details may unfortunately be exposed, but in a way which should be quite random. Web devs just can't really rely on network packages to be delivered to parser in some exact way. That randomness seems undesirable. Can we delay the delivery until DOMContentLoaded is fired so that we can have more consisnte behavior here? That prevents using MutationObserver for certain cases. Like when you stream data using an iframe. Also, there are already many cases when networking/parsing handling is exposed to the web pages. Just put any img onload=.. onerror= When the handlers run, the stuff after the img may or may not be in the document. - Ryosuke
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Wed, 20 Jun 2012 06:19:22 +0200, Elliott Sprehn espr...@gmail.com wrote: On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: ... This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. Why does it need a short name? If the name is too long to type then that's an argument for better IDEs. Otherwise you end up with stuff like strncpy to save typing. gzip eliminates the file size issue. I'm in agreement with Marat that find() is not as clear as most DOM APIs usually are. findBySelector() makes much more sense. In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. getElementsB(y)Selector is consistent with the platform, subject to getting the s wrong, awfully long. find is too short for a general platform that has lots of ways of finding things and things you might be finding. querySelector is just sucky. But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. If you want quick typing, alias it. If you want to know what it does because you only use it once a month (or in my case about once every six months), the name is barely clear enough. There are no good answers here, since there are significant and competing needs. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Web Notifications
Hi, The Web Notifications WG is planning to move Web Notifications to W3C Last Call meaning we don't intend to change it. But we might have missed something and would therefore appreciate your review of http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html and any comments you might have at public-web-notificat...@w3.org. Cheers, -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: Web Notifications
On 20 June 2012 10:58, Anne van Kesteren ann...@annevk.nl wrote: Hi, The Web Notifications WG is planning to move Web Notifications to W3C Last Call meaning we don't intend to change it. But we might have missed something and would therefore appreciate your review of http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html and any comments you might have at public-web-notificat...@w3.org. This looks really great. Do you have an idea of who is going to adopt this API? Cheers, -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: Web Notifications
On 06/20/2012 11:58 AM, Anne van Kesteren wrote: Hi, The Web Notifications WG is planning to move Web Notifications to W3C Last Call meaning we don't intend to change it. But we might have missed something and would therefore appreciate your review of http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html and any comments you might have at public-web-notificat...@w3.org. Cheers, Seems like tags are global. I think they should be per origin. -Olli
Re: CfC: Publish FPWD of Web Intents spec; deadline June 12
On Jun 19, 2012, at 13:29 , Arthur Barstow wrote: Dave - it appears this CfC passed. Unless I hear otherwise from you, I will assume DAP will take care of the Transition Request and Publication Request. Yes, we'll take care of that. The draft will be published under joint ownership between WebApps and DAP (so with the union of our IPR). -- Robin Berjon - http://berjon.com/ - @robinberjon
Tags and origins (was: Re: Web Notifications)
On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay olli.pet...@helsinki.fi wrote: Seems like tags are global. I think they should be per origin. Yes I believe they should be. http://dvcs.w3.org/hg/notifications/rev/563e9af218b9 Thanks, -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: Tags and origins (was: Re: Web Notifications)
On Wed, 20 Jun 2012 14:30:08 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay olli.pet...@helsinki.fi wrote: Seems like tags are global. I think they should be per origin. Yes I believe they should be. http://dvcs.w3.org/hg/notifications/rev/563e9af218b9 In the default case yes. Can you use something to change that (a la from-origin)? cheers -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Tags and origins (was: Re: Web Notifications)
On Wed, Jun 20, 2012 at 3:03 PM, Charles McCathieNevile cha...@opera.com wrote: In the default case yes. Can you use something to change that (a la from-origin)? I don't really see how. Do you have an example where it makes sense? -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: Tags and origins (was: Re: Web Notifications)
On Wed, Jun 20, 2012 at 5:30 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay olli.pet...@helsinki.fi wrote: Seems like tags are global. I think they should be per origin. Yes I believe they should be. http://dvcs.w3.org/hg/notifications/rev/563e9af218b9 Thanks, This seems like an odd way to restore per-origin tags. Now tag means be either a string or a tuple depending on context. Can we either go back to the original language where in the showing algorithm you compare both tag and origin (add origin to the model), or rename the model context of tag to something more specific, perhaps even replace ID? -John
Re: Tags and origins (was: Re: Web Notifications)
On Wed, Jun 20, 2012 at 3:25 PM, John Gregg john...@google.com wrote: Can we either go back to the original language where in the showing algorithm you compare both tag and origin (add origin to the model), Sure. http://dvcs.w3.org/hg/notifications/rev/93c6983ce465 -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. Right now, that draft uses find/findAll() simply because they're the names that were used throughout the discussion that led to them being added. There are still issues to resolve, however, which I would like feedback on. In particular, is there really value in adding two distinct methods that differ only by whether they return 1 element or a collection? Resolving this issue first would help with resolving the naming issue. It should be noted that JQuery/sizzle does not use querySelector() at all, AFAICS. It only uses querySelectorAll() and sometimes switches to .getElementById() or document.body. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Consider backporting find() behavior to querySelector()
20.06.2012, 18:26, Lachlan Hunt lachlan.h...@lachy.id.au:
In particular, is there really value in adding two distinct methods that
differ only by whether they return 1 element or a collection? Resolving
this issue first would help with resolving the naming issue.
It should be noted that JQuery/sizzle does not use querySelector() at
all, AFAICS. It only uses querySelectorAll() and sometimes switches to
.getElementById() or document.body.
The whole jQuery's paragigm of always searching all matching elements is a
potentially big shortcoming of jQuery as for (at least) performance. It's
natural to suppose that searching for just _first_ matching element and
returning immediately once it's found should be much _faster_ than searching
for _all_ matching elements (be it 100 or 1000 elements) even if we need just
first one.
So yes, we need two separate methods: one to select first matching element and
another one to select all matching elements. They could be united into one
single method with an optional argument, but I doubt it would be quite handy
and nonconfusing for using. Also, a method generally should return consistent
result as for type of returning value, so if we had one method that always
returns collection of elements, that would force us to often use the method
with item accessor (like find('A')[0]) that would be redundant, unusable and
less readable.
For example, I very like `querySelector()` and use it at least as much as (and
maybe even more often than) `querySelectorAll()`.
Re: [selectors-api] Consider backporting find() behavior to querySelector()
It should be noted that JQuery/sizzle does not use querySelector() at all, AFAICS. It only uses querySelectorAll() and sometimes switches to .getElementById() or document.body. I took a look at using querySelector as an optimization a while back but it did not seem to make a significant difference in speed, at least once the library overheads were included. This test html is based on the msn.comhome page to be representative of a big real-life document. http://jsperf.com/findone-vs-findall The reason we switch to getElementById is because querySelectorAll is much slower for that case. qSA can retrieve multiple elements in invalid documents with duplicate IDs, but that's not a case we are worried about.
Re: [selectors-api] Consider backporting find() behavior to querySelector()
20.06.2012, 18:14, Lachlan Hunt lachlan.h...@lachy.id.au:
4. Support for returning elements that are not descendants of the
context object.
This feature allows a selector to be constructed such that it matches an
element anywhere in the tree relative to the context element. This
feature is not relevant to document.find(), since it can already return
anything from the whole tree.
elm.find(+span) // span is a sibling
elm.find(/for/ input) // input could be anywhere
elm.find(:not(:scope)) // Everything except the context object
This feature cannot be supported on Element.qSA, even when using eplicit
:scope, because matching elements need to be descendants of the context
object.
It's unclear why an _updated_ qSA version should have same limitation that
matching elements need to be descendants of the context object. There is
nothing obvious that makes h1.querySelector('+ H2') impossible to work in newer
implementations (in older ones it would not work anyway -- to the same extent
as `elm.querySelector(span)` that you've declared as could work).
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 6/20/12 10:52 AM, Dave Methvin wrote: This test html is based on the msn.com http://msn.com home page to be representative of a big real-life document. For what it's worth, that document has about 2200 DOM nodes. That's two orders of magnitude smaller than big real-life documents. This is a medium-small real-life document. Just for scale, the google.com homepage has about 500 DOM nodes. The W3C homepage has about 1400 DOM nodes. A Zimbra UI with about 200 messages in the inbox is about 5000 nodes. Anything that does dynamic UI stuff will tend to be in the 5k-50k node range. Of course the library overhead might still kill you enough that it doesn't matter... -Boris
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 6/20/12 11:34 AM, Marat Tanalin | tanalin.com wrote: It's natural to suppose that searching for just _first_ matching element and returning immediately once it's found should be much _faster_ than searching for _all_ matching elements (be it 100 or 1000 elements) even if we need just first one. It's natural to suppose that, but it would be wrong if the majority of the time is spent setting up the search (e.g. preprocessing the selector, which jQuery does), not actually searching For example, I very like `querySelector()` and use it at least as much as (and maybe even more often than) `querySelectorAll()`. If you're calling these directly, there's a lot less preprocessing going on. -Boris
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Wed, Jun 20, 2012 at 12:36 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fiwrote: Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? end-of-microtask or end-of-task everywhere. And yes, some parsing / networking details may unfortunately be exposed, but in a way which should be quite random. Web devs just can't really rely on network packages to be delivered to parser in some exact way. That randomness seems undesirable. Can we delay the delivery until DOMContentLoaded is fired so that we can have more consisnte behavior here? This doesn't seem very useful to me. Observing during page load will clearly have a cost associated with it, and if you aren't notified until DOMContentLoaded, you could have just listened for DOMContentLoaded yourself, looked through the document for the stuff you care about, and then attach an observer. I'm not entirely opposed to notifying of parse-time mutations, but if we did it seems like we'd want to deliver them during page load in some way. - Adam
Re: Web Notifications
On Wed, Jun 20, 2012 at 3:17 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 06/20/2012 11:58 AM, Anne van Kesteren wrote: Hi, The Web Notifications WG is planning to move Web Notifications to W3C Last Call meaning we don't intend to change it. But we might have missed something and would therefore appreciate your review of http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html and any comments you might have at public-web-notificat...@w3.org. Cheers, Seems like tags are global. I think they should be per origin. Hmmm. Doesn't Section 4.3 step 2 restrict tag checking to same-origin? -Olli
Re: Web Notifications
On Wed, Jun 20, 2012 at 2:36 PM, Andrew Wilson atwil...@google.com wrote: On Wed, Jun 20, 2012 at 3:17 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 06/20/2012 11:58 AM, Anne van Kesteren wrote: Hi, The Web Notifications WG is planning to move Web Notifications to W3C Last Call meaning we don't intend to change it. But we might have missed something and would therefore appreciate your review of http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html and any comments you might have at public-web-notificat...@w3.org. Cheers, Seems like tags are global. I think they should be per origin. Hmmm. Doesn't Section 4.3 step 2 restrict tag checking to same-origin? Apologies, I see this was changed as a result of Olli's email.
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Wed, Jun 20, 2012 at 1:33 PM, Adam Klein ad...@chromium.org wrote: On Wed, Jun 20, 2012 at 12:36 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fiwrote: Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? end-of-microtask or end-of-task everywhere. And yes, some parsing / networking details may unfortunately be exposed, but in a way which should be quite random. Web devs just can't really rely on network packages to be delivered to parser in some exact way. That randomness seems undesirable. Can we delay the delivery until DOMContentLoaded is fired so that we can have more consisnte behavior here? This doesn't seem very useful to me. Observing during page load will clearly have a cost associated with it, and if you aren't notified until DOMContentLoaded, you could have just listened for DOMContentLoaded yourself, looked through the document for the stuff you care about, and then attach an observer. That's a good point. Although my point was so that you don't have to explicitly wait for DOMContentLoaded yourself. Because if that was script's intention, you could have just added differ or async content attribute to the script element. On Wed, Jun 20, 2012 at 12:53 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 06/20/2012 10:36 AM, Ryosuke Niwa wrote: That randomness seems undesirable. Can we delay the delivery until DOMContentLoaded is fired so that we can have more consisnte behavior here? That prevents using MutationObserver for certain cases. Like when you stream data using an iframe. Also, there are already many cases when networking/parsing handling is exposed to the web pages. Just put any img onload=.. onerror= When the handlers run, the stuff after the img may or may not be in the document. That's true. Maybe this randomness is okay after all. - Ryosuke
Re: Should MutationObservers be able to observe work done by the HTML parser?
* Jonas Sicking wrote: I can't think of any cases where you would *not* want these to fire for parser mutations. For example if you are building an XBL-like widget library which uses the DOM under a node to affect behavior or rendering of some other object. If you attach the widget before the node is fully parsed you still need to know about modifications that happen due to parsing. And you would typically want to attach early to avoid cannot click button while page is loading-style issues in such a scenario. I also note that making page load a special case likely means authors have to write special code to handle it, and that does not seem desirable. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
