Re: Items not listed as new in the draft charter

[Doug Schepers]

Hi, Maciej-

I'm a little frustrated to be having this conversation now, after I 
tried for several weeks to get comments on the charter before sending it 
to W3M, and then to the AC.  There was substantial discussion on both 
the member-only list and on this public list (which you engaged in), and 
the appropriate time to raise these issues was then.


I agree with the goal of transparency, but the chief rationale for a 
charter is as an overview, not as a detailed history or exhaustive scope 
delineation; that is what the links to the documents themselves are for 
(where those are available).  It is unusual to be asked to go into this 
level of detail in the scope of a chartering review in the AC, and I 
haven't seen evidence that others share your concerns.  I am extremely 
reluctant to establish a precedent here, when rechartering is already a 
major pain.


We all know that the ultimate scope of a specification is defined 
throughout the ongoing process within the group itself, with different 
parties contributing to and steering the precise scope of the spec. 
Questions of scope are not settled in fine detail in the AC, but in the 
group itself.


So, precision in a charter is good, because it can help prevent too much 
scope creep, but where it interferes with the natural development of a 
spec or a group's work, then that precision is counterproductive.


For example, I made a mistake in the previous charter by relying too 
heavily on the descriptions of specs from their abstracts, while the 
group as a whole did not have consensus on the scope of those 
deliverables.  In the examples you cite here, I was too precise: the Web 
Database one (where we all agreed that we wanted the functionality, but 
had disagreement on whether it would be based on SQL or B-Trees); and 
the secure cross-domain scripting one (where there are disagreements 
about the mechanism).  I was glad to be given the opportunity to correct 
those mistakes.


Based on my exegesis of the email discussions and history of the specs 
themselves, I think the wiki page is factual and neutral, and if 
necessary, I am willing to go into detail about why I reached these 
conclusions (I'm reluctant to go into such detail here because of the 
time it would take, and everyone is free to reads back through the 
sources, since it's all public).  Splitting hairs is arguably less 
forthright, because it would impose a particular viewpoint on the 
history of these specs, drawing more attention to certain deliverables, 
with potentially disruptive consequences... that is, reviewers may think 
certain deliverables are more controversial than they really are, and 
vote against the charter on that basis; for example, the Indexed DB spec 
seems more popular than the Web SQL DB, but pointing out that it is 
somewhat different than the originally defined scope would misrepresent 
its position.


Regarding differences between the descriptions of this charter and the 
last, that is precisely what a rechartering is for: to better describe 
the current state and focus of the deliverables as they have changed 
over time.  The previous (existing) charter is available for comparison, 
for those who are interested.


Perhaps at this point, if you have specific changes you would like made, 
it would be best to have your AC rep describe them in the normal course 
of AC review, or to discuss them in the AC forum?


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Maciej Stachowiak wrote (on 3/29/10 2:40 PM):


On Mar 29, 2010, at 10:22 AM, Doug Schepers wrote:


Hi, Folks-

I've put together a wiki page [1] that I propose to send to the AC as
a further clarification on the charter discussion. How does this look
to you?

Does everyone agree that this is fair representation of the changed
work in the WebApps WG charter?

[1] http://www.w3.org/2008/webapps/wiki/Charter



More comments:

It may be worth noting that some of the deliverables described as
alternate proposals do not actually match the charter descriptions for
the previous main deliverables. For example, the 2008 charter describes
CORS thus:
A mechanism for selective and secure cross-domain scripting (formerly
Access Control for Cross-site Requests).

But UMP is arguably not selective; it lets you limit what resources
can be access cross-domain, but not who can access them, by design.


The 2008 charter describes Web Storage thus:
Two APIs for client-side data storage in Web applications: a name-value
pair system, and a database system with a SQL frontend.

But Indexed Database clearly does not really satisfy the description of
either of those two APIs, again, by design.


I think it's better to be forthright about this. The whole reason these
APIs exist is to differ in a fundamental way from the other relevant
charter deliverables in a fundamental way.


I also disagree with both describing Widget Embedding as new, and then
also describing it as split from another document

Re: Client side JavaScript i18n API

[Doug Schepers]

Hi, Robin-

Robin Berjon wrote (on 4/27/10 12:21 PM):


On Apr 27, 2010, at 18:13 , Phillips, Addison wrote:

A project to implement this could go quite fast, I think, but would
require agreement by the major browser vendors and a place to do
the work. We could do this at W3C, but I think ECMA should be
involved from early on.


In general a good place for discussion that involves W3C/TC39
coordination is public-script-co...@w3.org. It doesn't have an
attached group and therefore cannot publish specifications, but
that's a sausage-making detail that can be handled orthogonally (we
just need to find a WG that can justify having this in its charter).


Actually, public-script-coord is associated with the WebApps WG, and was 
formed to coordinate between TC39 and the WebApps WG, specifically on 
Web IDL issues, but also on other matters of coordination.


If we do decide to bring this i18n work to W3C (which I think would be a 
good idea, though not by necessity in the WebApps WG), we could reuse 
public-script-coord, or we could make a new dedicated list.  I think the 
latter makes more sense, since the i18n folks wouldn't have to drink 
from the public-script-coord hose.


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: [widgets] Zip vs GZip Tar

[Doug Schepers]

Hi, Folks-

Sorry to jump in on this thread so late; I've been busy and traveling.

As W3C Team Contact for this group, I strongly agree with Ian here 
regarding the tone of some of the responses.  Technical comments on this 
list should be treated with the respect they are due.  If you feel 
something has been adequately covered in the archives, point to an 
example email.  Please keep this list civil, technical, and productive.


On a logistical level, I again agree with Ian.  I'm rather disappointed 
that we can't solve this problem more quickly.  I think Gregg raised 
worthwhile use cases and points for consideration [1], and wonder if 
this might not be dealt with in the Widgets Embedding spec... after all, 
that is intended for the latter case he mentions.  I can think of many 
worse things than having 2 alternate compression schemes, if the use 
cases are different.  (Yes, I realize I'm speaking loosely and there 
might be serious technical problems with this approach... I'm just 
brainstorming here.)


Aaron Boodman suggested something [2] on the WHATWG list that sounds 
suspiciously like Widgets, and it would be a real shame to miss out on 
this opportunity for increasing the applicability of the Widgets specs 
in multiple scenarios and platforms.


[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0349.html
[2] 
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026488.html


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

OFF TOPIC: SVG Progress Contest

[Doug Schepers]

Hey, folks-

Sorry to spam this list, but I thought that folks who are familiar with 
the new progress events might be interested in applying those skills to 
SVG.  This is a fun contest with some great prizes for making an SVG 
progress indicator.


The contest ends in a couple days, so don't delay!

 http://www.w3.org/QA/2010/06/svg_contest.html
 http://westciv.com/nobit/

Regards-
-Doug

Re: Goodbye

[Doug Schepers]

Hi, Robert-

Nice to have worked with you.  Good luck in your future endeavors.

Regards-
-Doug

Ennals, Robert wrote (on 7/8/10 5:02 PM):

Hi Guys,

I have chosen to leave Intel and so will no longer be representing Intel
in the HTML or WebApps working groups. The other Intel reps in the HTML
WG and the WebApps WG will follow through on the work that I have been
doing, including our distributed extensibility proposals.

If you wish to contact me in the future, please use my personal email
address: r...@ennals.org mailto:r...@ennals.org.

It has been great working with you all.

-Rob

Re: CfC: to publish a Last Call Working Draft of DOM 3 Events; deadline September 3

[Doug Schepers]

Hi, Anne-

There are still still some outstanding issues, which we intend to 
address in LC; many of them are marked up specifically to solicit wider 
review and comments, which is generally more forthcoming during LC.  The 
goal is to collect these comments so we are ready to discuss them during 
TPAC.  We expect we will have to have another LC.


So, are these intended as LC comments (which I'm happy to address), or 
as an argument against going to LC?


Replies inline...

Anne van Kesteren wrote (on 8/28/10 6:03 AM):

On Fri, 27 Aug 2010 19:32:13 +0200, Arthur Barstow
art.bars...@nokia.com wrote:

Doug and the folks working on the DOM 3 Events spec believe the spec
is now feature-complete and would like to publish a Last Call Working
Draft of the spec. As such, this is a Call for Consensus to publish
the following document as the LCWD:

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html


There still seem to be a open issues (marked up in the specification).


Yes, this is by design.  We believe the spec is feature complete, but we 
know there are outstanding issues we want feedback on.




A comment I raised on the 'scroll' event some weeks ago is also not
addressed.


Sorry, I see I started a reply there, but never sent it (sigh); I will 
send it now.  I think that issue needs more discussion, but I'm happy to 
change it during LC if that's the group consensus.




(Just noticed that the references section contains a reference to XHTML
but that is never referenced from the draft. The HTML5 and CSS 2.1
references are out of date.)


Removed XHTML (an artifact from an earlier draft), updated the other 
references.




Looking through it a bit more the mousewheel event seems gone. I thought
we agreed long ago that would be part of it. (Various notes in the
specification do mention it, but it seems they are included by accident.)


Yes, we included 'mousewheel' as recently as 7 months ago, but I removed 
it based on implementer feedback.  I've now removed the stray reference 
to it in the Changes section.


The only other place it's mentioned is in the 'wheel' event as an 
informative comparison.




I'll try to review more closely on Monday.


Thanks.  Please let us know if you object to us going to LC, given our 
plan of record.


(Note: I will be at the SVG Open conference and SVG WG F2F starting on 
Monday, for the next week and a half, and will probably not be very 
responsive.)


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: CfC: to publish a Last Call Working Draft of DOM 3 Events; deadline September 3

[Doug Schepers]

Hi, Anne-

Anne van Kesteren wrote (on 8/29/10 4:07 AM):

On Sat, 28 Aug 2010 19:48:18 +0200, Doug Schepers schep...@w3.org wrote:

There are still still some outstanding issues, which we intend to
address in LC; many of them are marked up specifically to solicit
wider review and comments, which is generally more forthcoming during
LC. The goal is to collect these comments so we are ready to discuss
them during TPAC. We expect we will have to have another LC.

So, are these intended as LC comments (which I'm happy to address), or
as an argument against going to LC?


Somewhat against a Last Call. After all, Last Call is for when we think
we are done. Although this is often not the case (see e.g.
XMLHttpRequest), if we know it is not, it seems too early to issue one.


Sorry, I should have set expectations better.

Those of us who were working on DOM3 Events during the telcons, 
specifically Travis Leithead, Olli Pettay, and me, believe that DOM3 
Events is feature complete, and while we understand that there are known 
points on which people will raise issue (such as the ones you are 
raising now), and are willing to change the spec to match that LC 
feedback, we don't expect the spec to change its feature set.  (BTW, 
I've already changed most of what you asked for with 'scroll'.)


There are a few places where we would also like to put in more examples 
or informative wording, but we didn't feel that should block Last Call.


As you say, with specs that have a long history, like DOM3 Events or 
XMLHttpRequest, there is always likely to be difference of opinion over 
whether it is done, or done to the satisfaction of the entire group.  I 
expect that long after DOM3 Events or XHR or even HTML5 are 
Recommendations, there will be people who are not happy with the spec. 
In my opinion, disagreement with some aspect of the spec is not 
sufficient rationale to block it from progressing to LC, if the 
technical details are sound.


If the group decides to change something, I will change it; I have 
changed, added, and dropped many things I personally didn't agree with, 
many of them based on your feedback; If anything, I will treat LC 
feedback even more carefully.  Obviously, this spec is not going to 
progress to CR unless the group feels it is ready, so I would like to 
take that first step of going to LC despite there being some areas of 
disagreement, even as you did with XHR.  If you will recall, I supported 
going to LC (twice) and CR for that spec, even though I disagreed (and 
still disagree) with some of the decisions.  I'm asking for the same 
courtesy; if there are indeed technical issues with DOM3 Event that are 
raised during LC, then we will address them as a group and resolve them.



I'm headed to the airport now, so I'll address your comments about 
mousewheel in another email.  I've CCed Olli and Travis, and ask them 
send in their rationale for dropping 'mousewheel'.  (I believe it was 
pretty fully specced when we dropped it, so it would be easy to add it 
again.)


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: XBL2

[Doug Schepers]

Hi, Ian-

Jonas Sicking wrote (on 9/3/10 7:24 PM):


In general I would have appreciated at least being pinged about our
requirements before these changes had been made. In the current state
its unlikely that we'll be following the specification without
modifications.

On Thu, Sep 2, 2010 at 6:23 PM, Ian Hicksoni...@hixie.ch  wrote:


 Since XBL2 wasn't getting much traction, I've taken an axe to the spec and
 made a number of changes to the spec based on some discussions with some
 browser vendors:


Since Jonas (surprisingly) wasn't among the browser vendors you 
discussed this with, I'd be interested to know who you discussed it 
with, what precisely their feedback was, and the justifications and use 
cases they explained.  I want XBL2 to succeed, so I think we should all 
get on the same page about it.


To that end, could you provide a link to the requirements document, or 
if there isn't one, could you start one?


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: ISSUE-122 (add mousewheel): Consider adding 'mousewheel' again [DOM3 Events]

[Doug Schepers]

Hi, Anne-

Anne van Kesteren wrote (on 9/10/10 7:17 AM):

On Fri, 10 Sep 2010 13:09:38 +0200, Web Applications Working Group Issue
Tracker sysbot+trac...@w3.org wrote:

'mousewheel' was later dropped based on feedback from implementers
(Mozilla, Microsoft), who expressed a reluctance to implement
'mousewheel', and a lack of useful interoperability and concern that
any change to improve interop would likely break a number of sites.

However, the group may wish to consider adding it again, see:
* http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0103.html


Are you saying Internet Explorer no longer supports the mousewheel
event? The reason Opera / Chrome / Safari support the event is because
Internet Explorer has it too and is needed for compatibility. Mozilla
indeed does not have it, but they have DOMMouseScroll or some such.


I'm not making any claims about who will or won't support mousewheel. 
I'm just trying to state what I recall of the rationale for removing it 
from DOM3 Events.  I don't feel terribly strongly about it either way, 
in any case.


See also my reply on the thread on www-dom:
 http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0126.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: Seeking agenda items for WebApps' Nov 1-2 f2f meeting

[Doug Schepers]

Hi, Art-

I would like for us to talk about DOM3 Events.  I am not sure how much 
time this would take up.  I'm neutral on when it happens.


Thanks-
-Doug

Arthur Barstow wrote (on 8/31/10 7:31 AM):

The WebApps WG will meet face-to-face November 1-2 as part of the W3C's
2010 TPAC meeting week [TPAC].

I created a stub agenda item page and seek input to flesh out agenda:

http://www.w3.org/2008/webapps/wiki/TPAC2010

[TPAC] includes a link to the Registration page, a detailed schedule of
the group meetings, and other useful information.

The registration fee is 40€ per day and will increase to 120€ per day
after October 22.

-Art Barstow

[TPAC] http://www.w3.org/2010/11/TPAC/

DOM3 Events Comments

[Doug Schepers]

Hi, Folks-

I appreciate all the comments on DOM3 Events so far.  I'm filing each of 
them in Tracker, though it may take me a few days to file a bug; 
however, I am reading all of them, and will get around to filing them all.


Currently, the WebApps Tracker sends the emails for each filed issue to 
public-webapps, rather than www-dom, regardless of the product.  I've 
asked our Systems Team if this can be changed for DOM3 Events issues, 
but I don't know if that's possible or easy to do.


In the meantime, if you are going to respond directly to the Tracker 
emails, please take the time to change the TO: field to www-...@w3.org 
(though you should feel free to BCC public-webapps if you like).  That 
will make it much easier to track the issues.


Thanks-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: A URL API

[Doug Schepers]

Hi, Adam-

I really like this idea.  Of course there are scripts out there that do 
most (all?) of this, but exposing it as an interface seems useful to me.


I proposed something similar in my SVG Params spec [1][2][3], though 
yours is better thought out.  One difference is that I was specifically 
looking at parameters, not merely as a function of the URL, but through 
any mechanism that the language provides; for example, HTML can pass 
parameters into a file referenced through the object element with 
child param elements.  Do you think there's some way to reconcile that 
with your proposal?


[1] http://www.w3.org/TR/SVGParam/
[2] http://dev.w3.org/SVG/modules/param/master/SVGParam.html
[3] http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Adam Barth wrote (on 9/17/10 2:05 PM):

On Fri, Sep 17, 2010 at 10:27 AM, Adam Barthw...@adambarth.com  wrote:

 On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisherda...@chromium.org  wrote:

 On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschkejulian.resc...@gmx.de
 wrote:

 That sounds good to me. In general I think it would be great if there were
 standard APIs for URI/IRI construction, parsing and resolution...


 Yes, that sounds pretty good to me too.


 This has annoyed me for a while too.  I'll write up a spec.


Here's a sketch:

https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en

Adam

Re: [Widgets] Mozilla open apps

[Doug Schepers]

Hi, Mike-

The Mozilla Open Apps project looks cool, and I hope it can work out to 
be compatible with Widgets.  Your extensions and use cases seem useful. 
 This would be a good thing for everyone involved.


Mike Hanson wrote (on 10/20/10 2:40 PM):


*In-Browser/live content usage*
Our goal is to encompass in-browser application usage, where some
subset of normal web browsing activity is identified as an app.


It seems that that might be a reasonable use case for the new Widgets 
Embedding spec [1]:


[[
Widgets Embedding: a mechanism to allow embedding of packaged 
applications within other Web content, such as referencing via the HTML 
object element. This is a new deliverable for the WebApps WG.

]]



(Prior warning: I apologize if I disappear from the list at short notice
in a day or two; I have a new baby coming imminently)


Congratulations to you and your family!


[1] http://www.w3.org/2010/webapps/charter/Overview.html#widget-embedding

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: requestAnimationFrame

[Doug Schepers]

Hi, folks-

This is just a quick note to let you all know that the topic of APIs for 
animation, both scripted and declarative, is one of the things that the 
FX Task Force [1] (a joint task force between the CSS and SVG WGs) is 
looking at, so we are following this thread with interest.


From a Recommendation-track spec perspective, animation (and by 
extension, animation APIs and timing stuff) are already in scope for 
those groups, so we would like to standardize things there; obviously, 
we would want the continued participation of the WebApps WG participants 
as well.  (I prefer to avoid more painful chartering discussions.)


I'm not trying to cut off conversation here, I just wanted to make sure 
people were aware.


[1] http://www.w3.org/Graphics/fx/

Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs


Gregg Tavares (wrk) wrote (on 11/15/10 6:03 PM):

following in the footsteps of a previous thread
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0223.html

I'd like to see if there is some consensus on this issue. Various people
are anxious to see this happen in more browsers.

A couple of questions came up for requestAnimationFrame
(see
http://weblogs.mozillazine.org/roc/archives/2010/08/mozrequestanima.html)

One is, how should this api be used if I want an app to update at 10hz.
  It seems to be designed to assume I want the maximum frame rate. If I
want to run slower would I just use

setInterval(function() {
window.requestAnimationFrame();
   }, 100); // request frames at 10hz?

That's fine if that's the answer

But that brings up the next question. I'm in some alternate world where
there is no Flash, instead all ads are implemented in Canvas. Therefore
a site like cnn.com http://cnn.com or msnbc.com http://msnbc.com has
5 canvases running ads in each one.  I don't really want all 5 canvases
redrawn if they are not on the screen but the current design has
requestAnimationFrame and beforePaint to be window level apis.

That seems to have 2 issues.

1) All of them will get a beforePaint event even if most or all of them
are scrolled off the visible area since there is only 1 beforePaint
event attached to the window.

2) All of them will get beforePaint events at the speed of the fastest
one. If one ad only needs to update at 5hz and other updates at 60hz
both will update at 60hz.

Do those issues matter? If they do matter would making both
requestAnimationFrame and beforePaint be element level APIs solve it?

Call for Editors for Server-sent Events, Web Storage, and Web Workers

[Doug Schepers]

Hi, Folks-

This is an active call for editors for the Server-sent Events [1], Web 
Storage [2], and Web Workers [3] specifications.  If you are interested 
in becoming an editor, with all the rights and responsibilities that go 
along with that, please respond on this thread or email us directly at 
team-weba...@w3.org.


Previously, Art Barstow asked for an analysis of the current status of 
these specs, with regards to LC comments, implementations, test suites, 
and so forth; these are typically performed and coordinated by the 
editor of a spec, and it's appropriate that someone doing this work 
would get editor credit for their effort.


These specs have not made progress along the Recommendation track in 
some time, and we want to move them forward to a stable state.  We 
appreciate and acknowledge the work the current editor, Ian Hickson, has 
put into these specs, but he seems to have indicated that he does not 
wish to be the one to drive them forward (which is understandable, given 
his other commitments, such as the HTML5 spec).  Ideally, we would 
prefer that Ian stay on as active co-editor, but if the logistics don't 
work out, we may ask the new co-editor to take on the sole 
responsibility for finalizing the spec, including processing comments 
from the WebApps WG, and from the community at large.



In the earlier thread, there was a discussion on the logistics and 
differing philosophies on spec development; without dwelling on that 
topic too much, it's worth stating that stability of a spec is a goal 
not only for licensing commitments, but also as a matter of coordination 
with multiple implementers, and for development of the entire 
infrastructure around a technology, including tests, tutorials, script 
libraries, and cutting-edge usage, some of which happens within W3C, and 
some of which happens in the wild.  We have an obligation to our 
community to make clear and consistent statements on the stability of 
our documents, because it costs real time, effort, and money to invest 
in these technologies.


Secure and efficient specifications are obviously the most important 
goal, but pushing out deadlines and changing the spec without clear 
progress toward a stable state is frustrating and troublesome for our 
community.


There is a difference in strategies between Ian's stated approach and 
W3C's; both are valid, but W3C has chosen to publish stable snapshots of 
specifications in the form of Recommendations, and to release updates to 
those technologies as subsequent editions, or to build upon them with 
new versions or levels.


This is the expectation in the WebApps WG, so we are calling for active 
co-editors who will dedicate themselves to the task of driving these 
specs to a stable state in a reasonable and predictable timeframe.



[1] Server-sent Events
http://www.w3.org/TR/2009/WD-eventsource-20091222/

[2] Web Storage
http://www.w3.org/TR/2009/WD-webstorage-20091222/

[3] Web Workers
http://www.w3.org/TR/2009/WD-workers-20091222/

Regards-
Doug Schepers, W3C Team Contact
Art Barstow (Nokia), Co-Chair
Charles McCathieNevile (Opera), Co-Chair,

Re: Call for Editors for Server-sent Events, Web Storage, and Web Workers

[Doug Schepers]

Hi, Ian-

Ian Hickson wrote (on 12/13/10 4:24 PM):

On Mon, 13 Dec 2010, Doug Schepers wrote:


 This is an active call for editors for the Server-sent Events [1], Web
 Storage [2], and Web Workers [3] specifications.  If you are interested
 in becoming an editor, with all the rights and responsibilities that go
 along with that, please respond on this thread or email us directly at
 team-weba...@w3.org.


That's kinda funny since those drafts already all have an active editor.


That's why I was explicit that we are looking for co-editors.  I hope 
that you are willing to work with other editors.




 We appreciate and acknowledge the work the current editor, Ian Hickson,
 has put into these specs, but he seems to have indicated that he does
 not wish to be the one to drive them forward (which is understandable,
 given his other commitments, such as the HTML5 spec).


I have done no such thing. I've only said I'm not interested in doing the
TR/ work.


Ian, the Technical Report work is what W3C does.  You stated that you 
aren't interested in TR work [1], and that you are fine with having 
someone take the draft and regularly publish a REC snapshot of it for 
patent policy purposes [2]... and that's what an editor does.  I'm not 
sure what other way to move forward.  (And to be honest, the tone of 
your emails does not inspire confidence in your willingness to work with 
W3C's framework.)


I'm not playing political games, and I'm not trying to insult you... I 
have been asked to move these specs along more rapidly, and I think 
that's a reasonable request.  Our expectation is that the specs will 
reach a stable state more quickly with an additional editor who can 
dedicate themselves more exclusively to the task.


It may be that no-one is interested or has the time, or that a volunteer 
doesn't have the right skills to manage the task, in which case we have 
no conflict; if it happens that we do find someone to help out, then we 
can discuss the distribution of work.


I'm not trying to shut you out of the process, and I respect any 
feedback you have on the subject.


[1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0865.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0866.html

Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs

Re: Call for Editors for Server-sent Events, Web Storage, and Web Workers

[Doug Schepers]

Hi, Ian-

I'm sorry if it wasn't clear that we hope to keep you on as co-editor, 
if you are willing and able.


I simply don't have time (nor, frankly, am I interested) in having a 
political or philosophical debate about what an editor is or isn't, or 
what makes a spec stable, or whether W3C is structured in the right way 
to meet any given aim.  That conversation would distract and detract 
from the pragmatic goal of finding additional co-editors for these specs.


We are not looking for someone to do mere secretarial work, we are 
looking for people with a stated interest to work within the W3C process 
to move these specs along the W3C Recommendation track at a timely pace. 
 Helping coordinate test suites is part of that, as is making changes 
to the spec based on requirements, implementation experience, and 
working group decisions.



So, I repeat: anyone interested in helping co-edit these specs, please 
contact the chairs or myself, or say so on this list.


Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs


Ian Hickson wrote (on 12/13/10 6:05 PM):

On Mon, 13 Dec 2010, Doug Schepers wrote:


 Ian, the Technical Report work is what W3C does.


I'm not sure how to interpret this. Do you mean that's the work W3C staff
does? Or that's the work that the consortium is set up to foster? Neither
is presumably true: W3C staff aren't the ones who do the TR busywork,
since otherwise you wouldn't be asking for an editor to do it, and the
goal of the consortium is hopefully not to publish TR/ drafts, it's
presumably to get interoperability on the Web.



 You stated that you aren't interested in TR work [1], and that you are
 fine with having someone take the draft and regularly publish a REC
 snapshot of it for patent policy purposes [2]... and that's what an
 editor does.


If that's what you're looking for, my apologies. That was not how I
interpreted your e-mail. It's certainly not what the term editor means
in general, though. What you describe is more of a secretarial role.



 I'm not sure what other way to move forward.


It's not clear to me that your definition of forward makes sense. :-)



 I have been asked to move these specs along more rapidly, and I think
 that's a reasonable request.


Publishing on the TR/ page does nothing to move the specs in any
direction, let alone forward.



 Our expectation is that the specs will reach a stable state more quickly
 with an additional editor who can dedicate themselves more exclusively
 to the task.


Publishing on the TR/ page does nothing for stability. The most productive
work one could do to help the stability of these specs is writing test
suites for them.


Anyway, I'm fine if someone wants to do the secretarial work of publishing
the spec on the TR/ page -- if anyone wants to help with that I'm more
than happy to work with them to get that done on a regular basis. It's
very easy work.

More useful, however, would be someone to drive a test suite. I'd be very
happy to help someone with that too, but that's much more work.

Added 'locale' to Text, Keyboard, and Composition Events [ISSUE-119]

[Doug Schepers]

Hi, folks-

In the latest draft of DOM3 Events [1], I have added a 'locale' 
attribute to the KeyboardEvent, CompositionEvent, and TextEvent 
interfaces, as agreed in telcons and at TPAC.


I took the liberty of renaming 'inputLocale' to 'locale', since most 
developers prefer shorter, nonCamelCased names, and it seems equally 
descriptive.


Please let us know if this satisfies your issue.

[1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html

Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs

Fullscreen API

[Doug Schepers]

Hi, folks-

(BCC public-webapps, public-html.  Apologies for the cross-post)

Various people in various groups (as well as the community at large) 
have been emphasizing the need for fullscreen functionality.  In the SVG 
WG, we had discussed the ability to make the root element fullscreen 
(this was a request a few years ago), but I like the idea of making 
individual elements (including grouping elements) fullscreen instead. 
The Mozilla FullScreen API [1] looks like a good start on this, and 
WebKit has picked up on this as well.


It's been suggested to bring this to the WebApps WG, but there is no 
clear scope for this in the WebApps WG charter, and I'd be concerned 
about rechartering.  the HTML WG was also suggested, but I as I 
understand it, they are trying to limit any new features for HTML5.


Since a fullscreen mode is presentational, it arguably belongs in the 
CSS WG, but there isn't much work there done in APIs (other than CSS OM).


So, my suggestion is that we work on it in the FX TF; we can add it 
explicitly to the SVG (and perhaps CSS) WG charters, which are up for 
review again soon.


Since this is a public list, the WebApps and HTML WG participants could 
review and comment on it there.  To some degree, it doesn't matter where 
it is done, as long as the right stakeholders are involved, and both the 
SVG and CSS WGs have participation by all the major browser vendors, 
among others.


Thoughts?  Is the FX TF willing to take this on?

[1] https://wiki.mozilla.org/Gecko:FullScreenAPI

Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs

Re: publish a new Working Draft of DOM Core; comment deadline March 2

[Doug Schepers]

Hi, Anne-

I object to publishing a Working Draft of the DOM Core spec that 
includes DOM Events.


Introducing conflicting specifications that cover the same materials 
dramatically harms interoperability, and the idea of competing 
specifications is an anti-pattern when it comes to standardization.


If there are changes that you want to the DOM3 Events spec, and if you 
get the support of the browser vendors to make those changes, then I am 
happy to change the spec; I'm not married to the spec as it exists, but 
that is the result of what the last few years of discussing it with the 
browser vendors and users has resulted in.  Please simply raise the 
individual issues on the www-dom mailing list for discussion.  So far, 
I've seen no support on the list for adding events to DOM Core.


Finally, at TPAC, when we discussed working on DOM Core and DOM 3 Events 
in parallel, we did not agree to adding events to DOM Core; in fact, 
we agreed to exactly the opposite: you wanted to move mutation events 
into DOM Core in a thinly-veiled attempt to remove them completely 
(rather than simply deprecate them as is done in DOM3 Events), and all 
the browser vendors disagreed with that.  Claiming otherwise is simply 
an attempt to rewrite history.


So, in summary: please remove section 4, Events, from DOM Core before 
publishing it as a Working Draft, for now.  After serious discussion, if 
the group agrees, we can always add them back later, but I would prefer 
to change DOM3 Events to seeing conflicting specifications.


Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs


Anne van Kesteren wrote (on 2/24/11 5:37 PM):

On Thu, 24 Feb 2011 19:26:19 +0100, Adrian Bateman
adria...@microsoft.com wrote:

I'm concerned about the working group endorsing a working draft with
phrasing like The timeStamp attribute must be useless. I understand
there are issues related to this (e.g. ISSUE-172) but this doesn't
seem like a professional way to approach them.


It's a funny way ;-) And it has a red marker pointing out the problems.
And as stated in the Status of this Document section publication does
not imply endorsement.



I think the document should have a clearly stated goal relative to DOM
L3 Events.


I thought that would be inappropriate since DOM Level 3 Events is still
in development. We discussed this at TPAC and decided that DOM Core
would do things in parallel and based on that we would figure out which
is the better approach once both are somewhat more stable. However,
relative to DOM Level 3 Events the differences are identical. So if that
would remove your objection I can change the 2 to a 3.



Currently it describes building on DOM L3 Core and DOM L2 Events. Anne
described adding events to the draft last week [1] but it's not clear
to me what the benefit of redefining the Event interface in this
document is when W3C is proceeding with DOM L3 Events on the
Recommendation track. If there are things that need to be clarified
specifically for browsers and similar user agents then perhaps a
profile of DOM L3 Events would be better.


The idea is to provide a better definition of the events model at a more
appropriate location. I do not think DOM Level 3 Events is the right way
forward, but I am happy to work in parallel to see which turns out
better in the end.



I'd prefer issues like this to be resolved before endorsing them in a
Working Draft.


Working Drafts are there to share ideas with the wider world. They are
not endorsed. Last Call Working Drafts and beyond are supposed to be
checked carefully. Letting the wider world comment on this idea is
exactly what I would like; to see if it's a good idea.

It would be nice if you could suggest some approach as to how we could
resolve this timely.



[1]
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0559.html

Re: publish a new Working Draft of DOM Core; comment deadline March 2

[Doug Schepers]

Hi, folks-

I have no problem changing the DOM3 Events spec if that's the behavior 
that implementers want specified.  I'd love for it to be as clear, 
simple, and precise as possible, and I have been asking for specific 
feedback for the past few years; while we have gotten a lot of good 
feedback, we did not get feedback asking for these specific changes... 
if we had, and if there was agreement by the browser vendors, we would 
have simply made the changes.


In fairness, it's often easier to start with a blank slate than to 
revise something that's been around for 10 years with several different 
rounds of editors.  I've thought of doing the same with DOM3 Events 
before, and maybe I should have.  So, sometimes things simply become 
more clear when you write them yourself than when you comment on 
existing specs.  I applaud the DOM Core editors taking the initiative to 
revisit assumptions and try to make a cleaner model.


However, what I don't want is for DOM3 Events to be irrelevant, 
incorrect, and misleading by the time it reaches Rec... obviously, we'd 
revise it, but in the meantime, it would be sitting in CR, giving 
implementers the impression that it is the way to get interoperable 
behavior, and that it is relatively stable... having a concurrent 
conflicting spec within the same group is an anti-pattern, when one spec 
is moving toward stability after years of consensus-building around the 
behavior.


(In general, I don't think it is a good practice to make conflicting 
working drafts rather than commenting on existing specifications first; 
I don't think it is an efficient way for a group to proceed (though of 
course conflicting proposals help improve specs in the early stages).)


I don't object to specifying the event model in DOM Core going forward, 
nor to extensions to what is defined in DOM3 Events; I only object to 
conflicts or contradictions between the two specs.  In fact, there are 
changes I would like to have specified in DOM3 Events, but couldn't 
build consensus around for that timeframe, including generic event 
constructors and initializers, rather than initializers for each event; 
I think this is a much better model.


I will remove my objection to publish DOM Core if: 1) conflicts (rather 
than extensions) are removed from the draft, or reconciled with changes 
in DOM3 Events; and 2) for those changes that have broad consensus, we 
can integrate them into DOM3 Events, which means that the changes should 
be sent as comments on DOM3 Events, to be discussed by the group and 
their current status determined.


I had previously started a DOM Core 4 draft specification, but when Anne 
and others volunteered to do Web DOM Core, I moved aside to let them 
work, and volunteered to help with that draft; I would still like to 
help edit that specification, to bring a slightly different perspective 
and approach, and to coordinate between DOM3 Events and DOM Core, and I 
believe we can edit the spec together amicably and productively.


Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs

Re: ISSUE-137 (IME-keypress): Should keypress events fire when using an IME? [DOM3 Events]

[Doug Schepers]

Hi, Hallvord-

The testing we did on this issue was inconsistent between different 
implementations in combination with different IMEs.  So, we did add a 
note mentioning possible key suppression.



http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#key-IME-suppress

Please let us know if this satisfies your issue.

Regards-
-Doug

Web Applications Working Group Issue Tracker wrote (on 10/6/10 2:16 AM):


ISSUE-137 (IME-keypress): Should keypress events fire when using an IME? [DOM3 
Events]

http://www.w3.org/2008/webapps/track/issues/137

Raised by: Doug Schepers
On product: DOM3 Events

Hallvord R. M. 
Steenhttp://lists.w3.org/Archives/Public/www-dom/2010JulSep/0176.html:
[[
current spec text says about the keypress event:


 This event type shall be generated after the keyboard mapping
 but before the processing of an input method editor, normally
 associated with the dispatching of a compositionstart, compositionupdate,
 or compositionend event.


I think this is wrong, if an IME is actively processing the input no
keypress event should fire.
]]

Re: [widgets]

[Doug Schepers]

Hi, Richard-

Depending on your timeline, this could be a v2 feature...

Any interest in following that up?

Regards-
-Doug

Marcos Caceres wrote (on 5/20/11 3:47 PM):

On 5/20/11 5:19 PM, Richard Felton wrote:

Hi,

Hopefully this is the right place to ask this question.

I'm looking at the possibility of using W3C widgets as a web-app
mechanism on an IP connected set-top box. I've had a look through the
specifications available and I can't see a way to pass launch parameters
to a widget. Is this possible or has it been ruled out for good reason?

For example, if I want to write a branded media player application (in a
widget) it'd be useful if I could allow the set-top box user interface
to pass the identifier of the programme to be played into the widget.
Effectively I'm looking for a way for a widget to specify something
similar to command line options so that the launching entity can control
the state the widget starts up in.


There is no standardized means to do this today, I'm afraid. However,
you could either pre-generate the widget to contain such information, or
acquire it from from the set top box through a http request. Another
means might be to create a proprietary feature:

widget ...
feature name=tv:startup
param name=custom_config value={'a': 'b', 'c': 'd'}
feature
/widget

Re: [DOM3Events] CR

[Doug Schepers]

Hi, Anne-

On 9/4/11 9:41 AM, Anne van Kesteren wrote:

On Sun, 04 Sep 2011 15:12:45 +0200, Arthur Barstow
art.bars...@nokia.com wrote:

Some members of the group consider the D3E spec as the highest
priority of our DOM-related specs and they have put considerable
resources into that spec. Doug and Jacob will continue to lead that
spec effort, and as I understand it, a CR for D3E is imminent. I
expect the group to help progress that spec.


I do not think that is appropriate given that unlike all our other
specifications it does not use Web IDL


DOM3 Events does provide Web IDL definitions for the interfaces [1]; it 
simply doesn't make them normative, because Web IDL is not yet stable.


Should the Web IDL spec reach a stable state in time, we can make the 
Web IDL definitions normative.




and we still have not settled how
to deal with exceptions on the web platform.


DOM3 Events doesn't change anything about this.  Should a later spec 
(such as DOM 4 / DOM Core) change how exceptions are handled, and if 
implementers agree with that change, we can simply issue an erratum for 
that in DOM3 Events, and publish an updated draft.  This is a minor and 
common issue... that later specifications supersede previous ones.





Anne, I try not to impute motives behind feedback, but you have been 
putting unusual energy behind undermining and blocking the progress of 
DOM3 Events, including:
* deliberately defining conflicting behavior in a later edition 
specification being developed in parallel with DOM3 Events, without 
raising those issues with the DOM3 Events editors
* refusing to join telcons to which you were invited to discuss issues 
you've raised
* asking other groups (like the Web Performance WG) not to cite DOM3 
Events on the grounds that it is obsolete
* raising issues very late in the process that call for sweeping 
non-technical changes to the spec (such as splitting the spec out into 2 
different specifications)
* claiming that W3C Process has been violated in dealing with your 
feedback, when it had not
* Finally, this email, where you state a false claim (that we don't 
provide Web IDL definitions) and introduce a blocking claim (exception 
handling) that will not be resolved anytime soon and which is not 
critical for the success of the spec and its implementations.


Perhaps these were unintentional missteps on your part, rather than 
deliberate attempts to slow down the progress of the specification, but 
it had the same effect of causing more work for the editors and stalling 
the process.  I don't think this is appropriate behavior for 
participating in a group in good faith, and seems more political than 
technical.


You have also provided good feedback to the spec, which we have 
incorporated and which we appreciate.  This spec, with feedback from 
crucial implementers and reviewers, provides incremental and substantial 
improvements to the Open Web Platform, such as a much-needed 
standardized keyboard model, and I suggest that any further improvements 
needed can be made in a later DOM spec.


Can we simply move forward, please?


[1] http://www.w3.org/TR/DOM-Level-3-Events/#webidl-definitions

Regards-
-Doug Schepers
W3C Developer Outreach
Project Coordinator, SVG, WebApps, Touch Events, and Audio WGs

Re: [DOM3Events] CR

[Doug Schepers]

On 9/4/11 12:49 PM, Charles Pritchard wrote:


Is there a wiki page or other resource for looking into implementation
status on DOM3Events?
It's a large spec, and I'd like to plan for it in our internal roadmap.


We will be building a complete test suite and implementation report 
during CR phase, which is the traditional time that stuff is done.


Informally, I believe that IE9+ implements all of the normative 
assertions in the DOM3 Events spec (there could be minor details that 
need better testing), and most of the spec is implemented in other 
browsers, since much of it is based on existing browser features.


I think the least coverage is in one of the most important features, the 
keyboard model; I would love to see this implemented in more browsers 
than just IE, but haven't been able to get anyone to prioritize it yet. 
 'mouseenter' and 'mouseleave' also need broader support (John Resig 
was just asking me to expedite this the other day, on behalf of jQuery).




I'm no fan of event.pageX, but it's very heavily used in our code base.
Our screenX hooks, when written, were targeting Adobe's Flash event
namespaces. It's mentioned once, in DOM3Events, in the legacy context of
initMouseEvent.


I believe the right place to deal with that is in the CSS Object Model 
specs.



(Snipping discussion of DOM 4.  I don't want to muddy the issue of 
moving DOM3 Events to CR with discussions of a later spec.  Those issues 
should be dealt with in another thread.)


Regards-
-Doug

Mouse vs. Touch Events (was: [DOM3Events] CR)

[Doug Schepers]

Hi, Charles-

(Renaming thread, because this is not relevant to moving DOM3 Events to CR)


On 9/4/11 1:27 PM, Charles Pritchard wrote:

On 9/4/11 10:06 AM, Doug Schepers wrote:

On 9/4/11 12:49 PM, Charles Pritchard wrote:


Is there a wiki page or other resource for looking into implementation
status on DOM3Events?
It's a large spec, and I'd like to plan for it in our internal roadmap.


We will be building a complete test suite and implementation report
during CR phase, which is the traditional time that stuff is done.

Informally, I believe that IE9+ implements all of the normative
assertions in the DOM3 Events spec (there could be minor details that
need better testing), and most of the spec is implemented in other
browsers, since much of it is based on existing browser features.

I think the least coverage is in one of the most important features,
the keyboard model; I would love to see this implemented in more
browsers than just IE, but haven't been able to get anyone to
prioritize it yet. 'mouseenter' and 'mouseleave' also need broader
support (John Resig was just asking me to expedite this the other day,
on behalf of jQuery).


I've got a bad situation with Apple's VoiceOver on Mobile Safari. As
they have not taken any steps to improve Canvas accessibility, I'm in
the unfortunate position of only having self-voicing via audio tags.

Is mouseenter and mouseleave intended for touch events as well? On
Mobile Safari's eyes-free interface, a user simply drags their touch
across the screen, and as it enters various elements, the elements are
voiced. The user then double-taps to focus on a given element.



It's a whole-lot-of-work to re-implement that from scratch. mouseenter
and mouseleave would lessen that burden. But, it is a touch* system, vs
a mouse* system, at it's core.


I suggest you raise this in the context of the touch stuff in the Web 
Events WG (where we are doing the Touch Interface spec).




Do you remember which list was discussing the addition of a MouseCoords
method being available on mouse events? I believe the thought originated
from the SVG realm.


We discussed it here, but decided that that would be better dealt with 
in the new CSS transforms and SVG2 specs.



Regards-
-Doug

Re: [editing] Using public-webapps for editing discussion

[Doug Schepers]

Hi, Charles-

I understand that it is frustrating to butt heads with a set of people 
who all share similar perspective and priorities, if you do not share 
those particular views.


However, I don't think it's productive to impute that a specific company 
is pushing their agenda, or blocking progress on other efforts.  For 
example, I've spoken to many Google people with different perspectives 
and goals (often at odds with other Googlers), and there are also many 
people outside Google who share some of the same opinions and methods as 
Hixie, Tab, and Aryeh, like Anne, Ms2ger, Marcos, Maciej, and many 
others (though there are many ways in which they all differ, as well).


Nor is this the only cadre of like minds in W3C and web standards; the 
accessibility community, the XML community, the SVG community... many 
people with similar backgrounds or interests tend to bond and work 
together toward a goal.


Google is a diverse company with a wide diversity of opinions, like many 
companies; if they are active in web standards, it should be no 
surprise, since they are a Web company, with a search engine, browser, 
advertising service, and many prominent webapps.  I don't think it's 
accurate or productive to single Google out as some sort of bad player 
here.


If you differ with individuals or sets of individuals, that is certainly 
a valid critique, is it is kept to the topic of process, working 
methods, or technical matters.  Please don't stray into the slippery 
slope of accusing companies of malice.  Instead, raise technical issues, 
with solid use cases and requirements, and defend your point.


That said, if you (or anyone) believe that there is collusion or willful 
or abusive disregard of comments (yours or anyone else's), then bring it 
to the attention of me or the chairs, and we will look into it.


In the case of the HTML Editing APIs, I haven't seen anything 
particularly harmful yet... we're in an experimental stage with 
Community Groups, and I think it's healthy to look at alternative 
working modes and processes.


So... please tone it down a bit... don't risk being seen as the guy who 
screams, Company X is evil!!!, because nobody listens to that guy. ^_^


Thanks-
-Doug Schepers
W3C Developer Outreach
Project Coordinator, SVG, WebApps, Touch Events, and Audio WGs



On 9/16/11 1:44 PM, Charles Pritchard wrote:

On 9/15/2011 1:26 PM, Aryeh Gregor wrote:

 Apple, Google and Microsoft representatives have vetoed rich text
editing as
 a supported use case for public-canvas-api, the Google/WHATWG editing
 specification is now the -only- supported solution for developers
to author
 editing environments.

It is not accurate to refer to the specification as Google or WHATWG.
It's in the public domain, so Google has no more right to it than
anyone else. Google paid for its development up to this point, but no
one from Google but me has exercised any discretion as to its
contents, and I'll continue working on it under different employment
if necessary. The spec has nothing to do with the WHATWG, except that
I used their mailing list for a while.


Google's support of editors is a net benefit for all of us. I greatly
appreciate the CC0 license that you and other editors have put onto your
specs.

That said, Google's support of various editors that have disdain for W3C
process, has real-world consequences.
You're not alone, amongst your co-workers when you state:
I don't believe that the W3C Process is useful, and in fact I think
it's actively harmful

I don't think it's malicious. But, Google has unprecedented control over
these W3C specs.
They are absolutely using that control to benefit their priorities.
That's their right, as you say:
my time is my own or my employer's, and no one else has any right to
place demands on how I spend it.

This puts non-vendors in a bad situation. Where Google has purchased the
space to play both sides of the game, the rest of us are struggling to
have our use cases accepted as legitimate. By funding so many editors,
for so many years, they gained control of the specs. That's fine... But
the specs are now driven by individuals who have no deference to the
W3C, and thus, no deference to the use cases that various member
organizations and developers are -actively- engaged in.

Yes, you have a public domain document, and yes, you're likely in the
same boat as Tab Atkins:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1265.html
The editor is the *lowest* level in the hierarchy of constituencies

The vendor implementation is the highest level... Your company has the
full vertical.

They use that position to knock-down use cases. When a use case serves
Google Docs, or Gmail, it's heard. When it does not, it's shuttered.

That's a problem. And it comes up again and again. With all of the best
intentions, you are a part of that group.

It's not a malicious interaction, it's not something I'm overly
concerned about. But it is real.

Lucky for all of us

Important: TPAC Registration

[Doug Schepers]

Hi, folks-

In case you don't know, TPAC (Technical Plenary and Advisory Committee 
meeting) is W3C's yearly plenary meeting, where all the different 
working groups have a chance to come together, to schedule joint 
meetings, to collaborate in person, and to meet as groups.  It's a 
really productive event.


Registration for TPAC has been a bit slow this year, so I'm reminding 
you all to register now if you intend to go:


  http://www.w3.org/2002/09/wbs/35125/TPAC2011/

Registration ends 14 October 2011... only 3 weeks away.

Go register.  Please.  Now.  Don't finish reading this email, just go 
register.  Then finish reading this email.



Note that there is a daily event fee of $50 USD (which goes up to $150 
USD after 14 October).




The event is happening at the Santa Clara Marriott hotel, Santa Clara, 
California, USA.


There is a guest rate blocked off for the special $169 USD rate.  This 
room rate is only available until 10 October 2011 (4 days _before_ TPAC 
registration ends), so don't delay in booking your room as well...



If you haven't already gotten travel permission from your organization, 
now is the time to do that.  Flights will be getting more expensive as 
the date looms ever closer.



Please don't make me nag you like your mother again.  I'll do it... I'm 
not proud.



Here's some info:


TPAC2011 Overview page:
http://www.w3.org/2011/11/TPAC/

TPAC2011 Groups Schedule:
http://www.w3.org/2011/11/TPAC/#Finalized

TPAC2011 Registration by Groups:
http://www.w3.org/2002/09/wbs/35125/TPAC2011/registrants


Regards-
-Doug

Re: Mutation Observers: a replacement for DOM Mutation Events

[Doug Schepers]

Hi, Adam-

I'm glad to see some progress on a replacement for Mutation Events.

Would you be interested in being the editor for this spec?  It's already 
in our charter, we just need someone to take it up.  Olli has offered 
offlist to be a co-editor, so between the two of you, I think it would 
be pretty manageable.


I'd be happy to help get you started.

Thanks-
-Doug (W3C staff contact for WebApps WG)

On 9/23/11 5:16 PM, Adam Klein wrote:

Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
proposal for a replacement for Mutation Events.

This proposal represents our best attempt to date at making a set of
sensible trade offs which allows for a new mutation observation
mechanism that:

- Is free of the faults of the existing Mutation Events mechanism
(enumerated in detail here:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html)

- Meets the goal of having the main “questions” that use-cases will
need answered about the net-effect of changes, be computable in linear
time complexity roughly proportional to the number of changes that
occurred.

Significant aspects of this design:

- Delivery of MutationRecords happens asynchronously, at the end of
the current “microtask”. This is between Options 2 and 3 from this
discussion 
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html.
Instead of calling listeners at the end of outermost DOM operation or
at the end of a Task, listeners are called at the end of outermost
script invocation. If there are no script invocations, listeners are
called at the end of Task.

- Information about mutations is delivered to observers as an ordered
sequence of MutationRecords, representing an observed sequence of
changes that have occurred.

- Subtree observation properly handles the case where nodes are
transiently removed from, mutated outside of and then returned to the
subtree.

- Observers specify the types of changes they are interested in and
(in some cases) level of detail they require.

Sample usage:

var observer = new MutationObserver(function(mutationRecords) {
   // Handle mutations
});

observer.observe(myNode,
{  // options:
   subtree: true;  // observe the subtree rooted at myNode
   childList: true;  // include information childNode insertion/removals
   attribute: true;  // include information about changes to attributes
within the subtree
});

…

observer.disconnect();  // Cease observation

Details:

We introduce a new interface MutationObserver with a constructor on DOMWindow:

[Constructor(in MutationCallback callback)]
interface MutationObserver {
void observe(in Node target, in MutationObserverOptions options);
void disconnect();
};

where MutationCallback is

[Callback, NoInterfaceObject]
interface MutationCallback {
 void handleEvent(in MutationRecord[] mutations, in
MutationObserver observer);
};

Registration  Observation
- A call to observe creates a registration for the observer to be
delivered mutations made to |target|, and optionally, its descendants.

- Subsequent calls to the same MutationObserver made with the same
|target| have the effect of resetting the options associated with the
registration.

- Subsequent calls to the same MutationObserver made with different
|targets| have the effect of expanding the set of nodes which are
being observed by the observer. All mutations made to all observed
nodes in all registrations for a given observer are delivered, in
time-ordered sequence, via a single invocation of the
MutationCallback’s handleEvent method.

- disconnect ceases observation over the observer’s set of observed nodes.

Registration Options
The |options| argument provided in observe is defined by the
MutationObserverOptions interface:

interface MutationObserverOptions {
 // Mutation types
 boolean childList;  // If true, mutations affecting node’s
childNodes are included.
 boolean attribute;  // If true, mutations affecting element’s
attributes are included.
 boolean characterData;  // If true, mutations affecting the value
of CharacterData
 //nodes are included.
 // [Note: If none of the known mutation types is specified, an
Error is thrown]

 // Subtree observation
 boolean subtree;  // If true, the observed set of nodes for this
registration should include
  // descendants of MutationTarget
(behavior described below).

 // Old values
 boolean attributeOldValue;
 // If true, MutationRecords describing changes to attributes should
 // contain the value of the attribute before the change. If true
 // without attribute: true specified, an Error is thrown.

 boolean characterDataOldValue;
 // If true, MutationRecords describing changes to
 // CharacterData nodes should contain the value
 // of the node before the change. If true without
 // characterData: 

[editing] Feedback Link?

[Doug Schepers]

Hi, Aryeh-

In the status section of the HTML Editing APIs spec [1], you have 
detailed instructions for how people should provide feedback, but the 
links you provide are to the pubic-webapps archive and to your personal 
email, rather than a mailto link to the list.


It might be handy provide an encoded mailto link to make it easier for 
people to start a discussion, like this:


a 
href=mailto:public-webapps@w3.org?cc=a...@aryeh.namesubject=%5Bediting%5D%20;discussion 
on the HTML Editing APIs specification/a (a 
href=http://www.w3.org/Search/Mail/Public/search?type-index=public-webappsindex-type=tkeywords=[editing];public-webapps 
archive/a)



[1] 
http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#status-of-this-document


Regards-
-Doug Schepers
W3C Developer Relations
Project Coordinator, SVG, WebApps, Touch Events, and Audio WGs

Testing Expectations (was: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization)

[Doug Schepers]

Hi, folks-

On 1/11/12 9:40 AM, Arthur Barstow wrote:

On 1/10/12 11:25 AM, ext Glen Shires wrote:

Per #4 Testing commitment(s): can you elaborate on what you would like
to see at this point?


At this point, I think a `warm fuzzy` like if/when the spec advances to
Candidate Recommendation, we will contribute to a test suite that is
sufficient to exit the CR would be useful.


I agree with this general sentiment, but I'd like to offer a different 
priority to tests.


Technically, the W3C Process does not require a test suite, but 
pragmatically, it's the best way to indicate conformance and 
implementability, and to promote interoperability.


Modern expectations (e.g. in the last 4-6 years) about the specification 
process include early prototyping and implementation feedback well 
before CR phase, with real-world webapps depending upon these early 
implementations, so we need interoperability fairly early on.


The infrastructure and methodology for creating and maintaining tests 
(at W3C and in implementation projects) has improved dramatically in the 
last few years as well, so it's easier to do.


As such, the creation of tests should not be left to CR... there should 
be a plan in place (e.g. a person, and a loose policy, like as we 
implement, we'll make tests and contribute them to the WG), and a 
person responsible for collecting and maintaining the tests (i.e. making 
sure that the tests are adapted to meet the changing spec).


Regards-
-Doug

Call for Review: Web Audio API

[Doug Schepers]

Hi, folks-

The Audio Working Group published an updated Working Draft of Web Audio 
API [1] on 15 March 2012. From the introduction:


[[
This specification describes a high-level JavaScript API for processing 
and synthesizing audio in web applications. The primary paradigm is of 
an audio routing graph, where a number of AudioNode objects are 
connected together to define the overall audio rendering. The actual 
processing will primarily take place in the underlying implementation 
(typically optimized Assembly / C / C++ code), but direct JavaScript 
processing and synthesis is also supported.

]]

We would appreciate review and feedback on the spec [1] and the use 
cases and requirements [2] from the participants in the WebRTC, WebApps, 
and HTML groups and the Media Capture task force.


[1] http://www.w3.org/TR/2012/WD-webaudio-20120315/
[2] http://www.w3.org/2011/audio/wiki/Use_Cases_and_Requirements

Regards-
-Doug Schepers
On behalf of the Audio WG

[charter] Addressable Ranges?

[Doug Schepers]

Hi, folks–

I'd like to ask for feedback on the notion of adding addressable 
ranges to the WebApps WG charter.


There are a set of use cases for being able to link to a specific 
passage of text in a document, which has a number of what I consider 
hard problems:

* the passage might cross element boundaries
* someone linking into the document usually doesn't have write access to 
the document such that they can insert permanent markers into the text
* documents might change: the passage may have moved, been slightly 
altered, or even been completely removed
* many other considerations (including single-page vs. multi-page 
versions of the same document, near-duplicates of the document at 
different URLs, etc.)


I bring this to the WebApps WG for a couple reasons:
* there are related deliverables and discussions already underway, 
including the new Selections API work from Niwa, the Clipboard API work, 
and the discussions around a Find API
* if this is ever going to happen, this is the right community of 
developers and browser vendors to discuss the different challenges and 
possibilities


This work might take a while before we consider it ready for serious 
consideration for implementation and deployment in browsers, but I'd 
like to start the conversation now so we can keep this in mind while 
developing related features, and build toward some tangible outcome in 
the not-too-distant future.


Because finding a solution to this would be a major goal of the proposed 
Web Annotations WG, it would be nice if this could be a joint 
deliverable of both groups. While we propose to have the conversation on 
public-webapps (for the widest and most critical review), the Web 
Annotations WG will provide an Editor and a Test Lead, and we would 
prefer to have a co-Editor from WebApps.


Regards-
-Doug

Re: [charter] Addressable Ranges?

[Doug Schepers]

Hi, Art–

There are different approaches that could be taken, but one concrete 
implementation in JavaScript is from the Hypothes.is Annotator [1].


https://hypothes.is/blog/fuzzy-anchoring/

Regards–
–Doug

On 4/22/14 9:04 AM, Arthur Barstow wrote:

Hi Doug,

Do you have some prior art/work for this functionality (that could help
people get a bit deeper understanding of the proposal)?

All - if you have any feedback - both positive/+1 or negative - please
do speak up by April 25 at the latest.

-Thanks, AB

On 4/18/14 3:45 PM, Doug Schepers wrote:

Hi, folks–

I'd like to ask for feedback on the notion of adding addressable
ranges to the WebApps WG charter.

There are a set of use cases for being able to link to a specific
passage of text in a document, which has a number of what I consider
hard problems:
* the passage might cross element boundaries
* someone linking into the document usually doesn't have write access
to the document such that they can insert permanent markers into the text
* documents might change: the passage may have moved, been slightly
altered, or even been completely removed
* many other considerations (including single-page vs. multi-page
versions of the same document, near-duplicates of the document at
different URLs, etc.)

I bring this to the WebApps WG for a couple reasons:
* there are related deliverables and discussions already underway,
including the new Selections API work from Niwa, the Clipboard API
work, and the discussions around a Find API
* if this is ever going to happen, this is the right community of
developers and browser vendors to discuss the different challenges and
possibilities

This work might take a while before we consider it ready for serious
consideration for implementation and deployment in browsers, but I'd
like to start the conversation now so we can keep this in mind while
developing related features, and build toward some tangible outcome in
the not-too-distant future.

Because finding a solution to this would be a major goal of the
proposed Web Annotations WG, it would be nice if this could be a joint
deliverable of both groups. While we propose to have the conversation
on public-webapps (for the widest and most critical review), the Web
Annotations WG will provide an Editor and a Test Lead, and we would
prefer to have a co-Editor from WebApps.

Regards-
-Doug

Re: [charter] Addressable Ranges?

[Doug Schepers]

Hi, Art–

Following on from the discussion at the AC, here is my suggested wording:

[[
Robust Anchoring API

Defines APIs for finding, addressing, and linking to a document 
selection based on a set of selectors, even when the document has 
changed. This may be a joint deliverable with the proposed Web 
Annotations WG.

]]

The timeline is for a FPWD in Q2-2015, with a Rec in Q4-2016; this needs 
some development, though I hope we can make good progress.


The group liaison could be:

[[
Web Annotations Working Group
This proposed group is interested in several of WebApps' specifications, 
as well as having a joint deliverable (Robust Anchoring API).

]]

We have resources to work on this deliverable, including an editor. This 
deliverable is being added for consideration by the AC during review; if 
not accepted by the AC, then the Web Annotations WG will work on it 
alone, but I'd rather it were developed under the eyes of the WebApps WG.


Any other details you need?

Regards-
-Doug

On 5/14/14 8:54 AM, Arthur Barstow wrote:

On 4/25/14 8:44 AM, Arthur Barstow wrote:

On 4/22/14 9:40 AM, Doug Schepers wrote:

Hi, Art–

There are different approaches that could be taken, but one concrete
implementation in JavaScript is from the Hypothes.is Annotator [1].

https://hypothes.is/blog/fuzzy-anchoring/


OK, so at this point, I think it would be helpful if you would please
provide a diff or a PR against
https://github.com/AFBarstow/WebApps/blob/master/charter.html
(http://afbarstow.github.io/WebApps/charter.html) so we can evaluate
your specific proposal.


Doug - are you going to provide a diff? Without a relatively firm
commitment from WebApps, my inclination is to not add this to the charter.

Philippe - what is the next step to get WebApps re-chartered (current
charter expires May 31)?

-Thanks, AB

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Doug Schepers]

Hi, Yosi–

On 10/6/15 9:30 PM, Yoshifumi Inoue wrote:

It's exciting!


Thanks!



For Shadow DOM, current Blink implementation traverses composed tree
rather than DOM tree. We introduced a concept position in composed
tree and ephemeral range in composed tree; "ephemeral" means range in
composed tree isn't live. Ephemeral range objects aren't update at
DOM mutation.

A continuation position, e.g. highlight find result, is specified by
composed tree position but implemented in collapsed range, since
positions in composed tree can be represented by DOM node position.


Makes sense.



From implementation, FindText.cursor is very expensive, UA needs to
serialize DOM nodes to plain text to get DOM node and offset. Note:
Blink has an implementation for this called PlainTextRange for IME
API.

I would like to proposed FindText API to be defined top on Text
Iteration API or Plain Text Serialization API, both of them aren't
specified yet, instead of Node.textContent. These API can define
HTMLElement.innerText, not standard but most of UA have it and
causes interoperability issue, and plain text format of clipboard.


Sure, I definitely want to do this in the most efficient way possible.

I'm happy to help define a Text Iteration API or Plain Text 
Serialization API; I'm no expert in that, but I can help with the 
editing work. Do you have any more information about those?




Just FYI: Here is a presentation from Yandex presented on last November
on Blink On conference:
*
https://docs.google.com/presentation/d/18UHSNEqkFW2toj7Qfo5CcuTuQsFLOibbAMq2VSWoE4I/edit?usp=sharing
*
https://docs.google.com/document/d/1HlPDpwXzzuKp0n5qkKaIL9mYkjtlQHD37OF5pHQuXtE/edit?usp=sharing


Cool, thanks for sharing that! Looks like Konstantin and Andrey from 
Yandex would be good people to get in on this discussion. I'll point 
them to this thread.


Regards–
–Doug



2015年10月7日(水) 7:55 Doug Schepers <schep...@w3.org
<mailto:schep...@w3.org>>:

Hi, Tab–

Thanks for the correction. I assumed that Houdini would expose more of
the underpinnings of the ::selection pseudo-element [1] and its ilk.
Maybe that hasn't surfaced (and maybe it won't). It does seem to be more
magic, though, which I'd thought we were trying to demystify.

But if there's no good story in Shadow DOM for things that explicitly
deal with Range, I think that needs a solution.


FWIW, JavaScript source-maps can comfortably deal with a similar
problem, with minified/cached versions of multiple source documents
(though I guess not multiple instantiations of the same source
document). Still, I'd expect there's a non-terrible solution for
serializing and expanding Shadow DOMs and pinpointing specific
instantiations.

(This makes me wonder how Shadow DOM is dealing with accessibility APIs;
I'm assuming there's a good story there, and maybe something we can draw
upon.)

[1] https://drafts.csswg.org/css-pseudo-4/#highlight-selectors

Regards–
–Doug

On 10/6/15 6:38 PM, Tab Atkins Jr. wrote:
 > On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers <schep...@w3.org
<mailto:schep...@w3.org>> wrote:
 >> Hi, Eliott–
 >>
 >> Good question.
 >>
 >> I don't have a great answer yet, but this is something that will
need to be
 >> worked out with Shadow DOM, not just for this spec, but for
Selection API
 >> and others, as well as to CSS, which has some Range-like styling.
 >
 > CSS doesn't care about this, because it doesn't expose its selections
 > to the wider DOM; it can freely style whatever it wants, including
 > ranges that span into shadows.
 >
 > This is indeed equivalent to the problem that the generic Selection
 > API has with Shadow DOM, tho.
 >
 > ~TJ
 >

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Doug Schepers]

Hi, Raphaël–

Yes, this is one narrowly-scoped piece of generalized functionality that 
we hope can get broad agreement and implementation.


It's just one of the building blocks of a full set of robust anchoring 
features, some of which might be standardized, but which may actually be 
done in script. We'll most likely gather together those pieces in the 
sort of umbrella document you suggest… maybe something like "Mapping Web 
Annotation Data Model Selectors to Client-side APIs" (or something more 
pithy.


Regards–
–Doug

On 10/7/15 11:56 AM, Raphaël Troncy wrote:

This is a call for consensus (CfC) to publish a First Public Working
Draft (FPWD) of FindText API; deadline 14 October (1 week)
This FindText API is joint deliverable of the WebApps WG and Web
Annotation WG (listed as "Robust Anchoring" in the charters [1], [2]).


+1 for publishing this document as FPWD but one clarification request:
the original "Robust Anchoring" had a wide scope covering various types
of documents while the FindText API document focuses on textual
documents. Would there be another "umbrella document" produced by the
Working Group that would refer to various specifications to perform
robust anchoring on various type of documents, such as listing the
FindText API, the CSV fragment RFC 7111, the Media Fragments API, etc. ?
Best regards.

   Raphaël

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Doug Schepers]

Hi, Eliott–

Good question.

I don't have a great answer yet, but this is something that will need to 
be worked out with Shadow DOM, not just for this spec, but for Selection 
API and others, as well as to CSS, which has some Range-like styling.


I don't know if this means a change to Shadow DOM, to Range, or to 
FindText and other specs.


If there were a better way of representing non-element document segments 
than ranges, one that's more friendly to Shadow DOM, I'd be open to that 
as a return / representation type. I just don't know what that would be; 
if someone has a suggestion, please let me know.


In the meantime, could you raise that as an issue [1]? Or I can do it by 
proxy.


[1] https://github.com/w3c/findtext/

Regards–
–Doug

On 10/6/15 4:49 PM, Elliott Sprehn wrote:

How does this work with shadow dom? Range is not very friendly to that.

On Oct 6, 2015 4:35 PM, "Frederick Hirsch" > wrote:

This is a call for consensus (CfC) to publish a First Public Working
Draft (FPWD) of FindText API; deadline 14 October (1 week)

This FindText API is joint deliverable of the WebApps WG and Web
Annotation WG (listed as "Robust Anchoring" in the charters [1], [2]).

This is a Call for Consensus (CfC) to publish a FPWD of the FindText
API, using the following Editor's Draft as the basis:

http://w3c.github.io/findtext/

"This specification describes an API for finding ranges of text in a
document or part of a document, using a variety of selection criteria."

This API was presented to the WebApps WG last TPAC under a different
name, and with a fairly different design; it was modified to fit the
feedback from that meeting and from others, including narrowing of
scope, the introduction of Promises, and exposing low-level
functionality in the spirit of the Extensible Web.

The specification is largely based on the Annotator JavaScript
library's "robust anchoring" code, and a standalone polyfill is
under development. Feedback from possible implementers is especially
welcome.

This CfC satisfies the group's requirement to "record the groups'
decision to request advancement".

By publishing this FPWD, the group sends a signal to the community
to begin reviewing the document. The FPWD reflects where the groups
are on this spec at the time of publication; it does _not_
necessarily mean there is consensus on the spec's contents and the
specification may be updated.

If you have any comments or concerns about this CfC, please reply to
this e-mail by 14 October at the latest. Positive response is
preferred and encouraged, even a +1 will do  Silence will be
considered as agreement with the proposal.

regards, Frederick & Rob

Frederick Hirsch, Rob Sanderson

Co-Chairs, W3C Web Annotation WG

www.fjhirsch.com 
@fjhirsch

[1] http://www.w3.org/2014/06/webapps-charter.html#deliverables

[2] http://www.w3.org/annotation/charter/#scope

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Doug Schepers]

Hi, Tab–

Thanks for the correction. I assumed that Houdini would expose more of 
the underpinnings of the ::selection pseudo-element [1] and its ilk. 
Maybe that hasn't surfaced (and maybe it won't). It does seem to be more 
magic, though, which I'd thought we were trying to demystify.


But if there's no good story in Shadow DOM for things that explicitly 
deal with Range, I think that needs a solution.



FWIW, JavaScript source-maps can comfortably deal with a similar 
problem, with minified/cached versions of multiple source documents 
(though I guess not multiple instantiations of the same source 
document). Still, I'd expect there's a non-terrible solution for 
serializing and expanding Shadow DOMs and pinpointing specific 
instantiations.


(This makes me wonder how Shadow DOM is dealing with accessibility APIs; 
I'm assuming there's a good story there, and maybe something we can draw 
upon.)


[1] https://drafts.csswg.org/css-pseudo-4/#highlight-selectors

Regards–
–Doug

On 10/6/15 6:38 PM, Tab Atkins Jr. wrote:

On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers <schep...@w3.org> wrote:

Hi, Eliott–

Good question.

I don't have a great answer yet, but this is something that will need to be
worked out with Shadow DOM, not just for this spec, but for Selection API
and others, as well as to CSS, which has some Range-like styling.


CSS doesn't care about this, because it doesn't expose its selections
to the wider DOM; it can freely style whatever it wants, including
ranges that span into shadows.

This is indeed equivalent to the problem that the generic Selection
API has with Shadow DOM, tho.

~TJ