date:20111124

On Thu, Nov 24, 2011 at 3:19 PM, Sean Hogan  wrote:
> This has been raised before, but I'll restate it here.
>
> How should the selector be expanded in
>     elt.findAll("div span, div :scope span")?
>
> The straight-forward interpretation of "implies :scope unless it is
> explicit" is to not expand this, thus:
>     "div span, div :scope span"
>
> But with that interpretation
>     elt.findAll("> div span, div :scope span")
> will throw an error, although
>     elt.findAll("> div span"); elt.findAll("div :scope span");
> is allowed.
>
> If this isn't to throw an error then a more complex definition is required
> which can apply a different rule for implying :scope in different parts of
> the selector argument. This is sure to be confusing for anyone reading the
> code.

You don't need a complex definition.  The rule applies per selector
(to be precise, per "complex selector", using current terminology.
Your example shows a comma-separated *list* of selectors.  Thus,
:scope is prepended to the first selector, and not to the second
selector.

However, this is irrelevant for matches().  It doesn't need to, and
shouldn't, imply :scope.

~TJ

Re: Remaining Problems with Explicit :scope Switching in find/findAll (was: Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?)

On Thu, Nov 24, 2011 at 10:53 AM, Yehuda Katz  wrote:
>> > * Is :scope always implied if it begins with an explicit combinator
>> > other
>> > than descendant, even if :scope is used elsewhere?
>> >  find(">div :scope");
>> >  find("+div :scope");
>> >  find("~div :scope");
>>
>> Yes.
>
> I think I would be ok with this case throwing, because all of the cases are
> nonsense queries.

*Those* cases are nonsense.  Use the reference combinator, though, and
it suddenly becomes possibly reasonable.

Alternately, assume that :matches() is eventually changed to allow
complex selectors.  Using :scope there is completely fine.

Rather than trying to carve out some ways that are okay and other ways
that throw, I think it's better to just use the simplest possible
rule: prepend :scope to them and evaluate them as normal.  The
selectors above just won't match anything, is all.

~TJ

Re: [Component Model] Decorator Challenges

2011-11-24 Thread Roland Steiner

On Wed, Nov 23, 2011 at 08:05, Dimitri Glazkov wrote:

> Even if we attempt to separate the state of a decorator from the
> element and its document using an iframe- or worker-like machinery,
> we’ll still have similar issues of managing decorator instances that
> are no longer relevant, but don’t know that yet -- in addition to the
> performance costs of such high-isolation approach.
>

I don't quite follow what you mean with the above - could you go into more
detail on this point? E.g., why would it be a problem if a worker-like
decorator that got detached sits around for a little while longer, doing
last timeouts and other stuff that no longer really matters?

(FWIW, I'm also not convinced that it'd have to have high performance
overhead - in the best case it could be as little as just one more level of
indirection.)

Cheers,

- Roland

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

2011-11-24 Thread Boris Zbarsky


On 11/24/11 7:07 PM, Sean Hogan wrote:

If and when there is a need for a matching method that does imply :scope
(which I provided a use-case for in
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html)


That's a use case passing in an explicit reference node.  If you're 
doing that, then it seems like using an explicit :scope in the selector 
would be just fine.  But I'll accept that in some sort of edge cases you 
can't do that.



then it could be called matches().


That seems backwards: "does this node match this selector?" is the 
common use case, so should have the shorter name, no?


-Boris

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

2011-11-24 Thread Sean Hogan


On 24/11/11 7:46 PM, Lachlan Hunt wrote:

On 2011-11-23 23:38, Sean Hogan wrote:

Are there any issues with:

- If you want to use selectors with explicit :scope then you use
querySelector / querySelectorAll / matchesSelector.

- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most js libs currently do) then you
use find / findAll / matches.


The matches method will not change behaviour depending on whether or 
not there is an explicit :scope because it is always evaluated in the 
context of the entire tree.  There is never an implied :scope inserted 
into the selector, so there will not be two alternative matches methods.




A matching method that doesn't imply :scope should be called 
matchesSelector().


If and when there is a need for a matching method that does imply :scope 
(which I provided a use-case for in 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) 
then it could be called matches().


I should be able to define querySelectorAll() in terms of 
matchesSelector(),

and findAll() in terms of matches().

Thus:

function querySelectorAll(selector) {
var refNode = this;
return [].filter.call(refNode.getElementsByTagName("*"),
function(elt) { return elt.matchesSelector(selector, refNode); });
}

function findAll(selector) {
var refNode = this, list = [];
for (var node=refNode; node; node=node.nextSibling) {
if (node.nodeType != 1) continue;
if (node != refNode && node.matches(selector, refNode)) 
list.push(node);

[].push.apply(list, [].filter.call(node.getElementsByTagName("*"),
function(elt) { return elt.matches(selector, refNode); });
}
return list;
}

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

2011-11-24 Thread Sean Hogan


On 24/11/11 10:52 AM, Yehuda Katz wrote:


Yehuda Katz
(ph) 718.877.1325


On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan > wrote:


On 23/11/11 12:17 AM, Boris Zbarsky wrote:

On 11/22/11 6:50 AM, Lachlan Hunt wrote:

Last time we had this discussion, you had a desire to keep
the name
prefixed until the refNodes and :scope stuff was
implemented [1]. What's
the status on that now?


The status is that I've given up on the :scope discussion
reaching a conclusion in finite time (esp. because it sounds
like people would like to change what it means depending on
the name of the function being called) and would be quite
happy to ship an implementation that only takes one argument.
 Web pages can use .length on the function to detect support
for the two-argument version if that ever happens.


Are there any issues with:

- If you want to use selectors with explicit :scope then you use
querySelector / querySelectorAll / matchesSelector.

- If you want to use selectors with :scope implied at the start of
each selector in the selector list (as most js libs currently do)
then you use find / findAll / matches.


The alternative option (find / findAll / matches can accept
explicit :scope, but will otherwise imply :scope) seems to be
where all the ambiguity lies.


What exact cases are ambiguous with "find/findAll/matches can accept 
explicit :scope, but will otherwise imply :scope"?





This has been raised before, but I'll restate it here.

How should the selector be expanded in
elt.findAll("div span, div :scope span")?

The straight-forward interpretation of "implies :scope unless it is 
explicit" is to not expand this, thus:

"div span, div :scope span"

But with that interpretation
elt.findAll("> div span, div :scope span")
will throw an error, although
elt.findAll("> div span"); elt.findAll("div :scope span");
is allowed.

If this isn't to throw an error then a more complex definition is 
required which can apply a different rule for implying :scope in 
different parts of the selector argument. This is sure to be confusing 
for anyone reading the code.


OTOH, if find / findAll  always implies :scope there isn't this problem. 
Moreover, that is what people will expect if they are used to jQuery's 
find() and equivalents in other JS libs.


This makes for a fairly straight-forward explanation of usage:

- If you want to use selectors with explicit :scope then you use 
querySelector / querySelectorAll / matchesSelector.


- If you want to use selectors with :scope implied at the start of each 
selector in the selector list (as most js libs currently do) then you 
use find / findAll / matches.

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

2011-11-24 Thread Yehuda Katz

Yehuda Katz
(ph) 718.877.1325


On Thu, Nov 24, 2011 at 9:47 AM, Boris Zbarsky  wrote:

> On 11/23/11 5:38 PM, Sean Hogan wrote:
>
>> - If you want to use selectors with :scope implied at the start of each
>> selector in the selector list (as most js libs currently do) then you
>> use find / findAll / matches.
>>
>
> I'm not sure that for matches() the :scope thing is all that relevant.
> :matches() just returns a boolean for whether the |this| it's invoked on
> matches the selector.  The only reason one would ever use :scope in there
> at all is if one provides an explicit list of reference nodes, right?  In
> particular, the assumption is that the selector passed in would obviously
> be allowed to match ancestor nodes of |this| for parts of it, since
> otherwise there is no point, right?  No one would expect
>
>  foo.matches("div *");
>
> to always return false; you would expect it to return true if |foo| has an
> _ancestor_ matching "div".
>
> Similarly, no one would expect this:
>
>  foo.matchs(" > div");
>
> to do much of anything, I would think.  Or am I wrong on that?
>

To my ignorant eyes, you seem correct.


>
> Am I just missing something here?
>
> -Boris
>
>

Re: Dropping XMLHttpRequest 1 (just do 2)?

2011-11-24 Thread Yehuda Katz

Awesome. I wonder if there's any utility to linking to the exact thread
where the merge was agreed to?

Yehuda Katz
(ph) 718.877.1325


On Thu, Nov 24, 2011 at 3:13 AM, Anne van Kesteren  wrote:

> On Thu, 24 Nov 2011 02:39:33 +0100, Yehuda Katz  wrote:
>
>> Sounds good to me. I agree that it would be good to have a sentence
>> somewhere explaining the history.
>>
>
> I just wrote this:
>
> http://dvcs.w3.org/hg/xhr/raw-**file/tip/Overview.html#**
> specification-history
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: Remaining Problems with Explicit :scope Switching in find/findAll (was: Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?)

2011-11-24 Thread Yehuda Katz

Yehuda Katz
(ph) 718.877.1325


On Thu, Nov 24, 2011 at 6:52 AM, Tab Atkins Jr. wrote:

> On Thu, Nov 24, 2011 at 12:50 AM, Lachlan Hunt 
> wrote:
> > On 2011-11-24 00:52, Yehuda Katz wrote:
> >>
> >> On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan
> >>  wrote:
> >>>
> >>> The alternative option (find / findAll / matches can accept explicit
> >>> :scope, but will otherwise imply :scope) seems to be where all the
> >>> ambiguity lies.
> >>
> >> What exact cases are ambiguous with "find/findAll/matches can accept
> >> explicit :scope, but will otherwise imply :scope"?
> >
> > The problems to be solved with automatically switching between implied
> and
> > explicit :scope are basically in determining what exactly counts as an
> > explicit :scope.  The answers to each of these has is trade off between
> > complexity and functionality, with the simplest option being always
> implying
> > :scope.
> >
> > * Is explicit :scope allowed at the beginning of each selector?
> >
> >  find(":scope>div");
> >  find("body.foo :scope>div");
>
> Anywhere within the selector.
>

Agreed.


>
>
> > * Does :scope inside functional pseudo-classes count?
> >
> >  find(":not(:scope)");
> >  find(":matches(:scope)");
> >
> > If yes, does the first match the whole document, only descendants, or
> > descendants plus siblings?
>
> Yes, I believe so.  The first matches the whole document except for
> the scoping element.  The second matches only the scoping element.
>

Agreed.


>
>
> > * If using an explicit :scope, can it match itself?
> >
> >  find(":scope") // Return null or the element itself?
>
> Yes, because selectors with an explicit scope are evaluated against
> the whole document.  (Selectors with an implicit scope are too,
> theoretically, though implementations can optimize.)  That example
> returns the element itself.
>

Agreed. This returns the element itself.


>
>
> > * Is :scope always implied if it begins with an explicit combinator other
> > than descendant, even if :scope is used elsewhere?
> >  find(">div :scope");
> >  find("+div :scope");
> >  find("~div :scope");
>
> Yes.
>

I think I would be ok with this case throwing, because all of the cases are
nonsense queries.


> > * There's also the general issue, not related to :scope, about how the
> > reference combinator affects the range of potential matches.
> >  label.find("/for/ input")
> >
> > Based on the above issues, what happens in this case?
> >
> >  foo.find(">label /for/ input+:scope~span)
>
> This is equivalent to prepending ":scope" to the selector, and
> evaluating it against the whole document.  In other words, it finds a
> span that is preceded by the scope which is immediately preceded by an
> input which is referenced by a label which is a child of the scope.
>
> So, the rules end up being very simple.  find always evaluates against
> the whole document.  If one of the selectors starts with a combinator
> or doesn't contain a ":scope" pseudoclass somewhere in it, ":scope" is
> prepended to it.  That's it.  With this, we make the most common cases
> (searching descendants/siblings) easy, while making the global case
> *also* easy.  There's a bit of intent-guessing when :scope is used in
> an indirect way, but I believe it's better to err on the side of
> simplicity and consistency there.
>

I am ok with this, but I am also ok with "find always evaluates against the
whole document.  If one of the selectors doesn't contain a ":scope"
pseudoclass somewhere in it, ":scope" is prepended to it."

I also thing we agreed that filtering selectors, in the case of implicit
scope, are applied on the :scope, not as a descendent of the :scope.

As I said above, since the cases of starting with a combinator are nonsense
queries (correct me if I'm missing something obvious), we can simplify the
rules even more and eliminate the case of "starting with a combinator *and*
has a :scope"


>
> ~TJ
>

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

2011-11-24 Thread Boris Zbarsky


On 11/23/11 5:38 PM, Sean Hogan wrote:

- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most js libs currently do) then you
use find / findAll / matches.


I'm not sure that for matches() the :scope thing is all that relevant. 
:matches() just returns a boolean for whether the |this| it's invoked on 
matches the selector.  The only reason one would ever use :scope in 
there at all is if one provides an explicit list of reference nodes, 
right?  In particular, the assumption is that the selector passed in 
would obviously be allowed to match ancestor nodes of |this| for parts 
of it, since otherwise there is no point, right?  No one would expect


  foo.matches("div *");

to always return false; you would expect it to return true if |foo| has 
an _ancestor_ matching "div".


Similarly, no one would expect this:

  foo.matchs(" > div");

to do much of anything, I would think.  Or am I wrong on that?

Am I just missing something here?

-Boris

Re: [XHR2] HTML in XHR implementation feedback

2011-11-24 Thread Anne van Kesteren


On Wed, 16 Nov 2011 11:40:08 +0100, Henri Sivonen  wrote:

[...]


In response to this thread and an earlier thread where sicking suggested  
"text" handling should be simpler, I have made these changes:


* Never use text/html handling for text decoding
  http://dvcs.w3.org/hg/xhr/rev/47d46d5c3845

* Limit XML text decoding to responseType being the empty string
  http://dvcs.w3.org/hg/xhr/rev/02b3d18a4907

* Restrict text/html document handling to responseType being "document"
  http://dvcs.w3.org/hg/xhr/rev/236face6f073


Once http://www.w3.org/Bugs/Public/show_bug.cgi?id=14284 is fixed I will  
update the document handling to make the specific requirements on the HTML  
parser Henri suggested.



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

Re: XPath and find/findAll methods

2011-11-24 Thread Julian Reschke


On 2011-11-24 16:12, Robin Berjon wrote:

On Nov 24, 2011, at 15:34 , Julian Reschke wrote:

So I believe it would be good if the yet-to-be-written spec would allow 
implementations to use an XPath2 engine that runs in compat mode.


Good as in there are use cases for it, or good just because? It seems to me 
that adding XPath 2.0 support is a non-negligible addition, and I have yet to 
hear about anyone being remotely interested in implementing it. So while 
attacking the low-hanging fruit of what we can get to work right today seems 
appealing to me, looking beyond that is IMHO not necessary.


Well, the use case is to allow browsers to move to XPath2/XSLT2 at some 
point in the future, without having to maintain another engine.


Best regards, Julian

Re: XPath and find/findAll methods

On Nov 24, 2011, at 15:34 , Julian Reschke wrote:
> So I believe it would be good if the yet-to-be-written spec would allow 
> implementations to use an XPath2 engine that runs in compat mode.

Good as in there are use cases for it, or good just because? It seems to me 
that adding XPath 2.0 support is a non-negligible addition, and I have yet to 
hear about anyone being remotely interested in implementing it. So while 
attacking the low-hanging fruit of what we can get to work right today seems 
appealing to me, looking beyond that is IMHO not necessary.

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

Re: XPath and find/findAll methods

2011-11-24 Thread Phil Booth

On 23 November 2011 18:23, Tab Atkins Jr.  wrote:

> have lying around everywhere.  Right now, authors in general have zero
> awareness of XPath, so recognizing it would be effectively "adding"
> it.
>

Not sure how much my opinion is worth in all this but, as a developer that
has non-zero awareness of XPath, I just wanted to chime in at this point.

It depends on your definition of "in general" of course, but the following
could be construed as evidence to the contrary (there are some false
positives in here, I realise):

http://stackoverflow.com/questions/183369/cross-browser-xpath-implementation-in-javascript
http://stackoverflow.com/search?q=xpath+javascript
http://www.google.com/codesearch#search/&q=preceding-sibling%20lang
:^javascript$%20case:yes&type=cs
http://www.google.com/codesearch#search/&q=descendant-or-self%20lang
:^javascript$%20case:yes&type=cs
http://goog-ajaxslt.sourceforge.net/
http://www.google.com/codesearch#search/&q=ajaxslt.*\.js
http://www.google.com/codesearch#search/&q=xpath.*\.js
http://chris-nielsen.blogspot.com/2009/12/xpath-axis-selectors-implemented-in.html
http://mcc.id.au/xpathjs
http://www.dashop.de/blog/en/dev/JavaScript/content/XPath/JavaScript-XPath-Implementation.html
http://www.codestore.net/store.nsf/unid/BLOG-20050420
http://www.ahristov.com/tutorial/javascript-tips/Browser%2Bindependant%2BXPath%2Bevaluation.html
http://goessner.net/articles/JsonPath/
http://js-xpath.sourceforge.net/
http://www.w3schools.com/xpath/
https://developer.mozilla.org/en/Introduction_to_using_XPath_in_JavaScript
http://programmers.stackexchange.com/questions/117399/xpath-vs-dom-api

Re: [Widgets] CfC: add WidgetStorage interface to API spec; deadline December 1

2011-11-24 Thread Charles McCathieNevile


On Thu, 24 Nov 2011 15:42:08 +0100, Robin Berjon  wrote:


On Nov 24, 2011, at 15:36 , Arthur Barstow wrote:
Marcos asserted in followups to his proposal that this change would not  
affect any implementations nor applications. As such, the change  
request, if applied, will not require republication as a new (LC)WD.


+1


Me Too !1!


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

Re: Remaining Problems with Explicit :scope Switching in find/findAll (was: Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?)

On Thu, Nov 24, 2011 at 12:50 AM, Lachlan Hunt  wrote:
> On 2011-11-24 00:52, Yehuda Katz wrote:
>>
>> On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan
>>  wrote:
>>>
>>> The alternative option (find / findAll / matches can accept explicit
>>> :scope, but will otherwise imply :scope) seems to be where all the
>>> ambiguity lies.
>>
>> What exact cases are ambiguous with "find/findAll/matches can accept
>> explicit :scope, but will otherwise imply :scope"?
>
> The problems to be solved with automatically switching between implied and
> explicit :scope are basically in determining what exactly counts as an
> explicit :scope.  The answers to each of these has is trade off between
> complexity and functionality, with the simplest option being always implying
> :scope.
>
> * Is explicit :scope allowed at the beginning of each selector?
>
>  find(":scope>div");
>  find("body.foo :scope>div");

Anywhere within the selector.

> * Does :scope inside functional pseudo-classes count?
>
>  find(":not(:scope)");
>  find(":matches(:scope)");
>
> If yes, does the first match the whole document, only descendants, or
> descendants plus siblings?

Yes, I believe so.  The first matches the whole document except for
the scoping element.  The second matches only the scoping element.

> * If using an explicit :scope, can it match itself?
>
>  find(":scope") // Return null or the element itself?

Yes, because selectors with an explicit scope are evaluated against
the whole document.  (Selectors with an implicit scope are too,
theoretically, though implementations can optimize.)  That example
returns the element itself.

> * Is :scope always implied if it begins with an explicit combinator other
> than descendant, even if :scope is used elsewhere?
>  find(">div :scope");
>  find("+div :scope");
>  find("~div :scope");

Yes.

> * There's also the general issue, not related to :scope, about how the
> reference combinator affects the range of potential matches.
>  label.find("/for/ input")
>
> Based on the above issues, what happens in this case?
>
>  foo.find(">label /for/ input+:scope~span)

This is equivalent to prepending ":scope" to the selector, and
evaluating it against the whole document.  In other words, it finds a
span that is preceded by the scope which is immediately preceded by an
input which is referenced by a label which is a child of the scope.

So, the rules end up being very simple.  find always evaluates against
the whole document.  If one of the selectors starts with a combinator
or doesn't contain a ":scope" pseudoclass somewhere in it, ":scope" is
prepended to it.  That's it.  With this, we make the most common cases
(searching descendants/siblings) easy, while making the global case
*also* easy.  There's a bit of intent-guessing when :scope is used in
an indirect way, but I believe it's better to err on the side of
simplicity and consistency there.

~TJ

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Thu, Nov 24, 2011 at 12:46 AM, Lachlan Hunt  wrote:
> On 2011-11-23 23:38, Sean Hogan wrote:
>>
>> Are there any issues with:
>>
>> - If you want to use selectors with explicit :scope then you use
>> querySelector / querySelectorAll / matchesSelector.
>>
>> - If you want to use selectors with :scope implied at the start of each
>> selector in the selector list (as most js libs currently do) then you
>> use find / findAll / matches.
>
> The matches method will not change behaviour depending on whether or not
> there is an explicit :scope because it is always evaluated in the context of
> the entire tree.  There is never an implied :scope inserted into the
> selector, so there will not be two alternative matches methods.

Agreed.  You will almost always want to evaluate matches against the
whole tree, and when you don't you can use an explicit scope.

~TJ

Re: [Widgets] CfC: add WidgetStorage interface to API spec; deadline December 1

On Nov 24, 2011, at 15:36 , Arthur Barstow wrote:
> Marcos asserted in followups to his proposal that this change would not 
> affect any implementations nor applications. As such, the change request, if 
> applied, will not require republication as a new (LC)WD.

+1

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

[Widgets] CfC: add WidgetStorage interface to API spec; deadline December 1

Below, Marcos proposed a change request to the Widget Interface spec and 
this is a Call for Consensus to accept this proposal and to update the 
spec accordingly.


Marcos asserted in followups to his proposal that this change would not 
affect any implementations nor applications. As such, the change 
request, if applied, will not require republication as a new (LC)WD.


Note this spec is currently in the LCWD phase and given there are 
already more than two implementations that pass 100% of the test suite, 
the only reason this spec is not already a Recommendation is because it 
is blocked by the W3C's dependency maturity rules (Web IDL, Web Storage 
in particular).


Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreeing with Marcos' proposal. The deadline for 
comments is December 1 and all comments should be sent to public-webapps 
at w3.org.


-AB

 Original Message 
Subject:[Widgets] WidgetStorage interface
Resent-Date:Mon, 21 Nov 2011 17:09:42 +
Resent-From:
Date:   Mon, 21 Nov 2011 18:08:56 +0100
From:   ext Marcos Caceres 
To: public-webapps 



Hi,
As part of LC, I've received quite a bit of offline feedback that because of 
some issue in Webkit, it's difficult for implementers to reuse the WebStorage 
interface in a widget context: the problem is that Widget's use of Web storage 
slightly modifies some of the behaviour of the storage methods (e.g., some 
things are read only and throw exceptions). The way around this is to define a 
WidgetStorage interface that allows for the specific behaviour defined in the 
Widget spec.

Consequently, I want to define this interface WidgetStorage in the spec:

WidgetStorage : Storage{}

And hence:

   readonly attribute Storage   preferences;

Becomes:
readonly attribute WidgetStorage  preferences;

In practice, the addition of WidgetStorage doesn't actually affect any 
conforming runtimes (but allows a bunch of new Webkit ones to comply).

Kind regards,
Marcos

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

Re: XPath and find/findAll methods

2011-11-24 Thread Julian Reschke


On 2011-11-24 14:57, Henri Sivonen wrote:

On Wed, Nov 23, 2011 at 11:05 PM, Julian Reschke  wrote:

could you elaborate on what you mean by "no smooth evolutionary path to
XPath 2.x"? (Are you referring to specs or to implementations?)


Specs. XPath 2.0 changed XPath in an incompatible way. There's a
"compatibility mode" for interpreting existing XPath 1.0 queries, but
it seems like a bad idea to build on a spec whose authors have put
compatibility into a side mode and what's considered the main thing
isn't fully compatible with existing queries.


OK,

so this is about .

 is the list of 
changes when XPath2 runs in compat mode, without additional schema 
information. That lists really looks harmless to me, many of the points 
are about making parsing more strict.


So I believe it would be good if the yet-to-be-written spec would allow 
implementations to use an XPath2 engine that runs in compat mode.


Best regards, Julian

Re: XPath and find/findAll methods

On Nov 24, 2011, at 14:59 , Henri Sivonen wrote:
> On Thu, Nov 24, 2011 at 3:49 PM, Robin Berjon  wrote:
 Node.prototype.queryXPath = function (xpath) {
> 
>> So, now for the money question: should we charter this?
> 
> Since IE and Opera already have a solution, it seems to me that unless
> that solution has bad flaws, it would make more sense to spec what
> they already support instead inventing a new API.

Yeah, that's fine by me — I didn't mean chartering the solution but rather the 
work, naturally. Given that those two solutions are different, we'll need 
something that merges them somehow. Opera's approach is pretty close to the one 
outlined above anyway.

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

Re: XPath and find/findAll methods

2011-11-24 Thread Henri Sivonen

On Thu, Nov 24, 2011 at 3:49 PM, Robin Berjon  wrote:
>> > Node.prototype.queryXPath = function (xpath) {

> So, now for the money question: should we charter this?

Since IE and Opera already have a solution, it seems to me that unless
that solution has bad flaws, it would make more sense to spec what
they already support instead inventing a new API.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: XPath and find/findAll methods

2011-11-24 Thread Henri Sivonen

On Wed, Nov 23, 2011 at 11:05 PM, Julian Reschke  wrote:
> could you elaborate on what you mean by "no smooth evolutionary path to
> XPath 2.x"? (Are you referring to specs or to implementations?)

Specs. XPath 2.0 changed XPath in an incompatible way. There's a
"compatibility mode" for interpreting existing XPath 1.0 queries, but
it seems like a bad idea to build on a spec whose authors have put
compatibility into a side mode and what's considered the main thing
isn't fully compatible with existing queries.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: XPath and find/findAll methods

On Nov 23, 2011, at 17:45 , Jonas Sicking wrote:
> On Wednesday, November 23, 2011, Robin Berjon  wrote:
> > I would be thinking about something along the lines of (untested, off the 
> > top of my head):
> >
> > Node.prototype.queryXPath = function (xpath) {
> >var snap = this.ownerDocument
> >   .evaluate(xpath,
> > this,
> > function () { return 
> > "http://www.w3.org/1999/xhtml";; },
> > XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
> > null);
> >var ret = [];
> >for (var i = 0; i < snap.snapshotLength; i++) 
> > ret.push(snap.snapshotItem(i));
> >return ret;
> > };
> >
> > Which hardly strikes me as a terribly complex addition.
> 
> I like this approach. Though I would make the type ANY and return whatever 
> type the expression produced.

I agree that in general ANY_TYPE is desirable so that we can get non-node 
results, the problem is that for node sets it defaults (for reasons that defy 
any understanding that I have) to UNORDERED_NODE_ITERATOR_TYPE — when we 
clearly want something ordered and a snapshot. But specifying around that is 
not a big deal.

So, now for the money question: should we charter this?

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

Re: PointerLock and Gamepad APIs

On 11/24/11 8:11 AM, ext João Eiras wrote:
On Thu, 24 Nov 2011 09:04:19 +0100, Darin Fisher
wrote:

Back in September, it was proposed to expand the charter of the
WebEvents

WG to include PointerLock (formerly known as MouseLock) and Gamepad APIs
[1]. This seemed like a logical home for them given that both of these
APIs pertain to input event systems.

However, one thing that became apparent was that Apple was not
willing to

join the WebEvents WG [2]. Since we, the Chrome team at Google, work on
WebKit alongside Apple engineers, it is a bit undesirable for us to
not be
able to work together with Apple in the WGs, which develop the specs
that
we implement in WebKit. From an efficiency point of view, it is far
easier

if we can discuss APIs in a single forum instead of having to relay
concerns between forums.

I'd like to therefore propose that instead of expanding the charter of
WebEvents to include PointerLock and Gamepad, that we instead add those
APIs to another WG such as WebApps. I believe they make sense in
WebApps

given the scope of work being done there and the parties involved.

Both are clearly related to events and pointing devices, so if this
group was created, it makes sense for it to continue working on such
specifications.

If those new specs should go into the WebApps group, then there is
little point in keeping this group, and move what has been done so far
also into WebApps.

The last part (starting with the ",") of Darin's P.S. comment isn't
accurate:

[[
[2] Recently, Apple disclosed some patents for the Touch Events
specification
[http://lists.w3.org/Archives/Public/public-webevents/2011OctDec/0118.html],
which is currently the only deliverable for the WebEvents WG.

]]

Besides the Touch Events spec, the Web Events WG's charter also includes
in its scope a "high-level representational events" spec. No explicit
work has yet started on the later spec, mainly because we expected to
collaborate with the PFWG on it and other priorities "won". However, the
latest proposal is that this intentional event spec (now referred to as
"Indie UI: Events 1.0") will be a joint deliverable between Web Events
and the proposed "Indie UI" WG [IndieUI] and not PFWG, and that Apple's
[UII4ARIA] spec will be the initial contribution for the spec.

-AB

[IndieUI] http://www.w3.org/2011/11/indie-ui-charter
[UII4ARIA]
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html

CfC: Add PointerLock and Gamepad APIs to WebApps' charter; deadline December 1

Below, Darin proposes the Pointer Lock [PL] (formerly known as Mouse 
Lock) spec and the Gamepad [GP] spec be added to the Web Applications 
WG's charter and not the Web Events WG's charter. This is a Call for 
Consensus to accept that proposal.


Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreeing with the proposal. The deadline for 
comments is December 1 and all comments should be sent to public-webapps 
at w3.org.


-AB

[PL] http://dvcs.w3.org/hg/webevents/raw-file/default/mouse-lock.html
[GP] http://dvcs.w3.org/hg/webevents/raw-file/tip/gamepad.html

 Original Message 
Subject:PointerLock and Gamepad APIs
Date:   Thu, 24 Nov 2011 00:04:19 -0800
From:   ext Darin Fisher 
To: 	, Web Applications Working Group WG 
, Arthur Barstow 




Back in September, it was proposed to expand the charter of the 
WebEvents WG to include PointerLock (formerly known as MouseLock) and 
Gamepad APIs [1].  This seemed like a logical home for them given that 
both of these APIs pertain to input event systems.


However, one thing that became apparent was that Apple was not willing 
to join the WebEvents WG [2].  Since we, the Chrome team at Google, work 
on WebKit alongside Apple engineers, it is a bit undesirable for us to 
not be able to work together with Apple in the WGs, which develop the 
specs that we implement in WebKit.  From an efficiency point of view, it 
is far easier if we can discuss APIs in a single forum instead of having 
to relay concerns between forums.


I'd like to therefore propose that instead of expanding the charter of 
WebEvents to include PointerLock and Gamepad, that we instead add those 
APIs to another WG such as WebApps.  I believe they make sense in 
WebApps given the scope of work being done there and the parties involved.


Thoughts?
-Darin

[1] 
http://lists.w3.org/Archives/Public/public-webevents/2011JulSep/0087.html


[2] Recently, Apple disclosed some patents for the Touch Events 
specification 
[http://lists.w3.org/Archives/Public/public-webevents/2011OctDec/0118.html], 
which is currently the only deliverable for the WebEvents WG.

Re: [XHR2] HTML in XHR implementation feedback

2011-11-24 Thread Henri Sivonen

On Mon, Nov 21, 2011 at 8:26 PM, Jonas Sicking  wrote:
> On Wed, Nov 16, 2011 at 2:40 AM, Henri Sivonen  wrote:
>>  * For text/html responses for response type "" and "document", the
>> character encoding is established by taking the first match from this
>> list in this order:
>>   - HTTP charset parameter
>>   - BOM
>>   - HTML-compliant  prescan up to 1024 bytes.
>>   - UTF-8
>
> I still think that we are putting large parts of the world at a
> significant disadvantage here since they would not be able to use this
> feature together with existing content, which I would imagine is a
> large argument for this feature at all.
>
> Here is what I propose. How about we add a .defaultCharset property.
> When not set we use the list as described above. If set, the contents
> of .defaultCharset is used in place of UTF8.

I think that makes sense as a solution if it turns out that a solution
is needed. I think adding that feature now would be a premature
addition of complexity--especially considering that responseText has
existed for this long with a UTF-8 default without a .defaultCharset
property.

>>  * When there is no HTTP-level charset parameter, progress events are
>> stalled and responseText made null until the parser has found a BOM or
>> a charset  or has seen 1024 bytes or the EOF without finding
>> either BOM or charset .
>
> Why? I wrote the gecko code specifically so that we can adjust
> .responseText once we know the document charset. Given that we're only
> scanning 1024 bytes, this shouldn't ever require more than 1024 bytes
> of extra memory (though the current implementation doesn't take
> advantage of that).

I meant that stalling stops at EOF if the file is shorter than 1024
bytes. However, this point will become moot, because supporting HTML
parsing per spec in the default mode broke Wolfram Alpha and caused
wasteful parsing on Gmail, so per IRC discussion with Anne and Olli,
I'm preparing to limit HTML parsing to responseType == "document"
only.

>>  * Making responseType == "" not support HTML parsing at all and to
>> treat text/html as an unknown type for the purpose of character
>> encoding.
>
> I don't understand what the part after the "and" means. But the part
> before it sounds quite interesting to me. It would also resolve any
> concerns about breaking existing content.

The part after "and" means the old behavior. This is now the plan.

On Mon, Nov 21, 2011 at 8:28 PM, Jonas Sicking  wrote:
>> The side effect is that  prescan doesn't happen in the
>> synchronous mode for text/html resources. This is displeasingly
>> inconsistent but makes sense if the sync mode is treated as an evil
>> legacy feature rather than as an evolving part of the platform.
>
> I'm not sure what this means. Aren't we only doing  prescan when
> parsing a HTML document?

The  prescan is done only when parsing HTML.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: XBL2, Component Model and WebApps' Rechartering [Was: Re: Consolidating charter changes]