3 ms·

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 st

by 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.

by 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.