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, 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, 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

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: [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

[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

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

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

[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

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: 

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: [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

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: [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: 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: 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: 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

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

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

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.

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?

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: 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

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: 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/

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: 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: 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: 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: 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

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: [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

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: Items not listed as new in the draft charter

[Doug Schepers]

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

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

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: Event handlers - Pointer Devices

[Doug Schepers]

Hi, Bryan-

SULLIVAN, BRYAN L (ATTCINW) wrote (on 3/4/10 9:15 AM):

This might be better discussed by the DAP group, as it's clearly a
device API topic.


By that definition, a mouse would be a device. :)  This work belongs in 
the WebApps WG, and it is explicitly mentioned in our charter, to be 
taken up during our next charter period.


DAP is not focused on user-input devices, more on things like cameras, 
calendars, etc. available on the local device.




Also it would be interesting to hear from Apple and Wacom (without
unnecessary details at this point), what areas of touch interface
capabilities would be problematic for W3C to create API's for, from an
IPR perspective (i.e. that would probably result in exclusions)... this
concern is driven e.g. by the current touch-related issue between Apple
and HTC.


This is putting the cart before the horse.  It's not appropriate to 
discuss IPR at this point, since we don't even have a draft spec (by 
design).  Once we have a draft of the spec, participants who have IPR 
can have their legal team look at it and chime in at that point (though 
this may take place in Member space, since they may wish to do so under 
the legal framework of W3C Member confidentiality).


I am concerned that it may not be fruitful, and may be 
counterproductive, for us to start speculating on this list about IPR. 
Let's keep the discussion on technical matters, please.


However, use cases and requirements would be appropriate to discuss, and 
this should help frame a successful outcome for this spec.


[1] http://www.w3.org/2009/05/DeviceAPICharter

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

Re: Notifications

[Doug Schepers]

Hi, Folks-

We should put together a use case and requirements document (or section 
of the spec) to scope out this work.  I know it seems like makework, but 
it can help resolve many issues later on, and serve as a measure of the 
maturity and success of the spec in meeting its goals.


I've started a simple wiki page to kick this off:
 http://www.w3.org/2008/webapps/wiki/Web_Notifications

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


Drew Wilson wrote (on 2/23/10 5:26 PM):


2010/2/23 Jonas Sicking jo...@sicking.cc

The same is not true for the suggest notification API. Several
proposals have been put forward that do not rely on fallback.

One of the reasons I stepped back from this discussion is because it
seemed clear that we weren't going to make progress on solutions until
we had agreement on requirements (specifically, the amount of
interaction that we want to enable in these notifications). The
non-fallback proposals that have been put forward aren't acceptable to
me for the same reasons that Jonas is opposed to the fallback proposals
- we both have a different vision for what the requirements should be.
I'd like to see us focus on gaining some consensus around requirements,
because I think the rest of these disagreements will mostly resolve
themselves once we do that.

-atw

Re: Notifications

[Doug Schepers]

Hi, Ian-

I generally agree with you, and certainly with your sentiment.  Not to 
go all SVG on you, but why *HTMLNotification?  I understand that HTML 
is really common, and that increasingly SVG can be used as part of HTML, 
but there are lots of devices out there (TVs, mobiles, set-top boxes) 
that use SVG rather than HTML, which would benefit from these 
interactive notifications... shouldn't we define a more generic 
CreateWebNotification and pass an optional MIME Type parameter that 
defaults to text/html (or some similar mechanism)?


I strongly agree with the sentiment that we should design for the 
future, in any case, and not limit ourselves to simple text notifications.


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


Ian Fette (イアンフェッティ) wrote (on 2/23/10 1:06 PM):

This thread seems to have languished, and I'm trying to figure out how
to move forward here.

My understanding, grossly simplified, of the current state of the world
is this:

1. Some people have a desire to show HTML / interactive notifications,
to support use cases like remind me of this calendar event again in 5
minutes or Answer this call / hang up this call.
2. Some people have a concern that the proposed way to achieve 1, namely
allowing HTML, will result in certain platform notification systems
(Growl, NotifyOSD etc) not to be used.

I will disclose my biases up front and say that I do believe the use
cases that 1) tries to support are important. (I want to be able to
interact with a calendar notification to say remind me again or take
me to the full details of the event, for instance). I also am of the
belief regarding #2, being unable to find any actual data on how many
users have and use growl, that the user base falls into roughly two
camps. There's the people who have gone out and downloaded Growl (or
another notification service) because they want everything coalesced,
and then there's the people who don't really care, and if mail.app wants
to tell them something vs their browser wants to tell them something,
they don't really think much of it.

I think that initially, we can do a lot more for this second group in
terms of functionality that we can provide, and would find it
unfortunate if we held up forward progress because of a current
implementation detail. If that functionality proves to be useful and
desired by a number of users, I believe that platforms like Growl and
NotifyOSD will find a way to make it work. In the meantime though, I
think there are relatively simple things we can do to not leave these
users in the dark.

1, for the CreateHTMLNotification call, we could still allow a text
version of the notification to be provided. If there's a significant
number of users whose platforms don't support HTML Notifications, I
think there's a reasonable chance that would be filled out. If 20% of
users didn't see images, alt= text would be more prevalent.
2. For the case where there is no text alternative provided by the
website for the HTML notification, the UA can make a best effort at
transforming the HTML notification to a text notification, optionally
with whatever markup the UA provides for text notifications (bold,
links, etc). Obviously things may not be perfect and it would be
preferable if the author of the page provided a notification, but the
world is not perfect.
3. Let the user decide which notification mechanism they prefer. If the
user prefers HTML notifications, then they get whatever the UA
implements. If the user has an alternate notification provider they
prefer, then they live with the constraints of that notification system,
but either way it's a tradeoff that the user can make. And yes, in the
near term some of this may be prohibitive on mobile devices, but so are
many things (try as they might, mobile browsers still aren't a pleasure
to work with when it comes to viewing large complex sites or sites that
use flash, etc).

I strongly believe that web applications are increasing in number, in
scope, and are becoming an integral part of people's lives. As web
applications expand, I don't think it is unreasonable to believe that
support for HTML in the platform (e.g. HTML in notification providers)
will happen some day. It's not going to be immediate, and so I have
outlined some ideas that I hope may get us moving in the meanwhile, but
I don't want us to fall victim to the argument of well, right now it's
hard so let's not do it.

My $0.02.

Am 12. Februar 2010 12:50 schrieb John Gregg john...@google.com
mailto:john...@google.com:


On Fri, Feb 12, 2010 at 10:14 AM, Drew Wilson atwil...@google.com
mailto:atwil...@google.com wrote:

On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi
mailto:hsivo...@iki.fi wrote:


On Feb 11, 2010, at 16:07, Jeremy Orlow wrote:

  As has been brought up repeatedly, growl and the other
notification engines are used by a SMALL FRACTION of all web
users.  I suspect

Re: Notifications

[Doug Schepers]

Hi, Ian-

No need to apologize... HTML is a little bit more widely adopted than 
SVG (I suspect that there are 10x as many HTML documents as SVG 
documents on the Web).


It may be that only specifying text and HTML notifications is the best 
way forward for now, I just wanted to make sure it was an informed 
decision.  I agree with the simplicity goal.  Fallbacks and defaults 
make a lot of sense to me.  I'll noodle a bit and see if I can come up 
with a simple mechanism, but I'm probably happier reviewing other 
people's proposals.


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

Ian Fette (イアンフェッティ) wrote (on 2/23/10 2:20 PM):

Doug -

I did not mean to be HTML centric, apologies. I'm currently going
through a debate in my mind (scary thing) about whether allowing an
arbitrary mime type and content would be good or bad. My gut sense here
is that if the UA is capable of displaying it, we should allow it, and
it will be used or not used (with fallbacks provided) based on the
support of UAs, with more UAs evolving to support it as user demand
grows. Ideally we would provide multiple fallbacks, e.g. allow someone
to specify an ordered list in order of preference, e.g. text/html
representation followed by image/svg+xml followed by text/plain
(although perhaps text/plain is better left broken out, so that it's
more visible and people actually fill it in, as opposed to being some
option in a list of things you can provide).

e.g.

CreateInteractiveNotification(in DOMString text-fallback, [Optional] in
DOMString MimeType1, [Optional] in DOMString NotificationFormat1,
[Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...)

forgive my broken IDL, I'm sure there's a better way to express it, but
you get the idea.

At any rate, I'm not opposed to what you propose, just trying to think
out loud of how to best do that while still ensuring that a text
fallback is still reasonably simple (and obvious) to specify.

-Ian

Am 23. Februar 2010 10:24 schrieb Doug Schepers schep...@w3.org
mailto:schep...@w3.org:

Hi, Ian-

I generally agree with you, and certainly with your sentiment.  Not
to go all SVG on you, but why *HTMLNotification?  I understand
that HTML is really common, and that increasingly SVG can be used as
part of HTML, but there are lots of devices out there (TVs, mobiles,
set-top boxes) that use SVG rather than HTML, which would benefit
from these interactive notifications... shouldn't we define a more
generic CreateWebNotification and pass an optional MIME Type
parameter that defaults to text/html (or some similar mechanism)?

I strongly agree with the sentiment that we should design for the
future, in any case, and not limit ourselves to simple text
notifications.

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


Ian Fette (イアンフェッティ) wrote (on 2/23/10 1:06 PM):

This thread seems to have languished, and I'm trying to figure
out how
to move forward here.

My understanding, grossly simplified, of the current state of
the world
is this:

1. Some people have a desire to show HTML / interactive
notifications,
to support use cases like remind me of this calendar event
again in 5
minutes or Answer this call / hang up this call.
2. Some people have a concern that the proposed way to achieve
1, namely
allowing HTML, will result in certain platform notification systems
(Growl, NotifyOSD etc) not to be used.

I will disclose my biases up front and say that I do believe the use
cases that 1) tries to support are important. (I want to be able to
interact with a calendar notification to say remind me again
or take
me to the full details of the event, for instance). I also am
of the
belief regarding #2, being unable to find any actual data on how
many
users have and use growl, that the user base falls into roughly two
camps. There's the people who have gone out and downloaded Growl (or
another notification service) because they want everything
coalesced,
and then there's the people who don't really care, and if
mail.app wants
to tell them something vs their browser wants to tell them
something,
they don't really think much of it.

I think that initially, we can do a lot more for this second
group in
terms of functionality that we can provide, and would find it
unfortunate if we held up forward progress because of a current
implementation detail. If that functionality proves to be useful and
desired by a number of users, I believe that platforms like
Growl and
NotifyOSD will find a way to make it work. In the meantime though, I
think there are relatively simple things we can do to not leave

Re: Notifications

[Doug Schepers]

Doug Schepers wrote (on 2/23/10 2:43 PM):


HTML is a little bit more widely adopted than
SVG (I suspect that there are 10x as many HTML documents as SVG
documents on the Web).


I've been told offlist that it may not be obvious that I was joking 
here... 10x is an absurdly low figure... HTML is many orders of 
magnitude more common on the Web than SVG (or PDF, or Word, or Flash, or 
txt, or pretty much anything else).


:)

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

Re: How do I join this list?

[Doug Schepers]

Hi, David-

Like that.

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

Re: How do I join this list?

[Doug Schepers]

Hi, David-

More specifically, you simply send an email to 
public-webapps-requ...@w3.org with the subject line subscribe.


The archives are here:
  http://lists.w3.org/Archives/Public/public-webapps/

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

Social APIs (was: Rechartering WebApp WG)

[Doug Schepers]

Hi, Scott-

This is certainly a valid aspect of Widgets... as a platform for a 
specific kind of Web application: a collaboration/discussion/sharing app.


But it seems to me that this is conflating two orthogonal things: an 
application host environment, and a collaboration platform.  Widgets can 
host the full range of Web apps; and a collaboration platform shouldn't 
be confined to Widgets.


The context for a Widget, in my opinion, shouldn't inherently contain 
the users of that Widget; that is functionality that should be specific 
to collaboration apps.


As an analogy, think of the Geolocation API.  A recipe widget which 
finds recipes based on a list of available ingredients has no use for 
that API, but a shopping widget might; traditional web sites built to do 
those things would have the same needs.  So, the Geolocation API is much 
better off as a standalone API that is available when needed, and not 
imposed when not needed, as general functionality, not just for Widgets.


It also seems that it would require more than just an API... it needs an 
infrastructure from which to draw the relationship data, and security 
considerations.  Like the Geolocation API encapsulates underlying 
device/service functionality (GPS, cell/wifi triangulation, logged IP 
locations, etc.), and the Widget Interface's Storage API uses 
functionality defined elsewhere (LocalStorage, SessionStorage, 
IndexedDB, WebDB, remote web service), a Social API would have to rely 
upon some source of data, which is not inherent in the device or a 
single established web service, so that would need to be defined.


I don't think the WebApps WG is the right place to work on a Social API; 
I don't think it would get the specific interest such an API would 
require to do it right, with the current participants of this group 
(though others in the group should correct me if I'm wrong).  Also, the 
WebApps WG has an urgent need to renew its charter to bring in 
deliverables we've already agreed are in scope, so I would be extremely 
reluctant to bring in a deliverable at this stage that has as broad a 
scope as a Social API.


That's not to say a Social API is not useful or desirable.  I'd love to 
see this done at W3C, and I think it's important to make sure it works 
well in both web sites and widgets.  So, my counterproposal is to 
suggest that you work with Harry Halpin to propose a new Social API WG 
(maybe under Interaction Domain, but more fittingly under the Technology 
and Society Domain), and bring in the Google Wave and Open Social folks 
(since Google is already a W3C member), and find other stakeholders 
(Facebook?) who might also be interested, to help standardize what they 
have all already done.  Harry and I have talked a bit before about next 
steps for the Social Web, and this strikes me as a logical and pragmatic 
next step.  I will be happy to do what I can to help set this up, and to 
ensure good communication between our groups, and to make sure that it 
works well with Widgets.


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


Scott Wilson wrote (on 2/13/10 5:21 AM):

Hi Doug,

I'm not adamant that these requirements are met specifically just for
Widgets, just that these are where the current use-cases come from. They
certainly ought to be supported through more general technologies where
possible.

There is also the issue of abstraction; should a widget author be
looking at low-level APIs to deliver functionality, or call a common
high-level API which is then implemented in a
device/architecture-specific way? E.g. if a widget author script wants
to get the list of current participants, should it need to be rewritten
for every platform it might be deployed in (e.g. XHR in some, Web
Sockets in another, native code another...) or can it call
widget.getParticipants() and let the UA handle the implementation?

Just as, for example, the Widget Interface defines preferences using
the Storage API: the actual choice of implementation of this
(LocalStorage, SessionStorage, IndexedDB, WebDB, remote web service) is
up to the UA.

So what I'm talking about here, just to be clear, are the high level API
abstractions available to a running widget (and potentially other types
of web application) and not any underlying protocols used to implement
them.

The specific high-level APIs I'm interested in are:

1. Participants [1]: getParticipants, getViewer, getOwner,
setParticipantCallback
2. State [1]: getState, state.submitDelta, state.submitValue,
setStateCallback
3. Friends/People [2]: getViewerFriends, getOwnerFriends

(Note these are subsets of the functionality of the referenced
specifications; other functionality they specify is already covered by
other W3C work such as Widgets:TWI [3] and Widgets:VMMF[4])

In some cases these APIs could map onto DAP (e.g. getViewer would map to
a call on the Contacts API) but in other cases would rely on other kinds
of implementations (OpenSocial itself, XHR, Websockets

Re: Window id - an idea to make multi page web application easier

[Doug Schepers]

Hi, Sebastian-

Sebastian Hennebrueder wrote (on 2/12/10 8:11 AM):

Maciej Stachowiak schrieb:

On Jan 29, 2010, at 6:36 AM, Sebastian Hennebrueder wrote:


Arthur Barstow schrieb:

Sebastian, All,
On Jan 18, 2010, at 10:54 AM, ext Sebastian Hennebrueder wrote:

About half a year ago I came up with an idea to add a unique window id
as request header to each browser request. I published this
initially on
my website
http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html

Now, I have stumbled upon the WebApps Working Group and would like to
introduce this here as well.

WebApp'ers - does anyone have any feedback for Sebastian? Would this
idea be more applicable to HTML5?


thank you for the feedback.
HTML 5 defines precise scopes for per window or per browser which can
be used by JavaScript.
The missing bit is to pass a window id to the server with the HTTP
request. I don't know to which spec this actually belongs to.

I am hoping that people here can help me or finally convince me that
my idea is useless.


I think this request would be more appropriate for HTML5, yes. Please
bring it to the HTML WG or WHATWG.


Thank you to both of you.

I started a discussion on the what wg list and somebody added a nice
idea to provide an interface to the local storage / session storage from
the server side.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/024979.html



Actually, I think this should also be in scope for the Web Messaging 
spec, which is in our new draft charter.  It needs to address resource 
discoverability, which your proposal might be part of.



[1] http://www.w3.org/2010/webapps/charter/Overview.html

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

Re: Rechartering WebApp WG

[Doug Schepers]

Hi, Scott-

I'm still confused as to what you're asking for as a chartered 
deliverable for Widgets.


Like others, I am extremely reluctant to define any special 
functionality for Widgets, when it could be useful for Web applications 
at large.  Let me try to break down some of what you are asking for in 
terms of specs we are already doing:


* communication between different widgets on the same computer: Web 
Messaging [1]
* communication between widgets on different computers: Web Sockets API 
[2], XHR [3] (through a gateway server)

* access to contacts on a specific device: Contacts API (DAP WG) [4]
* access to relationships between contacts, etc.: no current work, but 
possible as an online service (XHR), or locally through markup like RDFa 
or microdata



I don't know what social APIs OpenSocial or Google Wave Gadget API 
expose, but anything above and beyond the deliverables listed above 
should probably be developed by another group (maybe in collaboration 
with the RDFa WG, since it probably has to do with ontologies?), and 
simply reused within Widgets or Web apps.


But maybe I missed your point... can you give me a concise outline of 
what the specific use cases and requirements you have for this social 
API are?


[1] http://dev.w3.org/html5/postmsg/
[2] http://dev.w3.org/html5/websockets/
[3] http://dev.w3.org/2006/webapi/XMLHttpRequest/
[4] http://dev.w3.org/2009/dap/contacts/

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


Scott Wilson wrote (on 2/12/10 5:39 PM):


Specifically I'm thinking of access to friends/friends-of lists from
author scripts in a Widget runtime. This is something of interest to
widget developers, as it enables widgets to operate as social applications.

OpenSocial is an obvious source of inspiration here - however the actual
social APIs are only a small part of OpenSocial (which also covers all
aspects of app packaging. processing. discovery and persistence) and are
not easily reused in other kinds of devices and architectures.

The interop problem arises as currently authors of apps/widgets are
basically faced with two completely different stacks of specifications
based on the presence or absence of a few very small features - and the
friends API represents the main feature gap between the W3C widgets
family of specifications and OpenSocial.

Looking at recent developments, e.g. Vodafone's recent work on
integrating phone contacts and social network contacts, suggests that it
will not only be web widgets that would be able to access this type of
API, but also mobile and desktop widgets.

I would propose looking at this area with the W3C Social Web XG and
identifying a set of spec requirements either for webapps or DAP (it
could go either way - social APIs may fit better in DAP as they have
analogues with the contacts API work there, however Widgets are the
obvious vehicle for making use of such APIs. In any case some
co-ordination would be useful).

Currently in Apache Wookie we implement the Google Wave Gadget API as a
means of supporting inter-widget communication in collaboration
scenarios (e.g. multi-user environments); however the fact that this API
is completely different in almost every respect from the Google API to
get at friends (as opposed to participants) indicates there is a
significant interop gap where W3C could make a difference.

(One way of looking at this is that requesta for contacts,
participants and friends are just differently contextualized queries
on a core people API and should behave consistently.)

Re: Rechartering WebApp WG

[Doug Schepers]

Hi, Art-

Thanks for the feedback.

Arthur Barstow wrote (on 2/9/10 9:34 AM):


On Feb 8, 2010, at 7:25 AM, ext Doug Schepers wrote:


We are interested in comments to refine the charter before submitting it
to the Advisory Committee and W3C management for review.

[1] http://www.w3.org/2010/webapps/charter/Overview.html


The changes from the current [Charter] look good Doug!


Thanks, happy to help.



Some additional changes I propose, using [PubStatus] as a guide for some
of the comments:

3.1 - a straight diff on the draft and [Charter] shows a relatively
significant set of changes. However, there are really just 3 additions:
Alternate Input Device Events, PostMessage + MessageChannel and Web
Notifications. Perhaps it would be useful if these three additions were
marked up such that these additions were easily identified.


Added a paragraph describing the changes, and notated each of the new 
deliverables.




3.1 - it would be convenient if all of the specs included pointers to
their EDs (links are missing for Clipboard, DOM, File API, Progress
Events, PostMessage/MessageChannel, Selectors L1 and L2, Web
Notifications, XBL2, XHR L1 and L2).


Done.



3.1 - CORS is included as a 1st-level bullet and a sub-bullet of Secure
Cross-Domain Scriptiong. I would delete CORS' 1st-level bullet.


Copy/paste error... removed.



3.1 - Widgets specs: we have already started to remove the Widgets
1.0: prefix for the spec names and this draft charter should do the
same (e.g. change Widgets 1.0: Updates to Widget Updates).


Done.



3.1 - re Widgets View Modes - there are actually two related EDs so I
would change this to Widgets View Mode: a media feature and API related
to presentation mode.


Done.



3.3 - I think you can delete the Notes: line


Removed.



4.1 - besides XHR, at least one of the widget specs (TWI) has a
dependency on the HTML5 spec.


Added.



4.2 - re CSS WG, change the text to To collaborate on the Selectors API
and widget media feature specifications


Changed.



2., 3.1 and 4.2 all refer to the Canvas Graphics API. What is this API
and would it make sense to consolidate this info in one or two places in
the charter?


Removed from 2. and 3.1.  Probably won't happen anyway, but it has been 
split out as a separate HTML WG deliverable, so it's good to be prepared 
in case more upheaval happens.




4.2 - Security Group? - it's not clear what this is about. Is this the
informal security IG (public-web-security) or the XML Security WG or
something else?


TLR is working on putting together a Security Interest Group, but it 
won't be ready in time, so I've commented this out.




4.2 - re the MAWG, given WebApps' history with Media related spec work,
perhaps the text should be a bit more specific e.g To integrate
consistent APIs for multimedia functionality e.g. MAWG's a
href=http://www.w3.org/TR/mediaont-api-1.0/;API for Media Resource
1.0/a.


Done.



4.3. - the Web Sockets protocol is in scope for IETF's HyBi (not their
HTTP WG) and it should be explicitly identified. I think this can be
addressed by using ... keep pace with the IETF's HTTP and a
href=http://www.ietf.org/dyn/wg/charter/hybi-charter.html;HyBi/a
groups' work 


Done.



9. Given WAF and Device API WGs closed almost two years ago, I would
delete the Please also see ... sentence.


Changed to a link to previous charter.



Lastly, 4 specs are listed in [PubStatus] and not included in the draft
charter. Above I propose a way to reflect our interest in what [Charter]
calls Media Object, but re the other three:

a. Element Traversal - it seems like this should be explicitly included
in the charter with a caveat that no work will be done except errata
handling if the need arises.


Added back, with notes.



b. File Upload - does the group now consider this work taken over by the
File API and File System spec or is there something here we want to
explicitly include in the draft?


Added a note in File API that it replaces File Upload.



c. Window object - given the wording in 3.1 re HTML5 split out, I
presume it's OK for the draft to not explicitly include this spec since
this wording would permit WebApps to take it (given an Editor, etc.).


That was the previous suggestion, so I removed it.  I would be happy to 
add it back if we had an editor who will follow through on it, but those 
are scarce.



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

Re: Rechartering WebApp WG

[Doug Schepers]

Hi, Folks-

Per the telcon today, I have explicitly added a Widget Embedding 
deliverable to the charter [1] to allow widgets to be referenced from 
other web content, much as a '.swf' or '.flv' file is referenced in 
html:object.  This is a small but vital aspect of widgets that should 
round out the deliverables, and I've been given to understand that these 
deliverables will all be completed in the next charter period.


(As a side note, this is actually something the SVG WG has gotten quite 
a few requests for, especially as more Flash developers are looking to 
HTML5 and SVG for analogs to Flash functionality.  Maybe Adobe and 
Microsoft could even consider this as a new way to package and deliver 
their embedded content.)


I've also revised the Web Messaging description, again per the telcon, 
to include resource discovery; the use case described was, for example, 
having several YouTube video tabs open, and finding them all to give the 
currently focused one dominance and pause the others.  Along with normal 
use of XHR, this should also satisfy Scott's request for inter-widget 
communication in both the single-user and multi-user cases.


With these additions, and having integrated the feedback from the 
discussions on member-webapps and public-webapps, I would like to move 
ahead with W3M review, so we can get this in front of the Advisory 
Committee for further consideration.


[1] http://www.w3.org/2010/webapps/charter/Overview.html

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

Re: Rechartering WebApp WG

[Doug Schepers]

Hi, Anne-

Thanks for your feedback.

Anne van Kesteren wrote (on 2/11/10 11:06 AM):

On Thu, 11 Feb 2010 16:58:40 +0100, Doug Schepers schep...@w3.org wrote:

[1] http://www.w3.org/2010/webapps/charter/Overview.html


Sorry for being late.


NP, just in time.



Should it say DOM Level 4 Core rather than just DOM Level 4?


Quite right, fixed.



If not
maybe DOM Level 4 Events and new editions of existing DOM specifications
does not need to be mentioned.


The specs may not end up with those names, but I wanted the basic 
deliverables in scope.  Note that new editions (like, DOM3 Core 2nd 
edition, which incorporates errata) are different from new versions of 
those specs; I added this on Maciej's request, and it seems like a good 
thing to have in scope.




It is XMLHttpRequest, not XmlHttpRequest.


Hah!  I had actually just corrected that to XmlHttpRequest (it was 
written both ways previously)... un/re-corrected.




And Object can be dropped.


Fixed.



(And there's no Level 1 technically, but I suppose the reference makes
that clear.)


Yeah, understood, I thought it was a little clearer to casual readers 
this way.




Looks good otherwise.


Thanks.


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

[widgets] Applying Stylesheets to Resources

[Doug Schepers]

Hi, folks-

I've meant to mention this for a while (a couple years), and it's 
probably too late, but I thought I'd drop it in for future consideration.


One odd part of the separation of content and presentation is that a 
stylesheet is applied to a file by including a link to the stylesheet in 
the target file.  That is totally backward.


It's understandable in the historical context, because the file that was 
being navigated to was the HTML page, and there was no other way to 
associate or allow discovery of other applicable stylesheets.  Widgets, 
because it defines a manifest, could correct this, if the author wants 
that option.


I would like the manifest to add a linking element that points to a 
stylesheet and to its target resource (an HTML or SVG file, say), and 
says, apply this stylesheet to this file.


This would allow the author to reuse and repurpose a target resource 
without touching that file itself.  Mix this with parameters (something 
we are working on in SVG and CSS), and it's a nice model.


Is it possible to add something like this?

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

Re: [widgets] Applying Stylesheets to Resources

[Doug Schepers]

Hi, Boris-

Boris Zbarsky wrote (on 2/11/10 12:04 PM):

On 2/11/10 11:57 AM, Doug Schepers wrote:

One odd part of the separation of content and presentation is that a
stylesheet is applied to a file by including a link to the stylesheet in
the target file. That is totally backward.


Strictly speaking, this is just because most people don't have control
over their web servers (which is why the link element exists). Link
HTTP headers work fine for applying stylesheets.


Ah, interesting... I didn't know that, thanks!  Is this [1] the most 
recent reference on that?


Still, I think adding a way to do this in the Widgets manifest would be 
a nice authoring solution.


[1] http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.txt

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

Re: Rechartering WebApp WG

[Doug Schepers]

Hi, Maciej-

Thanks for the feedback.


Maciej Stachowiak wrote (on 2/10/10 8:10 PM):


Some comments:

- I would like to suggest the name Web Messaging for the postMessage /
MessageChannel deliverable.


Done.



- I think the Other Specifications section should be clear on the
right process for adopting new deliverables without having to recharter.
I think we want a process that is flexible but that retains transparency
and accountability. I like the idea of writing requirements documents
for these. Perhaps there should be some sort of review process for these
requirements documents, in lieu of a full recharter cycle.


Sure, let's discuss this as a group to see what we are all comfortable 
with, and I will tighten up the language accordingly.  Right now, I 
don't know exactly what else to say.




- I think errata for the existing DOM specs should be stated as
in-scope. I believe we are the right group to do this, but it's better
to be explicit. I think this would include even DOM specs where we may
not plan to publish a whole new version.


Clarified.



- I think it's no longer necessary to cite the previous Web API and WAF
charters. If we do cite a previous charter it should be the previous
version of the Web Apps WG charter, It hink.


Corrected.


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

Re: Rechartering WebApp WG

[Doug Schepers]

Hi, Folks-

Scott Wilson wrote (on 2/9/10 10:32 AM):


There are a couple of additional areas it would be useful to consider
for future work in the Widgets space, specifically:

- inter-widget communication (both single-user and multi-user, e.g.
collaboration)
- social web APIs for widgets (e.g. friends, friends-of)


Are these deliverables the Widgets folks are willing to take on?  If so, 
are there clear use case  requirements documents, and available editing 
resources?


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

Rechartering WebApp WG

[Doug Schepers]

Hi, Folks-

As you know, we will be up for rechartering on 30 June 2010.  However, 
we have a few new deliverables, and we've been specifically advised that 
though they are arguably in scope, it would be better transparency if 
e.g. postMessage and MessageChannel were explicitly added to the charter.


Thus, I have started a rough draft of the new WebApps charter [1], 
taking into account the feedback received so far on the WebApps member 
list.


We are interested in comments to refine the charter before submitting it 
to the Advisory Committee and W3C management for review.


[1] http://www.w3.org/2010/webapps/charter/Overview.html

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

Re: [widgets] Null in PC

[Doug Schepers]

Hi, Marcos-

Marcos Caceres wrote (on 2/2/10 7:29 AM):


I had a discussion with an implementer who was a bit confused about the
concept of null in the specification. The problem is that I kinda
wrote the spec as if it was to be implemented in Java or JavaScript.
This has resulted in confusion wrt how null is to be interpreted in
languages that don't have that concept/data type.

So, in an effort to clarify that, I've added the following to Processing
Rules section of PC:

[[
In the following algorithms, the concept of null is used as a special
symbol to indicate that a variable has no data associated with it. For
example, let x be null or if y is empty, then return null.

Note: Although ECMAScript and Java support null as a native value type,
there are some programming languages that have no notion of null or
where null is problematic (e.g. C++). For those languages, it is OK for
an implementation to substitute the null for some other value or symbol
(or for nothing at all). For example, it is ok to have the value 0
represent null for the height of a widget as the height of a widget is
defined as a non-negative integer greater than 0. In such a case, 0
would behave as if it is null.
]]


It seems strange to me to use language like OK in a spec, since it 
seems overly casual and definitely not normative; I suggest you replace 
all instances of OK with awesome.


Failing that, maybe wording like this might better capture the interop 
aspects?  We want all the C++ implementations to behave the same, even 
if they are crippled by their language. :P  (I used to be a C++ 
programmer... I thought it did have a NULL, but I guess that's only for 
pointers.)


[[
In the following algorithms, the concept of null is used as a special 
symbol to indicate that a variable has no data associated with it. For 
example, let x be null or if y is empty, then return null.


Note: Although languages such as ECMAScript and Java support null as a 
native value type, there are some programming languages that have no 
notion of null or where null is problematic (e.g. C++).  Implementations 
in these languages should substitute a language-specific value or symbol 
which is functionally equivalent to null, or if no equivalent exists, to 
have no value at all.  For example, the value 0 may represent null for 
the height of a widget, since the height of a widget is defined as a 
non-negative integer greater than 0.  In such a case, 0 should be 
treated as if it were null.

]]

I'm not satisfied by that wording either, to be frank... I think it 
needs to be precise about the value for each language that's affected. 
I also think we need to make a distinction between the implementation 
language and the content language... the content should not get a '0', 
right?  It should get 'null', I'd think.


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

Re: MPEG-U

[Doug Schepers]

Hi, Cyril-

Cyril Concolato wrote (on 1/20/10 12:24 AM):


Le 13/01/2010 19:59, Doug Schepers a écrit :


Cyril Concolato wrote (on 1/13/10 10:37 AM):


Yes, you're right, the problem is that liaisons usually are not
considered as public documents so the secretariat or MPEG members are
not allowed to make them public.
...
Anyway, MPEG is meeting next week, I'll
raise your questions and try to have MPEG make a formal answer.


Could you please make sure that the secretariat sends the email to
team-liais...@w3.org, CCing Steven, Mike, and me, as the Team Contacts
for the WebApps WG, and Philippe Le Hegaret as Interaction Domain Lead?
It's not appropriate to email Tim Berners-Lee for liaisons at this
level, though if they insist, I suppose they can include him. We need to
make sure that these liaisons are dealt with in a timely manner.

I would greatly appreciate if you could have the secretariat send an
immediate acknowledgment email to the above email addresses, just to
make sure that the process is understood and accepted, before sending
the liaison itself. Could you please request that right away?

I know you are doing what you can to make sure the communication
channels are clear, so I appreciate your help.


Just for clarification. I don't know yet if the liaison can be sent to a
public mailing list. But if it is possible, is it preferable to send it
directly to the public mailing list or to list of persons you mentioned?


My personal preference is that the technical discussion happen on 
public-webapps, of course, but that is a dialog that should be carried 
on by people like you, who are in both organizations.


Liaisons from MPEG (and other organizations) tend to be formal documents 
(usually in Word or PDF format), and require formal documents in return, 
so we need to address that in a separate channel, after the technical 
discussion has taken place.  If it is possible to have these liaisons 
sent to the public list as well as the people and lists I mention above, 
please do so; failing that, please ask them to send the liaisons to 
member-webapps as well.


If we need to draw up a Memorandum of Understanding regarding this, 
please let us know.  Thanks again.


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

Re: [selectors-api] comments on Selectors API Level 2

[Doug Schepers]

Hi, folks-

Since the Selectors API is so closely tied to CSS Selectors, which may 
affect implementations and the development of the CSS specs, I would 
suggest that there be a closer working relationship between the editors 
of Selectors API and the CSS WG.  It's a bad sign of coordination to see 
emails from people on the CSS WG who are unpleasantly surprised by 
developments in the Selectors API spec.  This requires more than the 
usual inter-group review.


Please let me know how I can help facilitate this.

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


Daniel Glazman wrote (on 1/20/10 2:50 AM):

Hi there.

(this message contains personal comments and does not represent an
official response from the CSS WG)

I have read the recent Selectors API Level 2 draft [1] and have a few
important comments to make:

1. I don't like the idea of refNodes. I think having the APIs specified
at Element level makes it confusing. I would recommend applying the
NodeSelector interface to NodeList instead. If queryScopedSelector()
and queryScopedSelectorAll() are applied to an Element or a NodeList,
the corresponding element(s) are the refNodes of the query.
Same comment for matchesSelector().

2. I am extremely puzzled by the parsing model of scoped selectors. In
particular, I think that the :scope pseudo-class introduces things
that go far beyond scoping. Let's consider the selector :scope+p.
Clearly, it's _not_ scoped since it queries element that are outside
of the subtree the context element is the root of. Furthermore, these
elements can be queried without scopes, and I don't see why this is
needed at all!!!
I would recommend dropping the pseudo-class :scope and make a simpler
model where a fictional :scope pseudo-class and a descendant
combinator are prepended to all selectors passed as the argument of
the corresponding APIs.

I don't like the idea that implementors will have to check if the
first sequence of simple selectors in a selector contains or does
not contain a given pseudo-class to prepend something to the context.
This is clearly the kind of things I think we should avoid in
Selectors in general.

3. the section about :scope does not include error handling. What
happens if multiple :scope are present?

4. what's the specificity of that pseudo? Since it's proposed as a
regular and non-fictional pseudo, web authors _can_ use it in
regular stylesheets, even if it's meaningless outside of a scoped
stylesheet. What's the behaviour in that case? What's the
specificity?

[1] http://www.w3.org/TR/selectors-api2/

/Daniel
--
W3C CSS WG, Co-chair

Re: MPEG-U

[Doug Schepers]

Hi, Cyril-

Cyril Concolato wrote (on 1/13/10 10:37 AM):


Yes, you're right, the problem is that liaisons usually are not
considered as public documents so the secretariat or MPEG members are
not allowed to make them public.
...
Anyway, MPEG is meeting next week, I'll
raise your questions and try to have MPEG make a formal answer.


Could you please make sure that the secretariat sends the email to 
team-liais...@w3.org, CCing Steven, Mike, and me, as the Team Contacts 
for the WebApps WG, and Philippe Le Hegaret as Interaction Domain Lead? 
 It's not appropriate to email Tim Berners-Lee for liaisons at this 
level, though if they insist, I suppose they can include him.  We need 
to make sure that these liaisons are dealt with in a timely manner.


I would greatly appreciate if you could have the secretariat send an 
immediate acknowledgment email to the above email addresses, just to 
make sure that the process is understood and accepted, before sending 
the liaison itself.  Could you please request that right away?


I know you are doing what you can to make sure the communication 
channels are clear, so I appreciate your help.


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

Spam Alert (was: Warning Notice!!!)

[Doug Schepers]

Hi, Folks-

Obviously, the previous message on this thread was phishing spam, and 
was not from the W3C Team.  As far as I can tell, it was sent to the 
following lists:


public-xhtml2
public-webont-comments
semantic-web
public-xmlsec
public-webapps

Please don't reply to the original email, for your own security.  I'm 
sure I don't have to tell you this, but never send a stranger your 
username, password, phone number, or date of birth.


You can, however, send me your bank account information... trust me... :)

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

W3 Online Team wrote (on 12/5/09 11:07 PM):

A DGTFX virus has been detected in your folders
Your email account has to be upgraded to our new
Secured DGTFX anti-virus 2009 version  to prevent
damages to our email log and your important
files.

Click your reply tab, Fill the columns below and
send back or your email account will be terminated
immediately to avoid spread of the virus.

USERNAME:
PASSWORD:
PHONE NUMBER:
DATE OF BIRTH:


Note that your password will be encrypted with
1024-bit RSA keys for your password safety.

WARNINGS
If the above details is not sent you will
experience login problems after you log out.

Fwd: [office] Public Review of OpenDocument Version 1.2

[Doug Schepers]

Hi, WebApps folks (particularly Widgets folks)-

The ODF 1.2 packaging specification has just been released for public 
review at OASIS.  I'm forwarding the announcement for those of you who 
might be interested in reviewing it, given the overall similarities to 
Widgets packaging.


Regards-
-Doug

 Original Message 
Subject: [office] Public Review of OpenDocument Version 1.2
Date: Fri, 13 Nov 2009 12:51:30 -0500
From: Mary McRae mary.mc...@oasis-open.org
To: memb...@lists.oasis-open.org, tc-annou...@lists.oasis-open.org
CC: ODF TC List off...@lists.oasis-open.org, OASIS TAB 
t...@lists.oasis-open.org


To OASIS members, Public Announce Lists:

The OASIS Open Document Format for Office Applications (OpenDocument) TC 
has recently approved the following specification as a Committee Draft 
and approved the package for public review:


Open Document Format for Office Applications (OpenDocument) Version 1.2

The public review starts today, 13 November 2009, and ends 12 January 
2010. This is an open invitation to comment. We strongly encourage 
feedback from potential users, developers and others, whether OASIS 
members or not, for the sake of improving the interoperability and 
quality of OASIS work. We also welcome interested parties to join the TC 
as it continues to further development of its specifications. Please 
feel free to distribute this announcement within your organization and 
to other appropriate mail lists.


More non-normative information about the specification and the technical 
committee may be found at the public home page of the TC at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office. 
Comments may be submitted to the TC by any person through the use of the 
OASIS TC Comment Facility which can be located via the button marked 
Send A Comment at the top of that page, or directly at:

http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=office.

Submitted comments (for this work as well as other works of that TC) are 
publicly archived and can be viewed at:
http://lists.oasis-open.org/archives/office-comment/. All comments 
submitted to OASIS are subject to the OASIS Feedback License, which 
ensures that the feedback you provide carries the same obligations at 
least as the obligations of the TC members.


The specification document and related files are available here:

Editable Source:
http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-v1.2-part3-cd01.odt

PDF:
http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-v1.2-part3-cd01.pdf

HTML:
http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-v1.2-part3-cd01.html

Related Files:
http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-dsig-schema-v1.2-cd1.rng
http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-manifest-schema-v1.2-cd1.rng
http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-package-metadata-v1.2-cd1.owl


OASIS and the OpenDocument TC welcome your comments.


Mary P McRae
Director, Standards Development and Technical Committee Administration
OASIS: Advancing open standards for the information society
email: mary.mc...@oasis-open.org
web: www.oasis-open.org
twitter: @fiberartisan #oasisopen
phone: 1.603.232.9090





-
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Use Cases and Requirements for Saving Files Securely

[Doug Schepers]

Hi, Folks-

During the TPAC joint meeting between the WebApps and DAP WGs, we 
discussed security policies and use cases and requirements around saving 
files in different scenarios: public web resources (web pages and apps), 
widgets, mobile device and desktop browsers, locally-installed 
applications, etc. [1]


To kick this thread off, I'd like to suggest the trust model that 
already exists for local applications and browsers, which is to open a 
modal dialog that allows the user to select the file the application can 
save to; for webapps, I suggest the extra security consideration we add 
is to have the file hook which is returned is completely opaque (as far 
as the directory and file name) to the web app, and it just knows where 
to write.  Further, we should limit the upper bounds of the file size. 
I don't have any thoughts about auto-save across sessions, but it should 
be addressed (probably not allowed).


This could be evoked through the UI convention of a file dialog, or just 
as a bare API (if the user preferences allow the API to ask about saving 
files).  In any case, it should never be a cool webapp-specific file 
API dialog, only ever the native dialog of the browser (be it a desktop 
or mobile).


Please send in use cases, requirements, concerns, and concrete 
suggestions about the general topic (regardless of your opinion about my 
suggestion).


[1] http://www.w3.org/2009/11/02-dap-irc#T20-40-39-1

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

Travel Notification: Expect Delayed Responses

[Doug Schepers]

Hi, Folks-

Like many W3C folks, I will be traveling to the TPAC (Technical Plenary 
and Advisory Committee face-to-face meeting in Santa Clara, CA) all next 
week, so I will most likely not respond to general emails during that 
time.  It may also take me some time to catch up after my return.  My 
apologies in advance for slow response times.


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

Changes to DOM3 Events Key Identifiers

[Doug Schepers]

Hi, Folks-

(BCC to potentially affected groups: w3c-html-cg, public-webapps, 
public-i18n-core, wai-xtech, www-svg, public-forms, public-xhtml2, 
public-h...@w3.org, www-voice... please forward on to any relevant 
groups or individuals I may have missed, especially outside W3C.)


As editor of the DOM3 Events specification, I made what some may 
consider to be drastic changes in the most recent drafts:
 * I changed the syntax of the key identifier strings from U+ (a 
plain string representing the Unicode code point) to \u (an 
escaped UTF-16 character string), based on content author and 
implementer feedback.

 * I renamed the key identifier(s) feature to key value(s).

I've mentioned these ideas before in DOM3 Events telcons, and finally 
decided to do it, after first consulting with the I18n WG, who generally 
approved of the scheme (though not without some comments about details 
that will need to be addressed and resolved).


The new string format should be easier to deal with for developers, and 
the new name reflects some confusion I've encountered when explaining 
what key identifiers are... the work identifier seems to evoke the 
concept of a unique identifier for a key, when in fact what the feature 
does is provides the most appropriate value given the state of keyboard 
modifiers and modes.  I have tried also to clarify this in the prose of 
the spec.


We are aware that there may already be implementations and 
specifications that rely on the previous string format and name (as well 
as links), back from when this was a W3C Note, and we do not make this 
decision lightly, but we do believe this is the right decision for a 
stable and internationalized keyboard interface going forward.  For 
those implementations and specifications that need the previous 
functionality and name, you may be able to reference the SVG Tiny 1.2 
specification [2] instead, which does include the old Key Identifiers 
feature more or less intact from the previous definition, and is a 
stable W3C Recommendation.


You can review the changes in the most recent Editor's Draft [1].  The 
WebApps WG welcomes your feedback to the www-...@w3.org list.  This 
specification is still a work in progress, though we do hope to go to 
Last Call soon, so we are open to suggestions. (Note that the spec is 
mostly feature-complete, so new event types and other changes may have 
to wait for the next version, but send them on anyway.)


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

[2] http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet


Regards-
-Doug Schepers, on behalf of the WebApps WG
Editor, DOM Level 3 Events
W3C Team Contact, SVG and WebApps WGs

Re: [cors] unaddressed security concerns

[Doug Schepers]

Hi, David-Sarah-

David-Sarah Hopwood wrote (on 10/24/09 2:45 AM):

Doug Schepers wrote:

 I'm not at all a security expert, or even particularly well-informed on
 the topic, but it does occur to me that most of CORS' opponents seem
 very much in the capability-based security camp [1], and may distrust or
 dislike something more authentication-based like CORS.


The reason for that is that the main issue here is CSRF attacks, which are
a special case of a class of vulnerabilities (confused deputy attacks) that
capability systems are known to prevent, but that other access control
systems are generally vulnerable to. So it is not surprising that proponents
of capability systems would be more likely to recognize the importance
of this issue.


Fair enough.



Indeed the most common -- and arguably most effective -- defence against
CSRF is to use an unguessable token as an authenticator. That token is a
sparse capability, used in essentially the same way that a capability
system would use it.


Is there an existing capability mechanism that would solve the use cases 
that CORS enables?  If so, what is the rationale for CORS?  If not, why 
not?  Could CORS be combined with a capability system to make it more 
secure (and are you alluding to that, and I was too dense to connect the 
dots)?


I'm not arguing for or against CORS here, just educating myself... sorry 
if I'm dragging down the dialog here.


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

CORS Best PRactices (was: [cors] unaddressed security concerns)

[Doug Schepers]

Hi, David-Sarah-

David-Sarah Hopwood wrote (on 10/24/09 2:07 AM):


Currently, the prevalence and impact of CSRF attacks is limited to some
extent by the same-origin restrictions. The adoption of CORS will remove
part of that limitation. This should be expected to result in more sites
that rely on CORS being vulnerable to CSRF, even though the vulnerabilities
are dependent on the detailed behaviour of those sites and are not a
*direct* consequence of CORS per se. That is, these sites could in principle
avoid such attacks, but only by avoiding the use of ambient authority, and
we know from experience that some proportion of them won't do that.


Okay, so, the complaint isn't that CORS itself is insecure, but that 
people won't know how to use it properly.  This is a different problem, 
with a different solution.


I certainly acknowledge your concern, and this is something we need to 
take seriously.


If I understand you correctly, there doesn't seem to be anything about 
the CORS specification inherently that would cause it to change, nor to 
prevent it from progressing along the W3C Recommendation Track... 
rather, the challenge is to properly educate people on its use.  We need 
to make sure that, as a consequence of CORS being enabled, site authors 
don't misapply the new power they have, to the extent that that is possible.


Perhaps at this point we could work on some easy-to-understand 
tutorials, best practices, or even sample code show what to do and what 
not to do with CORS (and cross-site scripting in general), which W3C 
could host alongside CORS, to get the right messages out there.


If the security community is willing to write up articles as well, W3C 
would be happy to link to or host that material.


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

Re: [cors] unaddressed security concerns

[Doug Schepers]

Hi, Maciej-

Maciej Stachowiak wrote (on 10/24/09 4:42 PM):


On Oct 24, 2009, at 10:03 AM, Adam Barth wrote:


On Fri, Oct 23, 2009 at 10:34 PM, Doug Schepers schep...@w3.org
mailto:schep...@w3.org wrote:

Sorry for being dense, but why couldn't the whitehats build toy
systems on  an open honeynet?


I suspect we could do much more for the security of the web by writing
up good tutorials and example code for using CORS than we could by
tweaking various parts of the specification at this point.


I think it would be valuable to put together a secure version of a
simple use case. First, for tutorial value, and second, to show that
it's possible to write a simple system that uses CORS without
immediately creating a CSRF attack, and that you don't have to do
anything super tricky to make it work. We don't need a hackathon contest
to learn something from the exercise, our own analysis should be
sufficient. Here's two potentially interesting simple scenarios:

1) Pure public data.
a) Sever A offers a public data API at some URL - the API is accessed
with GET and looks at the query part of the URL.
b) The data is not user-specific, just public knowledge like a list of
search hits or the answer to a math problem.
c) The server opts in to public access to this data via
Access-Control-Allow-Origin: * (on the URL providing the data API only).
d) Server B accesses data via this API.

Hypothesis: this does not introduce a CSRF vulnerability on Server A.

2) Simple per-user data.
a) Server C offers a per-user data API at some per-user URL - the API is
accessed with GET and looks at the query part of the URL.
b) The data is user-specific (e.g. list of contacts from an address
book), determining what user
c) Server C allows the user to grant access to this data to a specific
other origin on a per-user basis.
d) For users that have not opted in, cross-origin access to the data is
refused (by not sending any special Access-Control headers).
e) For users that have opted in, Server C responds to normal and
preflight requests with Access-Control-Allow-Origin including the
allowed other servers only, and Access-Control-Allow-Credentials.
f) Inside the implementation of the URL, the server checks Origin to
determine if the request should be allowed.
g) For requests missing Origin, the server rejects the request (in a
realistic deployment it might use a secret token mechanism to allow self
requests in legacy browsers).
h) For requests from an appropriate Origin but missing cookies, the
server returns no data, just a token indicating that the user needs to
log in to Server C.
i) For requests from an appropriate Origin and including cookies, the
server returns the per-user data.
j) Server D attempts to get per-user data from Server C using XHR+CORS
with the credential flag set.
k) If server D gets the need to log in error back, it gives the user a
link to Server C's login page.

Hypothesis: this does not introduce a CSRF vulnerability on Server C.

Perhaps we could build examples along these lines and host them on
Google App Engine or the like. Maybe we could also make versions that
don't opt into CORS at all, to check specifically whether the addition
of CORS created new vulnerabilities.



Excellent concrete suggestions!  This is along the lines I was driving 
at, but you've articulated it much better.


If the larger security community has other suggestions for likely 
scenarios that they have concerns about, we could model those as well.



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

Re: [cors] unaddressed security concerns

[Doug Schepers]

Hi, Adam-

Thanks for the reply.

Adam Barth wrote (on 10/24/09 1:00 AM):

On Fri, Oct 23, 2009 at 5:29 PM, Doug Schepersschep...@w3.org  wrote:

 That's an interesting point... if the proponents or opponents of CORS did
 more testing and modeling, would that satisfy concerns?  Surely it couldn't
 be hard to set up a few common model architectures using CORS and announce
 them as targets for the white hat community?

 Mind you, I'm not stating one way or the other that this should be part of
 the exit criteria for CORS, just that it would be helpful overall, and
 frankly, if it hasn't been tried, I'm a little surprised... isn't this
 *exactly* the sort of thing Google, MS, the browser vendors, and the
 security community at large have the resources and expertise to do, as well
 as the incentive?  Can a brother get a honeypot?


This issues that Mark and co raise are not really the kinds of things
one can evaluate with a honeypot-type contest.  They're worried about
what web developers will build if we give them CORS as a tool.


Sorry for being dense, but why couldn't the whitehats build toy systems 
on an open honeynet?


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

Re: [cors] unaddressed security concerns

[Doug Schepers]

Hi, Folks-

Maciej Stachowiak wrote (on 10/13/09 10:47 PM):


On Oct 13, 2009, at 5:31 PM, Mark S. Miller wrote:


2) How well do cross-origin cookies support the simple use cases of
cross-origin
resource sharing?

As we all now know, many simple use cases are supported well by
cross-origin cookies.


Actually, we now all know that many (most?) simple use cases are not
supported well by cross-origin cookies without some additional mechanism
beyond the basic-pre-existing platform, since they would be subject to a
CSRF vulnerability. You could argue that in the hypothetical world, no
one could have predicted this. But I think at the time cookies were
introduced, no one seriously tried to predict the vulnerabilities. This
was before the same-origin security model was formulated; there was
considerably less understanding of Web security. Cookies first shipped
before JavaScript.

If CORS has similar vulnerabilities in simple use cases, then in the
non-hypothetical present day we should be able to predict them.


Let's take it a step further, and propose a worst-case scenario.  Say 
that some undetected hypothetical vulnerability in CORS is discovered 
some years from now, with a degree of severity akin to CSRF.


At that time, we can learn from those new vulnerabilities, and either 
make CORS more secure, or develop a new technology that solves some or 
all or more of the use cases at hand, and discourage the use of CORS (or 
even block the CORS mechanism in servers and clients).


Certainly, some damage will have been done.  Will the damage done be 
more or less than the damage done by less-secure or less-private 
workaround developers employ instead to solve the use cases that CORS is 
designed for?  It's impossible to predict, but it's a real question.


I know that this argument is on the slippery slope towards being a 
slippery-slope argument, but my point is that, through inaction born of 
trepidation toward unknown unknowns, we may cause as much (or more) of a 
security problem than if we act now in a way that seems the most 
responsible course of action, and learn later from our mistakes how to 
improve the situation.


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

Re: childElements, childElementCount, and children

[Doug Schepers]

Hey-

Maciej Stachowiak wrote (on 10/20/09 4:42 PM):


On Oct 18, 2009, at 4:14 AM, Jonas Sicking wrote:


On Sun, Oct 18, 2009 at 12:12 AM, Doug Schepers schep...@w3.org
mailto:schep...@w3.org wrote:

So, rather than dwell on an admittedly imperfect spec, I personally
suggest
that we urge WebKit developers to implement .children and
.children.length,
in the anticipation that this will be in a future spec but can be
useful to
authors today.


They already do. Which casts some amount of doubt on Maciejs argument
that it was too performance heavy to implement in WebKit. :)


What I said way back in the day (about childElements) was this:

I suggest leaving this out, because it's not possible to implement
both next/previous and indexed access in a way that is efficient for
all cases (it's possible to make it fast for most cases but pretty
challenging to make it efficient for all). This is especially bad
with a live list and an element whose contents may be changing while
you are iterating.

If all you care about is looping through once, writing the loop with
nextElementSibling is not significantly harder than indexing a list.

I stand by that remark. It is indeed hard to get both indexed and
previous/next access efficient in all cases. Of course, we are not going
to let that stop us from interoperating with de facto standards, and we
do our best (as for other kinds of NodeLists and HTMLCollections), but
I'd rather not have new APIs follow this pattern.


I got similar feedback from mobile vendors, who had not optimized live 
lists, so I think Maciej's point was valid for the design constraints of 
Element Traversal.


Where we now take the idea of an element-node-based API is another matter.



In this particular case, I think anything that's implemented in all of
the major browser engines should be an official standard, not just de facto.


Agreed, which is why I've started off DOM4 Core as I did.

I don't feel too strongly about having both .children and 
.childElements, but I do think that .children is a little problematic 
for authors... they will always have to check to see if Comment nodes 
are included, because of the large marketshare for older versions of IE, 
while .childElements allows them to write simple, clean, efficient code, 
which is the whole point of an element-based API.


I also prefer ElementCollection over HTMLCollection, especially for 
environments where more XML is used.  I don't know if there are any 
deeper issues that would advantage one over the other, but I think it 
would be confusing to authors to collect non-HTML elements in something 
labeled HTMLCollection.


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

childElements, childElementCount, and children (was: [ElementTraversal]: Feature string for DOMImplementation.hasFeature(feature, version)?)

[Doug Schepers]

Hi, Garrett-

Garrett Smith wrote (on 10/17/09 11:06 PM):


It has been so long that I cannot remember (over 8 years since I even
tried using that). It is a useless, pointless method that tells little
about the result of calling, say: getAttribute(checked).

I read Nicholas was struggling with that:
http://www.nczonline.net/blog/2007/05/08/safari-lies/


The rationale I've heard for implementations reporting inaccurately is 
that features with too many subfeatures are ambiguous in how they 
should be reported (how do you report support for UIEvents if you 
implement some but not all event types defined for that interface 
module?).  I've tried to address this in DOM3 Events by allowing a finer 
granularity of feature strings [1].




What is missing from Element Traversal API is a convenience property
to get child elements.


Wholeheartedly agreed.



There is a childElementCount. What is the
purpose of childElementCount?

One comment response from you (Doug Schepers):-
|  While many uses of Element Traversal do not require this attribute, I
|  speak from personal developer experience when I confirm that it is
|  useful.

Does not describe the problem that childElementCount solves, nor
does it solve the problem of getting the childElements.


One use case is shown in the spec itself [2]; childElementCount allows 
the author to find out how many element children there are without 
looping through twice ().  Since there were strong objections to adding 
.childElements (as I originally suggested), I struck a compromise.




Usage patterns
for childElements are quite common; you want the elements, no text
nodes, no comments; only elements. This problem is trivially solved by
the one missing property: childElementCount.


I assume you mean childElements, not childElementCount.



This is not the first time childElements has been requested and
childElementCount has been questioned. it has been mentioned on
various w3c lists, on comp.lang.javascript, and on ejohn.org, numerous
times as far back as January 2008. That did not made it into the
specification. Here are a few:


No, not the first time at all... and farther back than that, to March 
2007.  I believe the first time it was mentioned was when I first 
suggested the feature [3], back when I took over as editor (note, Chaals 
checked it in and sent the message [4] to the list with the open 
question, since I was busy at the time with my day job).


I readily admit that childElementCount would have been obviated by 
childElements.length.  I also agree that in a perfect world, 
childElements would have been included.  But some good arguments against 
it were made (by Björn Höhrmann [5], Maciej [6], and the JSR folks); one 
of the arguments from the mobile community was that such lists were too 
computationally and memory intensive for some of their devices, and that 
their code bases were optimized in a different direction.  Finally, this 
feature was quite old even when I took over the spec, and had been 
shipping on devices for over a year, so I didn't want to change it too much.


There was a lot of history to this spec, and a lot of discussion; if you 
read back through all of the email discussion and telcon/f2f minutes and 
spec revisions, back to when it was part of SVG Tiny 1.2, you may 
appreciate that there was no choice that was right for all stakeholders.


I suspect that I would make different choices now, but the climate at 
the time was to ship the spec as it was, and revisit it in v2... in the 
meantime, .children is implemented widely (IE, FF, Opera, but not 
Safari/Chrome), so I reckon that's what we will standardize, either in 
Element Traversal v2, or probably more sensibly in DOM4 Core/Web DOM Core.


So, rather than dwell on an admittedly imperfect spec, I personally 
suggest that we urge WebKit developers to implement .children and 
.children.length, in the anticipation that this will be in a future spec 
but can be useful to authors today.



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

[2] http://www.w3.org/TR/ElementTraversal/#example-3.2
[3] 
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/ElementTraversal/publish/ElementTraversal.html?rev=1.2content-type=text/html;%20charset=iso-8859-1

[4] http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0064.html
[5] http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0065.html
[6] http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0013.html


p.s.  More history for those who care:  I was tricked into editing this 
spec by Nandini from Sun, who had inherited the action from Robin 
Berjon, and who asked me to be her co-editor at a Web API WG F2F at 
MIT... little did I know at the time that I'd be the sole person to take 
the spec from the meager sketch Robin had left us with, through all the 
LC comments and into CR, and write the entire test suite on a sleepless 
flight to a TPAC in Mandelieu to get us to PR and Rec

Re: [ElementTraversal]: Feature string for DOMImplementation.hasFeature(feature, version)?

[Doug Schepers]

Hi, Anne-

Anne van Kesteren wrote (on 10/17/09 2:33 AM):

On Sat, 17 Oct 2009 01:46:56 +0200, Doug Schepers schep...@w3.org wrote:

Sorry for the tardy response.

This was an unfortunate oversight. I've now added this to the proposed
errata [1]. Please let me know if this suits your needs.

[1] http://www.w3.org/2008/12/REC-ElementTraversal-20081222-errata#S1


Didn't we explicit decide against this because you could easily feature
test it?


I don't recall that, and can't find any reference to it in the 
archives... do you have a link?  It's possible it was discussed in some 
telcon of F2F that I don't recall, but was not minuted.


In any case, I don't believe that adding a feature string is harmful or 
introduces significant implementation burden.  If it is reported 
accurately, it is useful, and in non-browser environments, where there 
may be different DOM implementations available, it is necessary for the 
DOMImplementationRegistry (as Michael mentioned).


I've heard people complain about hasFeature() and feature strings 
before, on the grounds that implementations may dishonestly report false 
support, but I don't know of any instance of that happening... it would 
be interesting if you do know of such a case.


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

Re: Touch and gestures events

[Doug Schepers]

Hi, Kari-

That's very cool stuff.  Thanks for letting us know about that... I hope 
that if we do indeed standardize multitouch and gesture events, you will 
lend us your practical experience in specifying them.


It's great that you've opened the source on the multitouch stuff... I 
don't suppose you have Mac binaries?  What sort of hardware is needed to 
support it?  Are there any restrictions on the OS level, or can you 
enable multitouch on any OS?


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


kari.hiit...@nokia.com wrote (on 10/15/09 10:33 AM):


Hi,

I suppose that the interest Olli mentioned was ours (Nokia).
Unfortunately there was a long delay before we were able to participate
the discussion and release our implementation, but yes, we have
previously discussed touch events with Olli. We would be interested in
participating standardization of touch and gesture events.

We have implemented touch and manipulate (including pan, scale and
rotate) events on top of Qt 4.6 and WebKit, and the open-sourced results
can be seen in http://opensource.nokia.com/Starlight . Working binaries
for Windows 7 (on Dell Latitude XT/XT2, some HP TouchSmarts), source,
videos and some documentation can be found by following the links there.
For the period when there is no existing standard, we also funded an
event abstraction library in Script.aculo.us. Its release post is here:
http://mir.aculo.us/2009/10/15/pinch-twist-zoom-bringing-multitouch-to-a-browser-near-you/


The approach that we had was a bit different from Olli’s, but I see a
lot of merit in his proposal, especially in extracting the common
parameters to PointerEvent. Naturally there are also some improvement ideas:

In TouchEvent, instead of size there should be separate height and
width, because touch area is not necessarily circle or square. Of course
that is also an approximation, but in real life mostly accurate enough.
Having a bitmap of the touch area is a natural next step, but I think it
isn’t needed for now, and futureproofing usually fails miserably.

It might require a bit too much violence to fit the attributes of pan,
zoom, rotate, and swipe all to parameters direction and delta. We have
panX/Y delta coordinates, scale factor, rotation angle, and the speed
for each of them. Our event types are only manipulate start/move/end
instead of telling in the event type what kind of change happened. I
think that most of the time all of these happen in parallel, but I see a
point in being able to be notified e.g. only when pan coordinates change.

The manipulate/gesture naming is of course a matter of taste, but we
wanted to give a name according to what is done (manipulate) instead of
what secret handshake is needed to do it (gesture). This way the events
are mentally less tightly bound to any UI technology. For instance, our
implementation starts panning with one finger moving instead of
requiring two fingers to be present to start what can be called a
gesture. The same manipulate stream can be continued by inserting a
second finger and rotating. In another UI style pan and rotate could be
as well done by touching the screen and rotating a jog wheel.

To mention some omissions of our implementation, there can only be one
manipulate event stream happening any given time, and there is no
touchover/touchout implemented.

Let’s hope that now there could be a real discussion about the topic.
Let’s not make premature conclusions about anyone’s patent applications.

- Kari Hiitola
The architect of Nokia’s Starlight project

Re: [ElementTraversal]: Feature string for DOMImplementation.hasFeature(feature, version)?

[Doug Schepers]

Hi, Michael-

Sorry for the tardy response.

This was an unfortunate oversight.  I've now added this to the proposed 
errata [1].  Please let me know if this suits your needs.


[1] http://www.w3.org/2008/12/REC-ElementTraversal-20081222-errata#S1

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


Michael Glavassevich wrote (on 10/16/09 4:14 PM):

Hi all,

Just thought I'd check again. Has this been discussed or resolved? We're
planning on having a Xerces-J release in December and would be nice if
we could provide this to users (assuming the spec plans to adopt it).

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrgla...@ca.ibm.com
E-mail: mrgla...@apache.org

Michael Glavassevich mrgla...@ca.ibm.com wrote on 06/01/2009 10:47:07 PM:


 Hi Arthur / Doug,

 Just following up. Has there been any discussion on this issue?

 Thanks.

 Michael Glavassevich
 XML Parser Development
 IBM Toronto Lab
 E-mail: mrgla...@ca.ibm.com
 E-mail: mrgla...@apache.org

 Arthur Barstow art.bars...@nokia.com wrote on 01/14/2009 10:07:36 AM:

  Hi Michael - Doug agreed to respond to this e-mail so expect a
  reply/proposal from him RSN.
 
  -Regards, Art Barstow
 
  On Jan 12, 2009, at 2:02 AM, ext Michael Glavassevich wrote:
 
  Hi WG,
 
  The DOM Core specification and other DOM modules define feature
  strings [1] which applications can query to check whether or not a
  specific DOM module is supported by a DOMImplementation. For
  example, DOM Level 2 Traversal and Range [2] says: A DOM
  application may use the hasFeature(feature, version) method of the
  DOMImplementation interface with parameter values Traversal and
  2.0 (respectively) to determine whether or not this module is
  supported by the implementation. These feature strings are also
  useful for selecting a DOMImplementation which supports a specific
  set of features through the methods provided by
 DOMImplementationRegistry [3].
 
  After reading the spec it doesn't seem like Element Traversal has
  such a string defined for it, so applications would have no standard
  way for selecting a DOMImplementation which supports Element
  Traversal or determining whether the DOMImplementation instance they
  already have supports it. Is there a reason a feature string was
  omitted from the spec? An oversight, perhaps? Can this be added to
 the errata?
 
  Thanks.
 
  [1] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.
  html#DOMFeatures
  [2] http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-
  Range-20001113/traversal.html#Traversal-overview
  [3] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.
  html#Bootstrap
 
  Michael Glavassevich
  XML Parser Development
  IBM Toronto Lab
  E-mail: mrgla...@ca.ibm.com
  E-mail: mrgla...@apache.org

Re: Web IDL and the New Scripting Coordination List

[Doug Schepers]

Hi, Folks-

Arthur Barstow wrote (on 10/1/09 9:32 AM):

Sorry for the cross posting ...

Doug - since I've had at least one question about the use and scope of
public-script-coord with respect to the Web IDL, would you please
clarify if it should be used for all future discussions related to Web
IDL or just coordination-related discussions re Web IDL?

FWIW, I prefer all Web IDL.


Yes, I've talked with Cameron about this, and public-script-coord is 
intended for all Web IDL discussions, not just coordination between WGs 
or other standards bodies.


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

New Scripting Coordination List Set Up

[Doug Schepers]

Hi, Folks-

I've now created the scripting coordination list.

It was suggested that the name public-scripting would be too likely to 
invite off-topic posts from people with script-authoring questions, so 
we struck a compromise between descriptiveness and discoverability 
versus length.  Thus, the name of the new coordination list is 
public-script-co...@w3.org, with a public archive available [1].


Here is the description:
Discussion on the topics of scripting interface design, Web IDL, and 
coordination between W3C Working Groups, ECMA TC-39, and other 
interested parties. This list is not a forum for script authoring.


To subscribe, simply send an email to 
public-script-coord-requ...@w3.org with subscribe in the subject 
line [2].  You will have to respond to an email granting permission to 
archive your emails [3] before your first message is posted to the list.



[1] http://lists.w3.org/Archives/Public/public-script-coord/
[2] http://www.w3.org/Mail/Request
[3] http://www.w3.org/2002/09/aa/

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

Re: Let's set up a mailing list for coordination with ECMA and Web IDL discussion

[Doug Schepers]

Hi, Folks-

I've submitted the request for public-script...@w3.org, and I 
anticipate that this will be created Monday (tomorrow).  Thanks to 
everyone for the discussion leading up to this... I'm very happy that 
this coordination is going on.


I will announce when the list is ready, with instructions on how folks 
can subscribe themselves.


Art, I understand your concern and will ask the Team to look at the 
issue of IP risks in this scenario, but in light of public comments in 
general, I don't anticipate that this will be a major issue... we will 
have to be careful in how we deal with significant and substantive 
feature requests, of course.


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


Arthur Barstow wrote (on 9/27/09 5:24 PM):

On Sep 27, 2009, at 7:33 PM, ext Maciej Stachowiak wrote:


ECMA TC39 (the group responsible for ECMAScript) has expressed a
strong interest in having a list for joint discussion with the W3C,
and particularly the Web Apps WG. And they are especially interested
in review of Web IDL. I suggest we set up public-script...@w3.org
(name suggested by Mark Miller) as a list managed by the Web Apps WG
for both purposes - discussion of Web IDL, and other scripting-related
coordination issues. I think this would be better than the massive
cross-posting we've experienced over the past few days.

Does this sound like a good idea to everyone?


The only concern I have is the potential for an input from someone who
has not agreed to the W3C's Patent Policy (PP) to be included in one of
our specs. In practice, the risk for this scenario for the Web IDL spec
appears to be relatively low. However, at least one of the messages in
one of these related threads implied there may be an impedance mismatch
between ECMA's patent policy and the W3C's PP.

I think we should get some input from the W3C Team here but it appears
the benefits of this proposed list i.e. increased communication between
ECMA and W3C, outweigh the IP risks so you get a tentative Yes from me.

FWIW, I think Doug's earlier proposal to name this list public-idl was
good but I am mostly indifferent as to the name and could certainly live
with public-scripting.

Mike, Doug - please pursue creating the list.

-Regards, Art Barstow



If so, how quickly can
we get it done?

Regards,
Maciej

CfC: Event Namespaces Removed

[Doug Schepers]

Hi, DOM3 Events fans-

After much discussion, and having looked for compelling reasons for 
keeping them (especially content, implementations, or other 
specifications), I have now removed event namespaces from the DOM3 
Events specification.


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

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

Focus and focus()/blur() [ISSUE-102]

[Doug Schepers]

Hi, Folks-

I plan to tackle this issue soon.  If you have any thoughts about it, 
I'd appreciate your feedback before I get to it.


Please respond directly to this message, or send a message to www-dom 
with [ISSUE-102] in the subject line so Tracker finds it.


Thanks!

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


Web Applications Working Group Issue Tracker wrote (on 9/22/09 3:08 AM):


ISSUE-102 (focus and focus()): Behavior of focus events when interacting with 
focus()/blur() methods needs to be defined [DOM3 Events]

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

Raised by: Doug Schepers
On product: DOM3 Events

Boris Zbarsky 
wrotehttp://lists.w3.org/Archives/Public/www-dom/2009JulSep/0086.html:
[[
Jacob Rossi wrote:

 Yes, so in response to that action, here's how IE handles focus events:

 focus, blur, focusin, and focusout can be registered on any element which is 
focusable.

 During a focus change from elementA to elementB, the following events are 
fired in this order:

 1. focusout:   srcElement is elementA, toElement is elementB, bubbles, not 
cancelable
 2. focusin:  srcElement is elementB, fromElement is elementA, bubbles, not 
cancelable
 3. Focus changes from elementA to elementB
 4. blur: srcElement is elementA, does not bubble, not cancelable
 5. focus: srcElement is elementB, does not bubble, not cancelable


That's a great start (assuming we want to spec focusout/focusin).  We
also need to spec what happens if a handler during any of steps 1, 2, 4,
5, calls focus() or blur() on some element (possible cases being
elementA, elementB, elementC).  That's been by far the biggest source of
compatibility problems we've run into with Gecko.
]]



Jacob Rossi 
wrotehttp://lists.w3.org/Archives/Public/www-dom/2009JulSep/0325.html:
[[
On 9/15/09 4:21 PM, Travis Leithead wrote:

 Do we really need eventTarget? It seems to me that focusin/focusout can remain UIEvents, 
and if web developers want to know what the releatedTarget is, then can 
simply register for both: focusout is the element loosing focus, focusin is the element 
gaining focus. You don't even have to know which Node to register them on because these 
events bubble, you can simply listen at the document level.


It's likely that one *could* solve this problem by listening to both.
But for complex systems it could get nasty simply because these events
don't fire concurrently.

In other words, for a single code path that needs to know both the
source and the destination of the focus change, your code would have
to save the target of the focusout event, wait for the focusin event,
and then proceed through the code path. While this is certainly
doable, it's much more elegant and straight forward to be able to just
grab both targets in during one event. (Also, see how the scenario
below might complicate this further.)

On Tue, Sep 15, 2009 at 4:02 PM, Doug Schepersschep...@w3.org  wrote:

 In fact, it's worth thinking about changing focusin and focusout to be
 cancelable, to prevent the focus from changing.  I doubt there is any
 content that relies on them not being cancelable... what would people think
 of this idea?


My last email (http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0321.html)
had the wrong quote above it at the end. It was supposed to be the one
above. I was worried about the ability to trap focus. But I suppose
this is already possible with the ability to call focus() or blur().
This leads me to my next question:

What is the firing order when the focus is redirected during the focus
change (either if you can cancel the focusin event or by calling
focus( ) or blur() )? Example:

1. The focus is on element A
2. focusout fires on element A
3. focusin fires on element B Note: the focus hasn't actually changed yet.
3.1   A listener for focusin calls focus( ) on another element (element C)

At this point, which events fire and in what order?
I can see 2 possible options:

a) Simply redirect where the focus is going and fire the following events:
  4.  focusin on element C
  5.  Move focus to C
  6.  Blur on A
  7. Focus on C

b) Assume that focus() effectively cause  stopImmediatePropagation
to happen. Now start a new focus change:
4. focusout fires on element A
5. focusin fires on element C
6. Focus moves to C
7. Blur on A
8. Focus on C

Which option you pick could depend on whether the event object has a
relatedTarget on it. If it does not, then you can get away with option
(a) because  there's no need to refire focusout on A because you'd
effectively be firing the same event your fired in step 2 again. If it
does, then you probably need option (b) because you need to fire
focusout with relatedTarget set to element C.

Furthermore, how does this order change if focus() is instead called
during a listener of the focusin event? during the blur event? during
the focus event?
]]

Marked addEventListenerNS and removeEventListenerNS At Risk

[Doug Schepers]

Hi, DOM3 Events folks-

(BCC to groups potentially affected.)

I have marked addEventListenerNS and removeEventListenerNS at-risk in 
the latest Editor's Draft of the DOM3 Events specification [1].  This 
means that we are gathering information on whether we can safely remove 
these methods from the specification.


Apparently, these are not yet implemented in desktop browsers, so there 
has been a call to reexamine their inclusion in this specification.  I 
personally suspect that there is not much of an implementation burden 
regarding these methods, but I would welcome implementer feedback on the 
matter.


I don't know how widely deployed other implementations are, nor how much 
content relies on these methods.  I do note that it is supported in 
Batik [2] and Inkscape, and more generally in Java implementations of 
the DOM.  I believe that other W3C specifications may rely on it (XML 
Events [3], maybe XForms).  Any evidence that removing these methods 
from the specification should be sent to www-...@w3.org.


We also welcome use cases in favor of retaining or removing them.  My 
inclination is to retain the namespace-aware methods, since there are 
existing implementations, so evidence that removing them will be 
beneficial will have to be pretty strong, but it's on the table.


Thanks for your feedback.

[1] 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.80
[2] 
http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/events/NodeEventTarget.html#addEventListenerNS%28java.lang.String,%20java.lang.String,%20org.w3c.dom.events.EventListener,%20boolean,%20java.lang.Object%29

[3] http://www.w3.org/TR/xml-events/

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

Re: Web IDL for our API spec.

[Doug Schepers]

Hi, Thierry-

Thierry Michel wrote (on 9/9/09 8:43 AM):


Thanks for your response on the use of Web IDL for our API spec.
http://lists.w3.org/Archives/Public/public-media-annotation/2009Sep/0003.html

...

I have read that Web IDL is a variant of Object Management Group’s IDL
How different is WebIDL vs IDL OMG ?
Lots of differences ?


Conceptually similar, but yes, there are quite a few differences.



The Annot WG is interested in using Web IDL. Would you or someone from
the Web Applications WG would be willing to give us a help to use it to
describe our API, as there is no knowledge of it in our WG.


I'm not the right person to ask for help, but perhaps Cameron or one of 
the other people on the WebApps WG can assist you.  In general, I 
suggest not putting me in the critical path... just go straight to 
public-webapps.


My suggestion is to read the Web IDL spec, look at specifications that 
have used it, and learn by example.  Find functionality that is similar 
to what you want to specify, and copy and tweak those bindings.


I'm sure the WebApps WG will be happy to help you with course 
corrections along the way.




I have seen that HTML does use WebIDL for JavaScript bindings.
http://dev.w3.org/html5/spec/Overview.html


For all its bindings, not just JS.



This comforts the WG for using WebIDl as it is still an unstable Working
Draft.


It is unlikely to go through major changes, and those changes that do 
occur are unlikely to significantly negatively affect the specifications 
using it.  It is an abstraction layer,


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

Re: DOM3EV: [ViewModes] typeArg on initXXXEvent

[Doug Schepers]

Hi, Marcin-

Olli answered most of your questions, but I had one more comment, inline...

Marcin Hanclik wrote (on 8/24/09 12:21 PM):


Another issue related to DOM3EV: There seems to be no naming
convention for the events. We have DOMSubtreeModified, mousewheel,
keyup, textInput and so on. Is it related to the history that
CamelCase is used only partially (it seems it is not used only for
DOM2EVs)?


The camelCase names were a fad.  It's much more author-friendly to 
simply use lowercase (easier to type, easier to remember), and that is 
what we suggest for all new events.  We also suggest using the shortest 
name that still conveys what the event is meant to do.


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

Re: addEventListener naming

[Doug Schepers]

 enthusiasm on this, 
we could put it in.  Any implementers care to chime in?


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

Re: Specs using Web IDL

[Doug Schepers]

Hi, Cam-

Cameron McCormack wrote (on 6/28/09 7:10 AM):

Robin Berjon:

 I wonder what the value is of having it on Rec track in the first place?
 Could it simply be a Note?


I’d be reluctant to make it a note, given the normative requirements it
makes of implementations of a given IDL fragment.


Yes, it seems pretty clear to me that it should be normative.  The 
Process is flexible enough with regards to Rec-track deliverables that 
it allows us to decide what the best way for this spec to be 
demonstrably baked.



Cameron McCormack wrote (on 6/28/09 7:21 AM):

Doug Schepers:

 As we talked about at the SVG F2F, we need to have a discussion about
 what the exit criteria for Web IDL will be, since the implementations
 are actually other specs, and there is concurrent development between
 those specs and Web IDL.  This seems to be a special case with regards
 to the Recommendation Track... should other specs be allowed go to
 CR/PR/Rec before Web IDL?  Should we park them in CR while features of
 Web IDL are solidified by other specs, like HTML5?


Yeah I’m still not sure what the best approach for CR exit criteria is.


If we follow a more traditional approach, have multiple (two or more) 
interoperable implementations, as demonstrated by a test suite, is 
enough to justify moving it along to Rec.  Would it make sense to have a 
test suite for Web IDL (I suspect so), and if so, what are we counting 
as implementations?  I see a few options:


* other specifications that use Web IDL
* implementations of specifications that use Web IDL
* a combination of the other specs and their implementations
* Web IDL checkers
* parser libraries

Given that Web IDL is also meant to describe interfaces in Java in 
addition to JavaScript, would it be reasonable to require that there is 
at least one Java implementation for each of the interfaces, or would 
that be constraining ourselves too much?





 Will there be an updated revision or version 2 of Web IDL?


My guess is that there will be if:

   * we find mistakes or implementors aren’t happy with how some things
 are specified,
   * we want to add some extended attributes or definitions that would be
 generally useful across multiple specs, or
   * we want to update the ECMAScript language binding to ES5.


 Another possible implementation of Web IDL would be an IDL checker, like
 a validator.


Yes, a validator or other kind of processing tool would demonstrate
whether the conformance requirements on IDL fragments are internally
consistent, at least.

I think what we want to do is to make sure that each feature that is in
the spec is useful for at least one other spec.  There are plenty of
features that currently are depended on by other specs, but I don’t know
if (m)any people have read through the detailed conformance requirements
they entail.  It’s these details that I think are in most need of
verification somehow.



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

Re: Specs using Web IDL

[Doug Schepers]

Hi, again-

Oops, email sent too soon... I need to disable the keyboard shortcut for 
Send on Thunderbird, it's very annoying.


Email finished inline

Doug Schepers wrote (on 6/28/09 3:37 PM):

Hi, Cam-

Cameron McCormack wrote (on 6/28/09 7:10 AM):

Robin Berjon:

I wonder what the value is of having it on Rec track in the first place?
Could it simply be a Note?


I’d be reluctant to make it a note, given the normative requirements it
makes of implementations of a given IDL fragment.


Yes, it seems pretty clear to me that it should be normative. The
Process is flexible enough with regards to Rec-track deliverables that
it allows us to decide what the best way for this spec to be
demonstrably baked.


Cameron McCormack wrote (on 6/28/09 7:21 AM):

Doug Schepers:

As we talked about at the SVG F2F, we need to have a discussion about
what the exit criteria for Web IDL will be, since the implementations
are actually other specs, and there is concurrent development between
those specs and Web IDL. This seems to be a special case with regards
to the Recommendation Track... should other specs be allowed go to
CR/PR/Rec before Web IDL? Should we park them in CR while features of
Web IDL are solidified by other specs, like HTML5?


Yeah I’m still not sure what the best approach for CR exit criteria is.


If we follow a more traditional approach, have multiple (two or more)
interoperable implementations, as demonstrated by a test suite, is
enough to justify moving it along to Rec. Would it make sense to have a
test suite for Web IDL (I suspect so), and if so, what are we counting
as implementations? I see a few options:

* other specifications that use Web IDL
* implementations of specifications that use Web IDL
* a combination of the other specs and their implementations
* Web IDL checkers
* parser libraries

Given that Web IDL is also meant to describe interfaces in Java in
addition to JavaScript, would it be reasonable to require that there is
at least one Java implementation for each of the interfaces, or would
that be constraining ourselves too much?


It comes down to what we think is the most useful indicator of success 
for Web IDL.




Will there be an updated revision or version 2 of Web IDL?


My guess is that there will be if:

* we find mistakes or implementors aren’t happy with how some things
are specified,
* we want to add some extended attributes or definitions that would be
generally useful across multiple specs, or
* we want to update the ECMAScript language binding to ES5.


I guess the first point would call for a revision, while the others 
indicate a need for a new version.  No need to dwell on it, but setting 
expectations about the future of the spec is useful.




Another possible implementation of Web IDL would be an IDL checker, like
a validator.


Yes, a validator or other kind of processing tool would demonstrate
whether the conformance requirements on IDL fragments are internally
consistent, at least.

I think what we want to do is to make sure that each feature that is in
the spec is useful for at least one other spec. There are plenty of
features that currently are depended on by other specs, but I don’t know
if (m)any people have read through the detailed conformance requirements
they entail. It’s these details that I think are in most need of
verification somehow.


Maybe we should have a LC to draw out these comments... if not now, what 
timeframe are you thinking?  What else needs to be done to the spec?



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

Berkeley DB (was: Points of order on this WG)

[Doug Schepers]

Hi, Maciej-

Maciej Stachowiak wrote (on 6/26/09 1:49 AM):


As a side note, it should be noted Berkeley DB itself could not be used
by WebKit or Gecko to implement the spec, because even though it is open
source, the license is not compatible with the LGPL. It seems unlikely
that non-open-source browser engines could use it either, unless they
are willing to pay Oracle for a commercial license. So it's very
important for the spec to be clear and detailed, because everyone will
have to implement it from scratch.


I wonder if Oracle would be willing to back the Berkeley DB option by 
changing the license?


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

Re: Points of order on this WG

[Doug Schepers]

Hi, Arun-

Arun Ranganathan wrote (on 6/25/09 1:38 AM):



On Jun 23, 2009, at 5:10 PM, Ian Hickson wrote:

The Web Storage specification is someone dead-locked right now due
to the  lack of consensus on whether to use SQL or not.


This topic continues to be discussed in Mozilla newsgroups. Few are
reconciled to SQL usage:

Example:
http://groups.google.com/group/mozilla.community.web-standards/topics

Solutions such as BrowserCouch (which straddles localStorage currently)
offer other options: http://www.toolness.com/wp/?p=580

I'd personally rather see a clear articulation of use cases that we
agree are important for the web than further specification work.


Actually, I think that's an excellent point.  Nikunj, maybe that is the 
next logical step?  Could you take charge of that?


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

Re: Points of order on this WG

[Doug Schepers]

 don't have the time or resources.


I suppose I would ask the chairs to weigh in on what they think the best 
way forward is here.


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

Re: 'scroll' and 'resize' events

[Doug Schepers]

Hi, PPK-

Peter-Paul Koch wrote (on 6/17/09 9:41 AM):


More in general, exactly where is the firing of common events such as click,
mousedown and keyup defined? I can't find them in the HTML5 spec (or did I
overlook them?), and the DOM3 Events spec is rather old and has little to do
with reality.


We are updating that spec to align better with reality right now. :)



If they're currently undefined and you ask nicely, I might even create a
first overview of their firing in current browsers; an overview that could
lead to a proper specification. I've got most of the relevant data already
in my head.


Pretty please, with sugar on top?  I'm working on it right now, but 
suggestions, contributions, or corrections are most welcome.


Also, if you'd like to participate in the DOM3 Events teleconferences, 
you are welcome to do so:

 http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0124.html

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

Agenda:DOM3 Events Telcon

[Doug Schepers]

Hi, DOM3 Events Folks-

We will be holding the next DOM3 Events telcon tomorrow, Wednesday, 17 
June 2009, at 21:00 UTC. [1]  Please consult adjust for your local time.


We meet on both phone and IRC.

  Number: Zakim Bridge +1.617.761.6200, +33.4.89.06.34.99 or 
+44.117.370.6152
  conference code: To be determined at the time (meet on IRC 
first to confirm)
  IRC channel: #webapps on irc.w3.org:6665 (that's port 6665, not the 
default)

  Duration: one hour (or less)

Here is the proposed agenda:
* Mutation Events / Modification Notifications / onExecCommand
* Keyboard model
 + diagrams
* Event wording

[1] 
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009month=6day=17hour=21min=0sec=0p1=43p2=101p3=234p4=240


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

Next DOM3 Events Telcon (Time and Day?)

[Doug Schepers]

Hi, Folks-

I will be hosting a F2F at my house next week, but we will be 
reconvening the telcons week after next, probably on Wednesday, June 17 
or Thursday, June 18.  Either day works for me, but finding a good time 
for everyone might be challenging: we typically have attendees from 
Finland (Olli Pettay of Mozilla), from US West Coast (Travis Leithead 
and Jacob ??, of Microsoft), US East Coast (myself, and sometimes some 
government folks who are helping with testing), and now Sydney, 
Australia (Dan Danilatos, of Google Wave). [1]


Olli says:
  For me the best days are Wednesday and Thursday, 10:00am-01:00am (EET).
  Monday and Tuesday evenings/nights are also possible.

Travis says:
  Jacob and I are available for telecons 8-5 pm (perhaps a little
  later if needed).

Pretty much any time on Wednesday or Thursday works for me (late 
afternoon is best).  Looking at TimeAndDate [2], it looks like 21:00 UTC 
on Wednesday might work, if Dan is a morning person (otherwise it would 
be pretty cruel to him).



The proposed agenda is (what else?) mutation events and a sane keyboard 
model.  The telcon will last one hour.  So, I would greatly appreciate 
keeping up the email dialog on mutation events (I will compile the use 
cases and requirements on the wiki, as they roll in).  It may be that we 
don't solve mutation events for DOM3 Events, but put together another 
dedicated spec to address the use cases in another way, and caution 
people about the costs of mutation events.


In addition, I'm hoping that we have a flowchart of keyboard event 
models by that time, for both IE (Travis and Jacob are working on this), 
and if possible, for WebKit.  We have my rough draft of an idealized 
model [3], and Olli's more accurate Gecko model [4].


Dan, or anyone on your team, or anyone at all, could you work on a 
WebKit keyboard event model flowchart?


When I get them all, I'll normalize them for easy comparison, and we can 
work to produce a unified model that works as widely as possible.  If 
anyone wants to send in addition flowcharts for other implementations 
(including mobiles), that would also be welcome.  I don't know that 
we'll be able to solve the IME issues, but if we can, we will.


[1] 
http://www.timeanddate.com/worldclock/meetingtime.html?month=6day=17year=2009p2=43p3=101p4=234p5=240iv=0
[2] 
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009month=6day=17hour=21min=0sec=0p1=43p2=101p3=234p4=240
[3] 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/proposals/d3e-keyflow.svg
[4] 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/proposals/keyflow-gecko.svg



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

[widgets] Open in Browser?

[Doug Schepers]

Hi, Folks-

Right now, widgets gives us a good way to package collections of related 
resources.  I've heard other recent conversations about saving a Web 
page, along with all its associated stylesheets, images, scripts, etc. 
in a single archived file.  Is it worth thinking about how the two are 
related?


I'm thinking that a downloaded and saved file might reuse the widget 
mechanisms, but with an optional flag that indicates it might be opened 
directly in an application (like a browser or authoring tool) rather 
than (or in addition to) a standalone miniapp.


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

Working Vacation

[Doug Schepers]

Hi, WebApps and SVG-

Just to let you know, I will be away for the next week-and-a-half, for a 
conference and a short vacation.  I will still be checking my email 
periodically, but I may not respond very quickly.


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

Re: Web Storage Scope and Charter

[Doug Schepers]

Hi, Nikunj-

Nikunj Mehta wrote (on 4/24/09 2:24 AM):


On Apr 23, 2009, at 1:04 PM, Doug Schepers wrote:


Rather than change the charter (which would require everyone who's
already rejoined to re-rejoin at the simplest, and might require
another AC review at the worst), Nikunj offered that he would be
satisfied if more generic wording were put in the charter, and
highlighted as an issue.


Sorry, typo... I meant to say, if more generic wording were put in the 
*spec*.  (Depending on the outcome of the WG's decision on the matter, 
we could change the charter language during our next rechartering, too, 
if necessary.)




To be precise, I suggested that we can table the charter issue for now,
and emphasize in the spec that we haven't finalized SQL as the only
structured storage access solution.


Yes, thanks for the correction... my original sentence didn't make much 
sense. :)




Preferably, the current Section 4
would be renamed as
[[
Structured Storage
]]

with the following wording in it:
[[
The working group is currently debating whether SQL is the right
abstraction for structured storage.
]]


So, the phrase above is already in the spec... the only thing you're 
asking now is for Section 4 to be renamed, right?  Seems pretty minor.


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

Re: addEventListener naming

[Doug Schepers]

Hi, Alex-

Alex Russell wrote (on 4/24/09 5:31 PM):


The DOM function addEventListener is probably too long. It should,
instead, be named something much shorter owing to the amount of
exercise it receives. Further, it should default the last parameter to
be false (non-capture-phase). This call:

 node.addEventListener(click, function(e) { /* ... */ }, false);

Should be able to be written as (e.g.):

 node.listen(click, function(e) { /* ... */ });

Similarly, removeEventListener should be aliased as unlisten. As a
further help, the common-case operation of listening-for-a-single-call
is currently written as:

 var h = function(e) {
 /*  */
 node.removeEventListener(h);
 };
 node.addEventListener(click, h);

And given how common this operation it, it should probably have an alias:

 node.listenOnce(click, function(e) { /* ... */ });


Obviously, we can't get rid of addEventListener or 
removeEventListener.  In the past, we've had pushback from browser 
vendors that event aliasing is frowned upon.


Personally, I'm fine with your suggestion, and I'd be fine with putting 
it into DOM3 Events on the EventTarget interface.  Here are some of the 
challenges that would need to be overcome:


1) browser implementers would have to sign off on it, and commit to 
putting it into browsers


2) event aliasing would need to be better defined (maybe... if we 
introduced it simply as a new method, and don't dig into the rathole 
about what event aliasing is, that would be fine with me)


3) what would we do for older browsers that don't understand the new 
method?  Script libs are great, but only take us so far... if people 
have to use a script lib to use listen(), then why change it in the 
first place, when it can be aliased in the script lib anyway?  (I'm not 
arguing against it, just raising the issue... maybe the answer is: Make 
people upgrade their browsers to use new technology. ^_^ )


I like your idea of listenOnce().  Would that also be removed by 
unlisten() in case the author wanted to cancel it, or would it require 
its own remover?  Is it worth thinking about simply adding an optional 
parameter to el.listen( evtname, function(e) {}, 
number-of-times-to-listen )?  (Probably not.)  Listing some use cases 
for it might help this along.


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

Web Storage Scope and Charter (was: CfC: FPWD of Server-Sent Events, Web Sockets API, Web Storage, and Web Workers; deadline April 10)

[Doug Schepers]

Hi, Folks-

I discussed this a bit with Nikunj offline, in the context of the 
charter wording.  He and I both agreed that the scope of the charter was 
too narrow (that was my fault; I changed the wording to reflect the 
abstract of the current Web Storage spec, and I probably shouldn't 
have), but we also agreed that the spec itself is higher profile and 
more important than the wording in the charter.


Jonas and others seem to support broadening the scope, and I've also 
been reading various posts in the blogosphere that also question whether 
SQL is the right choice (I see a lot of support for JSON-based 
approaches).  At the very least, I think this group should discuss this 
more before committing to any one solution.  I note that Ian was already 
open to an early spec revision on the same lines, so I hope this isn't 
controversial.


Rather than change the charter (which would require everyone who's 
already rejoined to re-rejoin at the simplest, and might require another 
AC review at the worst), Nikunj offered that he would be satisfied if 
more generic wording were put in the charter, and highlighted as an 
issue.  I would propose something like, This specification currently 
contains wording specific to a SQL or name-value pair storage solution, 
but the WebApps WG is discussing other structured storage alternatives 
that may better match the use cases and requirements.  I leave it up to 
Nikunj to provide wording that would satisfy him.


If this is acceptable to the WG as a whole, I would ask that a message 
similar to the above be put in a prominent place in the spec.  This 
seems like the soundest way forward.


Art, Chaals, care to chime in?  Other comments on this matter?

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


Jonas Sicking wrote (on 4/21/09 6:22 PM):

Hmm.. I tend to agree. Using an SQL database is only one possible
solution that we should be examining. I would rather say that we
should provide storage for structured data inside the UA. I'm not a
fan of calling out neither SQL or name-value pair storage.

At the same time I'm not sure that I care that much about it, as long
as we can change the draft later in case the spec takes a different
turn than the current drafts.

/ Jonas

On Tue, Apr 21, 2009 at 2:44 PM, Nikunj Mehtanikunj.me...@oracle.com  wrote:

 Apparently the new charter [1] that forces everyone to re-join the WG also
 lists among its deliverables as WebStorage with the explanation that
 WebStorage is

 two APIs for client-side data storage in Web applications: a name-value
 pair system, and a database system with a SQL frontend

 Clearly, if the WD of WebStorage has in its abstract something more general,
 the charter should not be so specific.

 I now understand that this new piece of text made its way into the charter
 recently. The last message I can see about charter change for WebApps [1]
 only talks about adding WebWorkers. Apparently other changes were also made,
 but no diff provided to members about the charter change proposal.

 Can you throw some light on this?

 Nikunj

 [1] http://www.w3.org/2009/04/webapps-charter
 [2] http://www.w3.org/mid/3e428ec7-1960-4ece-b403-827ba47fe...@nokia.comian
 Hickson wrote:

 On Fri, 10 Apr 2009, Nikunj Mehta wrote:


 Here's what Oracle would like to see in the abstract:

 This specification defines two APIs for persistent data storage in Web
 clients: one for accessing key-value pair data and another for accessing
 structured data.


 Done.

Re: Web Storage Scope and Charter

[Doug Schepers]

Hi, Ian-

Ian Hickson wrote (on 4/23/09 4:18 PM):

On Thu, 23 Apr 2009, Doug Schepers wrote:


 Jonas and others seem to support broadening the scope, and I've also
 been reading various posts in the blogosphere that also question whether
 SQL is the right choice (I see a lot of support for JSON-based
 approaches).  At the very least, I think this group should discuss this
 more before committing to any one solution.  I note that Ian was already
 open to an early spec revision on the same lines, so I hope this isn't
 controversial.


If there is something that is more useful for Web authors as a whole than
SQL, and if the browser vendors are willing to implement it, then the spec
should use that, yes.

(I don't know of anything that fits that criteria though. Most of the
proposals so far have been things that are useful in specific scenarios,
but aren't really generic solutions.)


This seems to lead into a discussion of use cases and requirements.  You 
don't include those in your draft... Do you have a UCR document that we 
could put on the wiki, like the one for Web Workers [1] (note that 
although I put that into the wiki, I pulled them from somewhere else, 
maybe the HTML wiki)?


So, some of the requirements you're listing here are:
* more useful for Web authors as a whole than SQL
* browser vendors are willing to implement it
* should have broad and scalable applicability

The first two are rather hard to quantify, and part of the process of 
writing a spec is to discover what these are.  The best solution is not 
necessarily the most obvious one from the start, and after deeper 
examination, browsers implementers may be willing to implement something 
that didn't appeal to them at the beginning. (Any spec is better than no 
spec, so the fact that they may be willing to implement whatever the 
current spec says doesn't mean it's the best solution.)


What are the other criteria you have in mind?

Which other solutions have you looked at that don't meet these criteria?



 If this is acceptable to the WG as a whole, I would ask that a message
 similar to the above be put in a prominent place in the spec.  This
 seems like the soundest way forward.


The draft got published today, so it's too late to change the high-profile
version of the spec.


It's not too late at all.  This group can publish as frequently as it 
wants, and we could have another WD up next week, with such a message in 
it.  That would have an equally high profile.


The overhead of this seems much less than that of changing the charter.



Rather than add this message, I'd like to just come
to some sort of conclusion on the issue. What are the various proposals
that exist to solve this problem other than SQL, and how willing are the
browser vendors to implement those solutions?


We can do both: publish an updated version of the spec that says we're 
looking at various solutions, and examine the solutions that come in (as 
a result of broad review that opens that door).


If we are able to come to an immediate conclusion, I'm all in favor of 
that.  But Nikunj, at least, doesn't seem to think we are there yet, so 
I think it's worth reopening the larger issue.



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

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