On 08/10/2010 01:35 AM, Ian Hickson wrote:
On Fri, 18 Jun 2010, Mounir Lamouri wrote:
I'm wondering why select element do not have a required attribute.
It's impossible to submit a select element (without a size= attribute
or multiple= attribute) without it having a value -- essentially
On 08/06/2010 09:01 PM, Ian Hickson wrote:
- input.autocomplete: at the moment, it is returning the content but it
could return the resulting autocompletion state which is maybe a bit
more than just being limited to only known values but still in the same
spirit.
I haven't changed this;
On 07/29/2010 12:08 AM, Ian Hickson wrote:
Other than that, the only safe alternative would be to leave the values
untouched, so the page can say what it wants, the user honor it, and the
server get it as expected; or gracefully degrade to an error message
that actually points to the user
Hi,
At the moment, to suffer from a pattern mismatch an element needs a
non-empty value and a specified pattern (and the pattern should not
match the entire value) [1]. So, if, for any reason, an author write
input pattern='', the element would be always suffering from a pattern
mismatch except
On 07/24/2010 08:46 AM, Ola P. Kleiven wrote:
On Sat, 24 Jul 2010 00:21:10 +0200, Aryeh Gregor
simetrical+...@gmail.com wrote:
On Thu, Jul 22, 2010 at 5:46 PM, Jonas Sicking jo...@sicking.cc wrote:
I think that depends largely on how many, and how big, sites are
affected by this. Do you
On 07/20/2010 04:07 PM, Simon Pieters wrote:
On Tue, 20 Jul 2010 15:47:32 +0200, Mounir Lamouri
mounir.lamo...@gmail.com wrote:
Hi,
I'm wondering why there is no categories for elements candidate for
constraint validation. In the current state of the specs, all listed
elements
On 06/18/2010 01:04 PM, Ashley Sheridan wrote:
On Fri, 2010-06-18 at 11:35 +0200, Mounir Lamouri wrote:
Hi,
I'm wondering why select element do not have a required attribute. It
seems to be perfectly suitable. With the required attribute, select
element would be able to suffer from being
Hi,
At the moment, three form elements are barred from constraint
validation: object, fieldset and output. I can understand why object and
fieldset are barred from constraint validation but I think output could
use the constraint validation.
Indeed, it could be nice to be able to use
Hi,
I'm wondering why there is no categories for elements candidate for
constraint validation. In the current state of the specs, all listed
elements are candidate for constraint validation except when they are
barred from constraint validation. Barring an element from constraint
validation when
On 07/20/2010 06:00 PM, Tab Atkins Jr. wrote:
On Tue, Jul 20, 2010 at 6:37 AM, Mounir Lamouri
mounir.lamo...@gmail.com wrote:
Hi,
At the moment, three form elements are barred from constraint
validation: object, fieldset and output. I can understand why object and
fieldset are barred from
Hi,
I'm wondering why select element do not have a required attribute. It
seems to be perfectly suitable. With the required attribute, select
element would be able to suffer from being missing and the :required
pseudo-class could apply.
Is there a reason why the select element has no required
Hi,
According to the HTML5 specification, an IDL attribute reflecting an
enumerated attribute will have the default reflecting behavior (ie.
return the content attribute on getting and setting it on setting)
except if the attribute is limited to only known values [1]. There are
three attributes
Hi,
I'm wondering why the value and max IDL attributes have to reflect the
content attribute with zero as a default value instead of reflecting the
internal values used to calculate the position. Wouldn't that be easier
to know what is the internal value and max values by using the IDL
attributes
Hi,
4.10.18 Association of controls and forms explains the link between
forms and form-associated elements (and the form attribute). However,
I've the feeling the specifications go far over what should be done and
force the implementor how to do it.
What I mean is, this could be summarized like
Hi,
At the moment, the autofocus attribute specification [1] is quite
permissive: only one element should have the autofocus enabled in the
document but each time an element with autofocus is inserted into the
document, the UA should give it the focus. The UA can disable the
autofocus request for
Hi,
I have a few questions about the keygen element specification.
First of all, the keytype attribute should specify which algorithm to
use but it can be in the 'unknown state' and it is possible for a user
agent to not support any key types at all.. I do not understand why the
keygen element
Hi,
For input element in telephone state [1] specs say User agents may
change the punctuation of values that the user enters. I do not really
get it. What is the idea ?
[1] http://dev.w3.org/html5/spec/forms.html#telephone-state
Thanks,
--
Mounir
On 04/07/2010 12:37 AM, Ian Hickson wrote:
On Tue, 6 Apr 2010, Mounir Lamouri wrote:
For input element in telephone state [1] specs say User agents may
change the punctuation of values that the user enters. I do not really
get it. What is the idea ?
For example, if I enter 1 650 253-
On 04/07/2010 12:55 AM, Ian Hickson wrote:
On Wed, 7 Apr 2010, Mounir Lamouri wrote:
On 04/07/2010 12:37 AM, Ian Hickson wrote:
On Tue, 6 Apr 2010, Mounir Lamouri wrote:
For input element in telephone state [1] specs say User agents may
change the punctuation of values that the user enters
On 04/07/2010 01:08 AM, Ian Hickson wrote:
On Wed, 7 Apr 2010, Mounir Lamouri wrote:
Well the alternative is to not have the user agent change the value at
all, in which case you still have to do server-side canonicalisation,
so I don't think it really makes any difference.
If the UA
On 04/07/2010 01:18 AM, Tab Atkins Jr. wrote:
On Tue, Apr 6, 2010 at 4:13 PM, Mounir Lamouri mounir.lamo...@gmail.com
wrote:
As Davis said, there are too many phone numbers format out there so we
can't let the UA do a formatting because it will be a bad one in most of
the cases. For example
Hi,
I'm wondering why the [PutForwards=value] extended attribute is needed
for the htmlFor output element attribute ?
It is making things pretty ugly for a need I do not really get.
Thanks,
--
Mounir
On 03/29/2010 10:38 AM, TAMURA, Kent wrote:
By the way, it looks like WebKit has implemented type mismatch for color
state [1] [2].
Yes. That's because the type=color implementation of WebKit is just a
text field for now. Users can specify invalid strings.
When we complete the
On 03/29/2010 09:49 PM, Aryeh Gregor wrote:
On Sat, Mar 27, 2010 at 9:48 AM, Mounir Lamouri
mounir.lamo...@gmail.com 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
Hi,
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
Hi,
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 ?
Thanks,
--
Mounir
be appropriate to
specify one ?
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=457801
[2] https://bugs.webkit.org/show_bug.cgi?id=21227
Thanks.
--
Mounir Lamouri
101 - 127 of 127 matches
Mail list logo
