181–190 of 191 posts
Earlier quoted context omitted.
It shouldn't, and it has never been independent of behavior. The original pipe dream of CSS is not the only separation of concerns that exists: https://twitter.com/simonswiss/status/1664736786671869952
> It shouldn't Changing a theme shouldn't affect behavior (by default).
Earlier quoted context omitted.
It's quite literally not what we were trying to achieve.
How else would you want custom elements to work?
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. 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.
Earlier quoted context omitted.
You... Can't. You literally cannot define a custom element without Javascript.
Like I said: If you want to use the JS-based functionality, you obviously have to register it. Simply using any made-up element in your HTML and styling it via CSS just works ouf the box. See https://codepen.io/dkoch-org/pen/yLwPVYG for a quick example.
Earlier quoted context omitted.
How else would you want custom elements to work?
What we're discussing are not custom elements. If you rename a div into , 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 . And this is not custom elements. These are "elements unknown to the browser wh…
Earlier quoted context omitted.
Like I said: If you want to use the JS-based functionality, you obviously have to register it. Simply using any made-up element in your HTML and styling it via CSS just works ouf the box. See https://codepen.io/dkoch-org/pen/yLwPVYG for a quick example.
How exactly is this different from "the 'div/span-tag soup' as he calls it"? You just renamed some divs, and relied on the standardised behaviour of unknown tags. They are indistinguishable (and just as non-componentised and non-reusable) as the div/span soup.
Earlier quoted context omitted.
I started in 2004. Spent the years of 2007-2012 writing semantic, standards-compliant html (microformats, the works), css and js. Even my first years at booking.com still had that as a concern. Unless this was all a fever dream…
You were a statistical anomaly then. Very very very few people wrote or understood what semantic HTML is. And very few do now. To pretend that there was some time when, unlike now, people wrote semantic HTML en masse is silly.
Everyone I knew in the field was doing the same, Zeldman / ALA was everyone’s hero, UX, accessibility and standards compliance were the highlights of every project, not tooling or frameworks. Not saying everything was perfect but the focus was clearly different.
Earlier quoted context omitted.
> I've never seen anyone create a user interface by writing down the full, semantic markup, and then proceed to create CSS for that Indeed, not in the past 7-8 years. But we used to do it, and the outcome was great - semantic, accessible and machine-readable HTML was the norm. It’s unfortunate that we lost this in the transition to components.
Is that so? From my memory, most people used tables for layouts, or full-out relied on div tags for everything. At some point, HTML5 brought headers and footers and navs and more, and if anything, that made the situation better since. But if the working groups continue to pretend HTML is for text documents instead of web applications, things will never get more semantic.
Earlier quoted context omitted.
JS/HTML web components are the static HTML – ``` {your standard static html} ``` This is just a better way of doing DOM scripting, enhancing without waiting for Document Ready event, and having more freedom when to load the dynamic bits.
> This is just a better way of doing DOM scripting Better than what? > enhancing without waiting for Document Ready event Instead you wait for `connectedCallback` > and having more freedom when to load the dynamic bits. You literally have no freedom over that. Web components are rendered the moment they are added to the page, and you have no control over that. So if something dynamic is happening in your `connectedCa…
you control when the script is loaded right?
connectedCallback happens per component, not in a centralised manner – so you write the logic for what happens in a place where it happens