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

Fixed-Point HTML

habilis.net

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Fixed-Point HTML

#11

Post by hrunt »

chuckhoupt wrote: post #8
pushedx wrote: post #2

Interesting concept. On latest Chrome, the "Check Fixed-Point" button appears to fail.

Thanks [I'm the author]. I tested with Chrome 105 on macOS and it succeeded. Possibly there are OS/plugin/etc issues? Of course, I know there is no guarantee that every browsers innerHTML implementation will produce exactly the same result, but so far I haven't found any variation (Chrome, FF, Safari, Edge).

In Firefox 105.0.1 on MacOS, the button also always fails when I click it.

EDIT: In my case, it appears to be some extra "" text added before the closing tag. I suspect this is introduced by a plugin, probably LastPass.

Re: Fixed-Point HTML

#12

Post by eyelidlessness »

PaulStatezny wrote: post #3

> Why write Fixed-Point HTML? > simply the satisfaction of knowing that you and the browser are in total agreement So, just to clarify: there's no technical benefit, correct?

There actually may be! Depending on what you’re trying to do and what’s inconsistent between your markup and the actual DOM. As noted in my earlier comment, implicit insertion/wrapping of certain elements can cause structural changes which lead to actual code errors or unexpected behavior.

Re: Fixed-Point HTML

#13

Post by tfsh »

Before now I've explicitly reduced the size of my HTML docs (nothing critical/production facing, all passion projects) by removing certain HTML tags (e.g DOCTYPE, closing tags, etc) because I know modern browsers will still render them correctly.

This means there are miniscule savings from a bandwidth serving perspective. I wonder what the trade off is between the HTTP call and document parse/paint.

E.g is it correct to assume the browser will parse/paint the HTML content - fixing incorrectly closed tags on the fly faster than the few milliseconds more it would take to serve fixed-point HTML from the server?

Re: Fixed-Point HTML

#14

Post by nyanpasu64 »

PaulStatezny wrote: post #3

> Why write Fixed-Point HTML? > simply the satisfaction of knowing that you and the browser are in total agreement So, just to clarify: there's no technical benefit, correct?

My favorite example of the technical failings of HTML: https://research.securitum.com/mutation-xss-via-mathml-mutat... is a HTML sanitizing vulnerability that came about because some HTML not only doesn't survive a parse-stringify cycle, but the generated DOM tree does not survive a stringify-parse cycle!

Re: Fixed-Point HTML

#16

Post by skybrian »

Perhaps a more intuitive name would be "round-trip serialization HTML". That is, if you use the browser to parse and print some HTML, it matches the source code.

Or in other words, it's formatted the same way that the browser would do it. So, you use the browser to pretty-print the HTML page, and save the code as the source. It's not hard at all and could be done automatically.

Round-trip tests are often used to check that a deserialization routine outputs data that can be serialized again and no data is lost. It even lets you change the serialization format, provided that you change the parser and printer to match.

I expect that these sort of tests are a lot more useful with fuzzing, though. Finding one example that works mostly just tells you that the browser's HTML printing code isn't completely broken. A single test of that sort is only useful for catching stupid bugs quickly.

Post reply on HN