was referring to this http://www.w3.org/TR/dom/
I didn't realise that was being taken over by the HTMLWG, as I haven't
been actively following spec stuff for a while as I've been busy with
other work. I guess they'll take care of it, then, so never mind.
--
Lachlan Hunt
http://lachy.id.au/
-publish it as a NOTE, and get a draft of DOM that
includes selectors api features published.
--
Lachlan Hunt
http://lachy.id.au/
, but keep the latter two with explicit refNodes
parameters matching nothing.
--
Lachlan Hunt
http://lachy.id.au/
http://www.opera.com/
.
Does that address your concerns?
I have committed a WD ready copy, with the publication date tentatively
set for 6 December.
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
--
Lachlan Hunt
http://lachy.id.au/
http://www.opera.com/
On 2012-10-29 14:38, Norbert Lindenberg wrote:
The current drafts of the Selectors API specifications [1, 2, 3]
refer to the third edition of the ECMAScript Language Specification,
The references have been updated. Thank you.
--
Lachlan Hunt
http://lachy.id.au/
http://www.opera.com/
to make this happen
as soon as possible.
--
Lachlan Hunt
http://lachy.id.au/
http://www.opera.com/
/SelectorsAPI/tests/submissions/Opera/
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
On 2012-10-22 16:29, Boris Zbarsky wrote:
On 10/22/12 6:10 AM, Lachlan Hunt wrote:
* hasFeature() returns false
Just as a note, this is a pretty pointless test, and the language about
it should be removed from this spec, assuming
http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature
On 2012-08-06 13:25, Lachlan Hunt wrote:
On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote:
(12/07/31 20:06), Arthur Barstow wrote:
On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote:
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518
I think this is a very minor issue
in due course. They hadn't been added yet due to the
prior instability of the new API design and their low priority. However,
feel free to contribute some examples if you like and I will consider
including them.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
when they are used.
2. Allow comments, but define that unclosed comments should throw a
SyntaxError.
3. Allow comments, define that unclosed comments are silently ignored.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
/2006/webapi/selectors-api-testsuite/level1-baseline-report.html
[2]
http://lists.w3.org/Archives/Public/public-webapps-testsuite/2012Jun/0009.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
what to do when the methods were invoked. I've now
backported this from that spec, but omitted all things related to :scope.
The changes are in the editor's drafts.
http://dev.w3.org/2006/webapi/selectors-api/
http://dev.w3.org/2006/webapi/selectors-api2/
--
Lachlan Hunt - Opera Software
http
will be considered as agreement
with the proposal.
This draft has been prepared for publication and checked into the
repository.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
or concerns about this proposal, please reply
to this e-mail by June 25 at the latest.
This draft has been prepared for publication and checked into the
repository.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
On 2012-06-18 11:06, Lachlan Hunt wrote:
Since it seems there are no objections to the latter option, and a few
people in favour of that, I've tentatively updated both drafts to
reflect this.
It now states:
If the group of selectors include namespace prefixes that need to be
resolved
On 2012-06-20 17:46, Marat Tanalin | tanalin.com wrote:
20.06.2012, 18:14, Lachlan Hunt lachlan.h...@lachy.id.au:
4. Support for returning elements that are not descendants of the
context object.
This feature allows a selector to be constructed such that it matches an
element anywhere
On 2012-06-21 15:56, Kang-Hao (Kenny) Lu wrote:
(12/06/20 22:26), Lachlan Hunt wrote:
On 2012-06-20 10:42, Charles McCathieNevile wrote:
In other words we have the same arguments that we had five years ago,
when we settled on querySelector as the one that provoked least
objection
/001-report.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
querySelectorAll() and sometimes switches to
.getElementById() or document.body.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
a SYNTAX_ERR exception
I also removed the note about non-namespace supporting implementations
throwing a syntax error instead of a namespace error.
http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces
http://dev.w3.org/2006/webapi/selectors-api2/#resolving-namespaces
--
Lachlan Hunt
me to start a CfC to publish a new WD of v2, just let me know.
Yes please.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
scripts performing any special error handling for
namespace errors that differs from other syntax errors.
Is there any reason we should keep this distinction?
[1] https://github.com/jquery/sizzle/blob/master/sizzle.js
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
it back to
Selectors API without a version number and move on. (This is my
preferred approach).
http://dev.w3.org/2006/webapi/selectors-api/
http://dev.w3.org/2006/webapi/selectors-api2/
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
On 2011-12-12 17:57, Boris Zbarsky wrote:
On 12/12/11 6:07 AM, Lachlan Hunt wrote:
2. These new methods for Element may be split out to a separate
interface that omits the refElements and and refNodes parameters.
Yes, please. There's no point having the same interface if the behavior
On 2011-12-12 17:57, Boris Zbarsky wrote:
On 12/12/11 6:07 AM, Lachlan Hunt wrote:
Given a selector list as input to the method, trim whitespace and then
for each complex selector, run the first step that applies:
(Note: if the selector list is , then there are 0 complex selectors in
the list
|compound or simple selector, then do not prepend :scope.
|e.g. :scope, div:scope.foo, div :scope p
|
| 5. Otherwise, prepend :scope and a descendant combinator.
Finally, return the modified list of complex selectors.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http
generic numerically indexed object.
e.g. These should all work
var list = document.getElementsByTagName(section)
document.querySelectorAll(:scopeh1, list)
document.querySelectorAll(:scopeh1, $(section)) // JQuery $()
document.querySelectorAll(:scopeh1, [elm1, elm2, elm3])
--
Lachlan Hunt - Opera
for, or at least a version of
JQuery that implements proxybind?
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
, that will match the span element.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
On 2011-11-24 14:49, Robin Berjon wrote:
So, now for the money question: should we charter this?
Only if someone is volunteering to be the editor and drafts a spec.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
a group of selectors
(selectors 3 terminology), which is equivalent to a selector list
(selectors 4). But :scope is still only useful when ref nodes are supplied.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
the code.
Selectors in selector lists are always independent of each other, so
authors who use a selector list would likely assume that one doesn't
affect how another in the list matches. It would seem far more
confusing for authors to do it using the other alternatives.
--
Lachlan Hunt - Opera
there will not be two alternative matches methods.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
issues, what happens in this case?
foo.find(label /for/ input+:scope~span)
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
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
/Release:jQuery_1.2#XPath_Compatibility_Plugin
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
, not just elements.
Could you describe a clear use case where this is useful for your needs?
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
/webapi/selectors-api2/#nodeselector
See the refElement/refNodes parameters which specify elements matched by
:scope.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
weeks. I'll review any additional
discussion and attempt to draft up a possible solution in the spec after
I get back from holidays.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Array when this issue was originally discussed a few years ago.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
that live node lists were a mistake and that
it would have been better if static Arrays were returned, we are stuck
with them and cannot change that.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
. Though I suspect the former is
very rare, and the latter doesn't work in all browsers.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
basis, so the above would be equivalent to:
document.querySelector(:scope + div, :scope div, foo);
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
)
With the selector pre-processing, that selector becomes
section:scope+div, :scope div, :scope~p span, .x :scopeh1+span
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
) // Matches sibling p elements
div
style scoped
:scope+p { ... } /* Matches nothing */
/style
div
p.../p
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
/selectors-api2/Overview.html?rev=1.29;content-type=text%2Fhtml#processing-selectors
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
(:scopep);
That would be equivalent to:
document.querySelectorAll(:scope :scopep, el);
Which won't match anything.
That might keep things simpler from an implementation perspective and
doesn't sacrifice any functionality being requested.
--
Lachlan Hunt - Opera Software
http://lachy.id.au
document.querySelectorAll(:scope+p, list);
Thus, if we do introduce the proposed method, should it behave
similarly, but with the implied rather than explicit :scope?
e.g.
document.findAll(+p, list);
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
problems in the past with some CSSOM properties, although they
have since been defined as nullable types in that spec.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
On 2011-05-07 16:03, Lachlan Hunt wrote:
(I don't have results for IE yet because the testharness script I used
to write the tests doesn't work in IE.)
I've now tested IE9, which did give me results. The following
properties are all stringified to .
* BODY .text, .bgColor, .link, .vLink
On 2011-05-06 15:45, Boris Zbarsky wrote:
On 5/6/11 6:10 AM, Lachlan Hunt wrote:
Recently, in order to resolve a site compatibility issue caused by us
stringifying to null for some properties, we made all DOMString APIs
consistent in their handling of null, such that they now stringify
to the behaviour they had
shipped in Firefox 3.6, so it's unlikely that reverting this will result
in any web compatibility issues.
[1] http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
On 2011-04-13 04:43, Cameron McCormack wrote:
Lachlan Hunt:
This seems to differ from the algorithm given for T[], which
requires that the object be either an array host object or a native
object, which would not handle the JQuery case. The sequenceT
type seems more generic than
On 2011-04-13 06:32, Cameron McCormack wrote:
Lachlan Hunt:
OK. Then I'm not sure what the practical difference between the
Element[] or sequenceElement would be then, nor which one to use.
... the only difference is that with Element[] you can distinguish
between null and an array
On 2011-04-09 19:14, Boris Zbarsky wrote:
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
On 2011-04-08 16:41, Boris Zbarsky wrote:
On 4/8/11 6:44 AM, Lachlan Hunt wrote:
We are thinking that implementing with a prefix as
Element.oMatchesSelector() is unnecessary
Well, one obvious question is whether we now have good reasons to
believe that the name and number/meaning
On 2011-04-10 13:30, Lachlan Hunt wrote:
But is jquery's collection a JS Array?
The object returned by the $() function isn't an array. It's a custom
object that mimics the functionality of an array...
var p = $(p.foo)
Var a = $(a);
a[0].matchesSelector(:scopea, p)
...
Would it be useful
an exception, or should it just accept
that ref[0] was an element and use that?
For NodeLists, should it accept any NodeList and only use the Element
nodes? e.g. element.childNodes may contain text or comment nodes.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
://bugzilla.mozilla.org/show_bug.cgi?id=518003
[2] https://bugs.webkit.org/show_bug.cgi?id=29703
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
On 2011-04-08 18:22, Boris Zbarsky wrote:
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?
Yes, that's reasonable.
In which case, do we
, though I'm not sure why. So I would
like to get clarification whether that is in fact the case, and whether
[NoInterfaceObject] really is what I should be using here.
[1] http://lists.w3.org/Archives/Public/public-web-perf/2011Mar/0058.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au
/2006/webapi/selectors-api-testsuite/
[2] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1221.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
. It seems much more likely that developers would want to
have all icons used to be designed with a common style.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
?html;32 or about:icon?ext=htmlsize=32
(though, I think being shorter and avoiding '' is better, so authors
don't have to bother escaping it in their HTML)
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
interoperability by
standardising this? Are these icons meant to be used by web content, or
meant only for internal use by the browser?
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
points to, and then follows the normal rules for evaluating
querySelector. Given that selector, any descendents of refNode that are
also descendents of element (the context node) will be matched, the
first of which will be returned.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http
to:
document.querySelectorAll(:scope+p, elm);
Anyway, since the CfC for FPWD has already begun, I'd rather not make
any major changes till afterwards. I'd also like to hear from a few
other people on this issue.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
/0317.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Sean Hogan wrote:
On 8/01/10 1:19 AM, Lachlan Hunt wrote:
can we publish Selectors API Level 2 as an FPWD?
http://dev.w3.org/2006/webapi/selectors-api2/
FYI, it seems the whole Status of this Document hasn't been updated for
Selectors-API2.
Yeah, that will get fixed up when I get the spec
Mozilla and WebKit have begun their implementation of matchesSelector,
which is defined in it.
The editor's draft is here.
http://dev.w3.org/2006/webapi/selectors-api2/
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Robin Berjon wrote:
On Nov 26, 2009, at 15:07 , Lachlan Hunt wrote:
Jonathan Watt wrote:
Nevertheless, that doesn't mean that Web content shouldn't be
able to process XML that uses xml:id using script and present the
processed information to the user using content and semantics
that *does
help if you
could find some other APIs and illustrate with some real world sites
that use them, where namespace-supporting APIs are utilised for good
reasons on the client side.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
don't actually try to implement the
methods themselves. They just implement somewhat compatible
functionality and expose it on their own objects (e.g. $(divp);
instead of document.querySelector(divp);).
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
.org/Archives/Public/public-webapps/2009AprJun/1221.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
selector would work fine?
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Lachlan Hunt wrote:
There must be at least two complete, independent implementations, each
of which must pass 100% of the baseline testsuite and should pass
additional tests, dependent on the following conditions:
...
The current state of implementations is as follows:
Minefield:
Baseline
Boris Zbarsky wrote:
On 11/26/09 9:58 AM, Lachlan Hunt wrote:
Actually, correction. Minefield and Opera don't meet the condition if we
keep the shipping requirement in the exit criteria.
Which imo we should. I don't think we want to be opening up that loophole.
The Gecko 1.9.2 branch builds
Lachlan Hunt wrote:
I have now split the test suite up into 3 files, similar to how I
prevoiusly described [1]:
1. Baseline Tests: HTML with CSS Level 2.1 Selectors.
2. Additional Tests: HTML with Selectors Level 3.
3. Additional Tests: XHTML+SVG with Selectors Level 3.
http://dev.w3.org/2006
~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=UTF-8
I'll make all the necessary editorial changes to get it ready for CR
when I find out what the publication date will be.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
.
[1] http://dev.w3.org/2006/webapi/selectors-api2/
[2]
http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Selectors%20API
[3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1198.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
a
selector like em as being equivalent to :referenceem.
I also defined the :reference pseudo class in the spec (formerly known
as :scope in previous discussions) to match the contextual reference
elements.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Boris Zbarsky wrote:
On 9/26/09 4:36 PM, Lachlan Hunt wrote:
A scoped selector string is a string that begins with an exclamation
point followed by a the remainder of the selector.
This assumes that '!' will never be allowed at the beginning of a CSS
selector, right?
It does
or not such a use case is significant. It seems more natural to want to
restrict the results to those within the same tree.
See the current editors draft for more details.
http://dev.w3.org/2006/webapi/selectors-api2/
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
for the cases where they're
using custom pseudo-classes not supported by the browser)
One possible modification I'm considering is introducing a separate
factory method for creating implied scope selectors:
createScopedSelector(selector); rather than using a boolean parameter.
--
Lachlan Hunt
().
It was discussed a couple of days ago in IRC. It's based on the
functionality provided and needed by javascript libraries.
Garrett Smith wrote:
Lachlan Hunt wrote:
div2.matchesSelector(:scope~div, div1);
The matching seems backwards. Should be on the matcher, instead of the
element? I don't
Lachlan Hunt wrote:
Sean Hogan wrote:
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
it tries
to create it. Otherwise, it will be valid.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
via querySelector*() or getElementsBy*(), or wherever else.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
until we can create arbitrary NodeLists.
It would simplify the issues that John described in his last e-mail, but
the exact use cases aren't entirely clear which is making finding and
determining the most appropriate solution difficult. I'm hoping John
can answer this question.
--
Lachlan Hunt
of elements can be
provided somehow and that the implementation can execute the query on
each distinct element in that collection. How exactly that is done is
just an API design issue.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
easier to define, but
otherwise, no normative changes.
I also fixed up the IDL for the NodeSelector interface to match the
current WebIDL requirements. I made these changes to the level 1 spec too.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
used once.
I'm not sure which alternative would be best, and I'm kind of hoping
there's a 4th alternative I haven't thought of yet that can address the
use cases easliy enough.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
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/
target element matches a given selector. So it
would be something like:
if (evt.target.matchesSelector(.fooinput.bar)) {
...
}
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
in the transaction are discarded.
Can you clarify this statement so that it's clearer that it's referring
to the transaction's error callback, and not a statement error callback
in executeSql.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
/webdatabase/#processing-model
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Hi,
The spec currently requires the first 2 callbacks for the
changeVersion method, while the 3rd is optional. The spec should make
all of the callbacks optional so authors don't resort to specifying
empty functions when they don't actually need to do anything with it.
--
Lachlan Hunt
/public-webapps/2009JanMar/0788.html
[4] http://www.hixie.ch/tests/adhoc/dom/selectors/001.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
1 - 100 of 158 matches
Mail list logo
