This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]