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

[Jim Ley]

On Mon, 19 Jul 2004 15:35:27 -0400, Matthew Raymond
<mattraymond at earthlink.net> 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
- 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) 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)

> >>4) Memory leaks, which seems to be a problem with IE JScript in general.
> > Yep, these sound pretty f'ing alarming for release quality web-applications !
> 
>    No. 4, as a problem in JScript in general, is a problem for your
> solution as well, 

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.

>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?

>    There's a difference between coming up with new features that work
> on the majority browser and features that work on the lowest common
> denominator of all browsers. I don't believe we should drop features
> simply because the can't be implemented using Javascript on Minority
> Browser X. 

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.

>    The only case I can think of is your <object> solution for
> comboboxes,

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.)

> > It is supportable by plain script, with all
> > the enhancements, and would even be supportable by HTC's if you chose
> > that approach (you would have to include an extra DIV/SPAN or
> > something element in that situation, but it's perfectly doable.)
> 
>    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

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)

Jim.