3 ms·

The custom element specification (section 4.13) deals mostly with the registration and usage details, but the general extensibility section earlier on covers th

by d_k_f 3y ago

The custom element specification (section 4.13) deals mostly with the registration and usage details, but the general extensibility section earlier on covers the basic use case: https://html.spec.whatwg.org/multipage/infrastructure.html#extensibility-2 https://html.spec.whatwg.org/multipage/infrastructure.html#e... "User agents must treat elements and attributes that they do not understand as semantically neutral; leaving them in the DOM (for DOM processors), and styling them according to CSS (for CSS processors), but not inferring any meaning from them."

troupo 3y ago
Yes. It means they are not "custom elements". They are basically divs.
- xigoi 3y ago
  Yes, they are basically divs, but with a semantic name. Which is exactly what we wanted to achieve.
  - troupo 3y ago
    It's quite literally not what we were trying to achieve.
    - xigoi 3y ago
      How else would you want custom elements to work?
      - troupo 3y ago
        What we're discussing are not custom elements. If you rename a div into <some-other-name>, it doesn't make that a custom element. Very quite literally in the very literal sense of the word the only way to create actual custom elements is through javascript. There's no other way. A sibling comment posted this link: https://codepen.io/dkoch-org/pen/yLwPVYG https://codepen.io/dkoch-org/pen/yLwPVYG. And this is not custom elements. These are "elements unknown to the browser which will be treated in a neutral way making them indistinguishable from divs/spans". In the context of "preventing div/span soup" this does absolutely nothing. It's the same soup, just with longer names.
        globular-toast 3y ago
        Defining them in js doesn't "do anything" either. I think the dispute here boils down to why you would prefer longer names over div/span everywhere. It doesn't make any difference to users, but can make it a lot easier for developers. That's the main reason to do it for me.
- joquarky 3y ago
  More like span, since the default is inline
  - troupo 3y ago
    Ah. For some reason I misremembered that the default is block.

by d_k_f 3y ago

troupo 3y ago

Yes. It means they are not "custom elements". They are basically divs.

xigoi 3y ago
Yes, they are basically divs, but with a semantic name. Which is exactly what we wanted to achieve.
- troupo 3y ago
  It's quite literally not what we were trying to achieve.
  - xigoi 3y ago
    How else would you want custom elements to work?
    - troupo 3y ago
      What we're discussing are not custom elements. If you rename a div into <some-other-name>, it doesn't make that a custom element. Very quite literally in the very literal sense of the word the only way to create actual custom elements is through javascript. There's no other way. A sibling comment posted this link: https://codepen.io/dkoch-org/pen/yLwPVYG https://codepen.io/dkoch-org/pen/yLwPVYG. And this is not custom elements. These are "elements unknown to the browser which will be treated in a neutral way making them indistinguishable from divs/spans". In the context of "preventing div/span soup" this does absolutely nothing. It's the same soup, just with longer names.
      - globular-toast 3y ago
        Defining them in js doesn't "do anything" either. I think the dispute here boils down to why you would prefer longer names over div/span everywhere. It doesn't make any difference to users, but can make it a lot easier for developers. That's the main reason to do it for me.
joquarky 3y ago
More like span, since the default is inline
- troupo 3y ago
  Ah. For some reason I misremembered that the default is block.