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
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
On 2011-11-24 00:52, Yehuda Katz wrote:
On Wed, Nov 23, 2011 at 2:38 PM, Sean Hoganshogu...@westnet.com.au 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
On Thu, 24 Nov 2011 09:04:19 +0100, Darin Fisher da...@google.com wrote:
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
On Thu, Nov 24, 2011 at 12:04 AM, Darin Fisher da...@google.com 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
On Thu, 24 Nov 2011 02:39:33 +0100, Yehuda Katz wyc...@gmail.com 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
On 11/23/11 1:10 PM, ext Dimitri Glazkov wrote:
Let's iterate and get it to the digestible
point :)
Thanks for the list. Given we consider Web Components already in scope,
I added it to the Additions Agreed section as a reminder it should be an
explicit deliverable [1].
I expect that Web
On Mon, Nov 21, 2011 at 8:26 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Nov 16, 2011 at 2:40 AM, Henri Sivonen hsivo...@iki.fi 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:
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
On Nov 23, 2011, at 17:45 , Jonas Sicking wrote:
On Wednesday, November 23, 2011, Robin Berjon ro...@berjon.com 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 =
On Wed, Nov 23, 2011 at 11:05 PM, Julian Reschke julian.resc...@gmx.de 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
On Thu, Nov 24, 2011 at 3:49 PM, Robin Berjon ro...@berjon.com 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
On Nov 24, 2011, at 14:59 , Henri Sivonen wrote:
On Thu, Nov 24, 2011 at 3:49 PM, Robin Berjon ro...@berjon.com 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
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
On Thu, Nov 24, 2011 at 12:50 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-11-24 00:52, Yehuda Katz wrote:
On Wed, Nov 23, 2011 at 2:38 PM, Sean Hoganshogu...@westnet.com.au
wrote:
The alternative option (find / findAll / matches can accept explicit
:scope, but will otherwise
On Thu, 24 Nov 2011 15:42:08 +0100, Robin Berjon ro...@berjon.com 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
On 23 November 2011 18:23, Tab Atkins Jr. jackalm...@gmail.com 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
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
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
On Wed, 16 Nov 2011 11:40:08 +0100, Henri Sivonen hsivo...@iki.fi 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
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()
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 ann...@opera.com wrote:
On Thu, 24 Nov 2011 02:39:33 +0100, Yehuda Katz wyc...@gmail.com wrote:
Sounds good
Yehuda Katz
(ph) 718.877.1325
On Thu, Nov 24, 2011 at 9:47 AM, Boris Zbarsky bzbar...@mit.edu 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
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 shogu...@westnet.com.au
mailto:shogu...@westnet.com.au wrote:
On 23/11/11 12:17 AM, Boris Zbarsky wrote:
On 11/22/11 6:50 AM, Lachlan Hunt wrote:
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
On Wed, Nov 23, 2011 at 08:05, Dimitri Glazkov dglaz...@chromium.orgwrote:
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
On Thu, Nov 24, 2011 at 3:19 PM, Sean Hogan shogu...@westnet.com.au 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
On 2011-11-25 01:07, Sean Hogan wrote:
On 24/11/11 7:46 PM, Lachlan Hunt wrote:
On 2011-11-23 23:38, 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.
28 matches
Mail list logo
