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

Re: [css2.1] Issue 199 proposal

From: L. David Baron <dbaron@dbaron.org>
Date: Mon, 25 Oct 2010 16:20:55 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
Message-ID: <20101025232055.GA4325@pickering.dbaron.org>
On Wednesday 2010-10-20 09:25 -0700, Tab Atkins Jr. wrote:
> On Tue, Sep 14, 2010 at 1:46 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> > On Tue, Sep 7, 2010 at 5:06 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> >> This email is meant to address issue 199 on CSS2.1, which I
> >> volunteered to propose text for.
> >> http://wiki.csswg.org/spec/css2.1#issue-199
> >
> >
> > Urgh, I meant to do this last week.  New proposal, based on discussion
> > in the telcon:
> >
> > | Line boxes that contain no text, no preserved white space, no
> > | inline elements with non-zero margins, padding, or borders, and
> > | no other in-flow content (such as images, inline blocks or
> > | inline tables), and do not end with a line feed must be treated
> > | as zero-height line boxes for the purpose of positioning the
> > | elements inside of them, and must be treated as not existing
> > | for any other purpose.
[...]
> > Am I right in thinking that these lineboxes can only be created as the
> > sole linebox of an element?  It seems that if there's another linebox
> > with actual content in it, then the type of contents that would appear
> > in this "phantom linebox" would instead just be collapsed together at
> > the end of the real linebox, right?
> 
> Assuming that I was correct in my assumption immediately above, then I
> propose the following edit instead:

I think the assumption is correct.

> | If an element contains no text, no preserved white space, no
> | inline elements with non-zero margins, padding, or borders, and
> | no other in-flow content (such as images, inline block, or
> | inline tables), then no line boxes are generated inside the
> | element.  Any child elements that rely on the element for
> | positioning are treated as being in the "before start" corner
> | of the element.

However, I don't like the new proposal.  It introduces unpleasant
discontinuities that weren't there before, e.g., when 'text-align'
is 'right'.  See, for example, this testcase:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%20%3E%20div%20%7B%20border%3A%20solid%20blue%3B%20text-align%3A%20right%3B%20width%3A%20500px%20%7D%0Abody%20%3E%20div%20%3E%20div%20%7B%20display%3A%20inline%3B%20position%3A%20relative%20%7D%0Abody%20%3E%20div%20%3E%20div%20%3E%20div%20%7B%20position%3A%20absolute%3B%20height%3A%20100px%3B%20width%3A%2050px%3B%20background%3A%20orange%3B%20top%3A%200%3B%20right%3A%200%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%3E%3Cdiv%3E%3Cdiv%3E%3C%2Fdiv%3E%3C%2Fdiv%3E%3C%2Fdiv%3E

It turns out that Chromium already seems to implement these
discontinuities (try adding a single letter that's inside the second
div but not the third), but Gecko doesn't.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Monday, 25 October 2010 23:21:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:33 GMT