W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [Custom Elements] attributeChanged not sufficient?

From: Ryosuke Niwa <rniwa@apple.com>
Date: Tue, 01 Apr 2014 09:23:43 +0900
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Message-id: <5B40711E-31A5-4A58-9068-607EC50C0285@apple.com>
To: Ondřej Žára <ondrej.zara@firma.seznam.cz>

> On Mar 31, 2014, at 8:20 PM, Ondřej Žára <ondrej.zara@firma.seznam.cz> wrote:
> 
> Hi,
> 
> let me introduce my Custom Element scenario: an interactive map element, powered by one of the well-known JS APIs (such as Google Maps API or so).
> 
> Typically, the markup will be like
> 
> <my-map lat="..." lon="..." zoom="..." controls>
> 
> However, the underlying JS needs to know when this element's rendered size changes; the viewport needs to be filled with new map tiles and other geo data.
> 
> Typically, when using a plain JS API (and not a custom declarative markup), users are used to call a size synchronization routine, shall the map viewport change. This is no longer the case when a Custom Element is introduced (and scripting is replaced by declarative HTML).

I don't think this problem is specific to custom elements. Users can always affect the size of the element with or without custom elements.

> A user may insert a map element anywhere in the page (see http://api4.mapy.cz/ for reference), including a variable-width box in a sidebar or so. This means that the <my-map> element itself cannot determine when its own (rendered) size changes, as the attributeChanged callback only applies to own attributes.

Right.

> Is there some recommended way of dealing with this?

I think the only way to detect this would be constantly querying the size of your custom element, which will be a performance nightmare.

Perhaps we can add asynchronous event that fires whenever the dimension of an element changes? The hardest part of spec'ing such an event will be figuring how often the change will be checked. We can't do it after every DOM modification, every micro task, etc... due to performance constraints.

- R. Niwa
Received on Tuesday, 1 April 2014 00:24:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:23 UTC