Posts from March 2011

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.

• Inconsistent Transitions was published on Thursday, March 24th, 2011.
• It was assigned to the Browsers and CSS categories.
• There have been fourteen replies.

I recently became re-acquainted with a ghost, and it looked very, very familiar.  In the spring of 1995, just over a year into my first Web gig and still just over a year away from first encountering CSS, I wrote the following:

Writing to the Norm

No, not the fat guy on “Cheers.”  Actually, it’s a fundamental issue every Web author needs to know about and appreciate.

Web browsers are written by different people.  Each person has their own idea about how Web documents should look.  Therefore, any given Web document will be displayed differently by different browsers.  In fact, it will be displayed differently by different copies of the same browser, if the two copies have different preferences set.

Therefore, you need to keep this principle foremost in your mind at all times: you cannot guarantee that your document will appear to other people exactly as it does to you.  In other words, don’t fall into the trap of obsessively re-writing a document just to get it to “fit on one screen,” or so a line of text is exactly “one screen wide.”  This is as pointless as trying to take a picture that will always be one foot wide, no matter how big the projection screen. Changes in font, font size, window size, and so on will all invalidate your attempts.

On the other hand, you want to write documents which look acceptable to most people.  How?  Well, it’s almost an art form in itself, but my recommendation is that you assume that most people will set their browser to display text in a common font such as Times at a point size of somewhere between 10 and 15 points.  While you shouldn’t spend your time trying to precisely engineer page arrangement, you also shouldn’t waste time worrying about how pages will look for someone whose display is set to 27-point Garamond.

That’s from “Chapter 1: Terms and Concepts” of Introduction to HTML, my first publication of note and the first of three tutorials dedicated to teaching HTML in a friendly, interactive manner.  The tutorials were taken down a couple of years ago by their host organization, which made me a bit sad even though I understood why they didn’t want to maintain the pages (and deal with the support e-mail) any longer.

However, thanks to a colleague’s help and generosity I recently came into possession of copies of all three.  I’m still pondering what to do about it.  To put them back on the web would require a bit more work than just tossing them onto a server, and to make the quizzes fully functional would take yet more work, and after all this time some of the material is obsolete or even potentially misleading.  Not to mention the page is laid out using a table (woo 1995!).  On the other hand, they’d make an interesting historical document of sorts, a way to let you young whippersnappers know what it was like in the old days.

Reading through them, now sixteen years later, has been an interesting little trip down memory lane.  What strikes me most, besides the fact that my younger self was a better writer than my current self, is how remarkably stable the Web’s fluidity has been over its lifetime.  Yes, the absence of assuredly-repeatable layout is a core design principle, but it’s also the kind of thing that tends to get engineered away, particularly when designers and the public both get involved.  Its persistence hints that it’s something valuable and even necessary.  If I had to nominate one thing about the Web for the title of “Most Under-appreciated”, I think this would be it.

• Same As It Ever Was was published on Monday, March 7th, 2011.
• It was assigned to the (X)HTML, Browsers, History, and Writing categories.
• There have been four replies.

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.