Re: Should MutationObservers be able to observe work done by the HTML parser?

[Bjoern Hoehrmann]

* 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/ 

Re: Should MutationObservers be able to observe work done by the HTML parser?

[Ryosuke Niwa]

On Wed, Jun 20, 2012 at 1:33 PM, Adam Klein  wrote:

> On Wed, Jun 20, 2012 at 12:36 AM, Ryosuke Niwa  wrote:
>
>> On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay 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?
>>
>
> 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 
 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 . When the handlers run, the
> stuff after the  may or may not be in the document.


That's true. Maybe this "randomness" is okay after all.

- Ryosuke

Re: Web Notifications

[Andrew Wilson]

On Wed, Jun 20, 2012 at 2:36 PM, Andrew Wilson  wrote:
> On Wed, Jun 20, 2012 at 3:17 AM, Olli Pettay  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: Web Notifications

[Andrew Wilson]

On Wed, Jun 20, 2012 at 3:17 AM, Olli Pettay  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: Should MutationObservers be able to observe work done by the HTML parser?

[Adam Klein]

On Wed, Jun 20, 2012 at 12:36 AM, Ryosuke Niwa  wrote:

> On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay 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?
>

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: [selectors-api] Consider backporting find() behavior to querySelector()

[Boris Zbarsky]

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: [selectors-api] Consider backporting find() behavior to querySelector()

[Boris Zbarsky]

On 6/20/12 10:52 AM, Dave Methvin wrote:

This test html is based on the
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()

[Marat Tanalin | tanalin . com]

20.06.2012, 18:14, "Lachlan Hunt" :
> 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()

[Dave Methvin]

>
>
> 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()

[Marat Tanalin | tanalin . com]

20.06.2012, 18:26, "Lachlan Hunt" :
> 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()

[Lachlan Hunt]

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()

[Lachlan Hunt]

On 2012-06-18 16:45, Simon Pieters wrote:

So http://dev.w3.org/2006/webapi/selectors-api2/ introduces the methods
find() and findAll() in addition to querySelector() and
querySelectorAll() and changes the scoping behavior for the former
methods to match what people expect them to do.


The find methods introduce a number of new behaviours that are not 
present in qSA. Some of these features could be introduced into qSA in a 
backwards compatible way, but some features could only be partially 
supported.  The following is an objective look at your proposal, 
detailing what can and cannot be back-ported to the older qSA methods.


(Note: All rationale below stated to apply to documents also applies 
equally to document fragments.)



1. Support for relative selector syntax.

This features implies the :scope pseudo-class when the selector begins 
with a combinator.


  elm.find(">span") ==> elm.querySelector(":scope>span")

This feature also applies to document.find() and there is no 
compatibility problems with adding support for this to document.qSA. 
However, it is only useful when refNodes are supplied (see #3 below).


There is no compatibility problems with adding support for this to 
element.qSA, however it would have limited utility.


* It cannot work when it begins with a descendant combinator as this
  case is indistinguishable from using no combinator.  The reason this
  actually works for element.find is because of feature #3 below.

* It can never match sibling elements of the context object (see #4
  below), so element.qSA("+span") cannot match anything even if :scope
  is implied.

* The reference combinator will only be effective when the subject of
  the selector is a descendant of the context object.
  label.qSA("/for/ input") would only be useful when input is a
  descendant of the label.

* This would be effective for the child combinator.

In summary:

  elm.querySelector(" span") // Not possible to imply :scope.
  elm.querySelector("+span") // Sibling. Not possible to match.
  elm.querySelector("~span") // Sibling. Not possible to match.
  elm.querySelector("/for/ input") // Limited utility.
  elm.querySelector(">span") // Could work.


2. Support for reference nodes.

This feature allows a parameter to specify a set of elements that will 
be matched by :scope.  This does not apply to Element.find.


  var ref = [...] // Collection of elements.
  document.findAll(":scope>span", ref)

This was supported on qSA in previous drafts before the new find/findAll 
methods were added.  It was only removed from qSA because it duplicated 
the functionality of the new methods with no additional benefit.  There 
is no compatibility problems with adding support for this to document.qSA.



3. Implied :scope when a reference element is present.

Like the relative selector syntax, this is another trigger for implying 
:scope.  This applies when a non-null refNodes parameter is passed to 
the document.find methods.  The context object is used when it is an 
Element node, so :scope is always implied in that case.


  elm.find("div p")
  document.find("div p", elm)

Both of those are equivalent to using explicit :scope in:

  elm.querySelector(":scope div p")

This feature cannot be supported by Element.qSA because implying :scope 
would break the following case where the div is not a descendant of the 
context object (elm).


  elm.querySelector("div p")

This cannot be equivalent to the examples above without breaking 
compatibility.


There is no compatibility problems with adding support for this to 
document.qSA.



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.



5. Return type of the findAll method

Although not yet decided, there have been concerns raised about the 
NodeList return type of the querySelectorAll methods.  There has been 
suggestions that findAll instead return either an Array or an Array-like 
object that implements more useful functionality than NodeList currently 
does.  JS libraries tend to use the Array.slice() technique to convert 
node lists to arrays, which they can deal with more effectively.


It's not yet clear if this issue can be addressed by extending the 
current NodeList interface or using an alternative return type.



I'm not convinced that doubling the API surface is a good idea. If we
were to do that every time we find that a shipped API has suboptimal
behavior,

Re: Tags and origins (was: Re: Web Notifications)

[Anne van Kesteren]

On Wed, Jun 20, 2012 at 3:25 PM, John Gregg  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: Tags and origins (was: Re: Web Notifications)

[John Gregg]

On Wed, Jun 20, 2012 at 5:30 AM, Anne van Kesteren  wrote:

> On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay 
> 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)

[Anne van Kesteren]

On Wed, Jun 20, 2012 at 3:03 PM, Charles McCathieNevile
 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)

[Charles McCathieNevile]

On Wed, 20 Jun 2012 14:30:08 +0200, Anne van Kesteren   
wrote:


On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay   
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

Tags and origins (was: Re: Web Notifications)

[Anne van Kesteren]

On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay  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: CfC: Publish FPWD of Web Intents spec; deadline June 12

[Robin Berjon]

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

Re: Web Notifications

[Olli Pettay]

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: Web Notifications

[Melvin Carvalho]

On 20 June 2012 10:58, 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.
>


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/
>
>

Web Notifications

[Anne van Kesteren]

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: [selectors-api] Consider backporting find() behavior to querySelector()

[Charles McCathieNevile]

On Wed, 20 Jun 2012 06:19:22 +0200, Elliott Sprehn   
wrote:


On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr.  
wrote:



...
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

Re: Should MutationObservers be able to observe work done by the HTML parser?

[Olli Pettay]

On 06/20/2012 10:36 AM, Ryosuke Niwa wrote:

On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay 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 . When the handlers run, the stuff after 
the  may or may not be in the document.






- Ryosuke

Re: [IndexedDB] Origins and document.domain

[Anne van Kesteren]

On Wed, Jun 20, 2012 at 6:06 AM, Kyle Huey  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?

[Ryosuke Niwa]

On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay 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?

- Ryosuke

Re: Should MutationObservers be able to observe work done by the HTML parser?

[Anne van Kesteren]

On Tue, Jun 19, 2012 at 10:52 PM, Olli Pettay  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/