Re: [widgets] Applying Stylesheets to Resources

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/

Received on Tuesday, 4 May 2010 13:14:56 UTC