Is this thing on?

Subscribe to RSS feed

Posts tagged with "css"

Web Animations, towards a Web 2.1

, , ,

SVG Animation (based on SMIL) and CSS Animation offer some similar features for animating Web content. Harmonising these two technologies has been considered on a number of occasions but a path forward has yet to be established. In response to a feature-by-feature comparison of the two technologies the question was raised, “What are the animation features required, prioritised by use case?” (Meeting minutes which lead to Action-48) although a closely related question was, “What would it take to make CSS Animations achieve feature parity with SVG Animations?”

From face-to-face meeting on Web Animations, as discussed here. There is now a CSS-SVG Effects Task Force activity on this.

It has taken time, but by now CSS and SVG are on the same team, which is kind of a precursor to make the specifications well-integrated as well.

CSS 2.1 Solid Soon?

, ,

XKCD recently published the future and found through a good number of Google searches that finishing up HTML5 would herald the demise of newspapers and the Third Coming of Christ.

Coincidentally the W3C declared that finally CSS 2.1 had reached Proposed Recommendation status, and surely, surely!, the end, in the form of CSS 2.1 as Recommendation, should be nigh. I recapped the story in an almost four year earlier entry, Cruelly Slow Slog, a slog that cruelly continued for four more years. 11 years of labour is not bad for what was intended as a quick fix.

Heaping on the irony, a new working draft of CSS3 Speech Module was published. While CSS 2.1 was bound to reach PR some day, the CSS3 Speech Module had been missing in action for seven years, if this module had been a person he would have been recorded as dead long time ago and his belongings spread among his inheritors.

Maybe it is time for me to revive the Audio module? While the Speech module is an aural equivalent to the Text module, how to style spoken text (generated by text to speech), there would be a use, arguably a greater one, for handling audio files. Audio is to speech as image is to rendered text. Properties of an audio module would be the likes of volume, balance, delay, speed, how to present the media in a given context.

In the intervening years HTML5 has happened, with dedicated audio and video elements. As is otherwise the case having more well-defined markup makes the case for styles easier, with the ability of everyone involved to adapt content to user circumstances, for audio as well as images.

Of course, given present form, Jesus Christ would have become a frequent flyer by the time such a module would reach Proposed Recommendation.

Map to the future

, , , ...

Wikipedia has a nice and extremely useful map of the Beijing metro system with upcoming extensions. As the Beijing metro system is expanding extremely rapidly the future is almost now.

Like most Wikipedia maps of this type it is made in SVG (using Adobe Illustrator). The code it generates it fairly decent, better than some code I have seen earlier, but still hard to read and use for my purpose, so I cleaned it up with Kommodo Edit. The regular expressions work well in that editor, which makes clean-up much quicker and easier.

Maps are, or at least should be, ideal for SVG and SVG animations. Famously they are not the territory, but they are a layer of information that can be used instead of or as an overlay to other maps of the territory, highlighting the information you are looking for and hiding the information that distracts.

Read more...

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