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
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
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote:
Musing...
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
In the string split mode, it would pick up all three. However, I
suggest
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
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
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
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
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
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
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
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
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
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
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.
Ric Hardacre wrote:
Gervase Markham wrote:
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
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
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
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.
Lachlan Hunt wrote:
Ric Hardacre wrote:
Gervase Markham wrote:
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
this also raises the possibility of some confusion as the order of
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
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
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
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
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
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
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
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
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
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 :-).
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.
On Thu, 2 Feb 2006, David Hyatt wrote:
BTW, we tried to add span as an inline that should be reopened (like
font and b etc.) and it broke some of our layout tests (snippets of
real-world Web sites). span clearly does not always reopen in WinIE
and Firefox, so for now we are having to
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
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
* 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
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
34 matches
Mail list logo
