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

[css3-regions] Limitations and missing use-cases for Region CSSOM interface

From: Mihai Balan <mibalan@adobe.com>
Date: Tue, 10 Jul 2012 18:06:10 +0100
To: WWW Style <www-style@w3.org>
Message-ID: <32E5AE8565CC6142BA0AAFA5A95697E04616C31410@eurmbx01.eur.adobe.com>
Hi all,

One of the major changes between the November 2011 WD and the May 2012 WD for CSS regions was dropping the additions to the Element DOM interface and extracting them to a new, more "abstract" Region interface (with some additional functionality) .

While this makes sense for some of the new CSSOM features (e.g. getComputedStyle() for region styling), some use-cases that were possible as per the previous WD are not possible anymore with the latest. Below is a list with use-cases that are no longer possible and some suggested changes to the spec to (re)enable them. Feedback and/or other suggestions are greatly apprectiated (as well as other use-cases/limitations):

1.       Getting the specific region for a CSS selector
In the Nov. 2011 WD getting to a specific region in the region chain (or in the document as a whole) was simply a matter of calling document.getElementById() or querySelector(). In the May 2012 WD the same result requires more complicated logic for traversing a sequence of Region-s and stopping at the one(s) that interest us. Also it requires more assumptions about the over-all structure of the document (e.g. the logic may break if the regions are shuffled around in the document)
Proposed change: Add a way to get the region corresponding to an element (maybe as an addition to the NamedFlow interface?)
Use-cases:

a.       Use a CSS selector to select a range of regions and query their regionOverset property to remove the empty regions

2.       Access to Region box geometry (and style)
Since Region instances are no longer Element-s and they bear no linking to the underlying CSS box it's impossible to query or change at run-time the CSS properties of the region based on the region-specific properties
Proposed change: Augment Region interface with a way to access the underlying element/box
Use-cases:

a.       Changing the dimensions of the regions in order to make sure the content properly fits in the region chain

b.      Changing the dimensions of the regions in a region chain to evenly distribute content across regions

c.       Visually format regions based on their overflow status (empty/fit/overflow)

3.       Comparing Region interface instances
Currently the spec does not mention if Region interface instances are comparable for equality (as opposed to Element-s that are comparable for equality). This makes it dificult to write code that conditionally traverses and manipulates sequences of Region-s (as returned by NamedFlow.getRegions() and NamedFlow.getRegionsByContent() ).
Proposed change: Regions should be comparable for equality and the spec should detail when two Region instances are considered equal.
Use-cases:

a.       Checking if a region is in a sequence of regions in order to filter it out

b.      Set-operations on sequences of Region-s. Useful for things like highlighting certains regions in a region chain based on the URL of the page e..g. bookmarking

My feeling is that some of the changes were made to move away from the 1 region == 1 dom element scenoario, but in doing so a lot of useful stories break. Feel free to add your own use-cases or suggestions

Thanks in advance,
Mihai

Mihai Balan | Quality Engineer / WebKit team |  mibalan@adobe.com<mailto:mibalan@adobe.com> | +4-031.413.3653 / x83653 | Adobe Systems Romania
Received on Tuesday, 10 July 2012 19:29:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:56 GMT