meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: 'CSS' Category

Subgrids Considered Essential

Grid layout is a pretty darned fantastic thing.  I’ve been digging into it as I write the grid layout chapter of CSS:TDG4e, and there are more things in here than have been dreamt of in our layout philosophies.  One of the things I’ve recently come to realize is the power and necessity of subgrids.

To understand why, let’s explore a use case, which you can see in various forms on this test page.  I cribbed this use case pretty directly from Fantasai, but I’m going to be analyzing it a little differently.  The basis is a form with the various fields and labels in unordered list items, to help with accessibility and to be basically readable and usable if the CSS somehow fails to be applied.  The markup looks like this:

<form method="post" action="script.cgi">
  <ul>
    <li><label for=name>Name:</label>
        <input id=name name=name></li>
    <li><label for=email>Email:</label>
        <input id=email name=email type=email></li>
    <li><label for=tel>Telephone:</label> 
        <input id=tel name=tel type=tel></li>
    <li><label for=url>Homepage:</label>
        <input id=url name=url type=url></li>
    <li><label for=bday>Birthday:</label>
        <input id=bday name=bday type=date></li>
  </ul>
</form>

The basic form with no grids.

Ideally, we’d like the form fields to all line up into a column, and the labels to be in another column.  Furthermore, we’d like the label column to be only as wide as the widest label’s element box, and no more; the rest of the grid can be taken up by the input column.

This seems like a case tailor-made for grid layout, but there’s a problem.  Because grid items are only ever the child elements of a grid container, we can’t just apply a grid to the ul element and go from there.  Instead, we have to make each li element a grid container, in order to make each label and input element a grid item.  But that means each list item’s grid affects its children, with no reference to the other list items’ grids.  We can write the template we want, like so:

form ul li {display: grid;
  grid-template-columns: [start label] max-content [input] 1fr [end];}

Each list item a grid, but to what end?

That will get us a result almost precisely as if we’d applied no grids at all.  The only difference is that the input elements will all be as wide as their columns, according to the CSS Grid specification.  Chrome fails to do this last bit correctly, whereas Firefox Nightly gets it right, but otherwise the layout is essentially the same.  You can see this in the #form1 example on the test page.  (Remember, you have to have a current grid-supporting browser for the examples to correspond to what I’m talking about here.)

We can get closer to our goal by experimenting with a fixed-width grid column for the labels, figuring out the width of the widest label, and then just making all the label columns be that wide.  That would be written something like this:

form ul li {display: grid;
  grid-template-columns: [start label] 7em [input] 1fr [end];}

Using fixed-width columns to simulate a single column.

That works pretty well so long as none of the labels ever change—if a label is added (or edited) to be wider, it will wrap to multiple lines.  Alternatively, if the longest label is dropped or edited to be shorter, the label column won’t resize down.  It will just stay the same dumb fixed width until someone hand-adjusts it.  And honestly, at that point I may as well be using flexbox, which would do this version of the layout just as well, and would be more widely supported for the near to intermediate future.  At any rate, you can see the grid version of this in the #form2 example on the test page.

But what if we could set a grid on the ul element, and then make all the li elements grids that use their parents’ grid for the layout of their children?  That’s exactly what subgrids do.  This is the solution we’ve been seeking, in basic form:

form ul {display: grid;
  grid-template-columns: [start label] max-content [input] 1fr [end];}
form ul li {display: grid; grid: subgrid; grid-column: start / end;}

Here the list items establish grid containers, thus making the label and input elements into grid items like before, but are stretched across the two columns of the ul while using those very grid lines for laying out their child elements, plus those children influence the placement of their grandparent’s grid lines.  Thus, we can specify things like max-content for the label column size and have it Just Work™.

Or it would Just Work™, except that as I write this, none of the grid implementations have subgrid support.  Authors who want to create the kind of layout we’re after have to compromise in one way or another—either by faking the content-sizing with a fixed-width column, or by stripping down the markup until there’s barely anything left—thus sacrificing accessibility, progressive enhancement, and general best practices, as Fantasai illustrated in her article.

You can probably see a lot of other ways in which subgrids would be useful.  Take defining a full-page grid, the kind with a bunch of regularly repeating grid lines onto which various elements can be attached, like this one or this one.  In this scenario, being able to designate each section of the page a subgrid would let you have all the pieces inside that section participate in, and lay out in relation to, the overall page grid.  Without subgrids, you’d either have to make every element you want to lay out a child of the body element (or whatever you used to create the page grid), or you’d have to recreate segments of the page grid in each nested grid, and give up any hope of columns that can flex with the contents of multiple page sections.  Neither solution is appealing.

This is why I’ve come to the same conclusion other grid experts (like Rachel) already have: subgrids are a major component of grid layout, and should be a part of any grid layout implementation when it emerges from developer-preview status.  If that means delaying the emergence of grids, I think it’s worth it.

I say that because our field has a tendency to glom onto the first iteration of a technology, learn it inside out, hack around its limitations, and then ignore any future improvements unless somehow forced to do so.  If grid layout is released without subgrid support, we’re risking shoving subgrids into the back of the author-practices cupboard for a long time to come.  And along with it, potentially, grids themselves.  The frustration of trying to build layouts without subgrids will quickly become overwhelming for all but the simplest cases, leading authors to try and then discard grids as a serious tool.

First impressions matter.  CSS itself suffered for years from the initial impressions designers formed of “boring, boxy” layouts, and it still suffers from the handicap of being a presentation system without a layout engine at its core.  Grid layout is the first serious candidate to fill that hole in the past two decades, and I don’t want to see them hamstrung from the outset.  Subgrids are essential to the adoption of grids.  I hope they’ll be implemented as soon as possible, and before grids are pushed into public release channels.

CSS:TDG Update

It’s time for a semi-periodic update on CSS: The Definitive Guide, 4th Edition!  The basic news is that things are proceeding, albeit slowly.  Eight chapters are even now available as ebooks or, in most cases, print-on-demand titles.  Behold:

  • CSS and Documents, which covers the raw basics of how CSS is associated with HTML, including some of the more obscure ways of strapping external styles to the document as well as media query syntax.  It’s free to download in any of the various formats O’Reilly offers.
  • Selectors, Specificity, and the Cascade, which combines two chapters to cover all of the various Level 3 selector patterns as well as the inner details of how specificity, inheritance, and cascade.
  • Values, Units and Colors, which covers all the various ways you can label numbers as well as use strings.  It also takes advantage of the new cheapness of color printing to use a bunch of nice color-value figures that aren’t forced to be all in grayscale.
  • CSS Fonts, which dives into the gory details of @font-face and how it can deeply affect the use of font-related properties, both those we use widely as well as many that are quickly gaining browser support.
  • CSS Text, which covers all the text styles that aren’t concerned with setting the font face—stuff like indenting, decoration, drop shadows, white-space handling, and so on.
  • Basic Visual Formatting in CSS, which covers how block, inline, inline-block, and other boxes are constructed, including the surprisingly-complicated topic of how lines of text are constructed.  Very fundamental stuff, but of course fundamentals are called that for a reason.
  • Transforms in CSS, which is currently FREE in ebook format, covers the transform property and its closely related properties.  2D, 3D, it’s all here.
  • Colors, Backgrounds, and Gradients, which covers those three topics in FULL GLORIOUS COLOR, fittingly enough.  Curious about the new background sizing options?  Ever wondered exactly how linear and radial gradients are constructed?  This book will tell you all that, and more.

Here’s what I have planned to write next:

  • Padding, Borders, Outlines, and Margins — including the surprisingly tricky border-image
  • Positioning – basically an update, with new and unexpected twists that have been revealed over the years (case in point)
  • Grid Layout – though this is coming faster than many of us realize, I may put this one off for a little bit while we see how browser implementations go, and find out what changes happen as a result

My co-author, Estelle, has these three chapters/short books currently in process:

  • Transitions
  • Animations
  • Flexbox

Beyond those 14 chapters, we have eight more on the roster, covering topics like floating, multicolumn layout, shapes, and more.  CSS is big now, y’all.

So that’s where we are right now.  Our hope is to have the whole thing written by the middle of 2016, at which point some interesting questions will have to be answered.  While most of the book is fine in grayscale, there are some chapters (like Colors, Backgrounds, and Gradients) that really beenfit from being in color.  Printing a 22-chapter book in color would make it punishingly expensive, even with today’s drastically lower cost of color printing.  So what to do?

Not to mention, printing a 22-chapter book is its own level of difficulty.  Even if we assume an average of 40 pages a chapter—an unreasonabnly low figure, but let’s go with it—that’s still a nine hundred page book, once you add front and back matter.  The binding requirements alone gets us into the realm of punishingly expensive, even without color.

Of course, ebook readers don’t have to care about any of that, but some people (like me) really do prefer paper.  So there will be some interesting discussions.  Print in two volumes?  Sell the individual chapter books in a giant boxed set, Chronicles of Narnia style?  We’ll see!

Gradient Flags

With the news today of the Supreme Court’s decision in Obergefell v. Hodges, and my recent completion of the part of CSS:The Definitive Guide that deals with gradients, I thought I’d create a couple of flags using linear gradients.

First, I’ll define the basic box of the flags.  The dimensions are the same as those specified for the U.S. flag, 1:1.9.  I added a couple of box shadows for visual constrast with the background.

div {height: 10em; width: 19em; margin: 3em;
    box-shadow: 0 0 0.5em rgba(0,0,0,0.25),
        0.4em 0.6em 0.5em rgba(0,0,0,0.25);}

Okay, with that set, first up is what’s often called the pride flag, which is to say the “rainbow flag”.  There’s an interesting history to the design of the flag, but I’m going to stick with “the six-color version popular since 1973”, as Wikipedia puts it.

For such a flag, we just need color stripes with hard stops between them.  That means putting the color stops right up against each other, like so:

div#rainbow {
    background: linear-gradient(180deg,
        red 0%, red 16.7%, 
        orange 16.7%, orange 33.3%,
        yellow 33.3%, yellow 50%, 
        green 50%, green 66.7%, 
        blue 66.7%, blue 83.3%, 
        purple 83.3%, purple 100%);
}

The first red 0% isn’t really necessary, nor is the last purple 100%, but I left them in for the sake of consistency.  You could remove them both in order to make the CSS a little smaller, and still get the same result.  I decided to go from red to purple, as the spectrum is usually described, which meant having the gradient ray point from top to bottom.  Thus 180deg, although to bottom would be completely equal in this case.

Now for the US flag.  In this case, things get a little more interesting.  I’ll note right up front that I’m not going to put in any stars, in order to keep this simple and gradient-focused, and yet it’s still interesting.  We could use a repeating linear gradient, like so:

repeating-linear-gradient(180deg,
    #B22234, #B22234 0.77em, white 0.77em, white 1.54em)

That would then cause each red-white pair of stripes to repeat vertically forever.  Because the specified stripes are manually calculated to be 1/13th of the height of the overall flag (10em), they’ll just fit like they should.

The problem there is that if the overall flag size ever changes, like if the height and weight are converted to pixels, the stripes will get out of sync with the dimensions of the flag.  Fortunately, we don’t have to rely on ems here; we can use percentages.  Thus:

repeating-linear-gradient(180deg,
    #B22234, #B22234 7.7%, white 7.7%, white 15.4%)

Ta-da!  The stripes are the right sizes, and scale with any changes to the height and width of the flag, and repeat as required.

That’s all well and good, but we still need the blue canton (as it’s called).  Since the canton will be on top of the stripes, it actually needs to come first in the comma-separated value list for background-image.  That gives us:

background-image:
    linear-gradient(0deg, #3C3B6E, #3C3B6E),
    repeating-linear-gradient(180deg,
        #B22234, #B22234 7.7%, white 7.7%, white 15.4%);

Wait.  A blue-to-blue gradient?  Well, yes.  I want a consistent blue field, and one way to create that is a gradient that doesn’t actually grade.  It’s a quick way to create a solid-color image that can be sized and positioned however we like.

So, now we size and position the canton.  According to the official design specifications for the flag, the canton is the height of seven stripes, or 53.85% the height of the overall flag, and 40% the width of the flag.  That means a background-size of 40% 53.85%.  The stripes we then have to size at 100% 100%, in order to make sure they cover the entire background area of the flag.  Finally, we position the canton in the top left; the stripes we can position anywhere along the top. so we’ll leave them top left as well.

The final result:

div#usa {
    background-image:
        linear-gradient(0deg, #3C3B6E, #3C3B6E),
        repeating-linear-gradient(180deg,
            #B22234, #B22234 7.7%, white 7.7%, white 15.4%);
    background-size: 40% 53.85%, 100% 100%;
    background-repeat: no-repeat;
    background-position: top left;
}

And if you, like Bryan Fischer, believe that morally speaking “6/26 is our 9/11”, you can move the canton from top left to bottom left in order to invert the flag, which is permitted “as a signal of dire distress in instances of extreme danger to life or property”.

(Of course, it’s a lot easier to do that with background positioning since I didn’t include the stars.  If the stars were there, then we’d have left the canton’s position alone and done a rotateX() transform instead.)

So, there you go: two gradient flags.  You can see both (along with the “distress” variant) on this test page.  If you’ve any desire to use any or all of them, go ahead.  No copyright, trademark, patent, etc., etc. is asserted, implied, etc., etc.  I just wanted to have a little fun with gradients, and thought I’d share.

Friday Figure

Just for fun, and maybe for a little bit of edification, I present to you one of the figures from the chapter on color, backgrounds, and gradients I’ve just finished writing for CSS: The Definitive Guide, 4th Edition.

This figure is (at the moment) captioned “Very, very tall ellipses”; it’s a diagram of what happens if you create a radial gradient with no horizontal sizing.  (Whether you also have vertical sizing is actually irrelevant.)  The ellipses all get so incredibly tall that you only see the sides at their most vertical, which results in the appearance of a mirrored horizontal linear gradient.  This is of course explained in more detail in the chapter, and builds on a whole lot of previous text.

I had a much simpler version of this figure before, and shared it with Sara Soueidan, who had some very smart feedback that helped me get to what you see above.  The figure was finished not too long before i posted it; once it was done, I realized really liked the look, so decided on the spur of the moment to post it.  Thus the late-Friday timestamp on the post.

While the figure is a PNG, it’s actually a screenshot of an HTML+CSS file displayed in a browser—Safari, in this particular case, though most are done in Firefox.  All of the figures in the book will be created using HTML+CSS whenever possible.  Doing so lets me make sure I understand what I’m illustrating, and also allows me to change the look and arrangement of figures without too much difficulty.

So that’s fun with edge cases for this Friday.  If people like it, or more likely I just feel like doing it, I’ll post more in the future.

Run, Salmon, Run

I was recently asked on Twitter about the status of the fourth edition of CSS: The Definitive Guide.  A fair question, given how long the project has lain dormant!  I have two things to announce on that front.

The first is that I’m really excited to say that Estelle Weyl has joined me as co-author for the fourth edition.  We’re working in parallel, tackling individual chapters and doing technical review of each other as we work.  Sharing the load, especially with someone as sharp and knowledgable as Estelle, will help get chapters out faster, and the overall book done sooner.

The second is that writing is once again underway, with four chapters in process.  I’ve got the transforms chapter done, and the backgrounds and gradients (and maybe foreground colors too) chapter almost done.  Estelle is nearing the end of transitions and animations, with flexbox up next.  What comes after that for each of us is a little bit up in the air, though I’ll probably tackle basic visual formatting next.  Unless I get distracted by something more interesting, of course—truth be told, I’ve been eyeing grid layout with some covetousness in my heart.

So, the book is once again underway, and actually has been for a little while now.  I can’t say with certainty when we’ll be done and ready to compile everything into the Doorstop Edition, but we’re pushing for this year or early next.

As an offshoot of this renewed push, I’ve been expanding and revising my CSS test files so that I can check my understanding of the specification, as well as test the fine details of browser support.  Over the holidays I decided, more or less on a whim, to commit the whole kit ‘n’ kaboodle to Github.  There’s no license and no readme, mostly because I didn’t think to establish either when I set up the repository.  Sorry, I guess?  In any case, I regard the CSS in the tests to be public domain, but the actual content (whether inline or replaced) of the HTML files may or may not be, so a single license would have been hard to assert anyway.  I mostly put the files up there as a form of open backup, and also to smooth out the process of managing updates to the tests between my local machine and meyerweb.  Feel free to make use of the tests for your personal education, though!

rebeccapurple

I have been made aware of the proposal to add the named color beccapurple (equivalent to #663399) to the CSS specification, and also of the debate that surrounds it.

I understand the arguments both for and against the proposal, but obviously I am too close to both the subject and the situation to be able to judge for myself.  Accordingly, I let the editors of the Colors specification know that I will accept whatever the Working Group decides on this issue, pro or con.  The WG is debating the matter now.

I did set one condition: that if the proposal is accepted, the official name be rebeccapurple.  A couple of weeks before she died, Rebecca informed us that she was about to be a big girl of six years old, and Becca was a baby name.  Once she turned six, she wanted everyone (not just me) to call her Rebecca, not Becca.

She made it to six.  For almost twelve hours, she was six.  So Rebecca it is and must be.

Kat and I are deeply touched by all the caring and support from the community, and this proposal does mean a lot to me personally.  It will always mean that, even if the proposal is ultimately declined.  I always thought “it’s an honor to have been nominated” was a pleasant spin on sour grapes, but it’s not.  It really is an honor, regardless of the outcome, even if it is an honor I wish nobody had had cause to think of in the first place.

Thank you all.  For everything.


Update 22 Jun 14: the proposal was approved by the CSS WG and added to the CSS4 Colors module.  Patches to web browsers have already happened in nightly builds.  (I’m just now catching up on this after the unexpected death of Kat’s father early Saturday morning.)

Guidepost

As a followup to the recent public-speaking post, I want to talk about what’s happening with CSS: The Definitive Guide, 4th Edition.  So I will!

As many of you know, O’Reilly and I have been trying a new serial publication approach in which pieces of the book are released as they’re finished, generally at the ratio of one chapter per “pre-book”.  There are now five such books covering the first six chapters of the final book:

  • CSS and Documents, which covers the raw basics of how CSS is associated with HTML, including some of the more obscure ways of strapping external styles to the document as well as media query syntax.  It’s free to download in any of the various formats O’Reilly offers.
  • Selectors, Specificity, and the Cascade, which combines two chapters to cover all of the various Level 3 selector patterns as well as the inner details of how specificity, inheritance, and cascade.  It’s $4.99 to download, $9.99 to get on paper, and $10.99 to get both.
  • Values, Units and Colors, which covers all the various ways you can label numbers as well as use strings.  It also takes advantage of the new cheapness of color printing to use a bunch of nice color-value figures that aren’t forced to be all in grayscale.  $2.99 to download, $7.99 to print, $8.79 for both.
  • CSS Fonts, which dives into the gory details of @font-face and how it can deeply affect the use of font-related properties, both those we use widely as well as many that are quickly gaining browser support.  $5.99 to download, $7.99 to print, $8.79 for both.
  • CSS Text, which covers all the text styles that aren’t concerned with setting the font face—stuff like indenting, decoration, drop shadows, white-space handling, and so on.  $3.99 to download, $4.99 to print, $5.49 for both.

If you’re curious to know what other people think of these pre-books, all of the above except for “CSS Documents” and “CSS Fonts” have some customer reviews; “CSS Fonts” was recently reviewed by Virginia DeBolt.  If anyone who already has one wants to leave a review here in the comments, that’s fine too, though I’ll probably ask you to submit said reviews over at O’Reilly.

Given that all those are out, what’s next?  If I were to go by final-book-table-of-contents order, the next chapter would be “Basic Visual Formatting”, but I’m not going to do that, which is one of the big advantages of this approach.  Instead, my next topics are going to be transforms, transitions, and animations, and then flexbox.  Of course, all such plans are subject to change, but those are the topics I really want to do next, and they’re probably the most relevant topics to be talking about right now.

Given everything happening in my family’s life right now, I’m not going to try to commit to a specific schedule, because I might have to drop everything at next to notice at random.  All I can say is that I’ll be getting them out as soon as I can.

Resurrected Landmarks

It was just last week, at the end of April, that CERN announced the rebirth of The Very First URL, in all its responsive and completely presentable glory.  If you hit the root level of the server, you get some wonderful information about the Web’s infancy and the extraordinary thing CERN did in releasing it, unencumbered by patent or licensing restrictions, into the world, twenty years ago.

That’s not at all minor point.  I don’t believe it overstates the case to say that if CERN hadn’t made the web free and open to all, it wouldn’t have taken over the net.  Like previous attempts at hypertext and similar information systems, it would have languished in a niche and eventually withered away.  There were other things that had to happen for the web to really take off, but none of them would have mattered without this one simple, foundational decision.

I would go even further and argue that this act infused the web, defining the culture that was built on top of it.  Because the medium was free and open, as was often the case in academic and hacker circles before it, the aesthetic of sharing freely became central to the web community.  The dynamic of using ideas and resources freely shared by others, and then freely sharing your own resources and ideas in return, was strongly encouraged by the open nature of the web.  It was an implicit encouragement, but no less strong for that.  As always, the environment shapes those who live within it.

It was in that very spirit that Dave Shea launched the CSS Zen Garden ten years ago this week.  After letting it lie fallow for the last few years, Dave has re-opened the site to submissions that make use of all the modern capabilities we have now.

It might be hard to understand this now, but the Zen Garden is one of the defining moments in the history of web design, and is truly critical to understanding the state of CSS before and after it debuted.  When histories of web design are written—and there will be—there will be a chapters titled things like “Wired, ESPN, and the Zen Garden: Why CSS Ended Up In Everything”.

Before the Zen Garden, CSS was a thing you used to color text and set fonts, and maybe for a simple design, not for “serious” layout.  CSS design is boxy and boring, and impossible to use for anything interesting, went the conventional wisdom.  (The Wired and ESPN designs were held to be special cases.)  Then Dave opened the gates on the Zen Garden, with its five utterly different designs based on the very same document…and the world turned.

I’m known to be a history buff, and these days a web history buff, so of course I’m super-excited to see both these sites online and actively looked after, but you should be too.  You can see where it all started, and where a major shift in design occurred, right from the comfort of your cutting-edge nightly build of the latest and greatest browsers known to man.  That’s a rare privilege, and a testimony to what CERN set free, two decades back.

August 2016
SMTWTFS
July  
 123456
78910111213
14151617181920
21222324252627
28293031  

Archives

Feeds

Extras