The dangers of inherit; the dangers of first-letter; errors in spec on float; new float rules; mistake in clear example; background-sound; @viewport

The dangers of :first-letter:

Consider
P {
line-height: 1.5em;
font-size: 12pt;
}
H1 + P:first-letter {
/* Inherits 18pt for l-h */
font-size: 72pt;
float: left;
width: 1em
}
This is perhaps worth emphasising in the spec


--------------------------------

Viewport dependencies:

I would like to see an @viewport rule. This would work
thus:
@viewport [WminwidthinpixelsTOmaxwidthinpixels]?
[HminheightinpixelsTOmaxheightinpixels]?
[mincolourdepthinbitsTOmaxcolourdepthinbits]?.

E.g.:
@viewport W700TO1100 {
DIV.columns {columns: 5}
}

@viewport H0TO600 {  
DIV.columns {columns: 3}
}

@viewport W1000TO { /* Omitted so no upper limit */}

@viewport 16TO {
BODY {background: url(colourful.gif)}
}

@viewport 0TO8 {
BODY {background: black}
}
Better still would be an optional B or C on the colour
depth to specify black and white or colour.

E.g.,:

@viewport 8TOC{
/*
Matches only colour screens 
*/

The reason I do not call this @videodriver is because
the widths and heights refer to the actual widths that
we are working with - it is not much use to know that
the user has 800*600, if they have their browser in a
window only 200*100.

------------------------------------------------

The mess that float is:


<blockquote>
[1] ... The line boxes to the right of the float are
shortened due to the float's presence, but resume ...
[the] width ... of the containing block.

... 

[2] A float can overlap other boxes in the normal flow
(e.g., when a normal flow box next to a float has
negative margins). When an inline box overlaps with a
float, the content, background, and borders of the
inline box are rendered in front of the float. [3]
When a block box overlaps, the background and borders
of the block box are rendered behind the float ...
[and] the content ... in front.

</blockquote>

2. would be fine if it was headed thus: 'What happens
with float and negative margins', but it is not.

Having already said that line boxes are not considered
to overlap (1) but are instead shortened (i.e. the
float takes a bite out of the line box), the very next
paragraph states:

<blockquote>
[4] Here is another illustration, showing what happens
when a float overlaps borders of elements in the
normal flow.


Here is some sample text. Here is some sample text.
Here is some sample text. Here is some sample         
       text. Here is some sample text. Here is some
sample text. Here is some sample 
                text. Here is some sample text. Here
is some sample text. Here is some sample 
                text. Here is some sample text. Here
is some sample text. Here is some sample 
image           text. Here is some sample text. Here
is some sample text. Here is some sample 
                text. Here is some sample text. Here
is some sample text. Here is some sample 
here

                Here is some sample text. Here is some
sample text. Here is some sample text. 	         	Here
is some sample text. Here is some sample text. Here is
some sample 



</blockquote>

4 states that this an example of floating overlapping
borders, but according to 3, the content is rendered
in front, i.e. on top of the float. 

This is clearly wrong, since it should not be in front
of the float, but next to it, as stated in 1.

So what should be stated is:

HEADING: Negative borders:
A float can overlap other boxes in the normal flow
(i.e. [NB not e.g.] where a normal flow box is next to
a float, and either have negative margins). 

When an inline box overlaps with a float, the content,
background, and borders of the inline box are rendered
in front of the float. When a block box overlaps, the
background and borders of the block box are rendered
behind the float ... [and] the content ... in front.

HEADING: Elements overlapping preceding float elements

Normally blocks are laid out one after another, and
block's heights are such that is sufficient to hold
their content. However, when a block element includes
a floating element, the block's height is that which
is sufficient to hold all of its content disregarding
the floating element.

Since there is no reason why the height of an element
containing a floating box will be sufficient to
contain the floating element, it is likely that
subsequent block elements will be caused to overlap.
Should this occur, the background and borders of the
block box are rendered behind the float, and the
content is displaced to the side of the floating box.

------------------
Float rules:
Rule 4: A floating box's outer top may not be higher
than the top of its containg block.
Rule 5: A floating box's outer top may not be higher
than than the outer top of any block generated by an
earlier element.
Rule 6: A floating box's outer top may not be higher
than the top of a line box that includes an earlier
element. (NB. rule 6 is badly phrased)
Rule 7: A left floating box to the right of another
left floating box must not have its right outer edge
to the right of the content edge of the block.

These three rules seem to state that floating elements
can't have negative top, left or right margins. If
this is the case, it should be stated in so many
words. 

If not, these rules are wrong. 

The options are:
1. Allow negative margins, and resolve overlaps
according to the HEADING: Negative borders.
2. Forbid negative margin-top, rendering it as
margin-top: 0.
3. Forbid negative margins.

I would opt for 1.

In addition, I think the float rules are
unsatisfactory. I would change them to:

All elements:

Rule 1: Floated boxes are moved to the left (right if
float: right) until they meet the edge of their
containg block or the right (left) outer edge of
another floating element.
Rule 2: If there is insufficient width for the
floating box in its current vertical position in the
containing block, it is moved down until there is.

Floated inline elements only:
Rule 3: The line box from which the element was
displaced flows is reflowed as if the floated element
was never there.
Rule 4: The top (i.e. the border-top ) of the floated
box is aligned with the top of the current line box
(i.e. the current line box disregarding the floated
box)
Rule 5: Subsequent line boxes flow round the float.
Rule 6: The float will overlap the background, border
and padding of subsequent block boxes if necessary.
Rule 7: Line boxes in these subsequent elements flow
round the float.

Floated block elements only:
Rule 3: Subsequent block elements flow round the float
as if it was part of the left (right) margin (although
for the purposes of calculating width: auto they do
not).

The bracketed text in rule 3 could be omitted.

Note that this would be an important change, because
it means that this will work:

DIV.left {
float: left;
width: 50%}

DIV.anyclass {
/* Width: auto is implied */
}
<div class="left">
</div>
<div class="anyclass"> 
</div>

At present, width: auto becomes the width of the
containing block (minus margins, borders, paddings,
etc. (which these DIVs do not have)), and so the
DIV.anyclass goes after the float. [Note that both
Opera and Netscape 4 (incorrectly, I think) follow the
alternate method already [IE probably does as well,
but I haven't checked]]

With the alternative, DIV.anyclass's width is
considered to be the space remaining, so it will go to
the right of the float. However, the difficulty is
that it might look stupid if you had 

division 1 Division 2
division 1 Division 2
division 1 Division 2
division 1 Division 2
division 1 Division 2
division 1 Division 2
Last line  Division 2
of div1    Division 2
           Division 2
           Division 2

Or would it be:

division 1 Division 2
division 1 Division 2
division 1 Division 2
division 1 Division 2
division 1 Division 2
division 1 Division 2
Last line  Division 2
of div1    Division 2
Division 2
Division 2

Finally on float, what of
<div style="float: left; width: 50%">
</div>
<div style="width: 50%">
</div>
where the second DIV takes up more space than the
first. 

It seems that the existing spec is not explicit on its
behaviour. I am inclined to think that it continues as
in the second of my text art examples above, since the
first is more properly the correct behaviour for where
the second of the two DIVs has float: right,
<strong>but the spec is silent on this
matter</strong>. In addition, if the second example is
correct, what about margins and padding - presumably
it should be stated that the second DIV has two
margin-tops, border-tops, and padding-tops, one where
it starts and one where it returns to the left margin
following the end of division 1.

Alternatively, if it is the case that the left floated
box is considered to be overlapping the one next to
it, then width: 50% will mean that none of the content
will be seen, because it will all be overlapped.

Clear:     

For rule 6 on floated inline elements, and rule 3 on
floated block elements substitute:
Rule 6: If a block element has clear set to left, and
an earlier (i.e. one that precedes it in the HTML
source) floating element would ordinarily be to its
left, it treats the floating element as a normal block
box (and hence is moved below it (although it may
overlap with it if the resultant margin is negative)).


If a block element has clear set to right, and an
earlier floating element would ordinarily be to its
right, it treats the floating element as a normal
block box. 

If a block element has clear set to both, and an
earlier floating element would ordinarily be to its
left or right, it treats the floating element as a
normal block box. 

And omit rule 7 under floated elements.

---------------------------

The mistake in the clear example:

At the example at 9.8.3, clear is assigned to SPAN, an
inline element.

-----------------------
The dangers of inherit:
Consider:
* {property: inherit}

where the user has BODY {property: value !important}.

The result might be somewhat unexpected to say the
least, and could result in unreadable pages unless you
are careful. (E.g., BODY {background-color: black;
color: white} * {background-color: inherit} with user
stylesheet BODY {background-color: white !important}
[perhaps because said user dislikes all those pages
with fancy backgrounds]

-----------------------

Background-sound:

I would propose this property.

It is very similar to play-during, except it does not
apply to speech synthesisers (equally vice versa). The
distinction is important because a different sound
will be appropriate in text-based environments than in
ones where the sound has to compete with speech.

Thus
BODY {background-sound-uri: url(sound.format) || none}
BODY {background-sound-repeat: once || }
BODY {background-sound-volume: 0-100}
BODY {background-sound: shortcut}

=====
----------------------------------------------------------
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!?
Bid and sell for free at http://auctions.yahoo.com

Received on Wednesday, 10 November 1999 06:11:25 UTC