meyerweb.com

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

Archive: 'CSS' Category

Spinning the Web

Can CSS create art?  That’s a question I set out to explore recently, and I like to think that the answer is yes.  You can judge for yourself: Spinning the Web, a gallery on Flickr.

cnn

To be clear, when I say “Can CSS create art?” I don’t mean that in the sense of wondering if art, or artful designs, can be accomplished with CSS.  I think we all know the answer there, and have known at least since the Zen Garden got rolling.  What I’m doing here is using some basic CSS to generate art, using web sites as the medium.  For the series I linked, I spun all of the elements on a page using transform: rotate() to see what resulted.  Any time I saw something I liked, I took a screenshot.  After I was done, I winnowed the shots down to the best ones.

As some of you old-schoolers will probably have recognized, I’m absolutely following in the footsteps of Joshua Davis here, and in fact my working title for this effort was “Once Upon a Browser”.  I saw Josh speak years ago, and clearly remember his description of how he generated a lot of his art.  My process is almost identical, albeit with a bit less automation and computational complexity.

Because this is me, I built a little commentary joke into the first images in the series.  It’s not terribly subtle, but with luck one or two of you will get the same chuckle I did.

I’m already thinking about variants on this theme, so there may be more series to come.  In the meantime, as I surf around I’ll stop every now and again to spin what I see.  I’ll definitely mention any new additions via Twitter, and new series both there and here.  And of course if you follow me on Flickr, you’ll see new pieces as they go up.

I hope you enjoy them half as much as I enjoyed creating them.  And if anyone wants to use the originals as desktop wallpapers, as Tim proposed, feel free!

Seeing the matrix()

Over the weekend, Aaron Gustafson and I created a tool for anyone who wants to resolve a series of CSS transforms into a matrix() value representing the same end state.  Behold: The Matrix Resolutions.  (You knew that was coming, right?)  It should work fine in various browsers, though due to the gratuitous use of keyframe animations on the html element’s multiple background images it looks best in WebKit browsers.

The way it works is you input a series of transform functions, such as translateX(22px) rotate(33deg) scale(1.13).  The end-state and its matrix() equivalent should update whenever you hit the space bar or the return key, or else explicitly elect to take the red pill.  If you want to wipe out what you’ve input and go back to a state of blissful ignorance, take the blue pill.

There is one thing to note: the matrix() value you get from the tool is equivalent to the end-state placement of all the transforms you input.  That value most likely does not create an equivalent animation, particularly if you do any rotation.  For example, animating translateX(75px) rotate(1590deg) translateY(-75px) will not appear the same as animating matrix(-0.866025, 0.5, -0.5, -0.866025, 112.5, 64.9519).  The two values will get the element to the same destination, but via very different paths.  If you’re just transforming, not animating, then that’s irrelevant.  If you are, then you may want to stick to the transforms.

This tool grew out of the first Retreats 4 Geeks (which was AWESOME) just outside of Gatlinburg, TN.  After some side conversations betwen me and Aaron during the CSS training program, we hacked this together in a few hours on Saturday night.  Hey, who knows how to party?  Aaron of course wrote the JavaScript.  Early on we came up with the punny name, and of course once we did that the visual design was pretty well chosen for us.  A free TTF webfont (for the page title), a few background images, and a whole bunch of RGBa colors later we had arrived.  Creating the visual appearance was a lot of fun, I have to say.  CSS geeks, please feel free to view source and enjoy.  No need to say “whoa”—it’s actually not that complicated.

So anyway, there you go.  If you want to see the matrix(), remember: we can only show you the door. You’re the one that has to walk through it.

CSS Pocket Reference: The Cutting Room

I just shipped off the last of my drafts for CSS Pocket Reference, 4th Edition to my editor.  In the process of writing the entries, I set up an ad-hoc test suite and made determinations about what to document and what to cut.  That’s what you do with a book, particularly a book that’s meant to fit into a pocket.  My general guide was to cut anything that isn’t supported in any rendering engine, though in a few cases I decided to cut properties that were supported by a lone browser but had no apparent prospects of being supported by anyone else, ever.

For fun, and also to give fans of this or that property a chance to petition for re-inclusion, here are the properties and modules I cut.  Think of it as the blooper reel, which can be taken more than one way.  I’ve organized them by module because it’s easier that way.

After all that, I imagine you’re going to laugh uproariously when I tell what I did include:  paged and aural properties.  I know—I’m kind of poleaxed by my own double standard on that score.  I included them for historical reasons (they’ve long been included) and also because they’re potentially very useful to a more accessible future.  Besides, if we run out of pages, they’re in their own section and so very easy to cut.

I’m pretty sure I listed everything that I explicitly dropped, so if you spot something that I absolutely have to reinstate, here’s your chance to let me know!

Inconsistent Transitions

Here’s an interesting little test case for transitions.  Obviously you’ll need to visit it in a browser that supports CSS transitions, and additionally also CSS 2D transforms.  (I’m not aware of a browser that supports the latter without supporting the former, but your rendering may vary.)

In Webkit and Gecko, hovering the first div causes the span to animate a 270 degree rotation over one second, but when you unhover the div the span immediately snaps back to its starting position.  In Opera 11, the span is instantly transformed when you hover and instantly restored to its starting position when you unhover.

In all three (Webkit, Gecko, and Opera), hovering the second div triggers a one-second 270-degree rotation of the span.  Unhovering causes the rotation animation to be reversed; that is, a one-second minus-270-degree rotation—or, if you mouseout from the div before the animation finishes, an rotation from that angle back to the starting position.  Either way, it’s completely consistent across browsers.

The difference is that in the first test case, both the transform and the transition are declared on hover.  Like this (edited for clarity):

div:hover span {
	transition: 1s transform;
	transform: rotate(270deg);
}

In the second test case, the transform and the transition are split up like so:

div span {
	transition: 1s transform;
}
div:hover span {
	transform: rotate(270deg);
}

It’s an interesting set of results.  Only the second case is consistently animated across the tested browsers, but the first case only animates one direction in Webkit and Gecko.  I’m not sure which, if any, of these results is more correct than the other.  It could well be that they’re all correct, even if not consistent; or that they’re all wrong, just in different ways.

At any rate, the takeaway here is that you probably don’t want to apply your transition properties to the hover state of the thing you’re transitioning, but to the unhovered state instead.  I say “probably” because maybe you like that it transitions on mouseover and instantly resets on mouseout.  I don’t know that I’d rely on that behavior, though.  It feels like the kind of thing that programmer action, or even spec changes, will take away.

Edit Your Head (Styles)

When I saw Ian Lloyd tweet the words “Cunning. Like a fox. Neat little trick!” I knew I had to check it out, because Ian’s a sharp one.  So I popped over to the linked CSS-Tricks article, Show and Edit Style Element, and checked it out.  Cunning indeed!  And yet, it immediately bothered me.

See, the trick as posted involves editing style elements that have been embedded into the body.  That is of course valid in HTML5 when you scope the style element, but scoping wasn’t the point of the proffered demo.  And I’ve long known that it’s simple to display style elements from within the head; it’s what I did for the CSS3 tests I recently published, used in demos of diagnostic styles, and so on.  Why not do the same thing here and avoid the invalidity of an unscoped body-embedded style element?

Accordingly, I created my own variant demo, where you can edit the head-embedded styles directly.  While I was at it, I used another favorite trick of mine: I took the CSS used to make the styles appear in the browser and put them in their own style sheet that doesn’t get shown.  Usually I id the style sheet to be displayed and style based on that.  This time I had a better hook, in that the style element to be edited already had a contenteditable attribute.  So:

head, style[contenteditable] {display: block;}
style[contenteditable] {
  font-family: monospace; white-space: pre; padding: 0.5em;
  border: 1px dotted red; background: white;}

Yay attribute selection!

Feel free to have fun editing the styles embedded in the document from within the document.  As usual, do so at your own risk, no warranty is expressed or implied, not liable for damages arising from your use or failure to use, not a flying toy, blah blah blah.  Share and enjoy!

(Incidentally, if anyone knows a markup- or CSS-based way to get around the Shift-Return-for-newline requirement in Gecko browsers, I’d love to hear about it.)

CSS3 Tests

Over the past couple of months, I’ve been hacking together some CSS3 tests.  I did this to try to figure out what should be included in the upcoming fourth edition of the CSS Pocket Reference (and thereafter CSS: The Definitive Guide) and didn’t plan to do anything public with them, but at this point, I figure what the heck.  Maybe they’ll be of interest to others.

I was especially interested by the results for list-style-type, where I found some small spots of support for various types in various browsers.  In contrast, WebKit supports most of the CSS3 types, so far as I can tell, though in my install several types were apparently mangled by a lack of appropriate fonts.

If you dig in, you’ll discover that the individual tests are all poured through some PHP.  The reason for this is that the base test pages (which are straight HTML; see for example the list-style-type base) include neither navigation links nor vendor prefixes.  That’s what the PHP handles.  It’s a bit clumsy, URL-wise, and that’s why the index page of the tests warns that the tests’ URLs could change in the future.  Not the index page: that will remain cool for as long as I have anything to say about it.  I just can’t swear off tinkering with the URLs of the tests for the time being.  It’s entirely possible that at some point in the future I’ll ice them down, but no guarantees.

I’m tossing these into the public sphere for three reasons.  The first is that they might be useful to other people, and I’m always in favor of sharing stuff that might be useful.  The second is that I may have committed grievous errors of fact, and many eyes make errors obvious.  If you find an error, please let me know.  I prefer that such reports be left as comments here since it lets many eyes evaluate the error reports too, but I’ll accept private mail as well.

The third is that it represents another turn of the wheel.  I started my CSS career building tests to see what browsers got right and wrong, and every so often I come back to that same fundamental act.  The other times I’ve done so, I’ve published what resulted.  This time, I’m publishing a little earlier and little more in the raw, so to speak, but it’s still the same impulse—and by now, it’s Tradition.

So I hope you enjoy, or at least find useful, these tests and whatever other tests get built in the future!

CSS Editors Leaderboard

I recently decided to create a CSS Editors Leaderboard, which is my attempt to rank the various editors of CSS modules based on the current process status of their modules, how current the modules are, and so on.  It’s kind of a turn of the wheel for me, given that I started out my CSS career with browser support leaderboards.  Now you can see who’s amassed the most spec points, and who’s made the most effective use of their time and energy.  Who knows?  Maybe some editors will try to game the system by pushing their specs along the process track.  That’d be just awful.

One thing of note: I decided to write the leaderboard script so that it directly parses an HTML file to figure out the rankings.  You can see the file yourself, if you like.  At the moment it’s just a bunch of dls, but at some point I suspect I’ll convert it to a table.  The advantage is that it’s easier for other people to fact-check the source data this way: just load it up in a browser.

I thought about just parsing specs directly but it seemed like overkill to load the entirety of the CSS2.1 module just to figure out the process status, publication date, and editor list.  And then do that same thing for every one of the 38 tracked modules.  This way I have the leaderboard and a central summary of the modules’ status, and hopefully the latter will be even more human-readable in the future.

Anyway, it was a fun little project and now it’s loose in the world.  Enjoy.

Reset v2.0

Earlier today, I updated the CSS Tools: Reset CSS page to list the final version of Reset v2.0, as well as updated the reset.css file in that directory to be v2.0.  (I wonder how many hotlinkers that will surprise.)  In other words, it’s been shipped.  Any subsequent changes will trigger version number changes.

There is one small change I made between 2.0b2 and 2.0 final, which is the replacement of the “THIS IS BETA” warning text with an explicit lack of license.  The reset CSS has been in the public domain ever since I first published it, and the Reset CSS page explicitly said it was, but the file itself never said one way or the other.  Now it does.

Thanks to everyone who contributed their thoughts and perspectives on the new reset.  Here’s to progress!

September 2015
SMTWTFS
August  
 12345
6789101112
13141516171819
20212223242526
27282930  

Archives

Feeds

Extras