Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XHTML Club

xhtml.club

Post reply on HN
Print view View original

51–60 of 131 posts

Re: XHTML Club

#51

Post by assimpleaspossi »

jraph wrote: post #32
assimpleaspossi wrote: post #27

Earlier quoted context omitted.

It's not a technical term. Nowhere in the current HTML standard will you find a versioning of HTML. That's why it's now called a "living standard". You will never find a HTML6 or higher. That note you found is to help with any confusion.

> You will never find a HTML6 or higher You might be right, but we don't know yet. Microsoft said that for Windows 10. You might also be right that the current Living Standard specification doesn't really call it HTML5, but you'll find many people writing HTML for a living say HTML5 to refer to it, and telling them that HTML5 doesn't exist doesn't really help and is a bit wrong too if you have a descriptive approach…

Telling them HTML5 does exist does even more harm cause it doesn't exist. Telling them it does exist is entirely wrong and is even a false statement, is misleading and causes confusion.

Re: XHTML Club

#52

Post by chrismorgan »

swiftcoder wrote: post #40
hannob wrote: post #13

I used to create a number of simple web pages in XHTML back in the days when we believed XHTML was the future. Recently, while going through and restructuring some of my old "online stuff", I learned that XHTML really isn't in a state that I'd want to use it any more: * XHTML 1.0 and 1.1 are officially deprecated by the W3C. * XHTML5 exists as a variant of HTML5. However, it's very clear that it's absolutely not a pr…

> If you do a 'view source' in Firefox on a completely valid XHTML 1.0/1.1 page, it'll redline the XML declaration like it's something wrong Is the page actually being served as "application/xhtml+xml"? Most xhtml sites aren't, in which case the browser is indeed interpreting those as invalid declarations in a regular old html document

If it’s served as XML, then view-source instead highlights the doctype line as an error (“Stray doctype.”).

Re: XHTML Club

#53

Post by jraph »

mcny wrote: post #48
jraph wrote: post #32

Earlier quoted context omitted.

> You will never find a HTML6 or higher You might be right, but we don't know yet. Microsoft said that for Windows 10. You might also be right that the current Living Standard specification doesn't really call it HTML5, but you'll find many people writing HTML for a living say HTML5 to refer to it, and telling them that HTML5 doesn't exist doesn't really help and is a bit wrong too if you have a descriptive approach…

I'm still hopeful. The next version of html should be able to do all the http verbs -- get, put, patch, post, delete online, reactively without having to use a form. There has to be a way to figure this out, even if it requires a transition period. The best time to plant a tree was twenty years ago, the second best time is now. These things belong in the core HTML standards, not a js library you need to include in yo…

> that is something individual web browsers can implement on their own?

Yes, they could, but you want a standard that makes them all implement stuff in a compatible way… :-)

Re: XHTML Club

#54

Post by jraph »

I knew this HN submission would ate my Saturday afternoon and replace any other procrastination activity. Thanks, I hate it.

Re: XHTML Club

#55

Post by notnullorvoid »

I highly recommend everyone involved in web development to read at least a small proportion of the horrors that are the HTML parser specification. It will leave you yearning for the return of XHTML.

Or you could also read web proposals where the reason for avoiding the ideal implementation is complication of updating HTML parser rules.

Or attempt to use the web features that are already hindered by the HTML parser (custom element table rows).

Re: XHTML Club

#56

Post by robin_reala »

XHTML survives in ePub. Recently there was a survey to gather industry feedback for a potential addition of an HTML flavour of ePub to be added to the next version of the spec, but it soon became fairly clear that people saw a lot of value in remaining XHTML-only: https://www.w3.org/blog/2026/epub-and-html-survey-results-an...

Re: XHTML Club

#57

Post by chrismorgan »

jraph wrote: post #50
PaulHoule wrote: post #42

Circa '99 a high fraction (50%-ish) of HTML in the field was invalid, so if you were making a new web browser it had to parse invalid HTML the same way as Netscape which was one more reason we didn't get competitive web browsers. HTML 5 specified exactly how "invalid" HTML is parsed so now there is no such thing as invalid HTML. XHTML was one of those things that never quite worked: https://friendlybit.com/html/why-x…

> there is no such thing as invalid HTML There is. There are things that are still considered invalid, like nesting form elements for instance. (this doesn't take away your argument though, and you were focusing on the parsing aspect).

The things that are invalid should all have defined behaviour. For example, a is not allowed to contain two form controls, but is defined as applying to the first such control.

As far as parse errors is concerned, https://html.spec.whatwg.org/multipage/parsing.html#parse-er... says:

> This specification defines the parsing rules for HTML documents, whether they are syntactically correct or not. Certain points in the parsing algorithm are said to be parse errors. The error handling for parse errors is well-defined (that's the processing rules described throughout this specification), but user agents, while parsing an HTML document, may abort the parser at the first parse error that they encounter for which they do not wish to apply the rules described in this specification.

Re: XHTML Club

#58

Post by jraph »

assimpleaspossi wrote: post #51
jraph wrote: post #32

Earlier quoted context omitted.

> You will never find a HTML6 or higher You might be right, but we don't know yet. Microsoft said that for Windows 10. You might also be right that the current Living Standard specification doesn't really call it HTML5, but you'll find many people writing HTML for a living say HTML5 to refer to it, and telling them that HTML5 doesn't exist doesn't really help and is a bit wrong too if you have a descriptive approach…

Telling them HTML5 does exist does even more harm cause it doesn't exist. Telling them it does exist is entirely wrong and is even a false statement, is misleading and causes confusion.

Ok, I'll bite.

Assuming you are right and HTML5 doesn't exist. What would be the actual bad outcomes of the following?

- believing HTML5 exists

- silently choosing to understand what someone mentioning HTML5 obviously meant

Re: XHTML Club

#59

Post by jraph »

al_borland wrote: post #18

I was in college when XHTML was all the rage and everything we wrote had to pass validation. I still get uncomfortable adding breaks without closing them.

Younger but on the same boat. Nothing reasonable, but this just feels unmatched. It itches exactly like an (unclosed parenthesis

Re: XHTML Club

#60

Post by jraph »

chrismorgan wrote: post #57
jraph wrote: post #50

Earlier quoted context omitted.

> there is no such thing as invalid HTML There is. There are things that are still considered invalid, like nesting form elements for instance. (this doesn't take away your argument though, and you were focusing on the parsing aspect).

The things that are invalid should all have defined behaviour. For example, a is not allowed to contain two form controls, but is defined as applying to the first such control. As far as parse errors is concerned, https://html.spec.whatwg.org/multipage/parsing.html#parse-er... says: > This specification defines the parsing rules for HTML documents, whether they are syntactically correct or not. Certain points in the…

> The things that are invalid should all have defined behaviour

100% agree.

And then I guess the philosophical question is "What's invalid when everything is defined?"

Post reply on HN