Wednesday, July 29th, 2009

Text rotation for all

Category: CSS, Tip

<p>Jonathan Snook has posted a nice nugget on text rotation with CSS that takes a nice bit of markup like this:

  1. <div class="example-date">
  2.   <span class="day">31</span>
  3.   <span class="month">July</span>
  4.   <span class="year">2009</span>
  5. </div>

and converts it to:

all via the CSS:

  1. -webkit-transform: rotate(-90deg);
  2. -moz-transform: rotate(-90deg);
  3. filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=3);

Yup, even IE.

Posted by Dion Almaer at 10:20 am
31 Comments

++++-
4.3 rating from 59 votes

31 Comments »

Comments feed TrackBack URI

Before anyone goes complaining about how the standards nuts poopoo Microsoft for CSS extensions but give Mozilla/Apple a free pass, look at that syntax. Beyond the fact that Mozilla and Apple are pushing for standardization of the extension, the MS extension is idiotic. 3, really? Nevermind the complexity of targeting their internal rendering engine’s structure.

With that said, when the marketshare of the WebKit/Gecko browsers that support this reaches a critical mass of those vendors’ users, this is going to be awesome to be able to do.

Comment by eyelidlessness — July 29, 2009

For older versions of FF / safari and opera support, as well as better rendering, see http://css-tricks.com/date-display-with-sprites/ for an image sprite version.

It uses a sprite and some CSS, but in my opinion that’s better than less browser support.

Comment by youngestlinton — July 29, 2009

Also, from snook, IE can also rotate the text and keep ClearType by using writing-mode: tb-rl

Comment by eyelidlessness — July 29, 2009

VERY kewl layout…

However…hmm…Makes me wonder about what September or December would look like. First 3 or 4 characters?

JD

Comment by jdanylko — July 29, 2009

@eyelidlessness: You’re mixing two separate issues.

If you want to debate whether MS’s implementation is crap… well, you won’t get a whole lot of argument from me :) You’re right, “3″ is pretty horrid API design. But, the fact that you’re making use of aDirectX filter, which is what the MS version of the code is doing, is extremely cool on its own (and could open up a world of other possibilities if extended).

The other issue is that of standards, and that’s where I disagree.

MS shouldn’t catch flack for it any more than the other two should because if it wasn’t for stuff like this, and interface/features of a given browser over another, what would ever differentiate browsers? It’s things like this that move standards along because if we all stuck 100% to standards, and that’s what the vendors implemented in their browsers, we’d all be up in arms about how much power we weren’t being given :)

The point is, if someone is going to hammer MS for non-standard extensions, you need to hammer Mozilla, Apple (and Opera, I’d assume) just as much. That’s one choice. Or you hammer none of them at all. I personally prefer the second option since it puts more power in the hands of us developers and ultimately, if slowly, informs the standards down the road. It’s the double standard that is so prevalent which is untenable IMO.

Comment by fzammetti — July 29, 2009

Is that only possible angle 90? What if I want my text to be 15 degrees?

Comment by gustavs — July 29, 2009

@gustavs: Firefox and Safari support any arbitrary angle, I’m not sure about IE.

Comment by MattCoz — July 29, 2009

IE only supports rotation at right angles:
http://msdn.microsoft.com/en-us/library/ms532918%28VS.85%29.aspx

Incidentally, these are the other filters it supports:
http://msdn.microsoft.com/en-us/library/ms532972%28VS.85%29.aspx
This includes grayscaling, inverting, masking and mirroring.

Comment by Joeri — July 29, 2009

“You’re mixing two separate issues.”

Agreed. And I meant to, and said as much.

“MS shouldn’t catch flack for it any more than the other two should because if it wasn’t for stuff like this, and interface/features of a given browser over another, what would ever differentiate browsers?”

Why the heck would anyone want to differentiate browsers from a development perspective? The whole point of standards is to standardize, so that the same code produces the same results. That’s what an API is for. The standard, however, provides an extension mechanism, so that new features can be put into the wild and gain support for standardization. Whether or not Microsoft (or any other browser vendor) catches flack for this should be directly proportionate to the degree to which the vendor engages in the standardization process (extending and pushing for standardization: good; extending otherwise: bad).

Where my points converge, and where they should converge, is that even if Microsoft played nice with standards bodies, which they don’t, their API sucks and doesn’t stand a snowball’s chance in hell of being adopted. The poor API design (or rather, the API design to tie IE-specific code to Microsoft-stack-specific APIs) is part of the way Microsoft flouts standardization.

“It’s things like this that move standards along because if we all stuck 100% to standards, and that’s what the vendors implemented in their browsers, we’d all be up in arms about how much power we weren’t being given :)”

I don’t really think that’s true. The standards have a lot of great features that aren’t available for use because of a lack of consistent implementation across browsers. That is what most of us are up in arms about.

“The point is, if someone is going to hammer MS for non-standard extensions, you need to hammer Mozilla, Apple (and Opera, I’d assume) just as much.”

No, the point is that Microsoft’s extensions are not equivalent to the other vendors’ extensions. Not because Microsoft is Microsoft, but because Microsoft doesn’t extend in good faith toward the standardization process (both in terms of behavior and in terms of API design).

“It’s the double standard that is so prevalent which is untenable IMO.”

I agree there’s a double standard and that it’s untenable; what I’m saying is that the double standard is that Apple and Mozilla get the same criticism Microsoft gets, for entirely different behavior. Mainly this is because most of the criticism comes from people who don’t take the time to learn about the differences in behavior. And usually as an extension of taking an ignorant and dogmatic stand against extension in order to reconcile or parody dogmatic Microsoft hatred.

Comment by eyelidlessness — July 29, 2009

“Why the heck would anyone want to differentiate browsers from a development perspective?”

Because that is, unfortunately, the way it has to be. Standards bodies move slooooooowly, and if vendors waited for finalized specs to implement we’d have less capability available to use as developers. It is, I think, a necessary evil, and I think you sort of say as much. The only way new features are introduced is for vendors to implement them on their own. Then, us developers choose which live and die by using them or not, and eventually they get adopted, or not, by standards bodies. The real problem is not that this happens but the fact that it takes so damned long. That, and as you said, the fact that all vendors don’t implement the existing standards equally, but more on this shortly :)

“The whole point of standards is to standardize, so that the same code produces the same results. That’s what an API is for.”

Agreed… but we’re not here talking about different results, we’re talking about different implementations of the same non-standard thing. I’m sure you aren’t arguing that MS should get together with Mozilla, Apple and Opera and agree on an implementation independent of standards bodies, are you? That would be a nice world to live in, but not a realistic one :)

“Whether or not Microsoft (or any other browser vendor) catches flack for this should be directly proportionate to the degree to which the vendor engages in the standardization process (extending and pushing for standardization: good; extending otherwise: bad).”

This is where I disagree and where I see a contradiction. Either a vendor can extend standards, in whatever way they want, or they can’t. They’re under no obligation in any way. Just because one vendor doesn’t fully support existing standards doesn’t mean they can’t offer extensions. They may be setting themselves up for an epic fail in that case, but it’s their choice.

Remember, no vendor is under any obligation to implement standards. I of course think they should, *fully*, but I have a choice too: don’t support them if they don’t. I don’t think a person can say that a vendor can’t extend until they’ve fully implemented existing standards. That’s like saying I put a pool in my backyard, but I can’t go in it until I build the deck around it because everyone else has a deck (and has agreed to have a deck). No, I can use the pool to the extent I can and want to… or I can go to my neighbor’s house and enjoy his pool AND deck :) My choice. Likewise, my friends can go to my neighbors’ house instead of mine. Their choice.

“No, the point is that Microsoft’s extensions are not equivalent to the other vendors’ extensions. Not because Microsoft is Microsoft, but because Microsoft doesn’t extend in good faith toward the standardization process (both in terms of behavior and in terms of API design).”

Geez, I hate to sound like an MS booster because that’s just not accurate, but… is their behavior really any different than the other vendors? I mean, we have three different implementations of the same text rotation concept here. Sure, two vendors seem to have agreed on the value you set the attribute to, maybe just by chance, I don’t know, but the attribute name is different and therefore the API can’t be said to be the same because the API is not just the attribute value but also the attribute name. Sure, those two vendors are far closer together and probably more along the lines of what the standard will ultimately be, abd I certainly agree that MS’s implementation is WAY out in left field as compared to the others, but so what? That’s their choice.

Our choice, as developers and consumers, is to decide which implementation we’re going to support, until the standards bodies step in and decide for us (and the vendors implement them). Hell, they *could* decide that MS is onto something and their API should be the standard! I think we can assume that’s not going to happen, but it *could*, and that’s what makes it OK, that and the fact that we have a choice right now.

You know, this is actually a pretty bad example to argue about frankly because MS started offering these types of capabilities in like 1998 or so… they were WAY out ahead of others in this situation. Clearly, no one likes their implementation very much or it would likely be the standard today :) So, things are kinda working as they should be. It’s not really fair for anyone (not saying you did this by the way) to criticize them for something they did BEFORE the “standard” was announced. That would be like killing the Wright brothers for their aircraft design because we standardized on jet engines decades after :) (and before anyone says it, I realize we haven’t standardized on jet engines, but I think you get my point anyway)

Comment by fzammetti — July 29, 2009

I won’t hammer Microsoft for innovating new non-standard differentiators. But I’m willing to hammer Microsoft for not implementing what shows up in Firefox, Chrome, Safari, and Opera. We still do not have Canvas in IE8. If the Opera guys can manage, why can the behemoth? To this day, we’re using an emulation layer in JS to get Canvas stuff running. It’s, needless to say, rather slow.

So go ahead, Microsoft, break new ground. But don’t leave empty holes where everyone else has managed to agree.

Comment by Nosredna — July 29, 2009

Forgot to reply to this, because I think it’s an interesting point:

“I don’t really think that’s true. The standards have a lot of great features that aren’t available for use because of a lack of consistent implementation across browsers. That is what most of us are up in arms about.”

You’re totally right, there are parts of various standards we can’t use because of browser implementations. and that totally sucks. But that’s placing the blame in the wrong place IMO… don’t blame vendor A for not supporting standard feature B, blame the people that still insist on supporting vendor A with their business!.

We’re at a point where no one is being forced to use any vendors’ browser any more, that’s an old argument that doesn’t, IMO hold water any longer. That being said, we need to start blaming the people that insist on acting like that’s still true, and we need to be evangelists to get people to make the… ahem… “hard”… choice. If IE isn’t getting the job done, switch. If that means we as developers have to stop supporting IE, then so be it.

Now, I realize this is a pretty utopian comment to make… if I wrote an app that didn’t work in IE at my job I’d be in trouble because we’re an IE-only shop. That doesn’t however mean that I can’t and shouldn’t evangelize about why we shouldn’t be on IE any more, and standards support is the biggest reason IMO (not so sure security is a big differentiator any more). And there may even be some cases where I can degrade the experience for IE and be like “well, too f’ing bad, get on a standards-compliant browser”… err, in a slightly more politically-correct way of course :)

I still think it’s true that vendors will pretty much always be out ahead of standards bodies in terms of implementing functionality, and that’s the point I was making: if we completely ignored vendors’ extensions and stuck to standards we’d be depriving ourselves of some powerful tools. You’re right though, the delta between what the vendors provide and what the standards provide maybe isn’t as far apart as it once was.

Comment by fzammetti — July 29, 2009

@Nosredna: The way to handle that situation though is to try and get people to switch vendors. We have a pattern when it comes to IE, we know how MS does things. If they just simply missed support for canvas but were otherwise good we’d be pretty confident they’d implement it and be good to go with the next release. We know that’s not how it works though, and ultimately they have no obligation to do otherwise.

Rather than trying to change their behavior, let’s sidestep the problem entirely and get people off IE as much as possible. Not easy, not trivial, and in many cases not even possible, but we can and should try. Sure, it’s an idealistic goal that is probably a fool’s errand, but it’s worth doing, and in the end is probably less the fool’s errand than trying to get MS to truly embrace standards :)

Comment by fzammetti — July 29, 2009

“Because that is, unfortunately, the way it has to be. Standards bodies move slooooooowly, and if vendors waited for finalized specs to implement we’d have less capability available to use as developers.”

You didn’t answer my question. Why would a developer want to differentiate between browsers? I’m not asking why a developer would want extensions (I think we agree they are a net positive), I’m asking why a developer would want to treat one browser differently than another.

“Agreed… but we’re not here talking about different results, we’re talking about different implementations of the same non-standard thing.”

Er, you were promoting differentiating browsers; different results is a necessary conclusion of that.

“I’m sure you aren’t arguing that MS should get together with Mozilla, Apple and Opera and agree on an implementation independent of standards bodies, are you? That would be a nice world to live in, but not a realistic one :)”

No, I’m arguing that Microsoft should take the same approach Apple and Mozilla currently take: implement extensions that are consistent with existing standard APIs, and then push for standardization of those extensions. I spelled it out in my last comment. Microsoft does neither.

“This is where I disagree and where I see a contradiction. Either a vendor can extend standards, in whatever way they want, or they can’t.”

If they claim to support standards and interoperability, they should use the standard’s extension mechanisms. If they don’t do so, they are lying about their support for standards and interoperability, and are therefore going to catch flack.

“They’re under no obligation in any way. … Remember, no vendor is under any obligation to implement standards.”

They’re certainly under some obligation. As any other vendor, they have an obligation to fulfill their promises. By adopting the CSS standard, they have an obligation to use the standard’s extension mechanisms. They’re not under any obligation to adopt the CSS standard, but they certainly have claimed adoption. In short, they have an obligation not to mislead their customers.

“Geez, I hate to sound like an MS booster because that’s just not accurate, but… is their behavior really any different than the other vendors?”

Yes!

“I mean, we have three different implementations of the same text rotation concept here. Sure, two vendors seem to have agreed on the value you set the attribute to, maybe just by chance, I don’t know, but the attribute name is different and therefore the API can’t be said to be the same because the API is not just the attribute value but also the attribute name.”

You’re wrong. The Mozilla and Apple implementations are identical, and according to the standard’s extension mechanism. The prefix (-moz-, -webkit-, -ms-, -o-, et al) is not part of the property, it indicates a vendor-specific extension namespace. Even Microsoft has adopted that in IE 8′s “real” standards mode. The property is “transform”. Mozilla and Apple are correctly following the extension mechanism in CSS to introduce new features by keeping their extensions out of the global namespace in order to await final standardization.

“but so what? That’s their choice.”

Not if their claim to support standards and interoperability holds any water. They catch flack for flouting what they claim to support, not for failing to meet expectations from on high.

“Hell, they *could* decide that MS is onto something and their API should be the standard! I think we can assume that’s not going to happen, but it *could*, and that’s what makes it OK, that and the fact that we have a choice right now.”

I think this ignores the fact that CSS as an API is generally consistent, and that extensions to CSS are adopted in a manner consistent with the existing API. Microsoft’s extension is basically disqualified from the outset by being syntactically inconsistent, not to mention tying the syntax to its own internal, proprietary APIs (DirectX).

“You know, this is actually a pretty bad example to argue about frankly because MS started offering these types of capabilities in like 1998 or so… they were WAY out ahead of others in this situation.”

I don’t think it’s a bad example, because my point applies to all of Microsoft’s CSS extensions. They could have resolved this easily by providing API-consistent aliases to their internal functionality within IE 8′s “real” standards mode (eg -ms-opacity: [decimal >=0 <=1] as an alias to -ms-filter: [DX crap]). Nobody cares that they use DirectX to implement the functionality (except insofar as it produces inconsistent results), just that they require non-standard code to achieve the desired result. They’re making us work harder and code more than necessary. They’re unnecessarily costing us time and money.

“It’s not really fair for anyone (not saying you did this by the way) to criticize them for something they did BEFORE the “standard” was announced.”

The vendor prefix for keywords (properties, values) was introduced with CSS 2.1 in 2005. http://www.w3.org/TR/CSS2/syndata.html#vendor-keywords

IE 8 began development in 2006 and was released in 2009. IE 8 claims to fully support CSS 2.1, but I think its handling of extensions is only according to the letter, rather than the spirit, of the standard.

“don’t blame vendor A for not supporting standard feature B, blame the people that still insist on supporting vendor A with their business!.”

What are we supposed to do, block 75% of web traffic? I think by doing that we’d be breaking our own (implicit) obligations; obviously this is more or less tenable depending on the purpose of our websites/applications and their respective target audiences, but you get the point.

“We’re at a point where no one is being forced to use any vendors’ browser any more, that’s an old argument that doesn’t, IMO hold water any longer.”

That’s false. A huge percentage of IE users, for example, are disallowed by their employers from installing a new browser. Including, apparently, you!: “we’re an IE-only shop.”

“I still think it’s true that vendors will pretty much always be out ahead of standards bodies in terms of implementing functionality, and that’s the point I was making: if we completely ignored vendors’ extensions and stuck to standards we’d be depriving ourselves of some powerful tools. You’re right though, the delta between what the vendors provide and what the standards provide maybe isn’t as far apart as it once was.”

I just want to reiterate to be clear: I’m for vendor extensions to CSS, provided the extensions are done according to both the letter and spirit of the standard. There is only one exception to that, which is if the standard itself is incapable of supporting a given feature, in which case a new standard should be proposed. As far as I’m aware, the CSS standard is perfectly capable of including the functionality of Microsoft’s extensions, but those extensions fly in the face of the standard’s API. If Microsoft wants credit for supporting the standard, they need to actually support it rather than paying lip service to it.

Comment by eyelidlessness — July 29, 2009

Nobody in their right mind would make extensive use of them now, but back in the day (somewhere around 10 years ago), CSS expressions were actually a pretty good innovation.

Personally, I don’t think “rotation=3″ was all that difficult to write. But, at least, I think most everyone can agree the modern proprietary syntax is easier (transform: rotate…)

Also, you can use ‘-ms-filter:’ to make the text rotation work in IE8 in standards mode

Comment by WillPeavy — July 29, 2009

The problem isn’t that “rotation=3″ is hard to write, it’s that progid:DXImageTransform.Microsoft.BasicImage references the proprietary DirectX API, and that “rotation=3″ disregards CSS conventions both descriptively (3 does not actually describe the degrees of rotation) and syntactically (=).

Comment by eyelidlessness — July 29, 2009

Oh and, I think CSS expressions is still a good idea, but should probably be proposed as a whole new CSS module so issues with it can be ironed out. I think it should be implemented, but with CSS-consistent syntax, without reliance on JS, and with strict rules for redraw/reflow in order to ensure good performance. For example, syntax would be like

width: expression(100% – 16px);

And redraw/reflow would only occur when the container’s width changes (as is the case with width: 100%). As far as internal implementation, this could be accomplished by maintaining calculation adjustments (eg -16) to apply when the variable measurement is calculated, eg instead of [pseudocode]

element. positionedParentNode.onwidthchange = function() {
element.currentStyle.width = 1 * this.currentStyle.width;
};

use [again, pseudocode]

element.positionedParentNode.onwidthchange = function() {
element.currentStyle.width = (1 * this.currentStyle.width) + element.__expression.width;
};

where element.__expression.width would represent the static width expression adjustments (-16).

With these considerations, CSS expressions could still be tenable, and would be extremely useful.

Comment by eyelidlessness — July 29, 2009

@eyelidlessness – As far as the DirectX goes – I think everyone (including the people at MS) agreed, a long time ago, that the way their CSS expressions were implemented is bad. That’s why MS deprecated it.

As far as the “rotation=3″ goes – I understand some people don’t like the syntax. That’s fine with me. The syntax was created in a different era when essentially you had a Netscape standard and an IE standard. But for me (this is me personally, I can’t say how anyone else thinks), it was never difficult to use or understand that rotation=1 rotates 90deg, rotation=2 rotates 180deg, rotation=3 rotates 270deg.

Comment by WillPeavy — July 29, 2009

WillPeavy,

I’m not actually faulting Microsoft their expressions implementation. I’m saying that it’s a good idea, and deserves a good standard and good implementations. And I provided some thoughts on how that might look.

I’m also, again, not saying that the rotation syntax is hard to understand. I’m saying it’s poor syntax and a poor API. And that the syntax was created so long ago isn’t really an excuse, as it was translated to IE 8′s supposedly “correct” CSS 2.1 implementation.

Comment by eyelidlessness — July 29, 2009

Since Microsoft doesn’t even have to think about Macintosh or Linux when it makes IE, we really can’t expect a very board view out of the. I’m convinced it will eventually hurt them. It already has, given their browser share market drop.

Comment by Nosredna — July 29, 2009

Well, IE does support arbitrary rotation angles by using a matrix:

var deg2radians = Math.PI * 2 / 360;

//oObj input requires an matrix filter applied.
//deg input defines the requested angle of rotation.
{ rad = deg * deg2radians ;
costheta = Math.cos(rad);
sintheta = Math.sin(rad);

oObj.filters.item(0).M11 = costheta;
oObj.filters.item(0).M12 = -sintheta;
oObj.filters.item(0).M21 = sintheta;
oObj.filters.item(0).M22 = costheta;
}

Not the best-looking API around, but ah.

Comment by MartijnHoutman — July 30, 2009

Oh, forgot to mention the filter to use:


filter:progid:DXImageTransform.Microsoft.Matrix(sProperties)

Comment by MartijnHoutman — July 30, 2009

@eyelidlessness – I see what you’re saying. I may be biased because I learned how to build webpages on IE specific expressions, so its syntax became natural looking by association. I think everyone can agree, though, that this syntax “transform:rotate(-90deg)” is nicer and easier.

I think something like this would be good “width:50% – 16px;” – it would be more accurate than trying to accomplish the same with “width:48%;” , or playing with margins and relative positioning to fit something in.

Comment by WillPeavy — July 30, 2009

@Martijn – ha! Nice.

Comment by WillPeavy — July 30, 2009

In regards to the “rotation=3? argument, The API was probably originally designed for a language that supported the use of enum.

Comment by TNO — July 30, 2009

WillPeavy,

I think if we’re going to add maths to the CSS standard, it should be within a function (eg expression()), if only to avoid people assigning mathematical values without understanding the consequences.

TNO,

It was clearly designed as the DirectX API, as it calls DirectX functionality against the DirectX API structure.

Comment by eyelidlessness — July 30, 2009

@eyelidlessness:
You’ve apparently misunderstood the comment. I was primarily responding to this comment earlier by fzammetti:
“You’re right, “3? is pretty horrid API design”

I should have quoted. But anyway, to rephrase, the API itself is hardly horrid if it was used in a non-embedded context with enum support. ex:

enum Direction {
TOP:0,
RIGHT:1,
BOTTOM:2,
LEFT:3
}

It’s of course a simple academic observation.

Comment by TNO — July 30, 2009

The one downside of this in IE as mentioned in Jonathan’s post is that IE removes cleartype from the rendering. Meaning you get some horrible text/png rendering once rotated. This is fine if your are not using transparencies as a solid background color applied to the element seems to fix it. But for any opacity/rotation work using transparencies you have to be really careful with your font selection.

Comment by olliekav — July 31, 2009

Microsoft just won the game. Again.

Comment by Darkimmortal — July 31, 2009

So for that specific example, why not the writing mode that has been supported in IE since version 5.5? Sure, it won’t allow for arbitrary angles but 90 degree increments cover many scenarios. Also, I thought the direct-X transforms were dropped from recent IE versions?

Comment by BertrandLeRoy — August 1, 2009

Hi I have used writing-mode to vertically display text in jsp. When i export this jsp to excel, for some reason the same text does not get displayed vertically. I have included the css code in in the excel jsp. Any solution ? Tthanks in advance.

Comment by kadu — August 6, 2009

Leave a comment

You must be logged in to post a comment.