On 10/18/11 5:23 PM, Brian Kardell wrote:
This is not that easy. Especially because you can reach all DOM objects
from elements, so you have to lock down the entire API somehow.
Right, you would need essentially, to pass in a node list which
iterated 'lite' read-only elements.
So the script
On 10/18/11 5:01 PM, Brian Kardell wrote:
This too has come up in some discussions on CSS (CSSOM I think) that I
have had. In the right context - I don't think it would actually be
that hard. It would require a way to provide a sand-boxed evaluation
(read only elements)
This is not that easy.
On 10/18/11 4:20 PM, Yehuda Katz wrote:
* Speeding up certain operations like `#foo` and `body`. There is *no
excuse* for it being possible to implement userland hacks that
improve on the performance of querySelectorAll.
Sure there is. One such "excuse", for example, is that the user
On 10/3/11 5:32 AM, Roland Steiner wrote:
...
Cons:
- harder to implement: there's a window during parsing (before reading
the button) where it's still an ordinary button, requiring binding to be
added afterwards
I assume you meant "before setting the attribute"? I think working
around th
On 10/5/11 10:51 AM, Marcos Caceres wrote:
One other question: "expensive" is a relative term. How often do you
expect to perform this operation?
Not very in my case. The document is static.
OK. Just to put this into perspective, on the attached testcase I get
numbers in the 40-300 range on
On 10/5/11 4:14 AM, Marcos Caceres wrote:
1. I need to find elements of a particular type/name that are in a particular
language (in tree order), so that I can extract that information to display to
a user.
This use case is handled by querySelectorAll and :lang, no?
2. I need to check what
On 9/28/11 7:02 PM, Ian Hickson wrote:
There are specific problems in both those cases because of interaction
with the C++ layer, as far as I can tell.
Those are there, sure. But they're not the only problems...
The pure JS side of things, which is all that is needed for what we're talking
On 9/28/11 6:54 PM, Ian Hickson wrote:
Yes, for instance. Basically any use cases that is about presentation
rather than logic.
Do such use cases need to expose new API on the element?
-Boris
On 9/28/11 4:02 PM, Ian Hickson wrote:
I don't buy the argument that an element's API can't change.
To be more precise, such changes are very undesirable.
We have many counter-examples already in the platform, for example's API
can change dynamcially as it loads new plugins
This is actually
On 9/28/11 2:55 PM, Dimitri Glazkov wrote:
So, this is really a parsing issue, right?
Parsing is one side of the issue, yes. Only matters for declarative
markup, of course.
Hixie, is this the same problem you were mentioned as "doesn't have
fallback behavior"?
I would assume Hixie is als
On 9/28/11 2:24 PM, Dimitri Glazkov wrote:
Can you help me understand what the issues with fallback are?
Sure. If I want to attach a component to a and to do that I
have to write:
Content
and somewhere before that point register that x-my-table should be
treated as a table, the
On 9/28/11 2:12 PM, Dimitri Glazkov wrote:
C.) Just don't allow components to be used in places that have a special
content model.
I prefer this one, because:
1. It is very simple.
2. It discourages people from using components in cases already handled by HTML.
+1 as a first step. We can st
On 9/28/11 2:08 PM, Dimitri Glazkov wrote:
So, we need a way to express in markup that a particular element is to
be created with a particular behavior.
Yes.
Since the tagName is the only
identifying property of a DOM element that can't be changed, this
brings us to... custom tag names.
Or
On 9/26/11 7:53 PM, Charles Pritchard wrote:
The callback style is prevalent in the File API...
The enum style is also borrowed from
FileSystem.
Those are totally different things. One of them is much saner than the
other; it's not clear that either one is worth emulating in other specs
in d
On 9/23/11 5:20 PM, Julian Reschke wrote:
If I had $1 for every time I wrote xmlns="http://www.w3.org/1999/xhtml/";
and $10 for every time I told someone their page was broken because
they'd done that, I'd get myself a vacation package...
Namespace names are things I copy from templates and nev
On 9/23/11 4:13 PM, Julian Reschke wrote:
Contrary to what you say, I don't see anybody confused by URI comparison
when URIs are used as identifiers.
If I had $1 for every time I wrote xmlns="http://www.w3.org/1999/xhtml/";
and $10 for every time I told someone their page was broken because
t
On 9/23/11 4:26 AM, Henri Sivonen wrote:
Applying all the legacy text/html craziness to XHR could break current
use of XHR to retrieve responseText of text/html resources (assuming
that we want responseText for text/html work like responseText for XML
in the sense that the same character encoding
On 9/20/11 11:15 PM, Tab Atkins Jr. wrote:
I think this is properly a CSS issue. You want an element to not
exist in the box tree, but to still have its children in the tree,
which should be controllable with a display value, perhaps called
'transparent'.
I believe that would be an acceptable
On 9/20/11 11:10 PM, Erik Arvidsson wrote:
This is what we often refer to as the decorator pattern. The decorator
pattern in XBL has the problem that it changes the interface of the
element at runtime
To be clear, I am NOT proposing anything involving interface changes.
In the case I described
A comment on use cases that was brought up over here.
There's a use case that is not addressed by XBL1 and impossible to quite
address in a JS library that goes as follows. Say you have some data in
a . Semantically it's a data table. But you may want to present
it as a graphic (SVG or canv
On 8/29/11 4:53 PM, Robin Berjon wrote:
On Aug 29, 2011, at 21:40 , Boris Zbarsky wrote:
On 8/29/11 3:33 PM, Robin Berjon wrote:
For completeness, I'm guessing that namespaces would be supported as well?
Element renameElement(DOMString newName);
Element renameElement(DOMString
On 8/29/11 3:33 PM, Robin Berjon wrote:
For completeness, I'm guessing that namespaces would be supported as well?
Element renameElement(DOMString newName);
Element renameElement(DOMString newNS, DOMString newName);
Shades of
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNod
On 8/10/11 9:06 PM, Ryosuke Niwa wrote:
On Wed, Aug 10, 2011 at 12:49 PM, Olli Pettay mailto:olli.pet...@helsinki.fi>> wrote:
FYI, I'm planning to implement the proposal (using vendor prefixed API)
so that I can create "tryserver" builds.
I'll post the links to builds here later, hop
On 8/3/11 5:03 AM, Philippe De Ryck wrote:
You can create pretty much any arbitrary message body you want using
application/x-www-form-urlencoded already by crafting smart names and
values so the real importance is in not being able to set Content-Type.
This is not a security problem as far as I
On 8/2/11 9:55 AM, Anne van Kesteren wrote:
On Tue, 02 Aug 2011 15:48:53 +0200, Boris Zbarsky wrote:
http://blog.chromium.org/2011/08/new-websocket-protocol-secure-and.html
indicates
that the Chrome dev channel now has an unprefixed implementation of
the WebSocket API, as far as I can tell
http://blog.chromium.org/2011/08/new-websocket-protocol-secure-and.html
indicates that the Chrome dev channel now has an unprefixed
implementation of the WebSocket API, as far as I can tell. Also as far
as I can tell, the API is not really stabilized yet (e.g. there's the
big open question abo
On 8/1/11 7:39 AM, Phani wrote:
While we are still at CORS - could we have something like a reverse CORS
- that means a original server should explicitly allow a scripts loaded
from external domain.
You mean something like
https://dvcs.w3.org/hg/content-security-policy/raw-file/bcf1c45f312f/cs
On 7/22/11 12:32 PM, Dave Raggett wrote:
On 22/07/11 16:54, Boris Zbarsky wrote:
I don't need software that uses mutation events. I need software that
triggers editing operations, so I can them actually measure what DOM
mutations are performed in the course of these editing operations.
On 7/22/11 11:44 AM, Aryeh Gregor wrote:
Pretty much any formatting command is going to involve adding and
removing wrapper elements. To add a wrapper element, say adding a
around some text to make it bold, you first have to insert the wrapper
before or after the thing you want to wrap, then mov
On 7/21/11 4:15 PM, Aryeh Gregor wrote:
I can say that it's very common and critical for editors.
I'd really like numbers. Having looked at the Gecko editor code in the
past, I don't share your assurance that this is how it works
That said, if you point to a workload, I (or anyone else;
On 7/21/11 5:08 AM, Dave Raggett wrote:
Thanks for the explanation. Apps would need a way to disable
notifications during such animation sequences, and would be able to find
another means to serialize the animation (at a higher level).
I'm not sure I trust apps to do that, which is why I think
On 7/20/11 4:14 PM, Ryosuke Niwa wrote:
I'm not sure if we can have a concept of atomicity in DOM. Boris might
have a strong opinion on this.
I don't yet.
What I do have a strong opinion on is that it would be good to have some
data on how common "move" operations are compared to "remove" an
On 7/20/11 4:10 PM, Bjoern Hoehrmann wrote:
Simple example: you get a notification whenever a script could observe
the .getAttribute value changes, and you get it before the change is
applied.
Right, the synchronous "will mutate" notification.
Having that does simplify things. As discussed on
On 7/20/11 2:19 PM, Bjoern Hoehrmann wrote:
It's pretty common to have situations where lots (10-20) of properties
are set in inline style, especially in cases where the inline style is
being changed via CSS2Properties from script (think animations and the
like, where the objects being animated t
On 7/20/11 11:43 AM, Dave Raggett wrote:
Perhaps we need to distinguish auto generated attributes from those that
are set by markup or scripts.
I'm not sure what you mean.
Could you please clarify for me the
difference between the html "style" attribute and the one you are
referring to?
The
On 7/20/11 4:26 AM, Dave Raggett wrote:
You note that style attributes may be long as an argument against permitting
applications to see the
before value.
The problem is not the length per se. The problem is that the value is
not stored anywhere and has to be generated based on other data
s
On 7/19/11 7:18 PM, Ryosuke Niwa wrote:
For editing purposes, it's also crucial to know from/to where nodes are
removed/inserted. It seems like adding an offset trivially solves this
problem without much overhead.
I'm not convinced about "without much overhead". In general, adding an
offset
On 7/19/11 7:43 PM, Ian Hickson wrote:
On Thu, 28 Apr 2011, Magnus Kristiansen wrote:
Context: http://krijnhoetmer.nl/irc-logs/whatwg/20110428#l-707
Current browsers disagree about how to handlevar x;. Webkit browsers leave x pointing to
the div, whereas IE, Firefox and Opera make x undefined
On 7/7/11 6:28 PM, Jonas Sicking wrote:
In gecko you can for example use the nsIMutationObserver notification
to implement this.
Maybe you can, and maybe not. Those fire at "unsafe" times and are
limited in what you can do from them. Arbitrary debugging doesn't fit
the bill.
But yes, in g
On 7/6/11 10:23 AM, John J. Barton wrote:
This is another advantage of onModelChanging or 'before' events. All of
the previous values are available for listeners and the task of
selecting which ones to process is left to the listener.
Yes, I realize this is useful. This is why Gecko internally
On 7/6/11 4:27 AM, Dave Raggett wrote:
How does that scale to the case where you set the observer on the
document or on a div element acting as a contained for content editable
content? If I am not mistaken you would have to keep a copy of the
document, or of that div element respectively, and ke
On 7/5/11 5:21 PM, Rafael Weinstein wrote:
For ChildlistChanged, the potential data to be included:
-Target node*
-Removed nodes*
-Added nodes
-one of nextSibling or previousSibling*
My belief is that including the starred (*) data above would be
sufficient to meet David's test of mirroring a tr
On 7/5/11 4:25 PM, Aryeh Gregor wrote:
Maybe we don't want to give authors the ability to suspend mutation
events at all, though, sure.
Indeed.
It would also be a good way to deoptimize jits (e.g. you have to actually
_have_ the function around to detect when it "exits", so if your jit does
i
On 7/5/11 3:45 PM, David Flanagan wrote:
I've assumed that mutation events are an advanced feature that will
mostly be used by sophisticated developers and library authors. But I
see your point. I was worried you were saying that there quirks to the
DOM itself that made a read-only mode impractic
On 7/5/11 3:00 PM, David Flanagan wrote:
Boris, you have hinted that making the DOM readonly would cause all
kinds of problems, such as: a mutation listener that attempted to set
certain global variables would throw an exception. I'm coming at this
from the perspective of DOM Core and haven't got
On 7/5/11 12:30 PM, Aryeh Gregor wrote:
Why not have a function like suspendMutationEvents() that just makes
the current JavaScript function a compound mutating function? That
is, when you call that function, all mutation events are suspended
until the function exits.
That's a pretty fuzzy con
On 7/4/11 12:28 PM, Ojan Vafai wrote:
I'm not sure there really is a performance tradeoff. I believe that the
proposal Rafael put forward should almost always be faster. Storing the
list of changes and doing a JS callback once, for nearly all use-cases,
should be faster than frequent, semi-synchr
On 7/4/11 12:23 PM, John J. Barton wrote:
On 7/3/2011 1:23 PM, Boris Zbarsky wrote:
On 7/3/11 2:43 PM, John J. Barton wrote:
I'm not sure what you're asking... The whole point of the proposed
model is that if someone tries to do a mutation the mutation _will_
happen and will comple
On 7/4/11 12:09 PM, John J. Barton wrote:
In the current proposal, the DOM API is manipulated while the
onModelChange mutation listeners run.
Citation please? I see nothing like that in the proposal.
In the present case, imagine that the mutation listeners have only one
function call availab
On 7/3/11 2:43 PM, John J. Barton wrote:
I guess there are two different issues here. One has to do with compound
operations and the other is synchrony.
Keep in mind that insertBefore and appendChild are compound operations
for our purposes here, by the way.
If you imagine that mutation-can
On 7/3/11 11:41 AM, John J. Barton wrote:
I don't understand what 'trust' means here.
Ryosuke covered this.
I am not proposing any change to the privileges of listeners. How can the browser core
"trust"
an 'onModelChanged' listener but not an 'onModelChanging' listener?
Because the former
On 7/2/11 2:27 PM, Dave Raggett wrote:
n.b. the current mutation events work nicely for the document editing
use cases.
Only if you have full control over the set of all registered listeners.
If you do not, you're SOL, because current mutation events can be
delivered out of order if mutation
On 7/2/11 1:46 PM, John J. Barton wrote:
2) element transformation. The replacement fires "after" a mutation.
Library or tools that want to transform the application dynamically want
to get notification "before" the mutation. A common solution then is
to bracket changes:
"beforeChange" or "onMode
On 7/2/11 6:28 AM, Dave Raggett wrote:
My use case involves multiple people simultaneously editing the same
document. The mutations due to user actions are batched and serialized
as JSON. If you know that a given node was moved then you can avoid the
overhead of serializing a full description of
On 7/1/11 3:43 PM, David Flanagan wrote:
Sure, but if there were multiple listeners on different subtrees,
listening for different types of events, would you
built up a custom mutation list for each one as the mutations were
occuring? Or build up one master list and then filter it lazily when the
On 7/1/11 3:05 PM, David Flanagan wrote:
I don't think I really explained my use case on this list. See
https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c23 and
https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c25
And https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c26 please
> S
On 6/30/11 6:33 PM, Ryosuke Niwa wrote:
I think most developers are concerned with paint to avoid flickering and
not so much about layout.
I meant from the implementation's point of view. E.g. if a node is
partially inserted into the DOM, is it OK to trigger layout? The answer
may depend on
On 6/30/11 6:04 PM, Dimitri Glazkov wrote:
Perhaps the right solution is to require and disallow
access to shadow DOM tree if the sub-class is not overriding the
subtree?
I don't know. First, I'm not sure what problem we're solving. Second,
I'm not sure what does Third, who is being d
On 6/30/11 5:45 PM, Dimitri Glazkov wrote:
There's a very interesting distinction here. You don't "attach"
components to DOM elements. DOM elements _are_ components. The only
way to make a component is by sub-classing it from an existing
element. In this case, there is no distinction between nati
On 6/30/11 4:15 PM, David Flanagan wrote:
Forbid DOM modifications to all DOMs? Or just one DOM?
Is it clearer is I say "forbid any modifications to the document tree"?
There are multiple document trees around is the point.
It would be nice to only lock the document tree in which the mutatio
On 6/30/11 2:56 PM, David Flanagan wrote:
I'll add my own possibly stupid question... Can we go in the opposite
direction and fire mutation events immediately without queuing, but
forbid any DOM modifications from the event callbacks?
Forbid DOM modifications to all DOMs? Or just one DOM? Is
On 6/29/11 12:59 PM, Dimitri Glazkov wrote:
> It will just return null when the membrane is in place.
OK. And the encapsulation will prevent other ways of getting at the
shadow tree?
Ah yes -- I didn't know how to express this in IDL. The Node comes to
Document by way of TreeScope.
Docume
On 6/29/11 12:08 PM, Dimitri Glazkov wrote:
2) There is no separation between internal
(http://dev.w3.org/2006/xbl2/#xblimplementation) and external objects,
since we decided to push isolation into its own spec.
I still think this is a mistake that will come back and bite as as we
try to bolt
On 6/25/11 2:23 PM, Anne van Kesteren wrote:
So each specification that deals with custom headers of some kind (e.g.
EventSource has Last-Event-ID and Cache-Control) needs to say what
happens to them in the face of redirects?
On the face of it, yes. Especially because different redirect respon
On 6/22/11 1:50 PM, Arthur Barstow wrote:
Naturally, some will disagree with this view,
especially given the broad implementation of this spec.
But said implementations don't implement the storage mutex...
-Boris
On 6/21/11 3:01 PM, Darin Fisher wrote:
Isn't there already a signal to tell you when response headers are
available?
Yes; I believe the readystate changes at this point and
onreadystatechange is fired.
Isn't it a bit redundant for the upload complete notification to be tied to the
same sig
On 6/21/11 11:26 AM, Marcos Caceres wrote:
I agree that the focus should be the Web, but if other things benefit
from the security and design decisions, all the better, no?
Sure. I just don't think we should be doing things that are targeted
only at non-web situations.
The above still appl
On 6/21/11 10:25 AM, Marcos Caceres wrote:
Seems your idea of "the web platform" is very idiosyncratic and
limited. It almost sounds like you are advocating "a modern web
browser with no extensions installed is the Web platform" or "it's not
in the HTML/WAHTWG spec, so it's not the Web platform".
On 6/21/11 2:00 AM, Marcos Caceres wrote:
Browser extensions are in every browser, so in a sense are part of the
web platform.
I strongly object to both this claim and the idea that browser extension
concerns should affect web-exposed APIs in general
your claims seem pretty groundless giv
On 6/20/11 8:20 AM, Marcos Caceres wrote:
Browser extensions are in every browser, so in a sense are part of the
web platform.
I strongly object to both this claim and the idea that browser extension
concerns should affect web-exposed APIs in general
The APIs exposed to browser extension
On 6/20/11 6:30 PM, Aryeh Gregor wrote:
I object to this. Web SQL Database was never interoperably
implemented, or adequately specified. Web Storage has been
implemented in every major browser for a few years, and tons of
content depends on it.
Note that there are currently major browsers tha
On 6/17/11 12:57 PM, Boris Zbarsky wrote:
On 6/17/11 8:49 AM, Anne van Kesteren wrote:
On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky
wrote:
It looks like Gecko, Presto, and Webkit all support on* event
attributes on all DOM elements, not just HTMLElement.
IE9 seems to only support them
On 6/17/11 8:49 AM, Anne van Kesteren wrote:
On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky wrote:
It looks like Gecko, Presto, and Webkit all support on* event
attributes on all DOM elements, not just HTMLElement.
IE9 seems to only support them on HTMLElement.
I would propose that these
On 6/15/11 4:08 PM, David Bruant wrote:
2) XHR in the web browser gives (at the moment, at least) sites that are
outside a firewall that your browser is behind the ability to make requests to
hosts that are behind the firewall.
You wrote "at the moment, at least". Is there some planned chan
On 6/15/11 6:43 AM, David Bruant wrote:
Could someone explain how running in a web browser justify such a
difference? For instance, could someone explain a threat particular to
cross-origin XHR in web browser?
Off the top of my head:
1) XHR in the web browser sends the user's cookies, HTTP au
On 6/3/11 6:02 AM, Margarita Podskrobko wrote:
In this particular case, the user might be not aware that there is any
this kind of addon running in browser and changing the value of Origin
header.
If the user doesn't know what addons are running in the browser, then
the user is screwed. Addon
On 6/2/11 6:41 PM, Margarita Podskrobko wrote:
I have read couple of discussions in this mail list concerning security
issues of CORS. AFAIU, the main point of CORS is to delegate security
enforcement point from client browser(requestor of resource) to server
(possessor of resource).
It's the o
On 6/2/11 3:53 PM, David Levin wrote:
The mechanism:
* needs to have an intuitive feel for developers,
* must preserve backwards compatibility,
* should ideally allow the port to function the same regardless of
whether the message was cloned or transferred.
I'm not sure what
It looks like Gecko, Presto, and Webkit all support on* event attributes
on all DOM elements, not just HTMLElement.
IE9 seems to only support them on HTMLElement.
I would propose that these be supported on all Elements at least for
events that are not element-specific (e.g. "click").
-Boris
On 5/17/11 12:50 PM, Paul Libbrecht wrote:
So you (Mozilla) would not accept to include URL-list as acceptable flavor to
be read from the clipboard at paste time if that URL-list contains file URLs.
Correct?
I believe this is correct, yes.
-Boris
On 5/17/11 12:27 PM, Paul Libbrecht wrote:
On my mac, as far as I know, this can only happen if I copied the the
file explicitly (as a file, not as a content). Pasting in some web-page
means I want to transmit the information of the clipboard to the page.
You want to transmit the file contents.
On 5/13/11 4:07 PM, Jonas Sicking wrote:
It *does* however call for a readystatechange event to be fired in
response to the call to .open. Even if the request being started is a
synchronous one.
What is the use case for this event? It seems pretty useless and
inconsistent to me.
I believe web
On 5/9/11 3:39 PM, Aryeh Gregor wrote:
* Every time the UA would normally invoke its spellchecker on a word,
it fires a spellcheck event at the element in question
This does mean firing tens of thousands of events during load on some
pages (e.g. wikipedia article edit pages) Maybe that's
On 5/7/11 10:03 AM, Lachlan Hunt wrote:
For document.write(), Gecko, Webkit (including Safari 5), Opera and IE
write "null" on both Windows and Mac. I don't know which version of
Safari you were using that gave you a different result.
I was using Safari 5 on Mac; looks like it does something we
On 5/6/11 6:10 AM, Lachlan Hunt wrote:
This definition matches current selectors-api implementations, which do
this conversion for the selectors parameter and this is also the result
expected by the current selectors api test suite. However, according to
information I got from Anne, and from my o
On 4/28/11 4:31 PM, Magnus Kristiansen wrote:
Current browsers disagree about how to handle var x;. Webkit browsers leave x pointing to
the div, whereas IE, Firefox and Opera make x undefined [1]. (There is
content that depends on x being undefined, but I don't have any links
handy right now.)
M
On 4/22/11 8:35 PM, Rafael Weinstein wrote:
Myself and a few other chromium folks have been working on a design
for a formalized separation between View and Model in the browser,
with needs of web applications being the primary motivator.
Our ideas are implemented as an experimental Javascript l
On 4/20/11 6:57 PM, Tab Atkins Jr. wrote:
True, you need some side-channel to link the two iframes for a
particular client. You can use something simple like one of the
*other* within-domain communication mediums (cookies, localStorage,
etc.)
Which is why there are options to restrict third-pa
On 4/20/11 3:54 PM, Tab Atkins Jr. wrote:
Please correct me if I'm missing something, but I don't see any new
privacy-leak vectors here. Without Shared Workers, 3rdparty.com can
just hold open a communication channel to its server
Unless you have a firewall or proxy that prevents that particul
On 4/19/11 8:51 AM, Jonas Sicking wrote:
Could we at least limit overrideMimeType calls to only be allowed when
setting .responseType is allowed?
I think this would make the most sense, personally.
-Boris
On 4/13/11 6:20 AM, Lachlan Hunt wrote:
Which conversion algorithm applies here? Is it 4.1.15. object, or
4.1.16. Interface types?
http://dev.w3.org/2006/webapi/WebIDL/#es-object
The latter, since Node is an interface type.
-Boris
On 4/13/11 5:43 AM, Lachlan Hunt wrote:
I didn't think so, but then perhaps I misunderstand what the spec means
by a native object. ECMAScript defines a native object as
"object in an ECMAScript implementation whose semantics are fully
defined by this specification rather than by the host enviro
On 4/10/11 12:02 PM, Lachlan Hunt wrote:
I've updated and simplified the spec to handle the above case using the
parameter sequence. I still need to update the prose to say that
while the collections may contain any Node, only Element nodes are added
to the list of contextual reference elements.
On 4/10/11 4:30 AM, Lachlan Hunt wrote:
Would it be useful, and is it possible to define the refElements
parameter to accept any object that contains a .length and indexed
properties, just like a JQuery object?
Looks like this already got answered, but yes, sequence should
make that work.
O
On 4/10/11 4:32 AM, Lachlan Hunt wrote:
The same issue will occur with any new selector that gets added in the
future. The only real difference between this and any other is that
support for :scope will inherently imply refElement support.
Indeed.
I'm not entirely sure what you consider to be
On 4/9/11 6:27 AM, Lachlan Hunt wrote:
There were cases in JQuery where the script wanted to iteratively run a
selector on all nodes in a collection, and return elements that are
descendants of those elements. This allows :scope to be used in those
cases by passing the collection as the refNodes.
I have two questions about
http://www.w3.org/TR/selectors-api2/#determine-contextual-reference-nodes
1) What are the use cases for supplying more than one contextual
reference node, exactly? It seems weird to allow more than one node to
match :scope.
2) If we do want to allow the multiple
On 4/8/11 9:24 AM, Boris Zbarsky wrote:
In the text at
http://www.w3.org/TR/selectors-api2/#the-scope-pseudo-class the term
"belongs to a document" is not defined. Does it mean "there is a
Document on the parent chain", or does it mean "ownerDocument is not null"?
In the text at
http://www.w3.org/TR/selectors-api2/#the-scope-pseudo-class the term
"belongs to a document" is not defined. Does it mean "there is a
Document on the parent chain", or does it mean "ownerDocument is not null"?
-Boris
On 4/8/11 6:44 AM, Lachlan Hunt wrote:
2. Using the :scope selector in existing implementations will throw a
syntax error.
On which note, it seems like :scope will first show up prefixed as well,
right?
-Boris
501 - 600 of 896 matches
Mail list logo
