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

Overlapping markup

en.wikipedia.org

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Overlapping markup

#31

Post by lioeters »

thomascgalvin wrote: post #27
lioeters wrote: post #25

Earlier quoted context omitted.

One way to solve this could be to provide separate start/end tags without inner content. I, by attorney, bless thee from thy mother, Who prays continually for Richmond's good.

Yeah, that's how the linked article does it, but that's ... icky? It's still a token spanning multiple parents, it's just masquerading as a couple of self-closing tags. Which, of course, is the point of the article, and why this is a difficult problem.

Ah you're right, I should have read the article before commenting, haha. I agree it's not an ideal solution. A disadvantage I imagine is that this syntax pushes the problem onto the parser/consumer to keep track of overlapping regions.

> Milestones are empty elements that mark the beginning and end of a component, typically using the XML ID mechanism to indicate which "begin" element goes with which "end" element.

https://en.wikipedia.org/wiki/Overlapping_markup#Milestones

Re: Overlapping markup

#32

Post by chrismorgan »

samwillis wrote: post #24
chrismorgan wrote: post #21

Earlier quoted context omitted.

This behaviour is defined and explained in the HTML spec with the form element pointer https://html.spec.whatwg.org/multipage/parsing.html#form-ele... >: > The form element pointer points to the last form element that was opened and whose end tag has not yet been seen. It is used to make form controls associate with forms in the face of dramatically bad markup, for historical reasons. And search through the rest of t…

Thanks! My 2 minuets of googling back when I found it didn't surface that and I moved on to the next job. Somehow despite coding html for 25 years I had either not seen the input form attribute or forgotten about it. I suspect the latter!

Steps on finding this from the HTML spec:

① Start at https://html.spec.whatwg.org/multipage/. Or https://html.spec.whatwg.org/ if you prefer, with everything in one page, but that’s a big document. You can also build it all locally yourself if you like. I have.

② “The form element” sounds like a good place to look. https://html.spec.whatwg.org/multipage/forms.html#the-form-e...

③ Look through the DOM interface listed, elements sounds promising. Find the explanation of that IDL attribute below: “The elements IDL attribute must return an HTMLFormControlsCollection rooted at the form element's root, whose filter matches listed elements whose form owner is the form element, with the exception of input elements whose type attribute is in the Image Button state, which must, for historical reasons, be excluded from this particular collection.” Roll your eyes at the bizarre exclusion of , then focus on the term form owner which sounds relevant. That links you to https://html.spec.whatwg.org/multipage/form-control-infrastr....

④ Hmm… null, parser inserted flag, nearest ancestor form element, form attribute. Parser inserted flag sounds relevant (though it’s just a flag, not the actual association link). Also the note “They are also complicated by rules in the HTML parser that, for historical reasons, can result in a form-associated element being associated with a form element that is not its ancestor.”

⑤ This is where having the whole spec open, rather than the multipage version, is handy: you can search the entire document for the term “parser inserted flag” to see where that gets set. You can also guess that it’s going to be in §13.2 Parsing HTML documents (parsing.html). In the end, it’s https://html.spec.whatwg.org/multipage/parsing.html#creating...: “… then associate element with the form element pointed to by the form element pointer and set element's parser inserted flag.” Ah hah!

⑥ You have found the concept in the parser: “form element pointer”. You can then look through where it’s used and quickly see how it’s set on and unset on , thus deliberately handling the missing- case.

You develop a feeling for this kind of thing over time. I didn’t know about the form element pointer (though I feel I should have known about it), but this is a loose description of what I did, though I was able to speed through some of the steps, and I really should have just started by looking at “An end tag whose tag name is "form"”, but at first I thought the claim was bogus.

Re: Overlapping markup

#33

Post by layer8 »

laszlokorte wrote: post #28

Wouldnt one obvious solution be to allow tags from different namespaces to overlap? Maybe it is mentioned in the article but I could not see it: This is some content that is split into two nodes Then in this case two trees with common leaf nodes (4 text nodes) are constructed. From point of ns2-root there are only 3 children (the 2 next nodes outside and the ) and from point fof ns1-root there are two children (elemA…

Your proposal is very similar to SGML’s CONCUR feature mentioned in the Wikipedia article.

Re: Overlapping markup

#34

Post by TreeRingCounter »

thomascgalvin wrote: post #16
TreeRingCounter wrote: post #3

Can someone summarize this? 90% of the content on this page seems like excessively-verbose nonsense.

Many, if not most, computer models represent data as a tree. Some data, however, can't really be represented by a tree, because a "thing" can have multiple parents. The example in the link: Example, with lines marked up: I, by attorney, bless thee from thy mother, Who prays continually for Richmond's good. So much for that.—The silent hours steal on, And flaky darkness breaks within the east. With sentences marked up…

Perfect, thanks.

Re: Overlapping markup

#35

Post by samwillis »

chrismorgan wrote: post #32
samwillis wrote: post #24

Earlier quoted context omitted.

Thanks! My 2 minuets of googling back when I found it didn't surface that and I moved on to the next job. Somehow despite coding html for 25 years I had either not seen the input form attribute or forgotten about it. I suspect the latter!

Steps on finding this from the HTML spec: ① Start at https://html.spec.whatwg.org/multipage/ . Or https://html.spec.whatwg.org/ if you prefer, with everything in one page, but that’s a big document. You can also build it all locally yourself if you like. I have. ② “The form element” sounds like a good place to look. https://html.spec.whatwg.org/multipage/forms.html#the-form-e... ③ Look through the DOM interface liste…

I think I got to point 2, found no reference in the form tag section, and gave up.

But what's fascinating is that it describes the html parser effectively implementing "overlapping markup", as in the Wikipedia article, for this edge case for backwards compatibility.

Re: Overlapping markup

#36

Post by masswerk »

dejj wrote: post #11

Consider Aftertext (draft): it separates the markup from the text entirely. Overlapping markup ranges becomes trivial. https://breckyunits.com/aftertext.html

This is how styled SimpleText read-me files worked in classic Mac OS. A normal file was plain text, but styles could be appended based on indices (much like selection and regions work in modern web APIs).

Re: Overlapping markup

#37

Post by jake-low »

mdciotti wrote: post #12

I've frequently wondered why a hierarchical approach is the norm for text formatting. It seems that many problems could be solved trivially using a text buffer and a list of formatting sequences defined by a starting index and a length. The only place I've seen this in practice is in Telegram's TL Schema [1]. Is this method found anywhere else? Edit to note: there is one obvious advantage to in-band markup such as HT…

There are a number of rich text editors that model documents as a flat array of characters and a separate table of formatting modifiers (each with an offset and length). Medium's text editor is one of them. This post [1] on their engineering blog introduced me to the idea, and I think it's a good starting point for anyone interested in this topic.

ProseMirror (a JavaScript library for building rich text editors) also employs a document model like this. The docs for that project [2] do a good job of explaining how their implementation of this idea works, and what problems it solves.

[1]: https://medium.engineering/why-contenteditable-is-terrible-1...

[2]: https://prosemirror.net/docs/guide/#doc

Re: Overlapping markup

#39

Post by lordnacho »

samwillis wrote: post #7

There are so many odd edge cases in HTML, a good one I found was with forms. If you open a but don't have a closing tag, the browser will close the form block "visually" at the end of the forms immediate parent, as you would expect. All styles are applied to it, or children via selectors, up to that automatically inserted end point. It's how browsers handles most unclosed block tags. However, the forms "functionality…

Why didn't they go the grammar nazi route? Define a spec and if the page doesn't conform, draw an error message.

It's really annoying to have this kind of undefined behaviour that might end up being relied upon.

Re: Overlapping markup

#40

Post by chrismorgan »

samwillis wrote: post #35
chrismorgan wrote: post #32

Earlier quoted context omitted.

Steps on finding this from the HTML spec: ① Start at https://html.spec.whatwg.org/multipage/ . Or https://html.spec.whatwg.org/ if you prefer, with everything in one page, but that’s a big document. You can also build it all locally yourself if you like. I have. ② “The form element” sounds like a good place to look. https://html.spec.whatwg.org/multipage/forms.html#the-form-e... ③ Look through the DOM interface liste…

I think I got to point 2, found no reference in the form tag section, and gave up. But what's fascinating is that it describes the html parser effectively implementing "overlapping markup", as in the Wikipedia article, for this edge case for backwards compatibility.

There’s a lot of messy stuff the HTML syntax supports for historical reasons.

https://html.spec.whatwg.org/multipage/parsing.html#an-intro... covers a variety of fun ones, like how inline formatting elements basically support overlapping markup, and how malformed nesting can be achieved in a few different ways. It’s a useful section of the spec for understanding these things because it explains what’s going on, with links to the precise parser details.

Post reply on HN