- From: Alan Stearns <stearns@adobe.com>
- Date: Mon, 30 Sep 2013 08:50:26 -0700
- To: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>
- CC: Elliott Sprehn <esprehn@gmail.com>
On 9/30/13 8:02 AM, "Simon Pieters" <simonp@opera.com> wrote: >On Sat, 28 Sep 2013 00:52:32 +0200, Alan Stearns <stearns@adobe.com> >wrote: > >> 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. > >FWIW PseudoElement is already specced: > >http://dev.w3.org/csswg/cssom/#the-pseudoelement-interface It seems odd that I can get from an Element to a PseudoElement, but there's no way to get back from the PseudoElement to the Element (or find out which PseudoElement it is). Am I missing something? In any case, it's easy enough to say in a spec: Element implements Region PseudoElement implements Region But the question then is what happens with the NamedFlow.getRegions() call, which is intended to return a sequence of Regions. If those Regions can be either an Element or a PseudoElement, what then? Either we need to have a common base class that both Element and PseudoElement can inherit from, or we have to introduce multiple inheritance. Neither of those options appear feasible in the WebKit/Blink codebase (for this one small use case, at least). So it seems to me that making Region a standalone interface would be a better, incremental step. Thanks, Alan
Received on Monday, 30 September 2013 15:51:15 UTC