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

Hello Ian!

Thanks for the reply and for all the changes/fixes you made to the spec,  
based on my feedback.


Le Sun, 09 Mar 2008 04:32:53 +0200, Ian Hickson <ian@hixie.ch> a écrit:

> On Tue, 9 Oct 2007, Mihai Sucan wrote:
>
> [...]
>
>> 4. In the same section 5.2.1, the last paragraph: the Enter key is
>> marked-up with two <kbd> nested tags - should only be one <kbd>.
>
> Actually HTML5 defines one of them as meaning "type the word "Enter"" and
> two of them as meaning hit the key Enter.

I didn't see that. ;)


>> 6. How does a script determine the exact caret position? By "exact" I
>> mean: in which element node, at which character position within the
>> element is it?
>
> It appears that there's no way to do this right now using the API defined
> in the spec for the selection of text with contentEditable. We could add
> something, though... What do implementors think?

I'm not sure you will get a reply to this question. This brings me to  
something I wanted to tell you: replying to tons of emails in a single  
email, without providing CCs to the authors, can cause us to miss the  
replies. While it's easier for you, it's harder for us to track them down.  
This is because I get tons of emails, which I simply mark them as read - I  
only check the from, to and the subject fields.

Additionally, even when replying individually: asking what implementors or  
other people think, will not get much feedback. The reason is simple: most  
people subscribed to this list simply mark emails as read, if they are not  
direct replies to their feedback - they can't keep up with other emails.

As such, I would suggest that you make some notes, for all feedback, and  
for all the cases where you want more feedback from implementors and other  
people. When you have a good list of questions (about 30 or more), send  
them to the two mailing lists, something "Implementors feedback needed".  
This would be easier for people from Opera, Mozilla, and Apple to reply to.

(hopefully, this doesn't sound like "critical", or on a "high tone", but  
it's just an idea, about improving communication. don't worry, you are  
doing an amazing/impressive job already ;) )



>> 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?  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.

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"? 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.

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?

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.



>> Based on some concerns raised by this scenario, I suggest defining that
>> the "designMode" event fires at the document before it's enabled, and
>> after it's disabled, such that scripts can "know" this has happend. The
>> event must not be cancelable.
>
> Well, a script has to trigger designMode in the first place. So, that
> script can notify the page as desired.

It's not the same to be notified by a script, or by the UA. The script can  
choose not to notify that designMode has been enabled. The UA cannot  
choose that, and no script can cancel the event.


>> 1. My internal WYSIWYG editor (Awebitor) is not full-fledged like
>> others, yet it makes use of commands which are not in the spec.
>
> [...]
>
>> c) The "removeformat" command which removes all the formating of a
>> selection. This actually removes style attributes, bold, italics,
>> underline, align left/center/right/justify and some more. Proper testing
>> needs to be done to determine the precise behavior. I can do it, if this
>> command is to be added to the spec.
>>
>> The command is quite useful in many cases when editing a document. It
>> would be quite much work, prone to errors, for authors to write their
>> own implementations.
>
> 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).


Thanks again.

Best regards,
Mihai


-- 
Mihai Sucan
http://www.robodesign.ro

Received on Sunday, 9 March 2008 11:28:58 UTC