Re: [css-ui-4] user-select

The content seems good and clear to me, but there are others who can 
provide better feedback on that.

Ad Issue 17, 24: I think "default" or "normal" fit better, yes.
Ad Issue 20: "element" makes sense for me. I find "contain" more confusing.

My feedback as far as the text goes:
(-) 7.1. Controling content selection => s/Controling/Controlling
(-) I'd change
"The computed value is the specified value, except on editable elements 
where the computed value is always element regardless of the specified 
value, and when the specified value is auto, which computes one of the 
other values as defined below."
to "The computed value is the specified value, except:
a. on editable elements where the computed value is always element 
regardless of the specified value
b. when the specified value is auto, which computes one of the other 
values as defined below."

The specs are always hard to understand and long sentences obfuscate the 
meaning even more. I remember that there already have been a few 
discussions on the mailing list about how to improve wording on other 
topics so I thought I'd articulate my feedback on future specs.
(-) The computed value of auto is determined as follow: => s/follow/follows
(-) If the element is an editable element (ADD: ",") the computed value 
is element
(-) ... then the parent must (ADD: "be") included in the selection, 
recursively.
(-) UAs may render form controls using native controls of the host 
operating system or with a look and feel not other expressible in CSS. 
=> s/other/otherwise

There is more but it's tedious to write it down in an e-mail like this 
and even more tedious to collect it afterwards. Is there a way for me to 
edit it directly or are corrections like this not needed at this stage 
of the document anyway?

Have a nice evening,
Sanja

On 02-Apr-15 4:47 PM, Florian Rivoal wrote:
> Since CSS-UI level 3 is getting increasingly stable and nearing CR,
> I've just started a level 4 draft as a diff spec.
>
> I've started by adding 'user-select', which we had deferred from
> level 3:
>
> http://dev.w3.org/csswg/css-ui-4/#content-selection
>
> There is general agreement between existing implementations about
> which values should exist and what they mean, so I have not tried
> to be creative about that.
>
> However, the interop story is less nice when you look into the
> details, as browsers disagree on the meaning of auto, computed
> values, inheritance, applicability to editable elements...
>
> The specification tries to strike a reasonable middle ground. It
> tries to be close as possible to existing implementations when
> they agree and make sense. When it diverges from some of the
> implementations, I've either included a note saying why, or an
> issue highlighting the disagreements.
>
> Also, even though as of today, only IE supports the ''element''
> value, I have included it because:
>
> * Even browsers that do not explicitly support it have this
> behavior on editable elements (<input>, <textarea>,
> contenteditable elements...)
>
> * It influences the overall design of the property in terms of
> inheritance and computed values.
>
> * Mozilla[1] and Tab[2] have expressed at least some interest in
> having this value with similar semantics to IE.
>
> Feedback most welcome.
>
>   - Florian
>
> [1]https://bugzilla.mozilla.org/show_bug.cgi?id=1036853
> [2]https://lists.w3.org/Archives/Public/www-style/2014Nov/0541.html
>

Received on Thursday, 2 April 2015 17:48:50 UTC