- From: Asmus Freytag <asmusf@ix.netcom.com>
- Date: Wed, 10 Oct 2012 14:29:16 -0700
- To: fantasai <fantasai.lists@inkedblade.net>
- CC: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, liam@w3.org, "Tab Atkins Jr." <jackalmage@gmail.com>, koba <koba@antenna.co.jp>, Koji Ishii <kojiishi@gluesoft.co.jp>, www-style@w3.org, Glenn Adams <glenn@skynav.com>, MURAKAMI Shinyu <murakami@antenna.co.jp>, "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>
On 10/10/2012 9:52 AM, fantasai wrote: > On 10/04/2012 01:22 AM, "Martin J. Dürst" wrote: >> Just an additional datapoint in this discussion: >> >> I just noticed that CSS already has properties page-break-before and >> page-break-after (see >> http://www.w3.org/TR/CSS2/page.html#page-break-props). Rather >> obviously, these indicate the same directions as the -before and >> -after relative direction properties already in XSL-FO, but are >> orthogonal to the :before and :after pseudo-elements. >> >> These seem not to have caused any significant confusion up to now. > > Because there is only one axis involved. Imho the main problem isn't > ::before and ::after, but the fact that, given the set of terms > > start, before, end, after > > it's not clear, without memorizing it beforehand, which set belongs > to which axis. Why does each axis have to have its own term? In a graph, both the x and y axis use "positive" and "negative"... A./ > I raised this particular issue years ago, but nobody > came up with a sensible alternative until this year. :/ > > I'll also note that there's an idea to extend break-before/break-after > to control inline breaking, in which case they would operate in the > start-end axis. > > Imho before/after make the most sense as "in the DOM axis", whatever > that happens to be. This is consistent with break-before/break-after, > consistent with ::before/::after, and consistent with the way we talk > about the relationship of boxes and elements in the specs. That axis > is not always parallel to the block axis. > > ~fantasai > >
Received on Wednesday, 10 October 2012 21:30:05 UTC