Lists Home |
Date Index |
> There is another important structural problem with HLink. It is adopting
> the same conceptual disaster as <OBJECT> - overgeneralization in a single
> element type, a false economy. It leads to omnium gatherum attribute sets
> with all sorts of interdependencies. (You'd think people would have
> learned from the INPUT element in HTML!) It's all very fine to say that
> if the effect attribute is embed and the actuate attribute is onLoad then
> the onSuccess attribute means such-and-such, but without an *exhaustive*
> analysis of the various combinations, the spec is deficient in untangling
> a problem of its own making. This will result in either a reluctance to
> implement because the bogotic combinations lack definition, or an interop
> problem when the bogotic combinations are read as an invitation to um,
> "embrace and extend".
I agree with the point about object. I saw a lot of praise for the idea of
collapsing applet and img into object, but I find the idea a bewildering step
backwards. I hear talk that this will reduce the number of tags Web authors
need to remember. But I agree with you that remembering all the resulting
constellation of nuances of object will be a much harder task than remembering
2 different GIs. And wait until browser nuances are added to that mix.
As I design vocabularies, a significant difference of semantics in most
processing of two elements requires a different type names for these elements.
By this measure, img and applet undoubtedly deserve separate element types.
The reductio ad absurdum of the collapse into object is:
Probably a bit too saucy an argument, but I certainly can't see the rational
argument for the new super-OBJECT tag.
However, I'm trying to follow your extension of this criticism to HLink. It
is the hlink element itself that you find an over-stuffed concept, right? Not
the elements it describes.
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Basic XML and RDF techniques for knowledge management, Part 7 -
Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra