W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

Re: [Element Traversal LC] access to element by index

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 03 Apr 2008 10:04:55 -0700
Message-ID: <47F50E37.6050804@sicking.cc>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, "Web APIs WG (public)" <public-webapi@w3.org>

Bjoern Hoehrmann wrote:
> * Jonas Sicking wrote:
>> I'm not following this argument at all. Neither would content that uses 
>> .globalStorage, .forms, .querySelector or anything else that's not in 
>> the SVG Tiny spec.
>> We're trying to make a new API here, of course content that uses that 
>> API isn't going to work in implementations that don't support it.
> Look at this from the perspective of the SVG Working Group. The idea was
> simply that the element traversal feature defined in the SVG Tiny 1.2 CR
> would be put in a separate specification maintained by a separate WG and
> they would replace their definition with a reference to the new spec.
> If we add features to the specification they don't want to require of
> SVG Tiny 1.2 clients, they can no longer do that, they have to "profile"
> the specification and highlight, probably in both specifications, that
> the new feature is not necessarily available in SVG Tiny 1.2 clients,
> leading to complaints about the profiling and confusion among authors,
> who will use the feature in their supposedly Tiny 1.2 content because it
> happens to work in the clients they tested it in (but not in others).
> Both would be less so if the new feature is not added to this version of
> the element traversal specification, so I would expect them to say they
> are unhappy with the addition and, if the feature really has to be
> added, ask that it be added to some other specification. It's simply a
> problem you'll likely have to deal with when adopting the NodeList idea.

Ah, thanks, that does explain the issue.

Though I think that if we want the web to have a .childElements NodeList 
available then we have two options:
1. Add it to the ElementTraversal spec and have SVG Tiny say that they 
no longer require the full ElementTraversal spec.
2. Add it to a separate unrelated spec, such as HTML5.

Result 2 doesn't seem any better than 1. The end result for both is that 
SVG tiny only require a certain set of properties, and with 2 we'd have 
to wait some undefined amount of time before getting it into an Rec, 
possibly of a spec that will have a much slower adoption rate.

/ Jonas
Received on Thursday, 3 April 2008 17:05:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:10:00 UTC