[webcomponents]: When <element> is having a bad time

Hello WebApp... okay, I give up on funny suffixes.

I recently discovered that the spec [1] has a glaring ordering bug
[2], where an <element> is ignored if the prototype it extends hasn't
been registered yet. If all of our <elements> were always neatly lined
up in one place, that wouldn't be an issue, but with HTML Imports, and
the ideals of easily-shareable libraries, ensuring a specific order of
elements or face element drop-outs sounds too harsh.

Soo... what should we do?

We could try to collect as many declarations as we can, holding off
registration until we absolutely have to. Then, we reconcile all
dependencies, and successively register those elements whose
dependencies are registered.

The problem is that determining that "absolutely have to" point could
be nearly impossible. It's definitely not the microtask checkpoint.
Since every <element> could have a nested <script>, we will
effectively be back to currently specified behavior.

We could stay draconian about the order. I worry that this will simply
encourage developers to abandon <element> declarative syntax
altogether.

We could invent a time machine, travel forward, and torture the
solution out of future us. That seems like the easiest thing to do.

Ultimately, the challenge we're facing can be summed up as: we're
trying to build a prototype chain out of an arbitrary quantity of
arbitrary ordered chunks of markup and script. Over-constrained
problem? You betcha.

What do you think? Any great ideas?

[1]: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html
[2]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22833

:DG<

Received on Monday, 29 July 2013 22:55:44 UTC