On 7/26/12 2:36 PM, "Adam Barth" <aba...@webkit.org> wrote:
> >On Thu, Jul 26, 2012 at 2:29 PM, Alexandru Chiculita <ach...@adobe.com> >wrote: > >I don't see any advantage in having the interface anyway, so why don't we >just it let be a separate object and add two helper methods instead. I >can only imagine that other browsers might have the same issue anyway. > >document.getRegionForElement(element) >-> where element can be both Element and CSSPseudoElement >-> this may return null in case of no region being associated, so there's >no need for instanceof tricks anymore. > >region.element >-> that can return either Element or CSSPseudoElement > >BTW, is there any base class shared across Element and CSSPseudoElement? > > >Greping for CSSPseudoElement in WebCore appears to return zero results. > > >Discussing this issue with Sam in #webkit, we wondered whether another >solution is to not implement the CSSOM for Regions. Is there are strong >use case for having this CSSOM in the first place? > > >Adam CSSPseudoElement is something I want to bring up soon in the CSS WG. Future extensions like this as to what can become a CSS Region is the motivation for separating out the Region interface. Whether there's a shared base class that makes sense is still to be determined. There are strong use cases for the object model for CSS Regions. Adobe has projects we'd like to base on CSS Regions, and script access will be vital for these efforts. We've also been building prototypes of other CSS extensions using the CSS Regions OM. I understand that there are projects based on IE10's version of CSS Regions where script access is required. And in general I'd rather avoid adding new things to the platform that are opaque to scripting. For Alex's suggestion above, would there be any problems with a parameter (for the first method) and return type (for the second) that could be an Element or something else? Adding two helper methods seems messier to me than what's currently specced, but I'm open to the idea if it's much easier to implement. Thanks, Alan _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
