- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 7 May 2012 22:23:22 +0000 (UTC)
On Tue, 17 Jan 2012, Rich Tibbett wrote:
>
> During some experimentation today I wanted to establish a cross-document
> messaging channel for when a user submits a form with a target of _blank
> (or _someframe). I couldn't find any native way to do this when target
> == _blank so I had to produce my own workaround [1].
I don't understand what you are trying to do here. Can you elaborate on
your use case?
On Tue, 17 Jan 2012, Ben Darlow wrote:
>
> I've recently been implementing date controls for a web application to
> be primarily used on mobile browsers, and discovered that the
> placeholder attribute is considered forbidden for use on
> input[type=date] elements. I would like to propose that this be changed.
The problem is that many possible implementations of date controls don't
really leave anywhere to put the placeholder text. That's why it's not
supported. We don't want some browsers to show it and others to not show
it, since that would lead to some browsers possibly missing important
information.
> The ISO date format has the advantage over different local date formats
> in that it is unambiguous, but it isn't necessarily the most user
> friendly. I would like therefore to propose that an optional dateformat
> attribute be added to the input element, to permit different formats to
> be used to * display* a selected date. My initial feeling is that some
> flavour of the strftime syntax implemented by several languages (e.g.
> http://ruby-doc.org/core-1.9.3/Time.html#method-i-strftime) is probably
> the best way of specifying the format within this attribute.
Currently we're leaving this up to the user agent. Going forward, I expect
that we'll address this using a combination of CSS and the ongoing Web
Components work.
On Fri, 20 Jan 2012, Jake Verbaten wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-form-nameditem
>
> says to return a live NodeList
>
> where as
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#dom-htmlformcontrolscollection-nameditem
>
> says to return a RadioNodeList
>
> This is inconsistent. Personally to me, returning a RadioNodeList on the
> form namedItem getter makes sense.
Fixed.
On Fri, 10 Feb 2012, brenton strine wrote:
>
> Regarding the an input with type in the "number" state, the spec states
> that the "pattern" attribute "must not be specified and do[es] not apply
> to the element".
> http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#number-state-type-number
>
> Why is it specifically blocked? Doesn't that encourage the use of a less
> semantic "text" input type for numbers that need to be validated beyond
> simple max and min?
>
> What if you want the number to be either 13 or 16 digits long, as with a
> credit card
>
> pattern="(\d{5}([\-]\d{4})?)"
>
> or you want a US ZIP or ZP4 code which can either be nnnnn or nnnnn-nnnn
>
> pattern="(\d{5}([\-]\d{4})?)"
>
> To get the pattern to validate, I have to (non-semantically) change the
> input to the text state? I much prefer the current behavior of Firefox
> (tested 9 and 10) which does validate the pattern.
Neither zip codes nor credit card numbers are "numbers" in the sense of
type=number. They're strings that happen to use numbers (and punctuation).
On Fri, 10 Feb 2012, Ms2ger wrote:
>
> Using input type=number for those cases is wrong. You would not use a
> credit card number or a ZIP code in calculations. (In fact, in the
> United Kingdom, post codes contain letters.)
>
> input type=number is meant to be used for numbers, rather than for
> strings that happen to contain mostly numbers. The specification does
> indeed require a *more* semantically correct input type=text for those
> cases.
Right.
On Mon, 13 Feb 2012, fantasai wrote:
>
> The spec could perhaps benefit from an example of how /not/ to use
> type=number here...
Done.
On Wed, 22 Feb 2012, Cameron Jones wrote:
> On Tue, Feb 21, 2012 at 10:48 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 13 Sep 2011, Michael Gratton wrote:
> >>
> >> HTML5 does not provide a means of submitting form content that is
> >> otherwise rendered as normal text, i.e. not as a form control. The
> >> use cases for this are the same as for the <output> element, but when
> >> it is also desirable for the result of a calculation to be sent to
> >> the server when the form is submitted.
> >>
> >> Currently, the only way to implement this is to maintain two copies
> >> of the value, one the child text of an <output> element (or something
> >> similar, for example a <td> or <span>) and once in the value of an
> >> <input type="hidden"> element, using appropriate scripting to keep
> >> the two in sync. This is error prone and places an additional burden
> >> on the web page author.
> >>
> >> This can be remedied by allowing the value of <output> elements to be
> >> submitted. That is, include the <output> element in the submittable
> >> form-associated element category.
> >>
> >> I initially thought that this was precisely what the <output> element
> >> existed for - it was rather surprising when I tried using them but
> >> none of the values were appearing in the submission.
> >
> > You can work around this by just assigning the value to a hidden input
> > when you assign it to the output control.
> >
> > But in general, I recommend against this. Anything that can be
> > computed should be computed on the server to obtain the canonical
> > value, otherwise you open yourself up to attackers sending you
> > inconsistent data.
>
> This is based on the assumption of same origin web forms. If a request
> is being generated from a 3rd party web site to an open public web
> service, the 3rd party may choose to represent the input using methods
> or calculations unknown to the target web service and irrespective to
> the required request format.
Indeed. In those cases you can just use hidden inputs.
> > On Wed, 14 Sep 2011, Michael Gratton wrote:
> >>
> >> [As an aside, it just occured to me that it would also be helpful if
> >> <output> supported the "type" attribute, for most of the same values
> >> as <input> now does in HTML5, for much the same reason as it makes
> >> sense for <input>.]
> >
> > It makes sense for <input> because it lets the browser know what
> > interface to give to the user to let the user change the value... How
> > does that make sense for <output>?
>
> The type attribute is a discriminator over an otherwise
> indistinguishable text value which enables machine processing which
> would otherwise not be possible or be more error prone.
Can you elaborate on the use case here?
On Wed, 22 Feb 2012, Jukka K. Korpela wrote:
>
> <output> is just for looking semantic for semantics' sake.
Actually no, the main reason for <output> is to enable simpler
manipulation in form control event handlers. It's not about semantics.
Compare the code in the "simple calculator" example in the spec:
o.value = a.valueAsNumber + b.valueAsNumber
...to its equivalent before <output>:
document.getElementById('o').textContent = a.valueAsNumber + b.valueAsNumber
We could have used <span>, if adding <span> to form.elements wasn't so
likely to cause compat problems. (We added valueAsNumber for similar
reasons; without that API, this example would be even more verbose.)
On Thu, 23 Feb 2012, Michael Gratton wrote:
> Le 22/02/12 09:48, Ian Hickson a ?crit :
> > On Tue, 13 Sep 2011, Michael Gratton wrote:
> >> This can be remedied by allowing the value of <output> elements to be
> >> submitted. That is, include the <output> element in the submittable
> >> form-associated element category.
> >>
> >> I initially thought that this was precisely what the <output> element
> >> existed for - it was rather surprising when I tried using them but
> >> none of the values were appearing in the submission.
> >
> > You can work around this by just assigning the value to a hidden input
> > when you assign it to the output control.
>
> Yes, this is what I do at the moment, However as I have argued elsewhere
> on this tread, it a burdensome kludge for a limitation in the spec.
It's not really that burdensome. To assign a value to a hidden input as
well as an output element is as easy as this (going back to the example
above, and assuming a hidden input named "h"):
h.value = o.value = a.valueAsNumber + b.valueAsNumber
> > On Wed, 14 Sep 2011, Michael Gratton wrote:
> >> [As an aside, it just occured to me that it would also be helpful if
> >> <output> supported the "type" attribute, for most of the same values
> >> as <input> now does in HTML5, for much the same reason as it makes
> >> sense for <input>.]
> >
> > It makes sense for <input> because it lets the browser know what
> > interface to give to the user to let the user change the value... How
> > does that make sense for <output>?
>
> The same argument that applies to supporting extended type values for
> <input> applies to <output>.
The argument for <input> is "it lets the browser know what interface to
give the user to let the user change the value". There is no interface for
changing the value for <output>. So the same argument does not apply.
> My take on it is:
>
> The <input> not only allows a user to enter a value, it also displays
> its value to the user. For improved usability, some UAs will format or
> replace the value of an <input> element rather than displaying the raw
> string (some obvious candidates for this are: file, month, tel, date,
> number, and colour). For consistency, these UAs should also display
> calculated values - the values of <output> elements - in the same way.
> To do this, the element needs its type declared.
For both input and output, control over how the value is rendered (as
opposed to what the editing UI should be) is something that it is expected
will be handled by CSS and/or the Web Components work.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 7 May 2012 15:23:22 UTC