meyerweb.com

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

Archive: January 2011

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!

Border Imaging Redux

To follow up on my border-image post from Monday, it turns out that as currently written, border-image literally cannot take an image of a single symbol and repeat it around the border of an element.  Instead, you have to create an image with at least eight copies of the symbol in a 3×3 grid pattern.

Note that allowing a 3×3 grid pattern for border-image is potentially very useful, as it permits the creation of sophisticated border ‘frames’ with a single image.  The objection I have is that it’s required, even in simple cases like the one I described in the previous post.

The reason this 3×3 pattern is required is found in the description of border-image-slice, which states:

The regions given by the ‘border-image-slice‘ values may overlap. However if the sum of the right and left widths is equal to or greater than the width of the image, the images for the top and bottom edge and the middle part are empty, which has the same effect as if a nonempty transparent image had been specified for those parts. Analogously for the top and bottom values.

That means that if you specify, for example, a slice distance of 100% (the default) then the top, bottom, and side portions of the border will be completely empty.  Only the corners will get the image.  The same thing will happen in any case where the sum of two slices along the same axis exceeds the dimension of the image along that same axis.  In other words, if the defined left and right slice distances add up to more than the width of the image, then both slices are made completely transparent.  Ditto for top, bottom, and height.

It seems to me that the easy way to make it possible to repeat a single-symbol image is to change that bit to instead say something along these lines:

The regions given by the ‘border-image-slice‘ values may overlap.  Values greater than the intrinsic dimensions of the image are “clipped” to the intrinsic dimensions of the image.  Values greater than 100% are treated as 100%.  Negative values are treated as 0.

Or maybe going beyond 100% or the image dimension means filling the remainder with transparency—I’m not sure yet which would be better.  I’d be interested to know if anyone has a compelling use case for the “fill transparent past 100%” behavior.

Anyway, when I raised the beginnings of this as a possibility on www-style, I was told that an “older and less mature” draft did exactly that, but it was at some point changed to the current behavior.  My inquiry as to the reasons for that change have so far been met with silence, so if necessary I’ll raise it again in a few days.

Commenters found that WebKit browsers can be made, with a very specific value pattern, be made to repeat a single-symbol image all the way around a border.  It turns out that’s only because WebKit implements the earlier version of the specification and it hasn’t since been updated.  Personally, I hope it retains its behavior (with improvements to make it less finicky) and the other rendering engines change to match it, not the other way around.  But to make that happen, I suspect the spec will need to be changed.  Here’s hoping.

Border Imaging

As I dig into the nooks and crannies of the various CSS3 modules, I’ve come across something that seems like I should be able to do, but I can’t make it work in browsers.  Now, I know as well as anyone that if you try to do something and browsers won’t do it, it might well be the fault of the browsers.  Particularly if you can get various browsers to fail differently on the same declaration, as I have.  But this is, bizarrely, complicated enough that it’s hard to be sure if it’s me or them.

So allow me to pose this to you as a challenge.  Given the following ideal rendering, how would you arrive at the depicted result using the single 5-pixel-by-5-pixel image shown within the content?

Note that it doesn’t have to be quite as clean as this—if there are partial diamonds adjacent to the corners where repeated images get clipped, that’s fine.

Should you answer, please be clear which type of answer you’re giving:

  1. What the specification says you should write to make this happen.  Note to those tackling this fresh: I think the descriptive prose for border-image-slice (yes, -slice) makes this harder than it seems, but I could be wrong.
  2. What you wrote to get browsers to do it consistently.  (Safari, Firefox, and Opera at a minimum.  Did IE9 get border images yet?  Vendor prefixes not required unless you had to write different values for different browsers.)
  3. Both spec- and browser-friendly, which is of course what we really want.

I’m really curious to see if anyone cracks this one, because that person I will grill mercilessly until either I understand what’s happening or one of us starts plotting to have the other killed.

CSS3 in HTML5? HTML5 in CSS3!

HTML5 logo

The W3C unveiled a new logo and branding strategy today.  (You might have heard.)  It brings all the deliciousness of a Soviet-era Transformers logo to the yummy conflation of several related technologies!  Did you get your WOFF in my HTML, or did I get my CSS all over your HTML?

As per usual, a lot of people have said a lot of things about this.  For my part, I figure, hey, given that CSS3 is now a branded part of your nutritious HTML5 breakfast, why not go with the flow?  So I did.  You’re welcome.

(Disclaimer: it’ll look best in recent WebKit, Gecko, or Opera browsers, but it’s at least comprehensible in them what doesn’t yet support CSS transforms.  May not be valid in all jurisdictions.  Not a flying toy.)

Retreat!

Hey, any interest in spending a few days in a luxury lodge in the Great Smoky Mountains this coming spring with me and Aaron Gustafson, learning about and working with HTML5 and CSS3?  Then you might want to sign up for Retreats 4 Geeks: HTML5 & CSS3 in the very near future, because it was announced late yesterday and as of now there are only six spots still available.  It’ll be a very focused two days of training and a day of hands-on project work with a very small group of people, and it’ll be a ton of fun!

Personally I’m looking forward to this for many reasons, but two stand out:  this sort of very-small-group training and team project work setup is a new thing for me, and it’s the sort of thing I’ve thought about doing on and off for more than a decade but never quite found the time to do.  Aaron, thankfully, did find the time and I’m honored that he asked me to take part.  I hope I’ll see some of you this April in Tennessee!

Reset 2.0b2: Paring Down

A few changes for beta 2 of the updated reset, presented here:

/* http://meyerweb.com/eric/tools/css/reset/ 
   v2.0b2 | 201101
   NOTE: THIS IS A BETA VERSION (see previous line)
   USE WITH CAUTION AND TEST WITH ABANDON */

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed, 
figure, figcaption, footer, header, hgroup, 
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
	margin: 0;
	padding: 0;
	border: 0;
	font-size: 100%;
	font: inherit;
	vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure, 
footer, header, hgroup, menu, nav, section {
	display: block;
}
body {
	line-height: 1;
}
ol, ul {
	list-style: none;
}
blockquote, q {
	quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
	content: '';
	content: none;
}
table {
	border-collapse: collapse;
	border-spacing: 0;
}

First, the small changes: adding embed, output, and ruby to the first rule.  I went back and forth on these quite a bit, which is why they weren’t in the first cut.  However, none of them seem to be replaced so they’re in.  Others, such as command, are replaced and so stay out for the same reason that form inputs are left out.  (img is a special case.)

The HTML5 element I’m still stuck on is datalist, which seems sort of replaced but then again maybe not.  I’m really close to including it on the same grounds that I include canvas, but it’s hard to know if that’s a good idea.  If anyone with deep experience with datalist could explain what element it’s most like, and whether it’s really replaced or what, please do so.

Now the big changes: I removed the outline declaration from the first rule, which was option #2 in “Looking For Focus“.  I’d largely decided that was the best solution before I posted, but I didn’t want to say so for fear of skewing the responses either way.  It was interesting to see how that option initially didn’t come up very much, and then suddenly a bunch of people stumped for it.  Anyway, that course of action seems to make the most sense to me; for the reasons why, the comments of those who supported it pretty much sum up my thoughts.  With that declaration out, there’s no need to do anything special for :focus in subsequent rules.

Following on that, the other change is that I’ve dropped the :focus rule entirely, and also the ins and del rules.  Why?  Because all three of them are attempting, in some fashion, to impose a presentation above the baseline that the reset attempts to establish.  I basically left text-decoration alone in this reset; reset and del were the exceptions.  I can’t justify those exceptions any longer.

The rule for ins was actually interesting: it was, in spirit, exactly the same as the :focus rule.  Here’s a comparison:

/* remember to define focus styles! */
:focus {
	outline: 0;
}

/* remember to highlight inserts somehow! */
ins {
	text-decoration: none;
}

Both strip off a common visual styling and remind authors to define something visible.  Of course, pretty much nobody ever complained about the ins rule, but they’re conceptually the same and so if one goes, both should go.  And if I’m not keeping the ins rule, I can’t see any reason at all to keep the del rule.

So that’s where we are in beta 2.  I’ll be interested to know what you think.

Looking For Focus

In the reset revision draft I posted Monday, I got tripped up by some last-minute changes and I’m going to think out loud (so to speak, as it were) about possible solutions.

The problem is that the presence of a in the first rule means that focus outlines on hyperlinks are removed.  Thus in commenting out the :focus rule I restored default focus styles to form elements, but not hyperlinks.  This wasn’t a problem up until roughly a day before I published, but last-minute tinkering brought it back.  I’d say that’ll teach me not to tinker, but I hate to lie.

I’ve come up with the following solutions.  Consider them as mutually exclusive.

  • Remove a from the first rule.  This would exempt it from being reset at all.  On the one hand, this means that focus defaults are restored.  On the other hand, by exempting an (incredibly pervasive) element from the list, it does violate the spirit of element agnosticism I try to follow.  On the gripping hand, that first rule doesn’t do much to reset links as it is: their text-decoration and color properties are not altered.  Back in 2007 the color would have been thanks to a color: inherit declaration, but that was dropped at the time and I don’t think it’s likely to return.  Even if it does, the question of exempting a would remain and possibly even deepen.

  • Remove outline: 0 from the first rule.  The only things I can think of that get outlines are focused form elements, which the reset doesn’t touch; and focused hyperlinks, which I’m trying to avoid touching in the first place.  That’s not very forward-looking, though.  Outlines could start showing up in future browsers or on future elements.

  • Define explicit a:focus styles, as the HTML5 Doctor reset does.  This overcomes the problem of focus-stripping, but imposes a specific focus appearance.  That violates the entire spirit of the reset.  Of course, it’s not as though there’s much variance in how browsers present link focusing, and it’s pretty easy to write a rule that would be mistaken for browser defaults by just about anyone.

In the process of writing this out, I think I’ve mostly settled on which choice I prefer, but I’d like to hear what you think.  Which option strikes you as best, and why?

Reset Revisited

It was close to four years ago now that I first floated (ha!), publicly refined, and then published at its own home what’s become known as the “Eric Meyer Reset”.  At the time, I expected it would be of interest to a small portion of the standards community, provoke some thought among fellow craftspeople, and get used occasionally when it seemed handy.  Instead, it’s ended up almost everywhere.

(This occasionally backfires on me when people use it in the CSS of e-mail campaigns, it’s exposed by older mail clients, and people then mail me to demand that I unsubscribe them from the mailing list.  But that’s not the worst backfire—I’ll get to that in just a minute.)

Four years is long enough for a revisit, I’d say.  I spent a little time working on and thinking about it over the holidays.  Here’s where I ended up.

/* http://meyerweb.com/eric/tools/css/reset/ 
   v2.0b1 | 201101 
   NOTE: WORK IN PROGRESS
   USE WITH CAUTION AND TEST WITH ABANDON */

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, figcaption, figure, 
footer, header, hgroup, menu, nav, section, summary,
time, mark, audio, video {
	margin: 0;
	padding: 0;
	border: 0;
	outline: 0;
	font-size: 100%;
	font: inherit;
	vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure, 
footer, header, hgroup, menu, nav, section {
	display: block;
}
body {
	line-height: 1;
}
ol, ul {
	list-style: none;
}
blockquote, q {
	quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
	content: '';
	content: none;
}

/* remember to define visible focus styles! 
:focus {
	outline: ?????;
} */

/* remember to highlight inserts somehow! */
ins {
	text-decoration: none;
}
del {
	text-decoration: line-through;
}

table {
	border-collapse: collapse;
	border-spacing: 0;
}

Some of you may be thinking: “Hey, it’s the HTML5 Doctor reset!”  Actually, no, though I did use their work as a check on my own.  I felt like that one went a bit far, to be honest.  What I have above is simply the reset I had before with the following changes:

  • Removed font from the selector of the first rule.  It’s been long enough now, I think.  We can let that one go.
  • Removed background: transparent from the declaration block of the first rule.  I don’t think it really served any purpose in the long run, given the way browsers style by default and the CSS-defined default for background-color (which background encompasses, of course).  Its removal will also stop causing table-appearance glitches in old versions of IE, if that’s of interest.
  • Added font: inherit to the declaration block of the first rule.  There are still older versions of IE that don’t understand inherit, but support is now widespread enough that I feel this can go in.  I left font-size: 100% as a sop to older browsers, and override it with the next declaration in those browsers that understand.
  • Added HTML5 elements to the selector of the first rule.  While this is probably unnecessary right now, those elements being about as styled as a common div, it’s in the spirit of the thing to list them.
  • A separate rule to make blocks of those HTML5 elements that generally default to blocks.  This is more backward-looking, as the comment suggests, and it’s a prime excision candidate for anyone adapting these styles to their own use.  However, if you’ve ever known the pain of HTML5 markup shattering layouts in, say, older versions of Firefox, this rule has a place.
  • Removed the “cellspacing” comment near the end.  It used to be the case that lots of browsers needed the support, but that’s a lot less true today.
  • And then the big one, trying to correct the biggest backfire of the whole enterprise: I commented out and subtly altered the commentary on the :focus rule without removing it entirely.

On that last point, defining an invisible focus was the biggest blunder of the original reset.  In hindsight, it’s really a obvious unforced error, but when I published the reset I literally had no conception that it would be just copied (or, worse, hotlinked) blindly in a thousand sites and frameworks.  As the new advocacy site outlinenone.com points out, I did say right in the style sheet that one should define a focus style.  I put in a value of 0 in the same spirit I zeroed out paragraph margins and set the body element’s line-height to 1: by taking everything to a “plain baseline”, the thoughtful craftsperson would be reminded to define the focus style that made most sense for their site’s design.

Instead, focus outlines were obliterated wholesale as lots and lots of people, not all of them craftsmen, just copied the reset and built on top of it without thinking about it.  I can’t find it in my heart to fault them: most construction workers don’t think about how beams and rivets or even riveters are made.  They just bolt ‘em together and make a building.

Perhaps some of the pain would have been eased if I had said in the comment, as I do now, “remember to define visible focus styles”.  But I doubt it.

So in this revision, I’ve altered the rule and commentary to raise its visibility, but more importantly I’ve commented out the whole rule.  This time, copiers and hotlinkers won’t destroy focusing.  Some may still uncomment it and change the value back to 0, of course, but that could happen anyway.  With luck, this change will help educate.

As was the case in 2007, comments and suggestions are most welcome, and may well result in changes that make it into the final version.  Also, my thanks to the HTML5 Doctor crew for publishing their variant, which I used as a sanity check; and Michael Tuck, whose research into the history of resets got me looking back and interested in moving things forward.

Addendum 3 Jan 11:  as the previous paragraph says, and the version number (2.0b1) heavily implies, this is not a final version.  It may well change, either due to errors on my part (one of which has already come to light) or changes of mind due to discussions in the comments.  You can take this version and use it if you want, but I don’t particularly recommend it because—again—changes are likely.

Translations

January 2011
SMTWTFS
December February
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Archives

Feeds

Extras