meyerweb.com

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

Handiwork

The story of a mixer-breaking cookbook, the vault of all practical human knowledge, and what I see when I look at my hands

It all started with an afternoon date.  It ended in grease.

Kat and I took a weekend afternoon by ourselves to head down to University Circle, to have some early tea and macarons at Coquette and to see what we might find for a late lunch afterward.  We wandered up and down the new Uptown section, chuckling to ourselves over the massive changes since we’d each come to the city.  See that bowling alley?  Remember when it was a broken parking lot?  And when this bookstore was a strip of gravel and weeds?

In the window of the bookstore, I was looking askance at a coloring-book-for-grownups based on “The Walking Dead” when Kat exclaimed, “Oh, that looks fabulous!”  It was, I was not surprised to discover, a bakers’ cookbook.  Kat loves to bake, mostly for others.  In this case, it was Uri Scheft’s Breaking Breads: A New World of Israeli Baking.

The bookstore was closed, so I took a picture of the cover and we moved on, eventually ending up at a ramen shop.  I had an unagi don.


I gave Kat the book for her birthday.  It’s one of the few things I got right about that celebration this year.

Not long after, Kat had to work at the clinic on a Friday, and asked if I’d make challah from the book so it was ready for dinner that night.  I figured, what the heck.  What could go wrong?  So I hauled out the stand mixer and digital scale, assembled the various ingredients in a line, and started to work.

The challah recipe is sized to make three loaves, because (according to Mr. Scheft) the dough mixes better in large quantities than in small.  I was pleased to see the recipe gave all ingredients first as weights, so I didn’t have to convert.  I’ve never been great at cups and spoons, especially with baking ingredients, and most especially with flour.  I either leave too much air or pack down too hard.  A kilogram of flour seemed like a lot, but once I realized it was only a bit more flour than in the overnight bread recipe I’d made several times before, I forged ahead.

Everything fit fairly well into the mixing bowl, which had been my first concern.  There was enough room to not have the flour overtop the rim and form a glutenclastic flow over the countertop, at least as long as I started slow.  So I did.

Our mixer is a KitchenAid 325W model, bought many years ago and since put to hard service.  Kat as I mentioned before, enjoys baking, being good enough at it that she can often free-style in baking and produce wonderful results.  I do some baking of my own from time to time, though cooking is more my area of strength.  Carolyn has enjoyed learning to bake, and it’s common for her and a friend to decide to make a cake or some cookies when hanging out together, or bake cinnamon rolls for breakfast on a Saturday morning.  One of the last things Rebecca did entirely by herself was hold the dough paddle and slowly, methodically eat raw chocolate-chip cookie dough off of it.  Joshua isn’t as interested in baking yet, but he’s certainly a fan of paddle-cleaning.

As the challah dough started coming together, it kept climbing the dough hook and slowing the mixer, making the motor whine a bit.  I kept shoving it back down, turning the mixer off occasionally to really get it down there.  I was faintly smiling over the possibility that the dough would end overtopping the bowl instead of the raw flour when the hook stopped dead and a buzzing noise burst forth from the motor housing.

Uh-oh.

After I’d removed all the dough from the hook and set the bowl aside—the dough was basically done at that point, thankfully—I tried flipping the gear-speed lever back and forth.  Nothing but buzzing.  It sounded exactly like what you’d expect an unseated gear to sound like, as the teeth buzzed past the gear it was supposed to turn.

There was still bread to make, so I set the mixer aside and got on with the kneading and stretching.  Once the dough started its first rise, I went back to the mixer.  I figured, what the heck, so I banged on the housing a few times to see if the gear would reseat.  And, lo and behold, it started spinning again!  There were still some odd sounds, but it seemed to be mostly okay.  I decided to clean it off, put it away, and see if the “fix” held.


It was a week later that we found the fix had not, in fact, held.  Kat was making babka—from, once again, a recipe in Breaking Breads—for this year’s St. Baldrick’s event in Cleveland Heights when the paddle seized and the buzzing noise once more erupted.

We finished the recipe with a hand mixer (my hand ached for an hour) and I retired to the dining room to search Amazon for a replacement mixer.  We could get the same model for about $300, or a more powerful model for more—although that would mean tossing a bunch of accessories, since the more powerful models use a completely different bowl type.  There wasn’t, so far as I could find, a stronger motor in the same form factor.

On a whim, I opened a new tab and typed “kitchenaid stand mixer stripped gear” into the search bar, and clicked the “Videos” tab.  There were, of course, multiple videos at YouTube, that vast repository of all practical human knowledge.  If you want to know the history of stand mixers, you go to Wikipedia.  If you want to know how to use or fix them, you go to YouTube.

I started watching the first result, realized it was for a different mixer model, and skipped to the “Up Next” video, which was just what I was looking for: same model and everything.  I was a couple of minutes into it when Kat walked into the room saying, “Hey, why don’t you see if maybe you can fix—oh.”


I have not, generally speaking, been what you would call a handy person.  Most of my repair attempts made things worse, not better.  On occasion, I managed to turn a minor inconvenience into a major expense.  I was never particularly ashamed of this, although I was annoyed by the cost.  I wasn’t a stranger to manual labor, but I was always better with a keyboard than I was with a hammer—first 88 keys, and then 104.

But for some reason, one of the first things I did to try to manage my grief, late in 2014, was ask my friend Ferrett to help me do some rough carpentry.  He had the tools, having taken woodworking classes in the past, and I wanted to put a bookcase in the wall of our finished attic.  From that first painful attempt—it took us all day to put together a not-particularly-well-made case—we started getting together once a week or so to just build stuff.  Our friend Jim got into the act as well.

A bookcase here, a shelf there, we’ve gotten better at it.  We’ve managed to use every tool in the arsenal, though not always wisely.  We’ve made abstruse jokes based on the biscuit cutter being made by Freud.  We’ve invented hacks on the spot to make cuts easier and figured out later why things didn’t go quite as intended.  We’ve learned that you can never be too rich or have too many clamps.  (We depart from standard societal attitudes toward thinness.)

As we’ve progressed, those attitudes and skills have osmosed into regular life.  Minor home repair is now a thing I do, and approach with confidence instead of trepidation.  No real surprise there: practice at anything, and you’re likely to become better at it.  But when the screen door latch broke, I bought a replacement and improvised a way to make it work when the frame bracket and latch didn’t line up.  I took a Dremel to my aging laptop stand in order to keep it from scratching desks.  I’ve fixed more than one damaged or jammed toy.

So, sure, why not see if the mixer could be fixed with a cheap part replacement?  After all, a handyman told me years ago, if it’s already broken, trying to fix it can’t make it any worse.  Though I remember thinking to myself that he’d never seen me try to fix things.

I assembled my tools, covered the dining room table in several layers of drop cloth, and started the video.  I had real trouble getting out the roll pin that held the planetary in place, but WD-40 and persistence won the day.  I had to stop for a while while I searched for surgical gloves, but eventually they turned up and I got into the great globs of grease that keep the gears going.  And yes, just as the video had prophesied, the problem was the one plastic gear in the mechanism, nestled in amongst the chain of solid metal gears.

A broken worm gear.
Well, see, there’s my problem.

I’m not annoyed by this.  That gear, I believe, is intentionally plastic as a last-ditch defense against burning out the motor or shattering a metal gear or the paddle itself, should somethiing seize up the planetary.  Think of a metal bar that somehow gets thrust into the paddle, forcing it to stop.  Something has to give.  A small worm gear acting as a fail-safe is a better option than most others.

I went back to Amazon, this time to order a replacement part.  When I found out they were $6.24 each, I ordered three.  Until the new worm gears arrive, the various screws and pins I removed are taped in groups to a piece of printer paper, each group labeled according to their points of origin in the mixer assembly.  The gear tower pieces I put in a plastic sandwich bag, also taped to the paper, to keep their grease contained.

The broken worm gear I may throw away, or I may keep as a memento.


I am, in my way, pleased with myself about all this.  Proud both that I may be able to fix a problem for $7 and an hour or two of time, instead of having to replace an entire appliance for a few hundred dollars; and also for having developed the skills and familiarity to let me try it in the first place.  True, I likely couldn’t have done it without YouTube, but in years past, even with YouTube I’d have been hesitant to try, for fear of making it worse, or just being hapless and frustrated by the feeling that if I only knew more, I’d be able to do it right.

Now I know more.  I’ve learned—not at internet speed, but at slow, methodical, human speed.  I’ve changed, but in ways of my own making instead of ways that circumstance thrust upon me.

When I look at my hands now, I see tools that not only create, but can also repair.  They can put to right at least some things that have gone wrong.

There is much more solace in that than I would ever have guessed.

I don’t know, as I write this, whether the mixer will work again.  I may reassemble it incorrectly, or even correctly but without success.  Sometimes that happens.  Sometimes you do everything right, and still have no path to success.  But if we do have to junk it after all, I’ll know it wasn’t for lack of first trying to correct the situation.

I will draw pride from that, just as I did from the challah I made for my family and friends, an entire loaf of which was quickly devoured.  Just as I have drawn pride from things I’ve written, shaping words that have helped others in ways large and small, and sometimes in ways completely unexpected.

The difference is that when I fix things, I fix for myself, not for others.  One small repair at a time, I fix myself.

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!

Doubled Grids

Chrome 57 released yesterday, not quite a week ahead of schedule, with Grid support enabled.  So that’s two browsers with Grid support in the space of two days, including the most popular browser in the world right now.  Safari has it enabled in Technology Preview builds, and just blogged an introduction to Grid, so it definitely feels like it’ll be landing there soon as well.  No word from Edge, so far as I know.

I did discover a Chrome bug in Grid this morning, albeit one that might be fairly rare.  I filed a bug report, but the upshot is this: most or all of an affected page is rendered, and then gets blanked.  I ran into a similar bug earlier this year, and it seemed to affect people semi-randomly—others with the same OS as me didn’t see it, and others with different OSes did see it.  This leads me to suspect it’s related to graphics cards, but I have no proof of that at all.  If you can reproduce the bug, and more importantly come up with a reliable way to fix it, please comment on the Chromium bug!

Grid Inspection

I said yesterday I would write up the process of adding Grid to meyerweb, and I did.  I started it last night and I finished it this morning, and when I was done with the first draft I discovered I’d written almost four thousand words.

So I pitched it to an online magazine, and they accepted, so it should be ready in the next couple of weeks.  Probably not long after Chrome ships its Grid implementation into public release, in fact.  I’ll certainly share the news when it’s available.

In the meantime, you can inspect live grids for yourself, whether here or at Grid by Example or The Experimental Layout Lab of Jen Simmons or wherever else.  All you need is Firefox 52, though Firefox Nightly is recommended for reasons I’ll get to in a bit.

In Firefox 52, if you inspect an element that has display: grid assigned to it, you’ll get a little waffle icon in the inspector, like so:

Mmmmmm, waffles.

Click it, and Firefox will draw the grid lines on the page for you in a lovely shade of purple.  It will even fill in grid gaps (which are a thing) with a crosshatch-y pattern.  It’s a quick way to visualize what the grid’s template values are creating.

If you have Firefox Nightly, there’s an even more powerful tool at your disposal.  First, go into the inspector’s settings, and make sure “Enable layout panel” is checked.  You may or may not have to restart the browser at this point—I did, but YEMV—but once it’s up and running, there will be a “Layout” panel to go with the other panels on the right side of the Inspector.  There you get the box model stuff, as well as a checklist of grids on the current page.

The Layout panel

For each grid on the page—not just the element you’re inspecting—you can set your own color for the gridlines, though those color choices do not currently persist, even across page reloads.  You can also turn on number labels for the grid lines, which are currently tiny and black no matter what you do.  And if you allow grid lines to extend into infinity, you can turn the page into a blizzard of multicolored lines, assuming there are several grids present.

This panel is very much in its infancy, so we can expect future enhancements.  Things like color persistence and better grid line labels are already on the to-do list, I’m told, as well as several more ambitious features.  Even as it is, I find it valuable in constructing new grids and diagnosing the situation when things go sideways.  (Occasionally, literally sideways: I was playing with writing-mode in grid contexts today.)

There’s another, possibly simpler, way to enable the Layout panel, which I learned about courtesy Andrei Petcu.  You type about:config into the URL bar, then enter layoutview into the search field.  Double-click “devtools.layoutview.enabled” to set it to “true”, and it will be ready to go.  Thanks, Andrei!

So go ahead—inspect those grids!

Welcome to the Grid

Grid is public.  It’s live right now in the latest Firefox release, Firefox 52.

It will similarly be live in the next public Chrome release, due in the next week or so.

It’s here.  I almost can’t believe it.

For well more than a decade now, when asked what CSS needs more than anything, I’ve said it needs real, actual layout.  “A layout-shaped hole at its heart” is a phrase I may have used a fair few times.

Rachel Andrew had a great article last week about “Learning CSS Grid Layout”, which charts a sensible course for getting used to grid.  It also busted a few myths about grid.  I recommend it highly.

There’s one more myth I’d like to do my best to bust, which I’ll summarize as a comment I’ve seen many times: “Ugh, tables again?”

The underlying assumption here is: grids are just tables with a new syntaxThis is entirely untrue.

I mean, yes, you can recreate 1990s-era table-based layout techniques with grid, in much the same way you can recreate the submit button with two JS libraries and a complex front-end framework.  The ability to do it doesn’t necessarily make it a good idea.

(Though you might, from time to time, find the ability useful.  Here’s what I mean: you can take a bunch of data contained in arbitrary markup someone else is producing, and lay it out in a tabular format.  It would be far preferable to have the data in actual table markup, but if that’s not an option, grid will give you a potential solution.)

I have an example of just one way grids are different than tables.  I just last Friday finished writing the last chapter of CSS: The Definitive Guide, 4th Edition, covering filters, blending, clipping, and masking.  (I finished the grid chapter late last year, so it’s already available in the early-access title.)  Almost all the figures in the book were created by building HTML+CSS pages, and taking high-resolution screen captures with Firefox’s screenshot command.  Here’s one.

Compositing masks

The way these are displayed is actually the inverse of their source order.  I wanted them to be in document source such that the compositing steps were in chronological order, so that’s how I wrote them.  Once I laid them out that way in the figure, using grid, I realized it made more sense to arrange them visually, with the bottom layer at the bottom of the figure, the next above that, all leading up to the result at the top.

So I just rearranged them on the grid, by assigning grid row numbers.  The document source wasn’t touched.  A bit simplified, the CSS to do that looked something like this:


ol li:nth-child(1) {grid-row: 4;}
ol li:nth-child(2) {grid-row: 3;}
ol li:nth-child(3) {grid-row: 2;}
ol li:nth-child(4) {grid-row: 1;}

Because the compositing examples (the “columns” in the layout) were represented as ordered lists, with the grid set up to place each image with some captioning, I could just change their order.  So yes, it looks like a table, but the underlying structure is anything but table-like.  Just to get each column of examples grouped together with tables, I’d have to nest tables, or accept a one-row table with each cell containing some other structure.  Rearranging the columns would mean doing markup surgery, instead of just reassigning their layout placement via CSS.

Instead, I was able to represent the content in the best available structure (ordered lists) and then arrange them on a grid in the best way I could visually.  For that matter, I could responsively change the layout from a six-column grid to a three-column grid to un-gridded lists as the viewport got more and more narrow.  As, in fact, I did—check it out.  If you make the window narrow enough, Grid is dropped entirely so you can see the base structure and content.

This ability to place grid items without respect to source order is a powerful tool, and like all powerful tools it can be used for good or ill.  It’s possible to assemble a visually usable layout out of the most inaccessible, horrible markup structures imaginable.  It’s also possible to assemble a visually usable layout from clean, accessible markup in ways we’ve never even dared dream.

Combine grids with other CSS features, and you can really create art.  Jen Simmmons has a layout lab site, and her 2016 main-page design is… well, go see it in a grid-capable browser, like today’s release of Firefox.  Realize it’s all text, no images, no scripting.  Just markup and style.

And the style is remarkably simple for what’s being accomplished.  It’s not too alien a syntax, but it will likely take some time to adjust to using it.  It’s taken me some time, as I’ve experimented and written about it.  Unlearning my float habits has taken some work, and I don’t know that I’m completely done.  I do know that it’s been worth it many times over.

I’ve done a few experiments with the layout of a local copy of meyerweb, and done some frankly goofy things to the design along the way.  I’m hoping to convert what’s up here to a simple grid layout in the next few days, make it a slightly more complex grid shortly after that, and then maybe—maybe—actually do some redesigning for the first time in over a decade, to take advantage of grid more fully.  Jen has a great six-minute video exploring a few features of grid and the grid inspection tool now built into Firefox, which I recommend to anyone curious to know more.

So if you’re thinking of grid as tables 2.0, please, stop.  Table-style layouts are the first one percent of what grid offers.  There are works of art and undiscovered techniques waiting in the other 99 percent.

One Thousand Days

It has been one thousand days since our daughter took her last breath.

I don’t know if it’s a cruel irony or a fortunate happenstance that this coincides with an upward adjustment in my antidepression medication.  It was necessary, because I was losing the will to do anything but the bare necessary minimum to function.  Now I can actually initiate conversation, and see life as something other than a state to be passively endured.  But the surge in serotonin reuptake inhibitors has also distanced me from grief.

I can feel, distantly, the despair that accompanies this milestone and its root cause.  I can feel, distantly, the instinct that I should bring that despair closer, to mourn a little more and honor Rebecca’s memory. It stays on the horizon of my awareness, something to be noticed when my gaze happens to turn that direction.  Not more.

I can feel, distantly, the conviction that this is abnormal and should be unacceptable.  Maybe that’s true.  Maybe it isn’t.

Instead I remember the face of my daughter, and the aura of a smile suffuses my heart.

I still miss her.  I still, from time to time, wonder how I managed to get this far in the wake of so shattering a loss.  I honestly didn’t think I’d have the strength.  Maybe I was born with it.  Maybe it’s paroxetine.

I don’t know how I’ll feel toward the end of the month, when I reach 210 days, and I guess in some ways it doesn’t matter.  The day will come, the day will go, and it will be whatever it is.

Very much like a life.

Scaling SVG Clipping Paths for CSS Use

I’ve been working a lot with the clip-path property recently, as I write the chapter on filters, blends, clipping, and masking for CSS: The Definitive Guide’s long-delayed 4th edition (available now in early-release format!).  One of the nifty things you can do with clipping paths is define them with percentage-based coordinates.  For example, here’s a hexagon-like clipping path:

clip-path: polygon(50% 0, 100% 25%, 100% 75%, 50% 100%, 0 75%, 0 25%);

That starts at the center top (50% 0), goes to the right edge, quarter-down (100% 25%), and so on.

When I got to SVG-based clipping, which you can use with the CSS pattern clip-path: url(#pathID), I tried and failed with this:

<clipPath id="hexlike">
  <polygon points="50% 0, 100% 25%, 100% 75%, 50% 100%, 0 75%, 0 25%" />
</clipPath>

It didn’t work because, as I discovered to my horror, SVG does not allow percentage coordinates.  I could just strip all the percent signs out, but that would be the same as saying this in CSS:

clip-path: polygon(50px 0, 100px 25px, 100px 75px, 50px 100px, 0 75px, 0 25px);

I didn’t want pixels, though.  I want percentages, darn it all!

So I asked around on Twitter, and Markus Stange pointed me to the solution: converting all the SVG coordinates to the range 0–1 and using the clipPathUnits attribute.  The working version looks like this:

<clipPath id="hexlike" clipPathUnits="objectBoundingBox">
  <polygon points="0.5 0, 1 0.25, 1 0.75, 0.5 1, 0 0.75, 0 0.25"/>
</clipPath>`
A hexlike clipping path.

That yields the same result as the polygon() CSS shape with the percentages I showed before.

All that is great if you’re writing your own SVG shapes and can make sure you set it up properly, but what if someone hands you a shape to be used as a clip path and it’s in absolute coordinates like 100 75?  If you’re really lucky, the shape has a viewbox of 0 0 100 100 (or all the coordinate points are in that range) and you can just divide all the coordinate points by 100 to get the proper values.  But that’s really tedious for any but the simplest of shapes, and besides, what if it has some other viewbox?  That’s where the transform attribute saves the day.

For example, suppose you get an SVG file that looks like this (with the actual path coordinates removed because there are a lot of them):

<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 329.6667 86">
  <clipPath id="cloud02">
    <path d="…(coordinates go here)…"/>
  </clipPath>
</svg>

First, add the clipPathUnits attribute to the <clipPath> element:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
 xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 329.6667 86">
  <clipPath id="cloud02" clipPathUnits="objectBoundingBox">
    <path d="…(coordinates go here)…"/>
  </clipPath>
</svg>

Next, look at the viewBox attribute on the <svg> element itself.  The value there is 329.6667 86.  That means 329.6667 coordinate units horizontally, and 86 units vertically.  So all you need to do now is divide all the horizontal values by 329.6667, and the vertical values by 86.  Which would be super tedious, except we have scaling transforms at our disposal:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 329.6667 86">
  <clipPath id="cloud02" clipPathUnits="objectBoundingBox"
   transform="scale(0.003033 0.0116279)">
    <path d="…(coordinates go here)…"/>
  </clipPath>
</svg>

Those two values are 1/329.6667 and 1/86, respectively, and they effectively scale every point in the d attribute to fit into the needed 0–1 range.  (That’s not precisely what happens, but the outcome is the same.)  Thus we have an SVG clipping path that scales with the element and fits to its dimensions!

This works just as well for other markup patterns.  To return to the hexlike path from before, assume it was written like this:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
 xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 100 100">
  <clipPath id="hexlike">
    <polygon points="50 0, 100 25, 100 75, 50 100, 0 75, 0 25" />
  </clipPath>
</svg>

If that were applied as-is, via clip-path: url(#hexlike), it would create a hex-like clipping path that fits a 100px by 100px box, positioned in the top left of the element (in left-to-right languages, I presume).  The quick fix:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
 xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 100 100">
  <clipPath id="hexlike" clipPathUnits="objectBoundingBox"
   transform="scale(0.01)">
    <polygon points="50 0, 100 25, 100 75, 50 100, 0 75, 0 25" />
  </clipPath>
</svg>

Bingo bango bongo, it will now scale to the element’s dimensions, whatever those turn out to be.

Of course, if you apply that to something like a short paragraph, it will be verrrrry stretched out, but the same would be true with a percentage-based polygon() shape.  The beauty here is that you can scale any coordinate set, so if you have a tiny path that you want to blow up, or a huge path you want to shrink down, you can transform it without using clipPathUnits to stretch it over the bounding box.  Something like this:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
 xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 100 100">
  <clipPath id="hexlike" transform="scale(4)">
    <polygon points="50 0, 100 25, 100 75, 50 100, 0 75, 0 25" />
  </clipPath>
</svg>

That gets you a hexlike shape that fits a 400px by 400px box, for example.

Now all CSS needs is the ability to size and position clipping paths in a manner similar background images, and we’ll be in clover.  I hope such properties are in the WG’s mind, because I’d love to be able to just point an at SVG clipping path, and then say something like clip-path-position: center; clip-path-size: contain;.  That would remove the need for fiddling with SVG attributes altogether.

Thanks to Markus Stange for the technique and his invaluable assistance in proofreading this article.

December 2017
SMTWTFS
November  
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Archives

Feeds

Extras