Basically: xhtml is fast and verifiable?
instead.
21–30 of 33 posts
Basically: xhtml is fast and verifiable?
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…
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…)
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...
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
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).
> 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.
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).
edit: another commenter says ad blockers are the culprit.
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
God I hate that. It just doesn’t make sense. Where is the
closed?