https://bugzilla.wikimedia.org/show_bug.cgi?id=42803

--- Comment #22 from Gabriel Wicke <[email protected]> ---
(In reply to comment #20)
> Given all the discussion we've had, I think we should implement a quick and
> simple solution for now.  Here is my proposal.
> 
> As far as I can tell, the only place where tag reordering and minimization
> matters is where wikitext I and B tags end up as siblings.  So, just
> targeting
> that situation should give what we want.
> 
> 1. ..</i><i> ..
> 2. ..</b><b> ..
> 3. ..</i></b><i> ..
> 4. ..</b></i><b> ..
> 
> These 4 scenarios boil down to two cases which can be handled fairly easily
> in
> the serializer.

We also need to consider variants where other tags are in the mix. Example:

<i><ins><b>bold-italic</b></ins></i><b>bold</b>

This happens to be a case that is handled by our minimization algorithm. The
main deficiency is that the current recursive implementation can run out of
stack space: https://gerrit.wikimedia.org/r/#/c/60617/

The other issue is that it currently applies to both old and new content. For
incoming content it should only apply to b/i pairs in new/modified content.

I still think the simplest solution is to fix the algorithm to be iterative,
and to enable it only on new / modified incoming content on the way in.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to