W3C home > Mailing lists > Public > public-html@w3.org > August 2008

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 19 Aug 2008 22:23:27 +0000 (UTC)
To: Mihai Sucan <mihai.sucan@gmail.com>
Cc: HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0808192151370.14795@hixie.dreamhostps.com>

On Sun, 9 Mar 2008, Mihai Sucan 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?
> 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.

I don't really see how these aren't already defined. Isn't the behaviour 
pretty clear? I mean, it's not especially useful behaviour (in most of the 
examples above, the text isn't editable), but it's still well-defined. 
contenteditable doesn't change how CSS works, it just allows a caret to be 
inserted inside rendered text nodes.



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

The point is that since the script has access to the page, it can blow 
away any notification mechanism. Since you have to trust the page that 
invokes designMode anyway, you might as well just develop a convention 
with that page.


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

I haven't heard much feedback on this so far.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 19 August 2008 22:23:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:22 GMT