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

21–30 of 48 posts

Re: Overlapping markup

#21

Post by chrismorgan »

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…

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 the page for the term to find how it’s implemented—it’s straightforward, just set on a open tag and reset on an (explicit) close tag.

This is somewhat unreliable: browsers support it, but tools using XML pipelines are allowed to ignore it (§13.2.9), and lots of JavaScript code will assume hierarchy rather than using form.elements, and thus not catch such elements, or elements that manually specify a form owner via the form attribute.

Re: Overlapping markup

#22

Post by laszlokorte »

samwillis wrote: post #10
jraph wrote: post #9

Earlier quoted context omitted.

This seems strange, how is that represented in the DOM, which is strictly a tree?

It's not in the DOM, from memory chrome dev tools even shows a closing form tag where it's been inserted. I have no idea how it's implemented internally. Confuse me for a while when debugging a legacy website. It had actually been done intentionally to work around a rather complex architecture.

There exists a "form"-attribute for input elements that can be used to associate input elements outside the form hierarchy to be included in the form submission.

So the semantics of "form field outside the actual form" are available anyway. When parsing a not-closed the browsers just make use of that.

Re: Overlapping markup

#23

Post by ggus »

jraph wrote: post #9
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…

This seems strange, how is that represented in the DOM, which is strictly a tree?

Maybe it leverages the "form" optional attribute that can specify the form the element belongs to.

Re: Overlapping markup

#24

Post by samwillis »

chrismorgan wrote: post #21
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…

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!

Re: Overlapping markup

#25

Post by lioeters »

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…

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.

Re: Overlapping markup

#26

Post by jerf »

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…

"I've frequently wondered why a hierarchical approach is the norm for text formatting."

80/20, if not 90/10, effectiveness. Most people are not trying to do what the Wikipedia article is talking about. About the most complicated thing that people want to do is the moral equivalent of italic bold and italic bold, and you can losslessly convert that to italic bold and italic bold for almost all practical purposes.

It isn't until you're getting very precise about what your tags mean, for tags that intrinsically "cross" hierarchies like that, that you start seeing this issues. And then by the time you've gotten that far, you realize you have all sorts of problems, as the article says.

But a good deal of the answer is that while the stuff mentioned in the Wikipedia article is true and important, it's also fairly specialist.

As for "The only place I've seen this in practice is in Telegram's TL Schema [1]. Is this method found anywhere else?", tag-based formatting is the norm for rich text widgets, which generally can natively represent my first HTML example above in its internal format. Generally if you dig into your favorite language you'll find someone has already implemented this efficiently as a library you can pick up if you want to use the capability directly outside of a text widget. It has its own consequences, as anyone who has ever fought with them may realize, but it's not impossibly difficult to deal with.

It isn't a magic solution to everything either, though. Even if it is what you think you want, a widget able to represent a bold section starting in the middle of a paragraph, then proceeding through the first three rows of a table, then stopping in the middle of a paragraph in the third column of the next row is generally weird. To some extent, people have a certain hierarchiness to their thinking about these matters too, whether it's cause or effect. But that hierarchiness is messy; I think it's fair to say most people wouldn't "mean" that bold to mean something in my table case, we don't necessarily expect tags to proceed through tables like that, but ibib is something that people might intuitively expect to be able to do. It's a fractally messy space both in the computer science and human expectations, and the fractal messiness only gets messier when we try to harmonize those two things.

Re: Overlapping markup

#27

Post by thomascgalvin »

lioeters wrote: post #25
thomascgalvin wrote: post #16

Earlier quoted context omitted.

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…

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.

Re: Overlapping markup

#28

Post by laszlokorte »

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

Then when parsing one could even pre-select which namespaces to parse and skip all other, for example if I am only interested in ns1, ns2 could be skipped during parsing.

Re: Overlapping markup

#29

Post by chrismorgan »

admax88qqq wrote: post #17
FigmentEngine wrote: post #5

Earlier quoted context omitted.

overlapping b and i elements he ll o w or ld contary to the article it can still be represented as a tree, by decomposing the children into their own nodes (so in this case characters become nodes with child nodes expressing what formatting is active, followed by the letter, and then turn of all the active formatting)

No that's just nesting. It's overlapping if the lifetime of a child tag is greater than the lifetime of the parent tag. Example if you have two paragraphs and bold the end of one and the start of the next hello world this is your captain speaking Obviously bold is a poor example as you can just terminate and start a new bold without penalty. But if these were more semantic elements like "sections" and "verses" and "l…

> without penalty

It’s actually fiddlier than you may think. Take “Ta” for an example: in most decent fonts, there will be a kerning pair that tightens those characters, tucking the “a” underneath the beam of the “T” a little. The shaper thus needs to follow the actual fonts being used, for kerning purposes, rather than the markup—but this is still visible at the element level, with getBoundingClientRect().

Take this demo (which depends on your default font having such a kerning pair; if it doesn’t, you may need to find one that does and change the font by inserting or similar after the comma):

  data:text/html,
Ta
Ta
Ta
Ta
Tadocument.querySelectorAll("b").forEach(e=>console.log(e.getBoundingClientRect().width))
This shows five variants of “Ta”, with the last two being Ta and Ta, and prints five numbers to the console, the widths of each element. Numbers one and four (both corresponding to a T) differ if you have a kerning pair such as I describe: for me, the first is 11.7px, and the second 10.73333px (though it overflows that width in its rendering) because of the a that follows it. If you gave bold elements the style `display: inline-block`, it wouldn’t kern the pair and would thus go back to 11.7px.

Most fonts could really use italic-aware kerning (that is, kerning a pair where one glyph is regular and the other italic), but it’s sadly not a thing.

Re: Overlapping markup

#30

Post by captainmuon »

Back in the day when I was in school, and there was a IE monopoly, I wrote a simple HTML parser. Instead of parsing it into a tree, it just recorded the beginning and end position of tags as indicies into the string. I think I did use a stack to match nested tags properly. But overlapping markup was common back then, and IE rendered it "correctly" IIRC. This simple parser was enough to power a scraper (I don't remember what I was scraping. Maybe a competitor's emule link site or something like that :-P) and a crude rich text renderer, which I was very proud of.
Post reply on HN