Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Templating in HTML

kittygiraudel.com

Post reply on HN
Print view View original

31–40 of 78 posts

Re: Templating in HTML

#31

Post by spankalee »

labrador wrote: post #5

> 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…

is special, very different from display: none; and definitely has a few advantages:

- The elements in it are parsed into a different document and are inert until cloned or adopted into the main document. Images don't load, scripts don't run, styles don't apply, etc. This is very important.

- The content model validation is turned off, so a can contain a

- Mutation observers and events are not fired for parsed content.

- The element itself can appear anywhere, including restricted content elements like

- Other HTML processing libraries generally know to ignore , unlike other content just hidden with CSS.

This makes parsing faster and guaranteed to have no side effects, and conveys the correct semantics to the browser and tools.

Re: Templating in HTML

#32

Post by lelandfe »

kitsunesoba wrote: post #16
labrador wrote: post #5

> 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…

Front end web is not my forte, but as I understand display:none; can have unintended (usually negative) interactions with screen readers, which I don't believe is a possibility with HTML templates.

This is not true. I suspect it is a myth, I've heard it for decades now.

WebAIM[0]:

> display:none or visibility: hidden

> The content is removed from the visual flow of the page and is ignored by screen readers

[0] https://webaim.org/techniques/css/invisiblecontent/#techniqu...

Re: Templating in HTML

#33

Post by tomhallett »

spankalee wrote: post #31
labrador wrote: post #5

> 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…

is special, very different from display: none; and definitely has a few advantages: - The elements in it are parsed into a different document and are inert until cloned or adopted into the main document. Images don't load, scripts don't run, styles don't apply, etc. This is very important. - The content model validation is turned off, so a can contain a - Mutation observers and events are not fired for parsed content…

In addition - “template” also conveys correct semantics to the other developers working on the codebase. If I see an html at the bottom with “display: none” it’s very possible that the intended usage is to leave it there and set “display: block”, ie a modal. “display: none” doesn’t convey “clone me”, but “template” does.

Re: Templating in HTML

#34

Post by spankalee »

is 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 the result really, really fast with new data:

      import {render, html} from 'https://unpkg.com/lit?module';

      let count = 0;
      
      function increment() {
        count++;
        renderCount();
      }   
      
      function renderCount() {
        render(html`
          
The count is ${count}

          Increment
        `, document.body);
      }      
      renderCount();
You can try that out here: https://lit.dev/playground/#gist=1eff9baed1251fc60dd7da8b7f9...

We're also working with Apple on a proposal called Template Instantiation which brings interpolations and updates into HTML itself (though the pandemic and things really stalled that work for the moment).

Re: Templating in HTML

#35

Post by spankalee »

apatheticonion wrote: post #15
labrador wrote: post #5

> 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 it's mostly performance as the browser can add performance optimisations for HTML but not unevaluated JavaScript. The alternative is a "display: none" block, but that triggers a calculation of styles, where can never be rendered so it's evaluated (likely in parallel to JS) by the browser without style calculations. The optimisations lose weight if the tag is added programatically later. For it to be maximally…

Adding a tag later is great for perf too because the contents are still inert and fast to clone.

Re: Templating in HTML

#38

Post by spankalee »

goatlover wrote: post #20
verisimilidude wrote: post #9

The tag really shines when used alongside and the Shadow DOM. But I really wish there were an HTML-native way to load from separate files, the same way we do with CSS and JS. Not a show-stopper, but it’d be very nice to have.

> But I really wish there were an HTML-native way to load from separate files Seems like the JS folks blocked this from happening. It's weird to me to think we've arrived at the point where JS considerations have come to dominate for something that was built to be a document sharing platform.

No one blocked it. If you're referring to HTML Imports, the problem with them is that they didn't integrate with JS modules. There's a new HTML modules proposal [1], and with JS import assertions and CSS and JSON modules landing [2], HTML modules are probably not far behind.

[1]: https://github.com/WICG/webcomponents/blob/gh-pages/proposal... [2]: https://web.dev/css-module-scripts/

Re: Templating in HTML

#39

Post by icedchai »

cantSpellSober wrote: post #29
icedchai wrote: post #2

In the jquery days, I would often do this sort of thing with hidden divs.

You weren't doing the same thing, though it may have had the same effect. Template elements aren't part of the "main" DOM.

It had the same effect, yes, which it what I meant. The hidden div was effectively used as a template, by cloning the element and doing some awful manual data binding from JS.

Re: Templating in HTML

#40

Post by sgc »

spankalee wrote: post #31
labrador wrote: post #5

> 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…

is special, very different from display: none; and definitely has a few advantages: - The elements in it are parsed into a different document and are inert until cloned or adopted into the main document. Images don't load, scripts don't run, styles don't apply, etc. This is very important. - The content model validation is turned off, so a can contain a - Mutation observers and events are not fired for parsed content…

You can use templates for simpler items as indicated in the linked article, but it seems like it would be best used for larger datasets. I would usually load those async to avoid blocking the page while they download. Does it provide practical advantages over loading html to a js object via fetch?
Post reply on HN