Talk:Parsing/Notes/Section Wrapping

The current text seems to assume that DOM sections would be used directly against wikitext section edit APIs. Is this actually needed or desired?

Yes, it does. Why should we introduce different notions of sections, one for reading and one for editing? Do note that for the most common use case where we don't have malformed sections in wikitext, there are no conflicts between the two notions.

In edge cases, current edit sections don't necessarily align with DOM structures. Unless you are willing to break up DOM structures (which has many issues), there will be incompatibilities with the old-style section edit API.

Rather than defining sections around edge case bugs in the current section edit functionality, I think it makes a lot more sense to focus on product needs and user expectations. We can update APIs to respect DOM sections, rather than limiting DOM sections by old API issues.

Understood.

The plan (proposal 1) is indeed to add sections around DOM structures in those cases, but to then disable editability for those with the current save API. When the API changes or when we decide to enforce well-formedness of sections / templates / etc, editability can be enabled.

I had temporarily proposed one such different save API based on source offsets, but then quickly realized that it was a broken idea and removed it.

So, we are on the same page here as far as I can tell. The primary difference from what you have is to add a mapping with the MediaWiki section numbering that ensures that section tags can be used by editing clients and have the guarantee that they won't corrupt the page if they use the section edit API.

We already offer editing of DOM sections in the REST API. The main issue right now is that those "sections" are too fine-grained (all children of body), which is one of the issues the <section> wrapping discussed here should resolve.

The current page text states:

"TODO: "Page is a sequence of sections" doesn't map well to nested section tags? It also doesn't match the "styled Template" mechanism being introduced, where styled templates would deliberately introduce

tags outside of/around a <section>."

This does not seem to be an accurate characterization of the implementation in https://github.com/wikimedia/parsoid-dom-utils. Take a look at the test cases in https://github.com/wikimedia/parsoid-dom-utils/blob/master/test/sections.yaml. Nested section tags as well as

wrappers are supported. Nested sections receive their own nested <section> tags. Div wrappers are wrapped into a section of their own, effectively expanding the scope of the outermost section to wrap the entire

.

C.Scott was responding to your review comment I posted from the gerrit review. He may not have seen the implementation. I'll just edit that out.

Just to confirm that we don't need HTML5 header elements inside section. Is this correct? I just want to make sure that this won't change since it would change the way MCS would parse the HTML to get the section text for the JSON endpoint.

No, there isn't any plan to introduce those.

The "Consistency Options" section talks about an unclosed </div> tag. Isn't that more an unopened </div> tag?

Yup. Thanks. Changed that to unmatched </div> tag.