[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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120726/03fcad46/attachment.html>