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

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