Jump to content

Template talk:Hatnote/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

I created Template:dablinktop as a header for disambiguation links on pages that are genuine articles — not disambiguation pages themselves, worthy of the Template:disambig.

— <TALKJNDRLINETALK>     19:51, 22 August 2005 (UTC)

There are already a couple of disambig templates with a canned message, please have a look at Wikipedia:Disambiguation#Templates_for_disambiguation_links. --K. Sperling (talk) 00:41, 10 September 2005 (UTC)

Horizontal rule or no

I have a problem with the indenting and I don't think I'm the only one (although I think we are in the minority). I would rather just add a horizontal line underneath. Brianjd 10:19, 2004 Dec 24 (UTC)

The horizontal rule is evil and should be destroyed. It is one of the ugliest HTML elements and has defaced many a webpage. Please indent. JFW | T@lk 03:17, 9 Mar 2005 (UTC)
The wording of the response made me laugh :). I do agree with User:Jfdwolff on this. Courtland 15:29, July 23, 2005 (UTC) P.S. I annihilated the horzontal line above, just a minor piece of deconstruction
Disagree. As stated the horizontal ruler is very ugly in almost every case. In fact, if you could run a search for the usage of horizontal rulers in articles, you could probably use that criteria to track down badly formatted pages. I don't think I've ever seen a well-formatted article that contained horizontal rulers. --Michiel Sikma 12:12, 7 January 2006 (UTC)

Request

Can [[Category:Disambiguation and Redirection templates|Dablink]] be added? —Mark Adler (markles) 22:52, 26 January 2006 (UTC)

I second the request using <noinclude>[[Category:Disambiguation and Redirection templates|Dablink]]</noinclude>. – Doug Bell talk•contrib 00:51, 27 January 2006 (UTC)
Done. howcheng {chat} 19:00, 30 January 2006 (UTC)

Polish version

Hi. I would like to propose to using Polish version of Dablink. Here you can see them:

I think that they are more readeable, or put in another words: you see them in the couple of secounds after page is displayed. Present form of Dablink is hard to see for those who are first time on Wikipedia.org. I saw a situation then somone think that he can not find on Wikipedia information he wants, becouse he didn't notice Disambiguation.

So whats why I propose to change this Template to something more "hiting in the eye". Egon 18:11, 5 June 2006 (UTC)

Polish interwiki

Please, add Polish interwiki: pl:Szablon:DisambigL. Thanks. Hołek ҉ 13:31, 12 August 2006 (UTC)

Subst

Should these be subst'ed? --Liface 18:01, 10 June 2006 (UTC)

  • No, but I couldn't give you the detailed reasoning why not. My own reasoning is based on the desire to be able to track dablink usage via the what-links-here association with this template, which can be used by either human or robotic actors to harvest dab-msg bearing article identities for a number of different purposes. User:Ceyockey (talk to me) 19:52, 10 June 2006 (UTC)
Another argument against substing is that it defeats one of the purposes of this template, to globally change the formatting on all the disambig links if the accepted format is ever changed. Binabik80 20:52, 5 October 2006 (UTC)

visual formatting should be done in CSS, not wiki markup

See Wikipedia:Village_pump_(technical)#Disambig_link_formatting — Omegatron 16:29, 20 December 2006 (UTC)

Done. But couldn't you have done this yourself? Aren't you an admin? —Mets501 (talk) 20:50, 29 December 2006 (UTC)
Of course. I wasn't asking for someone else to do it. I was asking if it should be done. There are a few different ways it could be implemented.
Note that people are going to want to to rever these changes if they haven't bypassed their cache. — Omegatron 20:57, 29 December 2006 (UTC)
Also, the other templates that use this class need to be updated, which I am doing now.
{{primary}} uses class="notice". What's that for? — Omegatron 21:10, 29 December 2006 (UTC)
This change was not appropriate, since {{dablink}} has been subst'd in way too many places. Now those uses are all double-indented. Mike Dillon 22:08, 29 December 2006 (UTC)
You're right. But Omegatron has already changed many templates. What should we do? —Mets501 (talk) 22:17, 29 December 2006 (UTC)
Can you (Mike) give an example of this? I don't see that subst'ing now makes any difference (although it might be possible that subst'ing some earlier version might cause problems). Without some evidence to consider, it's hard to evaluate your complaint. older ≠ wiser 22:17, 29 December 2006 (UTC)
Los Angeles, California. Mike Dillon 22:22, 29 December 2006 (UTC)
I see, thanks. Although I have to say, subst'ing dablink kind of runs contrary to the whole point of using dablink in the first place (which is to standardize the formating a bit). older ≠ wiser 22:24, 29 December 2006 (UTC)
See Macintosh for example. —Mets501 (talk) 22:18, 29 December 2006 (UTC)
There are only 548 times that this template has been substituted; should I just send my bot to fix it? —Mets501 (talk) 22:19, 29 December 2006 (UTC)
How did you determine that? If we can compile a good list, having a bot fix it should work. Determining what the original template was is probably not possible anymore. Mike Dillon 22:22, 29 December 2006 (UTC)
(edit conflict) Well, I think you guys have been a little too bold with some of these changes lately. Please don't take this the wrong way, Mets501, but I don't think you know enough about the technology to be making changes on this scale without discussion.
As for fixing it, it probably needs to be done by compiling a list of pages using the classes directly from the database dump and unsubst'ing those uses. I think all of the template and CSS changes probably should be rolled back in the meantime.
Don't get me wrong, this is a good idea, but it needs to be done in a controlled way. Mike Dillon 22:22, 29 December 2006 (UTC)

That's why templates shouldn't be substituted. The substituted instances will be updated over time. This method of formatting is superior. — Omegatron 22:23, 29 December 2006 (UTC)

I have a list of substituted uses from the database dump. I do understand the technological aspect 100%, I was just hasty and didn't think that it might be used in other places and forgot about substitution.
OK. Like I said, don't take it the wrong way. Anyways, that list doesn't have Los Angeles, California. Mike Dillon 22:30, 29 December 2006 (UTC)
That was probably added since the last dump. Should I start fixing these substituted ones? (or am I being too hasty again? :-) —Mets501 (talk) 22:32, 29 December 2006 (UTC)
I don't think the fixing the subst'd dablinks is hasty. We can do a second pass after you're done to see if there are any more. The extra indent isn't the end of the world. Mike Dillon 22:34, 29 December 2006 (UTC)
Starting now. —Mets501 (talk) 22:37, 29 December 2006 (UTC)
You're right about the timing. It was done in this edit on November 25 by User:Mgekelly. I have asked him not to subst these templates and pointed him to this discussion. Mike Dillon 22:40, 29 December 2006 (UTC)

Another problem :-)

Now that I changed all the templates, the complaints are going to my talk page.  :-) See

See User_talk:Omegatron#Broken_templates and Wikipedia:Village_pump_(technical)#Someone.27s_screwed_up_the_formatting_of_the_dablinks.21.21.21

Another problem is the line break caused by the use of the definition list for indentation. We should either change the dablink class to display:block;, or change all the instances into p class="dablink" instead of span class="dablink".

Mets501, this is why I asked about it first instead of just doing it. Now you've rushed it. — Omegatron 22:42, 29 December 2006 (UTC)

This template is already a div, not a span. Changing it to a <p> probably makes sense. Mike Dillon 22:49, 29 December 2006 (UTC)
The CSS is already coded. People are having issues because of CSS caching, as is often the case with these things. Mike Dillon 22:54, 29 December 2006 (UTC)
Try to persuade a developer to update $wgStyleVersion... that will kill caches everywhere. Titoxd(?!?) 22:58, 29 December 2006 (UTC)
Unfortunately, that version number is not included in the site CSS link the way it is for the CSS in the skin. The link is "/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=2678400", without the current $wgStyleVersion (39). Mike Dillon 23:01, 29 December 2006 (UTC)
Bug 8433 filed. Titoxd(?!?) 23:22, 29 December 2006 (UTC)
<p> tags are much harder to control. I'd prefer <div>'s. -- Renesis (talk) 22:55, 29 December 2006 (UTC)
What does "harder to control" mean? We should be using the most semantically appropriate HTML tag. I think p is appropriate for these short paragraphs of text. — Omegatron 01:19, 30 December 2006 (UTC)
I agree that p makes sense semantically. I believe what Renesis is referring to is the fact that the default browser style for <div> is generally just display: block, while the default style for <p> often include line-height and other things. If you can't predict what individual browsers are doing, it's harder to control, whereas the fact the pretty much every browser has the same default styling for div makes it a cleaner starting point. Mike Dillon 01:41, 30 December 2006 (UTC)
Ah. Well, I will change them all to p pretty soon unless anyone objects. — Omegatron 03:14, 30 December 2006 (UTC)
Better yet, I'll convert them to dablink meta-templates. :-) Then if we change our minds, it's one change here. — Omegatron 03:15, 30 December 2006 (UTC)

In about 10 minutes, all the substitutions will be unsubstituted, and then everything will look the same everywhere. (I'm running my bot faster than usual as this is sort of urgent). —Mets501 (talk) 22:56, 29 December 2006 (UTC)

Excellent.  :-) — Omegatron 01:19, 30 December 2006 (UTC)

Layout broken

The most recent change ([1]) broken the usual layout (indented, with italics), thus I had to revert it. Please provide a test version before changing it once more. We don't one thousands of pages broken. -- User:Docu

Have you purged your cache? Your change results in the dablinks being double-indented. older ≠ wiser 13:45, 30 December 2006 (UTC)
Seems like I didn't do it sufficiently. Works fine now. Thank you for fixing it. -- User:Docu

One way to possibly ease this pain would be do add inline style to the {{dablink}} template to duplicate what's in Common.css. It could be left in for as long as necessary to make sure people's browser caches have cleared on their own. This would be made easier if all the other templates using class="dablink" called this one as a meta-template, as suggested by Omegatron. Mike Dillon 17:07, 30 December 2006 (UTC)

It looks like this has already been done by Omegatron, so that makes things easy. The only caveat is that the inline CSS will have higher importance than CSS rules using ".dablink" as a selector, so people who want to override the style in personal CSS will have to use "!important", since rules in a style attribute have the same specificity as an id selector rule (100). Mike Dillon 17:16, 30 December 2006 (UTC)
To be clear, I meant that the meta-template thing has been done. I still think that the inline CSS should be added as a stop-gap. It doesn't make sense to keep telling individual people to clear their caches. Mike Dillon 06:18, 31 December 2006 (UTC)
Done. —Mets501 (talk) 15:21, 31 December 2006 (UTC)

Made up a /doc file

Hi! Can you add Template:Dablink/doc to the template. (It seems likely to survive TFD <g>, and I wish I'd known of it sooner.)

  I added a couple of cats ans stubbed in some interwiki's so it would travel better. Best regards and Happy New Year. // FrankB 16:54, 3 January 2007 (UTC)

{{editprotected}}

Done. J Di talk 20:36, 3 January 2007 (UTC)

Afterthought Query for opinion

  • Just wondering whether it would be a good idea to add 2em on the right side to stand clear of infoboxes, images, etc. Or is that likely to mess up some of the works inside template tables and such? // FrankB 16:57, 3 January 2007 (UTC)
I've thought of that too. Might be a good idea. — Omegatron 18:53, 3 January 2007 (UTC)
Then go dude! Do it! Thanks // FrankB 18:20, 5 January 2007 (UTC)

XHTML fix.

{{Editprotected}}
A nitpick to some, but actually following the XHTML specs won't hurt anything. Please change all occurrences of <br> to <br /> in the template. — SMcCandlish [talk] [cont] ‹(-¿-)› 23:27, 26 July 2007 (UTC)

The template doesn't contain any <br>s - perhaps you got the wrong page? Tra (Talk) 23:41, 26 July 2007 (UTC)
Fixed, but you could have done it: the <br>'s were all on the unprotected /doc subpage. Nihiltres(t.l) 23:45, 26 July 2007 (UTC)

Template name and usage scenarios

Referring to some historical comments on this page, I believe the name "dablink" is a contraction of "disambiguation link". However, the template doesn't seem to be particularly suitable for disambiguation, and certainly doesn't add any sort of link. I'm confused. Could somebody please fill me in here? -- era (Talk | History) 23:10, 28 March 2007 (UTC)

But those aren't very descriptive of what the template is for. It is for applying a format that is consistent with all the other disambiguation related notes, but which allows the actual text content to be adapted as needed. older ≠ wiser 02:06, 29 March 2007 (UTC)
So shouldn't older ≠ wiser's clarification above be added to a more prominent place in the documentation for this template? -- era (Talk | History) 03:25, 29 March 2007 (UTC)
Good point, older≠wiser. Yes, era. The current text "This template provides HTML block around the material embedded within forcing browsers to react on the contained code and text within a div-/div block. This is very useful for binding effects within other templates, or on disambig lines heading an article." is not that accessible to the typical editor. Maybe saying something that emphasizes that this is a fall-back dab template when other more specific ones prove to be inadequate to the purpose of providing a dab-hatnote on an article page (avoiding the use of 'hatnote', though, as this isn't a term that a lot of people are familiar with). --User:Ceyockey (talk to me) 10:48, 29 March 2007 (UTC)
You want to avoid "dab" too ... or better yet actually explain that it stands for "disambiguation". Also pointers to the "Comments" and "Notice" templates as possible alternatives would be useful, I imagine. -- era (Talk | History) 01:58, 31 March 2007 (UTC)

(reset indent) I just ran across my first instance of {{dablink}}, and yes, the doc was utterly unhelpful in explaining what it was for and why you'd use it instead of an {{otheruses}} variant. I'm surprised no one made any changes since this thread seems to say I'm not the only one who has been confused. So, I've edited the /doc page in an attempt to address the concerns here.

I think part of the problem here could be that "dablink" appears first on alphabetically sorted pages like Wikipedia:Otheruses templates (example usage), which implies it's preferred rather than what I would call a "template of last resort". On the page I found it used on, there's absolutely no reason why other more convenient templates couldn't have been used instead. I think there should be a note explaining that you should only use dablink when no other template will do the job.--NapoliRoma 16:30, 29 July 2007 (UTC)

It's also used as a "meta-template" for all of the other disambiguation link templates. Look at the source of {{otheruses4}}, for example. So, even though there isn't generally much of a reason to use this template directly, it controls the ultimate formatting and CSS classes of all other disambiguation templates. Mike Dillon 17:19, 29 July 2007 (UTC)
That's what I thought was probably the case, so I came here to see whether it was true, and nothing in the doc or this discussion said it was the case. I hadn't gone to the extent of checking the source of the other templates yet.--NapoliRoma 17:50, 29 July 2007 (UTC)
FWIW, I tend to use this one far more often than any of the others for the simple reason that it is the easiest to remember how to use. Personally I find the thicket of Otheruses templates rather confusing. older ≠ wiser 17:25, 29 July 2007 (UTC)
We should probably sort this out here before making any more changes to the doc.
The fundamental difference between using this and using one of the "otheruses" templates is almost philosophical: who controls the style? If you use "dablink", you have full control over the style, which is a two-edged sword. On the one hand, yes, it's much easier for you, the editor, to do exactly what you think is appropriate in this case; on the other hand, that means there is a great potential for loss of consistency over the whole of Wikipedia, which would be a loss for readers.
This is very similar to the decision of whether in editing an article you use section headers or just fall back to raw HTML. Raw HTML is "easy to remember" if you're familiar with it, but you not only lose things like automatic TOC generation and consistent style, you also lose the ability for future changes or enhancements in WP style to automatically be applied to what you've edited.
The doc for this template is a perfect example of this -- prior to my edits, it used a collection of font size changes, manual numbering, horizontal rules, manual indents and other minor format abuse. Was I correct to change this to use section headers and other higher level wikiformats? Some might disagree, and I suspect the line would be pretty much the same as that between those who prefer "dablink" and those who prefer the "otheruses" family.
I totally agree that today, the range of options for disambiguation link formatting is broad and insufficiently documented (I've been making my own attempt to fix this in other places). However, I also feel that punting and saying "write your own HTML and wrap it in a div block" isn't the correct answer.
My opinion, which seems to be on the whole backed by all the various disambiguation policy and guideline docs, is that the higher level formats should be preferred. As I mentioned, today was the first time I'd seen {{dablink}} in the wild, and I'd never seen it in documentation. Can we gather consensus? Is this the right place to discuss it? Have I missed an existing policy that already covers this?--NapoliRoma 17:50, 29 July 2007 (UTC)
Editing on a Wiki should be easy. If I have to consult a reference page each time I want to add a simple disambiguation note to a page, there is something wrong. I never cared much for the Otheruses templates and never saw much point to what seems their overly prescriptive and overly fine gradations. I don't see that using dablink is in any way equivalent to using raw html. The point of dablink is that is provides consistent formatting. I'm not aware of discussions in which the use of dablinks has been deprecated. In fact, from what I can recall of previous discussions, it was the ridiculous proliferation of specialized otheruses templates that was criticized. I mean, I don't care that much when other editors replace my dablinks with some other template. But I'd sure get a little irritated if they start giving instructions like "Tsk, tsk, you shouldn't be using dablink there -- you should be using XXXX instead -- that's what the guideslines say." older ≠ wiser 18:41, 29 July 2007 (UTC)
I see your points. My initial reaction came from some very poor documentation surrounding "dablink" -- it didn't appear in any of the dab-related documentation I had so far encountered, and its own documentation was woefully inadequate. There was no indication that it is heavily used as a meta-template, and the doc page was mostly taken up by examples of what looked like very arcane markup (much of which turned out to be display formatting for the examples themselves). Meanwhile, this talk page led off with a deletion proposal (and I didn't dig further to see that it was unanimously defeated), and was followed by other people wondering why this was used instead of something in the "otheruses" family.
That being said -- I still think the "otheruses" templates could be useful; their main drawback is that there are so $#^% many of them ("otherhurricaneuses"?!). They promote standardization and consistency, which is in favor of the reader, which should trump ease of editing. There is nothing inherently hard about using them, but they do tend to also be poorly documented. Current guidelines favor their use, which is why I phrased my edits to dablink/doc as I did, but you make a good case for the policy to be changed/softened/clarified to include dablink.
Anyhow, I think the documentation is now sitting at a reasonable place. There's a better explanation of what the template is, why someone might use it, what alternatives are, and where to go for more info. I'm going to take one more pass to try to group concepts a little more appropriately (and "unquestionably" will probably disappear, sorry :-).--NapoliRoma 20:13, 29 July 2007 (UTC)

Problem with nested italics

By placing the italicization via the style attribute for the div, nested italics which should occur with items such as book titles can't.

Please change

<div class="dablink" style="font-style:italic; padding-left:2em;">{{{1}}}</div>

to

<div class="dablink" style="padding-left:2em;">''{{{1}}}''</div>

so that nested italics work properly. Caerwine Caer’s whines 01:52, 1 January 2007 (UTC)

Another way to address this would be to add CSS rules for <i> tags that occur inside of .dablink. For example:
.dablink i {
    font-style: normal;
}
Since MediaWiki won't generate nested <i> tags, this should cover all the cases. Mike Dillon 02:19, 1 January 2007 (UTC)
Done. If the effect does not display as desired, re-add {{editprotected}}. If you have any questions, please contact me at my talk page. Ian Manka 03:59, 3 January 2007 (UTC)

Please remove the CSS styling that forces italics on this template's contents. There is no compelling need for it when wiki markup suffices, and there's good reason to avoid it. Wiki markup and styling should serve the needs of ordinary editors, not the other way around. We should not have to tell people "use wiki markup everywhere, except in really weird places where it doesn't work because some programmers wanted to use CSS styling and didn't consider how it would break ordinary use, in which case you must use old HTML". We may be HTML coders, but we are expecting our main editing audience not to have to be. That's the whole friggin' point of wiki markup! ~ Jeff Q (talk) 05:25, 4 August 2007 (UTC)

Just to let people know, I've removed the redundant '' from the template, and added .dablink i { font-style: normal; } to MediaWiki:Common.css. This should enable '' to work as expected in dablinks, such that {{dablink|This is in italics, but ''this'' is ''not''.}} will produce:

This is in italics, but this is not.

See also this discussion at the village pump (technical). —Ilmari Karonen (talk) 15:49, 28 August 2007 (UTC)

CSS: Padding

Please add top padding to this template as such templates as {{Refimprove}} border too closely. For example:

This sentence exists to demonstrate insufficient top padding.

This sentence exists to demonstrate sufficient top padding.

The latter example uses <p> tags; however, I'm not suggesting the use of those tags.

Adraeus (talk) 01:48, 19 November 2007 (UTC)

Spanish interwiki

Admins: could you add the interwiki

[[es:Plantilla:Dablink]]

Thanks a bunch. Federico Grigio, alias Nahraana (talk) 07:56, 27 April 2008 (UTC)

 Done Titoxd(?!? - cool stuff) 08:10, 27 April 2008 (UTC)

Template copied to OpenStreetMap

This template has been copied intact with history to https://wiki.openstreetmap.org/wiki/Template:Dablink for use on the OpenStreetMap wiki. --User:Ceyockey (talk to me) 00:58, 25 March 2010 (UTC)

Articles using this template directly

As the free-form {{dablink}} has become a “meta-template” for other disambiguation templates, I’m not seeing any easy way to list articles which use this template directly (and which, in all but the most pathological of cases, could be updated to use one of several standard forms), short of scanning a database dump. This is because whatlinkshere disregards level of depth. ―cobaltcigs 03:44, 4 February 2011 (UTC)

Can we move this?

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: template moved per discussion. I've repaired the double-redirects already; other links shouldn't be a problem, as noted below. - GTBacchus(talk) 14:46, 13 September 2011 (UTC)


Template:Dablink → Template:Hatnote – Seeing which templates use this template nowadays, I really think that the name of it doesn't fit anymore. It's used for many other purposed than linking to a disambiguation, like linking a secondary topic (e.g. {{for}}, {{about}}), notes about conventions ({{Spanish name}}, {{Foreign character}}), technical notes ({{correct title}}). Thus, I believe that "Hatnote", which is already a redirect to this template, is a better name for the template, because that's what all these templates have in common. --The Evil IP address (talk) 12:05, 4 September 2011 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.


According to this it's WP/WMF jargon. Dablink is certainly jargon too. But the thing that worries me about this move is the genericity if the name. We have lots of hatnote templates, this is just one of them Rich Farmbrough, 02:09, 16 October 2011 (UTC).

The same objection would have applied to "dablink". But in a sense, this is the generic template for this purpose, so it seems perfectly in order that it should have a generic name. (And while both might be jargon, "hatnote" is the more common jargon.)--Kotniski (talk) 07:20, 16 October 2011 (UTC)
I hadn't realised just how dumb this template is, the new name is much better. Rich Farmbrough, 00:00, 24 October 2011 (UTC).

Conflict interwikis

To this English template, next templates suggested as interwikis:

as:Template:Dablink (currently renamed to as:সাঁচ:Hatnote)
ca:Plantilla:Metacaixa enllaç de desambiguació

I think the users of 'as' and 'ca' Wikipedia can clarify it. --94.27.64.95 (talk) 21:08, 10 January 2012 (UTC)

Conversion to Lua

I've recently converted the templates {{main}}, {{see also}}, {{further}} and {{details}} to Lua, and in the process I have collected all the joint functions that they use in Module:Hatnote. That includes Lua versions of {{hatnote}} and {{rellink}}. Would anyone object to me updating these two templates to use the module? The performance difference may not be that noticeable, but it will have the advantage of keeping the code all in one place. — Mr. Stradivarius ♪ talk ♪ 17:04, 24 April 2014 (UTC)

See also related discussions at Template:Details, Template:Further, Template:See also and Template:Main. — Mr. Stradivarius ♪ talk ♪ 17:08, 24 April 2014 (UTC)
@Mr. Stradivarius: prior to this happening, I would like to propose a template merge request of {{Hatnote}} and {{Rellink}} on Tfd. From what I saw, the two templates have only one difference that can be merged into the other without having to manually change the values in the near 800,000 combined transclusions of these two templates. Steel1943 (talk) 17:12, 24 April 2014 (UTC)
...(This was the reason I had requested the full protection be changed to template protection on these two templates a while back, but never got around to starting the discussion. Proposing a Lua conversion of these templates makes the need for the TFD discussion a bit more urgent.) Steel1943 (talk) 17:14, 24 April 2014 (UTC)
Sure, go ahead. The only sticking point looks to be that hatnote uses the "dablink" CSS class, whereas rellink uses the "rellink" class. Looking at MediaWiki:Common.css, though, the class definitions seem to be identical. If there's no reason for having different classes, I can't see that this would be controversial, but a TfD would definitely settle the issue. — Mr. Stradivarius ♪ talk ♪ 17:23, 24 April 2014 (UTC)
Would a successful TfD to merge trigger the full consequence that the classes are the same? That would make one obsolete right? At least for the affected hatnote templates; a phasing out. -DePiep (talk) 11:26, 25 April 2014 (UTC)
I'm in the belief that both classes ("dablink" and "rellink") should both be replaced with a new "hatnote" class for clarity purposes. Steel1943 (talk) 18:32, 25 April 2014 (UTC)
(Comment from uninvolved editor) Can someone, an admin or templateeditor, put <noinclude></noinclude> tags around the TFD notice at {{Rellink}}? It's showing up on a lot of articles. BTW, I support the merging of these two templates. Epicgenius (talk) 17:53, 24 April 2014 (UTC)
Done. Also, Steel1943, you still need to add an entry at Wikipedia:Templates for discussion/Log/2014 April 24. — Mr. Stradivarius ♪ talk ♪ 18:01, 24 April 2014 (UTC)
(edit conflict)And it also is directing to Wikipedia:Templates_for_discussion/Log/2014_April_24#Template:Rellink. §§Dharmadhyaksha§§ {T/C} 18:03, 24 April 2014 (UTC)
I will start the discussion here shortly. Steel1943 (talk) 18:27, 24 April 2014 (UTC)
 Done Discussion started at Wikipedia:Templates for discussion/Log/2014 April 24#Template:Rellink. Steel1943 (talk) 18:37, 24 April 2014 (UTC)
  • About {{selfref}}. This is a special hatnote that uses class="plainlinks selfreference" to handle self-reference links (=WP-internal). Instead of being a separate template, should not this be an option in all hatnote templates (by parameter). That way they use the standard (better known) name & text formatting, while functioning as intended. (I am not sure of the "plainlinks" class job in this). -DePiep (talk) 09:34, 25 April 2014 (UTC)
    {{Selfref}} also has an option to be used inline, so to merge the templates we would have to add that option to {{hatnote}}, which doesn't make much sense. — Mr. Stradivarius ♪ talk ♪ 10:01, 25 April 2014 (UTC)
Unless I am the one misunderstanding: {{selfref}} can stay untouched. But inversely, all hatnotes could have like |selfref=yes that adds the class. So for example an editor can use basic {{detail}}, adding the selfref status. That way an editor can use full module:hatnote naming & formatting in all Lua-fied hatnotes. Today, one would have to reproduce the full text into {{selfref}} to get that effect. -DePiep (talk) 10:14, 25 April 2014 (UTC)
Ah, I see. That would require some altering of the code, but could be done. I'll add it if there's a demand for it. — Mr. Stradivarius ♪ talk ♪ 08:22, 26 April 2014 (UTC)
Well, didn't I just explain that demand by logic? -DePiep (talk) 23:16, 27 April 2014 (UTC)
I'll explain more.
Currently, module:hatnote produces a red error text (1).
That will be introduced when we ('we', well, it won't be me) change to this module, for 100k's of pages. A few (1000?) may get that text after changeover. So far, we'd have to check all pages to see which are red topped. All readers of those pages see that (embarrassing, chasing away). Even an editor who edits a hatnote and makes a mistake, sees the red text and may leave without being offered help.
We could add the page to a hidden maintenance category (2), and hide the red text. This way we can track, chase & clean errored pages.
We could also add a specific maintenance tag (3). That looks like this[weasel words] (see Category:Inline cleanup templates). It could be specific, like {{convert}} can produce: 1 xyz[convert: unknown unit]. They are constructed by generic {{fix}}, by the way.
-DePiep (talk) 22:43, 25 April 2014 (UTC)
I'd be fine with either of those, although I have a slight preference for the big red error message plus a tracking category. I like my error messages to be obvious. I agree that having a tracking category is better than not having one. — Mr. Stradivarius ♪ talk ♪ 08:24, 26 April 2014 (UTC)
OK, please encode it. We understand that uncategorised (unlisted) red top pages are bad (I'd say: blocking this Lua switch). So: the reader is saved.
From there, it's only details & wp-philosophy. A big red error message when an editor does a preview -- I'd like to prevent that. Don't show & do categorise, I'd say. Even in my experience (a busy editor), those big red reference messages are not stimulating (I left such edit, did not improve it). And reference is a big thing, hatnotes are not. Now please rethink the error effects, help the editor. As said, all this is secundary to #1 the maint cat. -DePiep (talk) 20:20, 27 April 2014 (UTC)
Please correct & adjust as is needed for the discussion:
Template Lua? Module Note
{{hatnote}} no ? TfD to merge
{{rellink}} no ? TfD to merge
{{details}} no module:details
{{further}} no module:further
{{main}} no module:main
{{see also}} no module:see also
{{Format hatnote link}} yes module:hatnote

To be clear, I applaud & enjoy this proposal and the modules behind it. One more development I can learn from. Some questions, with varying importance (so please treat them as such):

  • ? Does the module setup require an intermediate module for {{hatnote}}, to use (generic) module:hatnote? A parallel question could be made for {{rellink}} of course. {{Format hatnote link}}, already using Lua, seems to contradict the "not by invoke" statement (in Module:Hatnote#Use_from_wikitext). -DePiep (talk) 22:21, 25 April 2014 (UTC)
    "Not by invoke" means that it is actually impossible. Try {{#invoke:hatnote|formatLink|Foo}} - it won't work. {{format hatnote link|Foo}}, however, will work just fine. That's for performance purposes - every argument check has a performance cost, although probably not very much in this particular case. However, for simple hatnotes, there's no need to go all-Lua. You could just use {{format hatnote link}} with the link and be done with it. Having a dedicated module is most important where you take a list of pages as input rather than a single page, as Lua allows you to grab the arguments that were actually passed to the module without trying 15 different arguments where only one was specified. (This also means that Module:Details won't actually save very much work - I readjusted the module structure and split out the functions into separate modules, and I probably wouldn't have bothered to make a separate module for {{details}} if I had done that from the start.) — Mr. Stradivarius ♪ talk ♪ 08:36, 26 April 2014 (UTC)
Thanks. -DePiep (talk) 20:07, 27 April 2014 (UTC)
  • In the new module documentations, the word "hatnote" is omitted. For example, module:further now says: This module produces a "Further information: a, b and c" link [sic]. It implements the {{further}} template.

    Apart from the sic (for being a bad sentence, what the word 'hatnote' could solve), why not write like "... the {{further}} hatnote template"? By omitting that it is a hatnote, the connection with WP:HATNOTE is cut out in the new module. I'd say the modules too should be guidelined for being a wp:hatnote. -DePiep (talk) 22:21, 25 April 2014 (UTC)

    Feel free to update the documentation yourself - I didn't give the wording an incredibly long amount of thought. If you have a better wording, by all means go ahead and change it. — Mr. Stradivarius ♪ talk ♪ 08:36, 26 April 2014 (UTC)
OK. I was just wondering. Especially since even your early documentations don't look like you "didn't give .. much thought". They are great! -DePiep (talk) 20:07, 27 April 2014 (UTC)
  • @Mr. Stradivarius: do you prefer a 1:~1 switch to Lua, and then any other issues be discussed & solved thereafter (classes, formats, maintenance categories, ...)? If so, I'd like to read that. That would reduce the discussion to the more blocking issues. -DePiep (talk) 22:21, 25 April 2014 (UTC)
    We probably shouldn't do anything wildly different from the existing templates, but I would be open to suggestions for improvement that are possible now that we have Lua. For example, {{Format hatnote link}} wouldn't have been possible (or at least, wouldn't have been easy) before we had Lua. — Mr. Stradivarius ♪ talk ♪ 08:36, 26 April 2014 (UTC)
OK. imo, class rethinking remains. -DePiep (talk) 20:07, 27 April 2014 (UTC)

I've implemented some of DePiep's above suggestions:

  • Wikitext errors produced by Module:Hatnote are now tracked at Category:Hatnote templates with errors. (They still use the big red error messages; if we want to use the smaller {{fix}}-style ones, really we need to convert that template to Lua so that people don't have to reinvent the wheel every time this situation comes up.)
  • You can now specify |demo=yes to suppress categorisation.
  • You can now specify |selfref=yes to add the "selfref" class to any of the converted templates. (See {{selfref}}.)
  • As a result of the selfref change, the syntax for calling Module:Main etc. from other Lua modules has changed slightly. It should now be more standardized and therefore less likely to break if programmers convert other hatnote templates.

Questions and comments welcome. — Mr. Stradivarius ♪ talk ♪ 17:15, 2 May 2014 (UTC)

Thanks. Feels good I could contribute a bit.
About classes in general: I understand you don't advocate any change, however archaic they are.
About |selfref=yes: the old two classes are added then?
(Can someone reorder this thread?)
-DePiep (talk) 21:40, 2 May 2014 (UTC)
Adding: the maintenance (error) categorisation could be restricted to mainspace or to content namespaces. -DePiep (talk) 21:43, 2 May 2014 (UTC)
Adding2: Don't understand why the parameter is named demo. Otherwhere I use |addcat=no.
Adding3: big red text is helping readers nor editors. I get the {{fix}} problem not being Lua. Alas, I already described. -DePiep (talk) 22:08, 2 May 2014 (UTC)
I'm fine with updating the classes, but that needs to happen at MediaWiki:Common.css before we can do it here. I've left a message on the talk page there. About selfref - all the old classes are added, yes. The only thing changed with selfref is that the selfref class is added. And about |demo=: that's a standard way of doing category suppression, and is also used by AnomieBOT to suppress template substitution. The other widely-used parameter that I have seen is |nocat=, and I don't mind switching to that if you prefer. I haven't seen |addcat=no used before, though. Also, about reorganising the thread - it's a bit late for that now. :) The best thing would have been to start each of these points in a different subthread, but now this discussion is thoroughly tangled, and untangling it probably isn't worth the bother. — Mr. Stradivarius ♪ talk ♪ 03:58, 3 May 2014 (UTC)

Demo parameter

@DePiep and Steel1943: The "hatnote" class has been added to MediaWiki:Common.css, and I have updated the module accordingly. I think we're almost ready to deploy. We have just a couple of issues still left that need addressing.

The first of these is the |demo= parameter. Would this be better off given a different name? |demo= is used in AnomieBOT's TemplateSubster, mostly used with user warning templates. |nocat= is the default in {{category handler}}, and in my experience has the widest adoption among category suppression parameters. DePiep has suggested |addcat=, but I'm not sure what precedence that has. What would people like to use? — Mr. Stradivarius ♪ talk ♪ 16:32, 3 May 2014 (UTC)

Every (?check) WikiProject banner (and there are thousands) uses |category=no - here's some typical documentation:
  • category – set |category=no if, and only if, a banner is being used for demonstration or testing purposes, to prevent unnecessary or undesirable categorization. Otherwise, omit this parameter.
I've not seen |addcat= used in the wild. --Redrose64 (talk) 16:55, 3 May 2014 (UTC)
  • I used |addcat=no as an illustration only. It's a ... demo name. It's a name I created in a module recently; what you can call "in the wild" ;-). Nothing more about it.
It is, I do not associate parameter name |demo= with category suppression at all. To me it is not intuitive, and will not become. When I would want to invoke it, it likely is not a demo situation but for an other reason. Cat suppression without using anything like "..cat.."?
I have no trump alternative. A detail issue with R64's suggestion |category=no is, that that is from WP space, not content space. I think I miss a reference (hint, option) to the maintenance status of the cat. I have no solution or improvement name though. So for now, my votes (huit points) go to |category=no.
The outcome here is not that important, but I find it worth thinking about this (better programmer). Except for this: now that Mr. Strad has mentioned {{category handler}}: the even worse parameter thing is |nocat=yes. That is moving programming heaven further away. -DePiep (talk) 19:06, 3 May 2014 (UTC)
Thanks for the comments. I've used |category=no in {{details}}, {{further}}, {{see also}} and {{main}}. I've christened the Lua parameter addTrackingCategory. (It doesn't matter if the Lua parameter has a long name, as it's all done positionally - other Lua coders will never have to type it in.)

Error message

@DePiep: You've mentioned that you want {{fix}}-style error messages rather than bold error messages, but I'm not sure how this would work in practice. Could you give an example of the wikitext that you would like to see generated? Normally {{fix}} comes after some text that needs labelling; for example, with {{citation needed}} we have a sentence in an article, and then immediately after the sentence we have the citation needed tag. So, in that case, the tag is referring to the sentence. With hatnote templates, though, there wouldn't be any surrounding text to reference a {{fix}} template to. Or maybe I'm misunderstanding what's been suggested? I think an example would help to clear things up. — Mr. Stradivarius ♪ talk ♪ 16:32, 3 May 2014 (UTC)

Well, I prefer {{fix}} like error messages over big red text, or a combination. For WP philosophy reason. By priority:
Prio 1. Never give a reader a red error text. You already helped preventing that (add to maintenance category).
Prio 2. Don't give an editor a big red error text. That would show in preview or right after save then. The minor problem is that they rarely link to the right help/documentation page (does this one now?). The major problem is that it does no help the editor at all. For example: <ref> produced them. I can say, 50% of the times I saw that in preview, I did not research & solve that section preview, but I dropped my intended edit completely. So no improvement for WP, and a frustration for an editor.
What then? Example {{convert}}, again. Most of 2013, Johnuniq was developing module:convert. In good working sequence, first the messages were to be just big orange blocks, inline even. In the end it was refined into {{fix}} layout (I proposed). It must be hardcoded in module:convert, not Lua. I must leave it up to Mr. Strad for Lua implementation, this is not my depth. For now: hardcoding {{fix}} format code would be needed.
You point to the resulting isolated fix message (no subject text nearby). After all, it is a hatnote. Well, by my approach, that is still better that any red text (because: no one is chased off, and others are invited in the maintenance category to wiki-improve. Good).
What I do want to advocate, in all, is to approach this by some WP-philosophy, to prevent bad experience as described. OTOH, if any issue would seriously postpone introduction, I think any intermediate solution would be OK for me (e.g., we should not wait for Lua-implementation of {{fix}}). -DePiep (talk) 20:21, 3 May 2014 (UTC)
I've added a helpLink parameter to the error category, so now editors will have a link to a detailed help section if they trigger an error in {{details}}, {{further}} or {{see also}}. ({{main}} doesn't trigger any errors, as it uses the page name as a fallback.) If red is really seen as a bad idea, we can try formatting the error message a little like {{see also}} used to do:
Error: no page names specified (help).
What do people think of this alternative? — Mr. Stradivarius ♪ talk ♪ 18:03, 5 May 2014 (UTC)
Meh. It's workable, but red error text actually gets noticed and fixed far more often than not; that's why citation templates, substitution error checking, etc., use it so often. If there were an actual "it's bad for our readers" problem, we'd know about it by now. Those closest case to there being such an issue is in citation templates, since many people paste a citation in, save and go, without checking to see if the ref worked correctly in the article. I.e., the #1 place you'll find uncorrected red error text in actual articles is under ==References==, at the bottom of a page. With hatnotes, it'll stand out more prominently and get fixed faster.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:36, 23 May 2014 (UTC)

Implemented

I have now switched this template to use Module:Hatnote, and {{details}}, {{further}}, {{see also}} and {{main}} have all been converted as well. If anyone notices any issues with the conversions, please let me know. — Mr. Stradivarius ♪ talk ♪ 18:03, 5 May 2014 (UTC)

The Lua version already picked up one badly formatted hatnote in the Blues article. There may be more to come - eyes on Category:Hatnote templates with errors would be welcome. — Mr. Stradivarius ♪ talk ♪ 02:24, 6 May 2014 (UTC)
Wilco. Codename Lisa (talk) 02:42, 6 May 2014 (UTC)

Inline variant

Module:Hatnote can now handle an "inline" parameter, outputting a span instead of a div (either for actual use inline, e.g. a "For more information..." at the end of a paragraph, or for use inside some other kind of block or inline-block element). See Module talk:Hatnote#Inline variant for details and how it's been deployed so far.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:31, 23 May 2014 (UTC)

Note: I've reverted this change and left a note on Module talk:Hatnote. — Mr. Stradivarius ♪ talk ♪ 23:49, 23 May 2014 (UTC)

Does not substitute

@Mr. Stradivarius: If you edit this section and Show preview you should see what I mean. I used {{delay subst}}, i.e. {{subst:delay subst}}hatnote|Not to be confused with a quick brown fox.}}

{{subst:hatnote|Not to be confused with a quick brown fox.}} — Wbm1058 (talk) 21:22, 17 May 2014 (UTC)

Is there a situation where substitution is necessary? It says at the bottom of the documentation not to substitute hatnote templates (and I didn't write that bit). — Mr. Stradivarius ♪ talk ♪ 03:25, 18 May 2014 (UTC)
I suppose not. In which case maybe there should be a {{Ifsubst}} or equivalent check to report the specific problem, rather than "Error: no text specified" because I did specify text. I was just working on another project and randomly picked this template as a simple template to test a use of multilevel substitution. So that's why I tried to subst: this. I suppose I should pick a simple template that is intended to be substituted. Wbm1058 (talk) 10:36, 18 May 2014 (UTC)
I'd call this a WONTFIX.  :-)  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:25, 23 May 2014 (UTC)
I added an error explanation to the documentation for this a while back - hopefully that will be enough of a fix. — Mr. Stradivarius ♪ talk ♪ 23:58, 23 May 2014 (UTC)
Yes, that's OK. I added a to {{Nosubst}} to Template:Hatnote templates documentation as well. Wbm1058 (talk) 01:03, 24 May 2014 (UTC)

Italicisation

What's the best way to prevent this template from italicising, for example when used in {{Category explanation}}?— Preceding unsigned comment added by Pigsonthewing (talk • contribs) 11:33, 22 December 2014 (UTC)
- - - - - (Here beginneth DePiep's contrib:)

Remove hatnote style altogether from that template! It is not a WP:HATNOTE at all. Whatever is entered there should be straight lede.
For other cases: pre-italicising the entry cancels out hatnote italisation:
  • {{hatnote|''Abc''}} →
    Abc

However, this might be introducing inappropriate style. When partial, it might be OK:

- - - - - (Here endeth DePiep's contrib.)

Hatnote issue

Why do the hatnotes have no extra paragraphing space? I liked the little space between two hatnotes. Qwertyxp2000 (talk) 06:26, 16 January 2015 (UTC)

@Qwertyxp2000: Hi there. Could you give an example of a page where you're seeing problems? It's hard to know what you mean just from that description. Best — Mr. Stradivarius on tour ♪ talk ♪ 08:18, 16 January 2015 (UTC)
This was discussed at Wikipedia:Templates for discussion/Log/2015 January 8#Template:Hatnotes. SiBr4 (talk) 09:04, 16 January 2015 (UTC)
An example...
Main article: potato
See also: lemon

Qwertyxp2000 (talk) 20:26, 16 January 2015 (UTC)

Or this...
"TEXT" redirects here. For STUFF TO WRITE, see THING.
Not to be confused with TEXT.

Wait, now it works? In other articles, hmm...

Qwertyxp2000 (talk) 20:28, 16 January 2015 (UTC)

Not it's not... The hatnotes sure need just a little more space between the hatnotes. Qwertyxp2000 (talk) 20:29, 16 January 2015 (UTC)
Below are examples: two hatnotes (A) vs. two regular lines (B). Next pair: same setup, but tight so it does line-wrapping (C, D).
This is hatnote One
This is hatnote Two

Here the lede starts. A.

This is a regular line Three
This is a regular line Four

Here the lede starts. B.

This is hatnote Five
This is hatnote Six

Here lede starts. C.

This is a regular line Seven
This is a regular line Eight

Here lede starts. D.

The whitespace above the lede is intentionally a bit larger. I do not see ap problem. -DePiep (talk) 21:20, 16 January 2015 (UTC)
  • The extra space between the hatnotes was an unintentional side effect of my trying to put some space below the hatnote(s). That has now been remedied, so what you see is what was initially intended. -- [[User:Edokter]] {{talk}} 21:44, 16 January 2015 (UTC)

Template-protected edit request on 9 August 2015

Add the Category:Exclude in print category to hatnote templates because they simply do not make sense in Wikipedia books (which lack links). sovereign°sentinel (contribs) 10:59, 9 August 2015 (UTC)

Seems to make sense. But has this been discussed anywhere? — Martin (MSGJ · talk) 16:53, 9 August 2015 (UTC)
Not done: It doesn't make sense, because Category:Exclude in print doesn't do anything anymore. Adding the noprint class to Module:Hatnote would work, but I seem to remember that this was discussed and rejected in the past. (Can't find the link to the discussion, though, sorry.) @Sovereign Sentinel: Either way, you'll need to demonstrate that there is a wider consensus for this change before we can go through with it, or at least that it's been discussed somewhere. I'd try WP:VPT first to see if anyone remembers the past discussions. — Mr. Stradivarius ♪ talk ♪ 12:48, 11 August 2015 (UTC)
I recall that when you (Strad) Lua-ised the hatnote, I proposed to add the option "Is internal WP only" aka self-reference. This from the meta-module into each hatnote tempalte, and setable in article page (so that an editor can use any hatnote template and not it to be selfreferencing). Isn't this related? -DePiep (talk) 11:22, 30 January 2016 (UTC)
We can't do that without forking the code, since module and its inline variant is used for more things than inter-page cross-referencing (i.e., it's used for within-page cross-referencing, which is not WP selfref). See, e.g., Template:See above, which uses the Module:Hatnote inline variant. These in-page cross-reference templates use {{Crossreference}} (which in turn is using {{Hatnote-inline}} and Module:Hatnote-inline); it passes the selfref class by default, but has that turned off for specific uses like {{See above}} that shouldn't have it. The regular {{See also}}, etc., indented hatnotes using Module:Hatnote can also be used in the same long article, though we're not presently account for these uses not being WP selfrefs. I've been slowly working here and there are separating out in-page and cross-page usage, but have not focused on this much. It needs to be done eventually, because "See also [article so-and-so]" will make no sense in many misuses and should be class selfref. If Jane Doe wants to borrow all WP content about dogs, for example, to work on a new DogPedia, a disambig hatnote to a geographical article sharing the same name as a dog breed is just "noise". But an in-context "(see below for details)" inline note referring to another section of the same article may be of value. They should remain tagged with the hatnote class (or some new crossref class or whatever) in case someone wants to expunge all of them, in-page or not, from whatever they need the content for.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:13, 24 March 2016 (UTC)

Hatnotes in HTML5: <aside> instead of <div>

HTML5 introduced a new <aside> element for content tangentially related to the main text. This is a perfect fit for hatnote messages. Currently, hatnotes use the semantically void <div> element. I propose switching to <aside> elements instead, so long as it can be done in a way that degrades gracefully in IE8 and earlier. Matt Fitzpatrick (talk) 00:41, 17 April 2015 (UTC)

A bit confusing.That "aside" and 'tangentially' is sematically? If so, how do we positionstyle the hatnote? And is the class=hatnote not sufficient? -DePiep (talk) 06:50, 17 April 2015 (UTC)
<aside class="Some classes">Some text</aside> → <aside class="Some classes">Some text</aside> - the tags are simply passed through with the < and > escaped, converting them into plain text. This means that the aside element is not whitelisted, so we can't use it. --Redrose64 (talk) 08:47, 17 April 2015 (UTC)
Oh dear, the HTML sanitizer seems to be well behind the times. I'll go file a bug report, then, and come back to this later? Matt Fitzpatrick (talk) 04:31, 18 April 2015 (UTC)

Okay, back! The role attribute will be whitelisted in the version to be deployed next week (1.27.0-wmf.12). role provides accessibility context similar to using <aside> and similar semantic HTML5 elements. Although some hatnotes could be role="navigation", I think role="note" is the best fit. Holding off on the edit request until the patch, but does this look like a good idea? Matt Fitzpatrick (talk) 03:17, 30 January 2016 (UTC)

I have a mockup at testwiki:User:Matt Fitzpatrick/sandbox. Adding role="note" makes no difference to the Orca screen reader over Firefox, but according to the JAWS ARIA doc, JAWS inserts user-configurable start and end strings to mark it as a note. I believe the default setting is "note" start string and no end string. So this appears helpful, for JAWS users at least, to set hatnotes aside from the main article content. Matt Fitzpatrick (talk) 08:03, 4 February 2016 (UTC)

Yeah, it's been frustrating for a long time that the sanitizer is denying use of HTML5 features like <aside>...</aside> and <article>...</article>, etc. Definitely needs to be fixed. There's so much we could do with these things.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:15, 24 March 2016 (UTC)

Minor tweak

Someone vented about me making a "trivial" edit here, so let me say that it wasn't trivial, just minor. WP page names begin with a capital letter, and code is more easily parseable at a glance when it uses this convention, especially when the function being called in the module has the same name as the module itself. I considered this edit for over a week before finally deciding to make it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:23, 23 May 2014 (UTC)

Yes, it was trivial. It doesn't have any effect on the output of the template, and I can only see it having an effect on readability for editors who know nothing about how #invoke works. All that edit has succeeded in doing is putting 400,000 pages into the job queue. — Mr. Stradivarius ♪ talk ♪ 23:21, 23 May 2014 (UTC)
And nothing bad happened.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:17, 24 March 2016 (UTC)

Please apply inline style to .hatnote class

There is no reason to ship the .hatnote styles to every user and not to do them inline in the template given they are so prominent in the UI.

I've made a suggested change to this module which would allow us to remove the rules in MediaWiki:Mobile.css and MediaWiki:Common.css. In the mobile site these CSS rules are delayed relating in a flash of unstyled content.

@SMcCandlish: @Mr. Stradivarius: what do you think?

Jdlrobson (talk) 21:01, 24 March 2016 (UTC)

Sure. Sounds like it will solve a problem. No styles need be in the centralized stylesheets unless there's a cascading, selector, pseudoclass, or other technical reason they cannot be inline, unless they need to be shared across multiple things with consistency "enforced". E.g., I would support retaining the block quotation style matters in the central stylesheets because whimsical people keep trying to "decorate", as if this were their own personal blog.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:00, 24 March 2016 (UTC)
@Jdlrobson: This sounds backwards to me - generally the received wisdom has been that templates used wiki-wide should have styles defined in style sheets because it avoids us having to use inline styles everywhere, and that inline styles are bad web design. But if it solves a real issue, then I won't object. I'll also leave a note at MediaWiki talk:Common.css, given that this proposal will mean editing MediaWiki:Mobile.css and MediaWiki:Common.css as well. — Mr. Stradivarius ♪ talk ♪ 23:46, 24 March 2016 (UTC)
Thank you for the quick reply! It is somewhat backwards.... but better than shipping to all users. Long term we should move away from inline styles somewhat and the WMF is luckily looking to push on resolving a longstanding problem for template editors- the ability to add style tags to templates] which will allow us to use @media queries. Inline styles are not necessarily a bad thing. They are mostly problematic for layouts that need to adapt to different resolutions e.g. mobile, or where they are generically useful and shared by templates. In this case the margins and paddings here are harmless and the same in both and are not reused to my knowledge by any other template (but please correct me if there are other templates using the hatnote class) so I'd recommend doing them in the template. I can edit MediaWiki:Common.css and MediaWiki:Mobile.css to remove the rules once they have been ported to style tags and we are sure the css rule is not used elsewhere @SMcCandlish: @Mr. Stradivarius: Jdlrobson (talk) 00:10, 25 March 2016 (UTC)
The "if they're shared" part is key to me. There's no reason to bloat the centralized stylesheets with stuff used in a single module (or one and its inline variant, the code of which can be merged easily into one module anyway). The more we move stuff into modules that service multiple templates the less we need to put styles in Mediawiki:Common.css, etc. I realize there are dueling dev philosophies at work here, and trust that it'll balance out over time. The more bloated the centralized stylesheets get the longer they take to load, sometimes with undesirable results as you've shown, and that concern has to be balanced against the centralize-style-in-one-place urge. We should centralize stuff that gets recycled, by design, in multiple places.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  00:23, 25 March 2016 (UTC)
This is completely backward. Let's analyze what causes the problem. Could it be Mobile.css is loaded too late? It didn't used to be. So how about we fix the cause instead of patching site CSS to hide the problem? -- [[User:Edokter]] {{talk}} 16:33, 25 March 2016 (UTC)
And yes, there is a selector (+) that cannot be applied inline. -- [[User:Edokter]] {{talk}} 16:37, 25 March 2016 (UTC)
Mobile.css is loaded at the bottom of the page. It is not designed for CSS changes that shift the layout. It has always been this way and is done so for performance reasons. The additional stylesheet link requested required when it is in the head delays rendering for users on mobile devices with slow connections (the same happens on desktop but desktop does not have so many 2G users to worry about). Anything changing margins/paddings at the top of the page should be avoided in this wiki page. As stated pushing harder on add style tags to templates will fix this on the long term but if we are keen to retain the hatnote margins in the mean time we should port them to the template. If we are not keen to do, I think there are good reasons not to, and we are keen to keep them we can add them temporarily to a MobileFrontend stylesheet until that RFC is resolved (hopefully within next 3 months). Jdlrobson (talk) —Preceding undated comment added 16:47, 25 March 2016 (UTC)
I though Mobile.css was intended to be the replacement for Commmon.css on mobile. Apparently, it is not. Has there been any performance testing? With proper caching, Mobile.css could easily be loaded from the top wihtout any impact. But really, all CSS in Mbile.css will generate FOUC in it's current form, but I cannot accept that as a reason to move CSS inline. If CSS presents a (perceived) problem for the mobile site, it should be removed from mobile.css, but never moved inline, as that affects all platforms, most notably desktop. I really hope the Mobile team is not expecting to solve all mobile CSS this way? -- [[User:Edokter]] {{talk}} 17:05, 25 March 2016 (UTC)

Let's stop abusing description list markup

Disregard
 – Reporter did not post sufficient details to track the problem down, and now can't remember what they were.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:18, 9 May 2016 (UTC)

I thought we fixed this a long time ago. Looking at the rendered source output, I see that we're still generating semantically bogus description list markup (<dl><dt><dd>...</dd></dt><dl>) just to produce an indent, by way of using : in front of the hatnote. This should be done with CSS like {{Block indent}} does.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:27, 24 March 2016 (UTC)

@SMcCandlish: How are you getting that output? When I try {{hatnote|Foo bar}} in Special:ExpandTemplates I get <div role="note" class="hatnote">Foo bar</div>. — Mr. Stradivarius ♪ talk ♪ 01:42, 25 March 2016 (UTC)
@SMcCandlish: The hatnote templates should all produce acceptable markup, as Mr. Stradivarius mentioned, but many pages unfortunately still use the old :'' garbage to produce hatnotes manually. I can speak for this firsthand as I've done a ton of work searching for and eliminating them. The solution is almost certainly "fix the offending hatnote". {{Nihiltres |talk |edits}} 05:26, 9 May 2016 (UTC)
A) Yay, that this problem is not as widespread as a I feared. B) Damn, I can't remember which hatnote template I was testing that produced the DL markup.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:17, 9 May 2016 (UTC)

Request

I notice my father, Bishop Doc Loomis, is not listed on the template. May we address that, please? Thank you 2606:A000:FD83:3300:9DD5:AAAD:D83D:9EE5 (talk) 15:40, 28 January 2017 (UTC)

  • This template produces a generic navigational element. It has nothing to do with any particular content, and is definitely not the right place for your request. If you describe where you expected to see something, perhaps we can figure out together where your request ought to go. {{Nihiltres |talk |edits}} 15:54, 28 January 2017 (UTC)

Preview warning and hatnotes moving to templatestyles

Page watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles Izno (talk) 23:57, 28 April 2021 (UTC)

"Template:Dabpage" listed at Redirects for discussion

The redirect Template:Dabpage has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 March 14 § Template:Dabpage until a consensus is reached. MClay1 (talk) 12:53, 14 March 2023 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Hatnote/Archive_1&oldid=1229035219"