Template talk:Tag

Category link[edit]

Resolved

– Fixed.

This protected page has been detected in [[Category:Wikipedia formatting templates]], but that category has been redirected to [[Category:Wikipedia formatting and function templates]]. Please update the category link. --RussBot (talk) 13:10, 27 August 2008 (UTC)[reply]

Done Harryboyles 17:14, 27 August 2008 (UTC)[reply]

ref group=[edit]

Resolved

– Fixed.

I don't think the last example actually works. It simply throws an error:

Unknown extension tag "ref group=note"

--Subversive Sound (talk) 21:21, 27 January 2010 (UTC)[reply]

<ref group=note> seems to be working. ---— Gadget850 (Ed) ^talk 00:36, 28 January 2010 (UTC)[reply]

Re-use of same reference[edit]

Resolved

– Wrong venue.

Hello, how do you input the same instance of tag#ref?

I.e. so it'll look like: "The cat was in a hat.[1] Also the hat was on the cat.[1]"

As it is now it justs auto-updates numbering so it's [1] and [2] with same content.

Cheers!Sandman888 (talk) 19:28, 29 April 2010 (UTC)[reply]

The #tag magic word has no relationship to this tag template. #tag:ref should be used only where you need to include <ref>...</ref> tags inside a reference. The syntax is {{#tag:ref|content|name="name"|group="groupname"}} where the optional name and groupname must come after the content. ---— Gadget850 (Ed) ^talk 23:36, 29 April 2010 (UTC)[reply]

Attributes in closing tag[edit]

Resolved

– This is in the documentation now.

Attributes used in the opening tag are placed in the closed tag. This is an error, or how should it be tagged?

<ref group=note>foo</ref group=note>

Douglaspaulwade (talk) 14:31, 30 June 2010 (UTC)[reply]

You need to use |params= to include text in the open tag that is not included in the close tag:

{{tag|ref|params=group=note|content=foo}}

<ref group=note>foo</ref>

---— Gadget850 (Ed) ^talk 14:56, 30 June 2010 (UTC)use[reply]

One redundant space[edit]

Resolved

– Answered (not redundant, mandatory).

Why

{{tag|references|single}} → <references />

and not

{{tag|references|single}} → <references/>

like here? --79.118.40.95 (talk) 15:33, 22 March 2011 (UTC)[reply]

HTML elements with no content are called empty elements. The space is required per specifactions.[1][2] ---— Gadget850 (Ed) ^talk 17:11, 22 March 2011 (UTC)[reply]

Unresolved

– New information

Gadget850 The space is no longer required, and may never have been, since <ref/> is a function of MediaWiki, not HTML or XTML. Finally got a definitive answer on this at Help talk:List-defined references#Formatting question. Would it be possible to remove the extra space from this template so the documentation isn't instructing editors to use an unnecessary space? It all adds up. Thanks!

—D'Ranged 1 VT^alk 00:43, 24 February 2016 (UTC)[reply]

@D'Ranged 1: The {{tag}} template is not just used for demonstrating <references /> and <ref name="refname" /> (which are MediaWiki extensions, and where the space is definitely optional), but is also used for demonstrating markup in HTML, XHTML, XML, SVG and several related markup languages. In some of these the space is mandatory. --Redrose64 (talk) 11:24, 24 February 2016 (UTC)[reply]

@Redrose64: Is it possible that you could alter the template so that the space in question is a non-breaking space ( )? On mobile, where paragraphs of text are wrapped a lot more, the tags with spaces can sometimes wrap around due to the space. It's insignificant but it can be confusing when the /> is dangling on the next line. OlliverWithDoubleL (talk) 09:38, 30 July 2022 (UTC)[reply]

No, because the template is usually used for example code. People sometimes mark-and-copy the tag(s), and if they copied a nbsp they would then paste invalid markup. As far as HTML, XHTML and the others that I mentioned are concerned, newlines count as whitespace but nbsps do not. --Redrose64 🌹 (talk) 21:47, 30 July 2022 (UTC)[reply]

Intuitiveness problem[edit]

One of the most common styles for referring to [X]HTML mark-up is ... (I'm using "..." as a literal string here). It's certainly more common than , and it should be easy to do, instead of requiring long-winded input like {{tag|span|content=...}}. By extending the switch, we should be able to have it default to assuming that any second parameter that does not match one of the pre-defined values is actually content, unless |content= is explicitly specified. After this fix, {{tag|span|...}} would produce .... Better yet, not only fix that (it would make it easier to do things like {{tag|span|{{var|text here}}}} to produce text here), but make the default display be the ... version, and have the odd  version be something manually obtained with a new value, |2=empty, along with the open, closed, etc. values. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 20:29, 19 June 2011 (UTC)[reply]

Asuming that the second parameter is content requires a lot of contitional coding, so I don't see that happening. Having said that, showing ... is easy if a pair has no content. If that is the established convention, I'll just add it. — Edokter (talk) — 22:59, 19 June 2011 (UTC)[reply]

That would be very helpful. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:49, 13 August 2014 (UTC)[reply]

Style[edit]

Moved to Template talk:Para § Site-wide solution

With the style change to <code>, I propose to with to switch to <kbd>. The box is just too much. -- Gadget850^talk 15:34, 10 August 2014 (UTC)[reply]

But semantically, its output is code. -- [[User:Edokter]] {{talk}} 18:56, 10 August 2014 (UTC)[reply]

But it is keyboard code, not output. -- Gadget850^talk 19:55, 10 August 2014 (UTC)[reply]

I ment the template's output; the HTML is code. -- [[User:Edokter]] {{talk}} 20:32, 10 August 2014 (UTC)[reply]

I give up. I overrode the style in my CSS. Help:HTML in wikitext will just have to look horrible to everyone else. -- Gadget850^talk 01:04, 11 August 2014 (UTC)[reply]

It's not that bad, and we didn't have a mass-complaint campaign. -- [[User:Edokter]] {{talk}} 08:52, 11 August 2014 (UTC)[reply]

This is wrong; we don't abandon use of the correct markup (<code>...</code>) to get around a style issue; just fix it with CSS. The <kbd>...</kbd> element is for examples of user input (i.e. the values of parameters, and only when we're giving literal examples, not variables, for which use <var>...</var>), not the parameter= code! It's semantically incorrect to use kbd this way. See Jonesey95's CSS fixes at the essentially duplicate discussions at Help talk:Citation style 1 and Template talk:Para. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:52, 13 August 2014 (UTC)[reply]

Resolved

Fixed for me in personal CSS. -- Gadget850^talk 12:58, 13 August 2014 (UTC)[reply]

@SMcCandlish: Not Jonesey95's CSS fix - mine. See Wikipedia:Village pump (technical)/Archive 129#Displaying 'code' font text and search for "inherit". --Redrose64 (talk) 15:20, 13 August 2014 (UTC)[reply]

@Redrose64: Answered at Help talk:Citation Style 1/Archive 5#Restore error message style.

@Gadget850: Re: "Resolved" – Fair enough for your part, but proposals to make semantic-HTML-breaking changes have continued at Template talk:Para. <sigh> — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 19:21, 13 August 2014 (UTC)[reply]

Let's consolidate this discussion at Template talk:Para#Site-wide solution. Having it forked like this is pointless and already leading to conflicting proposals. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 19:21, 13 August 2014 (UTC)[reply]

Changes[edit]

@Sardanaphalus and Edokter: Would y'all please work this out in the sandbox and talk page. I can't follow the issues from edit summaries. -- Gadget850^talk 21:32, 14 December 2014 (UTC)[reply]

I try to, but if others don't, I can't either. -- [[User:Edokter]] {{talk}} 22:38, 14 December 2014 (UTC)[reply]

How about we revert back to the last stable version, give it a full-prot and discuss? I see nothing above that proposes, let alone supports, any of the recent changes. --Redrose64 (talk) 10:48, 15 December 2014 (UTC)[reply]

I agree, this should have been discussed first. -- [[User:Edokter]] {{talk}} 12:16, 15 December 2014 (UTC)[reply]

Name tag[edit]

Is it possible to add a name parameter (like with <ref name="refname">....) if multiple targets on a page needs the same tag. Thanks, Sander.v.Ginkel ^{(Je suis Charlie)} 12:12, 5 March 2015 (UTC)[reply]

You can use |params= for that. See the documentation. -- [[User:Edokter]] {{talk}} 12:23, 5 March 2015 (UTC)[reply]

Template edit request[edit]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Could somebody add another parameter which is similar to |single / |s but does not include a space before the slash?

Example

{{tag|references|s2}} → <references/>
―PapíDimmi (talk | contribs) 17:21, 17 May 2017 (UTC)[reply]

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. This doesn't seem to add any value to the template, TBH. This template is for demonstration of a tag, not to provide a user any which way to display trivial whitespace. Izno (talk) 21:01, 17 May 2017 (UTC)[reply]

Closing tag broken[edit]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Closing tags aren't displayed. For example {{tag|b|c}} results in: . This is also evidenced in the the documentation. Anon126 (notify me of responses! / talk / contribs) 00:41, 6 August 2017 (UTC)[reply]

Done – Train2104 (t • c) 01:04, 6 August 2017 (UTC)[reply]

Template-protected edit request on 29 June 2018[edit]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I have worked on the coding for this template to modify the rendering for the HTML hidden comment which currently renders as  seeming odd without white space on each side of the comment; the normal appearance when that markup is in use. The hidden comments above and below this request (as seen when editing the page) demonstrates hiding text with HTML comment tags and the white space mentioned here is easily observable from the markup in use.

The modified coding causes the hidden comment example to render instead as ; consistent with the markup's standard appearance normal to its use. All of the other {{tag}} examples are unaffected by the code modifications associated with this edit request, and they remain unchanged under the modified coding.

The template's documentation uses 14 examples to encompass its functionality. All 14 are listed on Template:Tag/testcases along with the same examples rendering from the modified coding, as drawn from Template:Tag/sandbox. The comparisons demonstrate the new code's fitness for its requested use herein.

To effect this edit request, I am asking for Template:Tag to be completely blanked, and for its content to be replaced by the complete coding that is in the sandbox by this edit. Thank you. --John Cline (talk) 01:30, 30 June 2018 (UTC)[reply]

I have set |answered= to yes; placing this request on hold. There are other aspects of this change that require testing I have yet to do. I will request this edit anew if and when these additional tests are successfully logged. Thank you.--John Cline (talk) 03:18, 2 July 2018 (UTC)[reply]

Redundant space (again)[edit]

Though the space often used in void element tags (i.e.,  ) may have been the proper usage in the past, MediaWiki now seems to convert said usage to  . (You can see this by opening the page source of any Wikipedia article containing a  .) So, now that the space is actually redundant (unlike the last time this was brought up), can we get rid of it? Mr. Starfleet Command (talk • contributions) 13:14, 23 March 2024 (UTC)[reply]

@Mr. Starfleet Command: I refer you to my post of 11:24, 24 February 2016 (UTC): The {{tag}} template is ... also used for demonstrating markup in HTML, XHTML, XML, SVG and several related markup languages. In some of these the space is mandatory. --Redrose64 🌹 (talk) 14:24, 23 March 2024 (UTC)[reply]

@Redrose64: Fair enough. However, there are some instances where this template needs to give a result without the space, such as at H:BR, which currently tells us that "All of them [ , , , ] are converted to   in the HTML that browsers read." This is incorrect, as they are actually converted into  . Do you recommend editing that page to manually declare  , or should an option be added to this template allowing for the removal of the space? Mr. Starfleet Command (talk • contributions) 14:44, 23 March 2024 (UTC)[reply]

Always give examples when you state that such-and-such happens. I've tried viewing the source for Iffley Halt railway station, using the Ctrl+U feature of Firefox. In that, I see three br tags with a space, and none without. So I don't see a need for any change to this template. I would also refer you to the post of 21:01, 17 May 2017 (UTC) by Izno (talk · contribs). --Redrose64 🌹 (talk) 17:52, 23 March 2024 (UTC)[reply]

Here is some brs of each form:

 : A
B

 : A
B

 : A
B

 : A
B

Interestingly, in Firefox source view (Ctrl + U), these all get normalized to  ; when viewing in Firefox console (F12) they all get normalized as  . I think the source view is what MediaWiki is generating and the console is just the 'prettified' version because developers prefer to think in HTML 5 and not in XHTML.

That would seem to suggest that some browsers are doing different things with their display, possibly. One would need to investigate the code path in MediaWiki directly or pull out the good old Wireshark. Izno (talk) 18:09, 23 March 2024 (UTC)[reply]

@Izno and Redrose64: On Chrome, the tags are normalized to   in the page source, while they become   in the console. Given the info you have both provided, it seems that MediaWiki converts the tags slightly differently on different browsers (with the space on Firefox, without it on Chrome). In the end, the browsers both seem to convert it to  , which is why that displays in the console.

So the accurate statement for H:BR would be, "The MediaWiki software uses any of them for a single forced line break, converting them to   or  , depending on which browser is being used." The question at hand is how to achieve this. Should we simply use <code><nowiki> </nowiki></code>, or should we add that functionality to this template? I support the latter, as it simplifies the process and would make it easier to illustrate these differences on other pages.

Do you have an opinion on the matter, Izno? Mr. Starfleet Command (talk • contributions) 18:37, 23 March 2024 (UTC)[reply]

No, we can say pretty certainly say that MediaWiki is not varying the output HTML based on browser just for the br tag (otherwise the caches would double). Something in the browsers is being funky, so someone should consult the MediaWiki source to verify what it's actually being output as.

Either way, you do not need to use this template for arbitrary tags. I have demonstrated two ways in the response above (nowiki, as well as character escape) that suffice for a particular page if this template does not provide the precision necessary. Izno (talk) 19:01, 23 March 2024 (UTC)[reply]

OK, my mistake on the first point. (Incidentally, how would one "consult the MediaWiki source"?)

And yes, I know we don't need to use this template. That's why I gave two options: update the template, or do it manually, i.e. use <code><nowiki> </nowiki></code>. I didn't say the former was the only way, just more clean-looking on pages where the   version is needed. But I'm happy to go along with whatever you think would be the better option. Mr. Starfleet Command (talk • contributions) 19:12, 23 March 2024 (UTC)[reply]

You would use a command-line utility such as wget to retrieve the page to your device, this performs no client-side processing so what you get back is the HTML source exactly as it is served. Then you would use a plain text editor like vi or WordPad to examine its contents, search for <br and look at the next few characters. Unfortunately I can't do this myself: my copy of wget is from about 2009 and won't retrieve pages from servers that require https: - it's not worked for WMF-hosted sites for four or five years now. --Redrose64 🌹 (talk) 21:00, 23 March 2024 (UTC)[reply]

The source for MediaWiki can be found at Wikimedia Gerrit. I'd personally start from Parser.php. Izno (talk) 21:56, 23 March 2024 (UTC)[reply]

@Izno: Forgive my ignorance, but how do I get to Parser.php from the link you provided? :( Mr. Starfleet Command (talk • contributions) 22:25, 23 March 2024 (UTC)[reply]