dean at edwards.name
Tue Jul 20 08:37:52 PDT 2004
are you suggesting that we use the <object> tag for all new elements? or
just as an alternative to <datalist>?
can you provide some code examples to support the text below? because to
me, the fact that the <object> tag does not show up in the DOM is a
show-stopper. how do you know which <form> contains the <object> if it
is not in the DOM?
Jim Ley wrote:
> On Mon, 19 Jul 2004 20:51:50 +0100, Dean Edwards <dean at edwards.name> wrote:
>>>>I've done that, so far it's being rejected primarily because it is not
>>>>supportable by HTC's!
>>it was rejected because the <object> element does not reside in the DOM.
> Which is purely related to HTC's since inline script legacy support is
> fine here, or even HTC's with a simple extra convention as exampled in
> my previous post.
> Let me clarify the advantages of the OBJECT approach as I see them:
> They'll work with HTML 4.01 and XHTML 1.0 content, no need for people
> to learn new elements, or a new DTD at the top, which also means no
> need to get a new validator (or convince the validator people to all
> update their packaged DTD's etc.), in fact no need to write a new DTD.
> All in all much less new stuff to do.
> They allow people to degrade the content in any way they see fit, they
> can provide better input elements than a text element to anyone, even
> without using any script, or even just by using their existing
> scripts, the pages could in fact be modified purely by wrapping parts
> in OBJECT elements.
> Doesn't overload the input element, this simplifies the server portion
> of the script, it knows if it's getting the object named submission or
> the legacy content, so can immediately fork the validation routines
> there. They should be simpler for the WF2 client, as it knows valid
> input will a valid ISO date time for example.
> Accessibility is improved, you can provide user help with entering the
> data only in the legacy case - very important as we have seen with
> datetime, where so far the fallback is rudimentary at best.
> It can be implemented easily in binary plug-in extension - I realise
> this isn't a requirement, but a binary plugin for IE would be much
> better than a script one, with the new element approach, the only
> option is a binary behaviour, and they need author support so to get
> into the page. OBJECT doesn't have any such limitation.
> and the disadvantage of this mark-up ?
> Oh yeah - it doesn't appear in the IE6 DOM.
> there are probably others, but I've not been able to think of any -
> and I'm pretty pessimistic about proposals, as I'm sure people have
> Comments in CIWAH seem to agree with me:
> see message id: er8of0pojpnri5urc4ima5307q4jqjqrte at 4ax.com
> I really think this should be reconsidered, and proper arguments
> favouring new elements, and overriding input further be looked at
> against this.
More information about the whatwg