Talk:Snippets/Horizontal lists

Empty items
User:Edokter, something changed with hlists in the old days the code gave instead of Is there way of bringing the old functionality back? It affects a lot of pages on Commons. --Jarekt (talk) 18:54, 9 November 2015 (UTC)
 * A
 * B
 * C
 * A
 * B
 * C
 * C
 * C
 * Somebody stuck in 2003 recently figured the best way to eliminate empty LI tags was to slap a class on it and the set the display: to none like so...

... which, of course, is superseded by hList's definitions changing LI tags to display: inline and the reason we are getting the "extra dots". What that somebody needs is a divorce from parser/Parsoid love and go with adding the current CSS3 pseudo-tag meant for this kind of stuff instead.
 * I'm sure adding the above to your local .css will rectify the HList issue (and probably a few other list-item related problems too; unless your still using IE8 or lower that is). How to go about getting this across to the stuck-in-their-own-wiki-mentality people is another matter. -- George Orwell III (talk) 00:17, 10 November 2015 (UTC)
 * I've added a fix --Zhuyifei1999 (talk) 11:22, 10 November 2015 (UTC)
 * The problem seems to be fixed on Commons now. Thank you both for looking into it. The problem is related to T49673. Hopefully other people with "stuck-in-their-own-wiki-mentality" will look here for the solutions, the way we did. --Jarekt (talk) 12:56, 10 November 2015 (UTC)
 * Meh... personally I think it is better to fix the HTML of the pages instead of hiding their problem under the carpet... Keeping them visible would help with that.
 * Anyway, the code added to this page is redundant with the one added to MediaWiki itself. Helder 16:11, 10 November 2015 (UTC)


 * Helder I agree that fixing the HTML would be better, but that will need a rewrite of a template that is used on great number of pages. It will happen (see T89598) but we needed short term solution, before someone starts hacking at it or reverting all the resent changes to affected templates. And this fixes it. --Jarekt (talk) 17:03, 10 November 2015 (UTC)
 * @Jarekt: but this just copies code which is already added to MediaWiki, doesn't it? Why do we need to apply the same CSS two times? Helder 12:06, 12 November 2015 (UTC)


 * Emtpy wikilist items are legal now, so I would not want to add any code that makes horizontal wikilist behaviour inconsistent with regular wikilists.  20:00, 12 November 2015 (UTC)
 * That just breaks a LOT of pages that use hlists through Authority Control templates, but maybe we just need to fix the template so we do not have empty items. --Jarekt (talk) 21:06, 12 November 2015 (UTC)
 * I think we are in agreement for those instances where hList is in play, this new notion of "displaying" empty LI items is undesireable so I'm sure modifying the hList css to detect and nullify the newly added class name (.mw-empty-li) is the next best option. Example...


 * My problem is with the entrenched mentality that such "empty tags" still need messing with (e.g. stripping) by htmlTidy or the parser or Parsoid or wiki Mark-up or whatever mediwiki-ish entity is doing this when advancements such as the :empty pseudo tag now exist that allows a far easier way mange the display (or the non-display) of such tags. More to the point, the less meddling with default HTML specification behavior the better. The normal behavior outside of mediawiki influence is to display empty LI tags so that is what should have been happening without any additionally needed css tweaking or mark-up/tidy/parser/parsoid meddling. If there is a need to stop the default display behavior for empty LI tags, it should be done through .css similar to the above example without the need for another insertion of a class name and corresponding definition is all that I am hoping for someday. -- George Orwell III (talk) 22:48, 12 November 2015 (UTC)