- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 25 Jun 2012 14:51:29 -0700
- To: robert@ocallahan.org
- Cc: Rossen Atanassov <Rossen.Atanassov@microsoft.com>, Alan Stearns <stearns@adobe.com>, www-style <www-style@w3.org>
On Thu, Jun 21, 2012 at 4:20 PM, Robert O'Callahan <robert@ocallahan.org> wrote: > On Fri, Jun 15, 2012 at 9:30 AM, Rossen Atanassov > <Rossen.Atanassov@microsoft.com> wrote: >> Thanks Rob, the proposed text sounds good and I’ll try to push it into the >> ED. Still, I am still puzzled by the insistence on this spec to be different >> and specify everything in terms of fragmentation. > > > Existing specs often fail to take account of the one-to-many relationship of > elements and boxes, and have had lots of ambiguities as a result, so > existing spec text is often not a good model to follow :-(. Some specs do > take account of multiple boxes where the problems became glaringly obvious > and editors were responsive, e.g. CSSOM View discusses multiple boxes in a > few places. > > I don't think we should try to have the Fragmentation spec define how every > other spec should be modified to handle elements with multiple boxes. There > isn't a uniform way to do those modifications, so it would violate spec > modularity and make things very hard to understand since you'd constantly be > referring to CSS Fragmentation to understand how each spec actually needs to > work. E.g., I think Flexbox spec, not the Fragmentation spec, should define > any differences between pagination of flexboxes and other kinds of boxes, > and it should define how flexbox features should work in the presence of > pagination. Which it does (though informatively for now, until we get feedback), and I agree that it's definitely a custom job every time. Every layout spec has its own special foibles and invariants it would like to maintain in the face of fragmentation. ~TJ
Received on Monday, 25 June 2012 21:52:19 UTC