Yeah, this was a problem with Parsoid/JS and SQLite as well,
https://www.mediawiki.org/wiki/Topic:Vde0xothlxmwzg2y

https://github.com/fgnass/domino/issues/73

In T255190#6342311, @Esanders wrote:

VE needs to know the difference between inline and block tags to sensibly split and place new content, for example inline content can be inserted into a paragraph (and indeed must be wrapped in a paragraph or some other content branch), but inserting a table into a paragraph should result in the paragraph being split.

400 Bad Request

But even there redlinks is the last pass to run, no?

Redlink processing is the last step though and Parsoid's parserTests pretty much considers all links as known when it's doing redlink processing,
https://github.com/wikimedia/parsoid/blob/master/src/Config/Api/DataAccess.php#L144-L146

See the poster here,
https://en.wikipedia.org/api/rest_v1/page/html/Wikipedia:Extended_image_syntax#Temporal_media_fragments

We duplicate this list in VE, so that would need to be fixed too.

In T254502#6228429, @JTannerWMF wrote:

Please let us know if there is an action for the Editing-team @ssastry

See T149961 where it says,

This is about automatic approval of the edits so they don't have to be queued though. It turns Suggestor into an editing proxy and is a great way to get it banned :)

But in any case, I thought ORES was for edits already on-wiki, is it possible to run proposed edits through it?

$HTML4BlockTags is no more

Wrt HTML4BlockTags use and a general historical philosophy in Parsoid, https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/608968/3/src/Config/WikitextConstants.php#26, @ssastry says,

Ok, done

Should we remove https://www.mediawiki.org/wiki/Help:Cite#Parsoids_Cite_extension_is_changing_how_errors_are_handled_and_error_information_is_encoded_for_clients_to_use. ?

@Krinkle Please bring this to last call whenever possible.

https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/607902 was also part of this

@JTannerWMF Yes, please, we need information. What's the goal in copying the ids and when is it done?

In T245206#6208042, @Arlolra wrote:

VE seems to be duplicating the id when inserting that paragraph,

In T112045#1647399, @ssastry wrote:

This support is now there in the Parsoid Batching API. If all testing goes well, that will be enabled in production next week. So, the only thing left here is support in the non-batching API. It is unclear how easy it is to do it there, and if the batching API becomes the default, it is low priority to do this for the non-batching API use case.

Dangling references are inconsistently supported though. If it's in an image caption, ex. [[File:Test.png|Hi<ref>ho</ref>]], Parsoid will find it with $extApi->processHiddenHTMLInDataAttributes. So maybe this is another case that method should be handling.

We should start by gathering some data on how often these failures occur.

This is because <syntaxhighlight> gets unstripped before doBlockLevels(),
https://github.com/wikimedia/mediawiki/blob/08510de602c239a60d0918bdbf666250d8ac5846/includes/parser/Parser.php#L1651-L1653

There's a bit of an analysis / discussion of what it means for the open / close widths to be null in,
https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/606035/3/src/Wt2Html/PP/Handlers/DisplaySpace.php#13

Update the spec when this is resolved.

Added in https://www.mediawiki.org/w/index.php?title=Specs/HTML/2.1.0&type=revision&diff=3912001&oldid=3735022&diffmode=source

No longer in relevant since Parsoid/PHP makes these calls directly,
https://github.com/wikimedia/parsoid/blob/master/extension/src/Config/DataAccess.php#L343

Re: <video>, the comment there says,

I'm not sure that duplicating the id is working out so well. See T245206#6208042

Continuing from the some of the discussion in https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/604035,

In T255007#6213816, @cscott wrote:

The space after the CSS escape is harmless. For it's own baroque reasons, CSS doesn't have separate escape mechanisms for 2-hex-digit and 4-hex-digit unicode escapes, so instead it collects digits until it sees a non-digit, and if the non-digit is a space then it eats it. https://drafts.csswg.org/css-syntax/#consume-escaped-code-point

In T255007#6210849, @Tgr wrote:

so there seem to be multiple layers of brokenness here

The space is probably necessary to avoid the escaped character combining in any nefarious way.

In T255007#6210849, @Tgr wrote:

Somehow the \a0 (correct CSS escape for a non-breaking space) is turned into \a0 (extra space at the end)

In T255007#6210806, @Tgr wrote:

Why would the sanitizer be invoked for the contents of a TemplateStyles <style> tag though, which is not an attribute and has its own sanitizer?

TemplateStyles seems to be using a nowiki to avoid doBlockLevels processing,
https://github.com/wikimedia/mediawiki-extensions-TemplateStyles/blob/324dcb3d0612e778764ae675fff3491218591a91/includes/TemplateStylesHooks.php#L378-L381

Yeah, this was a result of the changes in T197879

In T251641#6212196, @Krinkle wrote:

<figure> has semantic meaning from the HTML5 spec. <figure-inline> does not. It is a non-standard element with the same default semantics of an inline element as <span>, no different from <mw-xyz>.

If the only benefit for the custom element is that of standardisation, then I think we should shy away from it in our page view output until and unless such a standard has emerged. We can certainly push for that with our W3C membership and contacts at WHATWG, but unless we want to block this RFC on that, I think for this RFC the only point in favour of <figure-inline> is compat for existing Parsoid clients. Would you agree?

In T245206#6207944, @Pols12 wrote:

Yes: to reproduce list2 bug, you must add a new paragraph just before the list (in addition to format first word of one element)

In T245206#6199472, @Pols12 wrote:

Please look at this diff.

Given that we just discussed this in the context of https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/591224

In T222774#6198018, @ssastry wrote:

Btw url is a starting rule, and I don't see any test code for this rule

We probably need unit tests for all the starting rules.

In T251346#6194362, @cscott wrote:

This seems to be crashing Parsoid CI now? @Arlolra has details.

Depending on the resolution here, we might need to mark mw:DisplaySpace as uneditable in the TestRunner.
See https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/602477

The src belongs the mw:Placeholder

See https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/591224/10/src/Wt2Html/PP/Handlers/DisplaySpace.php

See T94509 for context

We used to have one,
https://github.com/wikimedia/parsoid/commit/02b09d887c9c5d8afa3d9c7dae69aede0182f94b
https://github.com/wikimedia/parsoid/blob/master/lib/FromHTML.js

Or maybe it only got fixed in T241906

Probably related to when T94509 was being deployed.

In T251641#6170733, @Krinkle wrote:

Notes from last week:

• What's the expected benefit of a dedicated element? For example, does this enable particular optimisations or something within Parsoid's codebase?

In T106561#1472510, @cscott wrote:

Hm, I can't seem to reproduce this with Parsoid. Could this be VE's fault?

The above patch and https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/256052 remove some support for PST from the grammar. Noting them here in case they need to be restored.

The current string in Parsoid can be found here https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/599115