Re: Intent to unship: -moz-user-input: disabled / enabled
On 02/14/2018 06:00 PM, L. David Baron wrote: On Wednesday 2018-02-14 09:25 +0100, Emilio Cobos Álvarez wrote: Hi, In bug 1405087 I intend to remove the "enabled" and "disabled" values of the -moz-user-input property. Do other browser engines implement the 'user-input' property (prefixed or unprefixed)? Which values do they support? No other browser implements this property as far as I can tell, either prefixed or unprefixed. I've tested Edge 16 (via BrowserStack), WebKit Nightly via Epiphany's preview, and Chromium 63. The original spec for this property was: https://www.w3.org/TR/2000/WD-css3-userint-2216#user-input which seems to only have: Values: none | enabled | disabled | inherit So it sounds like this would leave 'auto' and 'none', where 'auto' wasn't part of the original spec and 'none' was. I'd be happy to try removing the property entirely, but that seemed more risky since we have at least a bunch of internal usage for the "none" value. That being said, most of that internal usage comes from patches mentioning: https://bugzilla.mozilla.org/show_bug.cgi?id=82547 Which I'm not sure is relevant at all these days, probably not. That usage comes mostly from EditorOverride.css and contenteditable.css. If someone familiar with editor could take a look and confirm that they're not relevant anymore, we could try to remove the property entirely. -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: -moz-user-input: disabled / enabled
On Wednesday 2018-02-14 09:25 +0100, Emilio Cobos Álvarez wrote: > Hi, > > In bug 1405087 I intend to remove the "enabled" and "disabled" values of the > -moz-user-input property. Do other browser engines implement the 'user-input' property (prefixed or unprefixed)? Which values do they support? The original spec for this property was: https://www.w3.org/TR/2000/WD-css3-userint-2216#user-input which seems to only have: Values: none | enabled | disabled | inherit So it sounds like this would leave 'auto' and 'none', where 'auto' wasn't part of the original spec and 'none' was. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: -moz-user-input: disabled / enabled
Hi, In bug 1405087 I intend to remove the "enabled" and "disabled" values of the -moz-user-input property. The reasoning for this is because they're slightly broken in presence of dynamic changes (see the bug), and their usage seems low / web-compat risk seems not too high. In particular, I could only a couple legit uses of -moz-user-input: disabled that weren't either commented out or broken (using "moz-user-input" instead of "-moz-user-input"). Of those uses, all of them were part of the jQuery iButton plugin: https://www.givainc.com/labs/ibutton_jquery_plugin.cfm Which I've verified works fine with my patches. -moz-user-input: enabled works exactly the same as -moz-user-input: auto, which is the default, and thus only changes behavior if it's specified under something that has -moz-user-input: disabled / none. Again, only legit use case of this I found (within a -moz-user-input: disabled / none element) was the mentioned jQuery plugin, which works just fine without those. If we happen to find web-compat fallout from this we can consider re-introducing them / aliasing them to the other values, I guess, and just remove our internal usage, but I think it's worth trying to remove them in light of the above. -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform