4 ms·

HTML5 Custom Elements: Contentious Bits

34 points by bpierre 11y ago

eponeponepon 11y ago
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 11y ago
  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
  - gsnedders 11y ago
    Notably, this is far closer to what XBL does in Gecko, and what the abandoned XBL2 was meant to do in a standard fashion. Web Components is strongly influenced by XBL2.
  - LoSboccacc 11y ago
    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 11y ago
      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 11y ago
        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 11y ago
        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 11y ago
  XML does let you define tags via DTDs and schemas, but HTML Custom Elements let you _implement_ new tags, so that they do something. The point isn't really to create new <div> or <span> tags, but new <img>, <a>, <input> and <select> tags, and of course, much more complex ones on top of those.
- paxcoder 11y ago
  What is the counter-argument to XHTML but the proliferation of sloppiness?
spankalee 11y ago
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 11y ago
  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 11y ago
    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.
elcritch 11y ago
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/ScalaDaysSF2015/T4_Miller_Function-Passing.pdf http://downloads.typesafe.com/website/presentations/ScalaDay... [2]: https://medium.com/@ChuckMiskyes/highlights-from-curry-on-prague-d9b5923fbfe2#.p3i5ei146 https://medium.com/@ChuckMiskyes/highlights-from-curry-on-pr...
- spankalee 11y ago
  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/logic https://github.com/Polymer/designer/tree/master/elements/log... https://github.com/Polymer/designer/tree/master/elements/designer-logic-editor https://github.com/Polymer/designer/tree/master/elements/des... 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.

34 points by bpierre 11y ago

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 11y ago
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
- gsnedders 11y ago
  Notably, this is far closer to what XBL does in Gecko, and what the abandoned XBL2 was meant to do in a standard fashion. Web Components is strongly influenced by XBL2.
- LoSboccacc 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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 11y ago
XML does let you define tags via DTDs and schemas, but HTML Custom Elements let you _implement_ new tags, so that they do something. The point isn't really to create new <div> or <span> tags, but new <img>, <a>, <input> and <select> tags, and of course, much more complex ones on top of those.
paxcoder 11y ago
What is the counter-argument to XHTML but the proliferation of sloppiness?

spankalee 11y ago

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 11y ago
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 11y ago
  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.

elcritch 11y ago

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/ScalaDaysSF2015/T4_Miller_Function-Passing.pdf http://downloads.typesafe.com/website/presentations/ScalaDay... [2]: https://medium.com/@ChuckMiskyes/highlights-from-curry-on-prague-d9b5923fbfe2#.p3i5ei146 https://medium.com/@ChuckMiskyes/highlights-from-curry-on-pr...

spankalee 11y ago
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/logic https://github.com/Polymer/designer/tree/master/elements/log... https://github.com/Polymer/designer/tree/master/elements/designer-logic-editor https://github.com/Polymer/designer/tree/master/elements/des... 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.