4 ms·
The issue is that if the page is an invalid XHTML - it supposed not render anything at all, which is very undesirable. `<b><p></b></p>` wouldn't stop HTML from
by 0x457 4y ago
The issue is that if the page is an invalid XHTML - it supposed not render anything at all, which is very undesirable.
`<b><p></b></p>` wouldn't stop HTML from rendering, but would stop XHTML. Plus the whole "XML parsers are very unsafe"
- Thiez 4y agoThat issue is considered a feature by many. Don't send out broken web pages. If you don't build your pages using string concatenation you have already eliminated most problems (it's just like SQL, in that respect). XML parsers are not that bad when you disable custom entities, which browsers could easily do.
- 0x457 4y ago> That issue is considered a feature by many. Don't send out broken web pages. If you don't build your pages using string concatenation you have already eliminated most problems (it's just like SQL, in that respect). Yes, but there weren't many tools to "correctly" compose XHTML back then. > XML parsers are not that bad when you disable custom entities, which browsers could easily do. Yes, but it's another thing browser developers need to think of. A lot of CVEs already originate in browser. Even if it's actually safe, people who got burnt by XML, would have bad opinions about XML in mind.
- dub 4y agoThere's nothing stopping developers from doing server-side validation before sending markup to clients. It seems like the majority of developers have never really wanted to make that cost-benefit tradeoff, though. I ran tons of websites declaring an xhtml doctype through https://validator.w3.org/ https://validator.w3.org/ back before HTML5 when xhtml was still trendy: almost all of the "xhtml" websites failed validation.
- codedokode 4y agoNo. This is actually wrong that browser by default doesn't report errors in HTML, CSS or JS - because of this nobody notices them and you cannot understand why the button is not working. Instead, in case of any error a browser should show a big red bar above or below the page. So that the user immediately understands that the page is broken and it makes no sense to try to enter anything. Hiding errors is always a poor choice. Only if you are low paid developer not interested in making a quality product then probably you like browser's behaviour.
- 0x457 4y agoWrong or not, the point is that many websites that declared`xhtml` back in a day failed validation and the majority of developers didn't like it. Browser vendors (WHATWG) didn't like that their browsers showed dead pages (parsing errors) more often than not. Some estimates say that 99% of HTML pages in the wild have at least one error in them. Yes, they errors would probably be fixed if it stopped browsers from rendering the page. Browser plugins also had to speak valid XHTML and be able to modify documents correctly. In-line JavaScript was...funny looking. CSS also behaved differently in XHTML. I, personally, liked XHTML behavior because errors in HTML were essentially Undefined Behavior. That resulted in different results from browser to browser (back when we had multiple browsers and not just Chrome). However, I also like Rust, so maybe it's a fetish? /s We didn't really have good tools back then, and the way HTML was generated wasn't brilliant. Currently, I'm making a website in Yew, and it won't even compile if I don't have tags correctly placed and closed because everything inside `html!` macro gets turned into rust code and then HTML gets built. I think JSX behaves similarly?