3 ms·

There are some good reasons for vendor prefixing. For instance, the 'user-select' property is implemented differently between in each prefix, so CSS styling sho

There are some good reasons for vendor prefixing. For instance, the 'user-select' property is implemented differently between in each prefix, so CSS styling should explicitly state which implementation it wants. These properties need to be standardized. But, we're going to start running into trouble if we start pushing to get rid of prefixes for unstandardized properties. https://developer.mozilla.org/en-US/docs/Web/CSS/user-select https://developer.mozilla.org/en-US/docs/Web/CSS/user-select

frivoal 11y ago
There were some good reasons behind the intent for vendor prefixing, but it was a flawed solution to a real problem. As vendor prefixed made it to production builds, we ended up not with experimental properties that we could still change willy nily, but with strangely named properties that we have to support forever (since content depend on them working correctly), and without even the benefit of being able to evolve the design of the unprefixed version anyway we like, since "best practices" mean that css authors very often writen the unprefixed property in their stylesheet along with the prefixed one for future proofing. What browsers are mostly doing (and the CSSWG is in the process of formalizing) is that experimental features should be included in nightly/preview/developer builds, but not in production builds (or be off by default, to be turned on via user settings). That way we can still experiment, but we don't use experiments in production, and avoid creating a legacy compat problem on things that were not meant to be permanent.
frivoal 11y ago
user-select does need some improvements in browsers, but this MDN page is somewhat out of date. It is now being standardized: https://drafts.csswg.org/css-ui-4/#content-selection https://drafts.csswg.org/css-ui-4/#content-selection Browsers haven't fully converged yet, but at least we're starting to see what they are likely to converge to.

frivoal 11y ago

There were some good reasons behind the intent for vendor prefixing, but it was a flawed solution to a real problem. As vendor prefixed made it to production builds, we ended up not with experimental properties that we could still change willy nily, but with strangely named properties that we have to support forever (since content depend on them working correctly), and without even the benefit of being able to evolve the design of the unprefixed version anyway we like, since "best practices" mean that css authors very often writen the unprefixed property in their stylesheet along with the prefixed one for future proofing. What browsers are mostly doing (and the CSSWG is in the process of formalizing) is that experimental features should be included in nightly/preview/developer builds, but not in production builds (or be off by default, to be turned on via user settings). That way we can still experiment, but we don't use experiments in production, and avoid creating a legacy compat problem on things that were not meant to be permanent.

frivoal 11y ago

user-select does need some improvements in browsers, but this MDN page is somewhat out of date. It is now being standardized: https://drafts.csswg.org/css-ui-4/#content-selection https://drafts.csswg.org/css-ui-4/#content-selection Browsers haven't fully converged yet, but at least we're starting to see what they are likely to converge to.