Comments welcome on Web Forms 2.0 proposal

[Ian Hickson]

A group of us have been unofficially working on a proposal of extensions
to HTML4's Forms chapter, and would like to get input from a wider range
of people now that we think our draft proposal is reaching a stable stage:

http://www.whatwg.org/specs/web-form...-for-comments/

Some of the features we are proposing include new input control types for
dates, times, e-mail addresses, and numbers; a new client-side validation
model; a way to mark input controls as required; a repetition model;
control over form submission so that forms can be updated instead of
causing the page to be replaced; and more.

If you have any comments or suggestions to make regarding this proposal,
please send them to our mailing list:

http://whatwg.org/mailing-list

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

[Chris Morris]

ia*********@gmail.com (Ian Hickson) writes:

A group of us have been unofficially working on a proposal of extensions
to HTML4's Forms chapter, and would like to get input from a wider range
of people now that we think our draft proposal is reaching a stable stage:

http://www.whatwg.org/specs/web-form...-for-comments/

Some of the features we are proposing include new input control types for
dates, times, e-mail addresses, and numbers; a new client-side validation
model; a way to mark input controls as required; a repetition model;
control over form submission so that forms can be updated instead of
causing the page to be replaced; and more.
I think there's some large backward-compatibility problems here:

Most notably, the behaviour of <input type='unexpected' name='foo' ...>

Display as text field: lynx 2.8, links2, Gecko, IE, Konqueror, Opera, Dillo
Ignore: w3m 0.5

So, firstly there's the serious problem that some UAs will just not
display these unexpected content types. I've found one, probably there
are others. Secondly there's the problem for the UAs that display them
as text (i.e. existing ones) - the time-based attributes are
incredibly user-unfriendly to enter compared to the reasonably
friendly approach possible by constructing multiple selects or using
multiple text inputs, one for each part of the datetime.

I can't think of a way to set up a datetime input that degrades
gracefully unless you require clients or servers to have quite
powerful string->time processors for the inevitable:
Start Date: _3rd_June_2001___
(or you could just reject it until the user guesses that you require a
specific (user-unfriendly) format, or you could specify that format by
the element and so confuse the person with a supporting UA)

The 'repeat' system is equally problematic, since the buttons won't
work in current UAs (and fallback JS is unreliable too).

Without a good method for getting graceful degradation (I may be
missing something on how you intend to get it, but I can't see
anything in the draft that suggests how it would happen), using these
extensions is very risky unless widespread browser support
exists. Which won't exist if there's no demand because people can't
risk using them in production environments.

While more types of form controls, stronger data typing in forms, the
functionality of the 'repeat' attributes, etc. is all a good thing, I
don't feel that client-side is the best place to be solving it since I
can't see a sensible way to get graceful degradation [1]. Server side
in a language with a good forms library seems the better place to
solve these problems.

[1] Okay, I can think of one. Invent a new content type
text/x-extendedwebforms-html. Use <object> with a manually constructed
user-friendly form as fallback. However, that gives a *lot* of extra
author effort for very little user benefit, which isn't helpful either.

Much less importantly - as regards 'autocomplete':
"A UA may allow the user to disable support for this
attribute. Support must be enabled by default, and the ability to
disable support should not be trivially accessible, as there are
significant security implications for the user if support for this
attribute is disabled."
Alternatively, a UA should be allowed to default autocomplete to 'off'
for all elements. Quite a lot of my UAs do this by having no
autocomplete functionality of any sort. This has no security
implications whatsoever.
If you have any comments or suggestions to make regarding this proposal,
please send them to our mailing list:

You asked here, you get the comments here.

--
Chris

[Ian Hickson]

Chris Morris <c.********@durham.ac.uk> wrote in message news:<87************@dinopsis.dur.ac.uk>...

http://www.whatwg.org/specs/web-form...-for-comments/
I think there's some large backward-compatibility problems here:

Most notably, the behaviour of <input type='unexpected' name='foo' ...>

Display as text field: lynx 2.8, links2, Gecko, IE, Konqueror, Opera, Dillo
Ignore: w3m 0.5

So, firstly there's the serious problem that some UAs will just not
display these unexpected content types.

That's a bug in w3m 0.5. HTML4 is quite clear that the default is
"text".

Secondly there's the problem for the UAs that display them
as text (i.e. existing ones) - the time-based attributes are
incredibly user-unfriendly to enter compared to the reasonably
friendly approach possible by constructing multiple selects or using
multiple text inputs, one for each part of the datetime.
It is expected that for legacy UAs, servers accept input in many
different forms and attempt to parse the user's input. Client-side
Javascript can help in such scenarios, for example replacing the one
control with several controls, or validating the user's input on the
client side.

Admittedly none of these options are as nice as simply having legacy
UAs display a calendar control (or similar), but as you say:
I can't think of a way to set up a datetime input that degrades gracefully
The solution I described above is similar to what you suggested:
require clients or servers to have quite powerful string->time processors for
the inevitable:
Start Date: _3rd_June_2001___
On the short run, while WF2 UAs are still rare, it is possible that
authors would prefer to use <select>s and the like; the idea is that
once the majority of non-IE browsers support WF2, authors can use WF2
features with IE6 being supported through JavaScript or HTC libraries
(these are already in develpoment).

The 'repeat' system is equally problematic, since the buttons won't
work in current UAs (and fallback JS is unreliable too).
Again, in HTML4-compliant UAs, the buttons should fallback to being
submit buttons, allowing the server to handle the repetition block
generation. There is a demo that shows that this works:

http://whatwg.org/demos/repeat-01/

Unfortunately it seems the only UA that is HTML4-compliant enough is
Mozilla.
Graceful degradation is definitely something that we are considering
important. Admittedly it isn't always easy, but we think we have some
pretty good solutions for most of the cases.

Much less importantly - as regards 'autocomplete':
"A UA may allow the user to disable support for this
attribute. Support must be enabled by default, and the ability to
disable support should not be trivially accessible, as there are
significant security implications for the user if support for this
attribute is disabled."
Alternatively, a UA should be allowed to default autocomplete to 'off'
for all elements. Quite a lot of my UAs do this by having no
autocomplete functionality of any sort. This has no security
implications whatsoever.

Well, supporting the "on" value doesn't require supporting
autocomplete, so the spec does indeed already allow for this.

If you have any comments or suggestions to make regarding this proposal,
please send them to our mailing list:

You asked here, you get the comments here.

That works too. Thanks!

--
Ian Hickson

[Chris Morris]

ia*********@gmail.com (Ian Hickson) writes:

Chris Morris <c.********@durham.ac.uk> wrote

http://www.whatwg.org/specs/web-form...-for-comments/
I think there's some large backward-compatibility problems here:

Most notably, the behaviour of <input type='unexpected' name='foo' ...>

Display as text field: lynx 2.8, links2, Gecko, IE, Konqueror, Opera, Dillo
Ignore: w3m 0.5

So, firstly there's the serious problem that some UAs will just not
display these unexpected content types.

That's a bug in w3m 0.5. HTML4 is quite clear that the default is
"text".

That's the default if the attribute isn't specified, yes. There's no
*requirement* for it to default back to text if the attribute exists
but is unrecognised, although the _informative_ Appendix B suggests
that UAs should do this in error recovery.

Uncommon behaviour, yes, but I don't think it's an actual bug.

Secondly there's the problem for the UAs that display them
as text (i.e. existing ones) - the time-based attributes are
incredibly user-unfriendly to enter compared to the reasonably
friendly approach possible by constructing multiple selects or using
multiple text inputs, one for each part of the datetime.

It is expected that for legacy UAs, servers accept input in many
different forms and attempt to parse the user's input.

This does make the server-side coding a lot more complex, though.
Client-side Javascript can help in such scenarios, for example
replacing the one control with several controls, or validating the
user's input on the client side.
True. Though that just moves the graceful degradation problem to a
different place.

require clients or servers to have quite powerful string->time
processors for the inevitable:
Start Date: _3rd_June_2001___

On the short run, while WF2 UAs are still rare, it is possible that
authors would prefer to use <select>s and the like;
the idea is that once the majority of non-IE browsers support WF2,
authors can use WF2 features with IE6 being supported through
JavaScript or HTC libraries (these are already in develpoment).

With the recent zero-day ActiveX/Javascript exploits that IE6 has just
been hit with, though, expecting Javascript to be enabled in IE is
unreasonable. People will have, of course. Anyway, Javascript just
moves where the graceful degradation problem is.

The 'repeat' system is equally problematic, since the buttons won't
work in current UAs (and fallback JS is unreliable too).

Again, in HTML4-compliant UAs, the buttons should fallback to being
submit buttons, allowing the server to handle the repetition block
generation. There is a demo that shows that this works:

http://whatwg.org/demos/repeat-01/

Unfortunately it seems the only UA that is HTML4-compliant enough is
Mozilla.

Again this seems to be relying on the behaviour in the _informative_
Appendix B that unrecognised attribute values should be treated as the
default value - it's not necessarily a browser bug that they don't,
it's not a requirement that a HTML4-compliant UA does so [1].

[1] Unless I'm missing something elsewhere in the specification, but
I've checked the obvious places.
Graceful degradation is definitely something that we are considering
important. Admittedly it isn't always easy, but we think we have some
pretty good solutions for most of the cases.

With sufficient server-side processing most of it can be done, yes. It
does put a lot more burden on the server-side programmer to make sure
that they have a robust date parser, etc, but that just involves
getting a good quality library.

Repeat seems to be the most difficult to get to work properly, though,
I think partly because it's not really like any other part of HTML but
has more similarities to pre-processor scripting behaviour.

PS: Why allow 'mailto:' and 'javascript:' as form actions? The latter
should always be duplicatable (with far better fallback) by using
onSubmit, the former has enough well-documented problems anyway and
there's enough server-side scripts to do the job around.

--
Chris

[Jim Ley]

On 30 Jun 2004 16:06:16 +0100, Chris Morris <c.********@durham.ac.uk>
wrote:

It is expected that for legacy UAs, servers accept input in many
different forms and attempt to parse the user's input.
This does make the server-side coding a lot more complex, though.

Of course it does, the whole WF2 concept is instead of having the
author constrain neatly what the user does by creating a complex
control themselves, (3 form elements for a date) we should some how
educate users into entering an understandable format. Fortunately
the WHATWG is getting hardly any interest only about 6 people active
on the mailing lists, including only 3 of their own Working Group. So
I can't see it really getting anywhere. Still if Opera etc. want to
waste their resources on it rather than creating good software, I
won't stand in their way.
With sufficient server-side processing most of it can be done, yes. It
does put a lot more burden on the server-side programmer to make sure
that they have a robust date parser, etc, but that just involves
getting a good quality library.
No, Hixie's said in the mailing list that there's nothing in WF2 that
requires a server, so degradation surely can't require it, you must be
mis-reading...
PS: Why allow 'mailto:' and 'javascript:' as form actions? T

Supposedly those sections are nothing new just documenting what
existing browsers do - I don't believe that, but not been bothered to
actually test.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[George Lund]

In message <40****************@news.individual.net>, Jim Ley
<ji*@jibbering.com> writes

Fortunately
the WHATWG is getting hardly any interest only about 6 people active
on the mailing lists, including only 3 of their own Working Group.

That's nonsense - in my mail database right now there are posts from at
least sixteen separate contributors. And I suspect that many, like me,
are reading with interest if not actually participating right now.

Good user interface design is _exactly_ about the software developer
constraining what users can do so that it is sensible and provides valid
data to back-end systems, as well as being easy-to-use There can't be
any doubt that what HTML provides right now isn't adequate to this task.

--
George Lund

[Ian Hickson]

Chris Morris <c.********@durham.ac.uk> wrote:

ia*********@gmail.com (Ian Hickson) writes:

Chris Morris <c.********@durham.ac.uk> wrote

So, firstly there's the serious problem that some UAs will just not
display these unexpected content types.
That's a bug in w3m 0.5. HTML4 is quite clear that the default is
"text".

That's the default if the attribute isn't specified, yes. There's no
*requirement* for it to default back to text if the attribute exists
but is unrecognised, although the _informative_ Appendix B suggests
that UAs should do this in error recovery.

True.

To be honsest, a strict reading of HTML4 finds very few conformance
criteria, and most that it does find make no sense in the real world.
Over the years of reading that spec I've developed a tendency to read
between the lines when reading the HTML spec!

So yeah, technically not a bug, but certainly not within the spirit of
the spec. (Same with the <button> case.)

Secondly there's the problem for the UAs that display them
as text (i.e. existing ones) - the time-based attributes are
incredibly user-unfriendly to enter compared to the reasonably
friendly approach possible by constructing multiple selects or using
multiple text inputs, one for each part of the datetime.

It is expected that for legacy UAs, servers accept input in many
different forms and attempt to parse the user's input.

This does make the server-side coding a lot more complex, though.

Yes, if the server wants to handle legacy UAs then it indeed have to
have moderately complex parsing for things like that. (This is only
really a problem for the date and time types, the other types are
already commonly requiring this kind of server side processing.)

Client-side Javascript can help in such scenarios, for example
replacing the one control with several controls, or validating the
user's input on the client side.

True. Though that just moves the graceful degradation problem to a
different place.

Well, it just means that when JS is enabled, the user gets helped. You
would still have the server side code mentioned above. So I don't
think it really moves the problem, just alleviates it in certain
cases. (Just like Web Forms 2.0 UAs would alleviate it in certain
cases.)

require clients or servers to have quite powerful string->time
processors for the inevitable:
Start Date: _3rd_June_2001___

On the short run, while WF2 UAs are still rare, it is possible that
authors would prefer to use <select>s and the like;
the idea is that once the majority of non-IE browsers support WF2,
authors can use WF2 features with IE6 being supported through
JavaScript or HTC libraries (these are already in develpoment).

With the recent zero-day ActiveX/Javascript exploits that IE6 has just
been hit with, though, expecting Javascript to be enabled in IE is
unreasonable. People will have, of course. Anyway, Javascript just
moves where the graceful degradation problem is.

Well, again, the point here would be that if you don't have to care
about graceful degradation in any case but one (IE6) then you can
special case that one browser and handle it specially (using HTCs, JS,
or whatever).

So here you don't move the problem so much as change the problem.

Graceful degradation is definitely something that we are
considering important. Admittedly it isn't always easy, but we
think we have some pretty good solutions for most of the cases.

With sufficient server-side processing most of it can be done, yes. It
does put a lot more burden on the server-side programmer to make sure
that they have a robust date parser, etc, but that just involves
getting a good quality library.

Right. And in many cases the server would have to do that today
anyway.

Repeat seems to be the most difficult to get to work properly, though,
I think partly because it's not really like any other part of HTML but
has more similarities to pre-processor scripting behaviour.
It's not too hard, the demo I mentioned earlier has source if you want
to study it.

PS: Why allow 'mailto:' and 'javascript:' as form actions?

It's not a matter of allowing it. It's a matter of defining what
happens when they are used. We could define it as doing nothing, but
since it is as easy to define what should happen, and since (at least
in the mailto: case) it has been requested to the point of being
implemented in several UAs, there doesn't seem to be an advantage to
saying it does nothing.

--
Ian Hickson

[Chris Morris]

I think I'm seeming more negative than I mean to be here - I *do* like
the idea of having better form controls. I just can't see a way to do
some of it with good graceful degradation, which is something that is
IMO essential (especially as regards disability legislation, but
beyond what that covers too).

ia*********@gmail.com (Ian Hickson) writes:

Chris Morris <c.********@durham.ac.uk> wrote:

That's the default if the attribute isn't specified, yes. There's no
*requirement* for it to default back to text if the attribute exists
but is unrecognised, although the _informative_ Appendix B suggests
that UAs should do this in error recovery.
True.

To be honsest, a strict reading of HTML4 finds very few conformance
criteria, and most that it does find make no sense in the real world.
Over the years of reading that spec I've developed a tendency to read
between the lines when reading the HTML spec!

So yeah, technically not a bug, but certainly not within the spirit of
the spec. (Same with the <button> case.)

However the <button> one is certainly very widespread. Why not instead
define a (new) repeat attribute for button, and have that override the
type attribute? That way you could have type="submit" for older browsers.

It is expected that for legacy UAs, servers accept input in many
different forms and attempt to parse the user's input.

This does make the server-side coding a lot more complex, though.

Yes, if the server wants to handle legacy UAs then it indeed have to

And given that Netscape 4 isn't completely dead yet, this will be
needed for a while yet.
have moderately complex parsing for things like that. (This is only
really a problem for the date and time types, the other types are
already commonly requiring this kind of server side processing.)
Agreed. The other types could quite safely fallback to "text", since
that's the general way to obtain that data at the moment. I generally
get date/time types by multiple <select>s (or possibly multiple
<input>s).

With the recent zero-day ActiveX/Javascript exploits that IE6 has just
been hit with, though, expecting Javascript to be enabled in IE is
unreasonable. People will have, of course. Anyway, Javascript just
moves where the graceful degradation problem is.

Well, again, the point here would be that if you don't have to care
about graceful degradation in any case but one (IE6) then you can
special case that one browser and handle it specially (using HTCs, JS,
or whatever).

Except that generally you do have to care about graceful degradation
in more than one case. IE5(.5) is still used quite a bit, Mac IE 5.x
is one of the better MacOS 9 browsers, Netscape 4+..., and of course
Opera 6,7, all the Mozillas to date - that's a lot to do graceful
degradation for and the list goes on. Including some that don't
support JS, HTCs, or anything clever other than creating the form
controls server-side.

And by the time support is common, there'll probably be IE 7 to worry
about too.
So here you don't move the problem so much as change the problem.
I think we probably mean the same thing here. What I was meaning was
that this reduces the problem from being "UAs (list)" to "UAs (list),
with JS disabled", but that's still quite a large problem.

Graceful degradation is definitely something that we are
considering important. Admittedly it isn't always easy, but we
think we have some pretty good solutions for most of the cases.

With sufficient server-side processing most of it can be done, yes. It
does put a lot more burden on the server-side programmer to make sure
that they have a robust date parser, etc, but that just involves
getting a good quality library.

Right. And in many cases the server would have to do that today
anyway.

Except that the effort of parsing date="3rd Septembre 199O" (or even
"3rd September 1990" compared to parsing date_d=3, date_m=9,
date_y=1990 from 3 <select>s) is a big increase in complexity. And
probably a usability decrease for the user.

Repeat seems to be the most difficult to get to work properly, though,
I think partly because it's not really like any other part of HTML but
has more similarities to pre-processor scripting behaviour.

It's not too hard, the demo I mentioned earlier has source if you want
to study it.

Sorry, I don't mean hard on the server-side, I mean hard for
client-side graceful degradation. Though the modification I've
suggested to the <button> specification, or something similar might
help there. Obviously with current browsers relying on <button
type="unknown" ...> to become <button type="submit" ...> isn't
workable.

The fact that this can be done quite easily server-side using existing
browsers (with a Javascript client-side version as well, if desired)
makes it less important.

I don't quite feel comfortable with HTML markup that is *designed* to
expand itself into something else, especially if it can do so when
scripting is disabled. I can't think of any current markup that
behaves in this way, which suggests to me that this would be better
handled by providing good server-side and client-side libraries within
the current HTML spec.

PS: Why allow 'mailto:' and 'javascript:' as form actions?

It's not a matter of allowing it. It's a matter of defining what
happens when they are used. We could define it as doing nothing,
but since it is as easy to define what should happen, and since (at
least in the mailto: case) it has been requested to the point of
being implemented in several UAs,

The problem being that it was implemented, and so people use it, and
think it works reliably when in fact it doesn't.

Thinking about it, sms(to): would almost certainly have the same
problem.
there doesn't seem to be an advantage to saying it does nothing.

Don't explicity say it does nothing, just don't specify it at all, as
you've done for the telepathy: and pigeon: protocols [1] (poorly supported
in current browsers, I admit). UAs can choose to make them do
something, but a specification should not encourage (by explicitly
saying that it will do something, especially without a warning that
there are problems with this) authors to shoot themselves in the
accessibility foot.

If you don't mention every protocol that could possibly be used for
form submission (and you don't) you are saying that the ones you do
mention are okay for it - when some clearly aren't, outside of an
intranet environment.

[1] And more seriously, nntp: (at least as valid as mailto: even if it
isn't supported by UAs) is one you don't mention, urn: could
potentially be useful, etc.

--
Chris

[Ian Hickson]

Chris Morris <c.********@durham.ac.uk> wrote:

I think I'm seeming more negative than I mean to be here - I *do* like
the idea of having better form controls. I just can't see a way to do
some of it with good graceful degradation, which is something that is
IMO essential (especially as regards disability legislation, but
beyond what that covers too).
I agree, but if there is no way to make it degrade perfectly, an
imperfect solution is better than none at all, IMHO.

[some UAs don't default button type="" to submit]

However the <button> one is certainly very widespread. Why not instead
define a (new) repeat attribute for button, and have that override the
type attribute? That way you could have type="submit" for older browsers.

Because that solution is very ugly. Imagine the second time someone
extends <button>. You end up having to have three attributes when you
really should just have one.

> It is expected that for legacy UAs, servers accept input in many
> different forms and attempt to parse the user's input.

This does make the server-side coding a lot more complex, though.

Yes, if the server wants to handle legacy UAs then it indeed have to

And given that Netscape 4 isn't completely dead yet, this will be
needed for a while yet.

have moderately complex parsing for things like that. (This is only
really a problem for the date and time types, the other types are
already commonly requiring this kind of server side processing.)

Agreed. The other types could quite safely fallback to "text", since
that's the general way to obtain that data at the moment. I generally
get date/time types by multiple <select>s (or possibly multiple
<input>s).

Incidentally, there is now a demo on the WHATWG site showing this
fallback behaviour:

http://www.whatwg.org/demos/date-01/

I agree that it would be nice to have better fallback for the date
controls, but nobody has yet come up with a solution that is neat
enough.

(And note that there are actually plenty of examples of one-control
inputs out there already, so it's not like users never see this.)

With the recent zero-day ActiveX/Javascript exploits that IE6 has just
been hit with, though, expecting Javascript to be enabled in IE is
unreasonable. People will have, of course. Anyway, Javascript just
moves where the graceful degradation problem is.

Well, again, the point here would be that if you don't have to care
about graceful degradation in any case but one (IE6) then you can
special case that one browser and handle it specially (using HTCs, JS,
or whatever).

Except that generally you do have to care about graceful degradation
in more than one case.

That depends. GMail, for instance, only works on a very small number
of browsers. Getting applications like this (and applications are the
primary concern of WHATWG, it's even in the name) working in legacy
UAs is often simply not interesting to application authors.

But yes, if you don't have JS then you have to rely on the basic
degradation built into WF2, and there isn't much we can do about that.
If you're targetting a UA that only supports HTML4, then no amout of
graceful degradation is going to get you the new features in CSS, DOM,
WF2, etc.

And by the time support is common, there'll probably be IE 7 to worry
about too.
I doubt IE7 will have any significant changes to its rendering engine.

I think we probably mean the same thing here. What I was meaning was
that this reduces the problem from being "UAs (list)" to "UAs (list),
with JS disabled", but that's still quite a large problem.
Is it?

It isn't much of a problem at all for people writing "Web
Applications", since they're going to need scripting enabled anyway.
For people writing basic forms and aiming to cover 100% of the market,
then I think they'll have their work cut out enough just getting HTML4
to work at all, so that adding WF2 to that won't be much, IMHO.

> Graceful degradation is definitely something that we are
> considering important. Admittedly it isn't always easy, but we
> think we have some pretty good solutions for most of the cases.

With sufficient server-side processing most of it can be done, yes. It
does put a lot more burden on the server-side programmer to make sure
that they have a robust date parser, etc, but that just involves
getting a good quality library.

Right. And in many cases the server would have to do that today
anyway.

Except that the effort of parsing date="3rd Septembre 199O" (or even
"3rd September 1990" compared to parsing date_d=3, date_m=9,
date_y=1990 from 3 <select>s) is a big increase in complexity. And
probably a usability decrease for the user.

Not that big. See the script quoted above.

Repeat seems to be the most difficult to get to work properly, though,
I think partly because it's not really like any other part of HTML but
has more similarities to pre-processor scripting behaviour.

It's not too hard, the demo I mentioned earlier has source if you want
to study it.

Sorry, I don't mean hard on the server-side, I mean hard for
client-side graceful degradation. Though the modification I've
suggested to the <button> specification, or something similar might
help there. Obviously with current browsers relying on <button
type="unknown" ...> to become <button type="submit" ...> isn't
workable.

Well, that works in the latest builds of Opera and Mozilla, and in IE
we will have HTCs to help. So I don't think it is really that much of
a problem.

I don't quite feel comfortable with HTML markup that is *designed* to
expand itself into something else, especially if it can do so when
scripting is disabled. I can't think of any current markup that
behaves in this way, which suggests to me that this would be better
handled by providing good server-side and client-side libraries within
the current HTML spec.
Just because it hasn't been done before doesn't mean it's bad. If we
used that criteria, we'd never get anywhere! :-)

PS: Why allow 'mailto:' and 'javascript:' as form actions?

It's not a matter of allowing it. It's a matter of defining what
happens when they are used. We could define it as doing nothing,
but since it is as easy to define what should happen, and since (at
least in the mailto: case) it has been requested to the point of
being implemented in several UAs,

The problem being that it was implemented, and so people use it,

I assure you, coming from the industry, that UAs almost never
implement anything unless there are customer requests.

and think it works reliably when in fact it doesn't.
Which is why we want a spec (and test suite). To be able to ensure it
works reliably.

Thinking about it, sms(to): would almost certainly have the same
problem.
That has _definitely_ had customer requests.

there doesn't seem to be an advantage to saying it does nothing.

Don't explicity say it does nothing, just don't specify it at all, as
you've done for the telepathy: and pigeon: protocols [1] (poorly supported
in current browsers, I admit). UAs can choose to make them do
something, but a specification should not encourage (by explicitly
saying that it will do something,

If it is undefined, how do you ensure interoperability?

especially without a warning that
there are problems with this) authors to shoot themselves in the
accessibility foot.
What is there that is non-accessible about the current definitions?

If you don't mention every protocol that could possibly be used for
form submission (and you don't) you are saying that the ones you do
mention are okay for it - when some clearly aren't, outside of an
intranet environment.
I don't see why they aren't. Do you have any specific concerns about
specific sections of that part of the spec?

[1] And more seriously, nntp: (at least as valid as mailto: even if it
isn't supported by UAs) is one you don't mention, urn: could
potentially be useful, etc.

Yes, I should indeed define those. I'll add those to my list of things
to look at.
Sorry about the delay replying, I'm doing most of the WHATWG work in
the WHATWG mailing list and only check CIWAH very occasionally.

--
Ian Hickson

[Jim Ley]

On 19 Jul 2004 08:24:35 -0700, ia*********@gmail.com (Ian Hickson)
wrote:

I agree that it would be nice to have better fallback for the date
controls, but nobody has yet come up with a solution that is neat
enough.
Odd, I've come up with one, that both provides degradability to any
sort of HTML the author wants to provide, but also is valid HTML 4.01
or XHTML.

<object name=datetime classid="urn:wtfwg:datetime">
Day:<input name=day>
Month: <input name=month>
Year:<input name=day>
Time:<input name=time>
</object>

(obviously you can put anything inside the object to degrade how you
want)

(The reason that's been rejected by the way, is that the OBJECT
element disappears in the IE6 DOM - no I don't really see the relevace
either.)
But yes, if you don't have JS then you have to rely on the basic
degradation built into WF2, and there isn't much we can do about that.

You've still not yet explained how to do the degradation with JS (the
lack of ability to discriminate between a WF2 UA and one that's not)

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Chris Morris]

ia*********@gmail.com (Ian Hickson) writes:

Chris Morris <c.********@durham.ac.uk> wrote:

ia*********@gmail.com (Ian Hickson) writes:

Well, again, the point here would be that if you don't have to care
about graceful degradation in any case but one (IE6) then you can
special case that one browser and handle it specially (using HTCs, JS,
or whatever).
Except that generally you do have to care about graceful degradation
in more than one case.

That depends. GMail, for instance, only works on a very small number
of browsers. Getting applications like this (and applications are
the primary concern of WHATWG, it's even in the name) working in
legacy UAs is often simply not interesting to application authors.

Adding (decent) alt attributes is very often simply not interesting to
page authors either. ;) Agreed, it's a nice set of extensions for a
controlled intranet where one can dictate the browser, and the ones
with graceful fallback (which is a good proportion) can be used safely
elsewhere.
But yes, if you don't have JS then you have to rely on the basic
degradation built into WF2, and there isn't much we can do about that.
If you're targetting a UA that only supports HTML4,
More a case of making sure it works in said UA than specifically
targeting it.
then no amout of graceful degradation is going to get you the new
features in CSS, DOM, WF2, etc.
Agreed. The point is to find a solution that means those features
ideally aren't missed too much.

(One nice-ish solution I saw over the weekend, and unfortunately I
can't remember where, had <select> dropdowns for day/month/year, but
also (presumably in JS-enabled browsers only [1]) had a little calendar
icon next to these HTML controls - that was nice fallback)

[1] I didn't check.

And by the time support is common, there'll probably be IE 7 to worry
about too.

I doubt IE7 will have any significant changes to its rendering engine.

Depends what significant means. Support for the big missing bits of
CSS 2 (display: table-*, min/max-width, etc.) would be quite
significant in an authoring context.

I think we probably mean the same thing here. What I was meaning was
that this reduces the problem from being "UAs (list)" to "UAs (list),
with JS disabled", but that's still quite a large problem.

Is it?

It isn't much of a problem at all for people writing "Web
Applications", since they're going to need scripting enabled anyway.

For intranet purposes that's acceptable, for internet purposes, IMO
it's not.
For people writing basic forms and aiming to cover 100% of the market,
then I think they'll have their work cut out enough just getting HTML4
to work at all, so that adding WF2 to that won't be much, IMHO.

Well, indeed, they can just ignore the bits that don't fall back well,
and most of the new input types degrade fine.

Except that the effort of parsing date="3rd Septembre 199O" (or even
"3rd September 1990" compared to parsing date_d=3, date_m=9,
date_y=1990 from 3 <select>s) is a big increase in complexity. And
probably a usability decrease for the user.

Not that big. See the script quoted above.

True. That does work fairly well.

> PS: Why allow 'mailto:' and 'javascript:' as form actions?

It's not a matter of allowing it. It's a matter of defining what
happens when they are used. We could define it as doing nothing,
but since it is as easy to define what should happen, and since (at
least in the mailto: case) it has been requested to the point of
being implemented in several UAs,

The problem being that it was implemented, and so people use it,

I assure you, coming from the industry, that UAs almost never
implement anything unless there are customer requests.

Who requested <blink>, I wonder? ;)

and think it works reliably when in fact it doesn't.

Which is why we want a spec (and test suite). To be able to ensure it
works reliably.

Except that mailto: can't work reliably, since it supposes the
capability of the web browser to send email (or to launch an external
application to do the same), which can't be guaranteed.

Likewise, javascript: could be replaced by a server-side (fallback?)
action and an onsubmit event.

Thinking about it, sms(to): would almost certainly have the same
problem.

That has _definitely_ had customer requests.

I can believe that. But then customers request a lot of things,
sometimes overspecifying.

Is there anything that <form action='smsto:1234'> would do that <form
action='sms.cgi?1234'> wouldn't? Assuming sms.cgi did the obvious thing.

there doesn't seem to be an advantage to saying it does nothing.

Don't explicity say it does nothing, just don't specify it at all, as
you've done for the telepathy: and pigeon: protocols [1] (poorly supported
in current browsers, I admit). UAs can choose to make them do
something, but a specification should not encourage (by explicitly
saying that it will do something,

If it is undefined, how do you ensure interoperability?

How do you ensure interoperability for mailto: anyway? It assumes the
existence of a mail client that the UA can communicate with (or has
built-in), which is not a requirement (and wouldn't solve the problem
if it was).

especially without a warning that
there are problems with this) authors to shoot themselves in the
accessibility foot.

What is there that is non-accessible about the current definitions?

On the Javascript one, http://jibbering.com/faq/#FAQ4_24 is a summary.

On mailto: a google search for 'mailto: form action problems' gives
various links describing the problems.

Obviously, neither apply on an intranet.

If you don't mention every protocol that could possibly be used for
form submission (and you don't) you are saying that the ones you do
mention are okay for it - when some clearly aren't, outside of an
intranet environment.

I don't see why they aren't. Do you have any specific concerns about
specific sections of that part of the spec?

See the links above, but basically, both mailto: and javascript: will
fail either silently or with an 'unrecognised protocol' in
non-supporting situations. Now, for some submission protocols this is
unavoidable (say you submit via https in a browser that doesn't
support it, for example) - but mailto: and javascript: both have
perfectly good and more reliable alternatives. (commonly available CGI
scripts, and onsubmit with a server-side fall back respectively)

As a quick test, I made a mailto: form to myself, and submitted it
with Galeon. Nothing happened, and the browser gave no indication of
success or failure, and it remained on the same page [0]. Now I admit,
I haven't told Galeon what program handles email, because I don't use
this machine to handle email - someone using a webmail-only address
would be in a similar situation [1].

Even more extreme, suppose the user doesn't even *have* an email
address. Or are using a browser in a public location and the admins
have sensibly configured it not to email anything, etc.

[0] Unless I'm misreading, that's what a WF2 UA would do having
successfully sent the email (though it would ask for confirmation
first).

[1] Indeed, even worse situation, since I can (if I could find the
setting, which I can't right now) presumably configure Galeon to send
mailto: requests on to an external program - but someone with
webmail-only email would have no good solution.

--
Chris

[Claire Tucker]

On Mon, 19 Jul 2004 16:26:45 GMT, ji*@jibbering.com (Jim Ley) wrote:

On 19 Jul 2004 08:24:35 -0700, ia*********@gmail.com (Ian Hickson)
wrote:

I agree that it would be nice to have better fallback for the date
controls, but nobody has yet come up with a solution that is neat
enough.

Odd, I've come up with one, that both provides degradability to any
sort of HTML the author wants to provide, but also is valid HTML 4.01
or XHTML.

<object name=datetime classid="urn:wtfwg:datetime">
Day:<input name=day>
Month: <input name=month>
Year:<input name=day>
Time:<input name=time>
</object>

I'm almost tempted to say that all of the new stuff should be written
in this way. The trend of bolting poorly-designed new elements into
HTML going back to Mosaic's IMG is why we're in the mess we're in
today.

OBJECT is a clean way of adding new "active features" to HTML, with
obvious backward-compatibility benefits.

This is certainly much cleaner than just adding more "modes" to the
already badly-designed and overloaded INPUT element and letting the
server sort out the ensuing chaos.

The only cases I can see where this is insufficient is for new
elements which require child elements, but they can just be carefully
implemented *as* new elements, since old browsers will ignore them.

All the best,
-Claire

[Chris Morris]

Claire Tucker <fa**@invalid.invalid> writes:

On Mon, 19 Jul 2004 16:26:45 GMT, ji*@jibbering.com (Jim Ley) wrote:

<object name=datetime classid="urn:wtfwg:datetime">
Day:<input name=day>
Month: <input name=month>
Year:<input name=day>
Time:<input name=time>
</object>

I'm almost tempted to say that all of the new stuff should be written
in this way. The trend of bolting poorly-designed new elements into
HTML going back to Mosaic's IMG is why we're in the mess we're in
today.

OBJECT is a clean way of adding new "active features" to HTML, with
obvious backward-compatibility benefits.

Agreed. There is the issue of buggy support in certain older browsers
(I'm told IE6 isn't really good enough to let it be used as an <img>
replacement, but never get around to testing that).

There's also the advantage that any *existing* browser with a plugin
architecture can be given <object classid="foo"> support far more
easily than it can be given support for a whole new <element>.
This is certainly much cleaner than just adding more "modes" to the
already badly-designed and overloaded INPUT element and letting the
server sort out the ensuing chaos.

The only cases I can see where this is insufficient is for new
elements which require child elements, but they can just be carefully
implemented *as* new elements, since old browsers will ignore them.

Hmm, not always true. In the case (consider trying to implement
<select> now if it hadn't been around for ages already) of an element
that requires both child elements and text content, this may not
always be possible. But a lot of the time, yes. Of course, you could
argue that <option> should have been implemented as <option
label='...' value='...' /> from the start, and you'd probably be right.

--
Chris

[Ian Hickson]

Chris Morris <c.********@durham.ac.uk> wrote in message news:<87************@dinopsis.dur.ac.uk>...

And by the time support is common, there'll probably be IE 7 to worry
about too.
I doubt IE7 will have any significant changes to its rendering engine.

Depends what significant means. Support for the big missing bits of
CSS 2 (display: table-*, min/max-width, etc.) would be quite
significant in an authoring context.

I doubt IE7 will have any significant changes to its rendering engine.
I would count any new CSS features, especially something as big as new
display types, to be significant.

I think we probably mean the same thing here. What I was meaning was
that this reduces the problem from being "UAs (list)" to "UAs (list),
with JS disabled", but that's still quite a large problem.

Is it?

It isn't much of a problem at all for people writing "Web
Applications", since they're going to need scripting enabled anyway.

For intranet purposes that's acceptable, for internet purposes, IMO
it's not.

I think you may be misunderstanding the concept of "application". We
are talking about quite involved client-side applications here.

> > PS: Why allow 'mailto:' and 'javascript:' as form actions?
>
> It's not a matter of allowing it. It's a matter of defining what
> happens when they are used. We could define it as doing nothing,
> but since it is as easy to define what should happen, and since (at
> least in the mailto: case) it has been requested to the point of
> being implemented in several UAs,

The problem being that it was implemented, and so people use it,

I assure you, coming from the industry, that UAs almost never
implement anything unless there are customer requests.

Who requested <blink>, I wonder? ;)

Can't speak for <blink>, but <marquee> was requested by most of the
far east, especially the Chinese.

and think it works reliably when in fact it doesn't.

Which is why we want a spec (and test suite). To be able to ensure it
works reliably.

Except that mailto: can't work reliably, since it supposes the
capability of the web browser to send email (or to launch an external
application to do the same), which can't be guaranteed.

It can if it is made into a requirement. (That's like saying that
requiring PNG support presupposes that the UA can decode PNG images.)

Thinking about it, sms(to): would almost certainly have the same
problem.

That has _definitely_ had customer requests.

I can believe that. But then customers request a lot of things,
sometimes overspecifying.

Is there anything that <form action='smsto:1234'> would do that <form
action='sms.cgi?1234'> wouldn't? Assuming sms.cgi did the obvious thing.

The primary thing would be that the latter wouldn't charge the same
account. Replies would go to the wrong place, too.

> there doesn't seem to be an advantage to saying it does nothing.

Don't explicity say it does nothing, just don't specify it at all, as
you've done for the telepathy: and pigeon: protocols [1] (poorly supported
in current browsers, I admit). UAs can choose to make them do
something, but a specification should not encourage (by explicitly
saying that it will do something,

If it is undefined, how do you ensure interoperability?

How do you ensure interoperability for mailto: anyway?

If it's defined, it can be tested to the spec.

It assumes the
existence of a mail client that the UA can communicate with (or has
built-in), which is not a requirement (and wouldn't solve the problem
if it was).
It's a requirement if you support mailto:, just like an HTTP stack is
a requirement if you support http:.

especially without a warning that
there are problems with this) authors to shoot themselves in the
accessibility foot.

What is there that is non-accessible about the current definitions?

On the Javascript one, http://jibbering.com/faq/#FAQ4_24 is a summary.

Granted.

On mailto: a google search for 'mailto: form action problems' gives
various links describing the problems.
Most of which are due to its lack of specification.

See the links above, but basically, both mailto: and javascript: will
fail either silently or with an 'unrecognised protocol' in
non-supporting situations.
Same as any other protocol that isn't supported.

but mailto: and javascript: both have
perfectly good and more reliable alternatives. (commonly available CGI
scripts, and onsubmit with a server-side fall back respectively)

True.

Anyway, the point is just that if they are going to be supported
anyway (which they are), we might as well at least try to get them
interoperably supported by having a spec that defines them.

--
Ian Hickson