> In this particular case, I think anything that's implemented in all of the
> major browser engines should be an official standard, not just de facto.
Why only in this particular case? :) As a rule that seems like sound
guidance. If it's implemented everywhere, shouldn't you have to make
a pret
@deprecated ? :)
On Tue, Oct 20, 2009 at 8:22 PM, Robert O'Callahan wrote:
> On Wed, Oct 21, 2009 at 4:15 PM, Maciej Stachowiak wrote:
>>
>> I agree. The reason I phrased it as I did was to contrast with my previous
>> remarks. The "children" attribute should be part of a standard, even though
>
On Tue, 20 Oct 2009 23:07:47 +0200, Doug Schepers wrote:
I don't feel too strongly about having both .children and
.childElements, but I do think that .children is a little problematic
for authors... they will always have to check to see if Comment nodes
are included, because of the large
On 10/20/09 11:25 PM, Maciej Stachowiak wrote:
It might be worth adding annotations to the spec to say "this API is
terrible, do not use" and "this API is terrible, do not follow its
design".
Are there any DOM Core methods where those notes would not apply? :-)
Node.parentNode is mostly ok.
On Oct 20, 2009, at 8:22 PM, Robert O'Callahan wrote:
On Wed, Oct 21, 2009 at 4:15 PM, Maciej Stachowiak
wrote:
I agree. The reason I phrased it as I did was to contrast with my
previous remarks. The "children" attribute should be part of a
standard, even though it creates what I think is
On Wed, Oct 21, 2009 at 4:15 PM, Maciej Stachowiak wrote:
> I agree. The reason I phrased it as I did was to contrast with my previous
> remarks. The "children" attribute should be part of a standard, even though
> it creates what I think is a poor design pattern (mix of previous/next and
> index
On Oct 20, 2009, at 8:03 PM, Brian Kardell wrote:
In this particular case, I think anything that's implemented in all
of the
major browser engines should be an official standard, not just de
facto.
Why only in this particular case? :)
I didn't say "only"...
As a rule that seems like s
> I don't feel too strongly about having both .children and .childElements,
> but I do think that .children is a little problematic for authors... they
> will always have to check to see if Comment nodes are included, because of
> the large marketshare for older versions of IE, while .childElements
Hey-
Maciej Stachowiak wrote (on 10/20/09 4:42 PM):
On Oct 18, 2009, at 4:14 AM, Jonas Sicking wrote:
On Sun, Oct 18, 2009 at 12:12 AM, Doug Schepers mailto:schep...@w3.org>> wrote:
So, rather than dwell on an admittedly imperfect spec, I personally
suggest
that we urge WebKit developers to
On Oct 18, 2009, at 4:14 AM, Jonas Sicking wrote:
On Sun, Oct 18, 2009 at 12:12 AM, Doug Schepers
wrote:
So, rather than dwell on an admittedly imperfect spec, I personally
suggest
that we urge WebKit developers to implement .children
and .children.length,
in the anticipation that this wi
Hi, Folks-
John Resig wrote (on 10/18/09 1:50 PM):
They already do. Which casts some amount of doubt on Maciejs argument
that it was too performance heavy to implement in WebKit. :)
Well, it does work in HTML, but not in SVG [1]... which may or may not
be desirable, since .children returns
> They already do. Which casts some amount of doubt on Maciejs argument
> that it was too performance heavy to implement in WebKit. :)
>
> / Jonas
>
> p.s. It also works in Opera and IE.
Yeah, .children is already the de facto standard here - implemented in
every major browser. It's a real shame t
On Sun, Oct 18, 2009 at 12:12 AM, Doug Schepers wrote:
> So, rather than dwell on an admittedly imperfect spec, I personally suggest
> that we urge WebKit developers to implement .children and .children.length,
> in the anticipation that this will be in a future spec but can be useful to
> authors
Hi, Garrett-
Garrett Smith wrote (on 10/17/09 11:06 PM):
It has been so long that I cannot remember (over 8 years since I even
tried using that). It is a useless, pointless method that tells little
about the result of calling, say: getAttribute("checked").
I read Nicholas was struggling with t
14 matches
Mail list logo