Ask HN: What's your biggest issue with HTML?

4 points by icipiracy 3 years ago | 14 comments

HTML is over 29 years old today. You must have used it in many projects during your career.

Perhaps the first time was modifying MySpace or some 90s/2000s social media site.

It's used for laying out pages, adding buttons or building whole UIs. Safari, Chrome, Firefox, Edge, Opera all implement some latest standard of HTML.

What's your biggest issue with HTML today in 2022? What's the one big thing you would change? Which of your needs are not being met with HTML as it is today?

johncoltrane 3 years ago |

HTML is not fit for some of what we currently do with it. Its print roots are obvious and _relatively_ well adapted for structuring editorial content. There are still many maddening issues when you come from a print background but it is not always clear if they are on the spec author or on the implementor: bad justifying and hyphenation, vertical displacement caused by sup and sub, etc.

But the big issue is all the UI stuff that goes around that editorial content, that we have to reinvent all the time or use piles of third-party stuff for. HTML has no tabs, no cards, no popins, no mega menus, no button groups, no steppers, etc.

We shouldn't use that "platform" to build applications.

icipiracy 3 years ago | |

It does feel like 'hacking' quite often to get special UIs done in HTML.

What do you think is a better platform for the web?

That meets similar requirements: - fast to deploy/load cross platform - accessible to build with

johncoltrane 3 years ago | | |

There is no serious alternative for the purely editorial stuff but still lots of room for improvement.

For the application-like stuff… there was some good and some bad in Java applets, Flex, and Silverlight but none of that had a barrier as low as HTML/CSS/JS.

I think the way forward is for HTML and the DOM is to adopt ideas from the framework space (like one/two-way binding) and expose more high-level UI elements out of the box.

Just imagine something like:

    <script>
    const myDataTable = new DataTable()
    myDataTable.head = ["Foo", "Bar", "Baz"]
    myDataTable.items = [[1, 2, 3],[4, 5, 6]]
    </script>
    <table binding="myDataTable" class="my-data-table" sortable />

with everything needed built into the platform, and no hard need for any third-party framework.

solardev 3 years ago |

...that it still exists.

God, I wish we just had a better language for the Web altogether. Something with sane UI primitives that automatically translate into platform API calls (i.e. you say <button>, the OS renders a button based on its own UI guidelines).

Some days I'm still nostalgic for XML + XSLT, which is like a super strict but super powerful alternative to HTML + CSS. You define the structure however you like, using a schema of your choosing, and then use XSLT to define the output, transformations, and styling. Instead, we get kludges like React trying to shoehorn their own abstractions into a million autogenerated nested <div>s because the DOM is the DOM, and having to build a UI lib on top of that, once per project per company per platform. It sucks!

HTML is a blank piece of paper force-fed into a 90s-style typewriter. Modern UIs are composed out of layers of abstractions that vaguely signal intent. The two are not a good pairing :(

icipiracy 3 years ago | |

Having never used XML + XSLT I can't understand exactly what that means.

Do you imagine a better version of HTML to be more like that? Or perhaps like SwiftUI? If you're familiar with that.

legrande 3 years ago |

I don't have any gripe with it other than one thing:

Lack of widgets. We have people writing emoji pickers in JS and placing them in documents, and some of them work horribly on mobile. Then there's the caveat of emoji pickers being already available on mobile and no such JS widget is needed. Then there's 100+ variations of dropdown menus implemented in JS, which all have their own bugs, don't work well on mobile, and are already somewhat natively available on mobile anyway so the JS widget is not needed.

icipiracy 3 years ago | |

This sounds like the issue where a 'datepicker' is not implemented in a standard way across browsers.

Like each browser does it differently, and on top of that renders emojis differently. Is this similar to the issue you're talking about?

tannhaeuser 3 years ago |

That it's locked at where it was over twenty years ago (modulo Ian Hickson's additions ie article, header, section, etc) with everything around it (CSS, JS) having been bloated ad absurdum to make up for HTML's lack of evolution. Yes I know we want to call it separation of presentation from ... whatever, but looks more like an organizational stalemate and self-inflicted problem to me. Today, WHATWG HTML the markup language specifies a vocabulary for casual academic publishing and in prose rather than formal fashion; when in reality it's used for messages and discussion threads, ads of all kinds, CVs, press articles, forms workflows, and countless other kinds of text. To capture such uses was the goal of W3C's XML initiative in 1997 for bringing new vocabularies to the web; but they obsessed over "meta" and enterprise techniques and only brought SVG and MathML. Subsetting XML from SGML was an entirely pointless 20+ years detour, and today SGML still remains the only game in town for formally capturing and evolving HTML. Hickson's/WHATWG's HTML spec OTOH is already fossilized and error-prone to update with new elements.

icipiracy 3 years ago | |

That the whole stack is bloated to support various use cases, how can that be solved differently?

Would you stick with HTML if you'd write a 'new browser' from scratch?

tannhaeuser 3 years ago | | |

I'd stick with pure JS for web apps, and markup (HTML and evolutions thereof for the content we're actually creating) for documents with basic GUIs such as tabs, menus, and the like.

Akcium 3 years ago |

Some redundancy in tags (<b>, <strong>), forgiveness when it comes to coding (you can type anything, no errors, no problems, every browser decides how to interpret the code)

speedgoose 3 years ago | |

People tried to fix that with xhtml but it was not very popular. Perhaps too difficult and not forgiving enough.

throwaway0asd 3 years ago |

Most of HTMLs problems were solved 20 years ago with things like schemas, namespaces, and conventions for extensions supported in browser. None of this caught on. At the time people wanted sloppy shit because all the value was in business logic written in ASP or Java that wrote static HTML with dynamic content for advertising and e-commerce. The just had to barely work well enough to create an e-commerce conversion and avoid lawsuits. You have the same shitty code now but it’s moved to Angular and React.

When people claim they want HTML improved I stop taking them seriously.

icipiracy 3 years ago | |

So what you're saying is that there's plenty of good things about HTML. Just that no one's really using it?

Coming from a gaming background, the web seems awesome. I can publish my game without gatekeepers like Apple or Steam. But, building the game itself using HTML/JS/WebAssembly has too many limitations.