- From: Alan Stearns <stearns@adobe.com>
- Date: Fri, 27 Sep 2013 15:52:32 -0700
- To: "www-style@w3.org" <www-style@w3.org>
- CC: Elliott Sprehn <esprehn@gmail.com>
Hey all, I had a short conversation this week with Elliot Sprehn, who advised that we change the Region interface a bit. Currently it's a supplemental interface that Element implements. The original idea was that anything that could be made into a region could also implement this interface. But it turns out it may not be practical to allow the Region interface to be implemented by (for instance) a future CSSPseudoElement interface. So instead, we could make the Region interface standalone, with two attributes pointing back to what's been made into a region. So we'd end up with this: interface Region { readonly attribute Element element; readonly attribute DOMString pseudoElement; readonly attribute DOMString regionOverset; sequence<Range>? getRegionFlowRanges(); CSSStyleDeclaration getComputedRegionStyle(Element elt); CSSStyleDeclaration getComputedRegionStyle(Element elt, DOMString pseudoElt); }; Where if the Region has been made from an Element, the element attribute will point to that Element and the pseudoElement string will be empty. But if a Region has been made from a pseudo-element, the element attribute will point to the Element hosting that pseudo-element and the pseudoElement string will contain the name of that pseudo-element ("::before", "::after" etc.). I'm following the pattern I see in TransitionEvent [1] for the pseudoElement attribute. It's not quite as nice to get from a Region to an Element, but it does allow access to pseudo-element regions *now*, instead of in some unspecified (and perhaps impossible) future. I think that's a worthy tradeoff. Thanks, Alan [1] http://dev.w3.org/csswg/css-transitions/#Events-TransitionEvent
Received on Friday, 27 September 2013 22:53:00 UTC