meyerweb.com

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

Archive: 'Tech' Category

Adding Backgrounds to Directly Loaded SVGs

My primary SVG viewer is Firefox.  This is partly because it’s always running, so the startup time is essentially zero.  It also allows me to directly inspect and modify elements of the SVG element through the Web Inspector, which can be handy.

But I’ve run into a problem more than once, which is that if I load an SVG file in Firefox, the browser window’s background defaults to white, and a lot of times I’m trying to view images that are partially or entirely white.  I started thinking that if there were a way to make the window background medium gray, that would solve the problem with rare downsides, since I can’t remember trying to view an all-medium-gray SVG.

After a question on Twitter and some ideas from Tibor Martini, I realized I could use Stylish to give the SVG files a background through CSS.  I didn’t want to select all SVGs, only those I was loading directly, so I tried this:

svg:root {background: gray;}

And it worked!  So I decided to make it more robust by doing a multicolor gradient, and grayscaling it on hover.  I couldn’t use filter because that would grayscale the whole image, rather than just the background, but that was easy to work around.  I ended up with this:

svg:root {background: linear-gradient(135deg, hsl(0,50%,60%), hsl(180,50%,40%));}
svg:root:hover {background: linear-gradient(135deg, hsl(0,0%,60%), hsl(180,0%,40%));}

Which works great!  Except that I discovered Firefox applies it to all SVGs, even those loaded into HTML documents via img.  SVGs apparently define their own roots, which I hadn’t expected, but I can see how it might make sense.  So I poked around in MDN until I came up with this:

@-moz-document url-prefix(file:) {
    svg:root {background: linear-gradient(135deg, hsl(0,50%,60%), hsl(180,50%,40%));}
    svg:root:hover {background: linear-gradient(135deg, hsl(0,0%,60%), hsl(180,0%,40%));}
}

And that’s exactly what I wanted.  If it’s useful to you, have at it.  Just paste that into a new Stylish rule in Firefox, and you should be good to go.

If you’re on Chrome, you can import the above into Stylish and create a new rule, but it hasn’t worked for me, and I’m not sure why not.  Removing :root didn’t fix it when I tried, and that shouldn’t matter anyway: I can see in Chrome’s user styles that svg:root is used and applied.  And my Stylish toolbar icon shows the rule is being applied.  It just doesn’t do anything I can see.  If anyone can figure out how to make it work, or explain why it can’t work, I’d love to know in the comments!

CSS: The Definitive Guide, 4th Edition

On Monday, July 3rd, as I sat in the living room of a house just a bit north of New York City, I pushed the last writing and editing changes to CSS: The Definitive Guide, Fourth Edition and notified the production department at O’Reilly that it was ready.

All twenty chapters, three appendices, and associated front matter are now in their hands.

It’s been a long and difficult journey to get here.  Back in 2011-2012, I started updating chapters and releasing them as standalone books, for those who wanted to grab specific topics early.  In mid-2013, I had to stop all work on the book, and wasn’t really able to get back into it until mid-2015.  At that point, I realized that several new chapters had to be added—for example, when I started out on this edition, Flexbox and Grid were pie-in-the-sky ideas that might or might not come to pass.  Feature queries weren’t a thing, back then.  Filters and masks and blend modes were single-browser at best, when I started out.  And forget about really complex list counters.

Now all those topics (and more!) have chapters, or at least major sections.  Had I not been delayed two years, those topics might not have made it into the fourth edition.  Instead, they’re in there, and this edition may well end up twice as long as the previous edition.

I also might not have brought on a co-author, the inestimable Estelle Weyl.  If not for her contribution in new material and her close, expert review of the chapters I’d already written, this book might have been another year in the making.  The Guide was always my baby, but I couldn’t be happier that I decided to share it with Estelle, nor prouder that her name will be on the cover with mine.

Speaking of major changes, I probably wouldn’t have learned AsciiDoc, nor adopted Atom as an authoring environment (I still use BBEdit for heavy-lift text processing, as well as most of my coding).  O’Reilly used to be a “give us your Word docs!” shop like everyone else, but that toolchain doesn’t really exist any more, from what I can tell.  In fact, the first few chapters I’d given them were in Word.  When I finally returned to writing, they had to give me those chapters back as AsciiDoc exports, so I could make updates and push them to O’Reilly’s internal repository.  The files I created to create figures in the book went into their own public repository, which I’ll get to reorganizing once the text is all settled and the figure numbers are locked in.  (Primary to do: create chapter lists of figures, linked to the specific files that were used to create those figures.  Secondary to do: clean up the cruft.)

As of this moment, the table of contents is:

  • Preface
  1. CSS and Documents
  2. Selectors
  3. Specificity and the Cascade
  4. Values, Units, and Colors
  5. Fonts
  6. Text Properties
  7. Basic Visual Formatting
  8. Padding, Borders, Outlines, and Margins
  9. Colors, Backgrounds, and Gradients
  10. Floating and Shapes
  11. Positioning
  12. Flexible Box Layout
  13. Grid Layout
  14. Table Layout in CSS
  15. Lists and Generated Content
  16. Transforms
  17. Transitions
  18. Animation
  19. Filters, Blending, Clipping, and Masking
  20. Media-Dependent Styling
  • Appendix A: Animatable Properties
  • Appendix B: Basic Property Reference
  • Appendix C: Color Equivalence Table

Disclaimer: the ordering and titles could potentially change, though I have no expectation of either.

I don’t have a specific timeline for release as yet, but as soon as I get one, I’ll let everyone know in a post here, as well as the usual channels.  I expect it to be relatively speedy, like the next couple of months.  Once production does their thing, we’ll get it through the QC process—checking to make sure the figures are in the right places and sizes, making sure no syntax formatting got borked, that kind of thing—and then it’ll be a matter of getting it out the door.

And just in case anyone saw there was news about O’Reilly’s change in distribution and is wondering what that means: you can still buy the paper book or the e-book from your favorite retailer, whether that’s Amazon or someone else.  You just won’t be able to buy direct from O’Reilly any more, except in the sense that subscribing to their Safari service gives you access to the e-book.  That does mean a tiny bit less in royalties for me and Estelle, since direct paper sales were always the highest earners.  Then again, hardly anyone ever bought their paper copies direct from O’Reilly, so honestly, the difference will be negligible.  I might’ve been able to buy an extra cup of coffee or two, if I drank coffee.

It feels…well, honestly, it feels weird to have finally reached this point, after such a long time.  I wish I’d gotten here sooner for a whole host of reasons, but this is where we are, and regardless of anything else, I’m proud of what Estelle and I have created.  I’m really looking forward to getting into your hands.

Gridded Headings v. Justified Headings

Amongst the reactions to Gridded Headings, Benjamin de Cock pointed out there’s another way to arrive at the same place I did.  Instead of this:

grid-template-columns:
    minmax(1em,1fr)
    minmax(min-content,max-content)
    minmax(1em,1fr);

…Benjamin pointed out one could instead do this:

justify-content: center;

That’s right: without explicitly specifying any grid columns, but just setting the grid items themselves to be centered, the same behaviors emerge.  Clever!

What’s interesting is that the behaviors are not precisely the same.  While mostly identical behaviors occur with either approach, there are a few subtle differences and a much different possibility space.  I’ll consider each in turn.

First, the differences.  First of all, the small gutters defined by the first and third grid column tracks—the ones defined to be minmax(1em,1fr)—aren’t present in the justify-content version.  This means the headings will jam right up against the edge of the grid container if things get narrow enough.

Side separation versus side smashing.  Grid on the left, justify-content on the right.

So we either need to re-establish them with grid-template-columns, which would seem to put us right back where we were, or else apply side margins to the heading and subheading.  Something like this:

div h2, div h3 {margin-right: 1rem; margin-left: 1rem;}

Either way, that side separation has to be defined (assuming you want it there).  Having to set those separations as margins feels a little clumsy to me, though not hugely so.  Doing all the sizing and separation in a single grid-template-columns declaration feels cleaner to me, though I admit that may be partly due to my current Gridfatuation.

There is another difference worth exploring.  If the content gets wider than the space available, the grid-template-columns approach means the content will overflow to the right (in LTR writing modes).  If it falls offscreen, it can be scrolled to read.  With justify-content: center, the content stays centered within the box, overflowing to both sides.  The content to the left may not be accessible via scrollbar.

How track sizing and content justification handle overspill.  Grid on the left, justify-content on the right.

So if you have a large headline containing a lengthy unhyphenated word, like “Kazakhstan” or “emoluments”, you might prefer one result over the other.

Beyond that, the further possibilities are a lot richer with Grid than with content justification.  Center-justifying the content means exactly that: the element boxes are centered.  So if you were interested in taking the heading and subheading, acting as an apparent unit, and shift them toward one side or another, this would be much easier to accomplish with Grid.

Suppose we want there to be three times as much space to one side of the headings’ column as the other.  Here’s what that would look like:

grid-template-columns:
    minmax(1em,1fr)
    minmax(min-content,max-content)
    minmax(1em,3fr);

That’s it.  One number changed, and the whole setup is offset from the center without losing the coherence of the original demo.

The same thing could likely be approximated with justify-content using side margins on the heading elements, but it wouldn’t be precisely the same, even with percentages.  fr is a very special beast, and permits very unique results.

The other major difference in possibilities is that with Grid, we can rearrange elements visually without ever touching the source.  Suppose we wanted to put the subhead above the heading in some layouts, but not others.  (Whether those different designs live on different pages or at different breakpoints, it really doesn’t matter.)  With Grid, that’s as simple as rewriting the grid template in a line or three of CSS.  The h2 remains ahead of h3 in the HTML.

With justify-content, you’d still have to write that same grid template, or else switch to flexbox and use flex-direction: column-reverse or some such.  That would work if you want to just switch the display order of two headings in a single column.  It tends to fall down for anything more demanding than that.

This is not to say Benjamin came up with a bad alternative!  I like it quite a bit, precisely because it has similar outcomes to my original idea, thus shedding light on creative ways Grid and content alignment can be combined.  But I like it even more for its differences, which shed even more light on how the two things operate.

In that combination of similarity and difference, I can sense an incredible range of capability, chock full of nuance and brimming with possibility.  There are going to be ways to put these things together that nobody has figured out yet.  I know I keep saying this, but there’s a vast landscape opening, so vast that I don’t think we can even guess how far it extends yet, let alone have mapped its terrain.

Grid Drop Quotes, Revisited

In last week’s Grid-Powered Drop Quotes, I overlooked a potential problem with the styles I created.  Fortunately, Philippe Wittenbergh caught it and pointed it out, and we both hit on the same solution.

The problem-in-waiting is that the big drop quote will force a gap between the first child element of the blockquote and the second, if the first child is short.  You can see this in the demo below (external version also available), where I made the first paragraph only a few words long.  If you select the “Borders” option, you can see the problem more clearly.

Besides, Grid was coming.

In the run-up to Grid support being released to the public, I was focused on learning and teaching Grid, creating test cases, and using it to build figures for publication.  And then, March 7th, 2017, it shipped to the public in Firefox 52.  I tweeted and posted an article and demo I’d put together the night before, and sat back in wonderment that the day had finally come to pass.  After 20+ years of CSS, finally, a real layout system, a set of properties and values designed from the outset for that purpose.

And then I decided, more or less in that moment, to convert my personal site to use Grid for its main-level layout.  It took me less than five minutes…

The solution is to have the drop quote span multiple rows.  The original CSS went something like this, simplified for the sake of clarity:

blockquote::before {
    grid-column: 1;
    content: "“";
    font-size: 5em;
}

That suffices to drop the drop quote into column 1 (explicitly) and row one (implicitly).  The row is as tall as the tallest of the grid items it contains, so in this case, the quote controls the row height.

The fix:

blockquote::before {
    grid-row: 1 / span 10;
    grid-column: 1;
    content: "“";
    font-size: 5em;
}

You can see that effect by enabling the “Row span” option.  I recommend trying it first with borders turned on, just to see how the element boxes change.

But wait!  Why span 10?  There aren’t that many rows in the blockquote, because there aren’t that many child elements!  That’s okay: the extra rows will be auto-created, but because they contain no content, the rows are of no height.  This means that in cases where there’s a blockquote with a lot of short child elements—think a passage of snappy dialogue—the pseudo-element will have more than enough spannability.  I could’ve gone with span 5 or similar, to echo the font sizing of the drop quote, but no sense risking having too little spannability.  (Which is a word I made up, then discovered it seems to have a meaning in mathematics, so I hope I’m not implying some sort of topological set unity of something.)

Auto-row generation may seem like dark magic, but you’re already soaking in it: remember how none of the blockquote’s child elements are explicitly given a row number, nor did I define rows with the grid-template-rows property?  That means they’re all auto-created rows.  This means if you do something like specify grid-auto-rows: 1em, then all the rows will be one em tall, with the contents spilling out and overlapping with each other.  For extra fun, try setting your auto row height to 0px instead!  (Warning: do not attempt where prohibited by law.)

The other thing Philippe pointed out was that in cases where the blockquote has only a single child element that’s one or two lines tall, the drop quote will not only set the height of the row, but the entire grid.  You can create this situation by selecting the “Short quote” option; again, I recommend leaving “Borders” enabled so you can see what’s happening.

Philippe’s proposal was to bring the line-height of the drop quote to nothing or almost nothing, and add some top margin to make up the difference.  For example:

blockquote::before {
    grid-column: 1;
    content: "“";
    font-size: 5em;
    line-height: 1px;
    margin-top: 0.33em;
}

This certainly works, as you can see by selecting the “Line height” option.  My concern is that having a great big drop quote next to a single-line blockquote is…not optimal.  I’d be more inclined to add a class for short blockquotes, and then restrict the drop quote effect to blockquotes without that class.  For example:

blockquote:not(.short)::before {
    grid-column: 1;
    content: "“";
    font-size: 5em;
}

That removes the need to fiddle with line heights and top margins, in exchange for remembering to class appropriately.  That’s a fair trade as far as I’m concerned.  Your preference may vary, of course.

Many thanks to Philippe for pointing out the error and proposing solutions!

Grid-Powered Drop Quotes

I’ve been experimenting with CSS Grid for various layout treatments—not high-level, whole-page layouts, but focused bits of design.  I’d like to share one of them for a few reasons.  Partly it’s because I like what I came up with.  More importantly, though, I think it illustrates a few principles and uses of CSS Grid that might not be immediately intuitively obvious.

First, here’s an interactive demo of the thing I’m going to be talking about.  You can use the checkboxes to alter aspects of the example, whether singly or in combination.  Feel free to fiddle with them before reading the rest of the article, or but you’ll probably want to come back to the demonstration as you read.  There’s also an external version of the demo as a standalone file, if you prefer opening it in a new tab and flipping back and forth.

So that’s how things have been laid out since the middle of 2005, more or less. I fiddled with a flexbox layout at one point as an experiment, but never shipped it, because it felt clumsy to be using a one-dimensional layout tool to manage a two-dimensional layout. I probably should have converted the navigation bar to flexbox, but I got distracted by something else and never returned to the effort.

Besides, Grid was coming. In the run-up to Grid support being released to the public, I was focused on learning and teaching Grid, creating test cases, and using it to build figures for publication.  And then, March 7th, 2017, it shipped to the public in Firefox 52.  I tweeted and posted an article and demo I’d put together the night before, and sat back in wonderment that the day had finally come to pass.  After 20+ years of CSS, finally, a real layout system, a set of properties and values designed from the outset for that purpose.

And then I decided, more or less in that moment, to convert my personal site to use Grid for its main-level layout.  It took me less than five minutes…

Let’s dig in!  The core concept here is a Grid-powered version of the big drop-quote on the left side, there, which is a relatively common treatment for blockquotes.  To make this happen, I’ve applied display: grid to the blockquote element itself, and added the opening quote using generated content, like so:

blockquote {
   display: grid;
   grid-template-columns: -webkit-min-content 1fr;
   grid-template-columns: min-content 1fr;
}
blockquote::before {
   grid-column: 1;
   content: "“";
   font-size: 5em;
   font-weight: bold;
}

There’s more to the actual styles of both rules, but that’s the central thesis: set up a two-column grid, and generate a great big opening quote.

The first thing to note here is that generated content also generates a pseudo-element that can be styled.  You may already realize this, since it’s known we can style generated content separately from the main content of the element.  But given that, if a grid is applied to the element, then any generated content’s pseudo-element, whether ::before or ::after, will become a grid item.  You can then place it in the grid.

I first came across this concept in the comments on my ALA article “Practical CSS Grid”, where Šime proposed using generated elements as a hack to get around the inability to directly style grid cells.  Here, I’m just using one to push a quote over to the side.

Why do this, when we can already use floats or relative/absolute positioning approaches to do the same?  Because it’s not quite the same: with Grid, the column containing the drop-quote responds to any changes to the quotation symbol.  Change the font, change its size, have the preferred font fail and fall back to an unexpected face, or replace the character with an SVG image, and the first column will resize thanks to the min-content track sizing, and the actual main content of the blockquote will adjust its placement to accommodate.  That didn’t happen with earlier techniques.

And yes, there is a vendor prefix in there.  Safari’s 10.1 Grid support came with -webkit- prefixed versions of min-content, max-content, and fit-content.  So I did the old pattern of prefixed first, unprefixed second.  This should be necessary only until the next release; Safari has already dropped the prefixes in its latest Technology Preview builds.  The change apparently just didn’t quite make the cut for 10.1.  It’s sad, but it’s also temporary.

In the meantime, this does mean that if you want to restrict your Grid styles only to implementations that don’t require prefixes, use that in your feature queries:

@supports (grid-template-columns: min-content) {…}

That, as well as a number of close variants like using grid-template-rows or max-content, will keep your Grid styles away from Safari until they update their Grid support in the public release channel.

That’s all nice, but there’s a great deal more to learn!  If you use the “Border” checkbox in the demo, you’ll see a dotted red border around the drop quote’s pseudo-element.  Notice that it matches the height of the opening paragraph, not the entire height of the blockquote.  That’s because the pseudo-element and the first paragraph share a row track.  The following paragraphs are in their own row tracks.

This brings up two things to consider.  First, all the child elements of the blockquote are now grid items.  That means the drop quote’s pseudo-element, but also all the paragraphs contained by the blockquote.  The same would happen to any child elements.  We could get around that by wrapping all the contents of the blockquote in a div or something like that, but I’d rather not.  So, this grid has four grid items: the pseudo-element, and three paragraphs.

This leads us to the second consideration: without placing the paragraphs into the same column, they’ll auto-flow into whatever grid cells are available.  You can see this by selecting the “Auto placement” option.  The first column will contain the quote and the second paragraph, as narrow as they both can be due to min-content.  The second column will contain the first and third paragraphs.

How I get around this in the working version is to explicitly put all the paragraphs—really, all child elements of the blockquote, which just happen in the case to be paragraphs—into the second column, like this:

blockquote > * {grid-column: 2;}

Okay, but how do they end up stacked vertically?  After all, I didn’t assign each of those child elements to a row, did I?

Wait a minute.  What rows?

If you go back and look at the CSS I showed, there is nothing about rows.  The property grid-template-rows exists, but I didn’t use it.  All I did was define columns.

Each child element goes into a row of its own anyway, because Grid has the ability to automatically create columns or rows when needed.  Suppose you define a three-by-three grid, and then assign a grid item to the fifth column of the fourth row.  What should happen?  The browser should auto-create as many columns and rows as needed.  Any auto-created tracks will have zero width or height if they don’t contain any grid items, unless you size them using grid-auto-columns or grid-auto-rows, but we’re not going there today.  The point is, here I’ve said all of the blockquote’s child elements should go into column 2.  Given that, they’ll auto-fill rows as available and auto-create rows as needed, filling them in once they’re created.

So the blockquote in the demo above has two columns because I explicitly defined them, and three rows because that’s what it needed to create to handle the three child elements.  If I’d added two more paragraphs and an unordered list, the grid would have had two columns and six rows (because six chid elements).

There are a lot of possible extensions to this technique.  A close quote could be created using ::after and placed in the last row of the grid, thanks to the ability to use negative track values to count back from the end of the grid.  Thus:

blockquote::after {
   grid-column: 3;
   grid-row: -1;
   content: "”";
   font-size: 5em;
   font-weight: bold;   
}

That places the close-quote in the third column, so to the right of the quoted text, and in the last row, regardless of how many rows were auto-created.  Of course, there is no third column…or there wasn’t, until assigning something to the third column.  At the point, the browser created it.

The danger there is that the auto-generated column is essentially tacked on to the trailing edge of the grid, without real consideration for what might be in the way—up to and including the edge of the viewport. Rather than auto-generate the column, we could define a third column like so:

grid-template-columns: min-content 1fr min-content;

This sets up a column on each side of the grid, one for each of the big quotes.  The second column, the one that gets all the actual child elements of the blockquote, receives all the space left over after those outer columns are sized, thanks to its 1fr value.

There’s one more drawback here, albeit one that’s easily overcome.  Grid items’ margins do not collapse.  You can see this effect by checking the “Default margins” option in the demo.  That shows what happens if default paragraph margins are allowed to remain.  We end up with two ems of space between the paragraphs, because each has top and bottom margins of 1em.

In the normal flow, margins collapse to the largest of the adjacent margins, which is why we’re used to 1em of space between adjacent paragraphs.  With grid items, what we see instead is the full element box, margins and all, placed inside the grid cell(s) they occupy.  That means any margin will create space between the edge of the grid cell and the border-edge of the element.  The fix here is straightforward: add a style to reduce margins between elements.  For example, something like:

blockquote > * {
   grid-column: 2;
   margin: 0.5em 0;
}

With a half-em margin above and below each element, any two adjacent elements will have the common 1em separation.  The demo actually has less than that because I wanted to use the print convention of paragraphs with the first lines indented, and a minor separation between paragraphs.  So the actual demo styles are more like this:

blockquote > * {
   grid-column: 2;
   margin: 0.125em 0;
   text-indent: 2.5em;
}
blockquote > *:first-child {
   text-indent: 0;
}

So there you have it: a Grid-powered drop quote.  I should note that all this by itself isn’t quite sufficient: if Grid isn’t supported, it will degrade poorly, as you can verify with the “Disable grid” option.

This is where using @supports() to encapsulate the Grid styling comes in handy.  You can put all of the quote-generation styles into the @supports() block, so that downlevel browsers just don’t get the drop quotes; or, you can set up the drop quotes with floats or positioning and then override those with @supports()-protected Grid styles.  Either one works.

Fortunately, we do have that capability, so it’s fairly easy to progressively enhance your designs with little touches like this one, even if you’re not ready for a full-on Grid plunge.  I’m looking forward to deploying this pattern here on meyerweb, as part of a site design overhaul I’ve been working on for the past couple of weeks.  That’s right: I’m working on my first redesign in a dozen years.  If that doesn’t give you some sense of the power of Grid, well, I just don’t know what will.


There is a followup to this article that explains and corrects an oversight in this article.

Practical CSS Grid

…In the run-up to Grid support being released to the public, I was focused on learning and teaching Grid, creating test cases, and using it to build figures for publication.  And then, March 7th, 2017, it shipped to the public in Firefox 52.  I tweeted and posted an article and demo I’d put together the night before, and sat back in wonderment that the day had finally come to pass.  After 20+ years of CSS, finally, a real layout system, a set of properties and values designed from the outset for that purpose.

And then I decided, more or less in that moment, to convert my personal site to use Grid for its main-level layout.

Me, writing for A List Apart, taking you on a detailed, illustrated walkthrough of how I added CSS Grid layout to meyerweb.com, while still leaving the old layout in place for non-Grid browsers.  As I write this, Grid is available in the latest public releases of Firefox, Chrome, and Opera, with Safari likely to follow suit within the next few weeks.  Assuming the last holds true, that’s four major browsers shipping major support in the space of one month.  As Jen Simmons hashtagged it, it’s a new day in browser collaboration.

As I’ve said before, I understand being hesitant.  Based on our field’s history, it’s natural to assume that Grid as it stands now is buggy, incomplete, and will have a long ramp-up period before it’s usable.  I am here to tell you, as someone who was there for almost all of that history, Grid is different.  There are areas of incompleteness, but they’re features that haven’t been developed yet, not bugs or omissions.  I’m literally using Grid in production, right now, on this site, and the layout is fine in both Grid browsers and non-Grid browsers (as the article describes).  I’m very likely to add it to our production styles over at An Event Apart in the near future.  I’d probably have done so already, except every second of AEA-related work time I have is consumed by preparations for AEA Seattle (read: tearing my new talk apart and putting it back together with a better structure).

Again, I get being wary.  I do.  We’re used to new CSS stuff taking two years to get up to usefulness.  Not this time.  It’s ready right now.

So: dive in.  Soak up.  Enjoy.  Go forth, and Grid.

Getting Grid

That converting-meyerweb-to-Grid article I’ve mentioned previously is still coming along (3,999 words as of the last draft, and I realized last night it needs another few hundred) and I think it will be out within a week.  I’ll do my best!  In the meantime, I’d like to point you to a few resources from the end of the article, plus do a tiny bit of self-promotion.

Resources first!  If you’re wondering what Grid means for Flexbox, Chen Hui Jing has a lovely piece on “Grid + Flexbox: the best 1-2 punch in web layout”.  Just the right length, with live Codepens, this is a very good introduction to using Grid and Flexbox in harmony.  Some of what’s described there won’t be as necessary in the future, as Flexbox-style alignment migrates to Grid, but in the meantime Hui Jing explores the current state of the art with elegance.

If you have Firefox or Chrome and they’re updated to the latest release (FF52, C57) then I strongly encourage you to set aside a few minutes and go browse The Experimental Layout Lab of Jen Simmons.  Jen’s been creating Grid demonstrations and experiments for well over a year now, and there are some really great examples there, summarizing some common design patterns and showing how Grid can make them much simpler and more robust.  I especially recommend the 2016 home page, which combines CSS Grid, writing modes, transforms, and design history to create something really great (try resizing to see the responsive coolness).  But don’t stop there!

If you like your learning in motion, Rachel Andrew’s video series introducing Grid concepts and properties is fabulous.  As an application developer—she’s part of the Perch CMS team—she’s been excited about Grid and what it can do longer than just about anyone.  Her deep technical skills and teaching abilities really come together in the video series.  If you prefer to read up on Grid, then Rachel’s written a series of articles for the Mozilla Developer Network that cover similar ground.

Finally, if you like extended technical explanations of every Grid property and value seasoned with lots of examples and screenshots, then I suggest picking up the Early Access version of CSS: The Definitive Guide, 4th EditionEstelle Weyl and I have been working on finishing this for a while now, and it’s just about ready: there are three chapters still to be added.  They’ve already been written, but haven’t quite finished first editorial review and production massaging.  But: the Grid chapter is already available, so if you get the book now, you’ll have instant access to something like 25,000 words going through Grid property by property.  And also a whooooole lot more words covering everything else in CSS.  (The current page count estimate for the book is 950.  Nine hundred fifty.  Yoinks.)

Go forth and Grid!

Chrome Grid Bug Update

I mentioned late last week, in my post about Chrome 57 having landed Grid layout, that there is a bug that affects some people.  Well, further investigation has revealed that the bug doesn’t seem to be in the Grid layout engine.  Instead, disabling selected extensions makes the bug go away.

The odd part is that the extension seems to vary.  In my case, disabling Window Resizer fixed the problem.  Before you think it’s all their fault, though, Rachel Andrew discovered that disabling Window Resizer in her copy of Chrome did not solve the problem.  For her, it was disabling the LastPass extension that did it.  I don’t even have the LastPass extension installed on my machine, in any browser.

So: if you run into this problem, try disabling extensions to see if that fixes it.  If so, you can enable them one at a time and test to see which one triggers the bug.  With any luck, a fix will be found soon and deployed via auto-updating.  And if you find out anything else, please let us know on the bug report!

August 2017
SMTWTFS
July  
 12345
6789101112
13141516171819
20212223242526
2728293031  

Archives

Feeds

Extras