3 ms·
No. 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
by codedokode 4y ago
No. 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?