- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Sep 2016 01:57:08 +0000
- To: public-css-archive@w3.org
> Blink and WebKit do not support auto up to today. They do, just with the not terribly useful behavior of always making it compute to `text`. Proof: http://jsbin.com/ciwema/edit?html,css,output > So may I understand you think it's possible but prefer to keep the current way to express per-value inheritance? As I said above, there is no actual per value inheritance. Only computed value that depends on the parent. Yes, the result is that in some situations, it kind of does the same as inheritance, and in others, it does not, so explaining the effects by saying "it behaves sort of like inheritance, except that...." sounds fine for teaching purposes, but there is no new concept being introduced, and I'd prefer that we used the precise terminology when discussing the mechanics or the proposal. As for whether it is possible to use the two properties (possibly with the shorthand), I did think so, but I've changed by mind (see https://github.com/w3c/csswg-drafts/issues/336#issuecomment-247206827). If you have a contenteditable element (or an element that's editable for other reasons) that's a child of a user-select:none element, in all browsers: - the selection is contained in the editable element, even in browsers that don't have an excplict "contain" value on user-select - the editable element and its descendants are selectable In the dual property approach, the second point would not be true. The spec is written to be compatible with everybody's existing behavior in that respect, and that change would break this. I'd argue this is for the worse, and not web compatible. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/336#issuecomment-247211627 using your GitHub account
Received on Thursday, 15 September 2016 01:57:18 UTC