Re: CfC: publish Last Call Working Draft of Web IDL; deadline July 7
Although there are ongoing discussions regarding exceptions, there were no objections to this CfC. As such, I will request publication of a LC specification to encourage broader review and comments. -AB On 6/30/11 6:46 AM, ext Arthur Barstow wrote: As Cameron indicated in [1], all non-enhancements bugs for Web IDL are now resolved and as such, this is a Call for Consensus to publish a Last Call Working Draft of Web IDL: http://dev.w3.org/2006/webapi/WebIDL/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Positive response to this CfC is preferred and encouraged and silence will be considered as agreement with the proposal. The deadline for comments is July 7. Please send all comments to: public-script-co...@w3.org -Art Barstow
Re: Where to discuss TR process issues? [Was: Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1
On Wed, 06 Jul 2011 23:50:48 +0200, Ian Hickson i...@hixie.ch wrote: On Wed, 6 Jul 2011, Arthur Barstow wrote: So, rather than continuing to complain about this process on public-webapps, I would appreciate it if you would please move TR process type discussions to another Public list. I'm not asking to have a discussion about it at all; I'm asking that you stop trying to prioritise my work based on it. Hi Ian, in so far as the Web Apps group is currently chartered under the existing W3C process, and you are an editor of some specs under the terms of that charter, I find it hard to understand what us unreasonable about prioritising the work of the group (some of which you have volunteered to do) according to the existing agreements about how the group functions. For what it's worth, I am a member of the Advisory Board, and in that capacity I share some of your concerns. I, and I believe the advisory board as a whole, would appreciate you taking the time to make some proposals on process to that forum - a...@w3.org with a cc to e.g. www-archive if you want a public track. As an employee of a W3C member, you could also ask your member representative (TV Raman) to present concerns through the Advisory Committee forum. Whether you chose to do so or not, these issues are being followed in the relevant fora - but this group isn't really it. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Mutation events replacement
On 9/07/11 1:12 AM, Ryosuke Niwa wrote: On Fri, Jul 8, 2011 at 5:21 AM, Sean Hogan shogu...@westnet.com.au mailto:shogu...@westnet.com.au wrote: - MathJax (http://mathjax.org) is a JS lib that facilitates putting math onto the web by converting LaTeX or MathML markup in a page to HTML. By default MathJax triggers off the onload event to run this conversion on the page. When content containing math is dynamically added to the page, MathJax must be called manually to convert the new content. A DOM insertion listener could potentially be used to handle this conversion automatically. - A similar use-case is element augmentation too complex for CSS :before and :after - ARIA support in JS libs currently involves updating aria-attributes to be appropriate to behavior the lib is implementing. Attribute mutation listeners would allow an inverse approach - behaviors being triggered off changes to aria-attributes. - DOM insertion and removal listeners could facilitate the implementation of automatically updating Table-of-* (Headings / Images / etc). It seems like all 3 use cases here can be implemented by observers that are called AFTER the fact, and do not requiere any events or callbacks before mutation. I agree, but it's just a list of the top of my head - I was merely trying to assist with the request for use-cases. An obvious advantage of callbacks that occur BEFORE mutation is that they can be used to implement post-mutation notifications. The reverse is impossible.
