Re: CfC: publish Last Call Working Draft of Web IDL; deadline July 7

2011-07-09 Thread Arthur Barstow
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.


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:

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:


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:

-Art Barstow

Re: Where to discuss TR process issues? [Was: Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1

2011-07-09 Thread Charles McCathieNevile

On Wed, 06 Jul 2011 23:50:48 +0200, Ian Hickson 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 - 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.



Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk   Try Opera:

Re: Mutation events replacement

2011-07-09 Thread Sean Hogan

On 9/07/11 1:12 AM, Ryosuke Niwa wrote:
On Fri, Jul 8, 2011 at 5:21 AM, Sean Hogan wrote:

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