Re: Cross Referencing Between Elements

12.06.2014, 05:35, "Boris Zbarsky" <bzbarsky@MIT.EDU>:
> But, and this is important, both SVG paint sources and element() are
> limited to ID lookups. šThese are very fast and more importantly easy to
> keep track of dynamically because browsers already keep track of an
> id-to-element(s) mapping to make things like getElementById() fast.
> There's a memory cost here, but it's a sunk cost. šFurthermore, dynamic
> changes to the value of the id attribute are fairly rare, so all you
> really have to worry about in practice is updating on insert/remove
> operations in the DOM, and only for elements which have an id.
>
> On the other hand, if you allow arbitrary selectors in this sort of
> setup then either you have to use a bunch more memory tracking which
> selectors currently map to which first element (so you can update when
> that changes) or you spend a bunch of time computing which elements are
> matching or no longer matching on DOM mutations. šIt's doable, but it'll
> cost a bunch of memory or CPU time or both.

Thanks for the explanation, Boris.

Possible performance issues are quite clear, but should probably not be a blocker to develop specs for the future given that some specs are developed for years while hardware performance grows constantly according to Moore's law.

For now, we could limit referencing selectors to id's as well as SVG and `element()` are, so that the cross-referencing feature in CSS could be implemented and used right now similar to how `-moz-element()` is already implemented.

Referencing by id would cover at least most basic needs of web developers as for setting a property value of an element based on computed value of a property of another element without sacrificing HTML semantics or using JS for the sake of just visual presentation.

For example:

    #aside {margin-top: computed("#h1", height); }

would set `margin-top` property of the element with `aside` id equal to computed height of the element with `h1` id. (FWIW, this case in particular would be useful to implement the design layout where top boundary of side column [e.g. `ASIDE` element] is at the same imaginary horizontal line as top boundary of text after first-level heading in content column [e.g. `MAIN` element], while side column and text part of content column cannot be placed into a common container after first-level heading when the side column has no semantical relation to content at all, so the heading cannot be taken out from content column and placed before "text + side column" container.)

Thanks.

Received on Thursday, 12 June 2014 16:04:57 UTC