On May 4, 2010, at 14:42 , Marcos Caceres wrote:
> Having a <style>, or styles, for a might be interesting:
>
> <widget ...>
> <style src="global.css"/>
> <style media="conditionA" src="x.css"/>
> <style media="conditionB" src="y.css"/>
> <content src="someFile.html"/>
> </widget>
>
> Or
>
> <widget ...>
> <content src="someFile.html"/>
> <style src="global.css"/>
> <style media="conditionA" src="x.css"/>
> <style media="conditionB" src="y.css"/>
> </content>
> </widget>
I'd really rather not. I'm not convinced that we need this degree of
orthogonality between content and styling on the web in general, and I'm even
less convinced that a widget-specific implementation of it has any value at all.
Contrary to what is often said separation of style and content isn't a big
foundational architectural principle up there with "Anything can be improved by
the addition of bacon, even bacon" and "Comic Sans users deserve to die". The
architectural principle is that content is more useful when it can be
repurposed easily. That's why making the content itself be stylistic is an
issue (because when all you have is style information, you can't repurpose it
much) whereas having the content link to style is not a problem. UAs can easily
chose not to use the style, or to use another one, and someone slurping up the
content can trivially do $("link[rel=stylesheet], style").remove() and
$("[style]").removeAttr("style")*.
Trying to orthogonalise the link to style further by externalising it doesn't
bring much other than a false sense of architectural purity, and it does create
a headache when you then want to save such documents to disk — where do you put
the out of band metadata?
* Yeah I know, it doesn't remove xml-stylesheet. Blame Selectors.
--
Robin Berjon - http://berjon.com/
