Template talk:Hlist/Archive 1

Archive 1

Changing style in wikitable hlist class

Is it possible to change the style parameters of the hlist when it is being used as part of a wikitable? Specifically I want to prevent wrapping within the list items, which is possible with normal hlists by passing "white-space:nowrap" to li_style. I'm just not sure how to do that when using the hlist class of a wikitable. Gamma Metroid (talk) 21:01, 20 March 2014 (UTC)

  • No styling
  • second item
  • third item
  • With |li_style=white-space: nowrap;
  • second item
  • third item
  • With |class=nowrap
  • second item
  • third item
  • With |style=white-space: nowrap;
  • second item
  • third item
  • With |ul_style=white-space: nowrap;
  • second item
  • third item
See second example above. --Redrose64 (talk) 21:53, 20 March 2014 (UTC)
I know how to do that, but I want to know if I can set that parameter in one place and have it work throughout the table without using the hlist template every time, in a table formatted like this:
{| class = "wikitable hlist" style = "width: 90px;"
|-
|
* item1
* longer item
* item3
* item4
|}
which shows
  • item1
  • longer item
  • item3
  • item4
What I'm looking for is a way to tell the table that I want all the hlist content to have the effect of |li_style=white-space: nowrap;. Gamma Metroid (talk) 02:37, 21 March 2014 (UTC)
hlist used to do this by default, but it was removed because applying nowrap to the list items caused unwanted side effects in Internet Explorer. So I would advice against doing that. Your safest bet is to use {{nowrap}} inside list items. Edokter (talk) — 10:44, 21 March 2014 (UTC)

Parameter to set something other than middots between items?

Is there – or would some kind soul with the Lua know-how please add – a parameter to replace the middots between items to something else, e.g.  {{big|→}} ..? Sardanaphalus (talk) 11:32, 14 April 2014 (UTC)
PS The same for {{flatlist}} too..?

The middot styling is produced by the CSS
.hlist dd:after, .hlist li:after {
    content: " · ";
    font-weight: bold;
}
and it is because of the necessity for using the :after pseudo-element and the content: property that it needs to go into a style sheet, rather than as inline styling. Since it can't be inline styling, it also can't be template- or module-configured. --Redrose64 (talk) 12:07, 14 April 2014 (UTC)
(edit conflict) No, it isn't possible, at least not from here. The mid-dots are added by the "hlist" class, which is defined in MediaWiki:Common.css. Without that class, this template would display as a vertical list. Here's a demonstration:

With the hlist class:

<div class="hlist">
*Foo
*Bar
*Baz
</div>
  • Foo
  • Bar
  • Baz

Without the hlist class:

<div>
*Foo
*Bar
*Baz
</div>
  • Foo
  • Bar
  • Baz
Hope this helps. — Mr. Stradivarius ♪ talk ♪ 12:14, 14 April 2014 (UTC)

Understood: the dots are part of the MediaWiki:Common.css fabric, which seems fair enough when something like A  C is exceptional next to the standard and abundant

  • A
  • B
  • C.

Thanks for your responses. Sardanaphalus (talk) 15:50, 20 April 2014 (UTC)

PS Can (or have) the category links at the very bottom of a page be (or have been) separated by dots?

It looks like the display of the categories on the bottom bar could be altered with judicious use of CSS, but I'm not aware of this ever having been attempted. HotCat has done something close, but didn't actually alter the pipes separating the categories. If you want to know more, for example to override the default MediaWiki CSS in your personal CSS page, WP:VPT would be a good place to ask. — Mr. Stradivarius ♪ talk ♪ 16:53, 20 April 2014 (UTC)
@Sardanaphalus: It's not difficult to change the CSS on a personal basis. If you wanted the links in the category box to be separated by the middot character instead of the pipe character, and you are using the MonoBook skin, you would put
#catlinks li:before { content: " · "; }
into Special:MyPage/monobook.css. If you use Vector skin, it can also be done, but is more complicated (let me know if you need that). If you wanted it changed for all users, this can also be done, but needs consensus: MediaWiki talk:Common.css is a good place to start. --Redrose64 (talk) 19:08, 22 April 2014 (UTC)
Monobook and Vector use the same method of separating the catlinks (in fact all skins do) by setting border-left, not a pipe character (but I think it used to). Edokter (talk) — 21:24, 22 April 2014 (UTC)
@Edokter and Sardanaphalus: Aha,   I forgot that I had modified my monobook.css to restore the old styling. I got it from de:Wikipedia:Fragen zur Wikipedia/Archiv/2011/Woche 41#MW118: Kategorienanzeige; so, the full CSS would be
#catlinks li {
  display: inline;
  border-left: none;
  padding: 0;
}
#catlinks li:first-child { padding-left: 0; }
#catlinks li:before { content: " · "; }
#catlinks li:first-child:before { content: ""; }
in Special:MyPage/common.css --Redrose64 (talk) 09:31, 24 April 2014 (UTC)
  • Thanks for all this information – I was wondering whether it had been (or had been proposed to be made) universal, but I'm now sufficiently intrigued to try it for myself anyway. (I'm using MonoBook.) Sardanaphalus (talk) 09:51, 24 April 2014 (UTC)
  • ...just found this at the end of my account's monobook.css:
/* Code (amended) from User:Sigma-Epsilon to replace category 
   category listings' vertical lines with bullets -- edit to use
   bold-middots instead?
   (http://en.wikipedia.org/w/index.php?title=Wikipedia%3AVillage_pump_%28proposals%29&diff=242646783&oldid=242624779)

addOnloadHook( function (){
 var cat_div = document.getElementById('mw-normal-catlinks');
 cat_div.innerHTML = cat_div.innerHTML.replace(/\|/g,'•');
});

*/
...so I'm about to uncomment it and see what happens. Sardanaphalus (talk) 09:56, 24 April 2014 (UTC)
It won't work. That script looks for the (old) pipe characters, which are no longer there. Use the CSS code above instead. Edokter (talk) — 10:00, 24 April 2014 (UTC)
  • Yes – I'm being given an "Unexpected token" error, so will revert to the above. Sardanaphalus (talk) 10:02, 24 April 2014 (UTC)
...Redrose's amended code plus a font-weight:bold; before the content: " · "; seems to do the trick. Looks nice – more consistent with horizontal lists elsewhere – so I'll run with it, at least for now. Thanks. Sardanaphalus (talk) 10:16, 24 April 2014 (UTC)
(edit conflict) @Sardanaphalus: It won't work, for two reasons: (i) it's javascript, which never works when placed in a CSS file such as User:Sardanaphalus/monobook.css; (ii) even if correctly placed in User:Sardanaphalus/monobook.js (or User:Sardanaphalus/common.js), it looks for the pipe character in order to replace it - and as pointed out by Edokter (and verified by myself), the pipes aren't actually there, and haven't been since MediaWiki 1.18 (September 2011). It's also not ideal practice to use javascript when all you need to do is modify existing CSS styling - if the MediaWiki 1.18 changes hadn't occurred, the same effect could have been achieved in one line of CSS (one rule, comprising one selector and one declaration).
If you want to use the '•' character - which is a bullet not a middot - use the same code that I posted at 09:31, 24 April 2014 but alter the declaration in the second-last rule from content: " · "; to content: " • ";. --Redrose64 (talk) 10:19, 24 April 2014 (UTC)
  • Thanks for the confirmation. I tried the bullet, but it looked too prominent – so, as the middot alone was too slight, I've settled on the bold-middot. "Call me Goldilocks", Sardanaphalus (talk) 10:26, 24 April 2014 (UTC)

Rogue padding?

This template seems to've started adding some padding-left to the hlists it creates – is anyone else seeing this..? Sardanaphalus (talk) 21:55, 29 April 2014 (UTC)

possibly related to [1] but you should provide a simple example to be sure (probably best to bring this up at MediaWiki talk:Common.css if it is indeed related to nesting hlist inside of class=plainlist). Frietjes (talk) 22:05, 29 April 2014 (UTC)

Dot (interpunct) size

I've forgotten (or maybe never knew) how to prevent the dots from becoming very small (near-illegible) in contexts such as:

<div style="font-size:90%;">
{{hlist|li_style=font-size:90%; |{{bigger|[[Canaanite languages]]}} ([[Biblical Hebrew|Hebrew]]|[[Phoenician language|Phoenician]]|...... )}}
</div>

A reminder/demonstration would be very welcome. Sardanaphalus (talk) 10:53, 11 June 2014 (UTC)

PS Renaming ul_style, li_style and li_style[N] as liststyle, itemstyle and item[N]style would also be welcome.

By applying a 90% font size when a 90% is already in effect, you're producing 81% which is below the 85% minimum specified at MOS:ACCESS. You're also putting the first two links into the same list item, which again has accessibility issues. If you're OK with using 90% for all list items, it can be done quite simply as
<div class="hlist" style="font-size:90%;">
*[[Canaanite languages]]
**[[Biblical Hebrew|Hebrew]]
**[[Phoenician language|Phoenician]]
**...
</div>
which produces
which is much more accessible. --Redrose64 (talk) 12:04, 11 June 2014 (UTC)

Sublists / no URL output

Does {{hlist}} have a (semantically-compliant) way to produce sublists – or do sublists mean that e.g. {{flatlist}} is required..?

Also:

Markup Renders as
{{hlist |item |[https://en.wikipedia.org/w/index.php?title=Special%3APrefixIndex&prefix=Example&namespace=2&stripprefix=1 User:Example pages] |item |…}}
  • item
  • item

Is the "Renders as" output as intended..?

Regards, Sardanaphalus (talk) 09:50, 25 October 2014 (UTC)

There's an equals sign in the second positional parameter. When that is the case, that parameter and all subsequent params must be explicitly numbered:
Markup Renders as
{{hlist |item |2=[https://en.wikipedia.org/w/index.php?title=Special%3APrefixIndex&prefix=Example&namespace=2&stripprefix=1 User:Example pages] |3=item |4=…}}
It's not a feature of this template, but a characteristic of all templates. --Redrose64 (talk) 11:03, 25 October 2014 (UTC)
or replace each = with {{=}}, which would be tedious in this case. Frietjes (talk) 14:03, 25 October 2014 (UTC)
  • Thank you, both. I thought I must be overlooking something.
    As they're not mentioned, I'm guessing that {{hlist}} doesn't or can't accommodate sublists – at least, not in an official/compliant way – or am I overlooking something again? Sardanaphalus (talk) 20:15, 26 October 2014 (UTC)
{{hlist}} works by making a regular bulleted list from its several parameters, and wrapping that in a <div>...</div> that applies some styling via a class. divs can be nested, and divs can be made to look like inline content, but nesting two divs and giving both of them the appearance of being inline is rather difficult. {{flatlist}} is a lot easier:
Markup Renders as
{{flatlist|
*Item 1
*Item 2
**Subitem 2.1
**Subitem 2.2
*Item 3
}}
  • Item 1
  • Item 2
    • Subitem 2.1
    • Subitem 2.2
  • Item 3
because all you need to do is use a double asterisk for the sublist, the same as you would for a regular bulleted list. --Redrose64 (talk) 20:27, 26 October 2014 (UTC)

(mobile)The documentation examples show the lists as vertical

In the mobile version the examples show the lists as Vertical rather than as Horizontal (use of template markup).SoSivr (talk) 09:54, 19 June 2015 (UTC)

You mean here? They're horizontal for me. Which device and operating system do you have? --Redrose64 (talk) 11:26, 19 June 2015 (UTC)

No initial line break

I would like to create a list like this:

This is a list: entry1 • entry2 • entry3 • entry4

But if I use {{hlist}} I get the following by default:

This is a list:

  • entry1
  • entry2
  • entry3
  • entry4

Is there any way to avoid the initial line break? — Martin (MSGJ · talk) 14:53, 1 April 2016 (UTC)

MSGJ, you could use
This is a list
entry1
entry2
entry3
entry4
which is similar, but not exactly what you are requesting. otherwise, you could left float the text before it,
{{align|left|This is a list: }}{{hlist|entry1|entry2|entry3|entry4}}
This is a list: 
  • entry1
  • entry2
  • entry3
  • entry4
basically, you are fighting the fact that the div container is a block element. there may be another way, but I don't recall at the moment. Frietjes (talk) 16:07, 1 April 2016 (UTC)
I think that the <ul>...</ul> element needs to be given the declaration
display: inline;
because it defaults to block. --Redrose64 (talk) 22:19, 1 April 2016 (UTC)
Yes, the whole thing is a div box at the moment. Pinging the module author to see if there are any other options. Otherwise I could try one of the options suggested by Frietjes — Martin (MSGJ · talk) 08:56, 4 April 2016 (UTC)
You could do it manually:
<div class="hlist inline">This is a list: 
*entry1
*entry2
*entry3
*entry4
</div>
This is a list:
  • entry1
  • entry2
  • entry3
  • entry4
-- [[User:Edokter]] {{talk}} 11:05, 4 April 2016 (UTC)
The module has a |class= parameter for the outer div, so you could also use {{hlist|class=inline|entry1|entry2|entry3|entry4}} (output:
  • entry1
  • entry2
  • entry3
  • entry4
). There is a |style= parameter as well, but |style=display:inline; doesn't seem to work properly. — Mr. Stradivarius ♪ talk ♪ 11:23, 4 April 2016 (UTC)
I don't think {{hlist|class=inline|entry1|entry2|entry3|entry4}} will work like Edokter's manual version because I need to put the "This is a list" inside the list definition. The only problem I have with Edokter's version is that empty entries are not ignored as they are in hlist. In other words
<div class="hlist inline">This is a list: 
*entry1
*entry2
*
</div>
produces an empty bullet:
This is a list:
  • entry1
  • entry2
Stradivarius' method works just as well (must have made a typo when I tried). You don'tneed the "this is a list" inside the lst. As for the empty list items; the current CSS can't detect empty items, but they are marked as empty, so I may want to tinker with that. -- [[User:Edokter]] {{talk}} 15:26, 4 April 2016 (UTC)
Actually, the empty list item is only a problem when it is the last item, and unfortunately, cannot be fixed. -- [[User:Edokter]] {{talk}} 15:51, 4 April 2016 (UTC)
I also tried Stradivarius' method and it didn't work, so it wasn't just you. But now it seems to work. So thanks all, works a treat on Template:ITN talk — Martin (MSGJ · talk) 09:35, 5 April 2016 (UTC)

Compatibility issues with mobile version

This template seems to have some compatibility issues with the mobile version of Wikipedia. The interpuncts between each item are simply gone. Is there any way to fix this? Artoasis (talk) 01:44, 4 August 2017 (UTC)

@Artoasis: Please see Wikipedia:Village pump (technical)#Hlist bullets not shown in mobile. --Redrose64 🌹 (talk) 06:51, 4 August 2017 (UTC)

Spacing after bullet/interpunct in hlist on mobile

Hi. I tried searching the village pump, but it returns so many results for hlist, I can't see if this is a known issue ...

Using the WP mobile interface, the interpuncts look fine, but the lead spacing of 2nd and any subsequent parameters is wonky. (Where + represents the interpunct) it looks like:

Derp +Derpier +Derpiest instead of Derp + Derpier + Derpiest.

I'm genuinely sorry if this is a known issue. But I feel like its only started appearing this way recently (I used hlist not so long ago, and I'm sure I didn't see it then). Prime Lemur (talk) 14:08, 1 January 2019 (UTC)

Hlist end

Maybe this has been like this for a while and I just haven't noticed, but following the last item in an hlist list, there's a hanging interpunct. See this:
  • 1
  • 2
  • 3

StarcheerspeaksnewslostwarsTalk to me 23:20, 24 January 2019 (UTC)

Looks like it's fixed. Thanks. StarcheerspeaksnewslostwarsTalk to me 02:27, 25 January 2019 (UTC)
I think that this is the same issue as Wikipedia talk:WikiProject Templates#Template:Film- and television-related infobox templates. --Redrose64 🌹 (talk) 10:43, 25 January 2019 (UTC)

Indent/Padding

Is there a reason why, on certain platforms, this template seems to add an indent when placed in an infobox? I've never seen it do that before recently; however, looking at earlier talk page topics, I see someone mentioned around six years ago that there was "padding-left" happening. Is this what the user was referring to? It looks very odd and not at all aesthetically pleasing. ~ Iamthecheese44 (talk) 07:31, 3 May 2020 (UTC)

Please give an example of where you see this. At Ealing Broadway station, it's fine; the hlist here follows the label "External links". --Redrose64 🌹 (talk) 18:22, 3 May 2020 (UTC)

hlists for description lists

Is there a template for formatting description lists? Can I repurpose Template:hlist? I do not want to use Template:flatlist or Template:plainlist.

I'mFeistyIncognito | Talk 15:44, 5 August 2020 (UTC)

Try this:
Fish
An animal that spends its entire life under water
Bird
An animal that has feathers
Mammal
An animal that feeds its young with milk
--Redrose64 🌹 (talk) 09:26, 6 August 2020 (UTC)

Proposal: enable inline behavior by default

{{hlist}} currently generates <div>…</div>, which behaves as a block element by default. Thus, to use the template inside text, one has to explicitly specify {{hlist|class=inline|…}}. And yet, the way {{hlist}} is used on Wikipedia does not seem to require block behavior at all. In fact, I struggle to come up with an example where block behaviour would be necessary. Hence, I propose to make {{hlist}} behave as an inline element by default. In the rare case that someone needs the block behavior, he/she will enable it by using {{hlist|style=display:block;|…}}.

There are two ways of implementing this:

  1. Add style=display:inline; to div and ul elements.
  2. Generate <span>…</span> instead of <div>…</div> and add style=display:inline; to the ul element.

I personally prefer the second way, as it is more semantically correct. Of course, the change must be extensively tested with sandbox as {{hlist}} is heavily used. — UnladenSwallow (talk) 21:42, 9 October 2019 (UTC)

Placing a list inside a span is a content model error in HTML and would be accordingly invalid. Izno (talk) 22:52, 3 October 2021 (UTC)

Inline functionality does not work on mobile

Specifying |class=inline, as in the third example, does not appear to work in mobile. Could this be fixed? {{u|Sdkb}}talk 05:59, 8 July 2020 (UTC)

Sdkb, CSS of mobile version is missing the following CSS rule:
.hlist.inline, .hlist.inline dl, .hlist.inline ol, .hlist.inline ul, .hlist dl dl, .hlist dl ol, .hlist dl ul, .hlist ol dl, .hlist ol ol, .hlist ol ul, .hlist ul dl, .hlist ul ol, .hlist ul ul {
    display: inline;
}
. So the tag ul is displayed per its default display: block;. —⁠andrybak (talk) 09:26, 8 July 2020 (UTC)
@Andrybak: I'm not fully sure what that means — should that rule be added for mobile, or is it left out intentionally? {{u|Sdkb}}talk 13:08, 8 July 2020 (UTC)
I don't know how mobile skin works—I assume it does not load MediaWiki:Common.css at all, an relies mostly on MediaWiki's builtin styles. MediaWiki:Minerva.css is small, but it already has a CSS rule related to hlist class. The CSS I quoted starts at line 125 of MediaWiki:Common.css. —⁠andrybak (talk) 10:35, 9 July 2020 (UTC)
Hmm. Well, if anyone else knows how to get this working on mobile, please let us know. {{u|Sdkb}}talk 04:34, 12 July 2020 (UTC)
Sdkb, if you somehow haven't come across the answer to this one by now, mobile loads MediaWiki:Mobile.css, which indeed does not contain anything related to inline hlist. Izno (talk) 22:51, 3 October 2021 (UTC)
Hmm, I forget why I was asking this or if I ever found a solution, but thanks for following up. I'm still not experienced enough to know precisely what the situation is—is there something we need to change to make this template work properly for mobile users? {{u|Sdkb}}talk 23:07, 3 October 2021 (UTC)

Loading .hlist styles in a user script

Thank you @Izno for the heads up!

Am I right in thinking that adding

mw.loader.load( '/w/index.php?title=Template:Hlist/styles.css&action=raw&ctype=text/css', 'text/css' );

in a user script will load it? The RedBurn (ϕ) 18:30, 23 December 2022 (UTC)

I haven't tried but I think that will work. :) I see that User:BrandonXLF/WPBannerNavbar.js adds a <link> for a similar case. cc @BrandonXLF Izno (talk) 18:33, 23 December 2022 (UTC)
Great, thanks! I'll try the link if mw.loader.load doesn't work. The RedBurn (ϕ) 18:40, 23 December 2022 (UTC)