On 2011-04-06 03:36, Tab Atkins Jr. wrote:
I like the idea of using display:list-item for thesummary. It has
some unfortunate weaknesses due to the way that display:list-item is
defined; in particular, you can't get an inline summary without losing
the disclosure marker, since there's no way to
Note: while this email is intentionally cross-posted; my request is that
any responses trim the replies down to *one* of the above lists.
===
At the present time within the HTML WG, there are no surveys active, and
no calls for proposals. Some are actively working on converging to
fewer
All,
I added some material to the wiki page based on our experience here at Netflix
and based on the metrics defined in MPEG DASH for adaptive streaming. I'd love
to here what people think.
Statistics about presentation/rendering seem to be covered, but what should
also be considered are
Currently, the spec disallows checkboxes from being made readonly. Is
there some good reason for this? If not, can we change it?
Checkboxes being readonly would be useful for the same reasons that
text inputs being readonly is.
Radio buttons can't be readonly either, but they have the obvious
On Wed, Apr 6, 2011 at 1:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Checkboxes being readonly would be useful for the same reasons that
text inputs being readonly is.
As someone who spends a lot of time writing native UIs, I agree. It's
useful to be able to dim out a checkbox that no
On 2011-04-06 22:45, Tab Atkins Jr. wrote:
Currently, the spec disallows checkboxes from being made readonly. Is
there some good reason for this? If not, can we change it?
Checkboxes being readonly would be useful for the same reasons that
text inputs being readonly is.
What's wrong with
On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-04-06 22:45, Tab Atkins Jr. wrote:
Currently, the spec disallows checkboxes from being made readonly. Is
there some good reason for this? If not, can we change it?
Checkboxes being readonly would be useful
On 2011-04-07 00:28, Tab Atkins Jr. wrote:
On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Huntlachlan.h...@lachy.id.au wrote:
What's wrong with using disabled?
input type=checkbox disabled
input type=checkbox disabled checked
Disabled elements don't participate in form submission.
That's true,
On Wed, Apr 6, 2011 at 3:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-04-06 22:45, Tab Atkins Jr. wrote:
Currently, the spec disallows checkboxes from being made readonly. Is
there some good reason for
On Wed, Apr 6, 2011 at 3:39 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-04-07 00:28, Tab Atkins Jr. wrote:
On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Huntlachlan.h...@lachy.id.au
wrote:
What's wrong with using disabled?
input type=checkbox disabled
input type=checkbox disabled
On Wed, Apr 6, 2011 at 3:39 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-04-07 00:28, Tab Atkins Jr. wrote:
On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Huntlachlan.h...@lachy.id.au
wrote:
What's wrong with using disabled?
input type=checkbox disabled
input type=checkbox disabled
On 4/6/11 3:43 PM, Jonas Sicking wrote:
What are the use cases for readonly oninput type=text?
The primary one I've seen is to have a non-editable text input that the
user can still select-and-copy from.
-Boris
I'm building a web-app that makes use of the Geolocation API. While
building my application, I've come across an issue with how browser
makers have implemented the Geolocation API.
Depending on the browser and device, permission will be asked either
in a bar across the top of the browser (Firefox
Is there an overwhelming reason why execCommand() should be restricted
to contentEditable/designMode elements, as the spec seems to suggest?
Tim
On 1 March 2011 18:36, Aryeh Gregor simetrical+...@gmail.com wrote:
Two or three weeks ago I began writing a specification for
execCommand() and
On Wed, Apr 6, 2011 at 4:37 PM, Andrew de Andrade
and...@deandrade.com.brwrote:
2) The HTML5 specification defines how browsers should implement this
consistently -- either a bar across the top OR modal dialog box, but
not both. This isn't ideal either since there are arguments both for
and
On Wed, Apr 6, 2011 at 8:04 PM, Peter Kasting pkast...@google.com wrote:
Furthermore, modal
dialogs have other usability issues that the browser vendor may wish to
avoid, e.g. requiring script on many different tabs to stop.
Are you thinking of how the prompt, etc. require that the UA pause
On Wed, Apr 6, 2011 at 7:37 PM, Andrew de Andrade
and...@deandrade.com.br wrote:
2) The HTML5 specification defines how browsers should implement this
consistently -- either a bar across the top OR modal dialog box, but
not both. This isn't ideal either since there are arguments both for
Right
17 matches
Mail list logo
