[Bug 17661] New: I would like to try this input box. Thanks
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17661 Summary: I would like to try this input box. Thanks Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: I would like to try this input box. Thanks Posted from: 183.179.149.221 User agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 17661] I would like to try this input box. Thanks
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17661 Ms2ger ms2...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||ms2...@gmail.com Resolution||INVALID -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Fri, Jun 29, 2012 at 6:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jun 29, 2012 at 8:25 PM, Adam Klein ad...@chromium.org wrote: On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking jo...@sicking.cc wrote: All in all I think that as soon as we introduce exceptions to when MutationObserver callbacks fire we change the API from being a reliable way to track DOM mutations to a unreliable way where all callers have to be aware of exceptions and deal with them in other ways. I.e. it feels like it significantly reduces the value of MutationObservers. And so far I don't see any good arguments made for making that reduction in value. Did I miss any arguments other then the randomness argument? Performance was one concern that's come up in discussing this with Ojan and Rafael. Imagine a MutationObserver attached to the document near the top of the page. Now we need to create basically one MutationRecord per node inserted (because the parser operates in a depth-first sort of order). I'm not at all sure this is a show-stopper (we might be able to introduce some new MutationRecord type that could compactly represent parser-style operation), but it definitely seems worrisome, especially given that one of the common uses for MutationObservers is extensions which might run on many (all?) pages. Hmm.. is there actually anything requiring that nodes are inserted one at a time? Internally in mozilla we do insert nodes one at a time, but the notifications we send out to the various subsystems make it seem like nodes are inserted in big chunks. This has previously been to Are the chunks arbitrarily shaped fragments? I.e. is their any restriction on their shape other than a tree? give us good performance from the layout engine which benefits from getting notified by large chunks being inserted rather than nodes being inserted one at a time. The MutationObserver implementation hangs off of the same notification system and thus also sees nodes as being inserted in big chunks. / Jonas
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Sat, Jun 30, 2012 at 5:56 PM, Rafael Weinstein rafa...@google.com wrote: On Fri, Jun 29, 2012 at 6:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jun 29, 2012 at 8:25 PM, Adam Klein ad...@chromium.org wrote: On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking jo...@sicking.cc wrote: All in all I think that as soon as we introduce exceptions to when MutationObserver callbacks fire we change the API from being a reliable way to track DOM mutations to a unreliable way where all callers have to be aware of exceptions and deal with them in other ways. I.e. it feels like it significantly reduces the value of MutationObservers. And so far I don't see any good arguments made for making that reduction in value. Did I miss any arguments other then the randomness argument? Performance was one concern that's come up in discussing this with Ojan and Rafael. Imagine a MutationObserver attached to the document near the top of the page. Now we need to create basically one MutationRecord per node inserted (because the parser operates in a depth-first sort of order). I'm not at all sure this is a show-stopper (we might be able to introduce some new MutationRecord type that could compactly represent parser-style operation), but it definitely seems worrisome, especially given that one of the common uses for MutationObservers is extensions which might run on many (all?) pages. Hmm.. is there actually anything requiring that nodes are inserted one at a time? Internally in mozilla we do insert nodes one at a time, but the notifications we send out to the various subsystems make it seem like nodes are inserted in big chunks. This has previously been to Are the chunks arbitrarily shaped fragments? I.e. is their any restriction on their shape other than a tree? We only perform valid DOM operations, which means that we're restricted to mutating Text nodes and inserting things that a DocumentFragment can express. I.e. we only consecutive siblings, though these siblings can have arbitrarily big subtrees. So if we're parsing a document like: div p span...lots of nodes here.../span span...more content here.../span /p form...lots of nodes here.../form footer...enough with the content already.../footer /div and a network boundary falls after the start p tag, then we'll first do a single insertion which looks like div p/p /div then once we receive more content we'll do a single insertion containing the two span elements: div p span...lots of nodes here.../span span...more content here.../span /p /div then do a single insertion containing the form and the footer div p span...lots of nodes here.../span span...more content here.../span /p form...lots of nodes here.../form footer...enough with the content already.../footer /div So all in all 3 MutationObserver records would be created in this instance. / Jonas
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On 2012-06-28 18:03, Stewart Brodie wrote: Arthur Barstow art.bars...@nokia.com wrote: This is a Request for Comments for the June 28 Last Call Working Draft of Selectors API Level 1: http://www.w3.org/TR/2012/WD-selectors-api-20120628/ The comment deadline is July 19 and all comments should be sent to the public-webapps@w3.org list with a Subject: prefix of [selectors-api]. Section 1 contains a unwanted duplication: With these methods methods, Fixed in both level 1 and 2. There is something odd about the way matching is defined: Section 6 defines matching Element node directly in terms of the [SELECT] reference, then section 6.4 defines what it means to evaluate a selector but this is never referenced. I think section 6 needs to define matching Element node as something like: Oops, this was supposed to have the content similar to that in the level 2 spec defining what to do when the methods were invoked. I've now backported this from that spec, but omitted all things related to :scope. The changes are in the editor's drafts. http://dev.w3.org/2006/webapi/selectors-api/ http://dev.w3.org/2006/webapi/selectors-api2/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
change of affiliation
Hi all, after today I will no longer be working for Opera. I will remain chair of web-apps as an invited expert. After a break I will be working for Yandex, the Russian search and services company... cheers Chaals -- Chaals - standards declaimer
