Skip navigation.

Posts tagged with "css"

Conditional Comments in HTML5?

, ,

Where we are

Four years ago I wrote a small piece on conditional comments in IE7, and whether there should be an institutionalised Opera CSS hack, in the style of @opera or @browser opera. While IE's standards support isn't stellar, it is still better than it was four years ago, and the desire to make specific hacks for the shortcomings of IE, Opera, or any other browser hasn't gone away and is unlikely to go away in the next decade either. This entry is triggered by a comment this Friday asking for Opera conditional comments. For all the talk about the ills of browser sniffing, and using capability detection instead, it is not going to go away. In that case wouldn't it be better to make browser sniffing less bad?

Read more...

The Missing Link: Connecting Boxes

, , , ...

There is one basic document functionality that none of HTML, CSS, nor SVG can do. None can represent one box, another box, and a link between the two.

Graph where box One has arrow to box Two

Read more...

CSS today, yesterday, and tomorrow

, , , ...

I held a CSS talk at CVUT a week or so ago.

Cruelly Slow Slog

,

The CSS 2.1 specification was recently refused entry into the (almost) safe harbour of Candidate Recommendation (CR) status again (for what is it? the fourth time?). This means that the spec is still in a you-can't-believe-a-word-of-this Working Draft state, just like it was seven years ago. This can be summed up in the word frustrating.

To be fair the goalposts have not only been shifted from when Tantek Çelik originally suggested CSS 2.1 one Sunday afternoon, but completely replaced. Originally the idea was just to remove the parts of CSS 2 that nobody wanted to implement. This could have been done in months. It would essentially be a profile of CSS 2, "CSS 2—The useful bits".

Instead CSS 2 was fully rewritten in tedious detail, the goal was now the interoperable CSS 2. This in itself was a good thing. It is much better that the spec is unambiguous than having incompatible implementations of the same, vague, spec. The ones having already implemented CSS 2 would need to adjust their products, but for new CSS 2.1 user agents getting it right the first time is much cheaper, not to speak of the millions of web designers that don't have to make specific hacks for every browser in existence.

But there is a diminishing return. The optimal time/clarity moment was probably when it was first submitted for CR, three years or so ago. This is not to say that what was done after that was unnecessary, but the extra clarity we have gotten for increasingly obscure issues have simply not been worth the additional years. They would have to be resolved at one point or another, but are errata or CSS3 material. The fatigue in the working group and impatience in the designer community is also starting to show, those that haven't given up on it years ago.

It is also slightly unfair. SMIL 2.1 had its first (and last!) working draft in February 2005, and a finished recommendation in December 2005. Were they that more efficient? No, but evidently their goal was to push out a spec as soon as possible rather than solving underlying problems, and crucially nobody outside the working group cared.


With this as a background it is none too surprising that a discussion on wither working group, even in some cases whether working group, has started. One solution I find particularly unconvincing is the argument that the CSS working group should follow the lead of the new HTML working group which currently has 405 self-invited experts, and the number is growing. That is the classic "the project is late, let's throw in many more people" approach. This behind the scenes report may be the best summing up of the situation.

The other symptom is an earlier call for CSS 2.2, reminiscent of my suggestion in 2002 or thereabout of a CSS 3.1. The big problem was as evident then as now. CSS 2.1 may have taken way more time and effort than was originally intended, and now we suffer from it. But sooner or more likely later it will be done. CSS3 on the other hand is a monster many times bigger than CSS 2(.1), the chances of it being fully done, let alone implemented, any time soon is nil. So what about the designers that have waited patiently on rounded corners for a decade and now have the outlook of having to wait another decade so that at least their children will be able to specify it in their style sheet?

Media, style, and access

, ,

The css Zen Garden has done more than any other site to evangelize that having a simple, expressive markup will allow you to create a great variety of displays. Even so I am struck with how similar most of the designs are, just throwing in different pictures. It is the same with Opera skins. Many are pretty, more are ugly, some are plain weird. But only a few are original. Neither are conformity breaking or pragmatic.

Simple markup and baroque styles is also more mallable, something that matters most in the field where I spend most of my time, between device independence (device is most of the time Opera-speak for phone), accessibility, and multimodality (which in Opera most of the time means Voice). They all have similar, but not identical, requirements, there are even a few features that would be a boon for one group of users but detrimental for others.

Any web designer that cares enough to test for every possible user group in every possible situation would probably not have time to do any web design, and neither should he have to. The good news is that most of the good habits are easier than than the bad ones. It is easier to mark up a headline than to specify that this paragraph has a 'b' element and a 'font' element. But before general CSS support the headlines were unpredictable, and tools still reflect that. CNN for instance has specified one headline on each page, which is patently not true.

Joe Clark has in A List Apart written an article on zoom users and Small-screen rendering. Opera has both, but with a separate origin and use case. Accessibility as defined by WAI doesn't include the access problems a phone user might have with a web site and that is reasonable. It isn't their problem, most in the community have a hard time using a phone at all except for phone calls, so they see phone browsing as a voluntary foray into their world. This is reflected in the table near the bottom of the article with the "PDA owner (personal choice)" entry (with Opera glasses on: "PDA? Are anyone still using that?"). The screen reader article is another should-read article, but the link here to the author's web site is more, ahem, accessible for us phone users than the PDF version or the Google de-pdf version.

Printing with CSS

I've spent more time with other media than print lately, but this article on XML.com, Printing XML: Why CSS Is Better than XSL, is well worth the read.

I have no opinion of XSL-FO as a print formatter, relative to for instance Postscript. What I have noted is that the printer vendors have been working hard on using XHTML and CSS as printer drivers.

Now, if we were to get over the "printer-friendly version" habit...