Time and time again I'm reading about a very interesting CSS property on MDN only to see that MDN considers some values it can take "experimental", recommends against using it in production and warns that its behavior may change in the future.
Two examples: width: max-content and display: contents.
What does it precisely mean that a property or value is 'experimental'? Is it a status given to such a keyword by MDN or is it an official status given to this keyword by an appropriate standarization body (W3C perhaps?)
Where can I find if MDN's warnings are not out-of-date? For example for max-content, MDN links to this standard document, but I can see no warnings about the experimental nature in the paragraph about max-content - perhaps the whole document MDN linked to is experimental?
Context: I'm asking because I'd dearly like to use both width: max-contents and display: contents, both seem to make my life so much simpler, and I'm wondering if (a) it's OK to use them, (b) I shouldn't use them, (c) I really really shouldn't use them?
Basically what this means is that the developers that make it so that CSS works are creating new functions that aren't available in every major browser and very-well could be removed as they continue to develop. Think of it as an alpha test of new CSS declarations. In theory, every CSS identifier was 'experimental' at some point and was then moved to 'stable.' Eventually if it falls out of favor, it turns to 'deprecated.'
You can find more info here: https://developer.mozilla.org/en-US/docs/MDN/Contribute/Guidelines/Conventions_definitions
Here is a site that allows you to see cross-browser compatibility as well: https://caniuse.com/
At the very beginning of your linked document (CSS Box Sizing Module Level 3
Editor’s Draft, 5 June 2019), there is this paragraph
[...]This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.[...].
So as long as a css property is only listed in the draft of the specification it has to be considered as experimental, as it is not even guaranteed that it will be finalized ever. Drafts have been completely rejected or had a major rewrite in the past if they were not practicable.
And if you look at this link https://www.w3.org/TR/css-sizing-3/ you can see that the current version of CSS Intrinsic & Extrinsic Sizing Module Level 3 is still W3C Working Draft, 22 May 2019.
[...]This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress[...].
So to figure out if a property or value is still experimental you need to check where it is defined and if those specs are final.
If those specs are final then the property/value is not experimental anymore and you only need to check if it is available in the browsers using e.g. caniuse.com
Related
I understood that while a W3C recommendation for a feature was still under development, it would often already have reference-implementations in browsers, but behind a vendor prefix or an experimental flag.
So it would be very clear in code that you're relying on a standard that might change.
Today I realised that this was not at all true. I checked my favourite example, position: sticky, and it seems that Firefox removed its experimental flag 2014, Chrome in 2017, and Edge directly introduced the feature un-prefixed in 2017.
Now the related standard CSS Positioned Layout Level 3 is still a Working Draft, implying there might still be changes until the official recommendation.
So I'm left with two questions:
On what indicator do browser vendors base their decision to remove vendor prefix or experimental flag?
Is there some formal state within the drafts that tells them (and us) that a specification can be considered stable enough for implementation?
It's mostly the other way around. A W3C spec can only become a recommendation when it has two complete, independent implementations. Officially, at least. Sometimes the rules are bent a bit.
It matters less than you think. Once there are interoperable implementations for most of the browsers in current use, any variation of the specification from the implementations is normally considered as a bug in the specification, not in the implementations. So at that point the spec is effectively stable for that feature, regardless of its status as Draft, CR, PR, or Recommendation.
Browser makers talk between themselves and the spec writers to decide when they're going to implement something, and when they agree that their implementations are complete. The "Recommendation" status is just the final step, to tell web authors it's all good for them to use it.
Of course, only the most defensive of web authors will wait that long.
CSS3 allows specifying display-outside and display-inside values within a single display rule.
For example:
display: block flow;
display: inline table;
display: flex run-in;
The CSS MDN page doesn't say which browsers support this multi-keyword syntax.
Which browsers currently support CSS3's multiple keyword values for display, and what quirks are present (if any) among those that do support it?
EDIT (response to close votes):
I'm not asking for a recommendation or for someone to find an outside tool/resource.
The question's intent is to help me (and others) decide whether or not to use this CSS feature in code I write, based on how well-supported it is in current target platforms (browser engines), NOT to help me choose a browser (I already have all of them -- IE, Edge, Chrome, FF, Safari, and I develop and test against the most recent versions of all of them).
Basically, I'm asking the same question this answers for flexbox, but for a different CSS feature. I.e. What would the impact on my user base be if I were to use this CSS feature? (which depends on my app’s user base, but which anyone can answer for themselves given data on browser support for hr feature in question)
There are many examples of this type of question already on SO (I can provide in comments/discussion if interested).
There are no implementations of the multi-value version of display as currently defined in css-display-3.
The only features new to css-display-3 that are implemented (not including features defined in their own CSS modules, such as flex layout, grid layout and ruby layout) are display: contents and display: flow-root, but these are implemented as single keyword values, which means implementations do not currently recognize display: block flow-root despite recognizing display: flow-root.
Considering that css-display-3 is still undergoing major clarifications and even rewrites as of 2017, I wouldn't hold my breath on implementations anytime soon, especially since the current definition of display requires reimplementing the property altogether (namely, moving from single-value to multi-value while ensuring that existing values and legacy values continue to work as intended and don't break for existing sites), not to mention perhaps an overhaul of the CSS layout system depending on how it's currently being implemented, warts and all.
The W3C maintains an excellent list of all CSS properties, both current and proposed. Of the 115 properties marked as CSS 2.1, sixteen of these are not part of any CSS module (for level 3 and above). These are:
azimuth,
elevation,
line-height,
page-break-after,
page-break-before,
page-break-inside,
pitch,
pitch-range,
play-during,
richness,
speak-header,
speak-numeral,
speak-punctuation,
speech-rate,
stress,
volume
Now I'm aware of the W3C statement, from CSS Snapshot 2015 that states "Each module adds functionality and/or replaces part of the CSS2.1 specification. The CSS Working Group intends that the new CSS modules will not contradict the CSS2.1 specification: only that they will add functionality and refine definitions." However there seems to be no upgrade path or list of deprecated properties.
I'm pretty sure modern browsers, will, for backward-compatibility reasons, choose to honor the well-defined and stable CSS 2.1 properties. But someone (perhaps the folks in charge of a particular module) decided that the CSS 2.1 properties were clunky, hacks, or otherwise did not fit into the clean world of CSS 3 modules.
For example, I searched the CSS Speech Module looking to see whether speak-numeral (one of the missing 16) was mentioned. It wasn't, but I found speak-as which appears to capture the same functionality.
So the programming and programming-related questions here are:
Why are these 16 properties not marked deprecated?
Is there an "upgrading to CSS3" guide somewhere?
What is the appropriate strategy for new web applications? Do we continue to use these old properties until the module makes Recommendation status and/or they get better browser support? Is it a good idea to use both properties (old and new) in a style sheet?
Let's take one example, I suspect by far the most commonly used of those listed, line-height.
The CSS Inline Layout Module Level 3, Section 2. Line Heights and Baseline Alignment says
This section is being rewritten. Refer to section 10.8 of [CSS2] for
the normative CSS definition or the 2002 Working Draft if you want
pretty pictures. (But ignore the old text, half of it’s wrong. We’re
not specifying which half, that’s to be determined.) The CSS2
specification should be used as the guideline for implementation.
So it's not deprecated, it's just that the description from level 2.2 holds until such time that a level 3 definition can be written. Level 3 is huge, and work has to be prioritized. Line-height obviously works well enough for that priority to be low. No doubt, it will be addressed eventually.
The others are probably similar. Their level 2 definitions have simply not yet been superseded.
In CSS Text Decoration Module Level 3, there’s text-decoration-skip. It does magic like this:
This representation is allegedly produced by using text-decoration-skip: ink;. For web typography, it’d be great if descenders are no longer struck through by native underlining.
There’s an entry at CSS-Tricks and more recently also one on MDN. There, it says it’s “not on a standards track”. Is that right? The property is listed in the W3C Candidate Recommendation.
How can I use text-decoration-skip? Or when? Are there flags to enable it?
As someone said in the comments to the question, there's no saying when and how it will be implemented.
For reference anmd clarification, the origin article of the picture you posted isn't what the actual spec necessarily will look like, but a draft of what Marcin Wichary had in mind when tinkering with it. So don't make the mistake and consider that image a reference for the CSS3 output, as it may look entirely different when finally implemented.
I also can't tell you why MDN doesn't list it as a feature necessarily to be implemented, whether it's a decision of the development team not to implement it, or they just missed it. I can, however, tell you that they are correct in saying "This property has not yet been implemented in any modern browser."
As for browser support, take note of this comment in the CSS-Tricks article, linking to the folliowing image:
It's not only interesting because that's quite a dated browser (which of course didn't do this because of some CSS3 spec, but likely because they had the same basic idea), but also because that's likely what the property will look like when finally implemented.
While text-decoration-skip seems to have been “deferred to Level 4 to allow for major changes”, Chrome 64 (2018-01) and Firefox 70 (2019-10) implemented a close relative (applied by default), because “most other browsers are converging on supporting the simpler text-decoration-skip-ink property”, and it certainly does work:
u{font-size:444%;}
u:first-of-type{ text-decoration-skip-ink: none; }
u:last-of-type{ text-decoration-skip-ink: auto; }
<u>parapsychologists</u>
<br>
<u>parapsychologists</u>
Note that there’s even more cutting-edge text-decoration stuff, like text-underline-offset or text-decoration-thickness.
I've been using white-space and was happy with it. Still am. Then, I noticed that there's something called text-wrap too. I've seen somewhere on the internet that there's no browser support for the latter. However, it's not in the plans for the future nor is it deprecated (let alone obsolete).
So what's that for? Should I regard it in any way?
text-wrap was originally in CSS Text level 3. It has since been deferred to level 4. The difference between it and white-space is that white-space is changed to be a shorthand of two other properties, one of which is text-wrap. That's all you need to know for now; any other details are highly subject to change and simply not relevant at this point.
You can disregard text-wrap for now. W3Schools is correct in stating that no browser supports it at the moment. You can also continue using white-space as normal; its syntax will not change even once the newer version is implemented by browsers.