[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK-APPS: Re: CSS for command tag
Norman Walsh wrote: > <snip/> > | Why wouldn't <span class="command">Tool0815<span/> be more flexible > | markup here? If we think it's absolutely necessary to create a visual > | indicator, place a ".command{ font-weight: bold;} in the head style? > > Yes, it's an excellent use case. It's a perfect example of what I > described in an earlier message: a case where it's desirable for > there to be some distinguishing presentation even when a non-CSS aware > browser is used. > > Given that a CSS user can override b.command, I actually think the b > is fine here. > > | Earlier you raise the issue of styles appearing in all files, even if > | not used. Is this a huge issue, presumably in terms of file size? How > | many of these imbedded styles are we talking about? > > Probably not too many, but there's no practical way for the > stylesheets to only selectors the fragments necessary. I guess it's one of those irreconcilable differences things. Under this scenario, the "CSS user" is required to become aware of all the imbedded styling items and then customize those of them deemed unacceptable to his application/situation. I suppose, in an ideal world, one would rather build from a clean visual slate than re-jigg and override; but then, CSS pretty much implies "override" in its basic design approach. This is not to say that I don't appreciate the value of cosmetics for non- or faulty-CSS browsers. I just wish they would go away. ...edN
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC