Re: Inline h*ll

--- Ian Hickson <py8ieh@bath.ac.uk> wrote:
> On Thu, 20 Jan 2000, Matthew Brealey wrote:
> 
> >>> Another reason that this approach is better is that it associates
> >>> backgrounds with the line box rather than the text.
> >> This of course means that text can _easily_ flow outside the
> >> background, which is bad.
> > Not at all. Give me an example of how this could happen.
> 
> Give your line boxes a short line-height (however you do that in your
> proposal) 
Like this P {line-height: 10px; font-size: 16px}
> and your inlines a larger font.
This would occur under the existing specification - 
P {line-height: .8} would result in at least the top of the text, and
probably the bottom (depending on your 'interpretation' (for which read
'change') of the spec. There is no difference whatsoever, except that it
my suggestion, 10px would be backgrounded, whereas if you try and imply
some anonymous spanning concept into the spec it would be 13 - Bp +
Banonymous. In neither case would it fully cover the text (unless the text
was greatly smaller than its nominal font-size) value; and neither should
it - if line-height<font-size, this surely can only be right.
> 
> However, I've just realised an even worse problem with putting the
> background on the line box rather than the inline boxes. It makes it
> impossible to have a transparent part if the lines are far apart:
And how would that occur - line boxes are stacked without separation?
> >>> In fact, the implementation
> >> What implementation? Do you mean your suggestion?
> > Implementation is not synonymous with suggestion - implementation =
> > the CSS 2 implementation.
> 
> CSS2 implementation? Do you perchance mean the CSS2 specification?
> 
> An implementation is an actual program which has been designed to work
> according to the specification. So IE3 and Netscape4 would be very
> poor implementations of CSS1, for example, while Opera would be a
> reasonable implementation of the same specification. And so on.
I really don't need a lecture on the use of the English language. I
apologise for my lack of specificty (<g>).
> 
>  
> >>> means that one cannot follow the advice in the spec that states
> >>> that one should always set background colours when one sets
> >>> foreground colours dangerous on inline elements.
> >> Why? If one does not do as the spec suggests, then one is asking
> >> for conflicts, meaning that text will be unreadable (e.g., black on
> >> black).
> > This is highly unlikely. You could probably search night and day for
> > a thousand years and not find someone who sets backgrounds on
> > inline elements.
I missed the word 'user' out there. They must not do so, since it would
clash with old HTML documents where alink, vlink and link can be
speccified but not alinkbgcolor, etc.
> > The reason that it is dangerous is that (particularly on A, which is
> > very commonly set to a different colour) if you set a background on
> > an inline element within a line box of different colour, the things
> > don't get lined up and the result looks stupid.
> 
> Please explain why it would look stupid.
Because it isn't aesthetically pleasing.
> 
> Don't forget that "transparent" and "inherit" are perfectly valid
> backgrounds to specify (in authors stylesheets). 
Oh indeed - the problems only occur when authors set the backgrounds to a
different colour (which doesn't seem an unreasonable thing to do).
> 

=====
----------------------------------------------------------
From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS))
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Received on Friday, 21 January 2000 05:38:03 UTC