I 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.

rotation and rotation-point from 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.

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!

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-binding property[2] and -webkit-binding although webkit version is disabled by default.

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.

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).

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.)