Page MenuHomePhabricator

Add tracking category to pages that generate empty <li> elements
Open, MediumPublic


On the path to replacing Tidy ( T89331 ), one of the tasks is to deal with empty-element removal which will no longer be supported. found a way to prevent Tidy from stripping empty-<li> elements which are now being hidden via CSS to preserve existing rendering. However, longer term, it makes sense to start fixing pages and templates to not rely on empty elements being stripped.

Towards this, it seems the accepted practice is to emit tracking categories to pages that need fixup. It should be simple to do this in the core parser.

Event Timeline

ssastry raised the priority of this task from to Medium.
ssastry updated the task description. (Show Details)
ssastry added subscribers: ssastry, tstarling, cscott, Arlolra.

Additional suggestions from the parsing team meeting:

  • we'd like to add additional information, such as: exact position in wikitext for the error.
  • dashboard for reviewing these pages and marking pages fixed or for marking them as not requiring fixes.

These feature suggestions have an overlap with T48705: Parsoid-based wikitext "linting" tool for "buggy" / "deprecated" wikitext usage; keywords: broken wikitext information and T120257: Investigate RESTBase as a possible storage solution for wikitext "errors" and issues that are found by Parsoid.

Izno renamed this task from Add tracking category to pages that generate empty <li> / <tr> elements to Add tracking category to pages that generate empty <li> elements.Aug 30 2018, 2:03 PM
Izno updated the task description. (Show Details)
Izno added a subscriber: Izno.

I think T152806: Wikitext representing an empty <tr> produces technically-invalid output probably reasonably tracks the desire for empty <tr> linting, given the discussion mostly occurred there.