Re: [selectors-api] Summary of Feature Requests for v2

[Jonas Sicking]

On Wed, Sep 23, 2009 at 9:57 PM, Maciej Stachowiak  wrote:
>
> On Sep 23, 2009, at 5:26 PM, Jonas Sicking wrote:
>
>> On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt 
>> wrote:
>>>
>>> *Scoped Queries*
>>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
>>>
>>> This has been discussed extensively in the past.  Basically, the idea is
>>> that the selector would be evaluated in the scope of the element, in a
>>> way
>>> more compatible with how libraries like JQuery work.  This slightly
>>> different from the :scope pseudo-class proposal, see bug for details.
>>
>> Note that what makes the ">strong, >em" selector (which apparently
>> some libraries support) hard to support spec-wise is that that is not
>> in fact valid CSS syntax. It's certainly possible to define behavior
>> for it, it's pretty clear to me how it's intended to work, but it
>> would mean specifying our own syntax.
>>
>> However if supporting commaseparated queries is critical for libraries
>> then I see no other choise. We'll one way or another have to specify
>> our own syntax, though it can be heavily based on the productions in
>> the Selector spec.
>
> I think we can define an algorithm for turning an implicitly scoped
> pseudo-selector like ">strong, >em" into a proper selector using :scope --
> in this case ":scope>strong, :scope>em". We could either have an API entry
> point that takes a scoped pseudo-selector, defined as transforming to a real
> selector plus establishing a scope node, or just present the algorithm as an
> option for libraries that want to expose pseudo-selector syntax.

Indeed, it's certainly possible. I'd like to find out if we can get
away with not doing that though. I'm curious to get feedback on how
far just having a :scope pseudo-class gets us.

/ Jonas

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

Re: [selectors-api] Summary of Feature Requests for v2

[Maciej Stachowiak]

On Sep 23, 2009, at 5:26 PM, Jonas Sicking wrote:

On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt > wrote:

*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860

This has been discussed extensively in the past.  Basically, the  
idea is
that the selector would be evaluated in the scope of the element,  
in a way

more compatible with how libraries like JQuery work.  This slightly
different from the :scope pseudo-class proposal, see bug for details.


Note that what makes the ">strong, >em" selector (which apparently
some libraries support) hard to support spec-wise is that that is not
in fact valid CSS syntax. It's certainly possible to define behavior
for it, it's pretty clear to me how it's intended to work, but it
would mean specifying our own syntax.

However if supporting commaseparated queries is critical for libraries
then I see no other choise. We'll one way or another have to specify
our own syntax, though it can be heavily based on the productions in
the Selector spec.


I think we can define an algorithm for turning an implicitly scoped  
pseudo-selector like ">strong, >em" into a proper selector  
using :scope -- in this case ":scope>strong, :scope>em". We could  
either have an API entry point that takes a scoped pseudo-selector,  
defined as transforming to a real selector plus establishing a scope  
node, or just present the algorithm as an option for libraries that  
want to expose pseudo-selector syntax.


Regards,
Maciej

Re: [selectors-api] Scoped Queries

[Sean Hogan]

Jonas Sicking wrote:

On Wed, Sep 23, 2009 at 6:00 PM, Sean Hogan  wrote:
  

Jonas Sicking wrote:


On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt 
wrote:

  

*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860

This has been discussed extensively in the past.  Basically, the idea is
that the selector would be evaluated in the scope of the element, in a
way
more compatible with how libraries like JQuery work.  This slightly
different from the :scope pseudo-class proposal, see bug for details.



Note that what makes the ">strong, >em" selector (which apparently
some libraries support) hard to support spec-wise is that that is not
in fact valid CSS syntax. It's certainly possible to define behavior
for it, it's pretty clear to me how it's intended to work, but it
would mean specifying our own syntax.

  

It is clear how it is intended to work, but it is less powerful than a
:scope selector.
I suggest it is a low priority feature.



But a :scope selector by itself doesn't help if the passed in selector
to the library contains a comma separated selector like "foo, bar".

  

However if supporting commaseparated queries is critical for libraries
then I see no other choise. We'll one way or another have to specify
our own syntax, though it can be heavily based on the productions in
the Selector spec.

/ Jonas
  

Libraries already parse selector queries anyway. And some of them add
non-standard selectors and presumeably will continue to do so. I don't think
it is an issue.



The input I've gotten from library developers is that they would love
to not have to ship a selector engine. Apparently it would reduce the
size of for example jQuery with about 10k which is pretty significant.

/ Jonas

  
They could. If something like the following is not sufficient it 
probably means they aren't happy with the native selector engine. In 
that case they will be providing their own anyway.


Element.prototype.queryScopedSelectorAll = function(selector) {
   var validSel = ":scope " + selector.replace(",", ", :scope ");
   return this.querySelectorAll(validSel);
}

Re: [selectors-api] Scoped Queries

[Sean Hogan]

John Resig wrote:


Libraries already parse selector queries anyway. And some of them
add non-standard selectors and presumeably will continue to do so.
I don't think it is an issue.


However the parsing only happens after the selector has been passed to 
the native querySelectorAll implementation. We assume the qSA will 
provide the fastest solution. If it throws an exception we then branch 
off into the old, slower, selector engine and forget qSA entirely. 
Since there's no good error-reporting coming from qSA we can't, 
reasonably, determine how or why an error happened (was it a syntax 
error (fooisn't (div:nth-of-type(2) in IE 8)? does it look like a valid selector 
but there's no existing implementation (div:first)?).


If there were two solutions, one that forced you to use :scope in 
front of all queries (or sub-queries) and one that had a separate 
method that handled cases like "> div" properly, I'd take the latter. 
Parsing queries sucks and is slow, it's easier to just pass all of 
that off to the browser.


--John

Yes, it will have to be a new method.
"> div" may be unambiguously ":scope > div", but if you allow it then 
people will expect "div p" to be ":scope div p"which would conflict the 
current definition.

Re: [selectors-api] Summary of Feature Requests for v2

[Jonas Sicking]

On Wed, Sep 23, 2009 at 8:17 PM, John Resig  wrote:
> Quick Summary of my opinions:
>
> Matches Selector: Super-super useful - critical, in fact. We're not able to
> remove jQuery's selector engine until this is implemented. I'm working with
> the devs at Mozilla to get an implementation landed. Already have a test
> suite in place.

And we have a patch :) So this should be available in Firefox 3.6 I hope.

> Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
> Neither of these are useful, as is, to libraries. What is actually useful is
> the ability to run these against an array (or array-like collection) of DOM
> nodes.

Very good input!

> If I can do:
> document.querySelectorAll.call([document.getElementById("node1"),
> document.getElementById("node2")], "div > span"); then yes, this proposal is
> useful. Rarely do libraries store raw NodeLists (they need to be converted
> into an array or array-like collection first).

I think filtering can easily be done using the filter function that's
available in Firefox these days. Don't know what the implementation
situation is for other UAs. But something like

filteredArray = myArrayOfNodes.filter(function(node) { return
node.matchesSelector("some>selector"); });

For "querySelectorAll on arrays" to work we'd need some function that
can merge multiple nodelists. Once you have that you can easily use
Array.map to get what you need.

> Scoped Queries: Also critical. As it stands, in jQuery, we just punt
> whenever does a query rooted to a DOM element and fallback to the old
> selector engine.

Does the :scope selector solve things for you? Or does it not because
of selectors like "> foo, > bar", or even "foo, bar"?

/ Jonas

Re: [selectors-api] Scoped Queries

[John Resig]

> Libraries already parse selector queries anyway. And some of them add
> non-standard selectors and presumeably will continue to do so. I don't think
> it is an issue.
>

However the parsing only happens after the selector has been passed to the
native querySelectorAll implementation. We assume the qSA will provide the
fastest solution. If it throws an exception we then branch off into the old,
slower, selector engine and forget qSA entirely. Since there's no good
error-reporting coming from qSA we can't, reasonably, determine how or why
an error happened (was it a syntax error (foo div" properly, I'd take the latter. Parsing queries sucks and
is slow, it's easier to just pass all of that off to the browser.

--John

Re: [selectors-api] Scoped Queries

[Jonas Sicking]

On Wed, Sep 23, 2009 at 6:00 PM, Sean Hogan  wrote:
> Jonas Sicking wrote:
>>
>> On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt 
>> wrote:
>>
>>>
>>> *Scoped Queries*
>>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
>>>
>>> This has been discussed extensively in the past.  Basically, the idea is
>>> that the selector would be evaluated in the scope of the element, in a
>>> way
>>> more compatible with how libraries like JQuery work.  This slightly
>>> different from the :scope pseudo-class proposal, see bug for details.
>>>
>>
>> Note that what makes the ">strong, >em" selector (which apparently
>> some libraries support) hard to support spec-wise is that that is not
>> in fact valid CSS syntax. It's certainly possible to define behavior
>> for it, it's pretty clear to me how it's intended to work, but it
>> would mean specifying our own syntax.
>>
>
> It is clear how it is intended to work, but it is less powerful than a
> :scope selector.
> I suggest it is a low priority feature.

But a :scope selector by itself doesn't help if the passed in selector
to the library contains a comma separated selector like "foo, bar".

>> However if supporting commaseparated queries is critical for libraries
>> then I see no other choise. We'll one way or another have to specify
>> our own syntax, though it can be heavily based on the productions in
>> the Selector spec.
>>
>> / Jonas
>
> Libraries already parse selector queries anyway. And some of them add
> non-standard selectors and presumeably will continue to do so. I don't think
> it is an issue.

The input I've gotten from library developers is that they would love
to not have to ship a selector engine. Apparently it would reduce the
size of for example jQuery with about 10k which is pretty significant.

/ Jonas

Re: [selectors-api] Summary of Feature Requests for v2

[John Resig]

Quick Summary of my opinions:

Matches Selector: Super-super useful - critical, in fact. We're not able to
remove jQuery's selector engine until this is implemented. I'm working with
the devs at Mozilla to get an implementation landed. Already have a test
suite in place.

Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
Neither of these are useful, as is, to libraries. What is actually useful is
the ability to run these against an array (or array-like collection) of DOM
nodes.

If I can do:
document.querySelectorAll.call([document.getElementById("node1"),
document.getElementById("node2")], "div > span"); then yes, this proposal is
useful. Rarely do libraries store raw NodeLists (they need to be converted
into an array or array-like collection first).

Scoped Queries: Also critical. As it stands, in jQuery, we just punt
whenever does a query rooted to a DOM element and fallback to the old
selector engine.

Namespace Prefix Resolution: Indifferent.

--John


On Wed, Sep 23, 2009 at 7:51 AM, Lachlan Hunt wrote:

> Hi,
>  I'm planning to look at beginning work on Selectors API v2 soon to add a
> number of requested features that didn't make it into the first version.
>  This e-mail is a summary of what is being considered, and is intended to
> start discussion about which ones are really worth focussing on, and how to
> ensure they address the use cases appropriately.
>
>
> *Matches Selector*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865
>
> The suggestion is for being able to check if a given element matches a
> given selector.  There is already similar functionality provided by JQuery
> and Mozilla have begun working on an implementation for it in Firefox.
>
> For the basic case, this is fairly trivial.  The method just needs to take
> a selector and evaluate it against the element, and return true or false.
>
> But considering the proposed :scope pseudo-class that has been previously
> discussed here and in the CSS WG, it might also be nice to check if the
> element matches the selector in relation to a specified reference element.
>
> For example, given 2 elements, div1 and div2, you could check if div2 is a
> sibling of div1 like this:
>
> div2.matchesSelector(":scope~div", div1);
>
> In this case, the div1 would be the reference element that is matched by
> :scope.  But we still need to determine how useful such functionality would
> be, and whether it's worth pursuing it in this next version.
>
>
> *Filtering NodeLists*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864
>
> The suggestion is for being able to take a NodeList, and filter the nodes
> to obtain a collection of just those that match a given selector.
>
> For example, being able to get a NodeList somehow, do something with it,
> and then filter it more to work with just a subset:
>
> e.g.
> var list = document.querySelctor("div>p");
> // Do something with list, before obtaining the subset
> subset = list.filterSelector(".foo");
> ...
>
> We need to find and document the possible use cases for this feature.
>
>
> *Scoped Queries*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
>
> This has been discussed extensively in the past.  Basically, the idea is
> that the selector would be evaluated in the scope of the element, in a way
> more compatible with how libraries like JQuery work.  This slightly
> different from the :scope pseudo-class proposal, see bug for details.
>
>
> *Collective Queries on NodeLists*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707
>
> The suggestion is to be able to run querySelector() and querySelectorAll()
> on NodeList, and have the result be the union of results in document order
> from running the method on each Element in the NodeList.
>
> e.g.
>
> list.querySelectorAll("p");
>
> Would be somewhat equivalent to running list[i].querySelectorAll("p"); for
>  on each element in the list, and then building an array with the union of
> distinct elements from all the results.  I've been told that similar
> functionality for this already exists in JQuery.
>
> I believe the expectation is that both NodeList.querySelector() and
> .querySelectorAll() would work.  The difference is that querySelector() on a
> NodeList would return a NodeList (unlike on Element which just returns a
> single element) containing the first matches from each node in the list.
> i.e. equivalent to running list[i].querySelector() on each node and then
> combining all results into an array.
>
> It also seems sensible to allow the new scoped methods to be used in an
> analogous way on NodeLists.
>
>
> *Namespace Prefix Resolution*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290
>
> The most controversial issue of the lot.  Need to clearly document the use
> cases and evaluate the problems being solved, and determine if it's really
> worth addressing in this version.
>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>
>

Re: [selectors-api] Summary of Feature Requests for v2

[Garrett Smith]

On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt  wrote:
> Hi,
>  I'm planning to look at beginning work on Selectors API v2 soon to add a
> number of requested features that didn't make it into the first version.
>  This e-mail is a summary of what is being considered, and is intended to
> start discussion about which ones are really worth focussing on, and how to
> ensure they address the use cases appropriately.
>
>
> *Matches Selector*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865

That helps event delegation pattern. That is, adding an event handler
to a container and then inspecting the event's target, to see if what
the user interacted with (and what the program should do about it).
This approach tends to be a much more efficient pattern than
traversing through the entire document to match nodes, and then add
event handler callbacks to them.

The existing draft encourages less efficient programming style of
traversing through the document. Pity.

>
> The suggestion is for being able to check if a given element matches a given
> selector.  There is already similar functionality provided by JQuery and
> Mozilla have begun working on an implementation for it in Firefox.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865

>
> For the basic case, this is fairly trivial.  The method just needs to take a
> selector and evaluate it against the element, and return true or false.
>
> But considering the proposed :scope pseudo-class that has been previously
> discussed here and in the CSS WG, it might also be nice to check if the
> element matches the selector in relation to a specified reference element.
>
> For example, given 2 elements, div1 and div2, you could check if div2 is a
> sibling of div1 like this:
>
> div2.matchesSelector(":scope~div", div1);
>

The matching seems backwards. Should be on the matcher, instead of the
element? I don't see the role of the element being something that does
matching. The matching should be something left to some sort of a
Matcher.

A function to get an actual Selector object would allow the program to
creating a cached matcher.

var selector = QuerySelector.create("div.panel");
var isPanel = selector.matches(event.target);

Garrett

Re: [selectors-api] Summary of Feature Requests for v2

[Sean Hogan]

I think a couple of those features are pretty low priority:

- I don't see the point of collective queries on NodeLists.
Are there any references for the proposal?
Otherwise I can't think of any useful queries that can't already be 
achieved with a single querySelectorAll().


- Filtering NodeLists is trivial once we get matchesSelector(). 


Sean


Lachlan Hunt wrote:

Hi,
  I'm planning to look at beginning work on Selectors API v2 soon to 
add a number of requested features that didn't make it into the first 
version.  This e-mail is a summary of what is being considered, and is 
intended to start discussion about which ones are really worth 
focussing on, and how to ensure they address the use cases appropriately.



*Matches Selector*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865

*Filtering NodeLists*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864

*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860

*Collective Queries on NodeLists*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707

*Namespace Prefix Resolution*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290

Re: [selectors-api] Scoped Queries

[Sean Hogan]

Jonas Sicking wrote:

On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt  wrote:
  

*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860

This has been discussed extensively in the past.  Basically, the idea is
that the selector would be evaluated in the scope of the element, in a way
more compatible with how libraries like JQuery work.  This slightly
different from the :scope pseudo-class proposal, see bug for details.



Note that what makes the ">strong, >em" selector (which apparently
some libraries support) hard to support spec-wise is that that is not
in fact valid CSS syntax. It's certainly possible to define behavior
for it, it's pretty clear to me how it's intended to work, but it
would mean specifying our own syntax.
  


It is clear how it is intended to work, but it is less powerful than a 
:scope selector.

I suggest it is a low priority feature.


However if supporting commaseparated queries is critical for libraries
then I see no other choise. We'll one way or another have to specify
our own syntax, though it can be heavily based on the productions in
the Selector spec.

/ Jonas


  



Libraries already parse selector queries anyway. And some of them add 
non-standard selectors and presumeably will continue to do so. I don't 
think it is an issue.

Re: [selectors-api] Summary of Feature Requests for v2

[Jonas Sicking]

On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt  wrote:
> *Scoped Queries*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
>
> This has been discussed extensively in the past.  Basically, the idea is
> that the selector would be evaluated in the scope of the element, in a way
> more compatible with how libraries like JQuery work.  This slightly
> different from the :scope pseudo-class proposal, see bug for details.

Note that what makes the ">strong, >em" selector (which apparently
some libraries support) hard to support spec-wise is that that is not
in fact valid CSS syntax. It's certainly possible to define behavior
for it, it's pretty clear to me how it's intended to work, but it
would mean specifying our own syntax.

However if supporting commaseparated queries is critical for libraries
then I see no other choise. We'll one way or another have to specify
our own syntax, though it can be heavily based on the productions in
the Selector spec.

/ Jonas

Re: more flexible ABNF for STS?

[Adam Barth]

This sounds like a good idea.  One thing we can do to reduce the
complexity is to have different grammars for server conformance and
for user agent conformance.  Essentially, servers would be required to
conform to the current grammar, but UAs would be required to conform
to the more tolerant grammar.

On Mon, Sep 21, 2009 at 4:27 PM, =JeffH  wrote:
> invalid-STSDirective    =  |  ":" |  ":" 
>                   = anything but ":" or ";"
>                  = anything but ";"

I'm not sure what role ":" is playing here.  It might be easier to
just omit it from the grammar.

Adam

Re: [selectors-api] Summary of Feature Requests for v2

[Lachlan Hunt]

Mike Wilson wrote:

My first priority would be "Matches Selector", and see to that
it fulfills the needs for event delegation.


Is there any special functionality that would be needed to achieve this? 
 If I understand correctly, event delegation just needs to be able to 
check whether the event target element matches a given selector.  So it 
would be something like:


if (evt.target.matchesSelector(".foo>input.bar")) {
   ...
}

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

[widgets] Comments for pre-FPWD of View Modes Media Feature spec

[Arthur Barstow]

Below are comments regarding rev1.1 of the View Modes Media Feature  
spec:


 http://dev.w3.org/cvsweb/2006/waf/widgets-vm/vm-mediafeature.src.html

-Regards, Art Barstow

1. Abstract:

a. I don't understand "the document's content" in this context.
b. Missing a sentence terminator for the first sentence
c. Change the URI under the "Widgets 1.0 family of specifications" to:

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

d. Delete ", which together standarize widgets as a whole."

2. Status of the Document - change the URI under "Editor's Draft" to  
point to the latest Editor's draft of the spec and not a directory.


3. Section 1.1 - the following isn't accurate:

[[
This document defines new media feature, its values and the DOM  
interface for querying the media features and types that apply to a  
document at a given instance in time, including events to detect when  
the values of the said features change.

]]

Change it to:

[[
This document defines a new media feature and its values.
]]

4. Section 1.2 - a User Agent in the context of this spec should  
implement this spec (not the P&C spec)


5. Section 2 - We should strive for more consistency with the various  
widget spec's Conformance section. To that end, change the title to  
just "Conformance" and replace this entire section with just the  
following text in the Conformance section of the latest Editor's  
Draft of the widgets Interface spec i.e.:


[[
All examples and notes in this specification are non-normative, as  
are all sections explicitly marked non-normative. Everything else in  
this specification is normative.


The key words must, must not, should, recommended, may and optional  
in the normative parts of this specification are to be interpreted as  
described in [RFC2119].

]]

6. Section 3. and 3.1

a. I think there are problems with all four of the view modes  
definitions. As such, I would delete all of them and state they are  
defined in terms of their property values as specified in the table  
in Section 3.1


b. Rather than use "Characteristics" and "attributes", just use  
"property". For example, the statement:


[[
The following attributes - summarized in the table below -  
characterize each of the values of the 'view-mode' media feature:

]]

Would become:

[[
The following table defines each of the view-modes' values in terms  
of its properties.

]]

c. The heading of the last column in the table should be shortened to  
something like "width & height"


7. References

a. Delete unused References: DOM2Events, DOM2Style, HTML4, CSS21,  
Widgets-Landscape, Widgets-Reqs


b. Make Normative: [Media Queries]

Re: [A&E] Last Call comments (1)

[Scott Wilson]

Hmm, I raised this one too.

I can't see how the origin handles instances exactly, and the concept  
of "origin" doesn't seem all that relevant to our implementation  
anyway - it looks more like something for browser makers to worry over?


Why is "origin of a widget" preferable to "instance of widget"?

This could be important as some conformance statements relate to the  
concept, e.g:
Upon getting the preferences attribute, the user agent must return a  
Storage object that represents the storage area for the origin of a  
widget.


If "origin of a widget" is not a sensible concept for the UA (as  
opposed to widget instance), does this fail conformance? How would you  
test for it for the UA anyway?


S

On 23 Sep 2009, at 17:10, Marcos Caceres wrote:




5.4
How to handle multiple instances of the same widget?
As far as I remember it was to be moved to WURIv2, but it seems  
important in the context of preferences.


No, it's not important. They are bound to the origin of a widget as
defined in WURI, and the origin of a widget is universally unique.
Hence, preferences are unique and not shared.





smime.p7s
Description: S/MIME cryptographic signature

Re: FYI: W3C Workshop on Access Control Application Scenarios; Nov 17-18 in Luxembourg

[Rigo Wenning]

Hi Art, Anne, 

looks like the focus of the CORS specification is on very simple 
access control that would just express that site A allows access to 
content if the javascript stuff calls it from a thing found on site 
B. 

The workshop deals with conditions (policy) under which a certain 
resource can be accessed. The conditions include the availability of 
credentials that include crypto credentials. It will also deal with 
the question on how to address credentials that are needed to get 
access. It may also address the question on how to describe the 
resource you are asserting conditions and access control 
restrictions on (e.g. clouds). 

Finally, it deals with privacy semantics and identity management of 
access control and how to assert them e.g. in XACML conditions. 
These are only the things I definitely know will come up. 

So it depends on whether Anne or other Members from the Webapps 
group see benefit in finding out and contributing to more advanced 
access control issues. 

It may be nice for those wanting more power in cross site access 
control, to want to find out how to use more advanced languages 
together with CORS. That may be a very useful contribution from 
folks in webapps.

Best, 

Rigo


On Wednesday 23 September 2009, Anne van Kesteren wrote:
> On Wed, 23 Sep 2009 02:18:02 +0200, Arthur Barstow
>  
> 
> wrote:
> > Given WebApps' CORS spec, this Workshop (November 17-18 in
> > Luxembourg) may be of interest to you:
> >
> >http://www.w3.org/2009/policy-ws/cfp.html
> 
> Thanks Art. I looked into this and couldn't really figure out how
>  CORS relates. And if I just misunderstood it, does that mean I
>  should submit a position paper on CORS? The scope seems quite
>  broad so I guess it might fit in somehow, but then we already
>  have a WG that handles it...
> 
> It also sounds like it has overlap with the IETF activity on
>  OAuth.
> 
> (Personally I get quite lost in the sea of terminology used on
>  that page
> 
> :-))
> 



signature.asc
Description: This is a digitally signed message part.

Re: [widgets] Draft Agenda for 24 September 2009 Voice Conf

[Marcos Caceres]

On Wed, Sep 23, 2009 at 4:36 PM, Marcin Hanclik
 wrote:
> Hi,
>
> One more comment to the below:
> There is one use case not handled by the below scenarios:
> In case the width/height are dropped on the Widget interface, the widget 
> would not know the initial dimensions.
> E.g. in Win32 each new window get WM_SIZE event with the initial width/height.
> However, I am not sure whether we should mandate the ResolutionChangedEvent 
> to be used for the initial viewport size.
>
> So I would opt for keeping the ResolutionChangedEvent, dropping width/height 
> on the ResolutionChangedEvent, and keeping width/height in the Widget 
> interface.
>

I'm still confused as to why we can't keep both. Is it because of redundancy?


-- 
Marcos Caceres
http://datadriven.com.au

Re: [A&E] Last Call comments (1)

[Marcos Caceres]

2009/9/15 Marcin Hanclik :
> The below comments refer to:
> Widgets 1.0: The widget Interface
> Editor's Draft 14 September 2009
>
> General:
> Replace "can" with "may" in the whole document.

I've used can deliberately throughout the document where statements of
fact are made. To use may would result in a conformance clause where
one is not needed.

> 2.
> Feature
> Why to repeat the definition from P&C?

People complain about having to jump from spec to spec. Makes the
document easier to read.

> Getting / Setting
> Refer to HTML5 for those definitions?

No, they are defined in WebStorage but I stole them  (muahaha!) :) I
only reference other specs where something that affects
conformance/behavior is said.

> Viewport
> [1] says that scrollbars are part of the rendering area
> (I do not claim that it is fully correct, I assume scrollbars are a 
> discussion point, specifically in the context of DHTML where they could 
> appear and vanish depending on the dynamic content).
> My proposal is to make this definition non-final.
>
> All definitions:
> Could we have a document with the definitions for all specifications from the 
> family?

That could be possible, but some definitions are inline - better to
leave them where they are and just follow the anchors in the document.

> 3.
> achived -> achieved

Fixed.

> 4.
> Again about the definitions:
> Could we have a common definition of the user agent, decoupled from the specs?
> (e.g. UA in P&C is an implementation, here it is a software implementation)

Yes, we have talked about this but just haven't got around to doing
it. I personally don't think we need an overarching definition,
however. The more modular these specs are, the better IMO. We try to
make it pretty clear what the dependencies for each UA are.

> 4.2
> a read-only item is an item in a storage area cannot be ...
> should be
> a read-only item is an item in a storage area that cannot be ...

Fixed.

> 5.
> Why aren't the following attributes available on the widget interface?
> @viewmodes from ,

That's your spec :) Add it as supplemental attribute to the widget interface.

> @short from ,

I would not mind adding this one, maybe calling it widget.shortname.

> @href from  and license,

What is the use case?

> icons

What is the use case? Also, these may be changing dynamically so it
makes things a mess.

I think we should create and Icon API at some point in the near future
(leverage HTML5 cross-doc communication), but we should not add
anything poorly specified now.

> 5.
> It preferences(via the preferences attribute).
> Unclear.

Yikes, changed it to:
"The interface also allows authors to access persistently-stored
preferences (via the preferences attribute)."

> 5.
> A user agent should to impose ...
> Should be
> A user agent should impose ...

I've deleted that assertion (Artb pointed out that it is an untestable
weasel assertion).

> 5.
> ... global object context of the widget's start file.
> What about:
> ... global object context of the document loaded from widget's start file.
> ???

I'm working on a better definition for this with Robin.

> 5.
> In
> ... global object context of the widget's start file.
> And
> A user agent whose start file implements HTML5's Window interface ...
> The "start file"s refer to 2 different locations.

I'm going to rewrite all this. Will let you know as soon as it is done.

> 5.4
> How to handle multiple instances of the same widget?
> As far as I remember it was to be moved to WURIv2, but it seems important in 
> the context of preferences.

No, it's not important. They are bound to the origin of a widget as
defined in WURI, and the origin of a widget is universally unique.
Hence, preferences are unique and not shared.

> 5.4
> Storage interface:
> The A&E specification should not add interpretation to the WebStorage with 
> regard to the exceptions thrown. It would be better to improve the WebStorage 
> specification.
>

Hixie was the one who said we need to define it here. There is no
notion of a read-only items in Web Storage. We can ask Hixie again,
but I doubt he will pay us any attention (besides, I agree with him.
It should be spec'd in our spec... no need to bloat WebStorage with
widget-only stuff).

> Specifically the NO_MODIFICATION_ALLOWER_ERR shall be presented in WebIDL on 
> Storage interface based on "raises" keyword of WebIDL.
>

That would be nice. I don't know any WebIDL. Do you want to write a
supplemental IDL declaration for us to include in the spec? We can
live without it, but would be nice to have (makes the spec easier to
understand).

> 5.4.1
> onClick -> onclick

Fixed (though I don't think case matters in HTML5, the parser still
works it out)

> 5.4.2#3
> ... make the preferences attribute a pointer that storage area.
> Should be
> ... make the preferences attribute a pointer to that storage area.

Fixed.

> 5.4.2#2.4.1
> ... apply the  rule for dealing with an invalid Zip archive ...
> And
> "In the event that an implementa

Mail List Etiquette & How to Loose Your Privileges

[Arthur Barstow]

All,

I think we all appreciate frank and open technical discussions about  
the Web Applications WG's specifications but we must also be  
respectful and professional in our exchanges.


My personal tolerance for terse exchanges is relatively high but that  
is not true for everyone and we must respect our differences via our  
behavior, interactions and responses.


More specifically, please read and follow:

1. The Community Principles defined by the W3C's Positive Work  
Environment Task Force:


 http://www.w3.org/2007/06/PWET-statement-of-principles.html

2. Section 3.1 of the W3C's Process document; nota bene: the "social  
competence" participation requirement:


 http://www.w3.org/2005/10/Process-20051014/ 
policies.html#ParticipationCriteria


Failure to adhere to the above social norms may result in being  
removed from a mail list (for at least some period of time).  
Depending upon the severity, immediate removal may be warranted i.e.  
no warning(s).


So please, use these mail lists for technical discussions only.

-Regards, Art Barstow; Co-Chair of the Web Applications WG

Re: [widgets] WURI Review pre-LC review

[Marcos Caceres]

2009/9/17 Robin Berjon :
> On Sep 3, 2009, at 14:25 , Marcos Caceres wrote:
>>>
>>> Many specifications in the Web stack depend on a context being defined
>>> that includes a current IRI. This is easily provided for documents
>>> retrieved over HTTP, or from the local file system, but is currently
>>> undefined for documents extracted from within a widget package.
>>
>> I don't like the above. Why are you starting this as an argument?
>
> It's not an argument, but I see how to change it.

Ok, I'll re-read it before we publish again.

>>> This document was published by the Web Applications WG as a Last Call
>>> Working Draft. This document is intended to become a W3C Recommendation.
>>> If you wish to make comments regarding this document, please send them
>>> to public-webapps@w3.org (subscribe, archives). The Last Call period
>>> ends 10 November 2009. All feedback is welcome.
>>
>> This LC period is too long. Make it 10th of October or mid October. This
>> is to facilitate two LCs.
>
> We'll change that when we really do go to LC. As things stand, we might be 
> delayed a little more so I can address Jere's comments which require some 
> rearchitecting.

Ok.

>>> This specification defines the widget URI scheme that is used to address
>>> resources inside a widget [WIDGETS].
>>
>> change to "inside a widget package"
>
> That text is gone, but I've changed it elsewhere.

Mmmkay.

>>> There are many different efforts that have specified URI schemes to
>>> access the content of Zip archives, or endeavour to do so. While these
>>
>> endeavour > endeavor
>
> Perhaps the day you pry my spellchecker from the unflinching grip of my cold, 
> dead fingers.

The W3C mandates specs be in en-us [reference-needed] (it's part of a
evil ploy the W3C has to enforce the US imperialist agenda through
linguistic hegemony).

>>> efforts have merit, and while W3C Widgets rely on Zip as a packaging
>>> format, the use cases that this specification addresses are radically
>>> different.
>>
>> "radically" is unnecessary. You make grand statements, but then don't
>> back them. What is so radical about what we are doing? Don't tell me (I
>> know how awesome we are!), put in the spec :)
>
> Hmmm, it seems to me that you don't know what "radically" means. It means "at 
> its root". We're doing something that is "at its roots" different. Something 
> that is "radically different" isn't necessarily "radical", in fact there is 
> little connection other than etymological. That being said I've changed it to 
> "substantially" to make it more K12 compliant :)
>

And there I thought radical meant "radical dude!" (Thanks A LOT, Ninja Turtles!)

>>> The scheme defined in this specification could be used to implement
>>> inter-widget communication, but that is outside the scope of this
>>> current document.
>>
>> This is not proven. I would just say that cross-widget is out of scope
>> and, may be future work, but not that it could be used for that.
>
> "Uniquely identifying widgets, or multiple instances of the same widget 
> package, as well as using that to enable inter-widget communication are 
> outside the scope of this document."
>

Nice.

>>> 4. Requirements
>>
>> All this should be moved to the widgets requirements doc.
>
> I don't have a strong opinion but I'm not sure. The widgets requirements 
> document holds requirements for the whole family, but it stops before the 
> technical implications. I don't think that there's a requirement to have a 
> URI scheme when you go and create a widget platform, it just so happens that 
> the technical decisions we made lead to a place where we need one.
>
> But I'm happy to remove them if you want to past them in the WR — the shorter 
> the better!

Yes, please.

>>> Must not require widget developers to be aware of it for basic tasks
>>> Using this scheme as the IRI of resources inside a widget must not force
>>> widget developers to be aware of its existence for simple tasks such as
>>> linking between widget resources, and would ideally not require such
>>> knowledge for advanced tasks either.
>>
>> Yep... but I would qualify this as "the whole scheme" or "must not need
>> to know about every component part of the scheme", as you need to at
>> least know about the path component.
>
> I see what you mean — technically if you use the path bit then you "know 
> about the scheme", but that's not what I meant, really. People shouldn't have 
> to learn anything to use it for basic tasks (e.g. just do a path). I think 
> most developers don't think that they're using the ipath-noscheme followed by 
> ifragment when they link to "marcos.xhtml#nose". So I'm unsure how to change 
> this to reflect both sides.
>

Ok, leave it then (and I've asked before to not to make fun of my nose).

>>> A careful review of existing schemes has found that none matches the
>>> needs above.
>>
>> "existing schemes" needs references to all the ones we looked at.
>>
>> "careful review" > "review" and link it to the wi

Re: CORS redirect behavior proposal

[Adam Barth]

On Wed, Sep 23, 2009 at 5:34 AM, Anne van Kesteren  wrote:
> For simple cross-origin requests Origin would be a space-separated list of
> origins indicating the redirect chain.

When we used this syntax for the Sec-From header, Mark Nottingham
advocated using commas to separate the origins to better align with
other HTTP headers.

> What order would be best there?

I think the simplest thing is to list the origins in the order in
which the user agent encounters them (with adjacent duplicates
removed).

> This is more or less on what I'm planning to go with (will wait a day or so
> with specifying to allow for feedback) unless someone has a better idea that
> keeps things relatively simple and works with the preflight result cache.

That sounds reasonable to me.  I don't quite understand all the
constraints we get from the preflight cache, but the rest sounds fine.

Thanks,
Adam

Re: FYI: W3C Workshop on Access Control Application Scenarios; Nov 17-18 in Luxembourg

[Anne van Kesteren]

On Wed, 23 Sep 2009 02:18:02 +0200, Arthur Barstow   
wrote:
Given WebApps' CORS spec, this Workshop (November 17-18 in Luxembourg)  
may be of interest to you:


   http://www.w3.org/2009/policy-ws/cfp.html


Thanks Art. I looked into this and couldn't really figure out how CORS  
relates. And if I just misunderstood it, does that mean I should submit a  
position paper on CORS? The scope seems quite broad so I guess it might  
fit in somehow, but then we already have a WG that handles it...


It also sounds like it has overlap with the IETF activity on OAuth.

(Personally I get quite lost in the sea of terminology used on that page  
:-))



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Publishing XMLHttpRequest

[Anne van Kesteren]

On Wed, 12 Aug 2009 18:03:52 +0200, Stewart Brodie  
 wrote:

The Abstract is good for an abstract, but I don't think it's got enough
detail in it for a list of differences.  I'll review the new documents in
closer detail when I get a chance and see if I can suggest some words.  
I'd like to adopt some of the new features into my implementation too,  
as time permits, probably starting with things like overrideMimeType  
that are

already widely implemented elsewhere.


I changed my mind and added a section on this by the way:

  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#differences

(Quite a while ago, but it seems I did not reply to this email.)


--
Anne van Kesteren
http://annevankesteren.nl/

Re: skipping and ignoring

[Marcos Caceres]

On Wed, Sep 23, 2009 at 12:44 PM, Robin Berjon  wrote:
> Hi,
>
> while writing tests, we've hit upon something that could use a little
> clarification: the distinction between skip and ignore.
>
> One interpretation that we can come to is that the two terms means the same
> thing for files and attributes, but for XML element processing "ignore"
> descends into the content whereas "skip" just moves on to the next. This is
> consistent for instance with the specification indicating that element
> content inside  has to be ignored. It is, however, not consistent with
> its application to  or  examples whereby those that don't
> match the locale are said to be ignored (logically it would be skipped —
> even though descending into the subtree would likely do nothing).
>
> Another interpretation is that when something is ignored the UA must act as
> if it hadn't even been there in the first place, whereas when skipping it
> ought to not process it but remember it has seen it. This interpretation is
> built on the fact that the definitions say that ignore causes the UA to "act
> as if [what is being ignored] is not present" whereas skip is to "proceed to
> the next element".
>
> It becomes less astract if you look at the following conformance statements.
>
> In "10.1.19 Algorithm to Process a Configuration Document", step 11, part "A
> content element", the following normative assertion is made: "If this is not
> the first content element encountered by the user agent, then the user agent
> must skip this element." A few lines later it is followed by "If the src
> attribute of the content element is absent, then the user agent must skip
> this element."
>
> Take the following configuration:
>
>  
>  
>
> You see the first. It doesn't have an @src so you skip it. You reach the
> second. It's perfectly serviceable, but it's not the first. Or is it? If you
> consider the first one to have been ignored, then you have to act as if it
> wasn't there.

Ok, I see the confusion.

> But instead of ignored it says skipped — and it's not clear
> whether skipped has the same meaning.

Good point. The second must not be processes because it is not the
first. It don't matter that is serviceable. It might just be that I
used ignore where skip was intended.

> If the second element is not taken into account, then we have a potential
> problem with forward compatibility. Let's imagine that we have v2 out, for
> which the following is correct:
>
>  
>  
>
> Clearly the desired behaviour is for v2 runtimes to process the first, and
> v1 runtimes to fallback to the second.

IMO the correct behavior would be for src attributes to take URIs and
for the second to be skipped. However, I'm sure you can dream up other
examples.

The "only ever use the first, even if b0rked" behavior is based on
HTML's behavior (particularly the  element). I'm happy to break
ranks with HTML parsing if that is what the WG thinks would be best.
However, it's a pretty big change to the parsing model, but if it
future proofs us, then it might be worth it.

> The same issue applies to other elements that refer to the skip/ignore
> distinction. We believe that some editorial improvements to those
> definitions would be welcome.

Agreed. I'll work on improving those but that depends on if we change
the parsing behavior or not to match what you suggested above.

-- 
Marcos Caceres
http://datadriven.com.au

Re: Progress Events - Credits Edits

[Charles McCathieNevile]

On Wed, 23 Sep 2009 15:33:22 +0200, Robin Berjon  wrote:


On Sep 19, 2009, at 15:00 , Charles McCathieNevile wrote:
On Sat, 19 Sep 2009 07:55:23 +0200, Garrett Smith  
 wrote:

In looking at the credits, I noticed all of:


Bjoern Hoehrmann, Björn Hoehrmann, Björn Höhrmann, Bjoern H�hrmann

I am not sure if there are two similar "BH", as "Björn" and "Bjoern".
Entities for the characters should be used.


You score a prize. I guess it is time to collapse all the names of the  
mysterious Mr Hoehrmann into a single identity.


Historically this was actually intentional — though its appearance in PE  
might be through copy and paste.


No, it was done by hand apparently...

anyway. Less talk, and maybe I will get to editing the draft :S

cheers

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: XHR request state vs provisional responses

[Anne van Kesteren]

On Tue, 25 Aug 2009 17:34:18 +0200, Julian Reschke   
wrote:
was it ever discussed to expose information from provisional HTTP  
responses  
() to  
clients?


That might become interesting once extensions such as  
 ever get  
deployed...


I don't think exposing HTTP 1xx status codes has been discussed before.


--
Anne van Kesteren
http://annevankesteren.nl/

Re: [A&E] Last Call comments (2): discovery & localization

[Marcos Caceres]

Robin Berjon wrote:

On Sep 21, 2009, at 20:08 , Marcos Caceres wrote:

5.1

Localization

Shall it be possible for the widget to programmatically discover the
localization path it was loaded from (section 9 of P&C)?


Yes, you can check its URI. If the implementation supports the window
object, then it possible.


How? window.location will return widget:///foo.html irrespective of
whether the runtime loaded /foo.html or /locales/fr/foo.html.


Ah, ok. Yes, forgot about that. Well, the best we can do is give the 
lang list that the UA is using? Ideas? is this really important? I can 
see it being useful to know where stuff is being loaded from instead of 
having to guess where a resource was loaded from.

Re: [cors] Comments on 17 March 2009

[Anne van Kesteren]

On Tue, 30 Jun 2009 17:11:04 +0200, Frederick Hirsch  
 wrote:
I have some basic comments and questions on "Cross-Origin Resource  
Sharing", W3C Working Draft 17 March 2009

http://www.w3.org/TR/2009/WD-cors-20090317/


Going forward, may I suggest you review:

  http://dev.w3.org/2006/waf/access-control/

It usually has better wording, less bugs, and less spelling mistakes than  
the latest version on TR/.



Perhaps some of these have been answered already and there are probably  
others I did not list.


I'll try to answer them all. (Though having done that now I didn't have  
one to all. Maybe someone else can help out?)



1. GET can have side effects, so can we assume it is safe? Thus does it  
not also always require pre-flight check?


The threat is not the actual request but exposing the response. A  
cross-origin request can already be made by a variety of means, e.g.  
, 

Re: [A&E] Last Call comments (2): discovery & localization

[Robin Berjon]

On Sep 21, 2009, at 20:08 , Marcos Caceres wrote:

5.1

Localization

Shall it be possible for the widget to programmatically discover  
the localization path it was loaded from (section 9 of P&C)?


Yes, you can check its URI. If the implementation supports the window
object, then it possible.


How? window.location will return widget:///foo.html irrespective of  
whether the runtime loaded /foo.html or /locales/fr/foo.html.


--
Robin Berjon - http://berjon.com/

RE: [widgets] Draft Agenda for 24 September 2009 Voice Conf

[Marcin Hanclik]

Hi,

One more comment to the below:
There is one use case not handled by the below scenarios:
In case the width/height are dropped on the Widget interface, the widget would 
not know the initial dimensions.
E.g. in Win32 each new window get WM_SIZE event with the initial width/height.
However, I am not sure whether we should mandate the ResolutionChangedEvent to 
be used for the initial viewport size.

So I would opt for keeping the ResolutionChangedEvent, dropping width/height on 
the ResolutionChangedEvent, and keeping width/height in the Widget interface.

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Marcin Hanclik
Sent: Wednesday, September 23, 2009 3:22 PM
To: Arthur Barstow; public-webapps
Subject: RE: [widgets] Draft Agenda for 24 September 2009 Voice Conf

Hi Art, All,

I would like to suggest to add to the agenda the point that appeared during the 
widgets testing event.
It is related to the Widget Interface, View Modes and patterns.
The comments below will be valid also as LC comments to the Widget Interface.

The Widget Interface includes width and height attributes. On the other hand 
the View Modes Interfaces defines the ResolutionChangedEvent event.
So we may have at least the following scenarios:
Scenario 1:

a) the dimensions of the viewport change.

b) the ResolutionChangedEvent is fired.

c) the widget gets the new dimensions from the event

Scenario 2:

a) the dimensions of the viewport change.

b) the ResolutionChangedEvent is fired.

c) the widget gets the new dimensions from the Widget interface (the widget 
object)

Incorporating the onresize handler on the  element, we could have another 
scenarion:
Scenario 2:

a) the dimensions of the viewport change.

b) the onresize handler is triggered.

c) the widget gets the new dimensions from the Widget interface (the widget 
object)

So we have 3 scenarios for 1 thing (notification about changed size and 
retrieval of the new dimensions).
If we want to keep ResolutionChangedEvent, we have two methods of getting the 
new width/height:

i) from the ResolutionChangedEvent

ii) from the Widget interface

Therefore I suggest picking up one of the following:

1. Drop the ResolutionChangedEvent, mandate onresize handler, keep width/height 
in the Widget interface.

2. Drop width/height from the ResolutionChangedEvent, ignore onresize handler, 
keep width/height in the Widget interface.

3. Keep the ResolutionChangedEvent, ignore onresize handler, drop width/height 
in the Widget interface.

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arthur Barstow
Sent: Wednesday, September 23, 2009 1:56 PM
To: public-webapps
Subject: [widgets] Draft Agenda for 24 September 2009 Voice Conf

Below is the draft agenda for the September 24 Widgets Voice
Conference (VC).

Inputs and discussion before the VC on all of the agenda topics via
public-webapps is encouraged).

Please address Open/Raised Issues and Open Actions before the meeting:

   http://www.w3.org/2008/webapps/track/products/8

Minutes from the last VC:

   http://www.w3.org/2009/09/17-wam-minutes.html

-Regards, Art Barstow

Logistics:

 Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London;
09:00 Boston; 06:00 Seattle
 Duration = 90 minutes
 Zakim Bridge = +1.617.761.6200, +33.4.89.06.34.99 or
+44.117.370.6152
 PIN = 9231 ("WAF1");
 IRC channel = #wam; irc://irc.w3.org:6665
 Confidentiality of minutes = Public

Regrets: Marcos, Marcin, Josh

Agenda:

1. Review and tweak agenda

2. Announcements

a. News/summary from the Widget Testing event
   http://www.w3.org/2008/webapps/wiki/TestWorkshop2009

3. Widget Interface spec: proposal to publish LCWD #2

  

4. Access Requests Policy (WARP) spec: comment period ended Sept 20;
review comments

  
  

5. URI Scheme spec: status of LC publication

  

6. View Modes Media Features spec: proposal to publish FPWD

  

7. View Modes Interfaces spec: Arve (from IRC) "the bit that troubles
me is rotation"

  

8. AOB






Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watana

Re: Progress Events - Credits Edits

[Robin Berjon]

On Sep 19, 2009, at 15:00 , Charles McCathieNevile wrote:
On Sat, 19 Sep 2009 07:55:23 +0200, Garrett Smith > wrote:

In looking at the credits, I noticed all of:


Bjoern Hoehrmann, Björn Hoehrmann, Björn Höhrmann, Bjoern H�hrmann

I am not sure if there are two similar "BH", as "Björn" and "Bjoern".
Entities for the characters should be used.


You score a prize. I guess it is time to collapse all the names of  
the mysterious Mr Hoehrmann into a single identity.


Historically this was actually intentional — though its appearance in  
PE might be through copy and paste.


--
Robin Berjon - http://berjon.com/

RE: [widgets] Draft Agenda for 24 September 2009 Voice Conf

[Marcin Hanclik]

Hi Art, All,

I would like to suggest to add to the agenda the point that appeared during the 
widgets testing event.
It is related to the Widget Interface, View Modes and patterns.
The comments below will be valid also as LC comments to the Widget Interface.

The Widget Interface includes width and height attributes. On the other hand 
the View Modes Interfaces defines the ResolutionChangedEvent event.
So we may have at least the following scenarios:
Scenario 1:

a) the dimensions of the viewport change.

b) the ResolutionChangedEvent is fired.

c) the widget gets the new dimensions from the event

Scenario 2:

a) the dimensions of the viewport change.

b) the ResolutionChangedEvent is fired.

c) the widget gets the new dimensions from the Widget interface (the widget 
object)

Incorporating the onresize handler on the  element, we could have another 
scenarion:
Scenario 2:

a) the dimensions of the viewport change.

b) the onresize handler is triggered.

c) the widget gets the new dimensions from the Widget interface (the widget 
object)

So we have 3 scenarios for 1 thing (notification about changed size and 
retrieval of the new dimensions).
If we want to keep ResolutionChangedEvent, we have two methods of getting the 
new width/height:

i) from the ResolutionChangedEvent

ii) from the Widget interface

Therefore I suggest picking up one of the following:

1. Drop the ResolutionChangedEvent, mandate onresize handler, keep width/height 
in the Widget interface.

2. Drop width/height from the ResolutionChangedEvent, ignore onresize handler, 
keep width/height in the Widget interface.

3. Keep the ResolutionChangedEvent, ignore onresize handler, drop width/height 
in the Widget interface.

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arthur Barstow
Sent: Wednesday, September 23, 2009 1:56 PM
To: public-webapps
Subject: [widgets] Draft Agenda for 24 September 2009 Voice Conf

Below is the draft agenda for the September 24 Widgets Voice
Conference (VC).

Inputs and discussion before the VC on all of the agenda topics via
public-webapps is encouraged).

Please address Open/Raised Issues and Open Actions before the meeting:

   http://www.w3.org/2008/webapps/track/products/8

Minutes from the last VC:

   http://www.w3.org/2009/09/17-wam-minutes.html

-Regards, Art Barstow

Logistics:

 Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London;
09:00 Boston; 06:00 Seattle
 Duration = 90 minutes
 Zakim Bridge = +1.617.761.6200, +33.4.89.06.34.99 or
+44.117.370.6152
 PIN = 9231 ("WAF1");
 IRC channel = #wam; irc://irc.w3.org:6665
 Confidentiality of minutes = Public

Regrets: Marcos, Marcin, Josh

Agenda:

1. Review and tweak agenda

2. Announcements

a. News/summary from the Widget Testing event
   http://www.w3.org/2008/webapps/wiki/TestWorkshop2009

3. Widget Interface spec: proposal to publish LCWD #2

  

4. Access Requests Policy (WARP) spec: comment period ended Sept 20;
review comments

  
  

5. URI Scheme spec: status of LC publication

  

6. View Modes Media Features spec: proposal to publish FPWD

  

7. View Modes Interfaces spec: Arve (from IRC) "the bit that troubles
me is rotation"

  

8. AOB






Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is 
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or 
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by 
responding to this e-mail. Thank you.

[WARP] "uri" attribute is confusing

[Dominique Hazael-Massieux]

Hi,

The attribute "uri" on the  element in WARP is somewhat
misleading - what it takes is more a URL pattern than a URI. I would
suggest renaming it in "urlpattern" or just "pattern" (unless there are
already many implementations that rely on that attribute name).

There may be lessons to be taken in designing these patterns from POWDER
http://www.w3.org/TR/2009/REC-powder-dr-20090901/ - although I suspect
the POWDER expressivity needs are much greater than what is needed here.

Dom

RE: [selectors-api] Summary of Feature Requests for v2

[Mike Wilson]

My first priority would be "Matches Selector", and see to that
it fulfills the needs for event delegation.

Best regards
Mike Wilson

Lachlan Hunt wrote:
> Hi,
>I'm planning to look at beginning work on Selectors API v2 soon to 
> add a number of requested features that didn't make it into the first 
> version.  This e-mail is a summary of what is being 
> considered, and is 
> intended to start discussion about which ones are really 
> worth focussing 
> on, and how to ensure they address the use cases appropriately.
> 
> 
> *Matches Selector*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865
> 
> The suggestion is for being able to check if a given element 
> matches a 
> given selector.  There is already similar functionality provided by 
> JQuery and Mozilla have begun working on an implementation for it in 
> Firefox.
> 
> For the basic case, this is fairly trivial.  The method just needs to 
> take a selector and evaluate it against the element, and 
> return true or 
> false.
> 
> But considering the proposed :scope pseudo-class that has been 
> previously discussed here and in the CSS WG, it might also be nice to 
> check if the element matches the selector in relation to a specified 
> reference element.
> 
> For example, given 2 elements, div1 and div2, you could check 
> if div2 is 
> a sibling of div1 like this:
> 
> div2.matchesSelector(":scope~div", div1);
> 
> In this case, the div1 would be the reference element that is 
> matched by 
> :scope.  But we still need to determine how useful such functionality 
> would be, and whether it's worth pursuing it in this next version.
> 
> 
> *Filtering NodeLists*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864
> 
> The suggestion is for being able to take a NodeList, and filter the 
> nodes to obtain a collection of just those that match a given 
> selector.
> 
> For example, being able to get a NodeList somehow, do 
> something with it, 
> and then filter it more to work with just a subset:
> 
> e.g.
> var list = document.querySelctor("div>p");
> // Do something with list, before obtaining the subset
> subset = list.filterSelector(".foo");
> ...
> 
> We need to find and document the possible use cases for this feature.
> 
> 
> *Scoped Queries*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
> 
> This has been discussed extensively in the past.  Basically, 
> the idea is 
> that the selector would be evaluated in the scope of the 
> element, in a 
> way more compatible with how libraries like JQuery work.  
> This slightly 
> different from the :scope pseudo-class proposal, see bug for details.
> 
> 
> *Collective Queries on NodeLists*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707
> 
> The suggestion is to be able to run querySelector() and 
> querySelectorAll() on NodeList, and have the result be the union of 
> results in document order from running the method on each 
> Element in the 
> NodeList.
> 
> e.g.
> 
> list.querySelectorAll("p");
> 
> Would be somewhat equivalent to running 
> list[i].querySelectorAll("p"); 
> for  on each element in the list, and then building an array with the 
> union of distinct elements from all the results.  I've been told that 
> similar functionality for this already exists in JQuery.
> 
> I believe the expectation is that both NodeList.querySelector() and 
> .querySelectorAll() would work.  The difference is that 
> querySelector() 
> on a NodeList would return a NodeList (unlike on Element which just 
> returns a single element) containing the first matches from 
> each node in 
> the list. i.e. equivalent to running list[i].querySelector() on each 
> node and then combining all results into an array.
> 
> It also seems sensible to allow the new scoped methods to be 
> used in an 
> analogous way on NodeLists.
> 
> 
> *Namespace Prefix Resolution*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290
> 
> The most controversial issue of the lot.  Need to clearly 
> document the 
> use cases and evaluate the problems being solved, and 
> determine if it's 
> really worth addressing in this version.
> 
> -- 
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
> 
> 

Re: CORS redirect behavior proposal

[Anne van Kesteren]

On Tue, 22 Sep 2009 20:38:46 +0200, Collin Jackson  
 wrote:

Proposal

Same-origin redirects are allowed. Redirects from same-origin to
cross-origin are also allowed. When processing a redirect from one
foreign origin to another, the browser replaces the Origin header with
"null". In this situation, the browser appends a Sec-Redirect-Chain
header that allows sophisticated sites to see the list of origins that
contributed to this request.


I don't think this works well with the preflight result cache. For more  
thoughts on that see this email:


  http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1000.html


I agree that it would be good to merge Origin and Sec-From. I've been  
thinking about a simplification of CORS that would make this possible  
while avoiding the complexity you run into with the preflight result cache.


My proposal is to make redirects not work for cross-origin requests with a  
preflight. That is, only make them work for simple cross-origin requests.  
For cross-origin requests with a preflight the redirect status codes would  
be the equivalent of a network error so we can in the future make changes  
there.


This would allow us to use CORS for the EventSource object (which uses the  
equivalent of a simple request). It would also make it possible to use it  
for . Basically if the resource sharing check is successful we could  
add a flag to the  so that it does not taint the  allowing  
you to use images from a different server on the  element while  
keeping the ability to export image data.


For the scenarios where XMLHttpRequest is involved redirects would not  
work for now. Maybe something to address in CORS v2 or maybe it turns out  
it is not really needed.


For simple cross-origin requests Origin would be a space-separated list of  
origins indicating the redirect chain. What order would be best there?


This is more or less on what I'm planning to go with (will wait a day or  
so with specifying to allow for feedback) unless someone has a better idea  
that keeps things relatively simple and works with the preflight result  
cache.


Kind regards,


--
Anne van Kesteren
http://annevankesteren.nl/

[widgets] Draft Agenda for 24 September 2009 Voice Conf

[Arthur Barstow]

Below is the draft agenda for the September 24 Widgets Voice  
Conference (VC).


Inputs and discussion before the VC on all of the agenda topics via  
public-webapps is encouraged).


Please address Open/Raised Issues and Open Actions before the meeting:

  http://www.w3.org/2008/webapps/track/products/8

Minutes from the last VC:

  http://www.w3.org/2009/09/17-wam-minutes.html

-Regards, Art Barstow

Logistics:

Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London;  
09:00 Boston; 06:00 Seattle

Duration = 90 minutes
Zakim Bridge = +1.617.761.6200, +33.4.89.06.34.99 or  
+44.117.370.6152

PIN = 9231 ("WAF1");
IRC channel = #wam; irc://irc.w3.org:6665
Confidentiality of minutes = Public

Regrets: Marcos, Marcin, Josh

Agenda:

1. Review and tweak agenda

2. Announcements

a. News/summary from the Widget Testing event
  http://www.w3.org/2008/webapps/wiki/TestWorkshop2009

3. Widget Interface spec: proposal to publish LCWD #2

 

4. Access Requests Policy (WARP) spec: comment period ended Sept 20;  
review comments


 
 


5. URI Scheme spec: status of LC publication

 

6. View Modes Media Features spec: proposal to publish FPWD

 

7. View Modes Interfaces spec: Arve (from IRC) "the bit that troubles  
me is rotation"


 

8. AOB

[selectors-api] Summary of Feature Requests for v2

[Lachlan Hunt]

Hi,
  I'm planning to look at beginning work on Selectors API v2 soon to 
add a number of requested features that didn't make it into the first 
version.  This e-mail is a summary of what is being considered, and is 
intended to start discussion about which ones are really worth focussing 
on, and how to ensure they address the use cases appropriately.



*Matches Selector*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865

The suggestion is for being able to check if a given element matches a 
given selector.  There is already similar functionality provided by 
JQuery and Mozilla have begun working on an implementation for it in 
Firefox.


For the basic case, this is fairly trivial.  The method just needs to 
take a selector and evaluate it against the element, and return true or 
false.


But considering the proposed :scope pseudo-class that has been 
previously discussed here and in the CSS WG, it might also be nice to 
check if the element matches the selector in relation to a specified 
reference element.


For example, given 2 elements, div1 and div2, you could check if div2 is 
a sibling of div1 like this:


div2.matchesSelector(":scope~div", div1);

In this case, the div1 would be the reference element that is matched by 
:scope.  But we still need to determine how useful such functionality 
would be, and whether it's worth pursuing it in this next version.



*Filtering NodeLists*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864

The suggestion is for being able to take a NodeList, and filter the 
nodes to obtain a collection of just those that match a given selector.


For example, being able to get a NodeList somehow, do something with it, 
and then filter it more to work with just a subset:


e.g.
var list = document.querySelctor("div>p");
// Do something with list, before obtaining the subset
subset = list.filterSelector(".foo");
...

We need to find and document the possible use cases for this feature.


*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860

This has been discussed extensively in the past.  Basically, the idea is 
that the selector would be evaluated in the scope of the element, in a 
way more compatible with how libraries like JQuery work.  This slightly 
different from the :scope pseudo-class proposal, see bug for details.



*Collective Queries on NodeLists*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707

The suggestion is to be able to run querySelector() and 
querySelectorAll() on NodeList, and have the result be the union of 
results in document order from running the method on each Element in the 
NodeList.


e.g.

list.querySelectorAll("p");

Would be somewhat equivalent to running list[i].querySelectorAll("p"); 
for  on each element in the list, and then building an array with the 
union of distinct elements from all the results.  I've been told that 
similar functionality for this already exists in JQuery.


I believe the expectation is that both NodeList.querySelector() and 
.querySelectorAll() would work.  The difference is that querySelector() 
on a NodeList would return a NodeList (unlike on Element which just 
returns a single element) containing the first matches from each node in 
the list. i.e. equivalent to running list[i].querySelector() on each 
node and then combining all results into an array.


It also seems sensible to allow the new scoped methods to be used in an 
analogous way on NodeLists.



*Namespace Prefix Resolution*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290

The most controversial issue of the lot.  Need to clearly document the 
use cases and evaluate the problems being solved, and determine if it's 
really worth addressing in this version.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

skipping and ignoring

[Robin Berjon]

Hi,

while writing tests, we've hit upon something that could use a little  
clarification: the distinction between skip and ignore.


One interpretation that we can come to is that the two terms means the  
same thing for files and attributes, but for XML element processing  
"ignore" descends into the content whereas "skip" just moves on to the  
next. This is consistent for instance with the specification  
indicating that element content inside  has to be ignored. It  
is, however, not consistent with its application to  or  
 examples whereby those that don't match the locale are said to  
be ignored (logically it would be skipped — even though descending  
into the subtree would likely do nothing).


Another interpretation is that when something is ignored the UA must  
act as if it hadn't even been there in the first place, whereas when  
skipping it ought to not process it but remember it has seen it. This  
interpretation is built on the fact that the definitions say that  
ignore causes the UA to "act as if [what is being ignored] is not  
present" whereas skip is to "proceed to the next element".


It becomes less astract if you look at the following conformance  
statements.


In "10.1.19 Algorithm to Process a Configuration Document", step 11,  
part "A content element", the following normative assertion is made:  
"If this is not the first content element encountered by the user  
agent, then the user agent must skip this element." A few lines later  
it is followed by "If the src attribute of the content element is  
absent, then the user agent must skip this element."


Take the following configuration:

  
  

You see the first. It doesn't have an @src so you skip it. You reach  
the second. It's perfectly serviceable, but it's not the first. Or is  
it? If you consider the first one to have been ignored, then you have  
to act as if it wasn't there. But instead of ignored it says skipped —  
and it's not clear whether skipped has the same meaning.


If the second element is not taken into account, then we have a  
potential problem with forward compatibility. Let's imagine that we  
have v2 out, for which the following is correct:


  
  

Clearly the desired behaviour is for v2 runtimes to process the first,  
and v1 runtimes to fallback to the second.


The same issue applies to other elements that refer to the skip/ignore  
distinction. We believe that some editorial improvements to those  
definitions would be welcome.


--
Robin Berjon - http://berjon.com/

Re: [widgets] Comments on Section 5 of the 18-Aug-2009 LCWD of A&E spec

[Marcos Caceres]

2009/9/21 Arthur Barstow :
> Hi Marcos,
>
> On Sep 21, 2009, at 2:08 PM, ext Marcos Caceres wrote:
>
>> For the sake of the DoC, can you please acknowledge that the comments
>> below have been addressed and your are satisfied with the way the WG
>> addressed your comments.
>
> Based on the exchanges we had regarding the 3 sets of comments I submitted 
> ([1][2][3]) against the 18-Aug-2009 LCWD of the Widgets A&E spec, I am 
> satisfied with the way those comments were addressed.
>
> Note that since we agreed to publish a new LCWD of that spec, I don't think 
> it is necessary for the WG to complete a DoC doc for the 18-Aug version.
>

Ok, but I am going to going to gather responses regardless because the
Process requires us to prove wide review. With P&C we were fortunate
to get wide review on the second LC, but I fear that we won't get a
lot of comments in the second LC of the Widget Interface spec.

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au

CORS redirect behavior proposal

[Collin Jackson]

Looking at the behavior of existing implementations, we don't seem to
have committed to how to handle redirects in CORS yet:

IE8 (XDomainRequest): Redirects are not supported

Firefox 3.5: If you start off same-origin, you can redirect
cross-origin once, and the Origin header gets added at that point.
Once you're making cross-origin requests, however, further redirects
are not allowed.

Safari 4 and Chrome 3: If you start off same-origin, cross-origin
redirects are blocked. If you start off cross-origin, you can redirect
on that origin, but you can't go to yet another origin. However, this
redirect behavior only works with synchronous requests; if you're
making an asynchronous request you can't do any redirects.

In summary, CORS redirects have not yet been implemented, except for
synchronous requests in Safari and Chrome. Furthermore, the Safari and
Chrome implementation doesn't yet handle the case where one foreign
origin redirects to another. We still have some choice as to what
behavior to specify in this case.

Goals

The first order of business is to make sure that the specification
fixes the DELETE request security issue that Tyler Close pointed out.
Additionally, it would be nice for the Origin header to be usable as a
CSRF defense (eliminating the need for a separate Sec-From header).

Proposal

Same-origin redirects are allowed. Redirects from same-origin to
cross-origin are also allowed. When processing a redirect from one
foreign origin to another, the browser replaces the Origin header with
"null". In this situation, the browser appends a Sec-Redirect-Chain
header that allows sophisticated sites to see the list of origins that
contributed to this request.

Example 1: Suppose a site1.com web page makes an XMLHttpRequest to
site2.com, which is redirected to site3.com. The requests to site2.com
has a site1.com Origin header, but the request to site3.com has an
Origin header of "null". When making a request to site3.com, the
browser adds a Sec-Redirect-Chain header of "http://site1.com,
http://site2.com";.

Example 2: Suppose a site1.com web page makes an XMLHttpRequest to
site1.com, which is redirected to site2.com, which is redirected to
site3.com. The requests to site1.com and site2.com have a site1.com
Origin header, but the request to site3.com has an Origin header of
"null". When making a request to site3.com, the browser adds a
Sec-Redirect-Chain header of "http://site1.com, http://site2.com";.

Discussion

This proposal defends against the DELETE attack that Tyler pointed
out: Suppose a goodsite.com web page makes a DELETE request to
attacker.com, which is redirected to victim.com. Previously, the
request to victim.com would carry the goodsite.com origin, potentially
confusing the victim site into deleting something. Under this
proposal, the Origin header would be null, so the victim site would
not be confused.

To defend itself against CSRF, a simple site just needs to make sure
the Origin header contains a whitelisted value. A sophisticated site
that uses redirects can look at the Sec-Redirect-Chain and ensure that
it trusts all the origins in the list.

The Sec-Redirect-Chain header is a tradeoff between complexity and
supporting more use cases. If we feel that the Sec-Redirect-Chain
header is too complicated, it could be dropped from this proposal.