71–78 of 78 posts
I wish HTML and not just JS had supported for consuming templates. That is I wish we could do variants of: 1. Define Template using ... 2. Consume Template using .. With substitution variables/text, this feature could be amazing.
> With substitution variables/text, this feature could be amazing. At which point, are you just re-creating JavaScript?
I wish HTML and not just JS had supported for consuming templates. That is I wish we could do variants of: 1. Define Template using ... 2. Consume Template using .. With substitution variables/text, this feature could be amazing.
Here's what I got: const $template = function(template) { // make copy of template content const root = template.content.cloneNode(true); // create proxy object for accessing named nodes and root const obj = { get $root() { // after template root is called, remove this getter function delete obj.$root; // return root only once return(root); } }; // find all named template nodes and add to proxy object for (const node…
Made a simple gist: https://gist.github.com/vidaj/b27f1140a8ae711c7df2372c4b5cfe... It supports using templates as slot content and updating only the slots you want. Add in some event listeners, and you got basic binding support.
tags are so incredibly useful for keeping your JS clean when you're not able to have something more reactive around for some reason. I've recently used that on an interview project I did ( https://github.com/pretzelhands/ubiquitous-sniffle ) and it surprisingly takes you quite far with very little effort. The only major annoyance is really manually keeping track of the elements in the DOM and .innerText and .innerHTM…
tags are so incredibly useful for keeping your JS clean when you're not able to have something more reactive around for some reason. I've recently used that on an interview project I did ( https://github.com/pretzelhands/ubiquitous-sniffle ) and it surprisingly takes you quite far with very little effort. The only major annoyance is really manually keeping track of the elements in the DOM and .innerText and .innerHTM…
> TypeError: path must be absolute or specify root to res.sendFile
when I try to visit it.
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 th…
I use lit-html for front end projects at work and it's a godsend, truly. Being able to keep one central 'state' object and just re-render a template based on that without having to pull in a whole framework, without having to set up a whole webpack build process, is incredible!
I wish HTML and not just JS had supported for consuming templates. That is I wish we could do variants of: 1. Define Template using ... 2. Consume Template using .. With substitution variables/text, this feature could be amazing.
> With substitution variables/text, this feature could be amazing. At which point, are you just re-creating JavaScript?
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 th…
lit-html is great. I use it for a lot of projects whenever I need some simple tempted HTML. That being said, it seems like the v1 documentation for lit-html [1] has been removed in favor of a single page in the v2 documentation [2]. Is using lit-html standalone not recommended anymore? I really liked using it standalone. [1] https://lit.dev/docs/v1/lit-html/introduction/ [2] https://lit.dev/docs/libraries/standalone-…
The organization of the lit-html and lit-element packages didn't change: they're separate and lit-element depends on lit-html. The only difference is that we added the lit package that rolls them both up and we talk about templating in one place in the docs rather than two (lit-html and lit-element used to have separate sites). We did this because most people used lit-element and the separation was confusing to some and a little bit of rough DX for most.
Earlier quoted context omitted.
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...
display: none hides the content from screen readers, as it is not rendered. aria-hidden is for elements that were rendered but are hidden (it's redundant on elements with a display value of `none`)