Re: [whatwg] Standardizing autocapitalize
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 certainly mark them as deprecated, but unless their usage is negligible, it seems better to document their behavior than to try to change all existing content not to use it. Especially since it'll also make the .autocapitalize JS property behave less surprising on/off is used. off is defined. The Non-conforming note means that the attribute reflection will behave like this: ```js input.autocapitalize = 'off'; input.autocapitalize === 'none'; // true ``` Right. My point is that this is unnecessarily confusing. Just like input.autocapitalize = 'on'; input.autocapitalize === 'sentences'; // true is unnecessarily confusing. How is that different from ```js input.type = 'foo'; input.type === 'text'; // true ``` Unless we expect that doing |input.autocapitalize = 'on'| is common use case. Which I think isn't. Just like leaving mention of on out of documentation and specs would be confusing for authors that are looking at other people's code and learning from it (which is one of the great powers of the web platform). The specification should definitely mention on in a non-normative section. The same way it should mention off as an allowed but deprecated value. I will have to double-check that but I wonder if the IDL attribute isn't always returning undefined on Safari iOS. At least, I wasn't able to use it last time I checked. Would that solve your concerns? -- Mounir
[whatwg] Standardizing autocapitalize
(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 user experience with the keyboard on Mobile. I wrote a small proposal document based on Apple's document and live tests on latest Safari mobile: https://github.com/mounirlamouri/html-autocapitalize/blob/master/proposal.md I would be really interested to hear from other vendors, particularly if they would be interested to implement it. In addition, if Apple has some feedback about the proposal, it would be very valuable. Thanks, -- Mounir
Re: [whatwg] Standardizing autocapitalize
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 fairly low while it can be very beneficial for the user experience with the keyboard on Mobile. Cool. We proposed it here back in 2011, though it didn't end up getting adopted. https://www.w3.org/Bugs/Public/show_bug.cgi?id=12409 It might be worth reading the old discussion around this topic. It seems that the main reason why it was killed is because it was considered that inputmode superseded autocapitalize. Unfortunately, in the wild, this is not the case and we (Google) have data about the usage of the attribute (cf Hixie's comment 1). I believe it is high enough to consider standardizing. In addition, if Apple has some feedback about the proposal, it would be very valuable. I'll take a look and get back to you. Thanks :) 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 certainly mark them as deprecated, but unless their usage is negligible, it seems better to document their behavior than to try to change all existing content not to use it. Especially since it'll also make the .autocapitalize JS property behave less surprising on/off is used. off is defined. The Non-conforming note means that the attribute reflection will behave like this: ```js input.autocapitalize = 'off'; input.autocapitalize === 'none'; // true ``` The same way you would have: ```js input.autocapitalize = 'NoNe'; input.autocapitalize === 'none'; // true ``` Basically, off should behave as none which is what Safari iOS is doing AFAIK. Regarding on, as pointed by Ted in the linked bug, it behaves like sentences (for states text and search). sentences is also the default value for those. This is the value that would be used if you were to type foobar or whatever. The fact that on is used a lot (or not) isn't really relevant here. To quote Ted In reality, if the attribute is present then only off is checked and all other values are assumed to be on. (He is mentioning the deprecated API.) HTH, -- Mounir
Re: [whatwg] Adding a property to navigator for getting device model
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 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? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. Isn't Cordova experience feedback a bit out of scope if usually developers do UA sniffing on the server side? It seems that such a feature would mostly benefit web sites that already entirely live on the client side and might be more inclined to do feature detection. -- Mounir
Re: [whatwg] Adding a property to navigator for getting device model
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 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 using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. Isn't Cordova experience feedback a bit out of scope if usually developers do UA sniffing on the server side? It seems that such a feature would mostly benefit web sites that already entirely live on the client side and might be more inclined to do feature detection. If feature detection covered all the use cases, then why would the Cordova module be so popular? I would love to know actually. Silvia, do you have any insights? -- Mounir
Re: [whatwg] Adding a property to navigator for getting device model
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
Re: [whatwg] Adding a property to navigator for getting device model
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 using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? -- Mounir
Re: [whatwg] Adding a property to navigator for getting device model
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
Re: [whatwg] Feature-detectable WakeLocks
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:
navigator.screenLock.request();
navigator.screenLock.isHeld();
navigator.cpuLock.request();
navigator.cpuLock.release();
I think the problem of feature detection is fair. Though, I think a
pattern like navigator.wakeLock.${name}.request(); would be conveniently
namespace'd. You would have .request, .release() and .held() (or.has())
I guess.
-- Mounir
Re: [whatwg] Proposal: Wake Lock API
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. an unbalanced request() and release() in both the currently proposed API, and in the API that I propose behave the same, the lock is held indefinitely. Any objects getting GCed does not change this. I overlooked that aspect, my apologies. It sounds good. I am not sure if that would be safer than global methods in the sense that developers will still be able to shoot themselves in the foot by not calling .release() or might assume that .release() will be called upon object destruction. How would you handle feature detection with this design? -- Mounir
Re: [whatwg] Proposal: Wake Lock API
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 that contain multiple independent subsystems will have to make sure that they don't stomp on each other's locks. Simply counting request() calls vs. release() calls helps, but doesn't fully solve the problem. It's very easy to accidentally call release too many times, in response to some UI action for example. An alternative design would be something like x = new WakeLock(display); x.request(); x.release(); Extra calls of either request() or release() are ignored, but pages can create any number of WakeLocks of the same type. It seems that we already discussed using an object and this solution was dismissed because of this model being error-prone. Where was this discussed? Why was it considered more error prone? Was it related to the patterns discussed at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297431.html There might have been some discussions in the DAP WG (but the archives website isn't helping). There was definitely at thread in blink-dev [1] and you might want to have a look at the GitHub repo [2]. By the way, it seems that this API might be worked in the DAP WG [3]. It's also not clear how this solution is superior than the current solution [1] with regards to multiple releases or requests. In [1], if you call .request() or .release() multiple time, the promise reacts appropriately. The problem arises when you have several semi-independent pieces of code within a single page. Given that request() and release() is likely going to happen in response to very different UI events or IO events, it makes it fairly easy to accidentally have unbalanced calls. Consider for example a lock which is released either when a video reaches its end, when the user presses the pause button, or when the user close the dialog in which the video is rendered. It seems quite easy to end up with a race where if the user close the dialog right when the video ends, that release() would get called twice. Or if the user pause the video first and then close the dialog that release() would get called twice. If there's only one subsystem of the page that uses a display lock, then this is not a big deal. The extra call to release() would cause an rejection, but hopefully that won't break the page. It is possible that the API might behave differently and the first release() will release the lock even if lock() was called multiple times. I guess the scope of the lock could be the browsing context so a website will not end up conflicting with iframes. However, if a websites embeds libraries that use this API, it will need to coordinate. However if there are multiple subsystems that all use a display lock, it would mean that those subsystems might stomp on each other's attempts at holding a display lock. The effect would be that the display lock is released too early. I don't care strongly about this though. It's pretty easy for pages to write a wrapper around the currently proposed API to implement the API that I'm proposing. I understand the problem and I agree that an object-based approach would be nicer in theory because the scope of the lock would be well defined. However, it's a very uncommon pattern as far as Web APIs are concerned and I would worry that developers would end up doing things wrong and depend on the GC behaviour without even being aware of it. [1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/SzVuAi2KRhA/OaNDiHOKl8gJ [2] https://github.com/w3c/wake-lock [3] http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0035.html -- Mounir
Re: [whatwg] Proposal: Wake Lock API
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() calls vs. release() calls helps, but doesn't fully solve the problem. It's very easy to accidentally call release too many times, in response to some UI action for example. An alternative design would be something like x = new WakeLock(display); x.request(); x.release(); Extra calls of either request() or release() are ignored, but pages can create any number of WakeLocks of the same type. It seems that we already discussed using an object and this solution was dismissed because of this model being error-prone. It's also not clear how this solution is superior than the current solution [1] with regards to multiple releases or requests. In [1], if you call .request() or .release() multiple time, the promise reacts appropriately. Typically, if you try to release() an un-hold lock, it will reject the promise. Is that something you are not satisfied with? [1] http://w3c.github.io/wake-lock/ ? -- Mounir
Re: [whatwg] Proposal to add website-* meta extensions
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 use-case wherein, based on the location of the user, JavaScript changes the value of the website-number meta extension to give a more relevant contact phone number. As a meta extension, this is easily achievable. But would the content provider be able to change the values based on the location via Manifest? (do pardon my lack of knowledge in this area) For the moment, the Web Manifest specification doesn't provide an API to modify the Manifest after the page load. However, the server can provide a different manifest depending on the user. It seems that serving different manifest is probably what you should do here. -- Mounir
Re: [whatwg] Proposal: Wake Lock API
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 to do with the tools the
platform already provides. The argument to support this feature in the
github issue was that it will prevent developers to forget releasing the
lock but I have a hard time believing that developers forgetting to
release a lock would use a timeout that is probably more painful and
error-prone.
I don't have a strong opinion. My concern was mostly about developers
having to watch for a whole bunch of different interaction queues (touch
events, mouse events, focus events, orientation-change events, etc.) in
order to release the lock at the right time.
Do you have specific UC? The basic UC I have in mind (reading a book,
watching a video, playing a game) would not use a timeout.
### Check if lock is already set
It might be useful to also have a way of checking if a lock is already
set:
``
readonly attribute WakeLockType? lockType
```
You might want something like:
partial interface WakeLock {
readonly attribute WakeLockType[] currentLocks;
};
Given that there can be multiple locks applying at the same time.
Otherwise, the proposal sounds good to me.
Could be... I was thinking that the locks are kinda like a fallback
chain. That is, if you have the screen you also have system. If you
lose screen (notified via an event), you request system before the
device goes to sleep. If it's not possible to do things in that order,
then yes: we would need to return a list of the current locks.
Question remains if there are other kinds of locks that we might need.
For example, Firefox OS has wifi as a lock type. I'm assuming that
their model keeps the cpu on, but the device can still shut down the
radios on a device. In the proposal, we lump wifi and cpu into
system.
Why not breaking these in different sub-systems? I can definitely
imagine my phone having the CPU kept at 100% while the screen is off if
it requires to do a heavy computation. Forcing the screen to stay on
while doing that would be a waste of battery.
-- Mounir
Re: [whatwg] Proposal: Wake Lock API
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 bind a whole bunch of listeners and constantly having to
request the wake lock). This would allow the UA to add whatever time the
developer requested to its normal wake lock timer + additional time the
developer might want. If the timeout is less than the default timeout, it
can just be ignored.
```
dictionary WakeLockOptions{
unsigned long timeout;
}
```
For example:
```
//I only need this for ~5 mins here.
var options = {timeout: 1000 * 60 * 5};
navigator.wakeLock.request(display, options);
```
I do not think we should have this timeout option. That sounds like a
very week use case and something fairly easy to do with the tools the
platform already provides. The argument to support this feature in the
github issue was that it will prevent developers to forget releasing the
lock but I have a hard time believing that developers forgetting to
release a lock would use a timeout that is probably more painful and
error-prone.
### Check if lock is already set
It might be useful to also have a way of checking if a lock is already
set:
``
readonly attribute WakeLockType? lockType
```
You might want something like:
partial interface WakeLock {
readonly attribute WakeLockType[] currentLocks;
};
Given that there can be multiple locks applying at the same time.
Otherwise, the proposal sounds good to me.
-- Mounir
Re: [whatwg] Proposal to add website-* meta extensions
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/ -- Mounir
Re: [whatwg] Splash screen proposal for web apps ?
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 data-splashscreen attribute, we always try standards first, so I'm evaluating the widgets spec, PhoneGap went the feature splashscreen way, RIM chose a rim:splash vendor namespace. On top of that there is also the manifest spec, implemented by Firefox OS. There have been a lot of discussions at Mozilla around this feature recently. The first released versions of Firefox OS have some kind of automatic splash screen mechanism that is under-optimised and not very accurate so our front end engineers asked for a declarative solution in the Web Manifest so they could tweak its behaviour. It seems to match what you are asking. The conclusions of our discussions are that a splash screen is not needed because the first paint of a page can be very quick if the page is designed for this. If all the scripts, stylesheets and content are loaded synchronously, your page will look slow and a splash screen might be required but the Web has many features that allow developers to be smart about time load. Even for applications that need to do some loading by design (let say a game that need to load assets), it is more efficient if the page itself handles the splash screen by loading a simple DOM + stylesheet that would show Loading. Please wait. rather than having the UA taking care of it. The UA will have a hard time to know when to stop loading the splash screen, when to stop it and would have many limitations around animated splash screen, internationalisation, etc. The sysapps WG is what I was looking for, thanks :) The Web Manifest lives in WebApps WG nowadays, you might want to bring that feature request if you still want it. Cheers, -- Mounir
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
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 because usually only organisations (companies, school, administrations) use such things and real people only use it when they have to send paper letters to those. I guess that someone that needs to fill out an address with a CEDEX will whether add it to the post code, the city name or simply not mention it. I doubt it is needed to add a new autocomplete value for that given that I doubt that forms have a field for that. -- Mounir
Re: [whatwg] inputmode attribute
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 http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#input-modalities:-the-inputmode-attribute But the mode looks somewhat sparse. In the Microsoft's proposal, more modalities are populated: https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html#inputmode-attribute Can we discuss the change here to get this proposal merged to the spec? Hi, A couple of months ago I sent some feedback regarding inputmode [1] and based on your reply [2] I assumed that you agreed that we should probably differentiate inputmode and scripts. However, I see that the IME API isn't making this difference and creates a lot of inputmode values to be able to handle different scripts. Is there a specific reason why or is this just in order to follow the HTML specification? [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038914.html [2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038947.html Thanks, -- Mounir
[whatwg] Ignore min and max if min max
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 widely different and generally speaking, such context can create pretty broken UI: a slider that can't move, a number spinner that doesn't allow changing the number's value, etc. I believe that having a special behaviour when min max would be appropriate here. Basically, the min and max attributes should be ignored in that situation. That means that the element's 'minimum' and 'maximum' should be ignored in that situation unless there is a 'default minimum' or a 'default maximum' (which would be used). Adding this to the specification would help having a decent fallback when the attributes are broken instead of broken form controls. FWIW, Chrome's implementation of input type='range' seems to simply ignore min and max when min max. Opera doesn't show any UI in that case. Cheers, -- Mounir
[whatwg] Defines the default size of input type='range' and other form controls
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, especially for inline-block elements that might end-up wrapped in text: if the default height is defined in px or em, the rendering might differ a lot. I think that it would be great to define default sizes for form controls, in em preferably I guess. Thanks, -- Mounir
[whatwg] Proposal: channel attribute on HTMLMediaElement
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 listening to a web music player might want to keep that music stream playing when the browser is no longer in the foreground. Also, it will help browsers to know when to keep media playing or pause them when a tab is put in the background. However, that problem is a sub-class or a larger problem about assigning media elements to a specific channel. This is a problem Firefox OS and Windows 8 have tackled recently with proprietary extensions to HTMLMediaElement [2][3]. This is a feature other platforms have, like Android [4] or PulseAudio (GNU/Linux) [5]. Based on the prior work, Paul Adenot and I tried to figure out the use cases that would apply on the web. Our proposal is to add a channel attribute on HTMLMediaElement. That attribute would give information about the type of channel to use and thus help the UA to know if the channel should be muted or not based on the current context. In addition, depending on the type of channel, the UA could decide to whether or not create a low-latency channel. There is open question regarding the default behaviour. Our proposal makes the default behaviour to only play the media when the website is visible but this is not the common default behaviour and such behaviour might break some websites. Depending on how critical this retro-compatibility issue is, we could add a 'Default' state that would have an undefined behaviour to do whatever retro-compatibility requires. The proposal is the following: The channel attribute gives a hint about the type of channel the author is expecting the UA to use. It is an enumerated attribute that uses the following keywords and states: Keyword: media State: Foreground Media Fallback: none Description: To be used for media element that wants to play basic media such as an audio or video stream that should be paused when the page is put in the background. Keyword: background-media State: Background Media Fallback: Foreground Media Description: To be used for media element that wants to play basic media such as an audio or video stream that should not be paused when the page is put in the background. Music, podcast or radio players are expected to use this state. Keyword: effects State: Effects Fallback: Foreground Media Description: To be used for media element that creates short and quick effects such as button click, game effects. It is intended to be used for effects that are being heard while using the page, not for notifications. When on this state, the media should use a low latency channel. Keyword: notification State: Notification Fallback: effects Description: Like the effects state, this intends to be used fort short and quick media but that require to catch user attention whether the page is currently visible or not. For example, this state could be used for a sound notification when there is a new email in the user's inbox. Keyword: communication State: Communication Fallback: Background Media Description: To be used for media element that transmits real time communication such as phone calls or VOIP. When on this state, the media should use a low latency channel. Keyword: alarm State: Alarm Fallback: Notification Description: To be used for media element that wants to make sure to be played even if the device is currently muted. Typical use case would be an alarm clock. The UA might not support some channels or not allow a specific media element to use some channels, in which case the fallback state should be used. The missing value default is the Foreground Media state. [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-March/039202.html [2] https://wiki.mozilla.org/WebAPI/AudioChannels [3] http://msdn.microsoft.com/en-us/library/windows/apps/hh767375 [4] https://developer.android.com/reference/android/media/AudioManager.html (see STREAM_* constants) [5] http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/ApplicationProperties#line-58 (see PA_PROP_MEDIA_ROLE) Thanks, -- Mounir
Re: [whatwg] Notifications: reviving Notification objects
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 then navigates to chat site at a later point. I guess a better example would be that the website is unloaded on memory pressure but the tab is kept. Otherwise, an explicit user action could be considered as enough to remove all currently opened notifications. 1) Tie the document's address of when a Notification is created to the Notification object to address B) and C). Maybe at some point allow sites to define a URL to open. What if I have to instance of the same website open? what if those two instances have different contexts like not logged in with the same user? 2) Define a method on Navigator, getNotifications(), that returns a Future which is resolved with an array of Notification objects. Once the Future is resolved, a task is queued to fire a click event on the appropriate Notification object in case of B) and C). This magic behaviour with the click event is a bit weird. Does that mean that the UA shouldn't do anything with the notification? What if the website never calls getNotifications()? We could expect the UA to close the notification by default when the website is re-opened but if it has to wait for a possible .getNotifications() call, what should be done? Timing out seems a bit racy. -- Mounir
Re: [whatwg] Allowing authors to obtain a vertical input type=range
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 orient=vertical attribute on it. There was only one reply to my email to www-style, but the author suggested using an attribute which I'd also concluded was the best thing to do. I'd like to propose that this attribute be added to the HTML5 specification. It seems like a very medium-specific attribute. Why wouldn't this be a CSS issue? That's the layer of the Web platform where we put presentationa-specific things. I'm not a big fan of adding presentation-specific things to the markup but I do not see another solution here. If we set the orientation in CSS, we can't select elements based on their orientation because the properties associated with the rule might change their orientation, thus ending in an infinite loop. After talking with Boris Zbarsky and David Baron, they said that could be prevented by hacks to actually not go in such loop but they were not very happy about it. For progress and meter, Mozilla decided to set the orientation based on a CSS property and not allow users to select elements based on their orientation. It seems like developers would like to select elements based on their orientation and in that case, using the markup to set the orientation seems to be the only solution. But in this particular case, why do we need authors to explicitly say anything about the direction? Why can't you just be vertical if you're tall, and horizontal if you're wide? I don't understand why anyone would ever want a tall horizontal slider. The fact that Webkit, Trident and Gecko are not doing that on purpose should be a good sign that this is not a good idea. Even jQuery changed its behaviour. You can easily imagine a square element that wants to be represented horizontal or vertical or a wide element that wants a vertical representation (the wideness coming from labels on tickmarks for example). There is an example in this old email from Sylvain Galineau: http://lists.w3.org/Archives/Public/www-style/2011Apr/0386.html -- Mounir
Re: [whatwg] A question about portrait-secondary of screen orientation
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 developer specified portrait instead of portrait-primary for lockOrientation(), which I suppose is a common case, we'll have to expand it to portrait-primary, portrait-secondary according spec. In this case the lockOrientation() would fail because orientations isn't a supported orientation set. I don't think it'll satisfy the original purpose of portrait. IMHO, we should explain this more detailed. We could either, 1. Only expand portrait(or landscape) into allowed orientations, or; 2. Filter out disallowed orientations from orientation sequence and lock the screen with that list. Thank you for your feedback, it is quite interesting. I went with the first solution you proposed. The only down-side with that solution is that lockOrientation(portrait) would no longer be exactly like lockOrientation([portrait-primary, portrait-secondary]) but I guess this is better for developers who don't care which portrait orientation are allowed exactly. I am assuming that someone using the explicit form might want to know if that failed and wouldn't prefer a half-working lock without notification. You can view the updated document here : https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html By the way, this specification is being worked on in the WebApps WG so posting in the webapps mailing-list would have been better ;) Cheers, -- Mounir
Re: [whatwg] Allowing authors to obtain a vertical input type=range
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 element will be filed from left to right or right to left depending on the directionality but it will have no impact when vertical. However, the orientation isn't affected by the directionality. What did you have in mind? Cheers, -- Mounir
Re: [whatwg] Allowing authors to obtain a vertical input type=range
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 a vertical slider if it has an orient=vertical attribute on it. There was only one reply to my email to www-style, but the author suggested using an attribute which I'd also concluded was the best thing to do. I'd like to propose that this attribute be added to the HTML5 specification. I don't have strong opinions on this topic, however, if we are going to add an attribute, it would be less verbose to use a boolean attribute: input type=range vertical I think that the orient attribute should be used for progress and meter too and those elements would need a third state in addition of 'vertical' and 'horizontal' that would be 'square' (or 'round' or 'center', whatever is the best name). That would allow spinners for progress [1] or round progress/meter UI like [2]. Using a vertical attribute would hardly solve those use cases whilst the orient attribute would deal with them quite easily. I also agree that 'auto' is a pretty undesirable behaviour. As far as I know, this is the behaviour input type='range' is requested to have and no one implemented it. Microsoft expressed their concerns about it two years ago to www-style [3]. [1] http://i.stack.imgur.com/bdrWh.png [2] http://www.clker.com/cliparts/L/c/G/Z/z/U/masque-alpha-camembert-md.png [3] http://lists.w3.org/Archives/Public/www-style/2011Apr/0386.html -- Mounir
Re: [whatwg] inputmode feedback
On 15/02/13 08:28, Takayoshi Kochi (河内 隆仁) wrote:
As you probably know, there is also 'ime-mode' CSS style which IE/FF
implements
(and still proposed in CSS3 UI at http://www.w3.org/TR/css3-ui/#ime-mode),
which makes this more complex to use.
Is that implemented by some vendors?
People may want to control IME input mode like the way Flash can,
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/IME.html
but it it is unfortunate that controlling IME from web apps is so
distributed (CSS, input attribute,
DOM lv3 compositionevent and IME API).
As I see it @inputmode isn't here to be a feature like this but maybe
Hixie had a different vision when he wrote the specs for it.
That said, even though authors of web apps may want to force the IME
mode or
its script mode for user's sake, it may cause user's confusion as they are
so accustomed to change mode manually where such mode is required.
So if a web app sets some mode, the user may toggle it back to unintended
mode
and get frustrated.
I tend to agree. In one hand, I believe that users might get irritated
if they can't control the inputmode but in another hand, forcing it
might fulfil use cases where authors use Javascript to force a user to
type in uppercase for example (that happens in a few forms).
Maybe if it was named @inputhint and the user was allowed to change the
input mode, it would be clearer?
On 15/02/13 09:45, Jonas Sicking wrote:
On Wed, Feb 13, 2013 at 11:29 AM, 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' would be the default value.
To conclude, Mozilla is interested in implementing this set of keywords:
verbatim, text, name, prose and digit (or numeric).
I have to say, these feel a lot less understandable than the types
currently implemented in x-inputmode.
There is a confusion here. Firefox OS v1 isn't going to implement the
list mentioned above. It is going to be some kind of subsets of what the
WHATWG specification has. But I do not think we should take into account
what Firefox OS implements in that discussion.
Using semantic names might give us the warm fuzzies, but is there
really any semantic use we will get out of these that we wouldn't by
using lowercase, titlecase or autocapitalized?
I think 'titlecase' can be added later. It's not in opposition with
'name' because 'name' is not really title case (think of Anne van K.)
and it will do autocompletion from the contact book ideally.
'lowercase' could also be added later. I just don't see much use cases
for it.
Regarding 'autocapitalized', I do not think the name is great. Apple has
autocapitalized={on,off,word,sentence,character} if I recall
correctly. It's probably clearer but inputmode=autocapitalized is
probably not that much self explanatory.
I take it verbatim and name would disable any spelling corrections,
Yes.
and name would also titlecase?
'name' would try to get the casing correct and auto-complete from the
contact book.
But the difference between text and
prose seems really hard to understand. I can't even understand the
actual behavioral difference (which is what authors actually care
about) reading the spec, much less guessing by the name.
I think the difference between 'verbatim' and 'text' is good to have.
Should we fix the spec and the naming?
On 21/02/13 01:14, Ryosuke Niwa wrote:
On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri mou...@lamouri.fr
wrote:
To conclude, Mozilla is interested in implementing this set of keywords:
verbatim, text, name, prose and digit (or numeric).
Why is name not an input type?
How does one decide whether a given semantics should be introduced as
a type or a mode?
I tend to prefer input type='text' inputmode='name' over input
type='name' because input type='name', for the moment would be
nothing else but a text field with an address book autocompletion. I
would prefer to have 'tel' that way instead of having it a type FWIW.
--
Mounir
[whatwg] inputmode feedback
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 not advertise it. We unfortunately had to push a x-inputmode attribute in Firefox OS because our UI needed that feature but we expect to replace this with a proper inputmode implementation as soon as possible. Basically, the Mozilla's inputmode attribute is describing behaviour, the allowed value are mostly self-explanatory: auto, uppercase, lowercase, titlecase, autocapitalized, digit and numeric. Autocapitalized is capitalizing words at the beginning of a sentence and the difference between digit and numeric is whether or not there should be a decimal separator and numeric operators available. The attribute as specified in HTML seems to focus on use cases, it provides more semantic and takes into account the handling of suggestions/corrections. However, the current set of values seems overly complex. To begin with, I think we should get rid of the latin prefix. The three modes with that prefix are latin, latin-name and latin-prose but in none of those situations latin is mandatory. The first one could be text: we want to have typing aid enabled and any other feature related to entering some basic non-formatted text. (The difference between verbatim and this type is weak and text might not be the best way to improve this.) The second one is simply name: whatever the script is, we want to enter a name in this field. The last one is latin-prose: like the others, the use case is to write some formatted-text, the script shouldn't have any impact. Regarding the three Japanese specific types, it is not clear if inputmode is the best way to solve the use cases intended to be solved. Actually, 'kana' and 'katakana' are trying to give a hint about the script that has to be used which seems to be orthogonal with the other types. We could allow inputmode to have a set of values but that would make the behaviour way more complex so I wonder if we couldn't try to solve that problem with another attribute like inputscript. Mozilla's implementation has 'numeric' and 'digit' and 'numeric' in the HTML specification seems to match what we called 'digit'. It is not very important but I believe it would be nicer to have 'numeric' renamed 'digit' to make things clearer and to keep the 'numeric' keyword available in case of we need it later. Mozilla's implementation also includes 'uppercase' which is a common use case in the web and could be interesting but it isn't as important as other types so it can be kept aside for later. The priority for us here being to make the Web Platform competitive with native apps on Mobile. Finally, it is not clear why 'tel', 'email' and 'url' are available. Actually, tel would make sense if it wasn't already implemented as a type (because the type is mostly an inputmode) but all of those inputmode already have an associated type. The specification even say rarely necessary and suggest to use the type. Why adding those keywords in the first place then? I feel like we shouldn't add stuff that we do not believe is useful. If it happens to be useful, we should listen to feedback and see if we can fix the types (like make it easier to have them not validate). To conclude, Mozilla is interested in implementing this set of keywords: verbatim, text, name, prose and digit (or numeric). We would be interested to hear from other vendors. Is anybody planning to implement inputmode? if that's the case, which set of keywords is going to be implemented? Feedback is welcome :) [1] This is definitely working with Firefox Android Nightly, I don't know for other channels. Thanks, -- Mounir
Re: [whatwg] Why do we have input type='month' and input type='week'?
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, Avril .. (or even Vendémiaire to Fructidor for FRC fans). FYI, I would find this annoying. CC expiry entry forms are typically select boxes containing 01-12. The text lines up with what's on my credit card, so I don't have to translate 07 to July in my head when entering it off of my card. Any month picker for credit card expiry dates should always have month numbers (of course, names *in addition* to numbers are fine, though probably pointless). That's exactly why I think the use case is weak: it is easy to implement a month picker: select name='month'!--fill with option for each month--/selectselect name='year'!-- fill with option for each year you want to show --/select Given how easy it is, authors might quickly end up expecting specific behaviour that the UAs do not provide. For example, Having 01 - January or January - 01 or even 01 instead of January. They could want the year to show up as 2 digits or 1 digit, as a textfield, a select or an input type='number' with a min and a max. Anyway, I still believe that the pros of input type='month' are quite low but in another hand, it shouldn't cost too much for UA to implement it if or date-time-related types are already implemented and it provides a real benefit on Mobile. Regarding week, I still believe that the use cases are pretty weak but the most important issue is that there is no good UI for this on Mobile AFAIK. Cheers, -- Mounir
[whatwg] More stepUp() and stepDown() comments (was: Re: Forms-related feedback)
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 arrow would call stepUp() and clicking on the down arrow would call stepDown(). [...] Done, though I described it in a different way. (I hope it's equivalent.) I think there are two behaviour that you seem to have described differently: - in step 12, if you take the example page [1], setting the value to 21 and calling stepDown() should change the value to 20 and setting it to 19 and calling stepUp() should change it to 20. This how it is implemented in Opera and Firefox and this how the Chrome's UI behaves. As far as I understand the spec you wrote, those two examples would give respectively 10 and 30. [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918 - I believe that when the value is set to below min and n 0, we should not change the value. Same thing for value below max and n 0. This is the behaviour all UA currently have with stepUp() and stepDown() (though, the previous spec was requiring that) and this is Chrome's UI behaviour. I think that behaviour makes more sense UX-wise because going down or up and having the value going the opposite way is just weird and unexpected. Done. For this: input type='number' min='10' step='10' max='21' ...if the value is 22 and you step up (with the UI), Chrome sets it to 21. (Opera does nothing.) Per spec, stepUp() now would leave this unchanged (like Opera). (I tried to test Firefox but I couldn't get my build to show UI for type=number. Not sure if I'm on the wrong channel or something?) There is no UI. The feature is only enabled on Mobile for the moment. Thus, as my initial email was saying, you can toggle a pref on Desktop to use stepUp() and stepDown() our intent being to have the UI simply relying on those methods (IOW, we want to dogfood the spec). Also, note that per the new spec if stepUp() or stepDown() are called with an argument that isn't 1, it's ignored if the value isn't on a valid step. So in the example above, if value=22 and you call stepDown(5), it only goes down to 20, not 10. Is that ok? Why? That is an arbitrary limitation. We could simply change point 6 to do: If value subtracted from the step base is not an integral multiple of the allowed value step, then set value to the nearest value that, when subtracted from the step base, is an integral multiple of the allowed value step, and that is *more* than value if the method invoked was the stepDown() and *less* than value otherwise. *In all cases*, run the following substeps: [...] I believe, this should just work. There is no technical reasons to have this behave differently for |n|=1 and |n|1. It will just create confusion. Basically, the behaviour I'm describing for stepUp(2) would be equivalent to calling stepUp(1) twice (which seems to be the sanest behaviour). Also, if you call it as stepDown(-2), it goes down to 20, it's not left at 22, because the argument is ignored and the method itself is used to determine the direction if we're not on step. Is that ok? Similarly, if you're at 10, and you call stepUp(1), it goes to 20, but if you call stepUp(2), it stays at 10, because 30 is out of range (max 21). Is that ok? No, it should go to 20 too. I think we should add a step between step 5 and step 6 that says: If value is less than minimum and stepDown() was invoked or if value is greater than the maximum allowed value and stepUp() was invoked, abort these steps. Then, step 7 and 8 should be changed to: 7. If the element has a minimum, and value is less than minimum, set value to the minimum. 8. If the element has a maximum, and value is greater than the maximum allowed value, set value to the maximum allowed value. I also believe we should define the maximum allowed value as: If an element has a maximum, its maximum allowed value is the maximum if the maximum subtracted from the step base is an integral multiple of the allowed value step. Otherwise, it is the nearest value that, when subtracted from the step base, is an integral multiple of the allowed value step and that is less than the maximum. Those changes would make the following snippet work as expected: data:text/html,input type='number' min=-10 step=10 max=100 value=-100 If you call stepDown() on this, you would expect that nothing happens because there are clearly nothing that can be done. However, stepUp() should clamp to the first allowed value. In addition, it will make sure we clamp to the maximum allowed value if we do stepUp(1000) instead of doing nothing. Thanks, -- Mounir
[whatwg] Why do we have input type='month' and input type='week'?
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 } information.
Given that the element is pretty trivial to implement by authors (this
is basically two select or a select and a input type='number'), the
only advantage I see to have this element in the specifications is to
have a native UI on mobile.
I am wondering if use cases were taken into account when this was added
to the specs and if vendors that implement this element can report good
adoption if any.
I can see niche use cases for 'week' but I do not think it is easy to
come up with a good UI for this, especially on mobile (there is no
native UI on mobile AFAIK). On desktop, Chrome's UI is terrible but the
Opera one is decent.
This type would solve the use cases of people trying to find a week to
meet. Typically, W3C F2F's. However, this is a niche use cases. Most of
the times, when people speak in 'week', they don't really mean from
Monday to Sunday. For example, if someone takes a vacation the first
week of February, he/she will not book its hotel for the week 5 or 6
but from a specific day to another specific day.
Generally speaking, I believe both those types lack use cases and I
wonder if the HTML specifications are not defining a solution for
something that is still looking for its problem.
In other words, are authors writing their own 'month' and 'week' widget
at the moment? If they are, would there life be easier with those input
types?
Thanks,
--
Mounir
Re: [whatwg] Make the files attribute of the input element writable
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. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140 The thread seems to have died down due to insufficient applications for the proposal. Actually the reason this thread hasn't gone anywhere is that there seems to only be implementer interest from Chrome. See: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest Thank you very much for explaining! I can file a bug against Firefox, and argue for it. I think I would have an easier time making an argument if I knew how the API should look like. Can you please give me a hint as to which variant you'd be more likely to agree with? Mutable FileLists vs a way to put together a new FileList + writable files attribute on input type=file? File constructor taking a Blob + name vs having Blobs in a FileList? There is already a bug for it: https://bugzilla.mozilla.org/show_bug.cgi?id=757664 -- Mounir
Re: [whatwg] 'datetime-local' and 'datetime' comments
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 nice. The bad is that Javascript Date objects are initialized with local time and prints local time (toString https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/toString). Web developers could expect the same behavior for date inputs and date objects. Aren't you looking for this: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/toUTCString -- Mounir
Re: [whatwg] 'datetime-local' and 'datetime' comments
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 zone, so if I said November 19th, 5pm, it would send that as November 20th, 1am UTC. Then, maybe a better naming could be datetime-utc? The idea is to be able to get a precise time from the user without having to worry about what time zone the user's in, and without the user having to worry about what time zone other users are in. This would be very useful for scheduling global events, e.g. when a hangout is to happen, or when a game is to start, etc. I really don't think this is a rare thing. In fact I think mostly it's the one to encourage people to use, which is why it's called datetime currently, with the one without timezones, which I think will overall be rarer, having the longer name. I feel like the main issue is that we disagree in which type is the most used. I guess it highly depends on who you ask. I tend to book way more often trains or flights than I arrange meetings. I agree that existing UIs are unfortunate, but they should be fixed. It would be unfortunate to push people towards the timezone-less control just because we screwed up the UI and then renamed the type in shame. What do you think would be a good UI? Does something that would allow selecting a date/time in the current user's TZ and then have the information sent to the server in UTC would be a good UI? But then, there would be no real difference between the datetime and the datetime-foo widget, right? If the main difference between datetime and datetime-foo is the format of the value we send to the server, can't we simply always send the timezone information? So, servers who care about the user's timezone could do the conversion, and others could simply ignore the information. Cheers, -- Mounir
Re: [whatwg] Forms-related feedback
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 of reasons why they can throw. 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 arrow would call stepUp() and clicking on the down arrow would call stepDown(). Such a use case needs methods that do better than just adding n * allowedValueStep. In addition, we think that throwing is very often a bad idea and that should happen when the developer clearly did something wrong. So, we would like to change the stepUp()/stepDown() algorithm to match the following behaviour: - we only throw if the input type doesn't allow those methods or if there is no allowed value step; - if the value isn't a number (aka empty string), we should just exit the steps; - if the value is below the minimal allowed value and n is negative, we should exit the steps; - if the value is above the maximal allowed value and n is positive, we should exit the steps; - if the element is suffering from a step mismatch, and n is negative, the value should be changed to the next valid value. Otherwise, it should be changed to the previous allowed value; - newValue = value + n * allodValueStep; - if the newValue is below the minimal allowed value, the newValue should be equal the minimal allowed value; - if the newValue is higher than the minimal allowed value, the newValue should be equal the minimal allowed value. Such a behaviour creates a real added value in stepUp() and stepDown() that make those methods useful compared to simply do value += n * allowedValueStep; and prevent throwing when there is no need to. Done, though I described it in a different way. (I hope it's equivalent.) I think there are two behaviour that you seem to have described differently: - in step 12, if you take the example page [1], setting the value to 21 and calling stepDown() should change the value to 20 and setting it to 19 and calling stepUp() should change it to 20. This how it is implemented in Opera and Firefox and this how the Chrome's UI behaves. As far as I understand the spec you wrote, those two examples would give respectively 10 and 30. - I believe that when the value is set to below min and n 0, we should not change the value. Same thing for value below max and n 0. This is the behaviour all UA currently have with stepUp() and stepDown() (though, the previous spec was requiring that) and this is Chrome's UI behaviour. I think that behaviour makes more sense UX-wise because going down or up and having the value going the opposite way is just weird and unexpected. [1] The only difference between Chrome's spin buttons behaviour and our proposal is that when value is the empty string, it is setting value to 0 and continue to the next steps (unless the 0 is below the minimal allowed value and n 0, in that case value=min). It might be interesting to specify something better than do nothing if value=. I'm open to doing that too; what would you preference be? Maybe if value isn't valid, we could have it changed to the step base or |min + (max - min)/2| and exit the steps if stepDown() or stepUp() is called. (I think even if stepDown(hugeNumber) is called, we should still just set the value and do nothing else.) I would tend to prefer step base mostly because it would know set it to the default value if there is a default value. However, I think step base is quite a bad solution for some types. Maybe we could use the default value if there is such a concept for the type or the step base otherwise? [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918 Thank you for the prompt change, Ian. -- Mounir
Re: [whatwg] Make stepUp() and stepDown() more developer-friendly
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 that in Mounir's suggestion, and the spec now rounds to the nearest allowed value in that case, rather than doing nothing. Mounir: is that ok? As said in my reply to Forms-related feedback thread, I think it is weird to have stepDown() going up or stepUp() going down. Users should understand that they can't go down if the down arrow isn't doing nothing. FWIW, this is the behaviour Opera and Chrome UI's have. This is also the behaviour stepUp() and stepDown() have in Gecko and Presto. I can list out the steps we take for all conditions, but I'd like to hear everyone's thoughts on the various cases where you're suggesting that the methods do nothing. Mostly I agree with Mounir here, but I'm curious about what you think should happen for the case where there's no value, and the case where the control isn't a numeric/date/time type. I could see an argument for stepping from the default in the former case (Mounir, what do you think about doing that?) but for the latter case I don't really see any point doing anything but throw an exception, as Mounir suggested. I also replied about the no value case in Forms-related feedback thread. I believe it might be better to set the value to something. I'm not sure which value should be used for that. Cheers, -- Mounir
Re: [whatwg] Improving autocomplete
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) If this API provides the ability to get user information without
even having a visible form, then it's not clear that it is even really
autofill. It's just requestUserInformation() or something.
Right. It's like openly shared super-cookies...
(3) This API has important privacy and even security considerations.
Yes.
You have to tell the user exactly what you are going to fill in to the
site before they approve.
And because as soon as you put it into the input field the site can use
it, as a basic security measure it seems like you should never autofill
without explicit user confirmation.
Unfortunately, most won't read it.
Indeed.
If sites are asking for so much info that they have to split pages for
usability, then it seems likely the UI that tells the user what the
site is asking for will be impractical for most users to meaningfully
review.
Yes. This is a problem I face from time to time, and I think its
seriousness is underestimated. This process can be used to collect all
sorts of information before the user realises they didn't want to hand
it over.
This becomes especially dangerous if the mechanism can fill in credit
card info.
That assumes your most valuable info is about your credit card, which is
only the case for a certain proportion of people.
I would be very nervous if the browser could at any moment pop up a
dialog that would submit all my credit card info to a dubious site if
I slip and click the wrong button. Can you expand more on what thought
you have given to the security considerations?
I share the same concerns as Charles and Maciej (see above).
Especially, even if there is an unspoofable UI that is clearly
recognised as part of the browser chrome, any malicious author would be
a click close from getting your credit card number information. If I
understand it correctly, it would be as easy as writing a form with
some input autocomplete=cc-{number,name,...} and then call
requestAutocomplete(). If the user press OK, the page will got those
information, right?
This might be the same security mechanism as geolocation but the outcome
would be so tempting that people might try way harder to get your credit
card information than your location.
In addition, I wonder how valid the use cases of this feature are.
Nowadays, I feel like most websites will, by default or trough opt-in,
save all information so when you come back, you do not have to enter
your address, credit card information and anything else. Seems like
those websites have solved the issue themselves.
I feel like the real use case is when a user wants to make custom with a
web site for the first time. It might be indeed harder to get a good
transformation ration if the user has to write all those information.
However, I doubt we should add such a scary feature for that use case.
Cheers,
--
Mounir
[whatwg] Make stepUp() and stepDown() more developer-friendly
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 stepDown() is to create a UI with spin buttons: clicking on the up arrow would call stepUp() and clicking on the down arrow would call stepDown(). Such a use case needs methods that do better than just adding n * allowedValueStep. In addition, we think that throwing is very often a bad idea and that should happen when the developer clearly did something wrong. So, we would like to change the stepUp()/stepDown() algorithm to match the following behaviour: - we only throw if the input type doesn't allow those methods or if there is no allowed value step; - if the value isn't a number (aka empty string), we should just exit the steps; - if the value is below the minimal allowed value and n is negative, we should exit the steps; - if the value is above the maximal allowed value and n is positive, we should exit the steps; - if the element is suffering from a step mismatch, and n is negative, the value should be changed to the next valid value. Otherwise, it should be changed to the previous allowed value; - newValue = value + n * allodValueStep; - if the newValue is below the minimal allowed value, the newValue should be equal the minimal allowed value; - if the newValue is higher than the minimal allowed value, the newValue should be equal the minimal allowed value. Such a behaviour creates a real added value in stepUp() and stepDown() that make those methods useful compared to simply do value += n * allowedValueStep; and prevent throwing when there is no need to. It is interesting to see that input type=number spin buttons in Chrome have that behaviour [1] but stepUp() and stepDown() do not. Opera has the same kind of UI behaviour than Chrome and stepUp()/stepDown() tries to be more clever than what the specifications say (it is clamping to the nearest allowed value). However, it is still throwing too much. You can try the implementation of stepUp() and stepDown() in Firefox desktop by enablinig the pref dom.experimental_forms or by using Firefox Android (no need to toggle any pref). You can use this page to test: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918 [1] The only difference between Chrome's spin buttons behaviour and our proposal is that when value is the empty string, it is setting value to 0 and continue to the next steps (unless the 0 is below the minimal allowed value and n 0, in that case value=min). It might be interesting to specify something better than do nothing if value=. Cheers, -- Mounir
Re: [whatwg] 'datetime-local' and 'datetime' comments
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. Having *a* use case doesn't make a feature a must have. Developers can write this feature themselves and as said, having a browser implementation isn't going to help them here. It might be the opposite actually. I think that whatever you decide for datetimes, it should always return a UTC value with only one format (-mm-dd hh:mm:ss or -mm-dd-Thh:mm:ssZ) to allow us to threat it the same way whether it is relative to the user timezone or not. 'datetime' should indeed return something like -mm-dd hh:mm:ss so, there is no timezone involved. Cheers, -- Mounir
Re: [whatwg] 'datetime-local' and 'datetime' comments
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 not good. People must think type=datetime is a combination of type=date and type=time. It's not too late to rename datetime-local to datetime because the number of type=datetime or type=datetime-local in the Web is terribly smaller than the number of type=date. Tamura, do you think Webkit/Chrome can do this change? Gecko/Mozilla would be willing to implement 'datetime' that way and not implement 'datetime-local' but having other vendors committed to this change would be helpful and prevent us from going alone in this path. Cheers, -- Mounir
[whatwg] 'datetime-local' and 'datetime' comments
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 to something. So, it seems somewhat natural to assume that 'datetime' would be simply those types added to each other. Instead of that, 'datetime' has a notion of timezone and 'datetime-local' is the timezone agnostic type. In addition of being more intuitive, it seems that a huge majority of date/time usage are timezone agnostics because, usually, the timezone is implicit. For example, booking flight/train tickets. There is however some use cases I can think of, like scheduling a meeting, where, sometimes, you might want to mess with timezones. But those are quite rare. Furthermore, there are currently two implementations for 'datetime' and 'datetime-local' I can think of: - Opera: 'datetime' is like 'datetime-local' except that there is a greyed 'UTC' text next to the datetime picker; - Chrome Android: 'datetime' is exactly like 'datetime-local'. I haven't checked what is actually sent when the form is submitted by those implementations. Last but not least, I have never seen any [good and simple] UI allowing me to pick a date and time in a specific time zone. As far as I know, there are no native UI for those things even on mobile where there are UI for date and time pickers. As a conclusion, given the lack of good UI and good implementations, I think we should change the behaviour of 'datetime' to match the behaviour of 'datetime-local' so developers don't use the former and falsely expect the behaviour of the later. Also, I would suggest that we remove 'datetime-local' from the specifications. If later if find out that we really need a date-time picker that is not timezone agnostic, we could add something. For the moment, given the state of the implementations and the very tiny use cases that could solve, I think having this type would hurt more than help. Thanks, -- Mounir
Re: [whatwg] input type=barcode?
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 mean something like inputmode=barcode? Can you elaborate on how that would work? It's an intriguing idea, but I'm not sure I follow quite how to specify it. Yes, something like that. In terms of the table in the spec: Keyword: barcode State: Barcode Fallback State: Default Description: Text input in the user's locale, with keys to activate the system's built-in barcode reader to retrieve a value instead. When you say barcode I'm presuming you're referring to barcode in all it's forms e.g. barcode, QR code, datamatrix etc? Some of these can contain up to 4,000 characters but many imagers have problems reading them. If that's the case, a full widget might make sense and in that case, we would need an new input type instead of a new inputmode value. -- Mounir
Re: [whatwg] input type=barcode?
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. But then I wonder why it should be an inputmode because there is
no reason why you couldn't use a barcode in any field. inputmode being
an hint for the UA about the input that should be used, which means the
UA would be asked to use a barcode app for certain fields and not
others. I don't really see a use case for that.
However, I think some users might want to use barcodes in some
situations (without any opt-in from the webpage). Like to put an URL or
an email address in a field. But in that case, it seems more like simple
input type={url,email}'s. I wonder if we couldn't leave this as UA
implementation details for URL and email fields?
--
Mounir
Re: [whatwg] Bandwidth media queries
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 both Mozilla [2] and Webkit [3]. As far as I can tell, the Mozilla implementation always returns Infinity for .bandwidth. This is not true. There is an implementation for Firefox Android which is based on the connection type. -- Mounir
Re: [whatwg] Bandwidth media queries
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 0.2, etc). This suggests that the API is extremely silly; although one could presumably claim that an estimate allows one to return anything, I don't see how returning 20 if the server is feeding you 1 byte/second can be helpful to anyone. If no one plans to implement this as a loose proxy for type of connection the spec shouldn't pretend to do more than that. Can you point me to the discussion of usecases that led to this design? This has been discussed in the DAP WG [1]. Actually, I think we should move that discussion there. [1] http://www.w3.org/2009/dap/ Cheers, -- Mounir
Re: [whatwg] Bandwidth media queries
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 provides navigator.connection.bandwidth It's been recently implemented (to some degree) in both Mozilla [2] and Webkit [3]. As far as I can tell, the Mozilla implementation always returns Infinity for .bandwidth. This is not true. There is an implementation for Firefox Android which is based on the connection type. Ah, indeed. I had missed that codepath. 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 0.2, etc). The idea is that the specification allows the implementation to be trivial and improve without changing the specification. And that implementation is good enough for web pages to know if the user is in a slow or fast connection without giving the connection type and leaking information. That would require not returning exact constant by blurring them a bit. This is not done yet but could easily happen. -- Mounir
[whatwg] Should a textarea outside of a document be immutable?
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 between those two elements. I believe both elements should be immutable when outside of a document. Cheers, -- Mounir
Re: [whatwg] media attribute of source element, default behavior on getting the property.
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 src=media.webm /video What should document.getElementById(asource).media [1] be ? The spec [2] currently says : The default, if the media attribute is omitted, is all, meaning that by default the media resource is suitable for all media. At that point, we understand that if no media attribute is specified, the expression [1] should return all. The quoted text says that the default is 'all', not that the default value of the IDL attribute is 'all'. This is speaking of how the UA should handle internally the attribute being omitted. Then spec then says : The IDL attributes src, type, and media must reflect the respective ? content attributes of the same name. At this point, we understand that [1] should return an empty string, but the source is matched as if media was all. AFAICT, this is what should be taken into account. -- Mounir
Re: [whatwg] register*Handler and Web Intents
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 much better alternative than changing the HTML parser. Trying to fit the registration components listed above into meta really doesn't work all that well, IMHO. meta name=viewport does that and is widely used AFAICT. On Tue, 6 Dec 2011, James Graham wrote: On Tue, 6 Dec 2011, Anne van Kesteren wrote: Especially changing the way head is parsed is hairy. Every new element we introduce there will cause a body to be implied before it in down-level clients. That's very problematic. Yes, I consider adding new elements to head to be very very bad for this reason. Breaking DOM consistency between supporting and non-supporting browsers can cause adding an intent to cause unrelated breakage (e.g. by changing document.body.firstChild). That is true, but adding this to the body seems weird too. How bad would that be? Do we expect a lot of breakage? Can't we simply assume websites would use the programmatic registration if the declarative one doesn't work/break some old browsers? On Tue, 6 Dec 2011, James Hawkins wrote: Originally we envisioned using a self-closing tag placed in head for the intent tag; however, we're now leaning towards not using self-closing and having the tag be placed in the body with fallback content, e.g., to install an extension to provide similar functionality. intent action=webintents.org/share Click here to install our extension that implements sharing! /intent What are your thoughts on this route? How common will fallback be on the short term and on the long term? I think the fallback is quite useless here. I don't think wildcard matching really makes sense. In particular, I'm not aware of any service that can honestly say it supports image/*, or indeed any other topleveltype/*. Doesn't @accept on input allows image/*, video/*, audio/*? We should at least accept those values. But maybe it would be safe to allow foo/* if a service and client would be connected only if they both marked they foo/* as a type? On Fri, 16 Dec 2011, Paul Kinlan wrote: We didn't want to add additional attributes to the meta tag or link tag just for intents, this seems to open up the flood gates for future platform features to also extend the meta syntax, the meta element then just becomes a dumping ground. That's not a big concern, so long as the semantics make sense. With intent registration, I'm not sure they do. e.g. with link href= you'd want to be able to register a URL with a %s segment for content/protocol handlers, but that's no longer a valid URL, so it's weird to use href= which currently requires a valid URL. Similarly, using type= to mean the filter rather than the type of the content at the href= URL would mean the type= attribute has a different meaning based on context. Similarly, we have an action= attribute on link that defines the disposition, but it has different values than what we're talking about here, so it would be weird to reuse it, and would be weird not to. meta is also a weird case because we'd basically be reusing the element but none of the attributes, and it already has three different roles. AFAIUI, link is far from ideal for what we want. IMO, meta would match quite well our needs. We could put all the information in @content like meta name='viewport' is doing. However, IIUIC, we can have only one meta with a given @name which means a page will not be able to register declaratively more than one intent. Otherwise, we could come with a very complex syntax to allow more than one declaration in @content. On Wed, 15 Feb 2012, James Hawkins wrote: We, the designers of the Web Intents draft API, have always seen Web Intents as a superset of the functionality provided by registerProtocolHandler (RPH) and registerContentHandler (RCH). To follow this to the logical conclusion, we should be able to provide functionally equivalent counterparts to RPH/RCH in Web Intents. This proposal provides a means of deprecating RPH/RCH, replacing this functionality with equivalent functionality from Web Intents. I don't think it makes sense to deprecate them. We should design intents to incorporate them, not deprecate them. Given that Web Intents would deprecate/supersede RPH and RCH, I wonder why we should bother incorporating them. - Using URLs as intents, especially for the default intents, is overly verbose. I highly recommend just having a wiki page be a registry of widely used intents, and saying that if people want specialised ones for their own communities, they can then use URLs, but otherwise it's fine to just use simple identifiers like edit or share, so long as they are
Re: [whatwg] iframe sandbox attribute
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 Webkit and IE10's implementations, as far as my testing can tell (and
in my work-in-progress implementation for Firefox also).
element.hasAttribute('sandbox') should return false for the former case
and true for the later.
There's also no way to clear sandboxing from an iframe without using
something along
the lines of .removeAttribute.
If you want to remove the sandbox attribute, isn't removeAttribute the
best way to do that?
Due to this and some sentiment expressed by others at Mozilla against
PutForwards
(the HTML5 spec specifies [PutForwards=value] on iframe's sandbox
attribute, which is
defined as a DOMSettableTokenList), I would like to propose a possible
modification
to the spec : changing iframe sandbox to be |string? sandbox| instead of a
DOMSettableTokenList.
I do not like [PutForwards=value] but I still believe
DOMSettableTokenList is useful.
Cheers,
--
Mounir
Re: [whatwg] Why isn't the pattern attribute applied to input type=number?
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
applyhttp://dev.w3.org/html5/spec/common-input-element-attributes.html#do-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 n or n-
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.
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.)
Ms2ger is correct. What you want is something like proposed in this bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12885
--
Mounir
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
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 of these use cases are about bandwidth. a) Images are too big. b) Too many javascript files. c) Too much html content. The proposed fix: a) Send a display size header, have the server do magick. That doesn't seem to be the right approach. Let me know if I've got that right / wrong. I'm fine with sending a bandwidth-request header. Something to say: hey you, I'm on a metered connection, don't waste my time. Or just, hey, this connection is slow, give me a hand here. FWIW, Network Information API (in DAP WG) might include those information in a JS API. -- Mounir
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
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 developed this initial draft proposal working together with developers or several autofill products, and are now looking forward to feedback and suggestions from the broader community. [1] http://wiki.whatwg.org/wiki/Autocompletetype Looking at the list of types you are proposing, I was wondering if we couldn't solve this another way. We could create two new input types: 'contact' (or person, or anything better) and 'address'. 'address' could even be part of 'contact' given that is a contact information. There is currently some work being done to access contact information [1] [2]. Currently, the way we handle names and addresses is probably suboptimal and websites have to re-invent a lot of things. A simple field that would ask the user to give those information might be way better for both authors and users. For example, on a mobile phone, I would be able to pick up one of my contact address to send him a gift instead of typing it. I believe that doing that would have the side effect to solve the autocompletion issue but would do much more. Other input types like 'email' and 'tel' should be able to solve the phone, fax and email autocompletetypes I believe. Authors should stop using multiple fields for telephone and use input type='tel' instead. Then, UA could always present the same autocomplete list when type=email or type=tel is used if they believe it's better. Also, I do not understand why we have credit cards types. Is anyone willing to have his credit cards information saved locally? Is any website not using autocomplete=off as soon as credit cards are involved? For the other types, we can consider them minor enough. This said, 'birthday' is part of contact information. [1] http://w3c-test.org/dap/contacts/ [2] https://wiki.mozilla.org/WebAPI/ContactsAPI Thanks, -- Mounir
Re: [whatwg] Form controls inside a label but not labelled by it
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 because it tries to combine expected behavior for clicking inside a label and for clicking on an interactive element. It sounds much more natural. Opera/IE behavior is similar to ignoring the fact that the interactive element is inside a label. Basically, Opera and IE are assuming that the author didn't want to write what he/she wrote. I do not think that is a sane behavior when they are good and real use cases for it. Well, the _spec_ assumes that the author didn't want to write what they wrote. That's why it's non-conforming! I don't think it makes sense to try to activate two things at once. The author clearly didn't express what they meant to express, but it seems highly unlikely that the author meant to express that the control in question should not be focusable at all. I would guess that this error occurs typically due to copy pasta: label for=a input id=a /label label for=a input id=b /label label for=a input id=c /label Why would you want inputs b and c to be unfocusable via the mouse? I agree that Opera/IE behavior is better to solve this case but it doesn't help for this one: labelinput type='radio'input/label And it seems that web authors tend to write that and expect the radio to be checked when the text field is focused based on the bug reports we had. Between two use cases I think the second is more important because the authors are more likely to have write something they meant to write. -- Mounir
Re: [whatwg] Idea: pseudo-classes :valid and :invalid for whole form?
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 specific
field-related. Could you consider adding form element class for such a
purpose?
Example:
p id=errYou've to fill all required fields/p
form:invalid #err {
display: block;
}
On Wed, 15 Jun 2011, Boris Zbarsky wrote:
Yep. I think we should do it.
I've added this to the spec.
Wouldn't be interesting to have the same thing for fieldset?
--
Mounir
Re: [whatwg] How should overflow be handled when parsing integers?
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 how to handle integer overflow when interpreting the result of a sequence of base-ten integers. Currently in WebKit we consider such overflow a parsing error. Is there any reason not to consider overflow a parsing error? Regardless, I suggest codifying the handling of overflow in the aforementioned sections. Gecko also considers that an overflow is a parsing error. Presto and IE6 doesn't seem to. The specs should probably mention this by whether consider it as a parsing error or request the UA to default to the highest value (which Presto and IE6 seem to do but not using the same value). This issue came up recently in WebKit with respect to the parsing of the maxlength attribute (https://bugs.webkit.org/show_bug.cgi?id=68981). Actually, this problem wouldn't have been that annoying if Webkit was following the specs regarding maxlength attribute: if the content attribute value isn't a valid non-negative integer, the element has no maximum allowed value length. -- Mounir
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] Idea: pseudo-classes :valid and :invalid for whole form?
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 correctly. Just some single warning, not specific field-related. Could you consider adding form element class for such a purpose? This would be more a CSS Selectors concern No, it wouldn't. The point here is to style based on a _form_ that is invalid. Whether a form is valid or not is up to the language defining forms, that being HTML. Isn't that somewhat related to CSS UI too? By the way, for what it worth, I've mention that in this mailing list and got no feedback. I'm happy to see someone else asking for it and I might implement that in Gecko. -- Mounir
Re: [whatwg] Form controls inside a label but not labelled by it
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 the labelled element ; - Webkit: focus the form control and activate the labelled element ; - Presto and IE9 RC: focus the form control (doesn't activate the labelled element). I think Webkit's behaviour makes the more sense here and it would be nice to have it specified. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=213519 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=595270 Oops, not sure why the text was lost in the WF2 merge. 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 because it tries to combine expected behavior for clicking inside a label and for clicking on an interactive element. It sounds much more natural. Opera/IE behavior is similar to ignoring the fact that the interactive element is inside a label. Basically, Opera and IE are assuming that the author didn't want to write what he/she wrote. I do not think that is a sane behavior when they are good and real use cases for it. Authors can emulate the WebKit behaviour if they really want it by just calling .click() on the element they want to have activated when the target is focused. Sure. Like the the Firefox one ;) -- Mounir
Re: [whatwg] input element list attribute and filtering suggestions
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 you want to use the datalist to suggest a few things you might not want to filter and when the list is long, you very likely want to filter. You might not want to filter when the list is a real set of suggestions and you can type anything else. For example, a field in a support form can ask you What is your problem? and you could type a brief summary but some pre-written issues will be available. It's equivalent to a select element followed by an input field that you can use if you select other in the list. As I see it, when you filter, you have a very long list and you very likely want the user to select something in the list like a list of bugzilla emails, a list o metro stations, etc. Writing anything not in the list might not work. -- Mounir
Re: [whatwg] Submit controls should be barred from constraint validation in favor of a new pseudo-class
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 and submittable so it should be able to be invalid is not a sane rule? At least, we should not include non-editable but visible submittable controls like submit controls. This only affects people who go out of their way to make submit controls invalid, right? I guess I don't really care one way or the other, but it seems easier all around to just make things as consistent as possible and just allow it. At the end of the day, on this, I'll spec whatever gets implemented. Do we have multiple implementations one way or the other yet? Opera 11.20 allows submit controls to be invalid and Gecko (since 2.0) does not. I haven't check Webkit but IIRC, it has the same behavior as Opera. -- Mounir
[whatwg] Questions and remarks about the labels attribute
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 but all elements in the list are HTMLLabelElement so an HTMLCollection sounds more appropriate, doesn't it? Though, I might miss a difference between these two collections. FWIW, Opera (only implementation AFAIK) returns an HTMLCollection. * The most important issue is related to the collection returned by the labels attribute. Given that the collection isn't stated to be static, it is live (according to DOM Core). Though, the root element of the collection might change: when an element is inside a document, it's always the document but when it is outside, it is the root of the fragment. One solution would be to explicitly say that labels can't labelize an element outside of a document even if it is the first labelled control descendant in the tree order. But how do we manage situations where .labels is returned when an element isn't in a document then the element is moved to a document? Should the root element of the collection change? Another solution would be to make the collection static. Thus, we return whatever seems appropriate depending on the element being in a document or not. This solution seems also saner because it prevents watching the entire document when .labels is used which is a bit of overkill. Actually, I think that only form.elements returns a collection that implies watching the entire document (because of the form attribute) all other collections uses a sub-tree. Thanks, -- Mounir
Re: [whatwg] input element's value should not be sanitized during parsing
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. I can't argue that it's desireable, but it's how the Web works, as I understand it. Gecko doesn't exhibit this behavior and I don't know of any sites that doesn't work in Gecko because of this. FWIW, it does. The first inp.value is 'foobar' while the second is 'foo bar'. See: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/900 Though, I do not think this is related to the initial issue which is about setting attributes while creating the element from the parser. -- Mounir
Re: [whatwg] Constraint validation feedback (various threads)
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 maxlength behavior, sorry for the ignorance. I just worried since I saw some applications in the past that don't allow users to enter values longer than the maxlength, and some of them were unusable with CJK input methods. If you're going to change the definition to not to allow entering values longer than the maxlength, I wish it be clearly defined with international environment in mind where text may be shorten as user types, and therefore they must allow longer values than maxlength during the undetermined state. Transition from undetermined to determined could be kicked by several criteria and it's hard to control, so my gut feeling is that not allowing entering longer values than maxlength tends to result poor in CJK, but I'm fine as long as it was designed such conditions in mind. FWIW, I did a proposal to change how maxlength currently behaves that would fix this issue too. See: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/029145.html And for some clarifications: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030444.html -- Mounir
[whatwg] selection-related IDL attributes and methods and input type
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 that should come with a widget like date, datetime, datetime-local, time, week, month, number, range or color. The resulting widget might have a text field. That's even very likely for all time-related and number types. Should those IDL attribute and methods apply in that case and be used on the text field? or should we just ignore them? Or maybe, we could have them apply depending on the UA's widget and not raise an exception when they do not apply [2] and do nothing instead? [1] See http://www.w3.org/Bugs/Public/show_bug.cgi?id=12262 [2] Actually, that's another issue but I wonder why we raise an exception... Thanks, -- Mounir
Re: [whatwg] Option label, textContent and value
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 contradictory to the spec, which gives the label attribute precedence. It's a very old bug in Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=40545 Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: select optionThis is value and label /select But not in a datalist, as the label is taken from the textContent rather than from the value of the option element: datalist option value=No label here option label=No value here /datalist I don't understand your point. If you want to have the same behavior, you should write the same HTML code and I believe this is what you want: select optionThis is a value and a label/option /select datalist optionThis is a value and a label/option /datalist Here, the option inside the datalist and the one inside the select element will have the same label and the same value. -- Mounir
Re: [whatwg] Allowing size and maxlength attributes for all new input types would provide better fallbacks
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, browsers are
expected to use advanced user interface, either with no visible text field
or with a text field of a size determined by the browser.
However, the method of extending forms with new input types is based on the
clever idea that using a new attribute in input elements, non-supporting
browsers will imply type=text and use a normal text input field as
fallback. This idea gets somewhat broken if size and maxlength attributes
cannot be used. Setting the visible width and imposing a maximum length of
input in characters are often useful hints. E.g., for input type=time,
it would be useful to have size=5 maxlength=5 (perhaps combined with a
CSS setting that sets the font to monospace for consistency) to convey or
support a message about expected input format as well as to prevent some
input errors.
Note that input type='time' maxlength='5' size='5' should work as
expected given than maxlength and size would just be ignored by a UA
which knows about the 'time' type and would be used by a UA which doesn't.
Though, if you want to have a valid HTML code, the best solution is
probably not to change the HTML specs to accept those attributes given
that they will be completely useless if the UA support the given types.
However, I think the web page should set the attributes in a compat
check in javascript. Probably the same way you would have to set a few
event handlers to create the widget you want. That way, you would only
use these attributes when the UA would actually use them.
For example, instead of:
input type='number' size='4' maxlength='4'
You could do:
body onload=
var i = document.getElementsByTagName('input')[0];
if (i.type != 'number') {
i.type = 'text';
i.maxLength='4'; i.size='4'; i.oninput=/*a event handler*/;
[...];
}
input type='number'
/body
--
Mounir
[whatwg] Form controls inside a label but not labelled by it
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 isn't focused. Recently, this bug appeared on GMail [2]: if you try to set a signature with Firefox and the HTML5 parser enabled, you will not be able to focus the textarea but you will focus the radio button instead. You can see a minimized test case here: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/839 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 the labelled element ; - Webkit: focus the form control and activate the labelled element ; - Presto and IE9 RC: focus the form control (doesn't activate the labelled element). I think Webkit's behaviour makes the more sense here and it would be nice to have it specified. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=213519 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=595270 Thanks, -- Mounir
Re: [whatwg] Constraint validation feedback (various threads)
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 that will let us know if the element's value has been changed by the user (probably if the _last_ change has been done by the user). The meaning of this flag would be to fix the retro-compatibility issues. Then, an element would suffer from being too long if this flag is true and it's value length is greater than the maxlength attribute value. In addition, users will be able to enter text longer than the maxlength attribute for textarea (and maybe input) elements. That way, we would be able to fix retro-compatibility issues and provide a better experience to the users. Why would you want to make it possible to enter long values? If there's a use case for it, I'm happy to address it, but if there isn't it's not clear that we should change this aspect of browser behaviour, since it's been pretty widely implemented for a long time. This proposition is mostly trying to fix a user experience issue: when you have to type a text limited to a given number of characters and at some point you just can't type anymore because you reached this limit, it's really frustrating because you have to constantly remove some text, type until you reach the limit, remove some text again... It seems much more interesting to use the constraint validation mechanism we already have to tell the user that the text is actually limited to X characters. With that system, the user will be able to type it's entire text and then easily reduce it to the desired size. Think about how annoying twitter.com would be if the users were not able to type when the text field has reached 140 characters. Though, this might not be really helpful for text field which aren't expecting a long text. If this is an issue, maybe we could go for Aryeh's suggestion for input [1] and do that one for textarea only? But it might be confusing. [1] UA shouldn't allow the the text length to be greater than the maxlength value (and assume that the element can't suffer from being too long). -- Mounir
Re: [whatwg] type=email and IDN
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 prohibits this. We should probably change that. Either by saying it should first be converted to Punycode and then validated, or by enhancing the pattern. (The email RFC might still be outdated on this point, I have not checked, but we have decided to not follow it anyway as it fails to match email addresses people actually use.) As far as I understand it, the specification somewhat handles this by telling UAs they may puny-encode/decode the value to show the IDN value and still be able to validate it with the current rules [1]. Note that there is a bug open to make this may a should or a must [2]. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#e-mail-state [2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11579 -- Mounir
[whatwg] double IDL attributes when reflecting content attributes?
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 double IDL attributes will be limited to single precision floating point values so why using the double type instead of the float type? [1] http://html5.org/tools/web-apps-tracker?from=5372to=5373 [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values Thanks, -- Mounir
Re: [whatwg] Make f...@bar.com, a valid email address list
On 01/06/2011 12:40 AM, Ian Hickson wrote: This thread led me to realise there were a number of problems in the spec with the multiple= attribute as applied to type=email, including a poor definition of how list= applies, a poor definition of how selectedOption applies, an incoherent expectation that the selection API should apply to type=email at all (which doesn't work since the UI is supposed to be IDN-based but the output and the API isn't), and various complication regarding how values are to be checked, depite the recent fixes in that area. I revamped how 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 but not . Unfortunately, as soon as you want to put a UI on top of that, values will always be appended by , . I've changed the spec so that it decouples the underlying DOM and submission value from the UI, so that's no longer an issue. On Fri, 22 Oct 2010, Anne van Kesteren wrote: I think it would be better to simply omit that trailing comma. Which should be allowed. If the specification currently does not allow that (somehow) it would be a bug and is just something that needs clarification. Indeed. Also fixed. I don't see where/how this has been fixed. To me, it's clear that f...@bar.com, b...@bar.com will now be represented as f...@bar.com,b...@bar.com in the DOM but not f...@bar.com, b...@bar.com, (which will be f...@bar.com,b...@bar.com,). In addition, this value seems to still be invalid. Can you point out the section/line that handle this case? Thanks, -- Mounir
Re: [whatwg] link.sizes and [PutForwards=value]
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 getters and setters work in a very different way. Inconsistency in APIs isn't a good thing. I don't understand how they work in a different way? The idea is to make the attribute appear to work like a DOMString for most purposes, but to allow methods to be invoked on it. (All the attributes that have [PutForwards] set also have a stringifier on their object's interface.) Is there a use case for [PutForwards] (except saving a few characters for the authors) that could justify the inconsistency? -- Mounir
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
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 can be invalid without any possible action from the user. If there is no specific use cases in mind I think we should just remove that. It's so that you can use a select in the datalist (with the same options) for fallback in older UAs, without that select having any effect on the form submission. I do not understand that the select inside the datalist should not be invalid but why it *has* to be barred from constraint validation? Adding the required attribute to the select element in that case would be stupid and useless. The other way to make the select element invalid would be by calling .setCustomValidity(). Is there a real use case that require calling .setCustomValidity() in batch? Even if, can't we rely on the authors not calling .setCustomValidity() on elements that should not be invalid? We already do that for non-displayed elements, don't we? You should take into account that this requirement force the UA to check the entire parent tree to prevent a situation that can happen in various other ways. -- Mounir
Re: [whatwg] :invalid
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
for IE). Unfortunately, :invalid is far from being perfect and most
UI/UX guys would tell you that the current :invalid behavior is really
bad. For example, having the invalid style applying as soon as you load
the page (ie. for input required) is not a good thing. There are few
UX rules like that that :invalid currently breaks.
So, to improve the user experience while using web forms we would like
to fix that. However, we are wondering if :invalid (and :valid?)
specifications should be updated to take UX considerations or if a new
pseudo-classe should be created. Does anyone has an opinion about that?
form onblur=event.target.classList.add('examined')
onsubmit=for (var i = 0; i elements.length; i += 1)
elements[i].classList.add('examined')
...along with CSS rules like:
.examined:invalid { ... }
.examined:out-of-range { ... }
Since then, we have implemented something you can try with Firefox
4.0b8: :-moz-ui-invalid and :-moz-ui-valid. By default, all element
matching :-moz-ui-invalid have a red box shadow.
The rules for :-moz-ui-invalid are the following:
a. When not focused (AND list)
1. The element has its default value changed OR the element is in a
form that the user tried to submit (but was invalid) ;
2. The element is invalid (:invalid applies).
b. When focused (OR list):
1. If the element had :-moz-ui-invalid before it was focused,
:-moz-ui-invalid applies if the element is invalid (IOW, if the element
was valid or no style was applying, the element will not be shown as
invalid as long as the user do not blur the elemnet) ;
2. Otherwise, :-moz-ui-invalid will not apply as long as the element is
focused.
:-moz-ui-valid is very similar to that.
Note that we chose to have none of these pseudo-classes applying if the
form has novalidate attribute and :-moz-ui-invalid always apply if
.setCustomValidity() has been used to make the element invalid.
My description is probably not really clear because the UI rules are
somewhat complicated but we hope this give a nice user experience.
We would welcome any feedback about these new pseudo-classes.
On Thu, 23 Sep 2010, Boris Zbarsky wrote:
Are there cases when pages would set invalid default values and want
them flagged as such in UI?
On Fri, 24 Sep 2010, Shiv Kumar wrote:
Typically, in large organizations, there are folks who clean up data. So
they will be presented with data that's already entered by someone else
and their job is to clean up the data. In fact I see the new Form API to
be a very good candidate for this use case.
Indeed.
Our implementation lets you use :invalid for such use case.
--
Mounir
Re: [whatwg] Submit controls should be barred from constraint validation in favor of a new pseudo-class
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 be used on those controls, the only use case I see is to set the submit controls invalid when the form is invalid thus having :invalid style applying to them. If the given use case is correct, I think we should make all submit controls barred from constraint validation and introduce a new pseudo-class allowing to style submit controls when their form is invalid. Form controls are part of constraint validation for completeness only, as far as I can tell. Anything that's visible and submitted is a candidate for constraint validation. Except keygen and object. But do we agree that it's visible and submittable so it should be able to be invalid is not a sane rule? At least, we should not include non-editable but visible submittable controls like submit controls. Current Gecko nightlies (and next beta, beta7) have a :-moz-submit-invalid pseudo-class. Submit controls can still be marked invalid but that might change before the final release if there is an agreement that :-moz-submit-invalid is a better way to fulfill the need. As a side note for web authors on this list, :-moz-submit-invalid currently has a default style on Firefox but that is very likely going to change for beta8. Do people use this feature much? It's not in a stable release yet so it's hard to say. Actually, I was wondering if we couldn't introduce the :invalid pseudo-class to the form element. This will remove the need of :-moz-submit-invalid and certainly help for other situations. -- Mounir
Re: [whatwg] Form element invalid message
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. I actually think that the customerrormessage attribute that has been suggested is a decent solution too. It does mean that you have to do some trickery if you want to display different error messages for different types of errors, but nothing too bad. All you'd need to do is install an event handler for the invalid event, and in that handler do something like element.setAttribute(customerrormessage, myMessage); If you're setting an error message, what's wrong with setCustomValidity()? setCustomValidity() means this element is invalid for custom reasons and the argument is the error message. I think the use case of setCustomValidity() is *checking* something on oninput, onchange or other events and, if the condition is not fulfilled, call the method to make the element invalid. For example, two passwords fields have to be the same. The customerrormessage attribute would have different use cases. It would be when the element has known reasons to be invalid but when the author want to override the UA string. I see two reasons for that: 1. the element has very complex rules like: input type='email' name='username' required maxlength=100 pattern=[...@]*@company.com. It sounds hard for a UA to give one simple sentence for this situation but the author can try something like Please, enter your corporate email address (max 100 chars). 2. the author want a specific string to match the context of the website. For example, when you want to log on Foo website, the author might want to be sure you see Please enter you Foo ID. instead of a generic Please, fill this field. for input name='username' required For sure, you can use setCustomValidity() for both use cases but there is a small semantic difference and a bigger work to do. Using setCustomValidity() for these use cases would be a pain while using a customerrormessage attribute would be quite straightforward. -- Mounir
Re: [whatwg] Make radio button group suffering from being missing
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 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 invalid elements with :invalid, and do: input type='radio' name='s' value='M' required input type='radio' name='s' value='F' only the first element will be styled. I think we should move the requirement to the radio button group that way: The radio button group suffers from being missing if one of the input elements in the radio button group is required and all of them have a checkedness that is false. and radio elements would have this constraint: If the radio button group is suffering from being missing, the element is suffering from being missing.. That way, all radio elements in the same radio button group will have the same validity state. That would be less annoying for authors and error proof while making things clearer (IMO). I'm thinking of implementing that for Gecko 2.0/Firefox 4 so I would like to know if you know any reason that would make the current behavior more appropriate than the one described here. Do you have tests for this by any chance? I agree it makes sense to always treat them as a group. Yes, you can found them in the patch attached to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=610687 -- Mounir
Re: [whatwg] Constraint validation feedback (various threads)
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 greater than the element's maximum allowed value
length, then the element is suffering from being too long.
The dirty value flag is only true when the user has edited the control.
I don't think you can change the meaning of the dirty value flag. If it
is set to true only when the user edit the control, this code will not
work correctly anymore:
input.value = foo;
input.setAttribute('value', 'bar');
input.value will return 'bar' (instead of 'foo') because when setting
the content attribute's value, with a dirty value flag set to false, the
value is set to the content attribute's value according to the specs.
On 11/16/2010 06:47 PM, Aryeh Gregor wrote:
[[
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 greater than the element's maximum allowed
value length, then the element is suffering from being too long.
User agents may prevent the user from causing the element's value to
be set to a value whose code-point length is greater than the
element's maximum allowed value length.
]]
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-maxlength
with something like
[[
If an element has a maximum allowed value length, and the code-point
length of the element's value is greater than or equal to the
element's maximum allowed length, user agents must prevent the user
from increasing the code-point length of the element's value.
Note: For historical reasons, maxlength does not impose any
constraints on an element. Thus if an element's value is longer than
its maxlength, such as if a script set it, the form it's in can still
be submitted, and no error event is fired.
]]
and remove the suffering from being too long state. This matches
current behavior, but doesn't differ much from the current spec in
practice, because it means the element can never be in an invalid
state to begin with unless you do it yourself in JavaScript or set a
too-long value attribute (and the latter is invalid markup).
That would indeed reflect what browsers seem to do but that wouldn't be
a good idea because this UI is really bad for textarea at least. When
you type a long text, it's very frustrating to be blocked at some point
and not being able to just write what you had in mind and then reduce
the size.
We (Mozilla) are going to fix that in two steps:
1. For Firefox 4, elements will be valid if the value length is greater
than the maxlength attribute value (IOW, an element will not be able to
suffer from being too long). This is somewhat following Aryeh's suggestion.
2. After Firefox 4, we would like to introduce a new flag that will let
us know if the element's value has been changed by the user (probably if
the _last_ change has been done by the user). The meaning of this flag
would be to fix the retro-compatibility issues. Then, an element would
suffer from being too long if this flag is true and it's value length is
greater than the maxlength attribute value. In addition, users will be
able to enter text longer than the maxlength attribute for textarea (and
maybe input) elements. That way, we would be able to fix
retro-compatibility issues and provide a better experience to the users.
Feedback are welcome :)
Thanks,
--
Mounir
Re: [whatwg] Constraint validation feedback (various threads)
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 value. value On getting, it must return the current value of the element. On setting, it must set the element's value to the new value, set the element's dirty value flag to true, and then invoke the value sanitization algorithm, if the element's type attribute's current state defines one. http://www.whatwg.org/specs/web-apps/current-work/#common-input-element-apis That seems to say that setting via .value will set the dirty flag (although setting via .setAttribute() will not). Am I mistaken? Hm, yes, you are correct. I've lost track of the context for this; does the above imply that there is a change we need to make? Aryeh was worried about page using maxlength to block users input then setting the value to something else before submitting. Given that maxlength has nothing to do with form validation and now can block the form submission, it might break some websites. 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 but the field has a maxlength set to 4 (it's a year). With a checkbox checked, one of this field will be hidden, with a value greater than the maxlength making the form always invalid. -- Mounir
Re: [whatwg] Constraint validation feedback (various threads)
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 but the field has a maxlength set to 4 (it's a year). With a checkbox checked, one of this field will be hidden, with a value greater than the maxlength making the form always invalid. 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 greater than the element's maximum allowed value length, then the element is suffering from being too long. The dirty value flag is only true when the user has edited the control. Actually, not: value On getting, it must return the current value of the element. On setting, it must set the element's value to the new value, set the element's dirty value flag to true, and then invoke the value sanitization algorithm, if the element's type attribute's current state defines one. http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-value -- Mounir
[whatwg] Make radio button group suffering from being missing
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 invalid elements with :invalid, and do: input type='radio' name='s' value='M' required input type='radio' name='s' value='F' only the first element will be styled. I think we should move the requirement to the radio button group that way: The radio button group suffers from being missing if one of the input elements in the radio button group is required and all of them have a checkedness that is false. and radio elements would have this constraint: If the radio button group is suffering from being missing, the element is suffering from being missing.. That way, all radio elements in the same radio button group will have the same validity state. That would be less annoying for authors and error proof while making things clearer (IMO). I'm thinking of implementing that for Gecko 2.0/Firefox 4 so I would like to know if you know any reason that would make the current behavior more appropriate than the one described here. -- Mounir
Re: [whatwg] input type=number without keyboard editing
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 range such as 1 - 16. The number type control in Opera and WebKit allow a user to input out-of-range value even if the control has min=1 and max=16 attributes. It's not a good UI and the reason why they doesn't use type=number. They need a number control which - doesn't allow any keyboard / cutpaste operations and So, a text field part is read-only, but the spin-buttons work. - always has a valid value. required by default, and sanitization algorithm may be different. I'm not sure how to solve this issue. Introducing new content attribute or another number type? Do you really want to disallow keyboard editing, or do you just want to disallow entering an out-of-range number? The latter should be prevented by a proper implementation of input type=number. If that is not the case in webkit or opera then I suggest you file bugs on those implementations. I'm not sure that disallowing out-of-range numbers would be the best implementation but if all implementations concur to that, maybe the specifications should reflect that and disallow out-of-range values like it's asking for valid floating point numbers value. For the moment, using a simple event handler should fix it. -- Mounir
[whatwg] Make f...@bar.com, a valid email address list
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 appended by , . Indeed, a comma have to be added to mark that the user is now editing another email address so the UI can suggests new ones. Without adding the comma automatically, the user would have to add it by hand to have the UI suggesting new entries. So, if we do not fix the specifications, all input type='email' multiple with a UI will be whether invalid or really annoying to implement. You can found an example of that kind of UI in GMail. I think we should change the specifications so an email address list will be valid if it's ending with a comma (plus trailing whitespaces). In other words, if a list of email address have more than one token, the last one can be the empty string. We are thinking of implementing this change in Gecko 2.0 so feedback are very welcome. Thanks, -- Mounir
Re: [whatwg] Make f...@bar.com, a valid email address list
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 to put a UI on top of that, values will always be appended by , . Indeed, a comma have to be added to mark that the user is now editing another email address so the UI can suggests new ones. Without adding the comma automatically, the user would have to add it by hand to have the UI suggesting new entries. So, if we do not fix the specifications, all input type='email' multiple with a UI will be whether invalid or really annoying to implement. Oh, and I forgot to add that we need to fix that to have @list working nicely with input type='email' multiple. -- Mounir
Re: [whatwg] Interaction between @multiple, @pattern and @list
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 pattern attribute. For example, the author wouldn't be able to ask for different emails with at least one from company A and company B. In addition, asking for at least x emails, exactly y emails or maximum z emails wouldn't be possible. Though, the former case doesn't sound to be important and the later would be better with new attributes like minentries and maxentries. I also realized that @list currently is pretty useless in similar situations together with input type=text. Often times text inputs are used to enter a list of tokens. One example is the keyword input field in bugzilla. It helps you autocomplete from the list of available keywords, but also lets you enter multiple keywords in the same text field. As things stand now you can't use @list to accomplish this as it operates on the whole value rather than each comma separated token. It would be possible to make this work by allowing @multiple to apply to input type=text. The only effect would be that @list and @pattern would operate on each comma separated token. A more common use case would be tag/keywords list on blogs/websites. Currently CMS must provide their own UI for that. list+multiple might be really helpful. Thanks, -- Mounir
[whatwg] Why children of datalist elements are barred from constraint validation?
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 cases in mind I think we should just remove that. Thanks, -- Mounir
Re: [whatwg] Constraint validation feedback (various threads)
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 could use the constraint validation. The user can't edit the value of output, so the only time this would be helpful is when you have script, with the script setting the validity using setCustomValidity(). But then the script can just as easily set it on the control that's actually making the output be invalid. That would also be better UI -- having the user agent point out the output control is invalid would likely just infuriate users who couldn't tell what they had to do to change the value. I don't think having invalid output will be confusing for the user given that the authors will have to set a message describing the issue. The authors would have no reason to make this message unclear. In addition, output is already semantically linked to some elements so marking it invalid should be a hint that they need to be modified. For the UI point of view, you can easily found use cases when showing the output is much more convenient that highlighting all elements making the output invalid. For example, in a web application to select courses in a university. If there is an output showing the sum of credits which has to be between 12 and 18, it sounds to be nicer to have the output marked as invalid with a message explaining that the sum of credits has to be between 12 and 18 than having all courses marked as invalid which can be wrongly interpreted. Though, I don't think the UI is a valid point here. Shouldn't we let the authors choose what UI they want to implement and just give them the API to do it? Tab, you seemed to support this proposition when I made it. Is it planned to have that implemented in Webkit? Thanks, -- Mounir
[whatwg] input element list attribute and filtering suggestions
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]. However, it sounds like having a static combobox would only fulfill some use cases (ie. when a very small set of suggestions is defined). In most obvious situations, having a list with all the suggestions would be annoying. So, it might be interesting to have the list filtered with the current element's value to be able to use the list attribute for large list and have a boolean attribute to enable or disable the filtering. One simple use case would be a city transportation website. If you have to type a station name in a field it might be much more user friendly to have a filtered list. Actually, I do not see any use case of the list attribute without filtering. To me, it seems like a replacement of a select with options and an input fields in the case of none of the above. And I do not think this replacement would be better. I am wondering what were the use cases in mind? So, the current implementation of the list attribute in Gecko [3] is filtering the list with the element's value by default [4] and we have introduced a mozNoFilter boolean attribute which can be used to have a non-filtered list. Feedbacks are welcome :) [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-list-attribute [2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9785 [3] Available in current Firefox nightlies and will be in beta7. [4] To be exact, the filter is done on the option's label Thanks, -- Mounir
Re: [whatwg] Form element invalid message
(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 doesn't seem cryptic to me. Come now Aryeh :). Imagine this scenario. On a web page/form, I'm asking the user to enter her social security number and she sees a message You have to specify a value, you're saying that sounds ok to you? Oh, and the next browser will say something like, This is a required field. What then? If the problem is the user didn't enter a value and the value is required, this message is probably the best. If the user wrote something which doesn't follow the SSN pattern, then, the message should be different (assuming the pattern attribute was used!). In that case, the message could be a generic one (like The value doesn't follow the given pattern or anything like that). However, specifications say you can use @title to add informations about pattern. In that case, the UA might add this message in the validation message. It could be something like The entered value is not valid: you have to enter a SSN number with title=you have to enter a SSN number. When the element is suffering from a pattern mismatch, it's the only case where it's hard to say what is exactly wrong. That's why @title is used. Do not expect @title to be used in other validation messages. -- Mounir
Re: [whatwg] Form element invalid message
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 the string abcd. In Opera it's worse -- The value is not
allowed by a script on the page! abcd (visible double space after
value, due to inserting the string unquoted) -- but the Opera UI
here is really bad in many ways, as noted, and is likely to improve as
other browsers implement good UIs. Note that Firefox is buggy here
and treats setCustomValidity('') as setting the error message to ''
instead of removing it, as the spec says, but when that's fixed it
will work.
I don't think there is a bug in Gecko. For what I understand, the bug is
in Presto if the behavior is what you describe.
According to the specifications [1], when the submission is requested
and there are invalid form elements, the form submission should be
canceled. If one element do not cancel the invalid event, the UA should
use it's own interface to explain what's happening. In all cases, the
form submission will be canceled.
So, what you do is making the element valid in the invalid event which
is too late. After the invalid event, Firefox tries to show the UI using
the validationMessage which return the empty string when the form is
valid. You should cancel the event if you want to have no UI at all but
still cancel the submission. You should use onchange/oninput to change
the validity state if you want the form to be submitted.
And, FTR, I think I do not think it's a good think to use
setCustomValidity() _only_ to put your own message in there. This should
be used when the validity rule isn't one of those specified. For
example, if you want two password fields to be the same, you can use
setCustomValidity() because there is no way to specify that with the
current constraint validation API.
I don't think people should promote the use of setCustomValidity() to
override a pre-defined message with a more custom one like changing
Please fill this field. by Please, set a username.. But that's just
an opinion...
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#interactively-validate-the-constraints
Thanks,
--
Mounir
[whatwg] fieldset disabled and first legend
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 any, to be disabled. First of all, form control descendants isn't really clear considering there is no real definition of form control in the specification AFAIK. Why not using listed elements instead? which would correspond to all elements returned by .elements. This is very interesting to have the elements inside the first legend to not be disabled. I guess the idea is to have a checkbox enabling some options. For example, advanced options in a configuration. However, the specification seems to miss one edge case. What if a fieldset has been disabled because it is inside a disabled fieldset? Depending on how you read the current specification, you can consider that the elements inside the first legend of the second fieldset should be disabled or not. My opinion is, those elements should be disabled and that's the current Gecko's behavior (current nightly and next beta). It would be good to add something mentioning this edge case. Thanks, -- Mounir
[whatwg] input element's value should not be sanitized during parsing
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 attributes are read, value will be set before or after type, thus, changing the value sanitization algorithm. So, the value sanitization algorithm of input type='text' will be used for one of these elements and the value will be foobar. The following change would fix that bug: - The specification should add that the value sanitization algorithm should not be used during parsing/as long as the element hasn't been created. OR - The specification should add in the set value content attribute paragraph that the value sanitization algorithm should not be run during parsing/if the element hasn't been created. For a specification point of view, both changes would have the same result. The specifications already require that the value sanitization algorithm should be run when the element is first created. So, with this change, the element's value will be un-sanitized during parsing and as soon as the parsing will be done, the element's value will be sanitized. By the way, first created could probably be changed to a concept from the specifications. We can guess what that means but there is no strong notion behind this words AFAIK. Thanks, -- Mounir
Re: [whatwg] input element's value should not be sanitized during parsing
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, hidden); and inp = document.createElement(input); inp.setAttribute(type, hidden);inp.setAttribute(value, foo\nbar); This does not seem desirable. They do. And I don't see this can be different. -- Mounir
[whatwg] Form controls disabled IDL attribute and disabled state
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 the same meaning. It's now only reflecting the content attribute and not the disabled state. Nothing in the API let the author knows the disabled state so the only solution is to look at the entire parent chain until a fieldset with the disabled attribute is found [1]. I can understand why when getting the disabled IDL attribute, this is not returning the state but the content attribute but I think there is a lack in the API and it might be nice for authors to have a simple way to know the state of the element [2]. This could be done with the IDL attribute returning the state instead of the content attribute or another attribute returning the state. Feedbacks welcome :) [1] if the fieldset has no disabled attribute, it still might be a child of another fieldset which has a disabled attribute. [2] some tricks might be to use query selector and check if the element has the :disabled pseudo-class applying but that's only a workaround. -- Mounir
[whatwg] :enabled and :disabled pseudo-classes should apply on fieldset elements
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 Mozilla might do the same. Thanks, -- Mounir
[whatwg] reset algorithm doesn't seem to reset input type='file'
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
Re: [whatwg] Case canonicalization for reflected enumerated attributes limited to known values
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 value); alert(el.method); /script IE alerts get, everyone else alerts invalid value. Are non-IE implementers interested in changing to match IE here? IE's behavior seems more useful. Hi, This is actually a recent change in the specification so you should not expect to have all browsers working the same way. FWIW, Firefox nightlies already follow this change. That will be in beta5 too. Thanks, -- Mounir
Re: [whatwg] select element should have a required attribute
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 optionvalue 3/option /select /label The first option should be selected, resulting in the select having value=. If `required` is specified, and the user selects an empty option (the first option in the list) and submits the form, what do you think should happen? Like for input or textarea, if select.value is the empty string, the select element suffers for being missing. Or select option value=Choose an option:/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select What should happen if the SELECT has `required`? ditto -- Mounir
