[webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

On Thu, Jul 26, 2012 at 3:45 PM, Alexandru Chiculita <achicu at adobe.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120726/1b4e204b/attachment.html>