W3C home > Mailing lists > Public > www-style@w3.org > January 2009

RE: [css3-linebox] aligning lines

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Sat, 3 Jan 2009 01:57:33 -0800
To: Håkon Wium Lie <howcome@opera.com>
CC: Tab Atkins Jr. <jackalmage@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <7C2F64B551D8664AAD94A28DAC37D0206B533346D9@NA-EXMSG-C103.redmond.corp.microsoft.com>

That's an awesome idea. Looking at how containing block is defined it seems to make sense that it is a good place to look for line grid.

Something needs to be said about regular nested blocks and inheritance though. In non-positioned case, containing block is the nearest ancestor block, which may not be the one that we want to define the grid.

In fact the most typical case is a P inside BODY, where P has a margin of 1em and BODY has line grid of 1.2em, so if P simply resets the grid for its children it is not working. Is there a way to make that most common case work without adding a line to containing block definition?

Actually... the whole deal with line grids transcending blocks clearly asks for a special case wrt containing blocks. The more I think about it, the more it seems to make sense to define line grid together with a block which owns it, which may not be any of currently defined containing blocks...

-----Original Message-----
From: Håkon Wium Lie [mailto:howcome@opera.com]
Sent: Saturday, January 03, 2009 12:24 AM
To: Alex Mogilevsky
Cc: Håkon Wium Lie; Tab Atkins Jr.; L. David Baron; www-style@w3.org
Subject: RE: [css3-linebox] aligning lines

I don't want to change the definition of containing block. Can't we
just say that if the containing block has

 line-stacking-strategy: grid

set, then the grid -- as defined by the line-height of the containing
block -- will be honored?

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Saturday, 3 January 2009 09:58:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:23 UTC