Live data from Hacker News

Fixed-Point HTML

habilis.net

21–30 of 33 posts

Re: Fixed-Point HTML

#22

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 w…

Annother interesting table one, tr/td/th outside of a will never appear in the DOM. You can make up your own tags and they appear anywhere, but those three are magic and can only exist inside a table.

Forms are also weird, if you leave off the closing tag, an implicit one is included in the DOM. However, if you have inputs further down the page, and technically outside the form, they are included in the submitted form data.

(Don’t ask how I discovered that…)

Re: Fixed-Point HTML

#23

This is called print-read consistency in the Lisp world: an object is printed in such a way that the syntax can be read to produce a similar object, or else is given a deliberately unreadable notation like # , where the # https://stackoverflow.com/questions/70797208/what-is-print-r...

Thanks for this

I've had this notion in my head, of making variables capable of echoing out their own definition when printed for easier time writing tests/debugging

Didn't know it had a name

Re: Fixed-Point HTML

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

It also fails on Firefox 104 on Linux.

Re: Fixed-Point HTML

#26

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

CSS errors are also common here. Especially with the child selector.

Re: Fixed-Point HTML

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

Fails on Safari on iPadOS 15.6.1 too.

edit: another commenter says ad blockers are the culprit.

Re: Fixed-Point HTML

#29

This is called print-read consistency in the Lisp world: an object is printed in such a way that the syntax can be read to produce a similar object, or else is given a deliberately unreadable notation like # , where the # https://stackoverflow.com/questions/70797208/what-is-print-r...

Thanks for this I've had this notion in my head, of making variables capable of echoing out their own definition when printed for easier time writing tests/debugging Didn't know it had a name

In Python, there is a distinction between the text representation of an object, and the result of converting the object to a string. Classes can implement both methods independently, and it's not uncommon to have a repr method that returns something that you could (at least in theory) evaluate as literal Python code. This is very useful for debugging and logging, although not nearly as cool or powerful as the Lisp equivalent.
Post reply on HN