[whatwg] Three concerns regarding HTML5 form validation
Hi, I don't know if this can/should be specified in the spec or if it's up to the browser implementors but here's some concerns I have regarding HTML5 form validation; 1) Is there a reason why native form validation seems to be tied to the click of the submit button? Submitting the form using JavaScript does not seem to trigger HTML5 form validation in either Firefox, Opera or the Webkit browsers (I haven't checked how IE10 behaves yet). To me this seems like an unnecessary limitation. 2) How about adding a method to programmatically display the native validation error messages instead of waiting for the form submit click? We already have a way to (more or less) detect if the form is valid or not, but no way of forcing the native validation error messages to render without using some submit button click hack. 3) Should there be a way of detecting if the browser actually understood all input element types? Browsers believe that a form is valid even when it contains invalid data for input types the browser doesn't understand. (Like the string 'asdf' in an input type=number field in Firefox.) So checking if the browser has a checkValidity method is not a guarantee that the form validates according to the HTML5 specified constraints. If there was a method or property like form.containsUnknownInputs and maybe element.isUnknownInput (not the best names, but you get the idea) we could determine the best way to handle further validation. I would love to hear your opinions on these issues which to me are quite serious impediments for a smooth validation implementation experience for web developers. Best regards, Matias Larsson
Re: [whatwg] Three concerns regarding HTML5 form validation
On Mon, 26 Sep 2011 13:58:52 +0200, Matias matia...@gmail.com wrote: 1) Is there a reason why native form validation seems to be tied to the click of the submit button? Submitting the form using JavaScript does not seem to trigger HTML5 form validation in either Firefox, Opera or the Webkit browsers (I haven't checked how IE10 behaves yet). To me this seems like an unnecessary limitation. Initially submit() caused validation to be done but that broke deployed content. What is the reason for wanting this? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Three concerns regarding HTML5 form validation
On 09/26/2011 01:58 PM, Matias wrote:
1) Is there a reason why native form validation seems to be tied to the click
of the submit button? Submitting the form using JavaScript does not seem to
trigger HTML5 form validation in either Firefox, Opera or the Webkit browsers
(I haven't checked how IE10 behaves yet). To me this seems like an unnecessary
limitation.
.submit() by-passes all possible submit cancellation per spec: there is
no submit event sent and given that the validation checks were done in
the submit event handler, it seems reasonable to disable the automatic
HTML5 form validation.
2) How about adding a method to programmatically display the native validation
error messages instead of waiting for the form submit click? We already have a
way to (more or less) detect if the form is valid or not, but no way of forcing
the native validation error messages to render without using some submit button
click hack.
I guess submitControl.click() should work and isn't that hacky.
3) Should there be a way of detecting if the browser actually understood all
input element types? Browsers believe that a form is valid even when it
contains invalid data for input types the browser doesn't understand. (Like the
string 'asdf' in an input type=number field in Firefox.)
So checking if the browser has a checkValidity method is not a guarantee that
the form validates according to the HTML5 specified constraints. If there was a
method or property like form.containsUnknownInputs and maybe
element.isUnknownInput (not the best names, but you get the idea) we could
determine the best way to handle further validation.
So, theoretically, you should be able to do:
input.type = foo;
if (input.type == foo) {
}
But last I checked Webkit brokes that by recognizing types it does not
[fully] understood. Though, maybe the validation is done as expected.
However, I don't think it would be a good idea to have a website using
only HTML5 Form Validation for a wide audience. It is better to have a
path for browsers who do not understand HTML5 Forms Validation.
Basically, that means keeping the checks in the submit event handler.
These checks will be done for non-supported types too.
--
Mounir
Re: [whatwg] Three concerns regarding HTML5 form validation
Hi Anne, The reason is I would love a simple and clear way to trigger form validation (as well as displaying validation errors) programmatically in web apps. As the current implementation stands, the submit button becomes a requirement if you want to utilize native browser form validation. Of course I don't see the big picture with legacy content etc. like you guys, but an example could be a web app using menu and command elements with different application flows/form targets depending on the command. The developer could have listened to command events, triggering form validation where necessary. What the developer has to do instead is; 1) Add a hidden submit button to the form. 2) On command events, trigger a fake click on the hidden submit button to activate native form validation. 3) Capture the submit event and cancel it to prevent the form from posting. 4) Add code to block form submits when the user presses the return key while typing in an input element. Clearly a first world problem, but not having to use workarounds like that is something I believe would benefit the community. But if there is no other way to solve this maybe you should add that a submit button is required for validation to work at all to the spec, just to make things clear? Best regards, Matias On 26 sep 2011, at 15:35, Anne van Kesteren wrote: On Mon, 26 Sep 2011 13:58:52 +0200, Matias matia...@gmail.com wrote: 1) Is there a reason why native form validation seems to be tied to the click of the submit button? Submitting the form using JavaScript does not seem to trigger HTML5 form validation in either Firefox, Opera or the Webkit browsers (I haven't checked how IE10 behaves yet). To me this seems like an unnecessary limitation. Initially submit() caused validation to be done but that broke deployed content. What is the reason for wanting this?
[whatwg] Making selectionDirection platform-independent
The spec ( http://www.whatwg.org/specs/web-apps/current-work/#dom-textarea/input-selectiondirection) currently allows for platform-specific differences in selectionDirection that limit its usefulness. Tightening the requirements to be platform-independent will allow selectionDirection to be used for determining the caret location in a selection. On Windows, selectionDirection indicates which end of the selection the caret should be placed. On Mac, selectionDirection works similarly when the selection is modified using shift+arrow key, but the spec does not require the same functionality when clicking and dragging a selection. This leaves no cross-platform way to determine the correct caret location! It looks like editors using a textarea (such as codemirror) are currently working around this by not drawing a cursor when there is a selection. Are there arguments against making selectionDirection explicitly forward or backward if the user modifies the selection, regardless of platform? Philip
Re: [whatwg] Making selectionDirection platform-independent
On Mon, 26 Sep 2011, Philip Rogers wrote: Are there arguments against making selectionDirection explicitly forward or backward if the user modifies the selection, regardless of platform? It wouldn't match the platform on platforms that don't do that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Making selectionDirection platform-independent
On Mon, Sep 26, 2011 at 9:14 AM, Philip Rogers p...@google.com wrote: The spec ( http://www.whatwg.org/specs/web-apps/current-work/#dom-textarea/input-selectiondirection ) currently allows for platform-specific differences in selectionDirection that limit its usefulness. Tightening the requirements to be platform-independent will allow selectionDirection to be used for determining the caret location in a selection. No. The property is platform dependent. It's just that UAs on Windows and Linux don't use none in most cases. On Windows, selectionDirection indicates which end of the selection the caret should be placed. On Mac, selectionDirection works similarly when the selection is modified using shift+arrow key, but the spec does not require the same functionality when clicking and dragging a selection. Yes, but this is required to match Mac's native selection behavior. Always giving direction to selection is neither desirable nor feasible at least in WebKit. A directionless selection allows users to extend it to either direction. e.g. say we have a directionless selection on r in world. Then pressing left-arrow key results in selecting or and pressing right arrow key results in selecting rl. This leaves no cross-platform way to determine the correct caret location! It looks like editors using a textarea (such as codemirror) are currently working around this by not drawing a cursor when there is a selection. We can't assume that the caret is always rendered on either side since the caret is never rendered with a range selection (not collapsed) on Mac. Are there arguments against making selectionDirection explicitly forward or backward if the user modifies the selection, regardless of platform? Yes. See above. - Ryosuke
Re: [whatwg] Making selectionDirection platform-independent
On Mon, Sep 26, 2011 at 9:34 AM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Sep 26, 2011 at 9:14 AM, Philip Rogers p...@google.com wrote: The spec ( http://www.whatwg.org/specs/web-apps/current-work/#dom-textarea/input-selectiondirection ) currently allows for platform-specific differences in selectionDirection that limit its usefulness. Tightening the requirements to be platform-independent will allow selectionDirection to be used for determining the caret location in a selection. No. The property is platform dependent. It's just that UAs on Windows and Linux don't use none in most cases. s/platform dependent/platform independent/ Also see the discussion on http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029814.html - Ryosuke.
Re: [whatwg] Making selectionDirection platform-independent
On Mon, 26 Sep 2011 16:14:39 -, Philip Rogers p...@google.com wrote: It looks like editors using a textarea (such as codemirror) are currently working around this by not drawing a cursor when there is a selection. In ignorance of the specificatory problem you describe, this seems sane enough to me. Whether to draw or not to draw a curser when there's a selection should of course be up to users. I'll refrain from thinking about the behaviour of multiple selections.
[whatwg] Fixing two security vulnerabilities in registerProtocolHandler
I was recently experimenting with the registerProtocolHandler (RPH)
API and came across a couple of security gotchas that make it hard to
safely use the API. One of these is already known, but AFAICT, hasn't
been fixed yet. I haven't seen the other discussed yet.
The Mozilla blog post that introduces the registerProtocolHandler API
makes use of window.parent.postMessage to send a response from the RPH
handler back to the client page. In the example code, the targetOrigin
for this postMessage invocation is '*', while also noting that this is
not secure. AFAICT, there is no API that the intent handler can
reliably use to determine the correct targetOrigin for this
postMessage invocation. I suggest fixing this problem by adding a new
readonly DOMString that contains the correct origin for the
postMessage invocation; perhaps document.origin. So the response
invocation would then be coded as:
window.parent.postMessage('my response data', document.origin);
Perhaps a different name or location is better for this field, so I'll
defer to the editor's judgment.
The second problem with RPH is that the handler page doesn't have a
way of reliably getting the URL of the content to be handled from the
browser. In order to work in offline scenarios, the RPH handler must
put the %s placeholder in the fragment of its handler's URL.
Unfortunately, this means that other content in the browser could
modify the content URL before the handler reads it. For example, an
attacker could open a window on a victim web page. The victim web page
then opens an iframe on a content URL that triggers RPH. The
attacker then navigates the iframe so that its window.location
contains a different content URL. The intent handler sees a request
coming from the victim page, but with a content URL specified by the
attacker. A related problem is that the intent handler has no way to
distinguish whether its URL was loaded via the browser's RPH handling,
or whether the client page directly navigated to the intent handler's
URL. Both of these problems could be fixed by adding another readonly
DOMString to the API that contains the %s data for the RPH invocation.
This new field must be in a location that can only be set by the
browser, such as window.navigator.action (taking the action name
from the form element). Safe intent handler code is then:
if (window.navigator.action) {
// Handle navigation to the URL in window.navigator.action
myCustomContentLoader(window.navigator.action);
window.parent.postMessage('did it!', document.origin);
}
Again, I defer to the editors on the best name and location for this
new readonly DOMString. I'm mostly interested in seeing these two
security issues in RPH cured.
Thanks,
--Tyler
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On 9/26/11 2:09 PM, Tyler Close wrote: AFAICT, there is no API that the intent handler can reliably use to determine the correct targetOrigin for this postMessage invocation. That's correct, though as long as you don't use too much in the way of about:blank or javascript: or data: URIs, passing window.location.href will do the right thing. I suggest fixing this problem by adding a new readonly DOMString that contains the correct origin for the postMessage invocation; perhaps document.origin. I would be somewhat in favor of this. -Boris
[whatwg] focusability of visibility:hidden and display:none elements WAS: Autofocus readonly Input Elements
On Sat, Sep 24, 2011 at 12:45 AM, Kaustubh Atrawalkar kaust...@motorola.com
wrote:
On Sat, Sep 24, 2011 at 1:57 AM, Ojan Vafai o...@chromium.org wrote:
Kaustubh, it would help if you could see what the behaviors for
disabled/hidden inputs are in various browsers as well.
Checked with other browsers and none support autofocusing of
disabled/hidden elements. As they might be following the specs above.
TL;DR version: The spec does not currently match what browsers do for
programmatic focusability, at least as per what the browser reports for
document.activeElement.
It's not clear to me whether the spec should change or the browsers. Some
relevant browser bugs:
https://bugs.webkit.org/show_bug.cgi?id=40338
https://bugzilla.mozilla.org/show_bug.cgi?id=570835
*8.3.2 Focus management*
An element is *focusable* if the user agent's default behavior allows it to
be focusable or if the element is specially focusable, but only if the
element is either being rendered or is a descendant of a canvas element that
represents embedded content.
As the test below shows, non-rendered divs with a tabindex are still
focusable in all browsers.
input elements whose type attribute are not in the Hidden state and that
are not disabled
It seems that all browsers also don't make visibility:hidden and
display:none input elements focusable.
The only disagreement between browsers seems to be that Opera allows
focusing disabled input elements and IE8 throws an exception when focusing
an unfocusable element.
DETAILS:
*
http://plexode.com/eval3/#ht=%3Cinput%20id%3Dtext%20type%3D%22%22%3E%3C%2Finput%3E%0A%3Cinput%20id%3Dhidden%20type%3D%22hidden%22%3E%3C%2Finput%3E%0A%3Cinput%20id%3Ddisabled%20disabled%3E%3C%2Finput%3E%0A%3Cinput%20id%3Dreadonly%20readonly%3E%3C%2Finput%3E%0A%3Cinput%20id%3Dvisiblity-hidden%20style%3D%22visibility%3Ahidden%22%3E%3C%2Finput%3E%0A%3Cinput%20id%3Ddisplay-none%20style%3D%22display%3Anone%22%3E%3C%2Finput%3E%0A%3Cdiv%20id%3Ddiv-hidden%20sytle%3D%22visibility%3Ahidden%22%20tabindex%3D1%3E%3C%2Finput%3E%0A%0A%3Cdiv%20id%3Dlogger%3E%3C%2Fdiv%3Eohh=1ohj=1jt=var%20result%20%3D%20''%3B%0A%0Afunction%20isFocusable(type)%20%7B%0A%20%20%20%20var%20element%20%3D%20document.getElementById(type)%3B%0A%20%20%20%20result%20%2B%3D%20type%20%2B%20'%20is'%3B%0A%20%20%20%20try%20%7B%0A%20%20%20%20%20%20%20%20element.focus()%3B%0A%20%20%20%20%20%20%20%20if%20(element%20!%3D%20document.activeElement)%0A%20%20%20%20%20%20%20%20%20%20%20%20result%20%2B%3D%20'%20not'%3B%0A%20%20%20%20%7D%20catch%20(e)%20%7B%0A%20%20%20%20%20%20result%20%2B%3D%20'%20not%20(error%20thrown)'%3B%0A%20%20%20%20%7D%0A%20%20%20%20result%20%2B%3D%20'%20focusable%3Cbr%3E'%3B%0A%7D%0A%0AisFocusable('text')%3B%0AisFocusable('hidden')%3B%0AisFocusable('disabled')%3B%0AisFocusable('readonly')%3B%0AisFocusable('visiblity-hidden')%3B%0AisFocusable('display-none')%3B%0AisFocusable('div-hidden')%3B%0A%0Adocument.getElementById('logger').innerHTML%20%2B%3D%20result%3Bojh=1ojj=1ms=100oth=0otj=0cex=1
*
Firefox 6, Chrome 16, IE9:
text is focusable
hidden is not focusable
disabled is not focusable
readonly is focusable
visiblity-hidden is not focusable
display-none is not focusable
div-hidden is focusable
div-display-none is focusable
Opera 11.51:
text is focusable
hidden is not focusable
disabled is focusable
readonly is focusable
visiblity-hidden is not focusable
display-none is not focusable
div-hidden is focusable
div-display-none is focusable
IE8:
text is focusable
hidden is not (error thrown) focusable
disabled is not (error thrown) focusable
readonly is focusable
visiblity-hidden is not (error thrown) focusable
display-none is not (error thrown) focusable
div-hidden is focusable
div-display-none is focusable
[whatwg] [MIME Sniffing] Editorial feedback
Otherwise, if the octets in s starting at pos match any of the sequences of
octets in the first column of the following table, then the user agent MUST
follow the steps given in the corresponding cell in the second column of the
same row. |
What's the stray `|` character at the end of that doing?
The ToC feels double spaced, is that normal?
Would you mind quoting your attributes in source? Things like
class=no-num or href=#web-data scare me. It's easier if you just quote
all attributes :)
Also, I generally recommend `span ...x/span ` over `span ...x
/span` - i.e. trailing space outside of span (see toc)
pMany web servers supply incorrect Content-Type header fields with their
HTTP
Can you mark up `Content-Type` in something which results in roughly
typewriter font?
s/user agents/User Agents/ as in:
responses. In order to be compatible with these servers, user agents consider
Without a clear specification of how to sniff the media type, each user
agent implementor was forced to reverse engineer the behavior of the other
user agents and to develop
s/the other/other/ -- there are some UAs who were ignored when the
sniffing of a given UA was developed :)
their own algorithm
I'm not sure if `algorithm` here belongs in singular or plural, I got
distracted :)
an HTTP response to be interpreted as one media type but some user agents
interpret the responses as another media type.
s/responses/response/ (agreement with first part)
However, if a user agent does interpret a low-privilege media type, such as
image/gif, as a high-privilege media type, such as text/html, the user agent
has created a privilege escalation vulnerability in the server.
s/, the user agent/, then the user agent/
I believe abarth has addressed the above.
This document describes a content sniffing algorithm that carefully balances
the compatibility needs of user agent implementors with the security
constraints.
`the security constraints` is problematic, I don't think `the`
references anything
so either drop `the`, or provide a reference :/
and metrics collected from implementations deployed to a sizable number of
users .
s/ ././
(such as strip any leading space characters or return false and abort
these steps) are to be interpreted with the meaning of the key word (MUST,
SHOULD, MAY, etc)
s/etc/etc./g
official-type should probably be given some styling -- preferably
not the same styling as Content-Type
(Such messages are invalid according to RFC2616.
s/./.)/
The rfcs should be href references of some sort :)
For octets received via HTTP, the Content-Type HTTP header field, if present,
indicates the media type. Let the official-type be the media type indicted by
the HTTP Content-Type header field, if present. If the Content-Type header
field is absent or if its value cannot be interpreted as a media type (e.g.
because its value doesn't contain a U+002F SOLIDUS ('/') character), then
there is no official-type. (Such messages are invalid according to RFC2616.
If an HTTP response contains multiple Content-Type header fields, the User
Agent MUST use the textually last Content-Type header field to the
official-type. For example, if the last Content-Type header field contains
the value foo, then there is no official media type because foo cannot be
interpreted as a media type (even if the HTTP response contains another
Content-Type header field that could be interpreted as a media type).
The for example part here applies to the previous paragraph, the
sentence needs to be moved to the paragraph before the instruction for
multiple header fields.
FTP RFC0959
Is there a reason for the leading 0?
Comparisons between media types, as defined by MIME specifications, are done
in an ASCII case-insensitive manner. [RFC2046]
You need to somehow note that this is merely a note about mime
equivalence and doesn't relate to how the spec works.
If the official-type ends in +xml, or if it is either text/xml or
application/xml, then let the sniffed-type be the official-type and abort
these steps.
Please mark up `sniffed-type` and `official-type`
If the official-type is an image type supported by the User Agent (e.g.,
image/png, image/gif, image/jpeg, etc), then jump to the images
section below.
s/etc//
If none of the first n octets are binary data octets then let the
sniffed-type be text/plain and abort these steps.
Binary Data Byte Ranges
You don't actually define a `binary data octet` as any item within the
ranges defined in the `binary data byte ranges`.
If the first octets match one of the octet sequences in the pattern column
of the table in the unknown type section below, ignoring any rows whose
cell in the security column says scriptable (or n/a), then let the
sniffed-type be the type given in the corresponding cell in the sniffed
type column on that row and abort these steps.
If you could make `unknown type section` a link to the
