meyerweb.com

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

Archive: 2011

Welcome

Kat and I are now triply parents.  Earlier today we welcomed Joshua David Meyer into our home and our hearts.

We’ve had this name ready ever since we started out to build a family almost a decade ago.  We chose Joshua to honor Kat’s late aunt Judy, an incredibly strong and brave woman who faced adversity with a smile.  The middle name, David, honors Kat’s grandmother Dot and is also the name of one of my best and oldest friends.

Carolyn and Rebecca are both incredibly excited to have a baby brother and are helping take care of him (and us) as much as they can.  I’ll obviously be a bit distracted during the settling-in phase of having a newborn in the house, but with any luck I’ll manage to get a few things out the door during naps.

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?

August 2014
SMTWTFS
July  
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Archives

Feeds

Extras