[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
Re: [whatwg] Add an attribute for opting out of synchronous CSSOM access
Le 05/04/2013 15:07, Henri Sivonen a écrit : Please add an attribute to link that: * opts an external style sheet out of synchronous CSSOM access Sorry if my suggestion is naive, but why about an attribute to opt out of CSSOM entirely? As you suggested in the www-style thread [1] I would guess that the average author doesn't use CSSOM beyond the sugaring for the style attribute and maybe getComputedStyle() and even those hidden behind a JavaScript library. As a web developer (I don't know about average) I certainly agree. David [1] http://lists.w3.org/Archives/Public/www-style/2013Jan/0519.html
Re: [whatwg] Add an attribute for opting out of synchronous CSSOM access
On Wed, Apr 17, 2013 at 2:51 PM, David Bruant bruan...@gmail.com wrote: Le 05/04/2013 15:07, Henri Sivonen a écrit : Please add an attribute to link that: * opts an external style sheet out of synchronous CSSOM access Sorry if my suggestion is naive, but why about an attribute to opt out of CSSOM entirely? As you suggested in the www-style thread [1] I would guess that the average author doesn't use CSSOM beyond the sugaring for the style attribute and maybe getComputedStyle() and even those hidden behind a JavaScript library. As a web developer (I don't know about average) I certainly agree. Opting out entirely doesn't really gain us anything, and locks out cases that *do* want CSSOM access but also want async stylesheets. ~TJ
Re: [whatwg] Forcing orientation in content
Hi, On Thu, 18 Apr 2013 01:52:47 +0300, David Bruant bruan...@gmail.com wrote: Hi, Currently working on a web project where tablet support (iPad especially) is important, I'm facing a need which apparently the platform doesn't support. I would need to lock the screen in landscape mode. Not sure if WHATWG is doing anything, but in the W3C there is https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html in the Web Apps group (by Mounir, who works on Firefox OS as a day job) I expect to know a bit more about the implementation status of this in about a week, when the group has a face to face meeting. cheers Chaals I've been searching and StackOverflow suggested this is not possible [1][2][3][4]. The best solution that I have read online was to listen to orientation changes, update an orient attribute (on body or html) and change the CSS based on that. Or Media Queries. But I don't really want to play with either JavaScript or CSS, I don't really know why I should. Especially given that in some comments [1], it is suggested that it is possible to lock the orientation in native apps. Beyond my current project, I have participated to a FirefoxOS app days in Bucharest (helped people developing their apps mostly answering their questions). A participant wanted to port his website (games for ~5yo kids) as an FirefoxOS app and told me clearly that if he had no way to lock the screen in landscape, he wouldn't be interested in FirefoxOS (pretty sharp opinion, but that's what he said). Fortunately, that's possible, but one has to use metadata to do so [5]. So I feel the need is there. I was wondering if it would be possible to add a meta (or whatever else is felt more relevant) to lock the orientation declaratively. It sounds like an information that belongs to the head. I feel the FirefoxOS experience [5] sets a good example. Thanks, David [1] http://stackoverflow.com/questions/2772691/is-it-possible-to-prevent-iphone-ipad-orientation-changing-in-the-browser/2772748#2772748 [2] http://stackoverflow.com/questions/8738072/forcing-web-site-to-show-in-landscape-mode-only [3] http://stackoverflow.com/questions/3217805/force-orientation-on-ipad-javascript [4] http://stackoverflow.com/questions/1207008/how-do-i-lock-the-orientation-to-portrait-mode-in-a-iphone-web-application [5] https://developer.mozilla.org/en-US/docs/Apps/Manifest#orientation -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
