W3C home > Mailing lists > Public > www-style@w3.org > July 2011

RE: [css3-exclusions] processing model

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Sat, 23 Jul 2011 23:47:00 +0000
To: "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E5398569284120C3744@TK5EX14MBXC218.redmond.corp.microsoft.com>
I think it is a strength of CSS Exclusions spec that it is staying away from positioning (including complex dependencies and collisions that it involves) and focuses on definition and effect of exclusions. For a full definition of wrapping behaviors that match applications like Word or InDesign we need a full CSS3 Floats spec, including all or most of GCPM floats...

We do have to define a processing model that resolves dependencies like in your example. I think we are prepared to have a productive discussion on that at F2F. It is an open question which spec the detailed processing model belongs to (I think CSS3 Floats). However it shouldn't block CSS Exclusions progress. I can even imagine leaving much of processing model undefined, leaving UAs room for improvements, while defining enough for perfect interop in cases with no circular dependencies or collisions...

One related issue that was a surprising discovery for me recently - it is the default order of effect of elements with exclusions on each other (what happens if 'wrap-shape-order' doesn't exist or not set). 
- normally in layout, earlier elements affect later elements
- visually, later elements are above earlier elements
- if default wrapping order is wrapping later elements around earlier elements, wrapping order is opposite to paint order. The result is almost never acceptable without manually tweaking z-order

That logic leads to conclusion that default wrapping order should be such that when later elements overlap earlier elements, earlier content wraps around later content. It is the worst option for performance, but it seems to be the only option that creates reasonable defaults...

If it helps at all, overlapping text boxes have same priority (boxes created later are on top and text below them wraps) in MS Publisher (I would try in InDesign if I had it; need to check).

Exclusions in scrollable content: I strongly believe content should not reflow when scrolling happens. It is similar to absolute elements inside non-position scrollers - auto position of positioned elements is calculated with scroll at zero and is not changing with scroll).


-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of L. David Baron
Sent: Saturday, July 23, 2011 4:04 PM
To: www-style@w3.org
Subject: [css3-exclusions] processing model

I'm reading http://dev.w3.org/csswg/css3-exclusions/ and trying to understand the processing model that it implies (and the implementation strategy that that processing model would imply), and I'm having trouble understanding it.  (I think I may have understood more in the past during a discussion of the spec, but I'm not able to remember that by reading the spec.)

In particular, the specification appears to be proposing a model where *any* element (normal flow or not) can create an exclusion that applies to all content not in a lower exclusion (ranked by 'wrap-shape-order' with ties broken by DOM order).  (I think this is a bad idea.)

However, in most positioning models (for example, the normal flow,
floats) the position of later content depends on the size of earlier content, which in turn depends on how that content is wrapped.

Thus it seems that the spec can require an element A's text to wrap around another element B whose position depends on the size (and thus wrapping) of element A.  For example:
  #b { margin-top: -5em; wrap-shape: circle(5em, 50%, 5em) }
  <div id="a">text text ... </div>
  <div id="b"></div>

I don't see anything in the spec that explains how such situations should be resolved.

(Another issue with such a general model relates to scrollable
elements:  the spec implies that text in a scrollable element must be rewrapped as the element scrolls; we had this bug with floats prior to CSS 2.1.  Other things that establish new block formatting contexts may have similar issues.)


𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla Corporation               http://www.mozilla.com/   𝄂

Received on Saturday, 23 July 2011 23:47:41 UTC

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