CSS Pocket Reference: The Cutting Room

Published 12 years, 11 months past

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.

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)

  1. I’d love to see backface-visibility added back in. When its value is set to hidden, it can suppress nasty flickering on certain kinds of transitions.

  2. 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?

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

    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/

  4. Some day maybe I’ll write a separate pocket reference just for the various CSS layout systems

    I think that’s a great idea!

  5. I assume you know Flexible Box Layouts just got updated:
    http://www.w3.org/TR/2011/WD-css3-flexbox-20110322/

  6. 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!!

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

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

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

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

  11. the 4th edition will release when ???

  12. 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 with float and position.

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

  14. Sounds like a great book, Dr. Neill! Let us know how your search goes.

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>


if you’re satisfied with it.

Comment Preview