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

1–10 of 33 posts

Re: Fixed-Point HTML

#5

Post by tomxor »

> the real reason to code in Fixed-Point HTML is simply the satisfaction of knowing that you and the browser are in total agreement about the HTML.

Interesting idea, I've been trying to achieve something similar but in reverse... rather than make my source match the browser, make the browser match my source by making it not ignore spacing.

i.e The basics being `white-space: pre;` on the body element, and fixed width and sized fonts. But I still want a HTML document so i can opt in to html where it matters. My reasons are to A) avoid a pre-processor and build toolchain complexity, stick to nice simple static files, and B) I get something similar to WYSIWYG but as source code. C) I like fixed width fonts and to plain text formatting (reducing decisions is helpful for focus).

Re: Fixed-Point HTML

#8

Post by chuckhoupt »

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).

Re: Fixed-Point HTML

#9

Post by [deleted] »

tomxor wrote: post #5

> the real reason to code in Fixed-Point HTML is simply the satisfaction of knowing that you and the browser are in total agreement about the HTML. Interesting idea, I've been trying to achieve something similar but in reverse... rather than make my source match the browser, make the browser match my source by making it not ignore spacing. i.e The basics being `white-space: pre;` on the body element, and fixed width…

[deleted]

Re: Fixed-Point HTML

#10

Post by eyelidlessness »

I’m surprised to see the highlights don’t include another common detail of the parsing algorithm that often trips people up: table rows and cells (tr/th/td) must be in one of thead/tbody/tfoot. If they’re not, they’re implicitly nested into a tbody. As in:

  
     -->
      
        Column one
        Column two
      
      
        Row one col one
        Row one col two
      
     -->
I’ve frequently seen it cause a variety of issues with VDOM libraries, and even plain DOM libraries with a notion of declarative templates, ranging from hydration mismatch logs (meh) to actual logic errors (corruption of the real DOM when nodes aren’t where they’re expected to be).

Other implied/omitted tags like body can cause similar issues too, but I think that’s become a far less common “mistake” (all of these are totally valid since at least HTML5) in recent years.

Post reply on HN