
HTML5 Custom Elements: Contentious Bits - bpierre
https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits
======
elcritch
Most of the contentious pieces listed in the article are very difficult
problems and correspond to similar problems in language and framework design.
It's awesome this is being done in a community driven fashion. Once these
issues are worked out, it would mean the existence of a very flexible
componentized UI system. In other words it's on par with web assembly in terms
of creating a de facto universal virtual machine, but in this case a universal
graphical system. Yes it'll have warts, and painful spots, but that will be
far outdated that there will be multiple implementations based on a living
specification. E.g. Many of the things that made PC architecture great should
apply here. I think it's already started with the rise of clojurescript,
typescript, and llvm ecmascript emitter.

I've been toying around with the idea of implementing an actor style
computation framework on top of web components. In this area details like
instantiate in order become crucial. It's a bit odd to see the subtree
notification order down on the "other items" list.

Has anyone else made progress in applying an actor computational model on
components? In particular in embedding nomadic data into them via message
passing? A lot of interesting work has been happening in formalizing data
processing in combination with closures [1,2]. I've created some initial
prototypes that turns scxml into functioning state matching with svg rendering
but have stalled a little in specifying the message passing specification. If
anyone's interested I could share the code on github.

[1]:
[http://downloads.typesafe.com/website/presentations/ScalaDay...](http://downloads.typesafe.com/website/presentations/ScalaDaysSF2015/T4_Miller_Function-
Passing.pdf) [2]: [https://medium.com/@ChuckMiskyes/highlights-from-curry-on-
pr...](https://medium.com/@ChuckMiskyes/highlights-from-curry-on-
prague-d9b5923fbfe2#.p3i5ei146)

~~~
spankalee
I had been playing with some very naive data-flow custom elements as part of a
GUI logic in Polymer Designer:

[https://github.com/Polymer/designer/tree/master/elements/log...](https://github.com/Polymer/designer/tree/master/elements/logic)
[https://github.com/Polymer/designer/tree/master/elements/des...](https://github.com/Polymer/designer/tree/master/elements/designer-
logic-editor)

They use Polymer's data-binding for message passing, which is just sugar for
synchronous property setting, so it could have some issues with un-
synchronized related state that would be handled better by a real dataflow
system. I haven't worked on it in quite a while, but if I get back to it I
might work on an event or stream based system.

My motivation here is that using custom elements to both setup and execute the
dataflow graph could be very nice for allowing non-programmers to build UI
logic, especially when paired with a GUI editor.

------
eponeponepon
Seems to me that the HTML 5 living-standard crowd, who were largely opposed to
the XHTML concept, are trying to reinvent a bunch of stuff that XML was
already good at - the "eXtensible" part of it.

Am I completely misunderstanding the situation?

~~~
cfv
Kinda. What this people are talking about are actually extending the DOM with
actual nodes that are programmatically defined. You could never do this kind
of stuff to the DOM with XML+XSLT

~~~
LoSboccacc
can't they just fix the mutator api and allow better low level support for
realtime dom and css interaction?

that would enable defining virtual components in javascript using the standard
dom+css for rendering, instead of locking an area of the page to be a
unstylable code defined render target - we already got canvas for that

~~~
Conlectus
Custom elements / Web components are just normal HTML + CSS, not a different
rendering method. The big difference is that their styling is isolated from
that of the parent DOM.

~~~
wanda
IIRC a Custom Element does not necessitate a shadow DOM. Shadow DOMs are
attached programmatically and the definition of a Web Component is a custom
element with a shadow DOM that allows it to act like a encapsulated, reusable
module. You can have custom elements in Angular without a shadow DOM, hence
the existence of Polymer.

~~~
domenicd
Although you're right in general, this sentence is pretty confused:

> You can have custom elements in Angular without a shadow DOM, hence the
> existence of Polymer.

Angular's "custom elements" are not custom elements at all; they are just
HTMLUnknownElement. (That is, `document.querySelector("x-my-angular-element")
instanceof HTMLUnknownElement` is true.) To program against these unknown
elements, you hook up Angular controllers to them, and the Angular runtime
plumbs notifications between your HTMLUnknownElement and the associated
controller.

What custom elements brings to the table is the ability to actually create an
API for your element that is integrated into the DOM. That is,
`document.querySelector("x-my-actual-custom-element") instanceof MyClass`,
where `MyClass` is something you define. This will allow things like
`myEl.myMethod()`, or `myEl.prop = "value"`, or similar. So you can directly
interface with a custom element's API the same way you interface with HTML
elements (`form.submit()`, `button.click()`, `input.value = "foo"`). You don't
need to use a framework to plumb things around between the actual element, and
some associated controller object hidden in a service location container.

------
spankalee
This big hope here is that the standard can be finalized in time for native
custom elements to be released in Safari 10. Given Safari's slow release
schedule, if they don't make it by 10, the next opportunity will be almost 2
years from now. For IE, Firefox, Chrome and Opera, the situation isn't as
urgent.

~~~
SimeVidas
I haven’t had experience with custom elements, but I think they can be
polyfilled quite well. In that case, Safari 10 shipping this would not be a
major concern.

~~~
spankalee
Polyfilling custom elements right now is ready because only Blink has native
shadow DOM, so the polyfill can use a single mutation observer. With native
shadow DOM, but no native custom elements the polyfill would need a mutation
observer in each shadow root. It would work, but might be slow.

