Re: [selectors-api] Consider backporting find() behavior to querySelector()
20.06.2012, 18:26, Lachlan Hunt lachlan.h...@lachy.id.au:
In particular, is there really value in adding two distinct methods that
differ only by whether they return 1 element or a collection? Resolving
this issue first would help with resolving the naming issue.
It should be noted that JQuery/sizzle does not use querySelector() at
all, AFAICS. It only uses querySelectorAll() and sometimes switches to
.getElementById() or document.body.
The whole jQuery's paragigm of always searching all matching elements is a
potentially big shortcoming of jQuery as for (at least) performance. It's
natural to suppose that searching for just _first_ matching element and
returning immediately once it's found should be much _faster_ than searching
for _all_ matching elements (be it 100 or 1000 elements) even if we need just
first one.
So yes, we need two separate methods: one to select first matching element and
another one to select all matching elements. They could be united into one
single method with an optional argument, but I doubt it would be quite handy
and nonconfusing for using. Also, a method generally should return consistent
result as for type of returning value, so if we had one method that always
returns collection of elements, that would force us to often use the method
with item accessor (like find('A')[0]) that would be redundant, unusable and
less readable.
For example, I very like `querySelector()` and use it at least as much as (and
maybe even more often than) `querySelectorAll()`.
Re: [selectors-api] Consider backporting find() behavior to querySelector()
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 in the tree relative to the context element. This
feature is not relevant to document.find(), since it can already return
anything from the whole tree.
elm.find(+span) // span is a sibling
elm.find(/for/ input) // input could be anywhere
elm.find(:not(:scope)) // Everything except the context object
This feature cannot be supported on Element.qSA, even when using eplicit
:scope, because matching elements need to be descendants of the context
object.
It's unclear why an _updated_ qSA version should have same limitation that
matching elements need to be descendants of the context object. There is
nothing obvious that makes h1.querySelector('+ H2') impossible to work in newer
implementations (in older ones it would not work anyway -- to the same extent
as `elm.querySelector(span)` that you've declared as could work).
Re: [selectors-api] Consider backporting find() behavior to querySelector()
20.06.2012, 00:38, Tab Atkins Jr. jackalm...@gmail.com: On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters sim...@opera.com wrote: On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: We have lots of shipped APIs with worse names. I think we should live with past mistakes, try not to make them again, and move on. This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. There is a key difference between native functionality and one implemented as a library -- they quite differently relate to backward compatibility. A library can be rewritten partially or even entirely if needed (older applications can just continue using older versions of the library), while native functionality, once widely implemented, have to be supported forever and in fact cannot (and should never) be dropped. As for `querySelector()` in particular, its name is indeed not the best, but _not_ because it's too long, but because it's not quite _clear_ / _self-documenting_. `querySelector()` and `querySelectorAll()` should have been named `getElementBySelector()` and `getElementsBySelector()` instead. In this regard, `find()` is far less clear (and even confusing) as for what it does.
Re: [webcomponents] Custom Elements Spec
Ian, it seems you are continuing to confuse two very different things: 1. local semantics; 2. extending existing elements. They have completely different purposes. Web-developers generally do not need to _extend_ existing elements (purpose of such extending itself is quite mysterious for me). What we need is local semantics that has more elegant code representation than _common_ container (SPAN or DIV) with a class. For example: x-lorem/x-lorem looks far better, compact, readable, and sensible than: span class=x-lorem/span (at the same extent as p/p is better and smarter then div class=p/div even if P had no any semantic sense). Both x-lorem and span class=x-lorem have NO global semantics at all like that SELECT element have. Instead, they have _local_ semantics which purpose is known exclusively for document author/scripts and/or consumers of the document. No any fallbacks needed here at all. Some of possible additional practical benefits of custom tag-names are: * browsers could implement more effective markup error correction based on equality of tag-name of opening and closing tags; * microformats that would not forced to rely on classes, but would use tag names instead. As for markup error correction: for example, in case of multiple nested DIVs, browser cannot unambiguously determine what exact DIV a closing tag is related to: div div !-- Closing tag for nested DIV is accidentally absent. -- /div!-- Browser wrongly thinks that parent's closing tag is for nested DIV. -- With custom tag-names, browser could easily determine exact element that has closing tag absent: x-lorem x-ipsum !-- Closing tag for x-ipsum is accidentally absent. -- /x-lorem!-- Browser automatically closes x-ipsum element. -- Again: local semantics (custom _tag-names_) has nothing to do with custom elements in their current form like select is=example. Thanks. 04.05.2012, 08:19, Ian Hickson i...@hixie.ch: On Tue, 1 May 2012, Dimitri Glazkov wrote: Custom tags vs. is attribute - is attribute is awkward, overly verbose - custom tags introduce local semantics - perhaps start with something as simple as reserving x- prefix on HTML tags for local semantics. Whether it's x-colour-picker fallback=select ...or: select is=colour-picker ...you have the same level of awkwardness. The advantage of the second one, aside from being less ugly and generally terser, is that it actually has workable fallback in legacy UAs -- the first one would only work in UAs that supported components or at a minimum knew enough about components to know how the fallback mechanism worked. (Also, the first one runs the risk that authors would start forgetting to give a fallback, with its resulting implications on accessibility, search engines, etc.) -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Custom Elements Spec
So what happens in browsers that don't support components? Or in search engines or other data analysis tools that are trying to extract the semantics from the page? Elements with custom tag-names would have EXACTLY SAME semantic (as for core HTML5 semantics) meaning as a common container (SPAN or DIV) with a class. No more and no less. P.S. FWIW: my proposal for custom elements: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14011 04.05.2012, 22:58, Ian Hickson i...@hixie.ch: On Fri, 4 May 2012, Marat Tanalin | tanalin.com wrote: Instead, they have _local_ semantics which purpose is known exclusively for document author/scripts and/or consumers of the document. No any fallbacks needed here at all. So what happens in browsers that don't support components? Or in search engines or other data analysis tools that are trying to extract the semantics from the page? Having elements with no well-defined semantic meaning is counter to the entire philosophy of the Web, IMHO. I strongly disagree that we should be even attempting to allow it, let alone optimising for it. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Custom Tags and Local Semantics
FWIW: my proposal (already successfully rejected) for custom elements (real custom elements with really arbitrary tag names allowed) in W3 bug tracker from 2011-09-03: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14011 BTW, it seems local semantics (what my proposal is about and what you are probably talking about) and element customization in its current form are completely different things, and the latter has nothing to do with solving the former. 23.04.2012, 22:55, Dimitri Glazkov dglaz...@chromium.org: Eric Meyer (cc'd) posted an intriguing article about custom tags and local semantics: http://meyerweb.com/eric/thoughts/2012/04/10/element-customization/ I must say, even though the current direction we take with Web Components does not involve custom tags, I still find the current, is attribute-based solution awkward. This keeps me wondering about the tradeoffs of custom tags and local semantics. In terms of elegance, nothing comes close to specifying an identify of a DOM element than the localName of the corresponding tag in markup. I know there are strong opinions around keeping local semantics out of the tag names. While I respect the owners of these opinions, I also want to build something _good_ with the Web Components effort. Given that pretty much every time I explain how is attribute works results in raised eyebrows and quizzical looks, I feel we need to revisit the notion of using custom tags for custom elements in Web Components. Who would be interested in a discussion around this at the WebApps F2F next week? I would like to keep this discussion isolated from other Web Components-related topics, mostly to limit effects of the giant rabbit hole that is debating language semantics. :DG
querySelectorAll() -- selecting _immediate_ children of element
querySelector() and querySelectorAll() methods are exciting features, but they
do not allow select _immediate_ children of reference element.
To address this lack, we could use following syntax:
var divs = refElement.querySelectorAll(' DIV');
Here 'divs' variable contains list of DIV elements that are immediate children
(not just descendant elements) of reference element (refElement).
This syntax is extremely intuitive and BTW is supported in jQuery.
Other combinators (e.g. adjacent-sibling combinator) would have sense too, for
example:
var span = h1.querySelector('+ H2 SPAN');
'span' variable here contains DOM reference to SPAN elements inside H2 element
which is next sibling of H1 element:
h1.../h1
h2... span.../span .../h2
But fundamental missing demanded feature is ability to select _child_ elements
of reference element ( querySelectorAll(' DIV') ).
Since usecases are purely script-level, CSSWG has nothing to do with this
syntax. From selectors perspective, there is nothing new here: we have
reference element (in CSS, a selector is used in place of concrete element),
standard selector (DIV), and standard combinator between them.
An acceptable alternative to implied reference element would be using ':this'
pseudoclass:
var divs = refElement.querySelectorAll(':this DIV');
var span = h1.querySelector(':this + H2 SPAN');
Furthermore, :this pseudoclass would give us additional possibilities such as
selecting descendant elements via selectors _all_ parts of which matches to
descendants of reference element.
For example, following code will select all links that are descendants of _any_
paragraph (not necessarily descendants of reference element):
refElement.querySelectorAll('P A');
As opposed, this code:
refElement.querySelectorAll(':this P A');
would select links that are inside of paragraphs which _themselves_ are
descendants of the reference element.
Probably most DRY, usable, and flexible solution would be to allow both
syntaxes: implied reference element to use with combinators (where :this would
be just redundant), and explicit :this to use in conjunction with descendant
selectors (where it really gives additional useful possibilities missing in
current querySelector spec and implementations).
Thanks.
P.S. The proposal has been originally posted in public-script-coord
(http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0078.html )
but it seems public-webapps is probably more appropriate place for this.
