W3C home > Mailing lists > Public > www-style@w3.org > August 2010

Re: [CSS 2.1] cases that do not pass in any browser

From: Peter Moulder <peter.moulder@monash.edu>
Date: Sun, 22 Aug 2010 19:47:45 +1000
To: www-style list <www-style@w3.org>
Message-id: <20100822094745.GC6534@bowman.infotech.monash.edu.au>
On Sat, Aug 21, 2010 at 09:27:51PM -0400, Boris Zbarsky wrote:
> On 8/13/10 10:45 PM, Peter Moulder wrote:
> >I believe that implementations are simpler if we can assign properties to the
> >float before line-breaking time.
> For what it's worth, Gecko's isn't.  ;) 

One might guess that Gecko is easier with green while Opera and WebKit are
easier with red, at least in the sense that that's their existing behaviour,
and their architecture (how/where inheritance gets applied) is based on one or
other of the two interpretations of the spec.

> At the very least some sort
> of special-casing would have to be performed where some things
> inherit from the :first-line and some other things that clearly
> should don't.

That sounds like a single "if (in-flow)" test.

(Though of course changing an existing implementation has more costs in testing
and actually finding out whether it's just a single extra test after all.)

FWIW, the cost of "green" would be more for the user agent I'm working on,
because part of the idea of the user agent is to react better to the problem
that in multicolumn or paged layouts, you want to avoid having floats hanging
below the bottom of the page, but you also want floats to be near the reference
point (the placeholder, in Gecko language).  So you want to look ahead, and
make decisions such as "how loosely or tightly should I set text here" or
"should I push this float to the next column/page" based on what problems
you're likely to encounter with upcoming content.  Part of that guess as to
what problems will arise in future is based on how much space nearby future
floats take up, because that tells us what text and hence what floats are
likely to be near the bottom of the page.  And of course it's easier to know
how much space these future floats are likely to take up if their styling can
be known without doing extra line breaking ("extra" because we don't yet know
what floats will be shortening the line boxes around then anyway, it'll just be
a guess, a guess that would involve some initial calculations as to what floats
are likely to be shortening the line boxes).

Of course in any case, implementation cost isn't the only criterion for the
decision.  Authoring/viewing issues are also relevant.

> >I'm also concerned about whether the properties assigned to that float might
> >affect whether or not it (i.e. the<float>  element) is on the first line in the
> >first place
> Since first-line can be styled with a different font, this problem
> is already inherent to any implementation of first-line and doesn't
> need floats to encounter it.

Yeah, I too had come to, what's the word, disregard/drop / cease to find
convincing, the circularity argument, given that both first-line and float
placement are already circular and code already has to deal with it.

However, I'm still moved by the argument that a float shouldn't change its
colour when the window is resized, that a float's styling shouldn't depend on
whether its invisible reference happens to fall on the first line, that authors
don't actually intend for :first-line styling to affect floats.  (Note though
that I don't write web pages for a living.)

Received on Sunday, 22 August 2010 09:48:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:40 UTC