Re: several messages about contentEditable, text selection, and related subjects

On Sun, 09 Mar 2008 12:28:45 +0100, Mihai Sucan <mihai.sucan@gmail.com>  
wrote:

>>> Also, it's generally undefined what happens with CSS :hover, :focus,
>>> :checked, and other "state-aware" pseudo-classes.
>>
>> Nothing special happens per spec right now... What should happen?
>
> Example:
>
> <p id="elem">Testing CSS</p>
> <p>Testing even more</p>
>
> #elem + p { display: none; }
>
> #elem:hover + p { display: block; }
>
>
> How does one go about editing "Testing even more", wtihout a pointing  
> device?

You can't.


> I know this is a corner case for document editing - nobody in his/her  
> right mind wouldn't provide such "trick cases" as documents for editing.

Indeed.


> Also, this can become more complicated easily.
>
> #elem:before { content: "test "; }
>
> <p id="elem">my paragraph</p>
>
> In rendering that shows as "test my paragraph". Should the user be able  
> to edit "test"?

No.


> The user won't be able to tell it's CSS generated content or not. The  
> user will simply expect he/she can edit "test" as well.

Consider a realistic case for this, e.g. counters in headings. They appear  
automatically when you create a heading, you can't select them (at least  
in Opera you can't), and they should be there in the output. Why should  
the user be able to edit it?


> Another interesting example:
>
> #elem { content: "whatever"; }
>
> <p id="elem">interesting example</p>
>
> In UAs which support CSS 3 ... that will render as "whatever"  
> ("interesting example" is lost). Can the user edit this paragraph or not?

No (unless the user disables CSS).


> In these two cases, it might "natural" for a developer to say: well, you  
> can't edit "test" nor "whatever" because it's CSS, but this is not true  
> for a user. Simple users just expect it to work.
>
> Even if all these are corner cases, they should be defined.

It's not clear to me what is actually undefined here.


>> Should removeformat remove things like 'em' and 'strong' and 'cite' and
>> 'var' and 'b' and 'i' and 'span' and 'a'?
>
> Afaik, this doesn't remove links, it doesn't remove semantical markup  
> (e.g. var, kbd, code). It does remove style attributes, b, i, font,  
> span, and similar presentational tags. I don't know the exact behaviour  
> - it would be best if you would ask some of the implementors (Opera,  
> Mozilla).

I tested Opera and Mozilla, and they do different things, and both are  
IMHO undesirable (e.g. Opera removes links, Mozilla removes bold but not  
italic). Removeformat is, AIUI, intended to get rid of style information  
without loosing "semantics" after pasting in a chunk of text from another  
application. I would argue that <b> and <i> should not be removed since  
they are generally tied to the content while font family is generally not.

Maybe UAs should just strike style information when pasting from another  
app directly as to make this command redundant?

-- 
Simon Pieters
Opera Software

Received on Sunday, 9 March 2008 12:03:30 UTC