mattraymond at earthlink.net
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
> 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
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
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
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
>> 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>
> (so you'd need the DIV for the HTC solution, whereas the inline script
> wouldn't need the extra element)
seeing what you're talking about.
More information about the whatwg