On Sat, 4 Feb 2006, Bjoern Hoehrmann wrote:
>>
>> It's mathematically impossible to verify that all script on the page is
>> always going to generate conformant DOMs, but indeed, a validator that
>> attempts it should be given high marks.
>
> Well, if you approach the problem by asking whether it's possible that
> things become non-compliant, you'll either have to analyze any and all
> dependencies like server-side scripts and workflows or you'd generate
> false negatives, since adding some external data to the document is very
> likely to generate errors if the external data is non-compliant. The
> right approach here is to extend implementations to perform validation,
> e.g. after each mutation event.
That still wouldn't work. Take this document:
Test
var N = 2;
function tag() {
if (Math.random() > 0.5)
document.write('');
else
document.write('<\/div>');
}
for (var i = 0; i < N; i += 1)
tag();
Is it conformant?
This is a simple case (it's conformant in 25% of cases; as you increase N
it gets conformant in fewer and fewer cases -- how would your program test
this?).
A more complex case would be something like:
Test
function test() {
var isItTrue;
/* something that tests whether
Goldbach's conjecture is true
or not and sets isItTrue to
true or false as appropriate. */
return isItTrue;
}
if (test())
document.write('
');
document.write('<\/div>');
Is this document (with the comment replaced by appropriate code)
conformant or not?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
* Ian Hickson wrote:
>On Fri, 3 Feb 2006, Blanchard, Todd wrote:
>> You are assuming that validators run javascript - they generally don't.
>> I'm hoping to add it to Scrutinizer
>> (http://www.blackbagops.net/seaside/html) but that would make it unique
>> in the world of validators.
>
>It's mathematically impossible to verify that all script on the page is
>always going to generate conformant DOMs, but indeed, a validator that
>attempts it should be given high marks.
Well, if you approach the problem by asking whether it's possible that
things become non-compliant, you'll either have to analyze any and all
dependencies like server-side scripts and workflows or you'd generate
false negatives, since adding some external data to the document is very
likely to generate errors if the external data is non-compliant. The
right approach here is to extend implementations to perform validation,
e.g. after each mutation event. That's in fact trivial to implement and
has already been done. It would not be fast though, and should probably
be combined with code coverage analysis but it's about as close as you
can get to the extend relevant to developers.
We already have several browser extensions like the HTML Tidy extension
for FireFox that do something close to that, before too long we'll also
have extensions that support RELAX NG, XML Schema data types, Schematron
and some extensions like DTLL or custom XPath functions combined with
some NVDL (since that would just require a simple wrapper to existing
implementations); you'd just bind that to some events and are almost
there. I also note that the various DSDL technologies are extremely
powerful, there is little that can't be checked that way (complex micro
grammars with middle recursion or grammars that require significant
post-processing like checking strings after removing escape sequences
come to my mind, along with non-machine testable requirements like that
certain things must be in a specific natural language).
Of course, all of that would be signiciantly simpler if implementations
simply validate as appropriate, they have to implement most if not all
relevant things anyway. But given browser vendors don't want to be
talked into that, we'll have to work around. Of course, errors are very
expensive in any case, it's best to design new technology such that
there is only a minimum of possible errors.
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
On Fri, 3 Feb 2006, Blanchard, Todd wrote:
>
> You are assuming that validators run javascript - they generally don't.
> I'm hoping to add it to Scrutinizer
> (http://www.blackbagops.net/seaside/html) but that would make it unique
> in the world of validators.
It's mathematically impossible to verify that all script on the page is
always going to generate conformant DOMs, but indeed, a validator that
attempts it should be given high marks.
> Browser makers can't just punt on this issue - you have to help the
> developers more. As it is now we spend way too much time writing little
> probe programs to reverse engineer browser behavior to figure out why
> our nifty AJAX apps don't work.
I don't disagree. This is out of scope for this working group, though.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
On Fri, 3 Feb 2006, Gervase Markham wrote:
>
> Simon Pieters wrote:
> > Browsers could mark all errors as red in view source. In Firefox you can
> > select a piece of text and view selection source, which will bring up
> > the serialized DOM.
>
> They could (at least, as far as I understand the issue), for XHTML at
> least (not HTML5), if they wanted to implement a validating parser
> instead of a non-validating one, and improve its error output
> sufficiently to be able to make such annotations.
In fact, in HTML5 it will be even easier, since the spec will clearly
specify exactly what the parse errors are as part of the parsing
algorithm.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
On Thu, 2 Feb 2006, Blanchard, Todd wrote:
>
> OK, I have to disagree with this - the id's MUST NOT be duplicated as
> the end result is simply converting one kind of error to a different
> kind of error.
I don't understand why this is bad. The document isn't even well-formed in
these cases, if the author cared about errors then presumably the document
wouldn't have these problems. Can you point to a page that breaks because
of this behaviour?
> I'd also suggest that browsers should be NOISY about bad HTML such that
> authors are encouraged to fix it (possibly through some disable-able
> preference).
That's up to the UA and is out of scope of this working group.
> Making one kind of problem look like another kind of problem isn't
> "HELPING" us.
It isn't intended to. It's intended to make the page render so that the
user can see what he can get to the information on the page.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
On Thu, 2 Feb 2006, David Hyatt wrote:
>
> BTW, we tried to add as an inline that should be reopened (like
> and etc.) and it broke some of our layout tests (snippets of
> real-world Web sites). clearly does not always reopen in WinIE
> and Firefox, so for now we are having to leave it out.
Nothing reopens in IE, IE just uses its magic DOM algorithm for
everything. I'm surprised that doing this for caused problems, but
it's good to know, thanks!
Currently, the list of elements we will definitely be doing this to is:
HTML5 elements: a em i small strong
obsolete elements: b big font s strike tt u
In addition to these, Mozilla also does it for:
bdo blink del ins sub sup q
...and Safari also does it for:
code dfn kbd nobr samp var wbr
I'm currently planning on not including any of these in the list of tags
for which browsers should "open an adoption agency". Do you know if any of
them _should_ definitely be included?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
On Thu, 2 Feb 2006, Blanchard, Todd wrote:
>
> What I want to know is: if the "cloned" node has an id attribute, and
> id is meant to be unique, then how do we resolve this conflict?
We don't. For compatibility with existing implementations we are forced to
require that the ID be duplicated too.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Lachlan Hunt wrote:
For example, using this CSS-like syntax (but it's not CSS).
selector {
event-name: function();
}
I just remembered BECSS, which is pretty much that exact thing. Strange
how didn't occur to me at all, though it must have been buried in my
subconscious somewhere :-).
http://www.w3.org/TR/becss
--
Lachlan Hunt
http://lachy.id.au/
On Feb 3, 2006, at 9:30 AM, Jim Ley wrote:
On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
Jim Ley wrote:
the document of course shows no use cases at all.
Is there some doubt that the ability to tag an arbitrary set of
elements
and later easily get an array of those elements is a useful feature
for
web development?
I've yet to hear of an actual reason to do so, people keep saying it
seems useful...
If you would like use cases, I present all of the web pages currently
using a JS implementation of getElementsByClassName based on
getElementsByTagName("*") and some manual class name inspection logic.
Yes, but they're all using it to attach events to every one of the
class, which is why you have to look at use cases, the reason they're
doing it is not because getElementsByClassName is missing, but because
addEventListenerToClass or -moz-binding etc. are missing.
It's the classic mistake of looking at making the workarounds easier,
when you should be looking at making the underlying use easier.
Jim.
Jumping in a little late here, and with a theoretical case only in that
I haven't implemented the specific combination of scripting the
animations and the markup, but work with me here
* Take a form that has been processed with some validation error
conditions met
* Use CSS class "error" to mark some specific text elements your
favorite shade of red
* Add on of those fancy "somethings changed here" javascript animations
the AJAXy kids love to use
And you have something like this (please forgive markup errors):
Some information was missing. Please fill out the
entire form
Who are you?
Name: />
Favorite Sports (Pick at least one)
Hockey
for="football">Football
for="baseball">Baseball
And a script that on document load (or some other event based trigger
like a fresh validation attempt.. point being the event listener is
elsewhere) that would grab all of the elements in the page with class
"error" and give them an animated/fading border and background for a
few seconds.
Just the first case that popped into my head. Another rough case would
be a file serving application[1] where a "thumbnail" isn't always an
but sometimes a No Preview Available or perhaps a
flash or sound player (or maybe in the future SVG) but in all
cases the element used is categorized by class="preview".
if pressed I could probably look over some old work with scripting
animations/dhtml and find cases where this would also be very helpful,
but they would be less applicable to your typical html usage.
[1] in an app like this one: http://files.lussumo.com/
--
[ Chris Casciano ]
[ [EMAIL PROTECTED] ] [ http://placenamehere.com ]
Jim Ley wrote:
On 2/3/06, Michel Fortin <[EMAIL PROTECTED]> wrote:
Le 2006-02-03 à 09:30, Jim Ley a écrit :
So to generalize the use case, when I want to attach an event to a
child element or an element linked by any other mean to the element
having that class, I can't use addEventListenerToClass.
So this shows that addEventListenerToCSSSelector is really what you
want so you can attach it to A's that are children of the class
doesn't it?
I don't agree with that, there are many valid use cases for a
getElementsByClassName and while it is true that many of them are event
related, that doesn't mean they all are. For example, if an author
marked up dates in their document like this (due to the lack of a date
element)
2006-02-03T01:30Z
A script could get all the elements with the class name of "date", parse
it and modify it to the user's preferred time zone and format. So, for
example, the script could change it to this for a typical Australian user:
03 Feb 2006 12:30 (local time)
Whereas, an American user may get this instead:
Feb 02, 2006 20:30 (local time)
Regarding the idea for addEventListenerToSelector, while I don't think
it should be implemented as a function like that, the idea of attaching
events based on a selector is quite reasonable. What if there was a way
to declaratively attach events to elements in the same way that the
on[event] attributes in HTML do, but with same level of abstraction
provided by CSS using selectors. It could even be used for some the
event-related use cases for getElementsByClassName, simply by using a
class selector.
Of course, there is XML Events, which also seems to be declarative, but
from what I know about it (not very much), it seems to be limited to
specifying IDs of the target/observer elements and putting IDs on every
target element is not always convenient; or otherwise embedding the
event attributes (like ev:handler, ev:event, etc) throughout the markup,
just like with the HTML on[event] attributes.
There's also IE's behaviours using HTCs and the proprietary 'behavior'
property in CSS, but it seems rather complex and HTCs look quite messy
(they seem to be a weird mixture of proprietary HTML with some XML
syntax), although perhaps they were on the right track with the concept
of making them declarative.
For example, using this CSS-like syntax (but it's not CSS).
selector {
event-name: function();
}
For example, using a real (rather nifty) javascript example, called Lightbox
http://www.huddletogether.com/projects/lightbox/
The basic way in which this works is to look for A elements with a rel
attribute containing a "lightbox" value. For everyone it finds, it
attaches a click event handler, which then handles all the funky
animation and loading of the image within the same page.
Using the above css-like syntax, that could be achieved by doing this:
a[rel=lightbox] {
click: showLightbox(attr(href), attr(title));
}
I know it's not an extremely well thought out idea, it's just a bit of
brainstorming, but it could always be improved. It also seems to be a
little out of scope for the WhatWG.
--
Lachlan Hunt
http://lachy.id.au/
On 1/30/06, Ric Hardacre <[EMAIL PROTECTED]> wrote:
> hello, i'm an asp developer in the uk and have a couple of
> suggestions... no doubt selfishly to make my life easier one day :-)
> these could probably do with their own threads if they're deemed worthy
> of discussion but let's just throw them out there:
>
> 1. form tag:
> send="all" , (default, send all fields to server in get/post)
> send="changed" , only send hidden fields and fields that have been
> changed by the user
Agreed, this is useful. Details of the implications of this, however,
I am not so sure of.
> the idea being that if i'm running a datagrid then there's no point
> sending a ton of data back and forth if the user only edits a couple of
> cells. but the hidden form data will still be needed in any case so i
> can still connect the data sent to the user who sent it!
>
> 2. select tag:
> selectedindex="[num]"
Agreed. This would be very useful.
> implicitly set the selected index, instead of having to parse all the
> option tags and insert a "selected" string, much easier to bind to
> server side data, an invalid value (such as -1 or greater than the
> number of option tags) would mean none are selected. this would
> obviously not apply to multiple-selects
>
> 3. input tags:
> validate="[regex]"
See: http://whatwg.org/specs/web-forms/current-work/#the-pattern
--
Brad Fults
NeatBox
On 2/3/06, Jim Ley <[EMAIL PROTECTED]> wrote:
> On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> > Jim Ley wrote:
> > > Yes, but they're all using it to attach events to every one of the
> > > class, which is why you have to look at use cases, the reason they're
> > > doing it is not because getElementsByClassName is missing, but because
> > > addEventListenerToClass or -moz-binding etc. are missing.
> >
> > But why implement addEventListenerToClass() when you could implement
> > getElementsByClassName(), which has a far more general utility? As soon
> > as a single non-event-listener-related application comes along, you find
> > you've implemented the wrong thing.
>
> Er, no the use case people have is that they want everything that has
> class X to respond to a particular event, if you model that with
> getElementsByClassName then you cannot change a class on an element
> and have it respond, without re-running the attachment, and manage the
> fact you've already attached it to some classes etc.
I can't believe that you're so insistent upon this extremely narrow
set of use cases and that there aren't any other popular use cases for
getElementsByClassName().
If there are no use cases for this function then what are the use
cases for getElementById()? I suppose this should be
addEventToElementById()? How about getElementsByTagName()? That one
too, eh?
The point of getElementsByClassName() is superior control over the
DOM. Where getElementById() falls short by only returning one element
and getElementsByTagName() falls short by only returning one,
document-mandated type of element, getElementsByClassName() gives the
author the control to collect arbitrary sets of elements which all
share the same class or set of classes.
> It does not simplify the situation at all. It can also only happen
> once the element with the class is available, that fails the
> consistency of UI axiom, since your element will respond differently
> after the function has run.
Completely irrelevant. See getElementById() or getElementsByTagName().
The requirement for a loaded document is to be expected when one
wishes to manipulate the constructed DOM from that document.
> > Here's a use case, then: the about:license document I just checked into
> > the Mozilla codebase. When the page is called with the spelling
> > "about:licence" instead of "about:license", I use
> > getElementsByClassName() to search for elements with the class
> > "correctme", and do a search and replace within them to correct the
> > spelling. However, I can't correct it everywhere as I shouldn't be
> > mutating legal documents. But I can do it in commentary, titles,
> > contents and so on.
>
> What an extremely odd use case, but it is at least a use case,
> thankyou. I'm not sure it's really one significant enough to warrant
> implementing it given the large number of other methods of achieving
> the same spelling correction. Especially as the majority of them can
> be done without requiring javascript at all.
>
> Jim.
>
So here's a shiny use case for us all:
I want my designer to be able to specify an arbitrary set of elements
in the markup for a web app that are to be "widgets". Now if the web
app is sent out to a client that supports function X, I want to
construct this X-widget around each of the elements in the set
previously defined.
The construction of each X-widget also depends on various other
rendered states of the web app as well as the support level of the
client. In order to support sane and graceful degradation, the markup
for the app will be sent down in its barest form and the widgets will
be added via JS on the client side, taking the constraints into
consideration and acting accordingly.
It is obvious here that getElementsByClassName() is a perfect fit for
the NodeList that I want to manipulate and much better than iterating
over every node in the document or something else to that effect.
This case is not restricted to event-driven behavior in the least, yet
leverages the power of getElementsByClassName() superbly.
Now that we can get past "why" we're specifying such a function, I
feel the need to reiterate the constraints on its specification, as
some have apparently forgotten them or neglected to read the
discussion in its entirety:
1. getElementsByClassName() must be host language agnostic. That is,
it must work with HTML, XHTML, SVG, MathML, and any other markup
languages which are approved for its use. Assumptions like "class
names cannot contain a space" may be ones that we can't make in light
of this requirement (IMHO).
2. getElementsByClassName() must be *binding language* agnostic. That
is, we cannot assume that it will only be used in JS. It should be
designed, as with all of the other DOM functions to my knowledge,
without special features which are specific to any one binding
language. That said, I believe a variable number of arguments is
completely out.
3. getElementsByClassName() should succeed as expecte
Gervase Markham wrote:
Brad Fults wrote:
I see this is still an open issue[1]. Is this now implemented as #1
(space-delimited class names to match)?
I suggest either going with the space-delimited approach (as it's
language-agnostic and well-defined at least) or with Aankhen's
suggestion of a single array argument.
Musing...
If you have:
Fred
Barney
Wilma
which should be picked up by getElementsByClassName("foo bar")?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red. so
the distinction between class="foo bar" and class="bar foo" is real, not
merely syntactic. a search for "foo" should pick up either but a search
for "foo bar" should only find the first, so IMO a comma seperated list
would be better in that respect:
1. getElementsByClassName("foo bar,foo tang,woo tang")
this use of explicit class matching could, however be considered an
"advanced" use of the function, with emphasis on the simpler:
2. getElementsByClassName("bar,tang")
as an aside this then yields another level of even more complex
behavioural possibilities:
3. getElementsByClassName("foo>bar")
though in this example the ClassName, having not being explicitly
declared in the markup. is not what is being selected, but a derived
inheritance, perhaps warranting a new function
4. getElementsByRelationship("foo:firstChild")
what this would mean, therefore is that
5.
would be selected by example 1. whereas
6.
would be selected by example 3. specifically and example 4. if the
designer wanted to make assumptions about the resuting DOM
Ric
hello, i'm an asp developer in the uk and have a couple of
suggestions... no doubt selfishly to make my life easier one day :-)
these could probably do with their own threads if they're deemed worthy
of discussion but let's just throw them out there:
1. form tag:
send="all" , (default, send all fields to server in get/post)
send="changed" , only send hidden fields and fields that have been
changed by the user
the idea being that if i'm running a datagrid then there's no point
sending a ton of data back and forth if the user only edits a couple of
cells. but the hidden form data will still be needed in any case so i
can still connect the data sent to the user who sent it!
2. select tag:
selectedindex="[num]"
implicitly set the selected index, instead of having to parse all the
option tags and insert a "selected" string, much easier to bind to
server side data, an invalid value (such as -1 or greater than the
number of option tags) would mean none are selected. this would
obviously not apply to multiple-selects
3. input tags:
validate="[regex]"
implicitly set a regular expression to which the inputted data must
conform, so a value of regex="([0-9]*)\.[0-9][0-9]" would (assuming my
top-of-the-head regexp isn't totally fubar) only allow the user to enter
a number in currency format (any number of digits, a full stop and two
digits). though how to enforce it is another question, leave it up to
the agent? simply not respond if any other key was pressed? would it
need a hint to fill out default formatting too, appending the .00 if it
is left off, etc.
just a few, i'm eager to get web 2.0 forms into a much more usefull
state than at present, and to not have to rely so much on javascript and
css hacking to get things done!
ric hardacre
Hi,
From: Michel Fortin <[EMAIL PROTECTED]>
I have a some markup like this:
Tab 1
Tab 2
...
...
With the help of a style sheet, the script transforms this into some sort
of tab view. It search for each div of class "pane". It looks for links
pointing to each of these div elements and attach an event to each so that
when you click on the link it shows the pane (and hides other panes).
You could do this with the following CSS:
.pane:not(:target) { display:none; }
Thus getElementsByClassName() is not needed for this use case.
Regards,
Simon Pieters
Le 2006-02-03 à 11:37, Jim Ley a écrit :
On 2/3/06, Michel Fortin <[EMAIL PROTECTED]> wrote:
Le 2006-02-03 à 09:30, Jim Ley a écrit :
So to generalize the use case, when I want to attach an event to a
child element or an element linked by any other mean to the element
having that class, I can't use addEventListenerToClass.
So this shows that addEventListenerToCSSSelector is really what you
want so you can attach it to A's that are children of the class
doesn't it?
Not in the case of my last mail: 'A' elements can be everywhere on
the page (in this specific example, they are in some sort of table of
contents at the top).
I would still need getElementsByClassNames to first get the div
elements. Then, for each of these div elements I'd have to use
addEventListenerToCSSSelector with rule "a[href='#{div id}']", where
{div id} is replaced by the id attribute of the div. If I really
wanted to, I could have been listening for new DOM elements of class
"pane" and, for each of them, add an event handler to the
corresponding A elements.
Anyway, I just wanted to show one valid use for a
getElementsByClassNames function and (maybe) for more advanced
functions (like those with CSS selectors). All these functions would
accomplish however can already be achieved by looping over the
elements, so it's not like they are absolutely necessary. And you
would need something a lot more powerful to handle my complex case
with only one function call (maybe addEventListenerToXPath?) which
I'm not asking for because it's probably overkill almost all of the
time. Obviously a line has to be drawn somewhere.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Blanchard, Todd wrote:
Any markup that causes a browser to automatically clone a node will
be non-conformant and will be flagged as erroneous by a validator.
You are assuming that validators run javascript - they generally
don't.
I'm well aware that validators don't run JavaScript and I'm talking
about a case where they don't even need to. Given this markup that will
cause a node to be cloned by the Adoption Agency Algorithm:
foobar
The validator *will* flag that as an error and, according to the
algorithm, it will also cause duplicate IDs, which is what we were
discussing.
The only case that won't happen is if that markup is written as a result
of document.write() or innerHTML.
--
Lachlan Hunt
http://lachy.id.au/
>Any markup that causes a browser to automatically clone a node will be
>non-conformant and
>will be flagged as erroneous by a validator.
You are assuming that validators run javascript - they generally don't. (I'm
hoping to add it to Scrutinizer http://www.blackbagops.net/seaside/html ) but
that would make it unique in the world of validators.
Browser makers can't just punt on this issue - you have to help the developers
more. As it is now we spend way too much time writing little probe programs to
reverse engineer browser behavior to figure out why our nifty AJAX apps don't
work.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt
Sent: Friday, February 03, 2006 3:21 AM
To: Gervase Markham
Cc: whatwg
Subject: Re: [whatwg] Update to the Adoption Agency Algorithm
Gervase Markham wrote:
> Lachlan Hunt wrote:
>> Errors caused by the result of duplicate IDs either in the markup or
>> indirectly as a result of badly nested elements can be fixed by a
>> quick visit to the validator (or other conformance tool) or by making
>> use of any or all of those tools I mentioned above.
>
> It's much harder to spot them when they are dynamically generated by
> e.g. a cloneNode operation. You can't submit your browser's DOM tree
> to the validator...
Any markup that causes a browser to automatically clone a node will be
non-conformant and will be flagged as erroneous by a validator. Of course it
won't say duplicate ID, but it will give errors about badly nested elements.
--
Lachlan Hunt
http://lachy.id.au/
On 2/3/06, Michel Fortin <[EMAIL PROTECTED]> wrote:
> Le 2006-02-03 à 09:30, Jim Ley a écrit :
> So to generalize the use case, when I want to attach an event to a
> child element or an element linked by any other mean to the element
> having that class, I can't use addEventListenerToClass.
So this shows that addEventListenerToCSSSelector is really what you
want so you can attach it to A's that are children of the class
doesn't it?
Jim.
Le 2006-02-03 à 09:30, Jim Ley a écrit :
Yes, but they're all using it to attach events to every one of the
class, which is why you have to look at use cases, the reason they're
doing it is not because getElementsByClassName is missing, but because
addEventListenerToClass or -moz-binding etc. are missing.
It's the classic mistake of looking at making the workarounds easier,
when you should be looking at making the underlying use easier.
I have been following this list for sometime and did not have much to
say until now. But I have a use case for this function which cannot
work by simply using addEventListenerToClass. And that's a real
working use case for a web application I'm working on, nothing
hypothetical.
I have a some markup like this:
Tab 1
Tab 2
...
...
With the help of a style sheet, the script transforms this into some
sort of tab view. It search for each div of class "pane". It looks
for links pointing to each of these div elements and attach an event
to each so that when you click on the link it shows the pane (and
hides other panes).
- - -
So to generalize the use case, when I want to attach an event to a
child element or an element linked by any other mean to the element
having that class, I can't use addEventListenerToClass.
Now, with that particular example in mind, something like
getElementsByHref('tab1') could be useful too, but surely you can't
have a function for each html attribute.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> As an aside, I'd be interested in hearing about any JavaScript-less
> methods (that don't involve marking up every instance of the word; this
> doesn't work, as some are e.g. in href attributes.)
I was imaging your build environment making similar sort of changes to
your script and the two resulting copies existing.
Jim.
Jim Ley wrote:
> Er, no the use case people have is that they want everything that has
> class X to respond to a particular event, if you model that with
> getElementsByClassName then you cannot change a class on an element
> and have it respond, without re-running the attachment, and manage the
> fact you've already attached it to some classes etc.
Oh, I get it. Sorry - I misunderstood.
> What an extremely odd use case, but it is at least a use case,
> thankyou. I'm not sure it's really one significant enough to warrant
> implementing it given the large number of other methods of achieving
> the same spelling correction. Especially as the majority of them can
> be done without requiring javascript at all.
As an aside, I'd be interested in hearing about any JavaScript-less
methods (that don't involve marking up every instance of the word; this
doesn't work, as some are e.g. in href attributes.)
Gerv
On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> > Yes, but they're all using it to attach events to every one of the
> > class, which is why you have to look at use cases, the reason they're
> > doing it is not because getElementsByClassName is missing, but because
> > addEventListenerToClass or -moz-binding etc. are missing.
>
> But why implement addEventListenerToClass() when you could implement
> getElementsByClassName(), which has a far more general utility? As soon
> as a single non-event-listener-related application comes along, you find
> you've implemented the wrong thing.
Er, no the use case people have is that they want everything that has
class X to respond to a particular event, if you model that with
getElementsByClassName then you cannot change a class on an element
and have it respond, without re-running the attachment, and manage the
fact you've already attached it to some classes etc.
It does not simplify the situation at all. It can also only happen
once the element with the class is available, that fails the
consistency of UI axiom, since your element will respond differently
after the function has run.
> Here's a use case, then: the about:license document I just checked into
> the Mozilla codebase. When the page is called with the spelling
> "about:licence" instead of "about:license", I use
> getElementsByClassName() to search for elements with the class
> "correctme", and do a search and replace within them to correct the
> spelling. However, I can't correct it everywhere as I shouldn't be
> mutating legal documents. But I can do it in commentary, titles,
> contents and so on.
What an extremely odd use case, but it is at least a use case,
thankyou. I'm not sure it's really one significant enough to warrant
implementing it given the large number of other methods of achieving
the same spelling correction. Especially as the majority of them can
be done without requiring javascript at all.
Jim.
Jim Ley wrote:
> Yes, but they're all using it to attach events to every one of the
> class, which is why you have to look at use cases, the reason they're
> doing it is not because getElementsByClassName is missing, but because
> addEventListenerToClass or -moz-binding etc. are missing.
But why implement addEventListenerToClass() when you could implement
getElementsByClassName(), which has a far more general utility? As soon
as a single non-event-listener-related application comes along, you find
you've implemented the wrong thing.
Here's a use case, then: the about:license document I just checked into
the Mozilla codebase. When the page is called with the spelling
"about:licence" instead of "about:license", I use
getElementsByClassName() to search for elements with the class
"correctme", and do a search and replace within them to correct the
spelling. However, I can't correct it everywhere as I shouldn't be
mutating legal documents. But I can do it in commentary, titles,
contents and so on.
Gerv
Jim Ley wrote:
On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
Jim Ley wrote:
the document of course shows no use cases at all.
Is there some doubt that the ability to tag an arbitrary set of elements
and later easily get an array of those elements is a useful feature for
web development?
I've yet to hear of an actual reason to do so, people keep saying it
seems useful...
If you would like use cases, I present all of the web pages currently
using a JS implementation of getElementsByClassName based on
getElementsByTagName("*") and some manual class name inspection logic.
Yes, but they're all using it to attach events to every one of the
class, which is why you have to look at use cases, the reason they're
doing it is not because getElementsByClassName is missing, but because
addEventListenerToClass or -moz-binding etc. are missing.
It's the classic mistake of looking at making the workarounds easier,
when you should be looking at making the underlying use easier.
Jim.
Hmm, i've used getElementsByTagName in the past couple of days,
specifically to walk a table row's data cells to retrieve and write
data. This was part of a HTML4 datagrid implimentation and the first
time i'd found a use for said function. Having this alongside
getElementById but missing out getElementsByClassName seems
short-sighted to me. There may be a use we havent thought of yet, and it
seems like a logical function to round out the family, rather than bloat.
Ric
On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> > the document of course shows no use cases at all.
>
> Is there some doubt that the ability to tag an arbitrary set of elements
> and later easily get an array of those elements is a useful feature for
> web development?
I've yet to hear of an actual reason to do so, people keep saying it
seems useful...
> If you would like use cases, I present all of the web pages currently
> using a JS implementation of getElementsByClassName based on
> getElementsByTagName("*") and some manual class name inspection logic.
Yes, but they're all using it to attach events to every one of the
class, which is why you have to look at use cases, the reason they're
doing it is not because getElementsByClassName is missing, but because
addEventListenerToClass or -moz-binding etc. are missing.
It's the classic mistake of looking at making the workarounds easier,
when you should be looking at making the underlying use easier.
Jim.
Lachlan Hunt wrote:
> Ric Hardacre wrote:
>> Gervase Markham wrote:
>>> If you have:
>>>
>>> Fred
>>> Barney
>>> Wilma
>>>
>>> which should be picked up by getElementsByClassName("foo bar")?
>>
>> this also raises the possibility of some confusion as the order of
inheritance is important:
>>
>> foo
>> {
>>color: red;
>> }
>>
>> bar
>> {
>>color: blue;
>> }
>>
>> in the quoted example Fred and Wilma would be blue and barney red.
>
> According to which rules specified in CSS will that be the case?
Given that CSS (assuming you meant to use class selectors instead), all
three markup samples will be blue. The order of the class names in the
markup is irrelevant. The order of the rules specified in the CSS is
relevant and the latter rule of equal specificity takes precedence.
>
just checked it, i was wrong, oops!
ric
Jim Ley wrote:
>> I know nothing of this "attaching events to a class name" of which you
>> speak. Can you give me a reference to a document or proposal describing it?
>
> It's the one use case described in this mailing list,
>
> See e.g.
> http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-January/005434.html
>
> the document of course shows no use cases at all.
Is there some doubt that the ability to tag an arbitrary set of elements
and later easily get an array of those elements is a useful feature for
web development?
If you would like use cases, I present all of the web pages currently
using a JS implementation of getElementsByClassName based on
getElementsByTagName("*") and some manual class name inspection logic.
Gerv
On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> > Rather than talk about technical details, can be talk about the actual
> > use cases please, working groups keep on creating things which need
> > implementing, testing etc. without once giving the use case. This
> > thread is now 21 messages old and there's not one use case which is
> > fulfilled by a getElementsByClassName. All the ones suggested are
> > fulfilled by the ability to attach events to a particular class name.
>
> I thought we were discussing it because it was in the spec? :-)
Firstly it has to justify its inclusion in the spec. Until we know
what it's _for_ how can we possibly design it? Or comment on any
individual design?
> I know nothing of this "attaching events to a class name" of which you
> speak. Can you give me a reference to a document or proposal describing it?
It's the one use case described in this mailing list,
See e.g.
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-January/005434.html
the document of course shows no use cases at all.
Jim.
Ric Hardacre wrote:
Gervase Markham wrote:
If you have:
Fred
Barney
Wilma
which should be picked up by getElementsByClassName("foo bar")?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red.
According to which rules specified in CSS will that be the case? Given
that CSS (assuming you meant to use class selectors instead), all three
markup samples will be blue. The order of the class names in the markup
is irrelevant. The order of the rules specified in the CSS is relevant
and the latter rule of equal specificity takes precedence.
--
Lachlan Hunt
http://lachy.id.au/
On Fri, 03 Feb 2006 15:39:26 +0200, Gervase Markham <[EMAIL PROTECTED]>
wrote:
ROBO Design wrote:
<...>
Well, not according to the current spec, which says:
1. Should it return *all* elements which have *all* the class names
wanted?
this one. Of course, you may disagree with the spec.
I'd personally like this:
getElementsByClassNames(["array", "of","class","names"], bool any)
if any = true then get all elements that have any of the class names
provided, otherwise get all elements that have *all* class names provided.
4. Should the order matter?
No, because class name ordering does not matter in the source or in CSS.
True, but Ric has made an interesting point about the order of class
names, which does actually matter.
Do we want getElementsByClassNames() to work as "the final page render" or
just "logically"? I don't even know how to say it, but here's the idea:
You have the foo bar example provided by Ric, in which Fred and Wilma
paragraphs are blue, and Barney is red.
Do you want to be able to make the distinction between Fred, Wilma and
Barney with getElementsByClassNames(["foo", "bar"]) ? If the order doesn't
matter ... you can't.
This is getting way beyond control.
<...>
That turns the function into something which is dependent on CSS rather
than just dependent on the markup language. That is a reasonably large
change in scope IMO.
True.
--
http://www.robodesign.ro
ROBO Design - We bring you the future
On Fri, 03 Feb 2006 15:31:37 +0200, Ric Hardacre <[EMAIL PROTECTED]>
wrote:
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red. so
the distinction between class="foo bar" and class="bar foo" is real, not
merely syntactic. a search for "foo" should pick up either but a search
for "foo bar" should only find the first, so IMO a comma seperated list
would be better in that respect:
1. getElementsByClassName("foo bar,foo tang,woo tang")
this use of explicit class matching could, however be considered an
"advanced" use of the function, with emphasis on the simpler:
2. getElementsByClassName("bar,tang")
as an aside this then yields another level of even more complex
behavioural possibilities:
3. getElementsByClassName("foo>bar")
though in this example the ClassName, having not being explicitly
declared in the markup. is not what is being selected, but a derived
inheritance, perhaps warranting a new function
4. getElementsByRelationship("foo:firstChild")
what this would mean, therefore is that
5.
would be selected by example 1. whereas
6.
would be selected by example 3. specifically and example 4. if the
designer wanted to make assumptions about the resuting DOM
Ric
This is way too wild :).
A comma separated list, or any list separated by any other character can't
be used. The reason has been over-stated (search the mailing list):
basically who what if some other styling language defines that class names
can contain the space char, or the comma char?
AFAIK, Ian said that something like getElementsCSSselector() is something
for the CSS WG from W3C. Defining getElementsByRelationship() would
already "touch" that subject. He only wants to define
getElementsByClassNames().
--
http://www.robodesign.ro
ROBO Design - We bring you the future
ROBO Design wrote:
> I believe there's some disagreement on what is this function supposed to
> do.
Well, not according to the current spec, which says:
> 1. Should it return *all* elements which have *all* the class names wanted?
this one. Of course, you may disagree with the spec.
> 4. Should the order matter?
No, because class name ordering does not matter in the source or in CSS.
> I also believe this function will always be confusing, no matter what.
> To drop all confusion just rename it to getElementsByCSSselector() and
> you get the exact idea to as what you are supposed to provide as an
> argument (if you know CSS). Yet, this is something Ian Hickson said is
> beyond the purpose of WHATWG.
That turns the function into something which is dependent on CSS rather
than just dependent on the markup language. That is a reasonably large
change in scope IMO.
CSS selector parsers in JS have been written (I believe Dean Edwards has
one); but such things would be much easier to implement if you had
getElementsByClassNames() to go with getElementsById().
Gerv
On Fri, 03 Feb 2006 15:24:19 +0200, Shadow2531 <[EMAIL PROTECTED]>
wrote:
Do we need to be able to pass an array of arbitrary classnames?
burnout426
Yes.
--
http://www.robodesign.ro
ROBO Design - We bring you the future
On Fri, 03 Feb 2006 14:34:14 +0200, Gervase Markham <[EMAIL PROTECTED]>
wrote:
Shadow2531 wrote:
<...>
This seems like a sensible change. Call it getElementsByClassNames()
would make it obvious that if you supply multiple class names, you get
only elements with all those names. And it would be a reasonably obvious
reduction that if you just supply a single name, you would get all
elements which had that one class name.
So we've ended up with:
elem.getElementsByClassNames("foo");
and
elem.getElementsByClassNames(["foo", "bar"]);
or
elem.getElementsByClassNames("foo", "bar");
or both.
Are there similar functions in the DOM at the moment which can take
multiple arguments? Do you pass an array or multiple individual
arguments, or can you do both?
Gerv
I believe there's some disagreement on what is this function supposed to
do.
Example:
paragraph 1
paragraph 2
paragraph 3
paragraph 4
1. Should it return *all* elements which have *all* the class names wanted?
getElementsByClassNames(["foo", "sample"])
returning: p1, p2
2. Should it return *all* elements which have *only* the class names
wanted?
getElementsByClassNames(["sample", "foo"])
returning: p2
3. Should it return *all* elements which have *any* of the class names
wanted?
getElementsByClassNames(["sample", "foo"])
returning: p1, p2, p3, p4
4. Should the order matter?
It is clear that getElementsByClassNames("foo bar") can't be an option,
because the reasons have already been over-stated.
Now... what's left to discuss: what is the function supposed to do? And
... to pick one of the following two methods of giving the list of class
names:
getElementsByClassNames("foo", "bar")
or...
getElementsByClassNames(["foo", "bar"])
As I previously stated, I preffer the latter method because we must be
able to provide an arbitrary number of class names without using the
(AFAIK deprecated) eval().
I also believe this function will always be confusing, no matter what. To
drop all confusion just rename it to getElementsByCSSselector() and you
get the exact idea to as what you are supposed to provide as an argument
(if you know CSS). Yet, this is something Ian Hickson said is beyond the
purpose of WHATWG.
--
http://www.robodesign.ro
ROBO Design - We bring you the future
Jim Ley wrote:
> Rather than talk about technical details, can be talk about the actual
> use cases please, working groups keep on creating things which need
> implementing, testing etc. without once giving the use case. This
> thread is now 21 messages old and there's not one use case which is
> fulfilled by a getElementsByClassName. All the ones suggested are
> fulfilled by the ability to attach events to a particular class name.
I thought we were discussing it because it was in the spec? :-)
I know nothing of this "attaching events to a class name" of which you
speak. Can you give me a reference to a document or proposal describing it?
Gerv
On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> This seems like a sensible change. Call it getElementsByClassNames()
> would make it obvious that if you supply multiple class names, you get
> only elements with all those names. And it would be a reasonably obvious
> reduction that if you just supply a single name, you would get all
> elements which had that one class name.
>
> So we've ended up with:
>
> elem.getElementsByClassNames("foo");
> and
>
> elem.getElementsByClassNames(["foo", "bar"]);
> or
> elem.getElementsByClassNames("foo", "bar");
> or both.
O.K.
> Are there similar functions in the DOM at the moment which can take
> multiple arguments? Do you pass an array or multiple individual
> arguments, or can you do both?
For getElementsByClassNames( var )
var could be an object or a string. The function could use typeof to
check which one it is. If it's an object, the function could check its
elements to make sure they are strings. So, you could pass a list or a
string.
For getElementsByClassNames("string1", "string2", "string3",
"stringN"), the function has an 'arguments' array that will output
"string1,string2,string3,stringN".
So, it should be possible to support, passing 1 or more strings, or 1
or more arrays, or a mixture. We don't want to go crazy though.
I'd prefer to just be able to pass one or more strings and keep it at
that. However, if you had an array of strings, you'd then be forced to
build a call to getElementsByClassNames() via eval() or use some other
method.
Do we need to be able to pass an array of arbitrary classnames?
burnout426
Gervase Markham wrote:
> Brad Fults wrote:
>> I see this is still an open issue[1]. Is this now implemented as #1
>> (space-delimited class names to match)?
>>
>> I suggest either going with the space-delimited approach (as it's
>> language-agnostic and well-defined at least) or with Aankhen's
>> suggestion of a single array argument.
>
> Musing...
>
> If you have:
>
> Fred
> Barney
> Wilma
>
> which should be picked up by getElementsByClassName("foo bar")?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red. so
the distinction between class="foo bar" and class="bar foo" is real, not
merely syntactic. a search for "foo" should pick up either but a search
for "foo bar" should only find the first, so IMO a comma seperated list
would be better in that respect:
1. getElementsByClassName("foo bar,foo tang,woo tang")
this use of explicit class matching could, however be considered an
"advanced" use of the function, with emphasis on the simpler:
2. getElementsByClassName("bar,tang")
as an aside this then yields another level of even more complex
behavioural possibilities:
3. getElementsByClassName("foo>bar")
though in this example the ClassName, having not being explicitly
declared in the markup. is not what is being selected, but a derived
inheritance, perhaps warranting a new function
4. getElementsByRelationship("foo:firstChild")
what this would mean, therefore is that
5.
would be selected by example 1. whereas
6.
would be selected by example 3. specifically and example 4. if the
designer wanted to make assumptions about the resuting DOM
Ric
On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> This seems like a sensible change. Call it getElementsByClassNames()
> would make it obvious that if you supply multiple class names, you get
> only elements with all those names. And it would be a reasonably obvious
> reduction that if you just supply a single name, you would get all
> elements which had that one class name.
Rather than talk about technical details, can be talk about the actual
use cases please, working groups keep on creating things which need
implementing, testing etc. without once giving the use case. This
thread is now 21 messages old and there's not one use case which is
fulfilled by a getElementsByClassName. All the ones suggested are
fulfilled by the ability to attach events to a particular class name.
Jim.
Shadow2531 wrote:
> O.K. Then, it should be getElementByClassName*s*() where you have
> have 1 or more classname arguments. If you pass more than 1 class
> name, both class names have to be present in the classname attribute
> for the element to match.
This seems like a sensible change. Call it getElementsByClassNames()
would make it obvious that if you supply multiple class names, you get
only elements with all those names. And it would be a reasonably obvious
reduction that if you just supply a single name, you would get all
elements which had that one class name.
So we've ended up with:
elem.getElementsByClassNames("foo");
and
elem.getElementsByClassNames(["foo", "bar"]);
or
elem.getElementsByClassNames("foo", "bar");
or both.
Are there similar functions in the DOM at the moment which can take
multiple arguments? Do you pass an array or multiple individual
arguments, or can you do both?
Gerv
On 2/3/06, Shadow2531 <[EMAIL PROTECTED]> wrote:
> O.K. Then, it should be getElementByClassName*s*() where you have
> have 1 or more classname arguments. If you pass more than 1 class
> name, both class names have to be present in the classname attribute
> for the element to match.
I just to be clear. If you do getElementByClassName("this", "that",
"other"), should that only match elements that have all those in their
class attribute value or does it match any element that has "this" and
any element that has "that" and any element that has "other"?
I just want to be sure on the intended behavior.
burnout426
On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Shadow2531 wrote:
> > I just threw them together as a proof of concept, but I have no doubt
> > that the class attribute value should be a space separated list of
> > classnames and the getElementByClassName function should split up the
> > class attribute value into an array and then search for the class name
> > to see if there's a match (Or use regex to be simpler). I also added a
> > case insensitve search option.
>
> IMO there should be no option; if class names are defined as
> case-insensitive, we should search case-insensitively, and if they
> aren't, we shouldn't.
O.K. agreed.
> > As the case above, getElementByClassName("foo bar") doesn't make sense
> > to me because there are 2 class names in there and it's
> > getElementByClassName, not getElementsByClassName*s*().
> >
> > In getElementByClassName("foo bar") , "foo bar" should be normalized
> > "foo" and therefore match all 3 because they all have "foo" in the
> > class attribute value.
>
> I think this behaviour would violate the rule of least surprise. Better
> behaviour would be to match nothing, treating "foo bar" as a single
> class name. Rationale: just because HTML doesn't allow class names with
> spaces doesn't mean no other languages do, and the coding error would be
> much easier to spot (you'd get no elements at all).
Point taken. That would be fine. I think I now agree with you about
not normalizing an argument with spaces.
> > getElementsByClassName*s*() should be a separate function and I agree,
> > getElementsByClassNames*s*("foo", "bar") would be great if possible.
>
> I also think it's not ideal to have two functions with such similar names.
O.K. Then, it should be getElementByClassName*s*() where you have
have 1 or more classname arguments. If you pass more than 1 class
name, both class names have to be present in the classname attribute
for the element to match.
I'm just being picky here though, but getElementByClassName() implies
only one classname where as getElementByClassNames() implies one or
more. Although as long as you know what the function does, that hardly
matters, but I bring it up anyway. :)
burnout426
Gervase Markham wrote:
Lachlan Hunt wrote:
Errors caused by the result of duplicate IDs either in the markup or
indirectly as a result of badly nested elements can be fixed by a quick
visit to the validator (or other conformance tool) or by making use of
any or all of those tools I mentioned above.
It's much harder to spot them when they are dynamically generated by
e.g. a cloneNode operation. You can't submit your browser's DOM tree to
the validator...
Any markup that causes a browser to automatically clone a node will be
non-conformant and will be flagged as erroneous by a validator. Of
course it won't say duplicate ID, but it will give errors about badly
nested elements.
--
Lachlan Hunt
http://lachy.id.au/
Shadow2531 wrote:
> I just threw them together as a proof of concept, but I have no doubt
> that the class attribute value should be a space separated list of
> classnames and the getElementByClassName function should split up the
> class attribute value into an array and then search for the class name
> to see if there's a match (Or use regex to be simpler). I also added a
> case insensitve search option.
IMO there should be no option; if class names are defined as
case-insensitive, we should search case-insensitively, and if they
aren't, we shouldn't.
> As the case above, getElementByClassName("foo bar") doesn't make sense
> to me because there are 2 class names in there and it's
> getElementByClassName, not getElementsByClassName*s*().
>
> In getElementByClassName("foo bar") , "foo bar" should be normalized
> "foo" and therefore match all 3 because they all have "foo" in the
> class attribute value.
I think this behaviour would violate the rule of least surprise. Better
behaviour would be to match nothing, treating "foo bar" as a single
class name. Rationale: just because HTML doesn't allow class names with
spaces doesn't mean no other languages do, and the coding error would be
much easier to spot (you'd get no elements at all).
> getElementsByClassName*s*() should be a separate function and I agree,
> getElementsByClassNames*s*("foo", "bar") would be great if possible.
I also think it's not ideal to have two functions with such similar names.
Gerv
On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Musing...
>
> If you have:
>
> Fred
> Barney
> Wilma
>
> which should be picked up by getElementsByClassName("foo bar")?
>
> In the "string split" mode, it would pick up all three. However, I
> suggest that designers might be misled by this interface into thinking
> that it only picks up the first one - which matches exactly.
>
> So I think a multiple-argument interface would remove this possible
> confusion, and make things more obvious than a whitespace-splitting
> interface.
>
> getElementsByClassName("foo", "bar") ideally, but if that's hard, then
> getElementsByClassName(["foo", "bar"]);
>
> So I agree with Brad, I think :-)
>
> Gerv
>
In I wrote
2 prototypes for Opera and Firefox: getElementsByClassName()
and getElementsByClassNameNS()
.
I just threw them together as a proof of concept, but I have no doubt
that the class attribute value should be a space separated list of
classnames and the getElementByClassName function should split up the
class attribute value into an array and then search for the class name
to see if there's a match (Or use regex to be simpler). I also added a
case insensitve search option.
As the case above, getElementByClassName("foo bar") doesn't make sense
to me because there are 2 class names in there and it's
getElementByClassName, not getElementsByClassName*s*().
In getElementByClassName("foo bar") , "foo bar" should be normalized
"foo" and therefore match all 3 because they all have "foo" in the
class attribute value.
getElementsByClassName*s*() should be a separate function and I agree,
getElementsByClassNames*s*("foo", "bar") would be great if possible.
Just my thoughts,
burnout426
On Fri, 03 Feb 2006 10:48:47 +0200, Gervase Markham <[EMAIL PROTECTED]>
wrote:
Brad Fults wrote:
<...>
Musing...
If you have:
Fred
Barney
Wilma
which should be picked up by getElementsByClassName("foo bar")?
In the "string split" mode, it would pick up all three. However, I
suggest that designers might be misled by this interface into thinking
that it only picks up the first one - which matches exactly.
So I think a multiple-argument interface would remove this possible
confusion, and make things more obvious than a whitespace-splitting
interface.
getElementsByClassName("foo", "bar") ideally, but if that's hard, then
getElementsByClassName(["foo", "bar"]);
So I agree with Brad, I think :-)
Gerv
Hello!
I wouldn't go for:
getElementsByClassName("foo", "bar")
Because that's not ideal in my opinion, since that makes harder to add an
arbitrary number of classes to search for programatically.
I would go for:
getElementsByClassName("foo bar")
But, as you said, that can add some confusion. Therefore, this is ideal:
getElementsByClassName(["foo", "bar"])
--
http://www.robodesign.ro
ROBO Design - We bring you the future
Simon Pieters wrote:
> Browsers could mark all errors as red in view source. In Firefox you can
> select a piece of text and view selection source, which will bring up
> the serialized DOM.
They could (at least, as far as I understand the issue), for XHTML at
least (not HTML5), if they wanted to implement a validating parser
instead of a non-validating one, and improve its error output
sufficiently to be able to make such annotations.
But I've heard no noises about anyone doing that, at least not for
Firefox. Perhaps I'm not listening in the right places. But it seems
like a heck of a lot of effort for relatively little gain.
> Browsers could also log all HTML parse errors in a
> console, just like Firefox currently logs CSS parse errors and XML parse
> errors in the JavaScript Console.
Well, they _could_ - but the immediate effect of that would probably be
to swamp the error console.
Gerv
Hi,
From: Gervase Markham <[EMAIL PROTECTED]>
It's much harder to spot them when they are dynamically generated by
e.g. a cloneNode operation. You can't submit your browser's DOM tree to
the validator...
Browsers could mark all errors as red in view source. In Firefox you can
select a piece of text and view selection source, which will bring up the
serialized DOM. Browsers could also log all HTML parse errors in a console,
just like Firefox currently logs CSS parse errors and XML parse errors in
the JavaScript Console.
Regards,
Simon Pieters
Lachlan Hunt wrote:
> Errors caused by the result of duplicate IDs either in the markup or
> indirectly as a result of badly nested elements can be fixed by a quick
> visit to the validator (or other conformance tool) or by making use of
> any or all of those tools I mentioned above.
It's much harder to spot them when they are dynamically generated by
e.g. a cloneNode operation. You can't submit your browser's DOM tree to
the validator...
Gerv
Brad Fults wrote:
> I see this is still an open issue[1]. Is this now implemented as #1
> (space-delimited class names to match)?
>
> I suggest either going with the space-delimited approach (as it's
> language-agnostic and well-defined at least) or with Aankhen's
> suggestion of a single array argument.
Musing...
If you have:
Fred
Barney
Wilma
which should be picked up by getElementsByClassName("foo bar")?
In the "string split" mode, it would pick up all three. However, I
suggest that designers might be misled by this interface into thinking
that it only picks up the first one - which matches exactly.
So I think a multiple-argument interface would remove this possible
confusion, and make things more obvious than a whitespace-splitting
interface.
getElementsByClassName("foo", "bar") ideally, but if that's hard, then
getElementsByClassName(["foo", "bar"]);
So I agree with Brad, I think :-)
Gerv
50 matches
Mail list logo
