W3C home > Mailing lists > Public > www-style@w3.org > April 2015

[css-ui-4] user-modify

From: Florian Rivoal <florian@rivoal.net>
Date: Thu, 30 Apr 2015 17:17:43 +0200
Message-Id: <3A8C1D51-47A4-49A6-BADF-F0331D83AA11@rivoal.net>
To: www-style <www-style@w3.org>
Hi,

After specing user-select and appearance, I've looked at user-modify as another legacy feature originating in early version of CSS-UI[1] that has some amount of browser support, and might deserve a specification.

However, my personal conclusion is that we should not be standardize it, and I'd like to hear whether the csswg agree.

Here are my reasons:

1) It is only supported in Webkit/Blink. Despite what MDN claims[2], Mozilla does not have an implementation [3], and despite some rumors here and there on the web[4], neither does IE. So there isn't a major argument that it is needed for compat reasons.

2) It goes against the idea of the separation of concerns: this is tightly coupled with other things in html and js, not with other things in css. CSS-UI does have a few things that are arguably not stylistic, for example 'nav-*' or 'resize', or user-select, but these do have a stronger coupling with other things in a stylesheet. user-modify is more strongly coupled with the content and with js than it is with css.

3) Having this as a CSS property does not enable anything you cannot already do in HTML with contenteditable. contenteditable takes both a ''false'' and ''true'' value, matching ''user-modify:read-only'' and ''user-modify:read-write'', and even takes ''inherit'', so we're not even missing inheritance. Webkit does have an extra value (read-write-plaintext-only), but there's no reason that couldn't be a value of contenteditable, so that's not a justification for having this feature in CSS.

5) Having this as a CSS property suggests you could use it on non HTML documents (SVG, arbitrary XML...), but the processing model for contenteditable is defined in terms that are only meaningful in an HTML document, so it cannot be applied elsewhere as is. Defining a generic mechanism in CSS that would apply to any language sounds hard, and if CSS just defers the meaning to the host language, I don't really see what it is bringing to the table.

6) Using it in a user style sheet doesn't seem like it would enable anything useful. There's no strong requirement that css properties have to be useful in user stylesheets, but if it had been useful, it would have been a hint that having it as a property could be a good match.

In my mind, the only nice thing about it compared to contenteditable is that you can use selectors to place it, and selectors are a neat tool. But since contenteditable is unlikely to be used without JS (to use the edited content) and JS has querySelector() and friends, you can use selectors with contenteditable anyway, so I am not convinced this matters.

This isn't to say that contentEditable is bug-free or completely figured out. Far from it. But I believe standardization and implementation effort would be much better spent on contentEditable than on user-modify, 

- Florian

[1] http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-modify
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-user-modify
[3] http://logs.csswg.org/irc.w3.org/css/2015-04-01/#e538914
[4] http://stackoverflow.com/questions/22226868/contenteditable-v-s-user-modify
Received on Thursday, 30 April 2015 15:18:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC