CSS Pocket Reference: The Cutting Room
Published 13 years, 8 months pastI just shipped off the last of my drafts for CSS Pocket Reference, 4th Edition to my editor. In the process of writing the entries, I set up an ad-hoc test suite and made determinations about what to document and what to cut. That’s what you do with a book, particularly a book that’s meant to fit into a pocket. My general guide was to cut anything that isn’t supported in any rendering engine, though in a few cases I decided to cut properties that were supported by a lone browser but had no apparent prospects of being supported by anyone else, ever.
For fun, and also to give fans of this or that property a chance to petition for re-inclusion, here are the properties and modules I cut. Think of it as the blooper reel, which can be taken more than one way. I’ve organized them by module because it’s easier that way.
- The backface-visibility property from the 3D Transforms module. This is one I’m already reconsidering, but I haven’t found any indication that anyone besides Webkit will be picking it up in the near future. Still, I did document the rest of the 3D Transforms module so I may add this back in during the tech review stage.
rotationandrotation-pointfrom the CSS3 Box module. These have been effectively replaced by the 2D Transforms module, but the Box module hasn’t been updated since that happened.- Everything in the Flexible Box Layout module. There are, as of now, just too many sections bearing notes, warnings, questions, and general feelings of instability and future change for me to feel comfortable including the properties from this module. I’m probably going to catch some flak for that.
- grid-columns and grid-rows from the Grid Positioning Module Level 3, which effectively means means excluding the entire module. Some day maybe I’ll write a separate pocket reference just for the various CSS layout systems.
- font-stretch. Its continued exclusion saddens me, because I am exactly the sort of sheep-stealing lowlife who would programmatically stretch and compress font faces and like it, but so far as I can tell nobody’s supporting the property. Alas.
- Basically, the entirety of the Generated Content for Paged Media module.
- The Behavioral Extensions module, which means the binding property as well as the
:bound-elementpseudo-class. - All the properties in CSS Marquee module. I’d love to see someone make a compelling case for re-instating them.
- The following properties from CSS Text Level 3:
hanging-punctuation,punctuation-trim,text-align-last,text-emphasis-position,text-emphasis-style,text-emphasis,text-justify,text-outline,text-wrap,white-space-collapsing, andword-break. - The following properties from the Basic User Interface module, dated 2004:
appearance,icon,nav-down,nav-left,nav-right,nav-up, andnav-index. - The Hyperlink Presentation module, dated 2004.
- The Presentation Levels module, dated 2003.
- move-to and crop from the CSS3 Generated and Replaced Content module, dated 2003.
- The Line module, dated 2002 and bearing my name for no reason I can recall. The one property listed there which I kept is
vertical-align, and I just used the CSS2.1 definition.
After all that, I imagine you’re going to laugh uproariously when I tell what I did include: paged and aural properties. I know — I’m kind of poleaxed by my own double standard on that score. I included them for historical reasons (they’ve long been included) and also because they’re potentially very useful to a more accessible future. Besides, if we run out of pages, they’re in their own section and so very easy to cut.
I’m pretty sure I listed everything that I explicitly dropped, so if you spot something that I absolutely have to reinstate, here’s your chance to let me know!
Comments (14)
I’d love to see
backface-visibilityadded back in. When its value is set tohidden, it can suppress nasty flickering on certain kinds of transitions.I’m looking forward to picking up a copy when it comes out! I’d love to hear a little more about why flexbox didn’t make the cut. I’ve read a lot of posts about the benefits it offers, and I’m seriously considering using it on the next site I make. Is your reluctance to include it purely an issue of difficulty with documentation, or more serious concerns about whether people should use it in the first place?
I believe there is activity on the binding front to create a better version of Mozilla’s XBL binding language[1]. There is also the
-moz-bindingproperty[2] and-webkit-bindingalthough webkit version is disabled by default.Interestingly there is also a JavaScript polyfill for XBL[3].
[1] http://www.w3.org/TR/2006/WD-xbl-20060907/
[2] https://developer.mozilla.org/en/CSS/-moz-binding
[3] http://code.google.com/p/xbl/
I think that’s a great idea!
I assume you know Flexible Box Layouts just got updated:
http://www.w3.org/TR/2011/WD-css3-flexbox-20110322/
THIS is why I love your work and follow your posts/tweets religiously! Your “cuts” help guide me toward things that I should REALLY study and learn rather than spinning my wheels with code that is not practical. Thank you, Eric!!
Not meaning to give you flak, but yeah, I do consider the Flexible Box Layout module potentially really important if the big webOS push from HP gains any steam at all as webOS 3.0 devices start hitting the market this year… their new framework, Enyo, bases most of its layout stuff on that module.
Great feedback, Erik—that’s really useful to know. Thanks!
Scott, it’s kind of both but mostly the difficulty in documentation, which is to say accurate documentation. Things are changing quite a bit, and quite a bit still seems to be unresolved. If you look at the draft to which Bruce and I both pointed, it has a lot of red ISSUE text. To pick one representative sample: “The precise syntax of the
flex()function is still under discussion.” If something that basic still isn’t settled, the draft is too unstable to document right now. I wish it were otherwise, but there you have it.Hopefully this clarifies my reasoning for you, Rob. I’ll add that Enyo’s dependence on a specification that’s changing so radically (and still so unformed) seems like a potential problem for the framework (and HP).
Couldn’t marquee be rolled into CSS transforms & animation? Seems like a natural fit and I’m sure it can already be done with transform / animation.
I’ve always found it odd that font-stretch wasn’t implemented from day one. Computers in the old greenscreen monitor days had it back then. Fonts could be either twice as wide, or half as thin. It was simple to just double or halve the pixels to get the effect. Surely this would also be possible on today’s pixel-driven screens? But alas not. Maybe it’s a lot more complicated, due to the way fonts are rendered or something. Pity, really. (And yet faux italic and bold fonts are possible for typefaces that don’t have those options.)
the 4th edition will release when ???
The
nav-*properties are supported by Opera. I’m not as pessimistic as you about their future in other browsers. They are quite useful sometimes if you have to work withfloatandposition.My question is not which parts of an incomplete specification, CSS3, you will include, but whether you will fully document CSS2.1 as it has been ratified as a W3C Recommendation as of June 7, 2011.
Right now, I am searching for a book that accurately reflects the final version of the CSS2.1 specification rather than yet another book on the incomplete CSS3 specification.
Sounds like a great book, Dr. Neill! Let us know how your search goes.