Re: W3C XHR, was Re: [admin] Draft of updated charter available for review
On Friday, January 24, 2014 at 1:48 AM, Jungkee Song wrote: To be clear: I’m concerned that the last time the spec on TR was updated was in 2012. That seems like a big failure to me, specially as when you google for the spec, the on the TR comes up first. This means that most people are looking at a grossly outdated spec if they click on the first link. I understand your concern. Indeed, we editors should have made it clearer providing updates on the status and more importantly a new TR. The goal of the snapshot version of the spec is clear. It aims to standardize all widely implemented parts of the spec that are compatibly supported across major implementations in a *timely* manner. Hence the number one to-do is to enhance the pass ratio of the test suite [1] by interacting with the implementors. We'd planned to publish LC with the Level 1 spec [2] in a near-term after the last TPAC but the changing publication policy recommends for us to take more conservative approach in publishing LC. That said, it seems necessary for us to publish a WD with [2] for now before we'll get ready with the test results good enough for publishing LC. Any comments would be appreciated. Thanks Jungkee for the update - looking forward to seeing an updated WD on TR soon. It's good to see the progress in the test suite and that you guys have been following up there with the various browser vendors.
[Bug 24351] [Shadow]: Event related target resolution algorithm should consider the case of multiple shadow roots.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24351 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|dglaz...@chromium.org |hay...@chromium.org --- Comment #1 from Hayato Ito hay...@chromium.org --- The algorithm was updated in https://github.com/w3c/webcomponents/commit/cfdea8597467d17baab0078630041d317a4f9f0a -- You are receiving this mail because: You are on the CC list for the bug.
Re: W3C XHR, was Re: [admin] Draft of updated charter available for review
On 1/23/14 8:48 PM, ext Jungkee Song wrote: I understand your concern. Indeed, we editors should have made it clearer providing updates on the status and more importantly a new TR. The goal of the snapshot version of the spec is clear. It aims to standardize all widely implemented parts of the spec that are compatibly supported across major implementations in a *timely* manner. Hence the number one to-do is to enhance the pass ratio of the test suite [1] by interacting with the implementors. We'd planned to publish LC with the Level 1 spec [2] in a near-term after the last TPAC but the changing publication policy recommends for us to take more conservative approach in publishing LC. That said, it seems necessary for us to publish a WD with [2] for now before we'll get ready with the test results good enough for publishing LC. Any comments would be appreciated. Thanks for the update Jungkee! I think your plan (to publish a WD now that will replace the 2012 WD and to continue to work toward a LC that is broadly and compatibly implemented) is good. Please let me know when you want me to start a CfC for the WD. -Thanks, Art [1] http://jungkees.github.io/XMLHttpRequest-test/ [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html
Re: Do we need a rendering spec?
On Jan 23, 2014, at 2:45 PM, Dimitri Glazkov dglaz...@google.com wrote: As HTML imports [1] are implemented across browsers, there’s a potential for diversity of opinion in how rendering of documents with imports occurs. What blocks rendering? What doesn’t? To prevent the inevitable pain of converging on a de-facto standard behavior, it would be super-nice to have precise documentation of when the rendering engine should start (and stop) rendering the document. I don't think we want to expose when rendering / painting / style resolution happens to the Web just like we don't want to expose GC timing to the Web. e.g. it makes the UAs much more vulnerable against the timing attacks. If the HTML imports specification exposes such timing, then we should fix that so that we expose such timing. But before jumping to conclusions, could you clarify how exactly HTML imports creates a dependency on the rendering timing? The specific problem we (the imports people) are interested in is “when do things first appear on screen?”, and we could definitely hack up some vague informative prose in the HTML Imports spec in the short term. But long-term, do we (the W3C people) want a rendering spec? It seems like a daunting path with lots of obstacles. To name a few: * Things like first-frame rendering traditionally had been a secret sauce for performance optimizations. Trying to standardize this could potentially remove such opportunities. Indeed. * Rendering as a concept doesn’t seem to exist in spec land. Starting from scratch will be a ton of work. * Browsers do wildly different things when rendering. Coming up with a cohesive unified spec for existing behaviors sounds like an epic multi-year undertaking. Right. What does the first time to render mean for printing UA for example? * Even more fundamentally, what is really rendering? Is it when the pixels appear on screen? Is it the specific consistent state of the box tree? Hell, do we have to now define a box tree? I don't think we want to define those either. Those should be left as implementation details. - R. Niwa
