- From: Alex Mogilevsky <alexmog@microsoft.com>
- Date: Wed, 2 Mar 2011 19:23:19 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- CC: www-style list <www-style@w3.org>
There are already precedents with anonymous blocks - in text and in tables. They are actually "blocks" in 2.1, which is neither boxes nor elements (nor is it defined what's a block, is it?) I guess it is fine with me if for the purposes of the spec we mention "box tree" if it helps to get clear definitions but it doesn't really need to exist in implementation... If analogy with anonymous blocks in text is any good, those definitely don’t need to be implemented while being fully compliant with spec behavior. As far as targeting anonymous blocks with selectors, I am not too excited about that idea. The main reason (or maybe even the only reason) we have anonymous boxes in flexbox and grid is to deal with malformed content. I really don't see why would we add features that add intentional functionality to what technically is an authoring bug... -----Original Message----- From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] Sent: Monday, February 28, 2011 6:25 PM I've inserted an issue about exactly how to define the flexbox-fixup algorithm. Similar to the table-fixup algorithm, it clearly has to take place over the element-tree, but it creates boxes, which only exist in the box-tree. I believe a compromise could work - the algorithm instead creates anonymous pseudoelements. Pseudoelems don't mess up Selectors, and they interact with the rest of box-tree construction in precisely the way we want. Being anonymous, they can't be targeted, either, though we could perhaps introduce a way to target them, probably all at once, to specify margins/padding/flex on them to match the rest of the flexbox items. This could help with using flexbox to display <figure>, for example, so you don't need to insert a wrapper around the content just so you can feed it flexbox properties. ~TJ
Received on Wednesday, 2 March 2011 19:23:54 UTC