Live data from Hacker News

You can make up HTML tags

maurycyz.com

181–190 of 202 posts

Re: You can make up HTML tags

#182
post #91

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

I'm a bit miffed about the dash. I wish it was a colon. Then well established XML could be simply name-spaced in, and then either styled with css and enhanced with JS. I suspect it wouldn't be that difficult to write something for nginx or apahce that simply converted the colon to a hyphen. Oh well, it cannot be 1999 forever.

Re: You can make up HTML tags

#183

Earlier 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

That rule doesn't work in reverse. If there's no dash it could be either.

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

#184
post #82
post #30

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

Flash was fun but it was never built for being responsive and handling desktop and mobile in one app. Everything was basically fixed layout. Adding in that responsiveness would have probably killed the "easy" part.

Re: You can make up HTML tags

#185

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

Nothing wrong with JS. It all depends on whether you have a strong sense of the bounds of the project.

Re: You can make up HTML tags

#186

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

[deleted]

Re: You can make up HTML tags

#187

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

> 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

#188

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

That is a strawman. I never said everyone who uses classes perfectly uses semantic elements.

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

#189

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

I've seen , and it made me want to break things.

Re: You can make up HTML tags

#190
post #55

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

Thanks, that's good to know. In some contexts I don't think a custom element is ever added to the DOM more than once, eg in htmx I am responding with HTML markup which is then injected into the page and then just kept there, possibly 'forever' or at least until it is replaced by some new markup from a new response.
Post reply on HN