5 ms·

Well, IETF can always publish an HTTP/2.1 with that removed, no?

by nousermane 4y ago

chrsig 4y ago
an HTTP/2.1 doesn't stop HTTP/2 from existing, it just creates another standard.
- samwillis 4y ago
 HTML5 doesn’t stop XHTML from existing, however it’s collectively considered a bad idea and no one uses it. Sometimes specs are proved to be wrong, this is just one of those occasions.
 - chrsig 4y ago
 > however it’s collectively considered a bad idea and no one uses it No one uses it going forward. I'd hate to venture a guess at how many existing sites there are that use xhtml. Browsers are still expected to parse and render them properly.
 - samwillis 4y ago
 True, although in this case no one is using HTTP/2 Push, so removing it is no harm and only makes it easer to maintain browsers.
 - jraph 4y ago
 What's wrong with XHTML 1.0 or 1.1? (assuming you are speaking about this) What significant feature in XHTML is not supported by HTML5? if you are only speaking about the syntax (so your statement includes XHTML5), I don't follow you neither: I don't see what's wrong with the XML version of HTML5.
 - 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. `` wouldn't stop HTML from rendering, but would stop XHTML. Plus the whole "XML parsers are very unsafe"
 - Thiez 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). 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 ago
 There'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 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.
 - vbezhenar 4y ago
 Who said noone uses it? XHTML is awesome.

Well, IETF can always publish an HTTP/2.1 with that removed, no?

chrsig 4y ago

an HTTP/2.1 doesn't stop HTTP/2 from existing, it just creates another standard.

samwillis 4y ago
HTML5 doesn’t stop XHTML from existing, however it’s collectively considered a bad idea and no one uses it. Sometimes specs are proved to be wrong, this is just one of those occasions.
- chrsig 4y ago
 > however it’s collectively considered a bad idea and no one uses it No one uses it going forward. I'd hate to venture a guess at how many existing sites there are that use xhtml. Browsers are still expected to parse and render them properly.
 - samwillis 4y ago
 True, although in this case no one is using HTTP/2 Push, so removing it is no harm and only makes it easer to maintain browsers.
- jraph 4y ago
 What's wrong with XHTML 1.0 or 1.1? (assuming you are speaking about this) What significant feature in XHTML is not supported by HTML5? if you are only speaking about the syntax (so your statement includes XHTML5), I don't follow you neither: I don't see what's wrong with the XML version of HTML5.
 - 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. `` wouldn't stop HTML from rendering, but would stop XHTML. Plus the whole "XML parsers are very unsafe"
 - Thiez 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). 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 ago
 There'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 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.
- vbezhenar 4y ago
 Who said noone uses it? XHTML is awesome.