Re: Text-Decoration

On Fri, 31 Mar 2000, Matthew Brealey wrote:

>>  + test 23 is incorrect, as according to CSS2, "conforming user
>>  agents" (i.e. those that recognise all of CSS2) "are not required
>>  to support this value".
> 
> It is true that they are not required to support it, but: 
>
>| If there hasn't been any blinking in the rest of the document, this
>| should be underlined. (text-decoration: underline; text-decoration:
>| blink).
> 
> is valid, since if they don't support it they should ignore it and
> revert to the previous value.

So you are saying that a fully compliant CSS2 browser could actually
render the following sample without _any_ text-decoration at all,
simply because one of them is the valid, recognised, but unsupported
keyword "blink"? Don't forget that "blink" might well be disabled due
to its potentially dangerous effects (or just because it is plain
irritating).

   span { text-decoration: underline overline blink; }

   <span> I should be underlined and overlined and MAY blink. </span>

 
>>  + test 28 is wrong, since the spec does not say "t-d only spans
>>  descendant inline elements", as quoted, it says "If the property
>>  is specified for a block-level element, it affects all
>>  inline-level descendants of the element", and the contents of line
>>  boxes are definitely inline-level.
>
> Your quote is true, but it says 'descendants' not 'descendant
> boxes'. If 'descendants' meant 'descendant boxes', it would say so.
> Since it does not, it would be wrong to treat it as anything other
> than 'descendant elements'.
> 
> [snip reference to previous (unresolved) discussion]

Do you mean that you believe that the text in the following paragraph
should _not_ be underlined at all???

   <p style="text-decoration: underline; display: block;">
      I am anonymous content of a block level element.
   </p>

I am very sure that the authors of the specification intended the text
above to be underlined. Certainly page authors would be *very*
surprised to find that text not underlined!


>>  + test 30 is unclear. It should point out that the baseline for
>>  the section with the large text is ABOVE the baseline of the large
>>  text itself (because of the "vertical-align:sub" declaration).
> 
> No it isn't:
> 
># sub 
>#   Lower the baseline of the box to the proper position for subscripts
>#   of the parent's box. 
>  -- http://www.w3.org/TR/REC-CSS2/visudet.html#line-height
> 
> It says that the baseline is lowered, so the underline is on the
> baseline; i.e., the underline is just below the text.

Only the baseline of the subscripted text is moved -- the subscript of
the parent element, along which the underline is drawn, is at the same
position throughout the inline box. [1]

 
>>  + test 32 is wrong, there should be two sets of underlines (for
>>  reasons which I feel have been discussed to death on this list.)
>>  + similarly for test 33.
> No I disagree. The underline of the descendant element is rendered
> on top of that of the ancestor element so although the underline is
> there, it is obscured.

But the parent's underline is not drawn at exactly the same place, so
both would be visible. The underline is unlikely to be drawn actually
_on_ the baseline, don't forget -- that would lead to the unfortunate
effect of the underline touching the glyphs. Since the font-size of
the child text is (IIRC) bigger, the underline of the child will be
offset further from the baseline than the underline of the parent.

 
>>  + tests 34, 35 and 36 are wrong for similar reasons; as far as I
>>  can tell the child elements are not given explicit
>>  text-decorations and so the decorations should be drawn by the
>>  parent inline element, thus they should not be broken as your
>>  tests suggest.
> I disagree. CSS states that text-decoration 'affects' inline
> descendant elements - it does not say that it spans them. To span
> them gives ugly results.

I disagree that it gives "ugly" results, but that is merely a
subjective point of view. Personally I find that underline breaking
each time there is a superscript (or whatever) is ugly. Certainly it
isn't how my textbooks are typeset.


>>  + test 40 is incorrect, because regardless of the position of the
>>  image, the underlining should span the entire inline element (in
>>  this case the line box or anonymous inline box depending on your
>>  interpretation of the spec).
> 
> I disagree. CSS says quite plainly that text-decoration does not
> affect images (for example, you wouldn't want your images
> lined-throughed).

Text-decoration is not in any way affected by the children elements of
the box on which it is set. The image is not being affected by the
underline, it merely happens to be at the same place.

If the author doesn't want his image "line-throughed", then one can
well wonder why he put it in a block of text that _is_.

This can become more obvious when you think of inline vector graphics
used to extend the glyph set -- for example:

   del { text-decoration: line-through; }
   img { height: 1em; }

   <del>
      The singer changed his name to 
      <img src="symbol.svg" alt="a funny symbol">. 
   </del>

To the reader, the image is just part of the flow of text -- it would
look incredibly odd if it was not struck out. I respectively suggest
that a case where an image should not be affected by its parent text
decoration is probably one where the markup was not semantic enough.

Another good way of seeing this is: if the image was not displayed,
then its alternative text would be inserted instead. That _would_ be
struck out. So if it is semantically correct to strike out the textual
representation of a concept, why is it not correct to strike out the
graphical representation of that same concept???

 
>>  + test 42 is invalid since it is missing an 'src' attribute
>>  (mandatory in HTML -- do you not validate your pages?).
> 
> The src attribute is missing, you are quite correct. But the reason
> that it is missing is that there isn't an image there!

Irrelevant. "src" is a mandatory attribute. The solution is to add a
bogus filename (as you have done).


> That there was no 'src' should not affect the result, however.

It might well, since HTML explicitly does not define how an invalid
page should be handled. If the test page is invalid, then a browser
which, upon reading it, connects to your oven and bakes some cakes is
operating perfectly within the specification. ;-)

---
[1] modulo potential problems with multiple font boxes within the
single inline box, of course.

-- 
Ian Hickson                            ("`-''-/").___..--''"`-._   
http://www.bath.ac.uk/%7Epy8ieh/        `6_ 6  )   `-.  (     ).`-.__.`)
                                        (_Y_.)'  ._   )  `._ `. ``-..-' fL
Member, Mozilla Quality Assurance     _..`--'_..-_/  /--'_.' ,'
Browser Standards Compliance Team    (il).-''  (li).'  ((!.-'

Received on Friday, 31 March 2000 08:27:50 UTC