Page MenuHomePhabricator

<a> / <b> / <i> issues.
Open, LowPublic

Description

Currently <a> tags are being broken by boldface/italics changes. See https://gerrit.wikimedia.org/r/57690 and T46476.

We should fix that, hopefully fixing cases like ''[[Lunar Prospector]]'''s at the same time (see https://gerrit.wikimedia.org/r/57748 ).

See also mediawiki.DOMPostProcessor:minimizeInlineTags, which currently ignores <a> tags. Probably the first task to do is turn this off and see what happens; we think this code isn't doing much right now (see T44803).


Version: unspecified
Severity: normal
See Also:
T55071: about=null entries on <figure> elements (because of dom-fragment reuse)

Details

Reference
bz47326

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:44 AM
bzimport added a project: Parsoid.
bzimport set Reference to bz47326.

A DOM-based solution makes sense, but I doubt that the current minimizeInlineTags helps much as it will only re-shuffle inline tags starting at the same text / content offset. This is not sufficient in cases like the example in bug 42803.

Fortunately, selective serialization mostly hides this issue for most untouched content as the break-up is deterministic. The visual editor tries to give priority to links, so in new content this should also not be an issue.

Somewhat related, but harder to 'fix': bug 47963

[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]

Another test case reported by jackmcbarn:

''<table><tr><td>'''foo'''</td></tr></table>'''

Liuxinyu970226 updated the task description. (Show Details)
Liuxinyu970226 updated the task description. (Show Details)

Parsoid reproduces what the legacy parser does. So, this is a feature request to clean up that behavior.