On Thu, 10 Feb 2011, Silvia Pfeiffer wrote:
>
> One particular issue that hasn't had much discussion here yet is the
> issue of how to deal with multitrack media resources or media resources
> that have associated synchronized audio and video resources. I'm
> concretely referring to such thing
On Thu, Apr 7, 2011 at 6:03 PM, Boris Zbarsky 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 results:
h
On Thu, Apr 7, 2011 at 5:57 PM, Tim Down 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 background colour
On 3/30/11 10:50 AM, Aryeh Gregor wrote:
That would result in
Foobar
but actually, the result in Gecko is
Foobar
So I looked into this. It looks like Gecko does move the text node
containing "bar" to be a child of the and tracks which selection
ranges are in the node it's removing
On 7 April 2011 18:36, Aryeh Gregor wrote:
> On Wed, Apr 6, 2011 at 7:40 PM, Tim Down 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 be
On Wed, Apr 6, 2011 at 7:40 PM, Tim Down 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 if you have a typ
On Thu, Apr 7, 2011 at 6:09 AM, Lachlan Hunt 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 implemented
> by Firefox, IE a
On 2011-04-06 02:56, Lachlan Hunt wrote:
To render this, the following CSS should be applied by the UA stylesheet.
details>summary:first-of-type {
display: list-item;
margin-left: 1em; /* LTR-specific: use 'margin-right' for rtl elements */
list-style-type: -o-disclosure-closed;
}
details
On 6 April 2011 23:39, Lachlan Hunt wrote:
> On 2011-04-07 00:28, Tab Atkins Jr. wrote:
>
>> On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt
>> wrote:
>>
>>> What's wrong with using disabled?
>>>
>>>
>>>
>>>
>>>
>>
>> Disabled elements don't participate in form submission.
>>
>
> That's true, but
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 be
Den 2011-04-06 22:45:36 skrev Tab Atkins Jr. :
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'
On Thu, Apr 7, 2011 at 3:25 AM, Alexandre Morgaut
wrote:
>>
>>> What are the use cases for readonly on?
>>
>> The primary one I've seen is to have a non-editable text input that the
>> user can still select-and-copy from.
>
> Well... could be enough for this use case ;-)
Well... you wont get eff
>
>> What are the use cases for readonly on?
>
> The primary one I've seen is to have a non-editable text input that the
> user can still select-and-copy from.
Well... could be enough for this use case ;-)
Alexandre Morgaut
Product Manager
4D SAS
60, rue d'Alsace
92110 Clichy
France
Standa
13 matches
Mail list logo
