Simon Pieters ha scritto:
On Sun, 07 Dec 2008 04:09:01 +0100, Calogero Alex Baldacchino
<[EMAIL PROTECTED]> 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