Hacker News Reader

Comment by rhdunn | Hacker News Reader

The suggestion to move the RSS/Atom feed links to a hidden link element is a horrible one for me and presumably others who want to copy that and paste it into their podcast applications. With that suggestion it adds another layer of indirection an application has to fetch and inspect.

Part of the reason HTML 5/LS was created was to preserve the behaviour of existing sites and malformed markup such as omitting html/head/body tags or closing tags. I bet some of those had the same usage as XSLT on the web.

View on HN

You're right, it's not a great flow! And while many podcast/feed reader applications support pasting the URL of the page containing the <link /> element, that still leaves the problem of advertising that one can even do that, or that there's a feed available in the first place.

> The suggestion to move the RSS/Atom feed links to a hidden link element is a horrible one for me and presumably others who want to copy that and paste it into their podcast applications. With that suggestion it adds another layer of indirection an application has to fetch and inspect.

This has already been the norm for years. Feed auto discovery is decades old at this point.

> Part of the reason HTML 5/LS was created was to preserve the behaviour of existing sites and malformed markup such as omitting html/head/body tags or closing tags.

This is not true. It has always been valid to omit html/head/body tags and the closing tags of several elements. This is a valid HTML 4.01 Strict document, it follows all of the parsing rules of HTML 4.01 correctly, it is not malformed, it parses correctly in every browser, there is no ambiguity, there is no error handling taking place, and there is nothing incorrect at all about it:

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
    <title>Valid</title>
    <p>This is a valid HTML 4.01 Strict document.

The intention behind this is dropping existing behaviour (XSLT support) and that will break at least some websites. I was saying that when they created HTML 5 they went to great lengths to preserve the HTML parsing behaviour, resulting in the complex parsing and tree construction rules. This is because their goal was to preserve compatibility with existing websites.

I could have chosen a better example like quirks mode. My point was that they could have simplified the parser logic and implementation buren by dropping that. But they didn't.

They even went to great lengths to parse existing XML content (SVG, MathML, and XLink) in HTML documents without supporting namespaces.

So dropping XSLT support here is purely because they don't want to put the effort in implementing their own XSLT engine (in a "safer" language if they need to), or to properly support the maintenance of the open source lbraries they rely on. And dropping XSLT goes against why HTML 5/LS was originally created, which was to support all existing HTML and web content no matter what they looked like.

> My point was that they could have simplified the parser logic and implementation buren by dropping that. But they didn't.

You’re right, and I think this is possibly the biggest mistake the HTML5 standards process ever made. They got that one badly wrong. Strict XML-based parsing was the clearly correct solution informed by many years of Postel’s Law constantly fucking the web up with incompatibilities and security vulnerabilities.

> So dropping XSLT support here is purely because they don't want to put the effort in implementing their own XSLT engine

That’s not the whole answer; they think the benefits don’t justify the effort, and I agree with that.

> And dropping XSLT goes against why HTML 5/LS was originally created, which was to support all existing HTML and web content no matter what they looked like.

That wasn’t why HTML5 was created. That makes no sense; you don’t need a new format to preserve the status quo.

Reply on news.ycombinator.com