- From: Alex Mogilevsky <alexmog@microsoft.com>
- Date: Wed, 25 Apr 2012 15:29:35 +0000
- To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
± From: fantasai [mailto:fantasai.lists@inkedblade.net] ± Sent: Friday, April 20, 2012 4:03 PM ± ± There are several places in the Flexbox algorithm where it seems assumed that ± the writing mode of the flexbox item is the same as that of the flexbox. This ± isn't a true assumption, so the algorithm needs to be fixed to define these ± cases. Can you point at such places? Flexbox is generally agnostic to what happens inside the items, including their inner layout type and most certainly writing mode. Issues of mixed writing modes have to be addressed in writing-modes spec or in specs for individual layout types (for issues of being inside a parent with a different writing mode)... If there are still places where flexbox spec says something that implies same writing mode in a child, it must be corrected. Perhaps you refer to baselines? Column-direction flexbox always treats 'baseline' alignment as 'center', while its children can have baselines in block direction. We should fix that. What else? ± Also the pagination section seems to assume that the writing mode of the ± flexbox is the same as that of the fragmenter. This is also not always true. ± So the issue of columns vs. rows is really one of main axis parallel to ± fragmenter's block axis vs. main axis perpendicular to fragmenter's block ± axis. We should say in the beginning of pagination algorithm that it only applies in parallel fragmenter. Unless fragmentation spec has a blanket statement on that. Alex
Received on Wednesday, 25 April 2012 15:31:18 UTC