[whatwg] Use cases for Node.getElementById

Simon Pieters ha scritto:
> On Sun, 07 Dec 2008 04:09:01 +0100, Calogero Alex Baldacchino 
> <alex.baldacchino at email.it> wrote:
>
>> I'm reading it :-)
>>
>> And I have a few questions. First, is it meant as the reference DOM 
>> Core for HTML 5 only, or in general (for other kinds of markup too)?
>
> In general.

Ok.

>
>
> Is it the name "HTMLCollection" that is the problem?
>

Perhaps. I don't know and can't guess how much 'political consensus' 
might be needed to make the specification fly (especially if trying a 
convergence with w3c). Maybe, the support of the main browsers vendors 
is more than enough, and a name is not much of a problem in practice. 
Anyway, since that's just a formal/political matter, that may be solved 
when and if needed, I've just pointed out a possible solution (but I'm 
sure you don't need my suggestions to get there, or to find a better one 
:-P).

>
>> I guess such attribute has been declared on the Element interface 
>> instead of the HTMLElement one because actually this is the most 
>> common implementation in current browsers.
>
> Right. Also because it seems useful for not just HTML.
>

Well, on one hand it duplicates a NodeList of child nodes, but on the 
other hand only Element nodes are listed, and this can be useful in 
practice, I agree. :-)

>
>> Anyway, let me suggest [..]
>
> This seems like adding complexity for political reasons.
>

Hmm, for a script no complexity would be added (I mean, a script engine 
embedded in a UA would implement the same interface as the UA, but the 
script code would work fine because of runtime inferred types -- the 
instanceof operator, in ECMAScript, might fail indeed, but such may fail 
anyway in IE, which seems not to expose the DOM hierarchy of an object). 
LiveConnect should work fine as well; any other access to the DOM 
through a plugin may require a whole implementation to make new DOM 
property types/interfaces available as compile-time known 
types/interfaces (I'm not sure, but I think that Java, actually, doesn't 
provide access to non w3c dom 2 properties -- true, at least, for some 
versions of the VM and related DOMAccessProvider objects; I don't know 
if there are third parties implementations allowing that -- and I also 
guess some non-standard interface might be adopted, in implementations, 
to give access to every properties of an html document without having 
always to cast to the proper interface, since HTMLDocument no more 
inherits from Document). Such an implementation might require objects 
wrapping at some point (e.g. to maintain consistency between 
corresponding data types), thus adding a constraint to anything likely 
yet needed shouldn't be too expensive for the implementors. Anyway, yes, 
that's mainly a formal/political need, and obviously can be added as 
needed (as above, :-P)

>
>
> I'm not sure what to do with attributes. I'd like to drop support for 
> attribute nodes (being moved around, etc), if possible, but keep the 
> .attributes list and be able to use .value etc on each attribute.
>

Good question. Unless moving .value/.name on the Node interface (which I 
guess might be problematic for backward compatibility), a Node-derived 
interface is needed to accomplish that, unless changing the list 
'nature' as well (but with similar issues, and not solving the need for 
an interface defining the .value and .name interface)...

>
>> I was thinking just to that when I've read, in HTML 5 spec, that 
>> "This specification doesn't preclude an element having multiple IDs, 
>> if other mechanisms (e.g. DOM Core methods) can set an element's ID 
>> in a way that doesn't conflict with the id attribute".
>
> It says this, AIUI, because other specs do make it possible, not 
> because it's a good idea that it is possible.

I understand it the same way (and guess such specs might allow custom ID 
attributes).

> Personally I think it should not be possible (specifically I think 
> 'id' should be like 'xml:id' is and all other ways to get an ID-like 
> attribute should be dropped).
>

I agree. But I'm not sure if that's a 'safe' choice in a general DOM 
(maybe it is considering actual needs; if support for those other ways 
were needed in the future, it might always be added in a future 
version/revision of Web DOM Core, and wouldn't conflict with html 5 
spec, in reason of that statement -- backward compatibility'd be no more 
problematic than it is today for new HTML tags, but changes and breaks 
are unavoidable if they're good evolutions - unless there is yet some 
degree of support for ID-like attributes, so the break might be less 
safe, but I guess that's not the case).

>
>> For this purpose, either the 'isId' property of an Attr node, or a 
>> mechanism to set an Element's attribute as an alternative ID (or 
>> both) might be helpful [...]
>
> It's not clear to me why it would be helpful.
>

If ID-like attributes were to be supported, specially user defined ones, 
providing any mechanism to set such attributes and/or check their 
'nature' might be useful both in script (i.e. when manipulating the DOM 
and willing to treat ID-like attributes differently from other 
attributes, in order to just check their nature instead of looking for 
matching names) and perhaps for the DOM itself (anyway, methods such 
.getElementById() would need only an implementation-level knowledge of 
the attribute nature - that is, just to rely on an internal property, 
but exposing such a property wouldn't be a ugly choice). However, if 
ID-like attributes won't be supported, there is no need for any suitable 
mechanism to handle them, of course.

>
>> The above takes me to the '.getElementsByClassName()' method: if it 
>> were to be moved from HTML 5 spec to Web DOM Core API, and if the 
>> latter is meant as some kind of replacement for W3C DOM level 3, 
>> perhaps, for generality sake, such method might be defined as 
>> referring to a property named CLASS (along the same lines as ID), 
>> pointing out that such property might not be binded to an attribute 
>> named 'class' (just to make the spec ready in case the need to 
>> support such sort of document arose in the near future, without 
>> having to change web dom core, or to derive a new version, only for 
>> this reason).
>
> That's how it's defined in HTML5 already.
>

Indeed, HTML5 defines such method behaviour without referring to the 
actual class-attribute, but in the end explicitly refers to it for HTML, 
MathML and SVG elements. Maybe that part might be modified when moving 
the method from HTML5 spec to a more general DOM spec, and I wondered 
whether pointing out that a class-attribute may have any name different 
from 'class' (perhaps leaving the reference to a somewhat document type 
as an example), the same way DOM 3 Core does it for IDs, might have been 
a nice formalism.

>
> AIUI, the 'subtree' in HTML5 means the tree from the top-most 
> ancestor. The spec could be clearer about this.
>

Yes, that's its meaning. In a previous mail, Ian Hickson answered me 
such term was chosen to formalize conformance for disconnected trees 
handled by scripts.

>
> Don't nodes always have an ownerDocument?
>

Yes, the always have one... I don't know where my head was when writing 
that... I should have referred to the parentNode property (which is null 
for removed an cloned nodes, for instance), and/or the topmost node not 
being a (html)document node.

>
> Are you arguing that HTML5 should remove the requirement about unique 
> IDs for nodes not in a document?
>

Let me clarify I'm not aiming to argue with anyone about anything. I'm 
just trying and showing an alternative point of view, hoping it may be 
helpful in the process of spec definition.

I'm not sure if a conformance rule for an HTML document may apply in 
such a case, even because a disconnected subtree might come from a 
non-HTML document (I'm not necessarily referring to an existing one, 
since HTML5 spec is thought to define conformance rules also for future 
UAs willing to handle 'older' html5 documents: such UAs might support 
any kind of document embedding html tags the same way html5 allows 
embedding MathML and SVG tags, and such a 'new' kind of document might 
have relaxed requirements for ids, thus I think HTML5 rules should not 
conflict with such, or better, should not define rules for HTML elements 
possibly originated outside an HTML document). Anyway, an ID is an ID 
and an HTML element's  id attribute represents the default ID property 
for its element in any kind of subtree, so, perhaps, indicating such as 
relevant for any api dealing with ID properties, and requiring 
conformance with HTML rules for any subtree to be inserted in any HTML 
document (where duplicate IDs are illegal), instead of declaring 
id-attribute values as always unique, might be reasonable. That's all 
(and I understand, perhaps that's splitting hairs).

>
> I guess the best way to avoid confusion is to not add the feature at 
> all. :-)
>

That's ok for me. Unless a real need for handling unique IDs in 
disconnected subtree arose, avoiding that is a good choice. :-)

>
>> [...]
>
> Right. <br> can have children by using XHTML or by DOM manipulation.
>
>
>> I don't know what every browser currently does (honestly, I've never 
>> tried -- this is a recent doubt of mine),
>
> Opera, Firefox and Safari don't throw. IE does.
>
>
>> but I guess the result might vary from one UA to another, and 
>> something inappropriate might happen (in any case, there is no 
>> standard way to block such). Perhaps, a new (readonly) property might 
>> be defined on Node telling the node is a "definitive leaf", so that 
>> whatever property/method might be declared as inaccessible/failing 
>> (e.g. throwing an exception) if the 'isLeaf' property were true -- 
>> such an attribute cannot be neither an Element, nor an HTMLElement, 
>> nor an HTMLElement derived interface property, since there are 
>> methods on the Node interface involved too, and as well the nodeType 
>> attribute wouldn't cope well with this, because that should work for 
>> instances of the same type, or regardless the type -- in other words, 
>> when trying and changing the descendant hierarchy of a node with a 
>> true value for such an attribute, the result should be an illegal 
>> hierarchy. Do you think such might be worth to be considered?
>
> I don't understand why it would be useful.
>

Well, in case the IE behaviour were chosen as standard (and only in this 
case -- which might be consistent with HTML5 empty content model), 
implementations would likely use an internal property to check when 
deciding whether to block an element subtree creation/manipulation or 
not. Exposing such a property might be useful to check the nature of an 
element in a script, but maybe also to formalize the chosen standard 
behaviour.

>
> Um. Yeah. Actually it rules out everything (a node can't be a Document 
> and a Text node at the same time, for instance). I think i'll move the 
> checking into each algorithm that's adding stuff to the tree instead 
> (in due course).
>

Such will work fine. :-)

Anyway, most checking will be the same, thus your original idea to 
isolate such requirements in a unique list was nice (just needed to 
become a list of what must not happen to have a legal hierarchy to 
work). I think both choices are fine :-)

>
> Thanks for the feedback,

Happy to be helpful somehow, if I can. :-)
Regards, Alex.

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 CAPODANNO A RIMINI HOTEL 2 STELLE
* 2 notti pernottamento con colazione a buffet euro 70,00, 3 notti euro 90,00
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8501&d=8-12

Received on Monday, 8 December 2008 13:30:32 UTC