CSS is most well known as a means of creating nifty-looking graphical effects and enhancements in W3C-compliant webpages. Also, it has been demonstrated that CSS can be embedded into both HTML (a text-oriented markup language) and SVG (a vector graphics-oriented markup language).

But while CSS can wire together embedded content (images, video, etc.) and text into a variety of harmoniously-compartmented displays on xHTML, it remains to be seen what CSS can wire together in an SVG file, apart from doing the same job in SVG (wiring text and embedded images together into specific positions) that it does in xHTML.

Sure, SVG can be approached in the same way that non-image MLs like xHTML are approached: text can be embedded into SVG just like SVG can be embedded into text. However, SVG embedded into HTML would be treated like any other image format like JPEG, PNG and SWF, while text embedded into SVG wouldn’t have anything to do with xHTML (at the moment, I don’t think it’s possible to embed HTML syntax into SVG, as there are very few to no resources via Google on the subject); instead, it would be treated as text from within SVG’s own approach.

However, I’m certain that other images and image/video formats can be embedded in SVG, just as images can be embedded into HTML. So a CSS-based layout of the images and the text would work similarly to, albeit not the exact same as, CSS-based layout of images and text in HTML.

I think that now, from the recent addition of animations and transformations into CSS on WebKit, the main issue of discussion on CSS’s role in vector graphics markup centers around how CSS and SMIL can be appropriated within both HTML and SVG without getting in each other’s way.

Like CSS and unlike HTML, SVG and other markup languages, SMIL (a markup language, abbreviation for “Synchronized Multimedia integration Language”), ironically pronounced as “smile”, doesn’t have a “face”; in other words, an SMIL file doesn’t have a visible output except when it is used to determine the sequential display of elements in another markup language, like SVG (thus being akin to Flash Player’s ActionScript in terms of its “animation” capabilities). In fact, the main purpose of SMIL in a markup language is to determine how the elements in a markup page are supposed to “act” when the page is “played”.

Also, it is most used by multimedia players such as QuickTime and RealPlayer to determine (or, dare I say, “daisy-chain”) a pre-determined playback sequence of audio and video, hence known as “playlists”. Also, a subset of SMIL, known as the Multimedia Messaging Service, is used primarily in the mobile device media industry to provide a variety of multimedia (video, images, audio, rich text) for messages between device rather than just the infamous “text message” allowed by the Short Message Service (SMS) protocol.

But what can CSS, even animated CSS, do for SMIL? Or what is the best relationship between the two?

At the moment, I’ve found this W3C resource on the interaction between CSS2 and SMIL (possibly for embedding); however, it was published exactly 10 years ago, while CSS animations were introduced this year as part of the drive toward an eventual CSS3 recommendation.

CSS, like SMIL, doesn’t have a “face” unless it is embedded or “inlined” correctly in a markup language; and to an extent, it does determine an exact layout for the markup file’s inner contents and embedded material. However, unlike SMIL, previous standards of CSS didn’t include provisions for animation, although animation in CSS has been proven to work in previous years at a very rudimentary and manual, mouse-driven (:hover) level prior to the introduction of larger animation attributes to the CSS implementation in WebKit this year.

At the same time, even with this recent CSS animation implementation, it is still (albeit slightly less) driven by the mouse, as the :hover and :mouseover tags’ capabilities have simply been expanded into the area of transformations (in other words, the attributes that allow for translations and rotations of elements).

So I could see the CSS3 transformations being geared exclusively to single hover-driven elements (like mousing over a hyperlink to see it expand or rotate into a bigger form), while SMIL’s animations can be applied to elements in the page that aren’t hover-driven, but click-driven (like clicking “play” to play a video and “stop” to stop it).

But that’s the best that I can see as far as a relationship between a transforming CSS3 and animating SMIL is concerned. There’s still no word yet on what embedding CSS into an SMIL file can do for the latter (vice versa, I believe, is impossible).

Neither of them have “faces” with which they can smile or style.