[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [docbook-apps] DocBook XSL 1.67.0 released
||*()*|| [\..konnichi wa, ogenki desu ka, Elliotte../] >> The var element is not a monospaced style. It's typically >> rendered in italic (non-monospaced). Which makes it inappropriate >> for marking up programming variables or program arguments. EH> The var element is not a style element, period. The problem is that EH> you're using semantic elements (var, code, strong, em) as style EH> elements. That's just as wrong as using b and i. In fact, it's more EH> wrong because at least b and i aren't actively misleading. I think var looks pretty. =) At least I more like default DSSSL output than default XSL. But I'm disagree with your point of view - HTML doesn't have semantic elements. All so-called "semantic" in HTML is just a hint to tell what some element should differ from other <b><i> and such. Way to have some "layers" in document presentation and quickly pick them with a simple code {font-weight:bold} stylesheet. EH> If the goal is to avoid presentation based markup, then the HTML element EH> names should be picked based on the appropriate semantic match. When EH> there is no such match, use <span class="whatever"> and add styling via EH> CSS. The goal is to make styling intuitive and easy. <code class="whatever"> is more clear than generic <span class="whatever">. <span class="methodsynopsis"> can have some science thesis contained (suppose I don't know about DocBook since we speak about HTML), but if it is <code> tag when I will think about some program method and will not try to render it like a quote with my CSS. -- //Old Rusty Cans Killers [ORCK]: //technically yours, techtonik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]