On Tue, 10 Mar 2015, at 22:44, Jonas Sicking wrote:
On Tue, Mar 10, 2015 at 3:05 PM, Mounir Lamouri mou...@lamouri.fr
wrote:
On Tue, 10 Mar 2015, at 21:44, Jonas Sicking wrote:
I think I'd prefer to define on and off as defined values unless
there is very little usage of them. We can
(bcc: public-webapps@)
Hi,
I would like to standardize the Apple's proprietary autocapitalize
attribute. This attribute is widely used and it would probably benefit
the platform to have a broader support for it. The implementation cost
should be fairly low while it can be very beneficial for the
On Tue, 10 Mar 2015, at 20:56, Edward O'Connor wrote:
Hi Mounir,
I would like to standardize the Apple's proprietary autocapitalize
attribute. This attribute is widely used and it would probably benefit
the platform to have a broader support for it. The implementation cost
should be
On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote:
On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote:
On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr
wrote:
On Wed, 24 Sep 2014, at 11:54, Jonas
On Fri, 3 Oct 2014, at 04:39, Jonas Sicking wrote:
On Thu, Oct 2, 2014 at 3:57 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote:
On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Wed, 1 Oct 2014, at 15:01, Jonas Sicking
On Fri, 3 Oct 2014, at 05:50, Silvia Pfeiffer wrote:
I've not used it - maybe others have some insights.
Sorry about that. I misread your previous messages and presumed that you
were related to the Cordova project.
-- Mounir
On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote:
On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr
wrote:
On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote:
Thoughts?
Do you have any data that makes you think that those websites would stop
using UA sniffing but start
On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote:
Thoughts?
Do you have any data that makes you think that those websites would stop
using UA sniffing but start using navigator.deviceModel if they had that
property available?
-- Mounir
On Tue, 19 Aug 2014, at 08:41, Kornel Lesiński wrote:
WakeLock.request() expecting a string isn't very friendly to feature
detection.
I'd prefer if individual lock types were instances of objects, e.g.
navigator.*Lock objects could be instances of a variant of the WakeLock
interface:
On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote:
Note that in the API that I'm proposing, there is no way to
accidentally rely on GC behavior. If a WakeLock object is GCed before
it has been release()ed, then the lock is held indefinitely (until the
user leaves the page of course).
I.e.
On Sat, 16 Aug 2014, at 08:40, Jonas Sicking wrote:
On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri mou...@lamouri.fr
wrote:
On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote:
I am however more worried about that only having a request() and a
release() function means that pages
On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote:
I am however more worried about that only having a request() and a
release() function means that pages that contain multiple independent
subsystems will have to make sure that they don't stomp on each
other's locks. Simply counting request()
On Wed, 16 Jul 2014, at 21:41, Arpita Bahuguna wrote:
Hi Mounir,
Agree! These meta extensions do appear to be an appropriate fit for the
Web
Manifest.
However, am not sure how well the Manifest would be able to handle
dynamically changing values for these extensions.
Consider the
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
On Wednesday, July 16, 2014 at 5:59 AM, Mounir Lamouri wrote:
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
I do not think we should have this timeout option. That sounds like a
very week use case and something fairly easy
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
### Timeouts
We are thinking of adding a dictionary to hint at the system the amount
of time it should hold the lock for (in ms). So, then the developer can
express holding the lock for 5 minutes (e.g., ebook case, instead of
having to
On Tue, 15 Jul 2014, at 20:11, Arpita Bahuguna wrote:
I would like to propose addition of the following three meta extensions:
website-mail, website-number and website-address.
It seems that those meta extensions would be good candidates for the Web
Manifest: http://w3c.github.io/manifest/
--
On 01/08/13 19:17, Laurent Perez wrote:
Our user agent is a HTTP proxy, currently we are feeding it HTML5 pages,
then we are parsing custom data-* attributes and replacing them with UI
components, for example data-carousel becomes a touch carousel, and so on.
Instead of creating another
On 11/06/13 23:46, Albert Bodenhamer wrote:
Address CEDEX codes:
Problem: They don't fit well into the postal-code field and are often
handled as a separate entity.
Proposal: Add a field name for CEDEX code.
As far as I can tell, CEDEX is never explicitly asked in French web
forms. Likely
On 29/05/13 11:12, Takayoshi Kochi (河内 隆仁) wrote:
Hi WHATWG,
We work on W3C IME API (http://www.w3.org/TR/ime-api/) and we got comment
from
Microsoft people that it would be nice to have inputmode attribute in
conjunction with the API.
Currently the inputmode attribute is spec'ed as
Hi,
Currently, the specification seems to take care of min max by simply
making the element suffering from a value underflow such as a value
overflow. Also, input type='range' has a special behaviour in that
situation. However, if you try different implementations, the behaviours
when min max a
Hi,
Currently the specification specifies some form control sizes (at least
text controls and progress and meter elements) but most of the form
controls bindings do not specify the expected default size of the
control. I believe that the default size is quite important for
interoperability,
Hi,
As Wes suggested it recently [1], we need a way for content to be able
to ask for their media to be played in the background. This is
particularly useful on Mobile when applications could have their audio
shut down when they are in the background. However, we can imagine that
someone
On 31/03/13 15:33, Anne van Kesteren wrote:
There are a couple of scenarios http://notifications.spec.whatwg.org/
does not address at the moment.
A) User navigates to chat site. Chat site creates a notification from
a chat with P while the user does something else. User closes chat
site and
On 29/03/13 17:27, Ian Hickson wrote:
On Tue, 26 Mar 2013, Jonathan Watt wrote:
The result of the discussion here:
http://www.w3.org/mid/514a17d4.3070...@jwatt.org
is that I've changed Firefox Nightly's handling of input type=range to
allow it to render as a vertical slider if it has an
On 08/02/13 17:53, Chundong Wang wrote:
Hello - Got a question of screen orientation on portrait/landscape.
Let's say we have a device doesn't support portrait-secondary, by
spechttp://www.w3.org/TR/screen-orientation/ we should remove it from allow
list which is fine. However if web
On 28/03/13 10:10, Dave Raggett wrote:
Is the orientation independent of or effected by the text directionality
in the context in which the input element occurs?
Depending on the orientation, text directionality might have an impact
on the element or not. For example, when horizontal, the
On 26/03/13 14:55, Simon Pieters wrote:
On Tue, 26 Mar 2013 15:07:55 +0100, Jonathan Watt jw...@jwatt.org wrote:
The result of the discussion here:
http://www.w3.org/mid/514a17d4.3070...@jwatt.org
is that I've changed Firefox Nightly's handling of input type=range
to allow it to render as
, Mounir Lamouri mou...@lamouri.fr
wrote:
Basically, the Mozilla's inputmode attribute is describing behaviour,
the allowed value are mostly self-explanatory: auto, uppercase,
lowercase, titlecase, autocapitalized, digit and numeric.
What's the difference between auto and autocapitalized?
'auto
Hi,
Mozilla did implement an inputmode attribute for the input element a
few months ago and the HTML specification has been updated after that to
introduce that attribute. Given that the specification and our
implementation was not matching, we decided to delay the release of that
feature [1] and
On 01/02/13 15:39, Glenn Maynard wrote:
On Thu, Jan 31, 2013 at 6:20 AM, Bruce Lawson bru...@opera.com wrote:
The use-case for an input type I imagine is that a browser can have a
select-like UI (Jan, Feb, March, April ...) which, in a French language
browser becomes Janvier, Fevrier, Mars,
On 08/01/13 00:47, Ian Hickson wrote:
On Wed, 21 Nov 2012, Mounir Lamouri wrote:
On 20/11/12 22:51, Ian Hickson wrote:
On Tue, 20 Nov 2012, Mounir Lamouri wrote:
At Mozilla, we think that the main use case for stepUp() and
stepDown() is to create a UI with spin buttons: clicking on the up
Hi,
In my war against useless input types, I had a look at 'month' and
'week' and I am wondering what was the rationale behind having them in
the HTML specifications.
Regarding 'month', I mostly don't understand the use case. I can't find
any situation where I am asked to input a { month, year }
On 07/12/12 21:42, Victor Costan wrote:
On Wed, Dec 5, 2012 at 12:11 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 5 Dec 2012, Victor Costan wrote:
There was a thread on this mailing list discussing making it possible to
set the file data behind an input type=file element.
On 20/11/12 08:37, Nicolas Froidure wrote:
On 20/11/2012 07:17, Ian Hickson wrote:
a date/time picker that works just like the
one without a timezone, except that it then converts the time you give
into UTC.
That's exactly the behavior i would like to have. From the server side
it seems
On 20/11/12 06:17, Ian Hickson wrote:
FWIW, the UI I'd expect for today's datetime, maybe renamed to
datetime-global, would be a date/time picker that works just like the
one without a timezone, except that it then converts the time you give
into UTC. So far example, I'm in the PST time
On 20/11/12 22:51, Ian Hickson wrote:
On Tue, 20 Nov 2012, Mounir Lamouri wrote:
Currently stepUp(n) and stepDown(n) are very basic methods. They more or
less do value += n * allowedValueStep; with n = -n; if stepDown() was
called. In addition of being pretty dumb, there are a lot
On 20/11/12 22:55, Ian Hickson wrote:
On Tue, 20 Nov 2012, Scott González wrote:
Can you explain why these methods should be no-ops if the value is above
the max or below the min? In jQuery UI, we decided that using these
methods should always result in a valid value.
I actually missed
On 11/11/12 13:26, Charles McCathie Nevile wrote:
On Sun, 11 Nov 2012 07:50:48 +0100, Maciej Stachowiak m...@apple.com
wrote:
(1) If this API fills in a form completely based on stored data, and
not by completing the user's typing, then it is autofill rather than
autocomplete.
Yep.
(2)
Hi,
Currently stepUp(n) and stepDown(n) are very basic methods. They more or
less do value += n * allowedValueStep; with n = -n; if stepDown() was
called. In addition of being pretty dumb, there are a lot of reasons why
they can throw.
At Mozilla, we think that the main use case for stepUp() and
On 13/11/12 10:51, Nicolas Froidure wrote:
So making datetime having the behavior of datetime-local does not seem
to be necessary for consistency. In any case, i think that we still need
a way to define a datetime in a particular timezone since you cited one
case in which it make sense.
On 13/11/12 09:42, TAMURA, Kent wrote:
The current UI implementations of Opera, iOS, and Chrome-Android spoil the
HTML standard. Web authors hardly have motivation to use type=datetime.
They can add 'UTC' text, and their code can append 'Z' to values easily.
I agree that the type names are
Hi,
We've been working on implementing date and time input types attributes
at Mozilla this summer and we found out that 'datetime-local' and
'datetime' have a quite odd behaviour.
'date' and 'time' are both timezone agnostic types: you just set a time
and date and we assume that it is relative
On 08/27/2012 07:01 PM, Andy Davies wrote:
On 27 August 2012 20:25, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Aug 27, 2012 at 10:56 AM, Ian Hickson i...@hixie.ch wrote:
True, so this is perhaps closer to an IME hint, as has been suggested
for a couple of other input types.
Do you
On 08/30/2012 12:12 PM, Tab Atkins Jr. wrote:
It shouldn't be a new input type, because it's not a *type* of value.
Barcodes are simple a wrapper for a value, to make it more easily
machine-readable. Scanning a barcode is an input mode for a value,
just like typing or speaking it is.
Indeed.
On 05/20/2012 03:04 PM, Boris Zbarsky wrote:
On 5/20/12 5:45 AM, Paul Irish wrote:
Since no one mentioned it, I just wanted to make sure this thread is
aware
of the Network Information API [1], which provides
navigator.connection.bandwidth
It's been recently implemented (to some degree) in
On 05/21/2012 04:42 PM, James Graham wrote:
On 05/21/2012 04:34 PM, Boris Zbarsky wrote:
If I'm reading the right code now, that looks like it returns a constant
value for each connection type (e.g. if you're connected via Ethernet or
Wifi it returns 20; if you're connected via EDGE it returns
On 05/21/2012 04:34 PM, Boris Zbarsky wrote:
On 5/21/12 10:09 AM, Mounir Lamouri wrote:
On 05/20/2012 03:04 PM, Boris Zbarsky wrote:
On 5/20/12 5:45 AM, Paul Irish wrote:
Since no one mentioned it, I just wanted to make sure this thread is
aware
of the Network Information API [1], which
Hi,
According to the HTML specifications, a textarea is mutable if it is
neither disabled nor has a readonly attribute specified. Which means
that a textarea outside of a document is mutable. This is not the case
for an input element.
I was wondering why there is this difference in behavior here
On 05/08/2012 10:29 AM, Paul Adenot wrote:
Currently implementing the media attribute for the source element in
Gecko, we are not sure on how to interpret the spec when the attribute
is not set in the HTML source.
Considering this snipped of code :
video
source id=asource
On 04/03/2012 01:23 AM, Ian Hickson wrote:
On Tue, 6 Dec 2011, Anne van Kesteren wrote:
You could also have
meta name=intent content=http://webintents.org/share image/*
or some such. Splitting a string on spaces and using the result is not
that hard and a common pattern. And seems like a
On 03/26/2012 02:37 PM, Ian Melven wrote:
While working on implementing HTML5's iframe sandbox, I realized that in
script, one can't
tell the difference between these two cases : iframe and iframe sandbox =
''.
In both cases, iframe.sandbox will be '' (the empty string). This is
true in
On 02/10/2012 05:49 AM, Ms2ger wrote:
On 02/10/2012 11:39 AM, 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
On 02/07/2012 10:19 PM, Charles Pritchard wrote:
On 2/7/2012 1:14 PM, Matthew Wilcox wrote:
Also, I am writing this on a laptop via a throttled mobile
connection.
It'd be nice if sites had the capability to adapt to that throttle
then wouldn't it...
As I read through this thread -- all
On 12/15/2011 10:17 PM, Ilya Sherman wrote:
To that end we would like to propose adding an autocompletetype attribute
[1] to the HTML5 specification, as a complement to the existing
autocomplete attribute that would eliminate ambiguity from the process of
determining input data types. We
On 01/10/2012 11:24 PM, Ian Hickson wrote:
On Fri, 10 Jun 2011, Mounir Lamouri wrote:
On 06/04/2011 12:57 AM, Ian Hickson wrote:
I've added equivalent text back. It describes the Opera/IE behaviour;
could you elaborate on why the WebKit behaviour is better?
Webkit behavior makes more sense
On 01/11/2012 01:05 AM, Ian Hickson wrote:
On Tue, 14 Jun 2011, Rafa�~B Mi�~Becki wrote:
We already have required attribute and :valid plus :invalid classes,
which are nice. However some may want to display additional warning when
form wasn't filled correctly. Just some single warning, not
On 10/16/2011 02:17 PM, Daniel Bates wrote:
How should overflow be handled when parsing integers?
Step 8 of the parsing algorithm in
bothhttp://dev.w3.org/html5/spec/Overview.html#rules-for-parsing-integers
andhttp://dev.w3.org/html5/spec/Overview.html#non-negative-integers doesn't
mention
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
On 06/15/2011 07:00 PM, Boris Zbarsky wrote:
On 6/15/11 4:31 AM, Eduard Pascual wrote:
2011/6/14 Rafał Miłeckizaj...@gmail.com:
We already have required attribute and :valid plus :invalid classes,
which are nice. However some may want to display additional warning
when form wasn't filled
On 06/04/2011 12:57 AM, Ian Hickson wrote:
On Thu, 17 Feb 2011, Mounir Lamouri wrote:
According to a comment of Hixie in [1], this case has been handled by
the specs in 2004 but it doesn't seem to be any more and UA's have a
very different behaviour here:
- Firefox: focus and activate
On 05/05/2011 01:02 AM, Aryeh Gregor wrote:
On Tue, May 3, 2011 at 8:04 PM, Jonas Sickingjo...@sicking.cc wrote:
The mozNoFilter attribute we added in Firefox 4.
I don't see any use-case where you wouldn't want to use mozNoFilter.
Why doesn't it just work that way always?
Basically, when
On 05/02/2011 10:44 PM, Ian Hickson wrote:
On Fri, 31 Dec 2010, Mounir Lamouri wrote:
On 12/31/2010 02:20 AM, Ian Hickson wrote:
far as I can tell. Anything that's visible and submitted is a candidate
for constraint validation.
Exceptkeygen andobject.
But do we agree that it's visible
Hi,
I'm working on the labels attribute implementation in Gecko and I have a
few remarks:
* I wonder what are the use cases for authors. I see some use cases for
browser vendors (a11y and UI for example) but what an author would do
with that attribute?
* The labels attribute returns a NodeList
On 03/12/2011 12:56 AM, Jonas Sicking wrote:
inp = document.createElement(input);
inp.setAttribute(value, foo\nbar);
inp.setAttribute(type, hidden);
and
inp = document.createElement(input);
inp.setAttribute(type, hidden);
inp.setAttribute(value, foo\nbar);
This does not seem desirable.
On 03/25/2011 05:24 AM, Koji Ishii wrote:
Thank you for the reply.
Anyway, do you have any concern about the behaviors of the current browsers?
No, not as of now particularly. Neither I know how UAs are going to implement
require that authors not let authors enter values longer than the
Hi,
Currently, the specs say that select(), selectionStart, selectionEnd and
setSelectionRange() only apply to the input element when the type is
text, search, url, telephone or password. Obviously, they should also
apply when type is email [1].
But, I'm wondering what should be done for types
On 03/08/2011 02:22 PM, Markus Ernst wrote:
select
option label=Label1TextContent1/option
option label=Label2TextContent2/option
/select
- IE 8, Opera 11 and Chrome 9 display Label1 and Label2
- Firefox 3.6 displays TextContent1 and TextContent2
Firefox's behavour seems to be
On 02/16/11 08:31, Jukka K. Korpela wrote:
The current version disallows the size and maxlength attributes in input
elements when type=time, type=date, type=datetime,
type=datetime-local, type=number, type=range, or type=color is
used.
I suppose the reason is that for other new input types,
Hi,
Mozilla has an old Gecko bug [1] lying around about form controls not
focusable when they are inside a label that is not labelling them: when
the user clicks the form control, because it's part of the label, the
activation behaviour is done on the labelled element. Thus, the form
control
On 02/11/2011 11:23 PM, Ian Hickson wrote:
Following up on the e-mail I just sent, which was on the same topic (I
missed that there was more to the thread when replying to that one):
On Wed, 24 Nov 2010, Mounir Lamouri wrote:
After Firefox 4, we would like to introduce a new flag
On 02/04/11 11:55, Anne van Kesteren wrote:
This must have been brought up before as e.g.
http://pukupi.com/post/2070/ is from June 2010, but I could not find
anything quickly. Apparently people are using IDNs and cannot get them
validated with email controls because the specification
Hi,
A few months ago all float attributes changed to double attributes [1].
I'm wondering why float IDL attributes reflecting content attributes
moved to double attributes given that the content attributes are still
following the rules for parsing floating point numbers [2]. So, AFAIUI,
these
it was specced and hopefully it makes more sense now.
On Thu, 21 Oct 2010, Mounir Lamouri wrote:
For the moment, a valid email address list is a set of comma-separated
tokens where each tokens are a valid email address so in the case of
f...@bar.com, , f...@bar.com is a valid email address
On 01/05/2011 02:29 AM, Ian Hickson wrote:
On Thu, 14 Oct 2010, Olli Pettay wrote:
may I wonder why on earth any new API, like
link.sizes uses PutForwards?
IMHO, PutForwards should be limited to the
awkward DOM0 APIs like window.location.
On Fri, 15 Oct 2010, Olli Pettay wrote:
It makes
On 12/31/2010 03:20 AM, Ian Hickson wrote:
On Fri, 24 Sep 2010, Mounir Lamouri wrote:
I agree that a child of a datalist element should not block the form
submission. However, I'm wondering why do we care about this particular
edge case when there are a lot of situations where an element
On 12/31/2010 02:13 AM, Ian Hickson wrote:
On Thu, 23 Sep 2010, Mounir Lamouri wrote:
The current specification of :invalid is pretty simple: it matches all
invalid elements which are candidate for constraint validation.
Today, Gecko betas, Presto and Webkit support :invalid (I didn't check
On 12/31/2010 02:20 AM, Ian Hickson wrote:
On Thu, 23 Sep 2010, Mounir Lamouri wrote:
It sounds like currently the specifications want explicitly to have all
submit controls being subject for constraint validation [1] which seems
to be a weird idea. Given that only setCustomValidity() can
On 12/29/2010 07:41 AM, Ian Hickson wrote:
One way to do this would be to make the invalid event implement an
interface with a function like setCustomErrorMessage(in DOMString
message). This string would then be displayed by the UA in its UI
wherever it displays validation error messages.
On 11/29/2010 04:15 PM, Anne van Kesteren wrote:
On Thu, 04 Nov 2010 01:20:37 +0100, Mounir Lamouri
mounir.lamo...@gmail.com wrote:
Currently, when a radio button is required, it will suffer from being
missing if no radio elements in the radio button group is checked.
However, radio elements
On 11/16/2010 04:35 PM, Anne van Kesteren wrote:
Actually, that specific problem was addressed long ago based on feedback
from us:
Constraint validation: If an element has a maximum allowed value
length, and its dirty value flag is true, and the code-point length of
the element's value is
On Thu, 12 Aug 2010, Aryeh Gregor wrote:
On Wed, Aug 11, 2010 at 6:03 PM, Ian Hickson i...@hixie.ch wrote:
The script setting the value doesn't set the dirty flag. The only way
this could be a problem is if the user edits the control and _then_
the script sets the value to an overlong
On 11/16/2010 04:35 PM, Anne van Kesteren wrote:
On Tue, 16 Nov 2010 16:04:08 +0100, Mounir Lamouri
mounir.lamo...@gmail.com wrote:
There is a LinkedIn form broken because of that: there are two fields
with a non-HTML5 placeholder (ie. it's the value) which is set with
.value=something
Hi,
Currently, when a radio button is required, it will suffer from being
missing if no radio elements in the radio button group is checked.
However, radio elements in the group will not suffer from being missing
if they do not have the required attribute. In other words, if you try
to style
On 11/01/2010 08:15 AM, Jonas Sicking wrote:
On Sun, Oct 31, 2010 at 7:31 PM, TAMURA, Kent tk...@chromium.org wrote:
A team in Google tried to use input type=number for a product, and they
decided
not to use it.
What they needed was a control to select an integer from a specific integer
Hi,
For the moment, a valid email address list is a set of comma-separated
tokens where each tokens are a valid email address so in the case of
f...@bar.com, , f...@bar.com is a valid email address but not .
Unfortunately, as soon as you want to put a UI on top of that, values
will always be
On 10/21/2010 03:31 PM, Mounir Lamouri wrote:
Hi,
For the moment, a valid email address list is a set of comma-separated
tokens where each tokens are a valid email address so in the case of
f...@bar.com, , f...@bar.com is a valid email address but not .
Unfortunately, as soon as you want
On 10/01/2010 05:11 PM, Jonas Sicking wrote:
I suggest that when pattern and multiple are both applied on a
control, that the pattern is applied to each individual component of
the value, rather than the value as a whole.
That makes sense. However,this is removing some possibilities with the
Hi,
I agree that a child of a datalist element should not block the form
submission. However, I'm wondering why do we care about this particular
edge case when there are a lot of situations where an element can be
invalid without any possible action from the user.
If there is no specific use
On 08/11/2010 03:03 PM, Ian Hickson wrote:
On Tue, 20 Jul 2010, Mounir Lamouri wrote:
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
Hi,
The list attribute [1] on input elements let the author specify a list
of pre-defined suggestions via the datalist element (each option of the
datalist is a suggestion). It looks like the idea is to have all the
suggestions showing like a combobox which is more or less confirmed by
Hixie [2].
(Re-sending this email which was only addressed to Aryeh by mistake.)
On 09/21/2010 09:43 PM, Aryeh Gregor wrote:
I think only Opera has UI at all), so it's best to just
not use it for now.
Firefox nightlies too. Will be in Firefox 4 beta 7.
On 09/21/2010 10:35 PM, Shiv Kumar wrote:
That
On 09/22/2010 02:51 PM, Aryeh Gregor wrote:
data:text/html,!doctype htmlforminput name=x required
oninvalid=this.setCustomValidity(''); if (!this.validity.valid)
this.setCustomValidity('abcd') input type=submit/form
In a Firefox 4 nightly, when I click the submit button, the error is
just
Hi,
The current specification for the fieldset element's disabled attribute
is the following:
The disabled attribute, when specified, causes all the form control
descendants of the fieldset element, excluding those that are
descendants of the fieldset element's first legend element child, if
Hi,
For a few days, Firefox's nightly had a bug related to value sanitizing
which happens to be a specification bug.
With the current specification, these two elements will not have the
same value:
input value=foo#13;bar type='hidden'
input type='hidden' value=foo#13;bar
Depending on how the
On 09/21/2010 10:18 PM, Jonas Sicking wrote:
On Tue, Sep 21, 2010 at 9:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Also, it would mean that the following two pieces of code behaves differently:
inp = document.createElement(input);
inp.setAttribute(value, foo\nbar);
inp.setAttribute(type,
Hi,
With HTML4 (at least before fieldset.disabled), form controls disabled
IDL attribute was a simple way to set and get the disabled state because
the disabled state and the disabled content attribute were exactly the
same thing.
Now, with fieldset.disabled, disabled IDL attribute has no longer
Hi,
The current state of the specifications do not mention fieldset elements
for the :enabled and :disabled pseudo-classes but fieldset can be
disabled so I guess it might be convenient to have these pseudo-classes
applied to them.
Opera applies :disabled and :enabled to fieldset elements and
Hi,
It looks like the reset algorithm for input elements is considering all
types except the input type='file'. Shouldn't empty the list of
selected files be added?
Thanks,
--
Mounir
On 08/17/2010 09:20 PM, Aryeh Gregor wrote:
Actually, it goes further than that. Everyone but IE seems to just
return the value of the content attribute when you do a get on the IDL
attribute:
!doctype html
script
var el = document.createElement(form);
el.setAttribute(method, invalid
On 08/10/2010 07:09 AM, Garrett Smith wrote:
Many times you want the user to make an explicit choice, rather than
just leaving whatever was already selected. What many websites do is:
labelChoose an option:
select
option/option
optionvalue 1/option
optionvalue 2/option
1 - 100 of 127 matches
Mail list logo
