Re: [webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

On Wed, Aug 1, 2012 at 9:45 AM, Andrei Bucur  wrote:
> On 7/27/12 1:55 AM, "Adam Barth"  wrote:
>>Perhaps it would make sense to start with a smaller CSSOM for Regions
>>that uses established patterns and techniques.  That way we can gain
>>experience with these patterns and techniques before jumping into API
>>designs that don't follow existing patterns and introduce complexity
>>across the entire platform.
>
> In the light of the recent discussions I think the best action to take is
> not to add the Region interface in WebKit at this moment. Instead of that,
> we should move the members from the Region interface to the Element
> interface and implement them there. The
> NamedFlow.getRegions()/getRegionsByContent() methods would then return a
> sequence of Elements.
>
> When other types of DOM/CSSOM objects will be able to become regions (such
> as pseudo-elements) we will take another look at implementing the
> supplemental interfaces mechanism.
>
> The downside with taking this path is the region sequences returned by the
> NamedFlow API functions will not contain the pseudo-elements that are
> regions. However, I think this is an issue we can live with :).
>
> Thoughts?

I think that's a wise course of action.  Nothing prevents us from
inventing the Regions interface in the future since nothing observable
will change in JavaScript.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Andrei Bucur]

Hi Adam,

On 7/27/12 1:55 AM, "Adam Barth"  wrote:

>Perhaps it would make sense to start with a smaller CSSOM for Regions
>that uses established patterns and techniques.  That way we can gain
>experience with these patterns and techniques before jumping into API
>designs that don't follow existing patterns and introduce complexity
>across the entire platform.

In the light of the recent discussions I think the best action to take is
not to add the Region interface in WebKit at this moment. Instead of that,
we should move the members from the Region interface to the Element
interface and implement them there. The
NamedFlow.getRegions()/getRegionsByContent() methods would then return a
sequence of Elements.

When other types of DOM/CSSOM objects will be able to become regions (such
as pseudo-elements) we will take another look at implementing the
supplemental interfaces mechanism.

The downside with taking this path is the region sequences returned by the
NamedFlow API functions will not contain the pseudo-elements that are
regions. However, I think this is an issue we can live with :).

Thoughts?

Thanks,
Andrei.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

On Thu, Jul 26, 2012 at 3:45 PM, Alexandru Chiculita wrote:

>
> On 26.07.2012, at 14:36, Adam Barth wrote:
>
>
> 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?
>
>
> I think CSSOM for Regions has 3 major use-cases:
>
> 1. Let JS discover what flow-threads are available in a document without
> having to parse the CSS file. Also it allows finding the content and
> regions associated with a specific flow
> 2. Discover if the flow-thread had enough regions to flow its whole
> content.
> 3. Get an event when more content has been added to the flow and more
> regions are needed.
>
> I suppose that 1 is needed for interactivity. It's not something that JS
> cannot do already by just greping through the CSS Styles, but I suppose it
> might be a lot faster to just expose it as an API. I guess that a framework
> will do it anyway like it happened before querySelector was exposed.
>
> The need for 2 is removed by the other module that Alan is working on.
> Developers would be able to describe using only CSS how the layout can add
> more regions when needed. However, I have a feeling that this is very
> similar to the debate about using javascript positioned elements versus
> flexbox/grid/normal-layout/tables, meaning that both ways have their pros
> and cons. Actually, they could complement each other.
>
> Just to give a small set of examples:
> - on a touch device, regions can be used to emulate paginated views -
> javascript can be used to switch pages and detect when more pages are needed
>

Why not just use pagenation instead of hacking it together with regions?


> - regions can be arranged in different templates - javascript can be used
> to download more templates as the user starts to scroll through pages
>
> I think the biggest pain is 3 because it exposes the information that
> layout was done and that has no precedence. There are other events that
> could be used instead, like window resize, or orientation change, but those
> do not catch the changes in content. The event is meant to improve pages
> that need interactivity inside the flows. For example, when an image inside
> the flow-thread has an unknown height,  but it is loaded and decoded 3
> seconds later. That might need a new region and JS would not know about it.
> Anyway, that is always possible to fix using JS hacking on other events
> like onload, onresize, onchange and other DOM added/removed. If this event
> is indeed a good idea, then I can see an opportunity to extend it to
> non-region based content too.
>

Exposing when we do layout to content seems like an interoperability
nightmare.  Different engine decide when to perform layout using entirely
different criteria.  Maybe I've misunderstood what you wrote.

On 26.07.2012, at 15:15, Adam Barth wrote:
>
> It depends on how many things will implement Region.  If there are N
> things, you'll need to add N properties and you're essentially asking web
> developers to call QueryInterface on the object to see what sort of Region
> it really is.
>
> Why do you need N properties? I was suggesting to use the "region.element"
> property for any other object type that we add? Maybe with a different
> better naming, like "associatedRenderer" or "region.viewportElement".
>
> If CSSPseudoElement would be designed to derive from the same base class
> as Element and share most of their style/layout properties, then 99% of the
> time people will just do region.element.style.top = '100px'; and no query
> interface would be needed.
>

I'm skeptical that can work.  If CSSPseudoElement is a Node, then it can be
moved around the DOM like any other node, which makes no sense.

The more we discuss this topic, the more worried I become that the authors
of this specification do not understand the DOM.  I suspect there is some
sort or knowledge and/or cultural barrier between the CSS working group and
the HTML and DOM communities.

Perhaps it would make sense to start with a smaller CSSOM for Regions that
uses established patterns and techniques.  That way we can gain experience
with these patterns and techniques before jumping into API designs that
don't follow existing patterns and introduce complexity across the entire
platform.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Elliott Sprehn]

On Thu, Jul 26, 2012 at 3:45 PM, Alexandru Chiculita wrote:

> ...
> If CSSPseudoElement would be designed to derive from the same base class
> as Element and share most of their style/layout properties, then 99% of the
> time people will just do region.element.style.top = '100px'; and no query
> interface would be needed.
>
>
I brought this up in #webkit yesterday, but Adam Barth made a good point
that making CSSPseudoElement an Element means you could appendChild it
anywhere, or even append children to it which doesn't make sense.

You could make detaching a CSSPseudoElement or appending a child to it an
error (which is easy since that's centralized in WebKit), but it's a little
weird in the spec.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Alexandru Chiculita]

On 26.07.2012, at 14:36, Adam Barth wrote:

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?

I think CSSOM for Regions has 3 major use-cases:

1. Let JS discover what flow-threads are available in a document without having 
to parse the CSS file. Also it allows finding the content and regions 
associated with a specific flow
2. Discover if the flow-thread had enough regions to flow its whole content.
3. Get an event when more content has been added to the flow and more regions 
are needed.

I suppose that 1 is needed for interactivity. It's not something that JS cannot 
do already by just greping through the CSS Styles, but I suppose it might be a 
lot faster to just expose it as an API. I guess that a framework will do it 
anyway like it happened before querySelector was exposed.

The need for 2 is removed by the other module that Alan is working on. 
Developers would be able to describe using only CSS how the layout can add more 
regions when needed. However, I have a feeling that this is very similar to the 
debate about using javascript positioned elements versus 
flexbox/grid/normal-layout/tables, meaning that both ways have their pros and 
cons. Actually, they could complement each other.

Just to give a small set of examples:
- on a touch device, regions can be used to emulate paginated views - 
javascript can be used to switch pages and detect when more pages are needed
- regions can be arranged in different templates - javascript can be used to 
download more templates as the user starts to scroll through pages

I think the biggest pain is 3 because it exposes the information that layout 
was done and that has no precedence. There are other events that could be used 
instead, like window resize, or orientation change, but those do not catch the 
changes in content. The event is meant to improve pages that need interactivity 
inside the flows. For example, when an image inside the flow-thread has an 
unknown height,  but it is loaded and decoded 3 seconds later. That might need 
a new region and JS would not know about it. Anyway, that is always possible to 
fix using JS hacking on other events like onload, onresize, onchange and other 
DOM added/removed. If this event is indeed a good idea, then I can see an 
opportunity to extend it to non-region based content too.

On 26.07.2012, at 15:15, Adam Barth wrote:

It depends on how many things will implement Region.  If there are N things, 
you'll need to add N properties and you're essentially asking web developers to 
call QueryInterface on the object to see what sort of Region it really is.
Why do you need N properties? I was suggesting to use the "region.element" 
property for any other object type that we add? Maybe with a different better 
naming, like "associatedRenderer" or "region.viewportElement".

If CSSPseudoElement would be designed to derive from the same base class as 
Element and share most of their style/layout properties, then 99% of the time 
people will just do region.element.style.top = '100px'; and no query interface 
would be needed.

Regards,
Alex

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

On Thu, Jul 26, 2012 at 3:39 PM, Alan Stearns  wrote:

> On 7/26/12 3:15 PM, "Adam Barth"  wrote:
> >
> >On Thu, Jul 26, 2012 at 2:58 PM, Alan Stearns  wrote:
> >
> >On 7/26/12 2:36 PM, "Adam Barth"  wrote:
> >...
> >>
> >>
> >>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?
> >
> >...
> >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.
> >
> >That all seems very vague.  Can you explain what you have in mind?
>
> Here's a few:
>
> 1. Modifying the region chain based on content changes or window resizing.
> This could involve adding or removing CSS Regions, or changing region
> geometry.
> 2. Handing events on named flow contents - using the OM to determine the
> CSS Region(s) that contain the content.
> 3. Layout extensions implemented via script (script-based layout
> constraints can change region chain geometry).
> 4. Paginated views that use script to navigate or search (use the OM to
> determine the page to display).
>

Again, I feel like I'm running up against my lack of knowledge about
Regions.  It seems to resolve this issue, we need someone who understands
the benefits of this feature as well as the implementation costs.  So far,
I'm not sure we've found such a person.  As a consequence, we're unable to
make an informed decision.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Alan Stearns]

On 7/26/12 3:15 PM, "Adam Barth"  wrote:
>
>On Thu, Jul 26, 2012 at 2:58 PM, Alan Stearns  wrote:
>
>On 7/26/12 2:36 PM, "Adam Barth"  wrote:
>...
>>
>>
>>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
>
>...
>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.
>
>
>
>
>That all seems very vague.  Can you explain what you have in mind?

Here's a few:

1. Modifying the region chain based on content changes or window resizing.
This could involve adding or removing CSS Regions, or changing region
geometry.
2. Handing events on named flow contents - using the OM to determine the
CSS Region(s) that contain the content.
3. Layout extensions implemented via script (script-based layout
constraints can change region chain geometry).
4. Paginated views that use script to navigate or search (use the OM to
determine the page to display).

Thanks,

Alan

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

Please see my initial email for the answer to that question.  Specifically,
you're suggesting that the answer to question (A) is "no" and the answer to
question (B) is "build another one-off RTTI replacement."

Adam


On Thu, Jul 26, 2012 at 3:35 PM, Andrei Bucur  wrote:

> Identifying what the Region actually is sounds very similar with
> identifying the nature of a Node using NodeType? Is this pattern applicable
> here as well?
>
> ** **
>
> https://developer.mozilla.org/en/nodeType
>
> ** **
>
> Andrei.
>
> ** **
>
> *From:* webkit-dev-boun...@lists.webkit.org [mailto:
> webkit-dev-boun...@lists.webkit.org] *On Behalf Of *Adam Barth
> *Sent:* Friday, July 27, 2012 1:15 AM
> *To:* Alan Stearns
> *Cc:* Kentaro Hara; Elliott Sprehn; webkit-dev@lists.webkit.org; Sam
> Weinig
>
> *Subject:* Re: [webkit-dev] Multiple inheritance in the DOM
>
> ** **
>
> 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.
>
> ** **
>
> It depends on how many things will implement Region.  If there are N
> things, you'll need to add N properties and you're essentially asking web
> developers to call QueryInterface on the object to see what sort of Region
> it really is.
>
> ** **
>
> Adam
>
> ** **
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Andrei Bucur]

Identifying what the Region actually is sounds very similar with identifying 
the nature of a Node using NodeType? Is this pattern applicable here as well?

https://developer.mozilla.org/en/nodeType

Andrei.

From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Adam Barth
Sent: Friday, July 27, 2012 1:15 AM
To: Alan Stearns
Cc: Kentaro Hara; Elliott Sprehn; webkit-dev@lists.webkit.org; Sam Weinig
Subject: Re: [webkit-dev] Multiple inheritance in the DOM

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.

It depends on how many things will implement Region.  If there are N things, 
you'll need to add N properties and you're essentially asking web developers to 
call QueryInterface on the object to see what sort of Region it really is.

Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

On Thu, Jul 26, 2012 at 2:58 PM, Alan Stearns  wrote:

> On 7/26/12 2:36 PM, "Adam Barth"  wrote:
>
> >
> >On Thu, Jul 26, 2012 at 2:29 PM, Alexandru Chiculita 
> >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.
>

That all seems very vague.  Can you explain what you have in mind?


> 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.
>

It depends on how many things will implement Region.  If there are N
things, you'll need to add N properties and you're essentially asking web
developers to call QueryInterface on the object to see what sort of Region
it really is.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Alan Stearns]

On 7/26/12 2:36 PM, "Adam Barth"  wrote:

>
>On Thu, Jul 26, 2012 at 2:29 PM, Alexandru Chiculita 
>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

Re: [webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

On Thu, Jul 26, 2012 at 2:29 PM, Alexandru Chiculita wrote:

>
> On 25.07.2012, at 18:16, Alan Stearns wrote:
>
> > From:  Adam Barth 
> > Date:  Wednesday, July 25, 2012 6:05 PM
> > To:  Sam Weinig 
> > Cc:  Elliott Sprehn , Alan Stearns
> > , Kentaro Hara ,
> > "webkit-dev@lists.webkit.org" 
> > Subject:  Re: [webkit-dev] Multiple inheritance in the DOM
> >
> > On Wed, Jul 25, 2012 at 6:00 PM, Sam Weinig  wrote:
> >
> > On Jul 25, 2012, at 5:53 PM, Elliott Sprehn  wrote:
> >
> >>>> It seems like this should really be a [NoInterfaceObject].
> >>>> That resolves the issue of multiple inheritance since you
> >>>> can no longer do instanceof Region, and I'm not sure why
> >>>> you'd ever want to do that anyway.
> >
> >>> I agree.
> >
> >> That doesn't solve the problem.
> >
> > But it's a good idea. I'll add it to the spec.
>
> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Alexandru Chiculita]

On 25.07.2012, at 18:16, Alan Stearns wrote:

> From:  Adam Barth 
> Date:  Wednesday, July 25, 2012 6:05 PM
> To:  Sam Weinig 
> Cc:  Elliott Sprehn , Alan Stearns
> , Kentaro Hara ,
> "webkit-dev@lists.webkit.org" 
> Subject:  Re: [webkit-dev] Multiple inheritance in the DOM
> 
> On Wed, Jul 25, 2012 at 6:00 PM, Sam Weinig  wrote:
> 
> On Jul 25, 2012, at 5:53 PM, Elliott Sprehn  wrote:
> 
>>>> It seems like this should really be a [NoInterfaceObject].
>>>> That resolves the issue of multiple inheritance since you
>>>> can no longer do instanceof Region, and I'm not sure why
>>>> you'd ever want to do that anyway.
> 
>>> I agree.
> 
>> That doesn't solve the problem.
> 
> But it's a good idea. I'll add it to the spec.

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?

Thanks,
Alex
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Dirk Schulze]

On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:

> On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze  wrote:
>> On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
>>> Eric Seidel points out that SVG uses multiple inheritance in its DOM
>>> interfaces.  However, the situation there is a bit different.
>>> Although SVGSVGElement implements SVGLocatable, there aren't any
>>> interfaces with methods that return SVGLocatable, which means we don't
>>> need to implement toJS(SVGLocatable*).
>> 
>> SVG 2 will use WebIDL. Therefore we also reorganize our inheritance 
>> behavior. Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED 
>> soon.
> 
> Do you anticipate adding properties or functions that return
> interfaces like SVGLocatable?
Here is a Wiki what we plan to do: 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization

It might not reflect all changes that we discussed during the SVG WG meeting 
today.

Greetings,
Dirk

> 
> Adam
> 
> 
>>> He also points out that Node inherits from EventTarget, which already
>>> contains a virtual interfaceName() function similar to that used by
>>> Event.  That pushes us further towards using a common DOMInterface
>>> base class because introducing Region::interfaceName would mean that
>>> Element would see both EventTarget::interfaceName and
>>> Region::interfaceName.
>>> 
>>> Adam
>>> 
>>> 
>>> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
 The CSS Regions specification [1] defines a CSSOM interface named
 Region, which can be mixed into interfaces for other objets that can
 be CSS regions.  That means that Region introduces a form of multiple
 inheritance into the DOM.  For example, Element implements Region but
 Node does not implement Region.
 
 There's a patch up for review that implements Region using C++
 multiple inheritance [2]:
 
 - class Element : public ContainerNode {
 + class Element : public ContainerNode, public CSSRegion {
 
 One difficulty in implementing this feature how to determine the
 correct JavaScript wrapper return for a given Region object.
 Specifically, toJS(Region*) needs to return a JavaScript wrapper for
 an Element if the Region pointer actually points to an Element
 instance.
 
 We've faced a similar problem elsewhere in the DOM when implementing
 normal single inheritance.  For example, there are many subclass of
 Event and toJS(Event*) needs to return a wrapper for the appropriate
 subtype.  To solve the same problem, CSSRule has a m_type member
 variable and a bevy of isFoo() functions [3].
 
 A) Should we push back on the folks writing the CSS Regions
 specification to avoid using multiple inheritance?  As far as I know,
 this is the only instance of multiple inheritance in the platform.
 Historically, EventTarget used multiple inheritance, but that's been
 fixed in DOM4 [4].
 
 B) If CSS Regions continues to require multiple inheritance, should we
 build another one-off RTTI replacement to implement toJS(Region*), or
 should we improve our bindings to implement this aspect of WebIDL more
 completely?
 
 One approach to implementing toJS in a systematic way is to introduce
 a base class DOMInterface along these lines:
 
 class DOMInterface {
 public:
   virtual const AtomicString& primaryInterfaceName() = 0;
 }
 
 That returns the name of the primary interface (i.e., as defined by
 WebIDL [5]).  When implementing toJS, we'd then call
 primaryInterfaceName to determine which kind of wrapper to use.
 
 One downside of this approach is that it introduces a near-universal
 base class along the lines of IUnknown [6] or nsISupports [7].  I
 don't think any of us want WebKit to grow an implementation of
 XPCOM...
 
 I welcome any thoughts you have on this topic.
 
 Thanks,
 Adam
 
 [1] http://dev.w3.org/csswg/css3-regions/
 [2] https://bugs.webkit.org/show_bug.cgi?id=91076
 [3] 
 http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
 [4] http://www.w3.org/TR/dom/#node
 [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
 [6] 
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
 [7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Alan Stearns]

From:  Adam Barth 
Date:  Wednesday, July 25, 2012 6:05 PM
To:  Sam Weinig 
Cc:  Elliott Sprehn , Alan Stearns
, Kentaro Hara ,
"webkit-dev@lists.webkit.org" 
Subject:  Re: [webkit-dev] Multiple inheritance in the DOM

On Wed, Jul 25, 2012 at 6:00 PM, Sam Weinig  wrote:

On Jul 25, 2012, at 5:53 PM, Elliott Sprehn  wrote:

>>>It seems like this should really be a [NoInterfaceObject].
>>>That resolves the issue of multiple inheritance since you
>>>can no longer do instanceof Region, and I'm not sure why
>>>you'd ever want to do that anyway.

>>I agree.

>That doesn't solve the problem.

But it's a good idea. I'll add it to the spec.

Thanks,

Alan

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Alan Stearns]

On 7/25/12 6:12 PM, "Sam Weinig"  wrote:

>
>On Jul 25, 2012, at 5:37 PM, Sam Weinig  wrote:
>
>> 
>> On Jul 25, 2012, at 5:13 PM, Alan Stearns  wrote:
>> 
>>> On 7/25/12 4:49 PM, "Kentaro Hara"  wrote:
>>> 
 A) Should we push back on the folks writing the CSS Regions
 specification to avoid using multiple inheritance?  As far as I
>>> know,
 this is the only instance of multiple inheritance in the platform.
 Historically, EventTarget used multiple inheritance, but that's
been
 fixed in DOM4 [4].
 
 If it is possible to avoid the multiple inheritance, that would be
best.
>>> 
>>> From the WebIDL side, it's not strictly multiple inheritance. It's
>>>merely
>>> a supplemental interface that more than one object can implement. None
>>>of
>>> the members of the Region interface can clash with any of the members
>>>of
>>> the object that implements it.
>>> 
>>> Right now Elements can become CSS Regions, but in the future other
>>>objects
>>> will be able to become CSS Regions. As far as I know, the correct way
>>>to
>>> specify this kind of relation is with WebIDL supplemental interfaces.
>>>I'd
>>> rather figure out the correct way to add this WebIDL functionality to
>>> WebKit now, than put something else into the spec and WebKit that we'll
>>> have to change later.
>>> 
>>> Thanks,
>>> 
>>> Alan
>> 
>> What other objects do you envision implementing CSSRegion?  With the
>>spec written the way it is now, I see no reason to make anything
>>virtual, or even have a Region class.  Just implement it in Element.  If
>>need to pull things out for code reuse purposes, we can do that when it
>>comes to that, but right now, there doesn't seem to be a need to
>>complicate things.
>> 
>> -Sam
>
>So, what I said isn't quite right, as I understand you actually can get a
>Region object (via getRegions()).  But, the point of not needing to solve
>the issue right now remains true (though thin).

No, you'll never actually get a Region object. What you get is a
sequence whose members will all be Elements or some other object
that implements the Region interface.

>
>That said, adding this type of multiple inheritance to the platform seems
>undesirable, and I think the standards body should work harder to come up
>with a solution that does not require it.
>
>-Sam
>
>


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Hajime Morrita]

If the only problem is to determine the type of JS wrappers, is it possible
to
make wrapSlow() a virtual method of some base class, instead of static
functions?

It need a tweak on the code generator. Also, it might need to avoid name
conflicts
by suffixing like wrapSlowForNode(), wrapSlowForRegion() etc.

This approach would make wrapSlow() a variation of QueryInterface(). But
considering that the functionality is limited and hard to abuse, it might
be better than having DOMInterface.



On Thu, Jul 26, 2012 at 9:53 AM, Alan Stearns  wrote:

> On 7/25/12 5:37 PM, "Sam Weinig"  wrote:
>
> >
> >On Jul 25, 2012, at 5:13 PM, Alan Stearns  wrote:
> >
> >> On 7/25/12 4:49 PM, "Kentaro Hara"  wrote:
> >>
> >>> A) Should we push back on the folks writing the CSS Regions
> >>> specification to avoid using multiple inheritance?  As far as I
> >> know,
> >>> this is the only instance of multiple inheritance in the platform.
> >>> Historically, EventTarget used multiple inheritance, but that's
> >>>been
> >>> fixed in DOM4 [4].
> >>>
> >>> If it is possible to avoid the multiple inheritance, that would be
> >>>best.
> >>
> >> From the WebIDL side, it's not strictly multiple inheritance. It's
> >>merely
> >> a supplemental interface that more than one object can implement. None
> >>of
> >> the members of the Region interface can clash with any of the members of
> >> the object that implements it.
> >>
> >> Right now Elements can become CSS Regions, but in the future other
> >>objects
> >> will be able to become CSS Regions. As far as I know, the correct way to
> >> specify this kind of relation is with WebIDL supplemental interfaces.
> >>I'd
> >> rather figure out the correct way to add this WebIDL functionality to
> >> WebKit now, than put something else into the spec and WebKit that we'll
> >> have to change later.
> >>
> >> Thanks,
> >>
> >> Alan
> >
> >What other objects do you envision implementing CSSRegion?  With the spec
> >written the way it is now, I see no reason to make anything virtual, or
> >even have a Region class.  Just implement it in Element.  If need to pull
> >things out for code reuse purposes, we can do that when it comes to that,
> >but right now, there doesn't seem to be a need to complicate things.
> >
> >-Sam
> >
>
> I have an upcoming proposal for a CSSPseudoElement object. You can make a
> pseudo-element like ::before or ::after into a CSS Region right now in
> WebKit. All that's lacking is a way to access those pseudo-elements from
> script.
>
> Thanks,
>
> Alan
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

On Wed, Jul 25, 2012 at 6:00 PM, Sam Weinig  wrote:

>
> On Jul 25, 2012, at 5:53 PM, Elliott Sprehn  wrote:
>
>
> On Wed, Jul 25, 2012 at 5:13 PM, Alan Stearns  wrote:
>
>> ...
>>
>> From the WebIDL side, it's not strictly multiple inheritance. It's merely
>> a supplemental interface that more than one object can implement. None of
>> the members of the Region interface can clash with any of the members of
>> the object that implements it.
>>
>> Right now Elements can become CSS Regions, but in the future other objects
>> will be able to become CSS Regions. As far as I know, the correct way to
>> specify this kind of relation is with WebIDL supplemental interfaces. I'd
>> rather figure out the correct way to add this WebIDL functionality to
>> WebKit now, than put something else into the spec and WebKit that we'll
>> have to change later.
>>
>>
> It seems like this should really be a [NoInterfaceObject]. That resolves
> the issue of multiple inheritance since you can no longer do instanceof
> Region, and I'm not sure why you'd ever want to do that anyway.
>
>
> I agree.
>

That doesn't solve the problem.  The problem arises from determining what
kind of wrapper to create for an WebCore::Region object (e.g., an Element
wrapper or a CSSPseudoElement wrapper).  It's easy for us to create the
proper constellation of prototype objects.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Alan Stearns]

On 7/25/12 5:37 PM, "Sam Weinig"  wrote:

>
>On Jul 25, 2012, at 5:13 PM, Alan Stearns  wrote:
>
>> On 7/25/12 4:49 PM, "Kentaro Hara"  wrote:
>> 
>>> A) Should we push back on the folks writing the CSS Regions
>>> specification to avoid using multiple inheritance?  As far as I
>> know,
>>> this is the only instance of multiple inheritance in the platform.
>>> Historically, EventTarget used multiple inheritance, but that's
>>>been
>>> fixed in DOM4 [4].
>>> 
>>> If it is possible to avoid the multiple inheritance, that would be
>>>best.
>> 
>> From the WebIDL side, it's not strictly multiple inheritance. It's
>>merely
>> a supplemental interface that more than one object can implement. None
>>of
>> the members of the Region interface can clash with any of the members of
>> the object that implements it.
>> 
>> Right now Elements can become CSS Regions, but in the future other
>>objects
>> will be able to become CSS Regions. As far as I know, the correct way to
>> specify this kind of relation is with WebIDL supplemental interfaces.
>>I'd
>> rather figure out the correct way to add this WebIDL functionality to
>> WebKit now, than put something else into the spec and WebKit that we'll
>> have to change later.
>> 
>> Thanks,
>> 
>> Alan
>
>What other objects do you envision implementing CSSRegion?  With the spec
>written the way it is now, I see no reason to make anything virtual, or
>even have a Region class.  Just implement it in Element.  If need to pull
>things out for code reuse purposes, we can do that when it comes to that,
>but right now, there doesn't seem to be a need to complicate things.
>
>-Sam
>

I have an upcoming proposal for a CSSPseudoElement object. You can make a
pseudo-element like ::before or ::after into a CSS Region right now in
WebKit. All that's lacking is a way to access those pseudo-elements from
script.

Thanks,

Alan

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Alan Stearns]

On 7/25/12 4:49 PM, "Kentaro Hara"  wrote:

 > A) Should we push back on the folks writing the CSS Regions
 > specification to avoid using multiple inheritance?  As far as I
know,
 > this is the only instance of multiple inheritance in the platform.
 > Historically, EventTarget used multiple inheritance, but that's been
 > fixed in DOM4 [4].
>
>If it is possible to avoid the multiple inheritance, that would be best.

>From the WebIDL side, it's not strictly multiple inheritance. It's merely
a supplemental interface that more than one object can implement. None of
the members of the Region interface can clash with any of the members of
the object that implements it.

Right now Elements can become CSS Regions, but in the future other objects
will be able to become CSS Regions. As far as I know, the correct way to
specify this kind of relation is with WebIDL supplemental interfaces. I'd
rather figure out the correct way to add this WebIDL functionality to
WebKit now, than put something else into the spec and WebKit that we'll
have to change later.

Thanks,

Alan

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Kentaro Hara]

>>> > A) Should we push back on the folks writing the CSS Regions
>>> > specification to avoid using multiple inheritance?  As far as I know,
>>> > this is the only instance of multiple inheritance in the platform.
>>> > Historically, EventTarget used multiple inheritance, but that's been
>>> > fixed in DOM4 [4].

If it is possible to avoid the multiple inheritance, that would be best.

>>> > - class Element : public ContainerNode {
>>> > + class Element : public ContainerNode, public CSSRegion {

Another concern is that if CSSRegion has any virtual method, this will
increase sizeof(Element) by 8 byte in a 64 bit architecture. A virtual
method table pointer is needed for each parent class of multiple
inheritance. (c.f. https://bugs.webkit.org/show_bug.cgi?id=88528)


>>> > B) If CSS Regions continues to require multiple inheritance, should we
>>> > build another one-off RTTI replacement to implement toJS(Region*), or
>>> > should we improve our bindings to implement this aspect of WebIDL more
>>> > completely?

If CSSRegions does require multiple inheritance, I think
DOMInterface::interfaceName() sounds reasonable as Adam pointed out.



On Thu, Jul 26, 2012 at 6:54 AM, Adam Barth  wrote:
> According to WebIDL, every platform object has a "primary" interface,
> as defined by .
> As long as that's the case, DOMInterface::interfaceName() should be
> sufficient to figure out which JavaScript wrapper to use.
>
> Adam
>
>
> On Wed, Jul 25, 2012 at 2:44 PM, Darin Fisher  wrote:
>> At least DOMInterface::interfaceName() is no where near as bad as COM's
>> QueryInterface.
>>
>> Provided we don't end up with any diamond inheritance hierarchies, we
>> shouldn't need
>> something as complicated as QueryInterface.
>>
>> -Darin
>>
>>
>>
>> On Wed, Jul 25, 2012 at 2:33 PM, Adam Barth  wrote:
>>>
>>> Eric Seidel points out that SVG uses multiple inheritance in its DOM
>>> interfaces.  However, the situation there is a bit different.
>>> Although SVGSVGElement implements SVGLocatable, there aren't any
>>> interfaces with methods that return SVGLocatable, which means we don't
>>> need to implement toJS(SVGLocatable*).
>>>
>>> He also points out that Node inherits from EventTarget, which already
>>> contains a virtual interfaceName() function similar to that used by
>>> Event.  That pushes us further towards using a common DOMInterface
>>> base class because introducing Region::interfaceName would mean that
>>> Element would see both EventTarget::interfaceName and
>>> Region::interfaceName.
>>>
>>> Adam
>>>
>>>
>>> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
>>> > The CSS Regions specification [1] defines a CSSOM interface named
>>> > Region, which can be mixed into interfaces for other objets that can
>>> > be CSS regions.  That means that Region introduces a form of multiple
>>> > inheritance into the DOM.  For example, Element implements Region but
>>> > Node does not implement Region.
>>> >
>>> > There's a patch up for review that implements Region using C++
>>> > multiple inheritance [2]:
>>> >
>>> > - class Element : public ContainerNode {
>>> > + class Element : public ContainerNode, public CSSRegion {
>>> >
>>> > One difficulty in implementing this feature how to determine the
>>> > correct JavaScript wrapper return for a given Region object.
>>> > Specifically, toJS(Region*) needs to return a JavaScript wrapper for
>>> > an Element if the Region pointer actually points to an Element
>>> > instance.
>>> >
>>> > We've faced a similar problem elsewhere in the DOM when implementing
>>> > normal single inheritance.  For example, there are many subclass of
>>> > Event and toJS(Event*) needs to return a wrapper for the appropriate
>>> > subtype.  To solve the same problem, CSSRule has a m_type member
>>> > variable and a bevy of isFoo() functions [3].
>>> >
>>> > A) Should we push back on the folks writing the CSS Regions
>>> > specification to avoid using multiple inheritance?  As far as I know,
>>> > this is the only instance of multiple inheritance in the platform.
>>> > Historically, EventTarget used multiple inheritance, but that's been
>>> > fixed in DOM4 [4].
>>> >
>>> > B) If CSS Regions continues to require multiple inheritance, should we
>>> > build another one-off RTTI replacement to implement toJS(Region*), or
>>> > should we improve our bindings to implement this aspect of WebIDL more
>>> > completely?
>>> >
>>> > One approach to implementing toJS in a systematic way is to introduce
>>> > a base class DOMInterface along these lines:
>>> >
>>> > class DOMInterface {
>>> > public:
>>> > virtual const AtomicString& primaryInterfaceName() = 0;
>>> > }
>>> >
>>> > That returns the name of the primary interface (i.e., as defined by
>>> > WebIDL [5]).  When implementing toJS, we'd then call
>>> > primaryInterfaceName to determine which kind of wrapper to use.
>>> >
>>> > One downside of this approach is that it introduces a near-universal
>>> > base cla

Re: [webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze  wrote:
> On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
>> Eric Seidel points out that SVG uses multiple inheritance in its DOM
>> interfaces.  However, the situation there is a bit different.
>> Although SVGSVGElement implements SVGLocatable, there aren't any
>> interfaces with methods that return SVGLocatable, which means we don't
>> need to implement toJS(SVGLocatable*).
>
> SVG 2 will use WebIDL. Therefore we also reorganize our inheritance behavior. 
> Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED soon.

Do you anticipate adding properties or functions that return
interfaces like SVGLocatable?

Adam


>> He also points out that Node inherits from EventTarget, which already
>> contains a virtual interfaceName() function similar to that used by
>> Event.  That pushes us further towards using a common DOMInterface
>> base class because introducing Region::interfaceName would mean that
>> Element would see both EventTarget::interfaceName and
>> Region::interfaceName.
>>
>> Adam
>>
>>
>> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
>>> The CSS Regions specification [1] defines a CSSOM interface named
>>> Region, which can be mixed into interfaces for other objets that can
>>> be CSS regions.  That means that Region introduces a form of multiple
>>> inheritance into the DOM.  For example, Element implements Region but
>>> Node does not implement Region.
>>>
>>> There's a patch up for review that implements Region using C++
>>> multiple inheritance [2]:
>>>
>>> - class Element : public ContainerNode {
>>> + class Element : public ContainerNode, public CSSRegion {
>>>
>>> One difficulty in implementing this feature how to determine the
>>> correct JavaScript wrapper return for a given Region object.
>>> Specifically, toJS(Region*) needs to return a JavaScript wrapper for
>>> an Element if the Region pointer actually points to an Element
>>> instance.
>>>
>>> We've faced a similar problem elsewhere in the DOM when implementing
>>> normal single inheritance.  For example, there are many subclass of
>>> Event and toJS(Event*) needs to return a wrapper for the appropriate
>>> subtype.  To solve the same problem, CSSRule has a m_type member
>>> variable and a bevy of isFoo() functions [3].
>>>
>>> A) Should we push back on the folks writing the CSS Regions
>>> specification to avoid using multiple inheritance?  As far as I know,
>>> this is the only instance of multiple inheritance in the platform.
>>> Historically, EventTarget used multiple inheritance, but that's been
>>> fixed in DOM4 [4].
>>>
>>> B) If CSS Regions continues to require multiple inheritance, should we
>>> build another one-off RTTI replacement to implement toJS(Region*), or
>>> should we improve our bindings to implement this aspect of WebIDL more
>>> completely?
>>>
>>> One approach to implementing toJS in a systematic way is to introduce
>>> a base class DOMInterface along these lines:
>>>
>>> class DOMInterface {
>>> public:
>>>virtual const AtomicString& primaryInterfaceName() = 0;
>>> }
>>>
>>> That returns the name of the primary interface (i.e., as defined by
>>> WebIDL [5]).  When implementing toJS, we'd then call
>>> primaryInterfaceName to determine which kind of wrapper to use.
>>>
>>> One downside of this approach is that it introduces a near-universal
>>> base class along the lines of IUnknown [6] or nsISupports [7].  I
>>> don't think any of us want WebKit to grow an implementation of
>>> XPCOM...
>>>
>>> I welcome any thoughts you have on this topic.
>>>
>>> Thanks,
>>> Adam
>>>
>>> [1] http://dev.w3.org/csswg/css3-regions/
>>> [2] https://bugs.webkit.org/show_bug.cgi?id=91076
>>> [3] 
>>> http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
>>> [4] http://www.w3.org/TR/dom/#node
>>> [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
>>> [6] 
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
>>> [7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Dirk Schulze]

On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:

> Eric Seidel points out that SVG uses multiple inheritance in its DOM
> interfaces.  However, the situation there is a bit different.
> Although SVGSVGElement implements SVGLocatable, there aren't any
> interfaces with methods that return SVGLocatable, which means we don't
> need to implement toJS(SVGLocatable*).
SVG 2 will use WebIDL. Therefore we also reorganize our inheritance behavior. 
Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED soon.

Greetings,
Dirk

> 
> He also points out that Node inherits from EventTarget, which already
> contains a virtual interfaceName() function similar to that used by
> Event.  That pushes us further towards using a common DOMInterface
> base class because introducing Region::interfaceName would mean that
> Element would see both EventTarget::interfaceName and
> Region::interfaceName.
> 
> Adam
> 
> 
> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
>> The CSS Regions specification [1] defines a CSSOM interface named
>> Region, which can be mixed into interfaces for other objets that can
>> be CSS regions.  That means that Region introduces a form of multiple
>> inheritance into the DOM.  For example, Element implements Region but
>> Node does not implement Region.
>> 
>> There's a patch up for review that implements Region using C++
>> multiple inheritance [2]:
>> 
>> - class Element : public ContainerNode {
>> + class Element : public ContainerNode, public CSSRegion {
>> 
>> One difficulty in implementing this feature how to determine the
>> correct JavaScript wrapper return for a given Region object.
>> Specifically, toJS(Region*) needs to return a JavaScript wrapper for
>> an Element if the Region pointer actually points to an Element
>> instance.
>> 
>> We've faced a similar problem elsewhere in the DOM when implementing
>> normal single inheritance.  For example, there are many subclass of
>> Event and toJS(Event*) needs to return a wrapper for the appropriate
>> subtype.  To solve the same problem, CSSRule has a m_type member
>> variable and a bevy of isFoo() functions [3].
>> 
>> A) Should we push back on the folks writing the CSS Regions
>> specification to avoid using multiple inheritance?  As far as I know,
>> this is the only instance of multiple inheritance in the platform.
>> Historically, EventTarget used multiple inheritance, but that's been
>> fixed in DOM4 [4].
>> 
>> B) If CSS Regions continues to require multiple inheritance, should we
>> build another one-off RTTI replacement to implement toJS(Region*), or
>> should we improve our bindings to implement this aspect of WebIDL more
>> completely?
>> 
>> One approach to implementing toJS in a systematic way is to introduce
>> a base class DOMInterface along these lines:
>> 
>> class DOMInterface {
>> public:
>>virtual const AtomicString& primaryInterfaceName() = 0;
>> }
>> 
>> That returns the name of the primary interface (i.e., as defined by
>> WebIDL [5]).  When implementing toJS, we'd then call
>> primaryInterfaceName to determine which kind of wrapper to use.
>> 
>> One downside of this approach is that it introduces a near-universal
>> base class along the lines of IUnknown [6] or nsISupports [7].  I
>> don't think any of us want WebKit to grow an implementation of
>> XPCOM...
>> 
>> I welcome any thoughts you have on this topic.
>> 
>> Thanks,
>> Adam
>> 
>> [1] http://dev.w3.org/csswg/css3-regions/
>> [2] https://bugs.webkit.org/show_bug.cgi?id=91076
>> [3] 
>> http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
>> [4] http://www.w3.org/TR/dom/#node
>> [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
>> [6] 
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
>> [7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

According to WebIDL, every platform object has a "primary" interface,
as defined by .
As long as that's the case, DOMInterface::interfaceName() should be
sufficient to figure out which JavaScript wrapper to use.

Adam


On Wed, Jul 25, 2012 at 2:44 PM, Darin Fisher  wrote:
> At least DOMInterface::interfaceName() is no where near as bad as COM's
> QueryInterface.
>
> Provided we don't end up with any diamond inheritance hierarchies, we
> shouldn't need
> something as complicated as QueryInterface.
>
> -Darin
>
>
>
> On Wed, Jul 25, 2012 at 2:33 PM, Adam Barth  wrote:
>>
>> Eric Seidel points out that SVG uses multiple inheritance in its DOM
>> interfaces.  However, the situation there is a bit different.
>> Although SVGSVGElement implements SVGLocatable, there aren't any
>> interfaces with methods that return SVGLocatable, which means we don't
>> need to implement toJS(SVGLocatable*).
>>
>> He also points out that Node inherits from EventTarget, which already
>> contains a virtual interfaceName() function similar to that used by
>> Event.  That pushes us further towards using a common DOMInterface
>> base class because introducing Region::interfaceName would mean that
>> Element would see both EventTarget::interfaceName and
>> Region::interfaceName.
>>
>> Adam
>>
>>
>> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
>> > The CSS Regions specification [1] defines a CSSOM interface named
>> > Region, which can be mixed into interfaces for other objets that can
>> > be CSS regions.  That means that Region introduces a form of multiple
>> > inheritance into the DOM.  For example, Element implements Region but
>> > Node does not implement Region.
>> >
>> > There's a patch up for review that implements Region using C++
>> > multiple inheritance [2]:
>> >
>> > - class Element : public ContainerNode {
>> > + class Element : public ContainerNode, public CSSRegion {
>> >
>> > One difficulty in implementing this feature how to determine the
>> > correct JavaScript wrapper return for a given Region object.
>> > Specifically, toJS(Region*) needs to return a JavaScript wrapper for
>> > an Element if the Region pointer actually points to an Element
>> > instance.
>> >
>> > We've faced a similar problem elsewhere in the DOM when implementing
>> > normal single inheritance.  For example, there are many subclass of
>> > Event and toJS(Event*) needs to return a wrapper for the appropriate
>> > subtype.  To solve the same problem, CSSRule has a m_type member
>> > variable and a bevy of isFoo() functions [3].
>> >
>> > A) Should we push back on the folks writing the CSS Regions
>> > specification to avoid using multiple inheritance?  As far as I know,
>> > this is the only instance of multiple inheritance in the platform.
>> > Historically, EventTarget used multiple inheritance, but that's been
>> > fixed in DOM4 [4].
>> >
>> > B) If CSS Regions continues to require multiple inheritance, should we
>> > build another one-off RTTI replacement to implement toJS(Region*), or
>> > should we improve our bindings to implement this aspect of WebIDL more
>> > completely?
>> >
>> > One approach to implementing toJS in a systematic way is to introduce
>> > a base class DOMInterface along these lines:
>> >
>> > class DOMInterface {
>> > public:
>> > virtual const AtomicString& primaryInterfaceName() = 0;
>> > }
>> >
>> > That returns the name of the primary interface (i.e., as defined by
>> > WebIDL [5]).  When implementing toJS, we'd then call
>> > primaryInterfaceName to determine which kind of wrapper to use.
>> >
>> > One downside of this approach is that it introduces a near-universal
>> > base class along the lines of IUnknown [6] or nsISupports [7].  I
>> > don't think any of us want WebKit to grow an implementation of
>> > XPCOM...
>> >
>> > I welcome any thoughts you have on this topic.
>> >
>> > Thanks,
>> > Adam
>> >
>> > [1] http://dev.w3.org/csswg/css3-regions/
>> > [2] https://bugs.webkit.org/show_bug.cgi?id=91076
>> > [3]
>> > http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
>> > [4] http://www.w3.org/TR/dom/#node
>> > [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
>> > [6]
>> > http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
>> > [7]
>> > https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Darin Fisher]

At least DOMInterface::interfaceName() is no where near as bad as COM's
QueryInterface.

Provided we don't end up with any diamond inheritance hierarchies, we
shouldn't need
something as complicated as QueryInterface.

-Darin



On Wed, Jul 25, 2012 at 2:33 PM, Adam Barth  wrote:

> Eric Seidel points out that SVG uses multiple inheritance in its DOM
> interfaces.  However, the situation there is a bit different.
> Although SVGSVGElement implements SVGLocatable, there aren't any
> interfaces with methods that return SVGLocatable, which means we don't
> need to implement toJS(SVGLocatable*).
>
> He also points out that Node inherits from EventTarget, which already
> contains a virtual interfaceName() function similar to that used by
> Event.  That pushes us further towards using a common DOMInterface
> base class because introducing Region::interfaceName would mean that
> Element would see both EventTarget::interfaceName and
> Region::interfaceName.
>
> Adam
>
>
> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
> > The CSS Regions specification [1] defines a CSSOM interface named
> > Region, which can be mixed into interfaces for other objets that can
> > be CSS regions.  That means that Region introduces a form of multiple
> > inheritance into the DOM.  For example, Element implements Region but
> > Node does not implement Region.
> >
> > There's a patch up for review that implements Region using C++
> > multiple inheritance [2]:
> >
> > - class Element : public ContainerNode {
> > + class Element : public ContainerNode, public CSSRegion {
> >
> > One difficulty in implementing this feature how to determine the
> > correct JavaScript wrapper return for a given Region object.
> > Specifically, toJS(Region*) needs to return a JavaScript wrapper for
> > an Element if the Region pointer actually points to an Element
> > instance.
> >
> > We've faced a similar problem elsewhere in the DOM when implementing
> > normal single inheritance.  For example, there are many subclass of
> > Event and toJS(Event*) needs to return a wrapper for the appropriate
> > subtype.  To solve the same problem, CSSRule has a m_type member
> > variable and a bevy of isFoo() functions [3].
> >
> > A) Should we push back on the folks writing the CSS Regions
> > specification to avoid using multiple inheritance?  As far as I know,
> > this is the only instance of multiple inheritance in the platform.
> > Historically, EventTarget used multiple inheritance, but that's been
> > fixed in DOM4 [4].
> >
> > B) If CSS Regions continues to require multiple inheritance, should we
> > build another one-off RTTI replacement to implement toJS(Region*), or
> > should we improve our bindings to implement this aspect of WebIDL more
> > completely?
> >
> > One approach to implementing toJS in a systematic way is to introduce
> > a base class DOMInterface along these lines:
> >
> > class DOMInterface {
> > public:
> > virtual const AtomicString& primaryInterfaceName() = 0;
> > }
> >
> > That returns the name of the primary interface (i.e., as defined by
> > WebIDL [5]).  When implementing toJS, we'd then call
> > primaryInterfaceName to determine which kind of wrapper to use.
> >
> > One downside of this approach is that it introduces a near-universal
> > base class along the lines of IUnknown [6] or nsISupports [7].  I
> > don't think any of us want WebKit to grow an implementation of
> > XPCOM...
> >
> > I welcome any thoughts you have on this topic.
> >
> > Thanks,
> > Adam
> >
> > [1] http://dev.w3.org/csswg/css3-regions/
> > [2] https://bugs.webkit.org/show_bug.cgi?id=91076
> > [3]
> http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
> > [4] http://www.w3.org/TR/dom/#node
> > [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
> > [6]
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
> > [7]
> https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

Eric Seidel points out that SVG uses multiple inheritance in its DOM
interfaces.  However, the situation there is a bit different.
Although SVGSVGElement implements SVGLocatable, there aren't any
interfaces with methods that return SVGLocatable, which means we don't
need to implement toJS(SVGLocatable*).

He also points out that Node inherits from EventTarget, which already
contains a virtual interfaceName() function similar to that used by
Event.  That pushes us further towards using a common DOMInterface
base class because introducing Region::interfaceName would mean that
Element would see both EventTarget::interfaceName and
Region::interfaceName.

Adam


On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
> The CSS Regions specification [1] defines a CSSOM interface named
> Region, which can be mixed into interfaces for other objets that can
> be CSS regions.  That means that Region introduces a form of multiple
> inheritance into the DOM.  For example, Element implements Region but
> Node does not implement Region.
>
> There's a patch up for review that implements Region using C++
> multiple inheritance [2]:
>
> - class Element : public ContainerNode {
> + class Element : public ContainerNode, public CSSRegion {
>
> One difficulty in implementing this feature how to determine the
> correct JavaScript wrapper return for a given Region object.
> Specifically, toJS(Region*) needs to return a JavaScript wrapper for
> an Element if the Region pointer actually points to an Element
> instance.
>
> We've faced a similar problem elsewhere in the DOM when implementing
> normal single inheritance.  For example, there are many subclass of
> Event and toJS(Event*) needs to return a wrapper for the appropriate
> subtype.  To solve the same problem, CSSRule has a m_type member
> variable and a bevy of isFoo() functions [3].
>
> A) Should we push back on the folks writing the CSS Regions
> specification to avoid using multiple inheritance?  As far as I know,
> this is the only instance of multiple inheritance in the platform.
> Historically, EventTarget used multiple inheritance, but that's been
> fixed in DOM4 [4].
>
> B) If CSS Regions continues to require multiple inheritance, should we
> build another one-off RTTI replacement to implement toJS(Region*), or
> should we improve our bindings to implement this aspect of WebIDL more
> completely?
>
> One approach to implementing toJS in a systematic way is to introduce
> a base class DOMInterface along these lines:
>
> class DOMInterface {
> public:
> virtual const AtomicString& primaryInterfaceName() = 0;
> }
>
> That returns the name of the primary interface (i.e., as defined by
> WebIDL [5]).  When implementing toJS, we'd then call
> primaryInterfaceName to determine which kind of wrapper to use.
>
> One downside of this approach is that it introduces a near-universal
> base class along the lines of IUnknown [6] or nsISupports [7].  I
> don't think any of us want WebKit to grow an implementation of
> XPCOM...
>
> I welcome any thoughts you have on this topic.
>
> Thanks,
> Adam
>
> [1] http://dev.w3.org/csswg/css3-regions/
> [2] https://bugs.webkit.org/show_bug.cgi?id=91076
> [3] 
> http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
> [4] http://www.w3.org/TR/dom/#node
> [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
> [6] 
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
> [7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

The CSS Regions specification [1] defines a CSSOM interface named
Region, which can be mixed into interfaces for other objets that can
be CSS regions.  That means that Region introduces a form of multiple
inheritance into the DOM.  For example, Element implements Region but
Node does not implement Region.

There's a patch up for review that implements Region using C++
multiple inheritance [2]:

- class Element : public ContainerNode {
+ class Element : public ContainerNode, public CSSRegion {

One difficulty in implementing this feature how to determine the
correct JavaScript wrapper return for a given Region object.
Specifically, toJS(Region*) needs to return a JavaScript wrapper for
an Element if the Region pointer actually points to an Element
instance.

We've faced a similar problem elsewhere in the DOM when implementing
normal single inheritance.  For example, there are many subclass of
Event and toJS(Event*) needs to return a wrapper for the appropriate
subtype.  To solve the same problem, CSSRule has a m_type member
variable and a bevy of isFoo() functions [3].

A) Should we push back on the folks writing the CSS Regions
specification to avoid using multiple inheritance?  As far as I know,
this is the only instance of multiple inheritance in the platform.
Historically, EventTarget used multiple inheritance, but that's been
fixed in DOM4 [4].

B) If CSS Regions continues to require multiple inheritance, should we
build another one-off RTTI replacement to implement toJS(Region*), or
should we improve our bindings to implement this aspect of WebIDL more
completely?

One approach to implementing toJS in a systematic way is to introduce
a base class DOMInterface along these lines:

class DOMInterface {
public:
virtual const AtomicString& primaryInterfaceName() = 0;
}

That returns the name of the primary interface (i.e., as defined by
WebIDL [5]).  When implementing toJS, we'd then call
primaryInterfaceName to determine which kind of wrapper to use.

One downside of this approach is that it introduces a near-universal
base class along the lines of IUnknown [6] or nsISupports [7].  I
don't think any of us want WebKit to grow an implementation of
XPCOM...

I welcome any thoughts you have on this topic.

Thanks,
Adam

[1] http://dev.w3.org/csswg/css3-regions/
[2] https://bugs.webkit.org/show_bug.cgi?id=91076
[3] 
http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
[4] http://www.w3.org/TR/dom/#node
[5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
[6] 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
[7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev