Various Niggling CSS1 Questions

Eric A. Meyer writes:

 > 1. Should CSS1 implementations take the FONT tag into account?  For
 > example, if I set the rule "BODY {font: 12pt serif;}", then tags like <FONT
 > size="+2"> will have no visual effect-- everything will be 12pt serif.

The CSS1 spec leaves the question unanswered -- UAs may or may not
take it into account. If they do take FONT into account, CSS1
specifies where in the cascade the rules should be put.

 > 2. On a related note, given the above CSS1 rule, all the browsers I've
 > tested will render every single heading level as 12pt serif text. 

Neither NN4 nor MSIE4 render H1 elements in 12pt serif on my screen.

 > Is this
 > because that's what the specification calls for, or because the browsers
 > are inheriting things incorrectly, or is it a failing on the part of
 > browser authors to provide good internal style sheets with font-size values
 > like 'x-large'?

The latter. But, it's perfectly legal to do so -- the CSS1
specification lists a sample style sheet for HTML2, but UAs are not
required to use this a the default style sheet.

 > 3. The specification says that vertical-align may get into "unsolvable
 > situations... where element dependencies form a loop."  I don't get it.
 > What does this mean, and can we have some examples?

Take a deep breath. Say you have two inline images on the same line.
The first one has "vertical-align: top", the second has
"vertical-align: bottom". When the first image is laid out, it will be
aligned with the top of the text. Assuming the first image is higher
that the font size, it will extend below the text. Now, the second
image should be aligned with the bottom of the first image (since that
is the bottom point on the line). Assuming the second image is higher
than the first image, it will extend above the text and form the top
point on the line -- a point which the first image should be alinged
with. To satisfy this constraint, the first image should be raised,
which again will move the bottom point on the line. Etc. etc.

 > 1. Why are the anchor pseudo-classes limited only to HREF anchors?  I'd
 > kind of like to be able to apply styles to NAME anchors without having to
 > create a class selector for them.  Something like "A:name {color: gray;}"
 > would work fine, it seems to me.

Right, it would be convenient in a few cases but it would complicate
the specification without adding a critical feature. AFAIK, You're the
first person who's asked for this.

 > 2. Let's say I set "BODY {color: blue;}".  In this case, obviously, all
 > foreground will be blue.  Including HRs, which will become unshaded blue
 > lines.  If I don't want this, I have to identify every block-level element
 > (at a minimum) in the document and group them into a rule which sets them
 > to blue, and eliminate the rule for BODY.  It would be much nicer to be
 > able to do something like this:
 > 
 >    BODY {color: blue;}
 >    HR {color: none;}
 > 
 > ...or whatever-- substitute a more appropriate value keyword if you like.
 > Is this a reasonable idea?

Are you trying to hide HRs? If so, this rule should do the job:

  HR { display: none }

Regards,

-h&kon

H   å   k   o   n      W   i   u   m       L   i   e
howcome@w3.org      http://www.w3.org/people/howcome
World     W      i     d     e       Web  Consortium

Received on Wednesday, 24 September 1997 15:08:01 UTC