On Tue, 19 Dec 2006 21:35:17 +0100, Dave Massy <[EMAIL PROTECTED]>
wrote:
It'd be great to have more detail and scenario on NSResolver. It appears
to allow elements within the document to have different prefixes than
things in the style sheet.
This is not about style sheets. (CSS does indeed allow that though.)
For example if we map html as the prefix for XHTML in our document then
we’d write it like:
<html:table><html:tr><html:td></html:td></html:tr></html:table>
But then we can write a selector such as:
“h|table > h|tr > h|td”
With a NSResolver that maps h to the same namespace as the html in the
primary document. This seems potentially confusing.
This is similar to how CSS and DOM Level 3 XPath deal with it. It allows
scripts to be written independently from the markup. Seems useful to me.
As I mentioned previously a more complete example of staticNodeList
usage would also be appreciated.
It's not clear to me what you mean with that. It's exactly like the thing
getElementsByTagName returns except it's not live. This should be pretty
clear from the draft.
2. Naming
getElementBySelector/getElementsBySelector is the only proposal we think
is acceptable.
But it's not accurate. This also creates the problem Ian Hickson pointed
out a few times. That people will map it to $$ or something which makes it
even less useful.
[...]
I'm concerned the group appears to believe naming is not important based
on the belief that there is no such thing as the perfect name.
Well, XMLHttpRequest is among the reasons for such "belief":-)
I don't really think the arguments about looking up the API in
documentation apply here. If this ever implemented interoperably it's
probably one of few things web developers will just remember because they
use it so often. Making a long name only increases the time in debugging
all the misspellings et cetera.
[...]
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
