- 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