Re: Text-Decoration

Ian Hickson wrote:
> 
> 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>

I think so, given that the also unsupported text-decoration: underline
emboss (WebTV) should be ignored). But I could be wrong.

> >>  + 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>

No. It affects that element because you have applied it to that element.
In addition to affecting that element it affects all inline-level
descendants (rather than affecting all descendants).

> Only the baseline of the subscripted text is moved -- the subscript of
> the parent element, along which the underline is drawn, 

I disagree. The spec says that text-decoration 'affects' descendant
elements; it does not say that it 'spans' them or that it is drawn at
the same place throughout. My position, and the one that I believe gives
the best results is summarized at the top of the page:

Text-decoration is 'inherited' (not spanned): 

   1.but only to inline descendants; 
   2.with the color of the ancestor; 
   3.and at the level appropriate for the descendant. 


> >>  + 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, 

Again this is a matter of differing interpretations. 

> 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.

That's all very well but using graphics, even if they are svg, as text
is not really terribly semantic (it's not really much better than spacer
gifs and text buttons made from images). In any case CSS doesn't say
that images should; if you think that they should then propose a change
to the specification so that it conforms to what you think is
attractive.

> 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. 

You make my point very well. The text is struck through because it is
text. The image is not struck through because it is an image.

> >>  + 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. ;-)

Fair enough (but I don't think any browser actually bothers to use the
DTD and throw out any elements that don't include the mandatory
attributes).