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

11–20 of 78 posts

Re: Templating in HTML

#11

Post by labrador »

runarberg wrote: post #7
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…

> for example a dialog box The element is now supported by all modern browser. I suggest you use it. It has a lot of niceties over implementing one your self, including capturing the focus, correct announcing to assistive technologies, styling the ::backdrop element, etc.

Thanks for the tip. I should read the spec again so I don't miss these.

Re: Templating in HTML

#12

Post by Stamp01 »

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

Re: Templating in HTML

#15

Post by apatheticonion »

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 efficient; all of the tags must be inlined in your HTML prior to your application loading. You can play around with loading it asynchronously to ensure nothing blocks.

Re: Templating in HTML

#16

Post by kitsunesoba »

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.

Re: Templating in HTML

#17

Post by clairity »

runarberg wrote: post #10
clairity wrote: post #3

Earlier quoted context omitted.

i remember doing stuff like that too, but now it's official! ha. it's exciting to see web standards (finally) taking direction from web developers rather than corporate interests, despite chrome being so prominent. as a random aside, i'm especially hoping forms get more love, like the common behaviors (datetime entry, combobox, validation/feedback, etc.) that every developer has to wrangle with over and over. and it'…

Datetime is mostly there. I think firefox and safari have yet to implement and . As for combobox, and is supported everywhere. However I would like to see the CSSWG focus on better standards for styling these, it is possible now using a lot of vendor-specific hacks, but is really annoying. I’m gonna go ahead though and declare frontend validation (as good as) finished. the constraint validation API is amazing to work…

yah, for datetime, i was mostly thinking about styling the widget via css (and perhaps a bit of configuration via json), with the flexibility that all those datetime components had from the jquery days. month and week are indeed just text fields in firefox (just tested it).

and for validation, i'd like it to be js-less, as it's such an integral part of the form use case. there are recent features that help, like :user-invalid and :focus-within, but it's still far from ideal for default behavior. something as simple as styling labels based on validation state of the input is only possible with the advent of :has(), which is still incomplete/experimental in firefox, but even that's still clunky (there's a combinatorial explosion of possible states to cover, having to consider :disabled, :hover, :required, :focus, etc.).

Re: Templating in HTML

#18

Post by grimgrin »

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.

There’s a way to hide from screen readers too if the OP was so inclined:

https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

Re: Templating in HTML

#19

Post by miohtama »

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…

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

#20

Post by goatlover »

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.

Post reply on HN