Page MenuHomePhabricator

Automatically switch from wikitext to HTML syntax in serializer when attributes were added to elements
Open, MediumPublic

Description

When editing a document that contains:

  • Foo
  • Bar
  • Baz

Adding an attribute to one of the list items in VE doesn't roundtrip (they serialise back to * instead of forcing <ul><li>..</ul>, as it will have to).

Right now VisualEditor never does this, but earlier today I was experimenting with this (the language inspector might need to do this to properly flip the directionality of an individual list item, wrapping the inner content is not an option as then the number would be on the wrong side).

When trying to reproduce this I noticed that it also happens when creating a new document (e.g. there is no existing page, it has no reason to force "*" instead of "<li>" other than that being the preferred default for wikitext).

http://parsoid.wmflabs.org/_html/:

In:
<div dir="ltr">
<ul>
<li>a
<li lang="he" dir="rtl">b
<li>c
</ul>
</div>

Out:
<div dir="ltr">

  • a
  • b
  • c

</div>

The only case where Parsoid kept the attributes is when not editing a document with wikitext, and not creating a new document, but when editing an existing document with "<li>" in wikitext already, it did roundtrip those.


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68800

Details

Reference
bz53568

Related Objects

StatusSubtypeAssignedTask
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
InvalidJdforrester-WMF
ResolvedJdforrester-WMF
ResolvedCatrope
OpenFeatureNone
OpenFeatureNone
OpenNone
DeclinedNone
ResolvedNone
DeclinedKrinkle
ResolvedNone
ResolvedEsanders
Resolved rmoen
Resolved rmoen
ResolvedMooeypoo
Resolved rmoen
ResolvedMooeypoo
ResolvedMooeypoo
Resolvedcscott
Resolvederanroz
ResolvedMooeypoo
ResolvedEsanders
ResolvedNone
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedLtrlg
ResolvedMooeypoo
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedInez
ResolvedMooeypoo
ResolvedJdforrester-WMF
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedJdforrester-WMF
ResolvedMooeypoo
ResolvedMooeypoo
Resolved rmoen
ResolvedMooeypoo
Resolved rmoen
Resolved rmoen
ResolvedAmire80
ResolvedEsanders
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedJdforrester-WMF
ResolvedMooeypoo
ResolvedAmire80
ResolvedAmire80
ResolvedCatrope
ResolvedAmire80
Resolved TrevorParscal
ResolvedEsanders
ResolvedEsanders
ResolvedMooeypoo
OpenNone
Resolvedmatmarex
ResolvedMooeypoo

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:05 AM
bzimport set Reference to bz53568.

Timo indicated on IRC that lists and list items will be first, but other elements will follow. We should try to use this first case to develop the general infrastructure.

We will need to convert an entire list to HTML syntax if an attribute is set on either the list or any list item.

Mixed templated / non-templated list items are discussed in bug 53368. We protect the entire list if any list item's bullets are template-generated. That means that we (thankfully!) won't have to consider that case here.

Arlolra added a project: Parsoid.
Arlolra set Security to None.
ssastry lowered the priority of this task from High to Medium.Feb 3 2015, 5:54 PM

@Esanders, @Catrope, @Jdforrester-WMF, Is this an use case that Parsoid should support in Q3 / Q4?

An option might be to use T230683's <<< .... >>> syntax to handle T242777, and T230658's {{#attr}} to handle this task.

Right now you can't mix "wikitext" and "HTML-ish" syntax in the same list (ie, some items * and some items <li>, which means the serializer needs to go back and convert *all* of the items in the list into html-ish syntax when it finds an item which can't be represented without it (either due to newlines in the content or attributes on the tag). We could make that work, but it would probably require either (a) backtracking and reserializing the list, which could be O(N^2) in the worst case (O(N) nested lists, where the final item in each requires going back and reserializing the list using html-ish syntax), or (b) lookahead in the serializer for problematic content, which again could be O(N^2) if done naively (O(N) nested lists, where each requires O(N) look ahead to the end).