> Let’s start with the fact that do not enabling you to do anything that’s not possible otherwise. In that way, it’s more of a convenience tool really. If you have significant HTML structures that need to be injected at runtime, it might be very cumbersome to do so manually with document.createElement and element.setAttribute. I didn't expect the paragraph to end that way. I would write it: Let’s start with the fact…
I assume content within "display:none" will be read by search engines and viewed in source. Is read by search engines?
Templating in HTML
41–50 of 78 posts
Re: Templating in HTML
#42is great, but some people are surprised that it doesn't include any form of parameterization or expressions. The entire process of cloning a template and updating it with data is left up to the developer - it's pretty low level. That's why my team made the lit-html library, which uses JS tagged template literals to make elements for you, clone them and interpolate data where the JS expressions are, and then update th…
Re: Templating in HTML
#43is great, but some people are surprised that it doesn't include any form of parameterization or expressions. The entire process of cloning a template and updating it with data is left up to the developer - it's pretty low level. That's why my team made the lit-html library, which uses JS tagged template literals to make elements for you, clone them and interpolate data where the JS expressions are, and then update th…
[1] https://lit.dev/docs/v1/lit-html/introduction/ [2] https://lit.dev/docs/libraries/standalone-templates/
Re: Templating in HTML
#44Any reason you’d write this instead of window.HTMLTemplateElement, which is shorter to type and more efficient to evaluate?
Re: Templating in HTML
#45> Let’s start with the fact that do not enabling you to do anything that’s not possible otherwise. In that way, it’s more of a convenience tool really. If you have significant HTML structures that need to be injected at runtime, it might be very cumbersome to do so manually with document.createElement and element.setAttribute. I didn't expect the paragraph to end that way. I would write it: Let’s start with the fact…
I think the main advantages are that you don't have to remember to add "display:none", and that it gives the structure more semantic meaning. If I look at your code and see "display:none", I don't know why you've chosen to hide it. If it's wrapped in a element, I instantly know why it's not being displayed as I now have an idea of how it's going to be used.
Also if you need to use the same HTML elsewhere, just copy the innerHTML of such an element and insert anywhere you want to.
Re: Templating in HTML
#46> Let’s start with the fact that do not enabling you to do anything that’s not possible otherwise. In that way, it’s more of a convenience tool really. If you have significant HTML structures that need to be injected at runtime, it might be very cumbersome to do so manually with document.createElement and element.setAttribute. I didn't expect the paragraph to end that way. I would write it: Let’s start with the fact…
If I recall correctly there are some subtle things you cannot achieve without . inside is not attempted to be loaded because “it presents nothing in rendering” https://html.spec.whatwg.org/multipage/scripting.html#the-te...
Re: Templating in HTML
#47Re: Templating in HTML
#48How does differ from ?
Re: Templating in HTML
#49Earlier quoted context omitted.
I think the main advantages are that you don't have to remember to add "display:none", and that it gives the structure more semantic meaning. If I look at your code and see "display:none", I don't know why you've chosen to hide it. If it's wrapped in a element, I instantly know why it's not being displayed as I now have an idea of how it's going to be used.
Yes but when you see "display:none;" isn't it obvious that the purpose is to make it visible sometime later? Also if you need to use the same HTML elsewhere, just copy the innerHTML of such an element and insert anywhere you want to.
Re: Templating in HTML
#50...but it should. It's shocking to me that we've had the modern paradigm of client-side-rendering frameworks for over a decade now, without so much as an RFC for any kind of native support.
For the sake of render performance, bundle size, removing a need for transpilation, compatibility across frameworks. There are a million reasons this should be happening in the browser at this point. I'm sure it's a complicated standard to come up with (for one: HTML-based vs JS-based rendering), but why does it feel like nobody's even trying?