On 25/05/2014 20:40 , Piotr Koszuliński wrote:
Making some things unselectable might also be useful. IE has
unselectable, there's also -moz-user-select and friends. But this is
small fries for later I'd reckon.
There are also nested non-editable islands. We built very important
feature based on them - http://ckeditor.com/demo#widgets. Currently we
block their selection by preventing mousedown and we handle left/right
arrows. But cancelling selectionchange would allow us to control more
cases in a cleaner way.
I'd be curious to know what your take is on the best way to expose this.
IE has an unselectable attribute, whereas Gecko and WebKit have a CSS
property. In this thread we've been talking about using cancellable
events for this (or if not cancellable, ones in which the selection can
be modified on the fly).
On instinct I would tend to think that this not a great usage of CSS,
it's much more tied to behaviour at a lower level. But it sort of is one
of those borderline things (as many of the properties that initially
came from the CSS UI module).
The scriptable option that we're consider is good in that it enables
arbitrary cases, but it could be interesting to support a number of
cases out of the box with a simpler (for developers) approach.
Let's imagine the following DOM:
<div contenteditable=minimal>
<p>blah blah blah</p>
<div class=widget unselectable>...</div>
<p>blah blah blah</p>
</div>
If the cursor is at the beginning of the first p, you hold Shift, and
click at the end of the second p, we could imagine that you'd get a
Selection with two Ranges (one for each p) and not containing the
unselectable widget. I *think* that's the most desirable default
behaviour, and it's also one that can be pretty painful to control
through script. In that sense an unselectable attribute would make
sense. (I reckon that setting the widget to be cE=false would have the
same effect, but it is nevertheless an orthogonal property.)
WDYT?
--
Robin Berjon - http://berjon.com/ - @robinberjon
