欢迎评论Web Forms 2.0提案 [英] Comments welcome on Web Forms 2.0 proposal
问题描述
我们这群人已经非正式地向HTML4'的表格章节提出了扩展
的建议，并希望从更广泛的范围获得输入
现在我们认为我们的提案草案正处于稳定阶段：
http://www.whatwg.org/specs/web-form...-for-comments/
我们提出的一些功能包括
日期，时间，电子邮件地址和数字的新输入控件类型;一个新的客户端验证
模型;一种根据需要标记输入控件的方法;重复模型;
控制表单提交，以便更新表单而不是
导致页面被替换;更多。
如果您对此提案有任何意见或建议，请将它们发送到我们的邮件列表：
http://whatwg.org/mailing-list
谢谢，
-
Ian Hickson U + 1047E）\ ._。， - ，''``` 。 fL
http://ln.hixie.ch/ U + 263A / ，_ .. \ _ \;`。。，。
不可能的事情需要更长的时间。 `._.-（，_..'' - （，_ ..''` - 。;。''
< a href =mailto：ia ********* @ gmail.com> ia ********* @ gmail.com （Ian Hickson）写道：我们一群人非正式地致力于HTML4'表格章节的扩展提案，并希望从更广泛的人群中获得意见，因为我们认为我们的提案草案正处于稳定阶段：
http://www.whatwg.org/specs/web-form...-for-comments/
一些功能我们建议包括日期，时间，电子邮件地址和数字的新输入控件类型;新的客户端验证模型;根据需要标记输入控件的方法;重复模型;
控制表单提交，以便可以更新表单而不是
导致页面被替换;以及更多。
我认为这里存在一些大的向后兼容问题：
最值得注意的是，< input type =''的行为意外的''name =''foo''...>
显示为文本字段：lynx 2.8，links2，Gecko，IE，Konqueror，Opera，Dillo
忽略：w3m 0.5
所以，首先是一些严重的问题，一些UA将不会显示这些意外的内容类型。我找到了一个，可能在那里
是其他人。其次，UA的问题是显示它们
作为文本（即现有的） - 基于时间的属性是
令人难以置信的用户不友好的进入比较通过构建多个选择或使用
多个文本输入，每个部分的日期时间，可以合理地实现友好的方法。
我想不出一种设置日期时间输入的方法，除非你要求客户端或服务器具有相当强大的字符串，否则优雅地降低
。不可避免的时间处理器：
开始日期：_3rd_June_2001___
（或者你可以拒绝它，直到用户猜到你需要
特定（用户不友好的）格式，或者您可以通过
格式指定该格式，因此将此人与支持UA混淆。
''重复''系统同样存在问题，因为按钮不会在当前的UA中工作（和f allback JS也是不可靠的。）
如果没有一个好的方法来获得优雅的降级（我可能会因为你想要如何获得它而错过了一些东西，但是我不能看到
草案中的任何内容都表明会发生什么），使用这些
扩展程序是非常危险的，除非广泛的浏览器支持
存在。如果没有需求就不存在，因为人们不能在生产环境中使用它们来承担风险。
虽然更多类型的表单控件，表单中更强的数据输入，''重复''属性的
功能等等都是件好事，我
别感觉客户端是解决问题的最佳场所，因为我没有看到一个合理的方式来获得优雅的降级[1]。服务器端
用一种具有良好表单库的语言似乎是更好的地方来解决这些问题。
[1]好的，我能想到一个。创建新的内容类型
text / x-extendedwebforms-html。使用< object>使用手动构建的
用户友好表格作为后备。然而，这给予了很多额外的
作者努力以获得非常小的用户利益，这也没有用。
不那么重要 - 关于''autocomplete''：
" UA可能允许用户禁用对此
属性的支持。默认情况下必须启用支持，并且不应轻易访问
禁用支持的能力，因为如果支持此用户，则会对用户产生重大的安全隐患。 />
属性被禁用。
或者，UA应该被允许默认自动完成为''off''
所有元素。很多我的UA通过没有任何类型的
自动完成功能来做到这一点。这没有任何安全保障
意义。
如果您对此提案有任何意见或建议，请将它们发送到我们的邮件列表：
你问这里，你得到这里的评论。
-
克里斯
Chris Morris< c。******** @ durham.ac.uk>在消息新闻中写道：< 87 ************ @ dinopsis.dur.ac.uk> ...
http：/ /www.whatwg.org/specs/web-form...-for-comments/
我认为这里存在一些大的向后兼容问题：
最值得注意的是，< input type =''unexpected''name =''foo''的行为......>
显示为文本字段：lynx 2.8，links2，Gecko，IE， Konqueror，Opera，Dillo
忽略：w3m 0.5
所以，首先是一些严重的问题，一些UA不会显示这些意想不到的内容类型。
这是w3m 0.5中的一个错误。 HTML4非常清楚，默认值为
" text"。
其次，显示它们的UA存在问题
作为文本（即现有的） - 通过构建多个选择或使用多个文本输入，与合理的友好方法相比，基于时间的属性对用户来说非常不友好。对于日期时间的每个部分。
对于传统UA，服务器可以接受许多不同形式的输入，并尝试解析用户的输入。客户端
Javascript可以在这种情况下提供帮助，例如用几个控件替换一个
控件，或者在
上验证用户的输入。
客户端。
不可否认，这些选项都不如简单地拥有传统
UAs显示日历控件（或类似），但是如你所说：
我想不出设置日期时间输入会降低优雅度的方法
上面描述的解决方案类似于你的建议：
要求客户或服务器拥有相当强大的字符串>时间处理器，这是不可避免的：
开始日期：_3rd_June_2001___
从短期来看，虽然WF2 UA仍然很少见，但作者可能更愿意使用< select> s等;这个想法是
一旦大多数非IE浏览器支持WF2，作者可以使用WF2
功能，IE6通过JavaScript或HTC库支持
（这些已经在开发中）。
重复系统同样存在问题，因为按钮不会在当前的UA中工作（和后备JS也是不可靠的）。
同样，在符合HTML4标准的UA中，按钮应该回退为提交按钮，允许服务器处理重复块
代。有一个演示，表明这有效：
http ：//whatwg.org/demos/repeat-01/
不幸的是，似乎唯一符合HTML4标准的UA是
Mozilla。
优雅的降级绝对是我们正在考虑的事情。重要的是
。不可否认，这并不容易，但我们认为对于大多数情况我们都有一些很好的解决方案。
更不重要的是 - 关于''autocomplete''：
" UA可能允许用户禁用对此
属性的支持。默认情况下必须启用支持，并且不应轻易访问禁用支持的功能，因为如果禁用对此
属性的支持，则会对用户产生重大安全隐患。
或者，应该允许UA默认自动完成所有元素的''off''
。相当多的我的UA通过没有任何类型的
自动完成功能来做到这一点。这没有任何安全意义。
好吧，支持开启。值不需要支持
自动完成，所以规范确实已经允许这个。
如果您对此提案有任何意见或建议，请将它们发送到我们的邮件列表：
您在这里问，您在这里得到了评论。
这也有效。谢谢！
-
Ian Hickson
ia ********* @ gmail.com （Ian Hickson）写道：Chris Morris< c.********@durham.ac.uk>写了http://www.whatwg.org/specs/web-form...-for-comments/
我认为有一些这里存在大的向后兼容性问题：
最值得注意的是，< input type =''unexpected''name ='''foo''...>
显示为文本字段：lynx 2.8，links2，Gecko，IE，Konqueror，Opera，Dillo
忽略：w3m 0.5
所以，首先是一些UA会出现严重问题只是没有显示这些意想不到的内容类型。
这是w3m 0.5中的一个错误。 HTML4很明显，默认是
text。
如果没有指定属性，那是默认值，是的。如果属性存在，则没有
*要求*默认返回文本
但是无法识别，尽管_informative_附录B建议
UA应该在错误恢复中执行此操作。
不常见的行为，是的，但我不认为这是一个真正的错误。
其次，UAs的问题是将它们显示为文本（即现有的） - 基于时间的属性令人难以置信通过构建多个选择或使用多个文本输入（日期时间的每个部分都有一个），相比于合理友好的方法，用户不友好地进入。
对于传统UA，服务器应该接受许多不同形式的输入并尝试解析用户的输入。
这确实使得但是，服务器端编码要复杂得多。
客户端在这种情况下，Javascript可以提供帮助，例如用一些控件替换一个控件，或在客户端验证
用户的输入。
是的。虽然这只会将优雅的降级问题转移到另一个地方。
要求客户端或服务器具有相当强大的字符串 - >时间
处理器不可避免：
开始日期：_3rd_June_2001 ___
从短期来看，虽然WF2 UAs仍然很少见，但有可能<作者更愿意使用< select>等等;
想法是，一旦大多数非IE浏览器支持WF2，作者可以使用WF2功能，IE6通过支持
JavaScript或HTC库（这些已经在开发中）。
最近的零日ActiveX / Javascript攻击，IE6只是
虽然预计在IE中启用Javascript是
不合理，但
一直受到打击。当然，人们会有。无论如何，Javascript只是
移动到优雅降级问题的地方。
''repeat''系统同样存在问题，因为按钮不会在当前的UA中工作（并且后备JS也不可靠）。
同样，在符合HTML4的UA中，按钮应该回退到正在提交按钮，允许服务器处理重复块生成。有一个演示，表明这有效：
http ：//whatwg.org/demos/repeat-01/
不幸的是，似乎唯一符合HTML4标准的UA就是Mozilla。
再次，这似乎依赖于_informative_
附录B中的行为，未识别的属性值应被视为
默认值价值 - 它不一定是浏览器错误，他们不是，
并不要求符合HTML4标准的UA这样做[1]。
[1]除非我在规范中的其他地方遗漏了什么，但是
我已经检查了明显的地方。
优雅降级绝对是我们正在考虑的重要事项。不可否认，这并不容易，但我们认为对于大多数情况我们都有一些非常好的解决方案。
有足够的服务器端处理大部分都可以做到，是的。它确实为服务器端程序员带来了更多的负担，以确保他们有一个强大的日期解析器等，但这仅仅涉及
获得一个高质量的图书馆。
重复似乎是最难以正常工作的，但是，
我认为部分是因为它并不像HTML的任何其他部分，但是
与预处理器脚本行为有更多的相似之处。
PS：为什么允许''mailto： ''和''javascript ：''作为表单操作？后者
应该总是可以重复（具有更好的后备），使用
onSubmit，前者有足够的记录良好的问题和
有足够的服务器端脚本来完成这项工作。
-
Chris
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. `._.-(,_..''--(,_..''`-.;.''
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
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
ia*********@gmail.com (Ian Hickson) writes:Chris Morris <c.********@durham.ac.uk> wrotehttp://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
这篇关于欢迎评论Web Forms 2.0提案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
