61–70 of 202 posts
If I were going to use them, I'd be inclined to vendor them just to prevent any sort of collision proactively
Earlier quoted context omitted.
I for one am glad that blink is no longer a thing, it's certainly behavior that should require more thought than a simple html element can provide.
I just kind of feel like removing it makes the internet less fun. 90's internet was basically a playground for geeky people to make things purely for fun, with basically no ambitions of making any money; people would host their own terrible web pages. My first real introduction to "programming" (other than making a turtle walk around) was when I was nine years old and bought "Make Your Own Web Page : A Guide for Kids…
Before blogging was called "blogging," people just wrote what they wrote about whatever they wanted to, however they did that (vi? pico? notepad? netscape communicator's HTML editor? MS frontpage? sure!), uploaded it to their ISP under ~/public_html/index.html or similar [or hosted it on their own computer behind a dialup modem], and that was that.
Visibility was gained with web rings (the more specialized, the better -- usually), occasional keyword hits from the primitive search engines that were available, and (with only a little bit of luck necessary) inclusion on Yahoo's manually-curated index.
And that was good enough. There was no ad revenue to chase, nor any expectation that it'd ever be wildly popular. No custom domains, no Wordpress hosts, no money to spend and none expected in return. No CSS, no frames, no client-side busywork like JS or even imagemaps.
Just paragraphical text, a blinking header, blue links that turned purple once clicked, and the occasional image or table. Simple markup, rendered simply.
Finish it up a grainy low-res static gif of a cat (that your friend with a scanner helped make from a 4x6 photograph), some more links to other folks' own simple pages, a little bright green hit counter at the bottom that was included from some far-flung corner of the Internet, a Netscape Now button, and let it ride.
It was definitely a purer time.
Earlier quoted context omitted.
I just evaluated Lit for work and while we didn't go with it, it was very nice. I love the base custom elements API regardless of using Lit or not, turns out that's all you really need to make intricate UIs that feel seamless.
Interesting, I'd be curious to know why you all decided not to go with it if you're open to sharing! Minimally to know if I should look at any other promising frameworks.
My secondary concern with Lit is the additional complexity of using shadow and light DOM together in long lived React/Angular apps. Adding a new paradigm for 75+ contributors to consider has a high bar for acceptance.
I've been doing this for about three or four years. Clever idea, tricky in practice. I don't think I'd recommend this approach broadly. But it works for me. It's definitely possible to take it too far. When most tags in your HTML are custom elements, it creates new readability problems. You can't immediately guess what's inline, what's block, etc. And it's just a lot of overhead for new people to learn. I've arrived…
If you're interested in my approach to custom elements I created: https://github.com/crisdosaygo/good.html
It utlizes custom elements, has autohooks for granular DOM updates, uses native JS template literal syntax for interpolation, imposes ordered component structure:
.
├── package.json
└── src
├── app.js
└── components
├── app-content
│ ├── markup.html
│ ├── script.js
│ └── styles.css
└── app-header
├── markup.html
├── script.js
└── styles.css
```
(defn bench `Feed bench a wrapped func and int, receive int for time in ns` [thunk times] (def start (os/clock :cputime :tuple)) ```
One place I'd love to see this is in a classless html framework. My experience is you always wind up wanting something like cards, and then either writing classes, or having a slightly magic "use these elements in this order" incantation[1].
It would be great to have a minimal framework that peppers in a couple elements of the kind , etc.
[0] I did ask an LLM at one stage too, and it also didn't mention this behaviour exists.
[1] pico css does this.for.example for cards/accordians
... a bunch more HTML ... Just one quibble over this specific example (not the broader concept, which is sound): it probably didn’t have to be div soup to begin with. Something like this may have been more reasonable: ... a bunch more HTML ...
This example also shows a weakness of custom tags compared with using the class attribute. An element can have only single name but may have several classes. And as classes are unordered set, one cannot in general emulate that with several elements as the nesting introduces an order absent in the class list.
https://lit.dev/ That's the premise behind Lit (using the custom elements api)! I've been using it to build out a project recently and it's quite good, simpler to reason about than the current state of React imo. It started at google and now is part of OpenJS.
I just evaluated Lit for work and while we didn't go with it, it was very nice. I love the base custom elements API regardless of using Lit or not, turns out that's all you really need to make intricate UIs that feel seamless.
But there's no real reason to, and it just adds confusion around which elements are semantic -- bringing formatting, functionality, meaning to screen readers and search engines, etc. -- vs which are custom and therefore carry no semantic meaning. If there's no native semantic tag that fits my purposes, I'd much rather stick to a div or span as appropriate, and identify it with one (or more) classes. That's what class…
Doing this for syntax highlighting on https://janetdocs.org/ shrank the homepage's .html from from 51kb to 24kb, or 8kb to 6kb compressed (at the time).
(function(d) {
'abbr article aside audio bdi canvas data datalist details figcaption figure footer header hgroup mark meter nav output progress section summary time video'.replace(/\b\w+/g,function (a){
d.createElement(a);});
})(document);