I've also just added a section with the stats that the Adobe Flash
player exposes.
Apart from the statistics that are not currently available from the
HTML5 player, there are stats that are already available, such as
currentSrc, currentTime, and all the events which can be turned into
hooks for
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.
Well... span could be enough for this use case ;-)
Alexandre Morgaut
Product Manager
4D SAS
60, rue d'Alsace
92110 Clichy
On Thu, Apr 7, 2011 at 3:25 AM, Alexandre Morgaut
alexandre.morg...@4d.com 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.
Well... span could be enough for this use
Den 2011-04-06 22:45:36 skrev Tab Atkins Jr. jackalm...@gmail.com:
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
Simple use case with existing car configurators:
When a car feature / accessory is selected that requires another feat. /
access., I don't want customers to uncheck that feature, but still need the
submission of the required features.
Or the Mootools library builder:
Depending modules need to
On 6 April 2011 23:39, 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 checked
On 2011-04-06 02:56, Lachlan Hunt wrote:
To render this, the following CSS should be applied by the UA stylesheet.
detailssummary:first-of-type {
display: list-item;
margin-left: 1em; /* LTR-specific: use 'margin-right' for rtl elements */
list-style-type: -o-disclosure-closed;
}
On Thu, Apr 7, 2011 at 6:09 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
1. The rendering of details will, unfortunately, inherit the quirks mode
rendering of list-items, where the bullet is a fixed size in quirks mode,
and based on the font-size in standards mode. This is a quirk
On Wed, Apr 6, 2011 at 7:40 PM, Tim Down timd...@gmail.com wrote:
Is there an overwhelming reason why execCommand() should be restricted
to contentEditable/designMode elements, as the spec seems to suggest?
IIRC from testing, that's how all browsers but IE9 behave. I guess
the reason is that
On 7 April 2011 18:36, Aryeh Gregor simetrical+...@gmail.com wrote:
On Wed, Apr 6, 2011 at 7:40 PM, Tim Down timd...@gmail.com wrote:
Is there an overwhelming reason why execCommand() should be restricted
to contentEditable/designMode elements, as the spec seems to suggest?
IIRC from testing,
On 3/30/11 10:50 AM, Aryeh Gregor wrote:
That would result in
pbFoo/bbbar/b/p
but actually, the result in Gecko is
pbFoobar/b/p
So I looked into this. It looks like Gecko does move the text node
containing bar to be a child of the b and tracks which selection
ranges are in the node
On Thu, Apr 7, 2011 at 5:57 PM, Tim Down timd...@gmail.com wrote:
I don't recall ever wanting to use execCommand() in non-editable
content myself (although I wouldn't rule it out), but I've answered a
few questions on Stack Overflow where the asker has wanted to
highlight (i.e. change the
On Thu, Apr 7, 2011 at 6:03 PM, Boris Zbarsky bzbar...@mit.edu wrote:
So browsers must be special-casing how execCommand() affects
selections somehow
That's certainly what Gecko is doing, yes.
Thanks for the info. In the end, I managed to define a reasonably
clean way of getting good enough
13 matches
Mail list logo
