[whatwg] Forms feedback
Ian Hickson
ian at hixie.ch
Tue Apr 6 02:00:48 PDT 2010
On Thu, 21 Jan 2010, NARUSE, Yui wrote:
> In 4.10.19.4 URL-encoded form data, The
> application/x-www-form-urlencoded encoding algorithm,
> it says:
>
> > For each character in the entry's name and value, apply the following
> > subsubsteps:
> >
> > If the character isn't in the range U+0020, U+002A, U+002D, U+002E,
> > U+0030 to U+0039, U+0041 to U+005A, U+005F, U+0061 to U+007A then
> > replace the character with a string formed as follows: Start with the
> > empty string, and then, taking each byte of the character when
> > expressed in the selected character encoding in turn, append to the
> > string a U+0025 PERCENT SIGN character (%) followed by two characters
> > in the ranges U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) and
> > U+0041 LATIN CAPITAL LETTER A to U+0046 LATIN CAPITAL LETTER F
> > representing the hexadecimal value of the byte (zero-padded if
> > necessary).
> >
> > If the character is a U+0020 SPACE character, replace it with a single
> > U+002B PLUS SIGN character (+).
>
> This means, U+9670, encoded as "¥x89¥x41" in Shift_JIS, must be encoded
> as "%89%41", and shouldn't be "%89A"?
Either is fine (they mean the same thing). I've changed the spec to be
closer to what browsers do though, thanks.
On Thu, 21 Jan 2010, Aryeh Gregor wrote:
>
> MediaWiki currently uses a search-suggest feature based on lots of
> JavaScript that's used to calculate all sorts of widths and heights to
> painstakingly construct an absolutely-positioned div, and reimplement
> standard dropdown navigation controls on top of that. It works pretty
> well (go to en.wikipedia.org and start typing a query to see --
> implementation at
> <http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/mwsuggest.js?view=markup>),
> but it's a horrible hack and doesn't integrate perfectly with the
> system. When I found out Opera implements <datalist>, thanks to the
> helpful spec annotations, I tried rewriting mwsuggest.js to use
> <datalist> where supported.
>
> My primary feedback here is that a simpler JS API would *really* be
> nice. In this kind of situation, typically you receive some JSON or
> whatnot from the server, so you have a JavaScript array that you want
> to use for suggestions. The code to make a given list the suggest
> source for an input is something like:
>
> var datalist = document.getElementById( 'arbitrary-id' );
> if ( datalist == null ) {
> datalist = document.createElement( 'datalist' );
> datalist.id = 'arbitrary-id';
> document.body.appendChild( datalist );
> } else {
> datalist.innerHTML = '';
> }
> input.setAttribute( 'list', 'arbitrary-id' );
> while ( var i = 0; i < suggestions.length; i++ ) {
> var option = document.createElement( 'option' );
> option.value = suggestions[i];
> datalist.appendChild( option );
> }
>
> This is all quite awkward. It was pointed out on IRC that there are
> legitimate use-cases for declarative datalists (e.g.,
> http://html5.lachy.id.au/), but I'd expect JS-constructed datalists to
> be a much bigger use-case. I can think of several sites off the top
> of my head that use absolutely-positioned divs to provide search
> suggestions to users, but none that do so statically. So I think a
> better API is needed -- preferably just
>
> input.suggest = suggestions;
>
> or similar. The details aren't particularly important, but the
> current API is really cumbersome when used from JS.
To be fair a lot of the above is redundant with just having the <datalist>
in the document ahead of time. All you really need is to set the contents
of the <datalist> element's contents each time; this need not be more than
one line if what you send from the server is a string of HTML representing
the <option> elements.
I agree that it would be nice to have a non-DOM way of doing this also,
though, from a performance point of view if nothing else. However, as
Aryeh says:
On Thu, 21 Jan 2010, Aryeh Gregor wrote:
>
> It's also worth noting that <datalist> currently seems to be conceived
> as a combobox, while search suggestions deserve totally different UI.
> Opera's UI is suitable to search suggestions, but WebKit's proposed UI
> is inappropriate for them:
>
> http://docs.google.com/View?id=dch3zh37_0cf8kc8c4
>
> There's a little drop-down arrow you have to click to get the list,
> which is unexpected for search suggestions. If a separate "suggest" IDL
> attribute were added, UAs could provide different UI for that and
> datalist.
...it would probably make more sense to wait until the current stuff is
implemented, and then add a separate addition for "suggest" UI and API.
On Mon, 25 Jan 2010, TAMURA, Kent wrote:
>
> > On setting, if the valueAsNumber attribute does not apply, as defined
> > for the input element's type< attribute's current state, then throw an
> > INVALID_STATE_ERR exception. Otherwise, if the valueAsDate attribute
> > applies, run the algorithm to convert a Date object to a string
> > defined for that state, passing it a Date object whose time value is
> > the new value, and set the value of the element to resulting string.
> > Otherwise, run the algorithm to convert a number to a string as
> > defined for that state, on the new value, and set the value of the
> > element to resulting string.
>
> It seems the current spec doesn't define behavior in a case of setting
> NaN or Infinitiy to HTMLInputElement::valueAsNumber. Because
> 'input.valueAsDate = null' makes the value empty, I think
> 'input.valueAsNumber = Number.NaN' also makes the value empty.
On Mon, 25 Jan 2010, Philip Taylor wrote:
>
> http://whatwg.org/html5#float-nan : "Except where otherwise specified,
> if an IDL attribute that is a floating point number type (float) is
> assigned an Infinity or Not-a-Number (NaN) value, a NOT_SUPPORTED_ERR
> exception must be raised."
>
> This case seems to apply for valueAsNumber.
Indeed.
On Tue, 26 Jan 2010, TAMURA, Kent wrote:
> >
> > attribute float valueAsNumber
>
> valueAsNumber is defined as float, IEEE754 single precision number.
> It should be double because number values for date and time types are
> milliseconds from UNIX epoch. As of today, milliseconds from UNIX epoch is
> about 1,264,492,163,000. The float type can't represent this value
> precisely.
> If we do the following with float valueAsNumber, the input value loses the
> data.
> input.type = "datetime";
> input.value = "2010-01-26T08:00Z";
> var num = input.valueAsNumber;
> input.valueAsNumber = num;
Fixed.
On Tue, 26 Jan 2010, Randy Drielinger wrote:
>
> Currently the submit button is used to submit a form once (more than
> average purpose). In some occassions it's possible to submit a form
> twice, and get it processed twice by the webserver, resulting in a
> double submit (e.g. forum post). For this specific example, it isn't
> desired bahavior.
>
> Should there be a way to prevent a (submit) button in HTML to be clicked
> more than once or is this clearly a behavior (and therefore be solved
> with JS)?
On Tue, 26 Jan 2010, Adam Shannon wrote:
>
> I'm sure you know this, but there is always this simple way.
>
> <input type="submit" value="Submit" onclick="this.disable=true;" />
On Tue, 26 Jan 2010, Kornel wrote:
>
> No, it's wrong. It may not submit the form, because submit button will
> be disabled before submission takes place.
>
> And even in case it does submit, it becomes incredibly annoying when
> submission fails for some reason (e.g. temporary loss of network
> coverage) — user won't be allowed to retry submission.
>
> This is much better IMHO:
>
> onclick="var t=this; setTimeout(function(){t.disabled=true},1);
> setTimeout(function(){t.disabled=false},5000)"
On Tue, 26 Jan 2010, Aaron Bassett wrote:
>
> Ensuring that your server-side form handler can detect and properly deal
> with multiple submissions?
>
> Client-side validation should only ever supplement server-side
> validation, never replace it. The reason for client-side validation is
> to improve the user experience, it allows for common data entry problems
> to be detected and the user notified without a round trip to the server.
> IMHO disabling the submit button does not add anything to the user's
> experience, so there is no reason to do it. Unless you are too lazy to
> have proper server-side validation? ;)
On Tue, 26 Jan 2010, Kornel wrote:
>
> I agree that in cases when it's important that duplicate submissions are
> stopped (placing orders, etc.), there must be server-side protection.
>
> However it's not always essential (e.g. for idempotent actions or in
> chat applications) and in these cases authors may be OK with weak
> protection.
>
> There are benefits of client-side prevention regardless of server-side
> validation:
>
> - if form is large (long wiki page or file upload), it saves time and
> bandwidth.
>
> - if client-side handles most cases, then server-side check for
> duplicate submission becomes mainly a fallback and security measure, and
> doesn't need to be as user-friendly (i.e. it would suffice if it replied
> with error instead of having to silently redirect to previous
> submission's result). This simplifies server-side implementation.
As far as I can tell, nothing prevents a browser today from making submit
buttons get disabled while the form is submitting. That even seems
somewhat reasonable (maybe with the stop button resetting the disabled
state). I don't think there's much to spec here; it's a UI issue.
On Tue, 26 Jan 2010, Aaron Bassett wrote:
>
> I am simply saying that in this particular case (detecting multiple form
> submissions) there is no benefit I can see to the end-user in disabling
> the submit button. Let them click it a dozen times if it makes them feel
> better (like pushing the call button on a lift to make it arrive
> faster!) If your server-side validation is done correctly it will make
> no difference.
Each submission will restart the navigation, so it'll make it slower.
Also, the client will interrupt its upload each time, so it may in fact
result in some corruption, if the server can't detect if it got
everything.
On Fri, 29 Jan 2010, Sidney San Martín wrote:
>
> When a user binds to a form's submit event, it's almost always for one
> of three purposes:
>
> 1. To prevent submission, if the page or form is in an unsubmittable
> state
This can be done now easily with the form validation stuff.
> 2. To handle submission in a non-default way (submit it asynchronously
> or use it locally)
>
> 3. To add to the data in the form before it's submitted
>
> The result is that every major JavaScript framework has functionality to
> extract the data from a form. [This page compares][1] the behavior of
> the most popular ones. *None* of the framework results match any of the
> others, except for jQuery and jQuery Form, and *none* of the framework
> results match my UA's results (WebKit r53990). Scripts handling the
> submit event can't get at the submitter, which makes it impossible to
> know its name, value, and mouse coordinates (in the case of image
> inputs) without binding to click on every button in the form and keeping
> track of which one fired in the same event loop as submit. This is how
> forms are handled today.
>
> JavaScript authors shouldn't be in the game of implementing the HTML
> API. I propose that the [form submission algorithm][2] be rearranged
> slightly so that the form data set is constructed before the submit
> event fires, and the data set and submitter are exposed as properties on
> the submit event.
>
> If I want to submit additional data describing some state on the page,
> right now I have to create an input, set its type to hidden, set its
> name and value, append it to the form, and, if I don't plan to target
> the form at its own browsing context, wait for the submit to run, and
> remove it from the form. With this new model, sending extra data could
> be as simple as
>
> formData.push({ name: "someAdditionalName", value: "someAdditionalValue" });
>
> It's also conceivable that objects could be deleted from the data array
> (maybe in the case that an input only has relevance to the script
> handling a form and not to its action), and that the names and values
> could be writeable without mutating the name or value of the associated
> input (I don't have use case for this last one). The implementation
> would have to handle inputs being added, removed, or modified during the
> submit event. I think that the cleanest way to deal with this would be
> to update the data object synchronously to reflect those changes, so
> that behavior remains backwards compatible. There may be a better way,
> or my whole implementation could be garbage.
>
> What do you think?
On Sat, 30 Jan 2010, Anne van Kesteren wrote:
>
> If we do anything here it needs to be harmonized with
> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-formdata-interface
> somehow.
>
> If the main use case is asynchronous submission it could be something as
> simple as <form>.formData which seems better than tying it to the submit
> event.
>
> (This has been suggested various times before as well by the way. We are
> just waiting for some more stabilization of various other <form> and
> XMLHttpRequest features first.)
As Anne says, this seems overall like a reasonable request, but we've
added a _lot_ of forms features tp HTML5 already, and few of them have
been implemented yet. So we should wait until they are implemented before
adding more.
On Thu, 4 Feb 2010, Philippe Wittenbergh wrote:
> On Feb 4, 2010, at 9:21 PM, Ian Hickson wrote:
> >> 2) What should UAs do when printing? It seems to me that, when
> >> printing, a <details> element should be open, regardless of the state
> >> of the boolean open attribute. (because it's a markup attribute,
> >> there is presumably now way for a print stylesheet to override this).
> >> Can that be added to the spec?
> >
> > Generally speaking, browser vendors have found that people expect
> > their "print" features to just print what's on the screen. However,
> > I'm certainly open to changing the spec on this if the browser vendors
> > feel the spec should change -- any implementors have an opinion on
> > this?
>
> As a page author and site developer (and as a user), I would certainly
> want the possibility to display the content of the details element when
> printing, insofar as it is relevant to the document in a printed state.
> (that is, a print stylesheet should be able to override the onscreen
> display state of <details>)
Well you currently can do this by using the onbeforeprint and onafterprint
hooks, though that's not exactly pretty. Hopefully it will also be
possible with media-specific CSS, though that depends on how <details>
ends up working in CSS. If this proves to not be enough, we'll have to add
something to support it; however, I'd like to wait until this is more
widely deployed (so we get more experience) before changing this.
On Wed, 10 Feb 2010, TAMURA, Kent wrote:
>
> The default step base for type=week should be -259,200,000 (the beginning of
> 1970-W01) instead of 0.
> If an implementation follows the current spec and an input element has no
> min attribute, stepMismatch for the element never be false because the step
> base is not aligned to the beginning of a week.
Fixed, thanks. Good catch.
On Thu, 11 Feb 2010, Aryeh Gregor wrote:
> On Thu, Feb 11, 2010 at 9:39 PM, Ian Hickson <ian at hixie.ch> wrote:
> >
> > 2. Getting validation of forms with the UI designed by the author, but
> > with the actual validation work (including working out what the
> > messages should be) done by the UA.
> >
> > . . .
> >
> > For #2, the author can use validationMessage to get the relevant
> > message, which it can then insert into its page dynamically.
>
> I don't think anyone is going to want to do the UI himself but leave the
> messages up to the browser -- i.e., I don't think your #2 is a realistic
> use-case.
On Fri, 12 Feb 2010, Tab Atkins Jr. wrote:
> On Thu, Feb 11, 2010 at 9:29 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> > Do you know of any actual authors who would want to use
> > validationMessage? Â If there are any authors here who would want to
> > use the validation API with their own UI, would you want to use
> > validationMessage or write your own messages? Â I wouldn't be likely to
> > write my own UI at all, so I'm not the best person to have an opinion
> > here.
>
> When I use a jQuery validation plugin for my forms today, I pretty
> much always rely on the default error message that the library
> provides. It's rare for me to override it; I typically only provide
> messages when I'm specifying a custom validation that doesn't have a
> message (as the default error message for a custom validation rule is
> far too generic).
>
> So yes, I'd use validationMessage in my own UI. It's easier, as it
> lets me be completely agnostic about the actual error, and just plug
> in whatever the error is into my custom UI.
On Sat, 13 Feb 2010, Mike Taylor wrote:
>
> I also use a jQuery validation plugin at work--but have a mixture of
> default and custom errors--depending on what language the "business" is
> testing that week. Either way, I do think that validationMessage is
> absolutely useful. In the cases where I might need to change the
> message, I'm OK with a mixture of setCustomValidity and using the title
> attribute in conjuction with the pattern attribute to describe what went
> wrong (which is how Opera currently works, at least).
Indeed.
On Thu, 11 Feb 2010, Aryeh Gregor wrote:
> On Thu, Feb 11, 2010 at 9:39 PM, Ian Hickson <ian at hixie.ch> wrote:
> > It should show the same message it would give the user if the user hit
> > "enter" to submit the form in this scenario.
>
> I suggested UAs might snap the value to the max/min onchange or
> onsubmit, so in this case there would be no error: if the user hit
> enter, the value would be snapped to the range before submission. I
> guess then the value DOM attribute should reflect what would actually be
> submitted, though, and always be valid.
Right.
> More generally, however, who says the UA will provide actual text for
> all validation errors?
The spec, it's a requirement.
> I'm not sure what a concrete example would be, not being particularly
> good at UI, but I could imagine UAs using some non-textual cue if you
> try to submit a form with a missing required input, say. They could
> provide some artificial string in that case, though, I guess.
Indeed.
On Fri, 12 Feb 2010, Tab Atkins Jr. wrote:
>
> I don't know that I've ever seen a validated form rely solely on
> non-textual UI for anything, except possibly the failure to fill out a
> required field (and even then, there's a message somewhere on the page
> explaining that all the fields with a red border are required or
> whatever).
>
> If that were to happen, though, an artificial string would be
> appropriate. Ian, do you think this needs to be explicitly stated?
Done.
> On Fri, Feb 12, 2010 at 12:40 AM, Peter Kasting <pkasting at google.com> wrote:
> > I am explicitly opposed to the UA showing validation messages to the user.
> >Â I do not think HTML5 should attempt to address use cases where the
> > author wants the UA to show the messages. Â I think the design should
> > provide the author with return values that indicate what the results
> > of validation were and the author should provide the rest of the UI.
> > Â In other words, I am opposed to trying to solve use cases #1 and #2
> > above. Â Any design that attempts to solve them is a mistake. Â Please
> > remove validationMessage from the spec.
>
> I *strongly* disagree. #1 is by far the MOST important use-case for
> these features, in my opinion. Without it, several of the new input
> types and attributes are basically useless.
>
> Just as important, requiring the author to handle the UI means that
> accessibility will likely be impaired. I'm very excited about the new
> types and error messages making my forms significantly more accessible.
> When you can provide accessibility like this *for free* with no author
> intervention, it's silly to pass up the opportunity.
I agree entirely that without UA UI this whole feature set is pointless.
It would be designed in a very different way if it wasn't up to the UA to
support it.
On Fri, 12 Feb 2010, Boris Zbarsky wrote:
> On 2/12/10 12:10 AM, Ian Hickson wrote:
> > HTTP already says for 301, 302, and 307 redirects: "If the [...]
> > status code is received in response to a request other than GET or
> > HEAD, the user agent MUST NOT automatically redirect the request
> > unless it can be confirmed by the user, since this might change the
> > conditions under which the request was issued".
> >
> > Do user agents not implement what HTTP specifies here?
>
> What Necko (and hence Gecko) implements is the following, as far as I
> can tell:
>
> 1) A 301 or 302 response leads to a silent redirect performed via a
> GET of the Location header.
> 2) A 307 response to a request that had a (possibly empty) request
> body (this always includes the form POST case) puts up one of those
> dialogs from hell. It's a prompt that asks: "This web page is
> being redirected to a new location. Would you like to resend the
> form data you have typed to the new location?" No indication of
> what the new location is. The user is presented with an "OK"
> button and a "Cancel" button. If the user selects the former, the
> request is redirected. If the latter, the response-body of the 307
> response is shown, I think, modulo some SSL stuff.
> 3) A 307 response to a request that does not have a request body (a
> situation one can get into by passing null to XHR send(), I think),
> is silently redirected to the new URI while preserving the request
> method. Note that this is somewhat mitigated by the restrictions
> on cross-origin XHR, if it can be reached via XHR at all.
On Thu, 11 Feb 2010, Adam Barth wrote:
>
> Neither Chrome nor IE show a dialog when 307 redirecting a POST. In any
> case, the user doesn't have any context for understanding what the
> dialog would mean, let along making a security decision based on the
> dialog.
On Thu, 11 Feb 2010, Jonas Sicking wrote:
>
> Yeah, I think we should make the same change in firefox. I actually
> created a pref a while back to control this behavior (in order to allow
> suppressing the dialog during testing), so it would be a trivial change
> to Firefox.
On Thu, 11 Feb 2010, Devdatta wrote:
>
> Even if they do show a dialog box, like CORS, shouldn't a server opt-in
> to receiving a PUT/DELETE ?
I've changed the spec to explicit drop cross-origin redirects for PUT and
DELETE (and indeed anything non-POST and non-safe, should that be
relevant).
On Fri, 12 Feb 2010, Erik Arvidsson wrote:
>
> At the moment an input element needs to [be] part of a form and have a
> name attribute for the CSS pseudo classes :valid and :invalid to be
> applied. These limitations forces people to make their DOM more
> complicated just to be able to use these pseudo classes. It might have
> made sense to have these limitations in a world where JavaScript was not
> available but in many modern web apps there is no need for forms nor
> name attributes.
>
> Can we please remove these limitations?
Done.
On Sun, 14 Feb 2010, TAMURA, Kent wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#definitions
> > Note: An element can still suffer from these states even when the
> > element is disabled; thus these states can be represented in the
> > DOM even if validating the form during submission wouldn't indicate
> > a problem to the user.
>
> This paragraph mentions only "disabled". But it means ValidityState also
> works without a form element, without a name attribute, or with a readonly
> attribute, right?
The paragraph you quote above is non-normative, meaning that the spec has
the same requirements with or without that paragraph. You are correct, the
attribute is live even when the element is readonly, for instance.
"disabled" is just an example.
> An element is a "candidate for constraint validation" if
> 1. it is a validatable type,
> e.g. true if <input type=number>, false if <input type=reset>
> 2. has no "disabled" attribute,
> 3. has no "readonly" attribute,
> 4. inside of a <form> element,
> 5. has non-empty "name" attribute, and
> 6. not inside of a <datalist> element.
>
> I hope ValidityState and the pseudo classes ignores 2-6.
The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.)
The reason :invalid doesn't match a disabled element is that you don't
want a disabled element to give the user an indication that it needs
fixing, since the user can't fix it. Same with readonly.
On Tue, 16 Feb 2010, Jonas Sicking wrote:
>
> In step 7, substep 1, of "Form submission algorithm" remove the bullet
> that says: "The field element is an input element whose type attribute
> is in the File Upload state but the control does not have any files
> selected". Additionally, add to step 8 "If no files are selected, append
> an entry in the form data set with the name as the name, the empty
> string as the value, and "application/octet-stream" as the type.". See
> [1] as to why.
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=529859
Done.
> Somewhere it needs to be expressed that processing of <input type=hidden
> name="_charset_"> should happen even for multipart/form-data encoded
> submissions too.
Done.
> In step 7 substep 1 of the submission process, add a bullet that says:
>
> * The field element does not have a name attribute specified, or is
> the empty string. Except if the field element is an input element
> whose name attribute is in the Image state.
>
> and remove step 4. This will make it clearer that non-images are not
> submitted if they lack a non-empty name.
Done.
On Wed, 17 Feb 2010, Jonas Sicking wrote:
>
> The FormData object [1] is a great way to allow multipart/form-data
> encoded content to be submitted using XMLHttpRequest. It would be
> great if it was possible to get a FormData object representing the
> data contained in a <form>. This in order to allow normal HTML forms
> being used, but using XMLHttpRequest to submit the form data in order
> to allow AJAX to be used.
>
> So I suggest we add a method like
>
> interface HTMLFormElement : HTMLElement {
> ...
> FormData getFormData();
> ...
> };
>
> The reason this is a function rather than a read-only attribute is to
> allow the return FormData to be further modified. I.e. the following
> should be allowed:
>
> fd = myFormElement.getFormData();
> fd.append("foo", "bar");
> xhr.send(fd);
>
> If it was a property I would be worried about people expecting the
> following to work:
> myFormElement.formData.append("foo", "bar");
> xhr.send(myFormElement.formData);
>
> However I don't think there is a good way to make the above work. Thus
> my suggestion to use a function instead. I'm writing a prototype
> implementation over in [2]
>
> [1] http://dev.w3.org/2006/webapi/XMLHttpRequest-2/Overview.html#the-formdata-interface
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=546528
Anne said he'd add a constructor for FormData that takes a <form>, so I
haven't added anything here.
On Thu, 25 Feb 2010, Timothy D. Morgan wrote:
>
> As a follow up to my paper advocating HTTP authentication over
> cookies [1], I've built a simple sample application which demonstrates
> how a combination of XMLHttpRequest and response code tricks can be
> used to achieve form-based login, logout, and authenticated password
> changes in the four most popular browsers:
> http://www.vsecurity.com/download/tools/fbha-poc_0.1.zip
>
> Note that this is achieved without using any checks to determine what
> browser is being used.
>
> While this is promising, I still think we should have an HTTP-based
> log out mechanism. In addition, the proposed W3C change to
> XMLHttpRequest authentication behavior will make this code much
> simpler.
>
> [1] http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
We investigated doing something in HTML to address this a few years ago,
but the conclusion was that a better way to do this might be to go the
other way, and make Cookie-based authentication an HTTP auth mechanism.
On Thu, 11 Mar 2010, Mounir Lamouri wrote:
>
> I'm wondering why meter and progress elements are barred from constraint
> validation even if they are not implementing the constraint validation
> API ? I am missing something or it is not needed to specify they are
> barred from constraint validation ?
Fixed.
On Mon, 22 Mar 2010, bgy wrote:
>
> On webkit based browser, we can see a little cross used to reset the
> field, it's useful, but in some ajax based application, it could be
> useful to be able to handle this event, to dispatch the event to any
> controller and reset results.
>
> Use case:
>
> Highlight a given text in webpage.
>
> Input search is likely to be used since the highlight functionnality
> will search through the webpage and highlight all matched patterns. In a
> server side solution, the problem is likely to be inexistant, but if we
> use a plain javascript option, it'll be usefull to handle the reset
> event to remove the highlighting from the page in browser impletementing
> this functionnality.
>
> What are your thoughts about this ?
I don't really understand the proposal or the use case. Can you elaborate?
On Sat, 27 Mar 2010, Mounir Lamouri wrote:
>
> It looks like the input color state can't suffer from type mismatch
> according to the specs but it seems to be the only way to be sure the
> value is correct. Email and URL states can suffer from type mismatch for
> the exact same reason.
>
> I think we should add:
> "Constraint validation: While the value of the element is not a valid
> lowercase simple color, the element is suffering from a type mismatch."
> in the color state.
> And add "Color" in the "Suffering from type mismatch" definition.
>
> By the way, it looks like WebKit has implemented type mismatch for color
> state [1] [2].
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=28966
> [2] https://bugs.webkit.org/attachment.cgi?id=39044
The color input is supposed to be a colour picker, not text input, so it
makes no sense to have it be in the type mismatch state. If a UA insists
on having it be a text control, then the UA must not set the value until
the user input is a valid color value.
On Mon, 29 Mar 2010, Mounir Lamouri wrote:
>
> I understand this is because there is only a simple text field for now
> but in a general matter, having typeMismatch for the color state would
> be fine because the UI is optional and we can easily imagine UA not
> adding an UI.
There has to be a UI -- that's the point of type=color. :-)
On Mon, 29 Mar 2010, Aryeh Gregor wrote:
>
> It isn't possible for color inputs to suffer from a type mismatch,
> because the spec says "User agents must not allow the user to set the
> value to a string that is not a valid lowercase simple color." If the
> user somehow selects an invalid color, the UA is required to simply
> refuse it, or auto-correct it somehow. This doesn't work well with a
> text input, where the user has to type the color incrementally -- I
> guess the UA could decide to not update the script-visible/submitted
> value until the user no longer focuses the form field, and if the value
> isn't valid at that time, it could revert to the previous value.
Right.
On Mon, 29 Mar 2010, Mounir Lamouri wrote:
>
> Indeed, this sentence must be the reason why the input element in the
> color state can't suffer from a type mismatch. However, as you said it
> may be really difficult to respect this where not using a specific UI. I
> do not even see how we can do that reasonably. It's the same issue for
> date/time/week/whatever. At least, we can consider number/range to be
> doable by blocking letters. Type mismatch seems to be a clean way to
> prevent that.
>
> If the specific UI is optional, the specifications should let a descent
> implementation without this specific UI.
It's pretty easy to do -- you just don't update the .value until the user
has entered a valid value.
On Tue, 30 Mar 2010, Jonas Sicking wrote:
>
> The spec says
>
> "When a form-associated element has a form attribute and the ID of any
> of the form elements in the Document changes, then the user agent must
> reset the form owner of that form-associated element."
>
> However it does not seem to reset the form owner if a form element
> with an ID is added or removed to the Document. I suspect this is an
> oversight that needs to be fixed.
Fixed.
> Also, one critical step in the "reset the form owner" algorithm is
> somewhat ambigious. Step 3.1 says
>
> "If the first element in the Document to have an ID that is
> case-sensitively equal to the element's form content attribute's value
> is a form element, then associate the form-associated element with
> that form element."
>
> However I wonder if "in the Document" includes only nodes that are
> descendants of Document, or if it includes all nodes whose ownerDocument
> is the Document. I.e. are disconnected subtrees "in the Document"?
Fixed by cross-referencing to the definition of "in a Document".
On Thu, 1 Apr 2010, John Gregg wrote:
>
> For context, Ian Fette started a thread about uploading directories of
> files in December:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024455.html
>
> At that time, it was thought that directory upload could be implemented
> by a UA in response to a <input type="file" multiple> tag using
> different UI only, and modifying the FileAPI spec to allow path
> information in the form
>
> input.files[0].name="1.jpg"
> input.files[0].path="a"
> input.files[1].name="2.jpg"
> input.files[1].path="a/b"
> input.files[2].name="3.jpg"
> input.files[2].path="a/c"
>
> I've started developing a prototype of this in WebKit/Chromium. Based
> on what I've encountered so far, I would like to propose adding
> directory upload functionality using an explicit new 'directory'
> attribute on the file input element.
>
> The existing behavior of <input type="file" multiple> would not change,
> but when processing <input type="file" directory>, the UA would display
> a directory selection UI and store the path information, and *not* allow
> individual files to be selected. It would allow multiple files to have
> the same leaf name (.name attribute), as long as the paths were
> different. The path attributes would include the name of the chosen
> directory
>
> This would be preferable for several reasons:
>
> - Most built-in file system UI on major platforms (Windows/Mac/Linux)
> have distinct dialogs for choosing files and choosing directories.
> Allowing the UA to use these directly makes sense rather than creating
> hybrids.
>
> - Avoiding "leaf name" conflicts in a directory tree is not feasible in
> many applications -- asking a user to ensure unique photo names in a
> large set of albums before uploading would fail to meet that use case.
> Therefore HTML documents should know in advance whether the path
> information will be relevant in the eventual storage of the files.
> Sites currently using <input type="file" multiple> would have
> compatibility problems with an implementation which allowed conflicting
> file names along different paths.
>
> What are your thoughts about adding the 'directory' attribute?
What is the advantage over an <input type=file multiple> control? It seems
like it would be more backwards compatible to just make this a UI switch
-- let the user chose whether he's uploading a file, many files, or a
directory of files. That's also more backwards-compatible.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list