[whatwg] Why not JavaScript?

On Thu, 10 Jun 2004, Andrew Clover wrote:
>
> [BTW, 'expdate' should clearly be named 'month'; it is not explicitly a
> credit card expiry date.]

How strongly do people feel about this? The advantage of having it be
"expdate" is that it is immediately clear what the field is. I couldn't
actually think of another use case for it when I wrote this up.


> Validation is something that can be done by script, but could benefit
> from a standard browser interface. I would like to see the 'validate'
> event on form do the 'alerting the user that the entered value is
> unacceptable' action in all cases, even manually calling .validate()
> from script.

Yeah I was thinking about that. Ok, done.


> autofocus would also be good, if it's meant to only focus when the
> window itself has focus, ie. not steal focus from other windows. This
> can't currently be done from JS so I assume this is what it's for.

Note added to this effect.


> Things I'm not especially keen on, OTOH:
>
>    - repeating form controls. Seems a *lot* of added complication for
>      something that can currently be done pretty easily with DOM
>      (cloneNode etc.).

Having done it, I assure you, it's a lot easier if you don't have to. :-)


>      The name-[]-hacking bit is especially nasty,
>      a way of including literal square brackets seems to be missing,

Yes. Better suggestions are welcome. :-)


>      and id duplication inside the template seems not be catered for.

Just put [template] into the IDs, so they get changed as well.


>    - <output> seems pretty redundant, providing no functionality that
>      can't currently be done just as well using styled readonly inputs
>      or plain spans.

Functionality, no, but it provides for better semantics. It also makes the
script a bit nicer; instead of having to hack around with text nodes you
can just change "value".


>    - the FormImplementation method of remoting seems redundant. DOM
>      Level 3 LS and XMLHttpRequest already cover this ground, I would
>      prefer to see browsers standardise on either of these.

Both XMLHttpRequest and DOM3LS are significantly more complicated.


>    - user-modify. I am VEHEMENTLY opposed to the IE model of being
>      able to arbitrarily edit non-form elements. This proposal has
>      all the disadvantages of contentEditable, without the advantage
>      of actually being IE-compatible.

Yeah, I agree. The Web Controls spec hasn't yet really been looked at.


> I would be particularly interested in sending DOM Mutation Events down a
> wire to synchronise DOMs, especially if the client end could send
> addEventListener requests to the server end to specify what it was
> interested in. That's not strictly web application-related, but it'd be
> cool.

Well, you control the server side, so just define whatever you want as
your API and then use <event-source>:

   <event-source src="dom-watcher?mutations-on=foo,bar">

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 11 June 2004 08:41:48 UTC