Posts in the Tech Category

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.)

• Edit Your Head (Styles) was published on Friday, March 4th, 2011.
• It was assigned to the CSS category.
• There have been fourteen replies.

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!

• CSS3 Tests was published on Friday, February 11th, 2011.
• It was assigned to the CSS category.
• There have been fifteen replies.

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.

• CSS Editors Leaderboard was published on Friday, February 4th, 2011.
• It was assigned to the CSS, Standards, and W3C categories.
• There have been seven replies.

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!

• Reset v2.0 was published on Wednesday, January 26th, 2011.
• It was assigned to the CSS, Projects, and Tools categories.
• There have been twenty-five replies.

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 Redux was published on Wednesday, January 26th, 2011.
• It was assigned to the CSS category.
• There have been two replies.

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.

• Border Imaging was published on Monday, January 24th, 2011.
• It was assigned to the CSS category.
• There have been thirty-nine replies.

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.)

• CSS3 in HTML5? HTML5 in CSS3! was published on Tuesday, January 18th, 2011.
• It was assigned to the CSS category.
• There have been twenty-seven replies.

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 Thursday, January 13th, 2011.
• It was assigned to the CSS and HTML5 categories.
• There have been two replies.