You can make up HTML tags
181–190 of 202 posts
Re: You can make up HTML tags
#182are NOT unrecognized tags! I blogged about this: https://dashed-html.github.io ◄ = always an HTMLUnknownElement until the WHATWG adds it as new Element. ◄ = (No JS!) UNDEFINED Custom Element , valid HTMLElement, great for layout and styling ◄ Upgraded with the JavaScript Custom Elements API it becomes a DEFINED Custom Element --- ► This is standard behaviour in all browsers. Chrome (2016) Safari (2017) FireFox (2018)…
Re: You can make up HTML tags
#183Earlier quoted context omitted.
Because there are so many native elements to keep track of now. If you see an unfamiliar tag that has a reasonably simple name, you simply don't know if it's native or for formatting. That's confusing. It's taking two categories of things and mixing them so you can't tell them apart.
There's a very clear rule for it: if it contains a dash it's a custom element
So now you've got to try to enforce some practice of using hyphens in all tag names that used to be class names, even if they're a single word that has no place for a hyphen?
It's getting even more confusing now, you see? Not less.
Just use classes. That's what they're there for.
Re: You can make up HTML tags
#184Many years ago, I decided to reinvent the `blink` tag, because the monsters who make browsers removed support for it. I didn't know you could just make up tags, but I figured I'd give it a shot, and with a bit of jquery glue and playing with visibility settings, I was able to fix browsers and bring back the glorious blinking. I was surprised you could just do that; I would have assumed that the types of tags are fina…
Talking about this, I am still sad Flash got removed from the web. Nothing to replace it with to afaik.
Re: You can make up HTML tags
#185Earlier quoted context omitted.
I’ve been getting into SSR with JSX as a template engine using kita. You still get full typescript analysis and composability. It beats any other SSR web templating system I’ve used. I agree the need for everything to be a react app by default has gotten out of control. But I think if you’re a startup with unknown future needs it’s hard to ignore the flexibility and power of something like react. If you know you’re j…
You do the crud app and then they want: just make this to edit inline. You do some Ajax api Call with a tiny js. Then you need more and more. Then you have a mess and you’d be better with react. I still can’t find a project id be better of without react. When I tried without it bite me very quickly.
Re: You can make up HTML tags
#186Earlier quoted context omitted.
Just keep using Flash? It's called Animate now. https://www.adobe.com/products/animate.html
I know, but since there’s not a great way to deploy and share stuff it’s not the same. Yes I know about Ruffle, but I don’t really want to make a retro game that targets an emulator, I want something that’s consistently updated. Also Animates pricing model is bullshit.
Re: You can make up HTML tags
#187Earlier quoted context omitted.
> isn't semantic It's certainly better than calling everything a div. > breaks accessibility features I don't know if I'd call it breakage to just... not use them where they should be used. Of course if a real tag exists that adequately matches the author's intent, that should be preferred over a made-up one.
> It's certainly better than calling everything a div. It's not. For semantic purposes is the same as . So on the surface they are equivalent. But if you are in the habit of using custom elements then you will likely continue to use them even when a more useful element is available so rather than so in practice it is probably worse even if theoretically identical. Basically divs with classes provide no semantic infor…
You could say the same about divs. I’ve seen pages where everything is a div. No paragraphs, no headings, no tables, no lists, just divs.
Re: You can make up HTML tags
#188Earlier quoted context omitted.
> It's certainly better than calling everything a div. It's not. For semantic purposes is the same as . So on the surface they are equivalent. But if you are in the habit of using custom elements then you will likely continue to use them even when a more useful element is available so rather than so in practice it is probably worse even if theoretically identical. Basically divs with classes provide no semantic infor…
> But if you are in the habit of using custom elements then you will likely continue to use them even when a more useful element is available You could say the same about divs. I’ve seen pages where everything is a div. No paragraphs, no headings, no tables, no lists, just divs.
My point is that if you are using you don't have to change your .my-element CSS selector or JS selection code to improve your code to . If you are using it is much more work to change your selectors and now you have two ways of doing things depending on if you are using a native semantic element or a div (either a tag selector or class selector). You have made your styling code depend on your element choice which makes it harder to change.
Re: You can make up HTML tags
#189Earlier quoted context omitted.
> It's certainly better than calling everything a div. It's not. For semantic purposes is the same as . So on the surface they are equivalent. But if you are in the habit of using custom elements then you will likely continue to use them even when a more useful element is available so rather than so in practice it is probably worse even if theoretically identical. Basically divs with classes provide no semantic infor…
> But if you are in the habit of using custom elements then you will likely continue to use them even when a more useful element is available You could say the same about divs. I’ve seen pages where everything is a div. No paragraphs, no headings, no tables, no lists, just divs.
Re: You can make up HTML tags
#190Earlier quoted context omitted.
So, the article doesn't discuss this, but there's actually a really good reason to make up and use custom elements: the browser can hydrate their dynamic behaviour automatically. For example, suppose you have: Expand And you have some JS that handles the expander's behaviour: for (const expander of document.querySelectorAll('.expander')) { const btn = expander.querySelector('button'); btn.addEventListener('click', ()…
Beware that connectedCallback runs _every time_ a custom element is added to the dom. So you should make sure to only add event listeners once by tracking internally if the element was already initialized.