Javascript for degradation [ Re: [whatwg] Suggested changes to Web Forms 2.0, 2004-07-01 working ]

Matthew Raymond mattraymond at
Mon Jul 19 18:26:02 PDT 2004

Jim Ley wrote:
>>   I might remind you that nothing is stopping anyone from creating a
>>pure script solution, and both the pure script and HTC efforts may even
>>cooperate and reuse each other's code.
> No, but we're excluding a solution because it cannot be done in HTC's

    Actually, I've tested <object> in IE, and the <object> element in my 
test didn't show up in the DOM using straight JScript, so I fail to see 
what HTC even has to do with it.

> - that's my problem, even though HTC's are sub-optimal for the
> majority of situations (look at the two proposed examples, neither use
> HTC's)

    Proposed examples?

 > Simply because the cost of development and risk exceeds the
> value - the vast majority of the shims are trivial small quantity of
> code, that is cross-browser, and well tested (since all WF2 provides
> is the same things people are already doing, but this time with extra
> markup)

    So implement the emulation layer using only necessary, 
browser-specific technologies, starting with the one that has the most 
browser share. According to what I've heard so far, that would mean 
starting with Javascript and HTC on IE6. If the rest are easy to add 
support for, so much the better.

> No it's not, do you know much about HTC's and jscript, IE DOM
> development?  normal jscript leaks are tiny, especially when all
> you're dealing with is DOM 0 forms arrays, no closures etc.  which a
> lot of the WF2 shims are dealing with.  HTC's are another order of
> magnitude different.

    I'll defer to Dean on this one, as he is the expert.

>>especially with Microsoft resuming maintenance on IE.
> Didn't you just say one of the motivations was that IE wasn't being
> developed any more?

    Code maintenance is not the same as active development.

> Nowhere did I advocate that, but I see massive numbers coming out of
> the Mozilla people saying how many people are downloading the current
> UA's, by the time WF2 is releasable, you're working on the assumption
> that IE6 still has a monopoly on UA's - I'm not willing to take that
> bet.

    My understanding is that they're trying to get WF2 supported in 
Mozilla and Opera by the end of the year. That's hardly enough time to 
tip the scales in the browser war.

>>   The only case I can think of is your <object> solution for
> It's for all form elements, not just comboboxes datetimes too.
>>and I personally listed many problems with that solution.
> Could you list them again, as I remember 2, one was ridiculous (having
> to specify multiple classids), and the other was the swallowing of
> OBJECT in the IE DOM - which is only relevant to HTC degradation. (and
> even that isn't absolute if you could agree a convention with the HTC
> folk.)

>>   Please explain how this is possible in plain script, but is somehow
>>not possible in an HTC.
> Because OBJECT is swallowed in the DOM, so the IE DOM from the HTC's
> perspective, even if you bind it to a BODY element or something, can't
> see the OBJECT element to recognise a DOM element is there, non HTC
> solution, can use an inline script inside the OBJECT

    My tests show that the <object> element isn't in the DOM at all 
regardless of HTC use. Therefore, how do you use inline script to 
recover the <object> properties, and how is that any better than other 
solutions that don't use <object>?

> Alternatively you could use an HTC solution, but you'd require an
> extra convention e.g.
> <object name=datetime classid="urn:whatwg:datetime">
> <div class="whatWG_datetime">
> Day:<input name=day>
> Month: <input name=month>
> Year:<input name=day>
> Time:<input name=time>
> <div>
> </object>
> (so you'd need the DIV for the HTC solution, whereas the inline script
> wouldn't need the extra element)

    Perhaps you should give us a HTML+Javascript example, as I'm not 
seeing what you're talking about.

More information about the whatwg mailing list