Posts in the CSS Category

Border Imaging

Published 13 years, 10 months past

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!

Published 13 years, 10 months past
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!

Published 13 years, 10 months past

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!

  • Retreat! was published on .
  • It was assigned to the CSS and HTML5 categories.
  • There have been two replies.

Reset 2.0b2: Paring Down

Published 13 years, 10 months past

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

Published 13 years, 10 months past

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

Published 13 years, 10 months past

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


Smashing CSS

Published 14 years, 5 days past
Smashing CSS cover

Well, I done did it again: I wrote a book.  This time, it’s Smashing CSS: Professional Techniques for Modern Layout, published by Wiley and Sons and available as of some time last week.  (Just in time for the holiday gift-giving season!  Buy one for everybody in the family!  Don’t delay—act now!)

What’s different about this book as compared to others I’ve written is that this is a collection of short tips, tricks, and techniques for using CSS in everyday work.  Many of them involve making changes and seeing the results, similar to my New Riders books, but where those books had chapter-long projects these are usually only a page or three in length.  Well, okay, a few get up towards ten pages, but only on occasion.

Another difference is that Smashing CSS spans the spectrum from basic tools and browser features that can speed your development and debugging to some cutting-edge ideas and a taste of the latest CSS3 hotness.  I really do hope there’s something in it for everyone, and with something like a hundred entries, I think my odds are pretty good.

I’m especially happy that it’s in full color, which allowed me to do lots of screenshots as well as color-hinting of the markup and CSS, and personally I think it looks awesome.  I hope you’ll agree.  Check out the official catalog page at Wiley or comparison-shop at ISBN.nu, and thanks!

Update 19 Nov 10:  Kindle, ePub, and PDF versions of the book should be available within the next week.  They’re all in the hands of Wiley’s ebook distributor, so now it’s up to the distributor to get the files into the hands of ebook sellers.  On behalf of all you ebook fans, I hope it will happen soon!  (Is “ebook” the way we write that now?  I’m a little light on the lingo.)

Update 6 Dec 10: So far I’ve found the Kindle (mobi) and Nook (ePub) versions of the book.  Finding a good (read: legal) PDF version is proving difficult, so if anyone’s seen it out there, let me know so I can link away!


Vendor Prefix Lists

Published 14 years, 1 month past

At the prompting of an inquiry from a respected software vendor, I asked The Twitters for pointers to “canonical” lists of vendor-prefixed properties, values, and selectors.  Here’s what the crowd sourced at me:

Lists more than just prefixed properties, values, and so on.

While there’s no guarantee of completeness or accuracy, these are at least what the vendors themselves provide and so we can cling to some hope of both.  I was also pointed to the following third-party lists:

If you know of great vendor-prefix lists that aren’t listed here, particularly anything from the vendors themselves, please let us know in the comments!

Somewhat if not obviously related: does anyone know of a way to add full Textile support to BBEdit 9.x?  Having it be a Unix filter is fine.  I know BBEdit already supports Markdown, but since Basecamp uses Textile and lots of people I work with use Basecamp, I’d like stick to one syntax rather than confuse myself trying to switch between two similar syntaxes.


Browse the Archive

Earlier Entries

Later Entries