[whatwg] Why not JavaScript?

[Andrew Clover]

Peter-Paul Koch <gassinaumasis at hotmail.com> wrote:

 > First of all, when I read the (very interesting) position paper, it
 > struck me that every described feature can be implemented in
 > JavaScript

Am inclined to agree. I would prefer not to standardise mechanisms that 
could already be implemented just as well using an appropriate 
client-side scripting library.

However, I *do* like many of the proposed extensions, especially where 
they offer a reasonable level of backwards compatibility.

For example the new form element types and restrictions give the browser 
the opportunity to present more polished interfaces, whilst still 
allowing older UAs to input text (because legacy UAs will typically 
treat an unknown or missing type attribute as the default 'text'). There 
are also some features here that couldn't currently be done with 
scripting, for example localised text and timezone support in date 
controls, and e-mail/uri selection.

[BTW, 'expdate' should clearly be named 'month'; it is not explicitly a 
credit card expiry date.]

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.

Required fields, input.labels, "Handling characters outside the 
submission character set", fieldset-disabled and the suggested addition 
of a way to include HTTP Authentication login/logout on a web page are 
also welcome.

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.

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.). The name-[]-hacking bit is especially nasty,
     a way of including literal square brackets seems to be missing,
     and id duplication inside the template seems not be catered for.

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

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

   - 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. Suggest instead:

     <textarea type="text/html">some <em>emed/em> blah</textarea>

     which would much better fit the current Forms model and would
     also be compatible with legacy and other browsers that cannot
     supply HTML editing facilities. Other MIME types might also be
     appropriate, eg. text/xml, or text/csv to get a full tabular
     data editor.

 > maybe except for the server sent events and the clipboard
 > api (but even in those cases it might be possible).

Clipboard API I don't really want to see, given the problems IE's 
implementation of such brought up. A better standardised drag-and-drop 
interface would be great though, as doing it with mouse events and IE's 
proprietary events is annoying-to-impossible to get right all the time.

I really like the idea of server-side events, though I would prefer to 
have them set up by a scripting call rather than an HTML element.

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.

 > The point is that JavaScript is not 100% reliable.

Sure, and for normal web sites or documents reliance on JS is highly 
undesirable. However with "web applications" (assuming we've decided 
what they are...) it is unrealistic to unexpect that their entire 
functionality could be implemented without any client-side scripting. So 
if scripting is going to be a bit necessary, it might as well be a lot 
necessary.

 > To me, [eBay and Amazon] are not applications but web sites

I agree. That's not to say they couldn't evolve to include or be web 
applications, but their core functionality IMO isn't and doesn't need to be.

-- 
Andrew Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/