OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[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