Martijn wrote:
On 12/20/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
One of the arguments that was made was also that the existing methods
have
failed, which would make #3 the odd one out and probably #2 as well. I
don't really care what the final name, but it should match the first
Wow, sorry, a bunch of messages got caught in spam filter temporarily.
I think the point was overcommunicating how this works in the spec would be a
really good idea, not this doesn't work well.
-Original Message-
From: Charles McCathieNevile [mailto:[EMAIL PROTECTED]
Sent: Tuesday,
On Thu, 21 Dec 2006 19:09:17 +0100, Chris Wilson
[EMAIL PROTECTED] wrote:
Wow, sorry, a bunch of messages got caught in spam filter temporarily.
I think the point was overcommunicating how this works in the spec would
be a really good idea, not this doesn't work well.
Not quite sure I
Nope, that's what I meant. The spec should give more examples, particularly in
the simplistic cases. The one case I wanted a definition for was if there is
no doctype given on an HTML document, and there is a specific namespace given
for XHTML (or whatever), does it match? (e.g. is there a
On Fri, 15 Dec 2006 16:37:38 +0100, Ellen Siegel [EMAIL PROTECTED]
wrote:
I will put your current draft version into the upcoming 280 Proposed
Final Draft
spec that we plan to publish in early January.
The main issue remaining, then is to determine when this interface can be
considered
Currently the following methods exist:
* document.getElementsByTagName()
* document.getElementsByName() (HTML only)
* document.getElementById()
The following method is proposed by the WHATWG:
* document.getElementsByClassName()
These four methods all return a _live_ NodeList meaning that
I don't care about the particular conclusion. For the purposes of
interoperability across implementations (and that IS the point of creating a
standard, right?) I believe it absolutely should be defined, and is the issue
of the WebAPI WG - unless you don't really care about interoperability,
On Thu, 21 Dec 2006 22:25:11 +0100, Chris Wilson
[EMAIL PROTECTED] wrote:
I don't care about the particular conclusion. For the purposes of
interoperability across implementations (and that IS the point of
creating a standard, right?) I believe it absolutely should be defined,
and is
Whose job is it in the W3C? (This isn't how you transform HTML into a DOM -
it's what doctype do you presume when it's not there?)
-Original Message-
From: Anne van Kesteren [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 21, 2006 1:35 PM
To: Chris Wilson; Charles McCathieNevile;
On Thu, 21 Dec 2006 22:57:55 +0100, Chris Wilson
[EMAIL PROTECTED] wrote:
Whose job is it in the W3C? (This isn't how you transform HTML into a
DOM - it's what doctype do you presume when it's not there?)
DOCTYPEs? DOCTYPEs have two use cases on the web as far as I know:
1. In HTML
Sorry. I should be saying what namespace URI is an HTML document in?
-Original Message-
From: Anne van Kesteren [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 21, 2006 2:07 PM
To: Chris Wilson; Charles McCathieNevile; Dave Massy; Web API WG (public)
Cc: Tina Duff
Subject: Re:
On Thu, 21 Dec 2006 23:09:46 +0100, Chris Wilson
[EMAIL PROTECTED] wrote:
Sorry. I should be saying what namespace URI is an HTML document in?
As I said before, currently implementations set the namespaceURI attribute
of elements to null for documents parsed with an HTML parser. The
So even a quirksmode document is in the xhtml namespace?
-Original Message-
From: Anne van Kesteren [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 21, 2006 2:15 PM
To: Chris Wilson; Charles McCathieNevile; Dave Massy; Web API WG (public)
Cc: Tina Duff
Subject: Re: NSResolver Re:
On Thu, 21 Dec 2006 23:19:09 +0100, Chris Wilson
[EMAIL PROTECTED] wrote:
So even a quirksmode document is in the xhtml namespace?
I think that's the plan, yes. That all documents parsed with an HTML
parser will return a DOM with namespaced element nodes. (There's still an
open question
Hi, Anne-
Anne van Kesteren wrote:
Currently the following methods exist:
* document.getElementsByTagName()
* document.getElementsByName() (HTML only)
* document.getElementById()
The following method is proposed by the WHATWG:
* document.getElementsByClassName()
I'd really like to
* Anne van Kesteren wrote:
[...]
I would like to point out that there exists a valid technical reason for
using different method names than the ones in the current draft. One of
reasons why the DOM uses longer, more descriptive names is to avoid name
clashes. The current draft essentially
On Thu, 21 Dec 2006, Anne van Kesteren wrote:
Currently the following methods exist:
* document.getElementsByTagName()
* document.getElementsByName() (HTML only)
* document.getElementById()
The following method is proposed by the WHATWG:
* document.getElementsByClassName()
We
I agree with what Bjoern says below about the need to avoid name clashes.
If developers don't like the long names such as getElementsBySelectors(),
then they can write their own JavaScript wrapper functions that have
shorter names, such as function matchAll(...) { return
Hello Web API interested parties,
I've read this thread, and rather than replying to people's specific
points, I would like to give some arguments in favor of a relatively
short name.
Short Names For Common Idioms
---
Many have argued that classes,
Hi, Maciej-
Maciej Stachowiak wrote:
- Microsoft representatives endorse a longer name -- I don't think
Microsoft's track record in design of web APIs for JavaScript justifies
treating them as an authority. I hope their arguments will be evaluated
on their merits, not the credentials of
On Fri, 22 Dec 2006 02:48:45 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
Based on this, I think that shorter names like match or matchAll are
justified, if not necessarily those exact names.
How about (document+).match(/Document/) vs. (document).match() -- sure,
a bit exaggerated
21 matches
Mail list logo
