this post was submitted on 04 Jan 2024
113 points (95.9% liked)
Programming
17326 readers
217 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Wait... I just noticed this:
This confuses me; don't you want to make sure you are always generating a syntactically valid document, rather than hoping that the browser will make something suitable up to work around your mistake?
The thing with XHTML is that even a minor problem will make the page refuse to render and display a full page error message instead of any content. Having the browser guess how to handle the malformed HTML isn't ideal, but it's a lot better than showing nothing at all.
As an end result, maybe. But it also means that you get specific feedback on how to properly author it correctly and fix it before pushing it live.
IDK, I lived through that whole era, and I’d attribute it more to the fact that HTML is easy enough to author in any text editor by complete novices. XHTML demands a hell of a lot more knowledge of how XML works, and what is valid (and, more keystrokes). The barrier to entry for XHTML is much, much, higher.
I completely agree with that assessment, but what is weird to me is that most people use frameworks so they don't actually touch any of the markup themselves.
I don’t know if it’s “most people,” but I agree, there is no excuse for frameworks producing sloppy output - that being said, XHTML is a bit more chatty than HTML(5), so there is some minor benefit to not using the less verbose standard.
I feel the idea was that anyone should be able to make a webpage by just copy pasting snippits and to help with that html and Javascript will attempt to continue as best as it can, even if there are glaring issues.
That approach makes a lot of sense for amateur web sites, but less sense for professional web sites.
Oh yes, Front-end developers suffer this decision daily. Luckily there things like Typescript to ease the pain.
well, no. because broken html can still function sometimes. but most importantly most of html is not even "broken", just not "adhering to the complete standards".
html is just formatting around the content. even completely devoid of html you can still see things. we're not writing latex here and no one cares things are a little fucky.
as far as generated html go, you're more likely to break it further if you fuck with it anyways.
Sure, but shouldn't you want your generated markup to adhere to the complete standards so that you know it will be interpreted correctly, rather than hoping that the browser will make the correct guess about what you really meant?
I mean yeah it would be nice but software isn't perfect and validating html is not a sexy feature.
That's too sensible for the web. It almost makes sense, and there's no fun compatibility problems to revel in!