Help talk:Citation Style 1/Archive 46

It makes no sense to force editors to go through extra hoops to support the first case, but allow the second case.

Any questions of cs1 style or cs2 style seem irrelevant, as this proposal (as In understand it) makes no change to the formatting of a citation, only in the details of the anchor. Being only a default, it would make no difference in any explicit use of |ref=.

I am inclined to support, but perhaps Trappist would enlighten us with why he currently opposes the proposal. ♦ J. Johnson (JJ) (talk) 20:05, 26 July 2018 (UTC)

Nine years ago, editors at {{citation/core}} believed that something was amiss when both cs1 and cs2 templates auto-set |ref=harv. They took the decision that they took in response to that problem. I was not there then, the environment was entirely different then, cs1|2 were in their infancy then. At this time I am not willing to say that they were wrong. For nine years thousands of editors have apparently been content with that long-ago decision.

The CITEREF id is an imperfect identifier because is isn't guaranteed to be unique to a rendered citation (this is why others in the

harv}} and {{sfn

}} templates link to other than their intended targets. Untangling that kind of a mess is akin to figuring out which of several <ref name="same name" /> tags belongs to which definition when you have <ref name="same name">some sort of reference content</ref> but you also have <ref name="same name">reference content of a different sort</ref>. Broken reference links and pissed-off editors are, I think, to be expected.

—Trappist the monk (talk) 00:02, 27 July 2018 (UTC)

This is a chicken and egg problem and a law of laziness. CS2 supports |ref=harv natively, so people who wants to use {{

b

} 00:09, 27 July 2018 (UTC)

I don't see a reason why not to turn |ref=harv on by default for CS1 since it is on for CS2. Imzadi 1979 → 02:46, 27 July 2018 (UTC)

Hmm. I find this argument (Trappist's) to be a compelling one: there is an existing consensus, that has stood for nine(ish) years without a lot of complaints, and the proposed change is imperfect in a technical sense. This is definitely cause for taking the time to consider the issue thoroughly before making any kind of change. So, in that light, let me perpetrate some "reasoning out loud" here…

The main problem being brought up in the original discussion, and part of the reason adduced for hesitation on that implementation here, is the likelyhood of having multiple citations with identical author—date values, which will generate duplicate |ref= values, which in turn will end up as the same id attributes on more than one HTML element. The relevant standards (HTML 3.2 through 4.01, and the DOM spec post-HTML5) all require that the value of id be unique within a document, and the net result is that validation tools like the W3C Markup Validation Service will flag the duplicate id's as errors. Actual implementations (i.e. web browsers; i.e. Chrome, IE, Opera, Safari, JAWS, etc.) will silently ignore the error (and always have), and use the first found id (in DOM order) as the target.

This is because duplicate id attributes are a matter of syntax and is well-contained: it affects nothing but those elements who have duplicate id attributes (unlike unclosed elements, mismatched quote marks, improperly nesting or overlapping elements, etc., which does have run-on effects on document parsing) and it is an error in non-rendered syntax elements, so it is not visible to users. That is: the existence of duplicate id attributes cause no problems in themselves, unless you are specifically using those specific id attributes for something further.

However, those issues are mere symptoms. The actual problem we have exists at the semantic level: we have short citations that are ambigious because they cite author—date and we have multiple works by author on date. You can't (easily) catch this problem with software tools (they're much better at syntax then semantics), but it is the actual root cause problem. This is a problem that requires manual effort to resolve, and as a side effect will resolve the minor syntax errors that were at issue in the original discussion. That is, I conclude that I disagree with the premise of the original discussion: it focussed on the symptom (and an essentially benign one) rather then the underlying problem, and the underlying problem is not affected either way by the proposed remedy.

As a corollary, though I assert we should not worry overmuch about generating duplicate id attributes, they do of course need to be fixed when they occur. But this is best done through tracking categories, bot flagging, and concerted cleanup efforts. The status quo hides the problem by not generating those id attributes.

The other major side of this is impact and failure modes. All changes carry some measure of risk, so let's say we turned on |ref=harv as default today. What's going to happen from the perspective of readers and editors and visible article content (I've addressed the technical syntax issues above)? ← Not a rhetorical question; do please answer it!

• Articles using {{citation}} and articles using explicit |mode=cs2 are unaffected.
• Articles using full cites inline gain id / link targets, but since they're not used the article is unaffected.
• Short cites using {{sfn}} (et al) that were dangling (pointing at full references that do not have |ref= set) will start working.
• Full cites with an explicit |ref= set are unaffected (including |ref=none).
• In articles (using {{sfn}} and full cites in a bibliography and the bibliography has full cites with a mix of those with |ref= set and those without it and there is one such pair (with/without) that has identical author—date information and the one without |ref= occurs before the one with it) the existing link from {{sfn}} to the author—date will begin pointing at the wrong full cite.
  • The {{sfn}} short cites in that article intended for the other full cite (the one without |ref=) were already pointing at the wrong full cite.
  • The absence of the link target for one of the full cites is here hiding a problem: the short cites are ambigious and only happenstance gives the (false) appearance that they are working.
• Citation pairs with {{sfn}} and full references without |ref= can now be checked by user scripts (like HarvErrors) and problems flagged.
• Full references without |ref= for which there is no {{sfn}} pointing at it (i.e. possibly an uncited work that should be removed) can be detected and flagged by user scripts (like HarvErrors).
• Other failures from the change, or from the status quo?

Based on this I see no significant negative impact except in edge cases; that do not simply make visible an existing problem; and that should not be fixed in any case. So my conclusion, unless someone comes up with other issues, is that we definitely should turn on |ref=harv by default. But we should perhaps actively solicit a bot to flag articles where duplicate IDs occur with a tracking category so that they can be fixed (perhaps WP Check Wikipedia might be a good venue for that?). --Xover (talk) 07:56, 27 July 2018 (UTC)

Regarding tracking, I have filed phab:T200517. --Izno (talk) 14:00, 27 July 2018 (UTC)

You are right. That is a lot of words.

• yes, {{citation}} templates and templates using |mode=cs2 are not affected
• yes, articles without short cites are not affected
• perhaps; we cannot know with certainty that previously unconnected short cites will magically connect correctly because we cannot know why the unconnected short cites were not already properly connected
• yes, cs1|2 templates with |ref= set to anything but harv are not affected
• there is no requirement that short cites must link only to cs1|2 templates that are part of a 'bibliography' so any 'new' ID that exists anywhere within the rendered page and that matches a previously existing ID may become the incorrect target of an exiting short cite
  • not really, because after auto-setting |ref=harv, nothing has been clarified; all of the same-ID short cites will point to one cs1|2 template; some of those short cites will link to the correct cs1|2 template, the others will not; we will have exchanged one variant of the problem for another variant of the problem
  • yes, ID ambiguity is the fundamental flaw
• it is not wrong to place cs1|2 templates anywhere within an article; cs1|2 templates are commonly used to list an author's published works and may or may not include full bibliographic detail but because of their position in the article may become incorrect short cite targets if we auto-set |ref=harv

The status quo hides the problem by not generating those id attributes. If the fundamental problem here is the ambiguity of CITEREF IDs, it seems to me that the status quo doesn't 'hide' the problem (nor does it solve the problem) but is doesn't exacerbate the problem by creating more ambiguous targets.

Based on this I see no significant negative impact except in edge cases; that do not simply make visible an existing problem; and that should not be fixed in any case. What? Why should the problem not be fixed? Does your sentence read as you intended it to read?

—Trappist the monk (talk) 14:31, 27 July 2018 (UTC)

That is a lot of words. My apologies. As I wrote: thinking out loud. Does your sentence read as you intended it to read? Sorry. Too many negative clauses. I meant that the errors should be fixed regardless, and that the proposed change would simply make them visible/detectable and thus more likely to be fixed.

However, despite (or because of?) my wordy explication, it seems I've failed to communicate my point correctly. The underlying problem here is not the ambiguity of CITEREF IDs (that's a mere implementation detail). Rather, the real problem is that John Smith wrote two journal articles in 1984 and I've failed to distinguish them. The reason I've failed to do so may be that I've looked at the article's title or other bibliographic detail and thought that was sufficient, or it may be that I added one and another editor added the other, or… Whatever the reason, I've created the problem that when I use parenthetical referencing, citing (Smith 1984, p. 32) is ambigious.

When I change the article to use {{cite journal}} and {{sfn}} this problem becomes detectable because the CITEREF ID generation algorithm is working within the bounds of that referencing style: it exactly replicates the problem that was already there. In other words, generating duplicate CITEREF IDs is correct from a technical point of view; it's failing to distinguish between Smith's two 1984 articles (1984a and 1984b) that is the problem, and it's caused by the human editors failing to correctly implement the author—date (wetware) algorithm.

However, I hadn't considered non-reference uses of cs1|2 templates, possibly because I routinely use |ref=none for these for other reasons (see thread above). It's certainly a complicating factor, and a significant negative impact of the proposed change. Not sure I'm persuaded that it's a big enough negative impact that it makes the total tradeoff untenable, but it certainly adds weight to that side of the equation. --Xover (talk) 15:53, 27 July 2018 (UTC)

Addendum: On further reflection I am convinced that the impact of non-reference uses of cs1|2 templates if |ref=harv was made the default is sufficiently large that this question isn't something we should decide with a local consensus here. (That's in addition to the other negative effects that I consider relatively lesser drawbacks.) It affects a large number of articles, and in a way that is likely to lead to "angry editors with pitchforks" scenarios. I am still of the opinion that |ref=harv should be the default, but I now think getting there will take a community-wide RfC; and one that is properly cast so that it will stick, with a minimum of drama, and as few hurt feelings as possible. But throwing a proposal here and drafting a site-wide RfC are different ballgames, and I wouldn't want to embark on the latter solo. Are the other editors who participated in this thread interested / willing to help out drafting an RfC for this? Trappist the monk: would you still be opposed to this if it has support from a community-wide RfC? I mean, this change would definitely have associated breakage, and an RfC wouldn't prevent that (it just prevents the pitchforks when stuff does break). I consider the breakage a reasonable tradeoff and the associated (manual, mostly) cleanup surmountable, but it's a point on which one may easily disagree, and I wouldn't want an RfC to act as a "trump card" in that discussion. --Xover (talk) 06:40, 28 July 2018 (UTC)

[W]ould you still be opposed to this if it has support from a community-wide RfC? You ask that question as if I have some sort of veto power here. My position with regard to any RFC outcome is irrelevant. So what if I oppose or support, when the community have spoken, the community have spoken.

—Trappist the monk (talk) 19:32, 28 July 2018 (UTC)

Well, no, but I'm asking whether the existence of a supportive outcome from a community RfC would affect your position on the change? I got the impression, perhaps erroneously, that your opposition was in part founded on the risk of a "angry editors with pitchforks" scenario occurring. If the change is backed by RfC, that would significantly alleviate this concern, and so perhaps also your stance on the proposed change? --Xover (talk) 06:21, 29 July 2018 (UTC)

My comment about pissed-off editors is simply idle speculation about a possible future and is not an armature upon which I hang my opinion. Broken reference links is the point of that sentence. I am more concerned about this change suddenly breaking some number of articles that worked correctly before the change because we will have exchanged one form of 'broken' for another form of 'broken' and all because CITEREF IDs cannot be automagically truly unique to each cs1|2 template and its paired short refs.

—Trappist the monk (talk) 11:16, 29 July 2018 (UTC)

• Support. I started out using CS2, did a lot of Harvard referencing, and didn't have to think about ref=harv. I loaded the HarvErrors script a long time ago. Overtime, I've edited many articles using the more common CS1 templates, and now I use CS1 by default, but I don't take any side on the commas or periods debate. Even articles using CS1 templates will use plain text Harvard referencing, so I"ve inserted many {{
  harvnb}} and |ref=harv to make the linkage. And I've played the 1981abc game. I've also turned off the implicit CS2 |ref=harv in many Further reading sections. So it's been use |harv= one way for CS1 and the opposite way for CS2.

  I support Izno's analysis. If an article has ambiguous references, it would be good to discover that problem and fix it. It will have a down side for me because the HarvErrors script will raise more red flags, but that might be a good thing in the long run. Glrx (talk
  ) 19:35, 27 July 2018 (UTC)
• Support. Just to be clear. ♦ J. Johnson (JJ) (talk) 22:43, 5 August 2018 (UTC)
• Support. An instance of this discussion just broke out independently in Template talk:Cite EB1911 ({{Cite EB1911}} uses CS1) because Gog the Mild noticed that its interaction with {{sfn}} results in the second click not jumping to the citation itself. You'd have to add "ref=harv" to a use of this template, unlike {{EB1911}} which provides a default (that template is intended to attribute a verbatim from a PD source and uses CS1). I guess it would help if we had noted that in the template's doc. PBS pointed out that this {{PD source}} versus {{Cite PD source}} pattern has many instances, and they would all have to be changed for consistency, which is why I like this top-down approach. Anyway, a few more points:
  • I dispute that editors "have...been content" with this (mis)behavior of dangling sfn-type links (which, again, require two clicks to show the error, which itself is a mere absence of behavior). It's a subtle thing to test when you edit a page, easily missed.
  • Instances of same-author, same-year are quite rare, and in the cases I have seen editors have already handled it with the a/b suffix.
  • I don't see the problem with generating an unused citation link target. It isn't an error not to link to it. The {{Cite source}} family are often used in ==Further reading== or ==External links==.
  • Just to take the {{Cite EB1911}} template as an example, there are about 430 articles that should have ref=harv and don't, probably because editors (OK, mostly me) were never aware of the issue. I'd be happy for a top-down fix, because spending time on such a subtle error is about #2,319 on my priority list. David Brooks (talk) 16:58, 15 August 2018 (UTC)
• @David Brooks Just a note on your bullet point "**I don't see..." If you place "importScript('User:Ucucha/HarvErrors.js');" into "user:/DavidBrooks/common.js file" you will see the errors. -- PBS (talk) 10:55, 16 August 2018 (UTC)
• I Support this change, (indeed I would support changing all the common CS1 templates to {{citation|mode=CS1}}). So given the snow here I suggest that someone implements a RfC in an appropriate place (eg Wikipedia:Village pump (proposals)). If it is done please inform the people who have taken part in this debate. As an aside: if this proposal is implemented a bot script will need to be run to add ref=none to all instances where CS1 templates are used in in ==Further reading== or ==External links== to remove cases of false positives. Also depending on how wrapper scripts around CS1 templates are written this may have an affect on some scripts. -- PBS (talk) 10:55, 16 August 2018 (UTC)

  @PBS: Unless I misunderstand the intent, I think you suggest adding ref=none only if there are no actual references (sfn, harv) elsewhere in the body. Also, the section name is a semantic issue, not syntactic. I think past editors have been pretty promiscuous about where to stick these full citation templates. There are also some nonstandard section titles that should probably also be addressed. David Brooks (talk) 13:24, 16 August 2018 (UTC)

  "Further reading" and "External links" are specifically for non-referenced sources (

  harv}} type templates in the article. -- PBS (talk

  ) 13:36, 16 August 2018 (UTC)

  Spamming |ref=none serves pretty much no purpose (does |ref=none even have a use?) and would never fly. And it runs pretty much counter to why we'd want |ref=harv to be default in the first place.

  b

  } 13:29, 16 August 2018 (UTC)

  On the one hand, editors who have incorporated User:Ucucha/HarvErrors.js into their javascript page in order to make citation errors more obvious might want to have full citations that are not intended to be the target of short citations to not show a warning; I haven't tested to see if |ref=none will accomplish this.

  On the other hand, if there were a full citation in the "Further reading section" with |ref=none, and an editor decided to move it to the "Works cited" section and cite it, it wouldn't work until the editor realized the |ref=none needed to be removed. Jc3s5h (talk) 13:38, 16 August 2018 (UTC)

  I use this all the time with {{Citation}} in "Further reading" sections. If this change is made to the template core, and if the parameter is not added, then there are possibilities of breaking citation links in articles becomes a possibility. For example if a book in a "Further reading" section happens to have the same author and date as one used in the "References" section ... . -- PBS (talk) 13:48, 16 August 2018 (UTC)

  Editor PBS wrote: I would support changing all the common CS1 templates to {{citation|mode=CS1}}. Explain that please?

  —Trappist the monk (talk) 13:56, 16 August 2018 (UTC)

  I fail to see why we have {{cite book}} {{cite web}} etc when we could simply have one wrapper around all the same core used for all such citations, and we already have {{citation}} to do that job. AFAICT apart from the handling of ref=harv (which this section is discussing changing) the only difference is the formatting between the parameters which is handled by the mode parameter. eg:

  • (1a cite book) Smith, Fred. The Blue Book. London: Cheesecake.
  • (2a citation with mode=CS1) Smith, Fred. The Blue Book. London: Cheesecake.
  • (1b cite book with mode=CS2) Smith, Fred, The Blue Book, London: Cheesecake
  • (2b citation) Smith, Fred, The Blue Book, London: Cheesecake

  Having only one template would simplify the documentation and also simplify it conceptually for editors new to using citation templates. For example deciding if a book on the internet should be referenced by using {{cite book}} or {{cite web}} would go away, as they would just select the parameters that best describes the citation (as is done now with {{citation}}). -PBS (talk) 18:41, 16 August 2018 (UTC)

Because different types of citations need to be handled differently, and presenting strong and recognizable "default" parameters names matter. What should you use to cite a book in {{

b

} 19:01, 16 August 2018 (UTC)

This is going off topic so I have moved my answer down to a more appropriate section. -- PBS (talk)

Template styles has been enabled on en.wiki so I've begun experimenting with it. I have created Module:Citation/CS1/style.css and added rules that apply the access indicator icons in place to the normal external link icon. The distinct advantage to this is that the wrapping issue that has plagued us (url on one line and the icon on the next) is solved.

We should think about this and spend some time getting the rules right. I don't know how many other wikis have template styles. If only a few have it, then perhaps we should not use this here because these modules are used on a lot of other wikis.

—Trappist the monk (talk) 12:13, 20 July 2018 (UTC)

Apparently, TemplateStyles will be enabled on all wikis 9 August 2018; see phab:T199909.

—Trappist the monk (talk) 11:35, 21 July 2018 (UTC)

I saw the edits made to the module sandboxes today. I have some light feedback:

1. In keeping with the naming convention at WP:TemplateStyles, recommend moving the page to use "styles.css" rather than "style.css". (Aside: I have submitted a task for allowing creation of stylesheets in the module namespace.)
2. Load the CSS using Lua rather than adding a TemplateStyles invocation at each page. Per my discussion with Anomie on phabricator, that would require frame:extensionTag. There is some other code there that Anomie provided for a helper function.

--Izno (talk) 16:13, 1 August 2018 (UTC)

/style.css moved to Module:Citation/CS1/styles.css. We should probably create a sandbox version of that file so that we can play around with it and not disturb the citation rendering in article space. Alas, we can't follow the convention of Module:Citation/CS1/styles.css/sandbox so I propose that we should use Module:Citation/CS1/styles-sandbox.css.

I have implemented the frame:extensionTag in Module:Citation/CS1/sandbox and removed the <templatestyles /> tag from {{cite book/new}}.

—Trappist the monk (talk) 12:16, 3 August 2018 (UTC)

@Trappist the monk: There is a current discussion regarding sandbox naming at WT:TemplateStyles#Sandbox naming convention to which you may be interested in contributing. --Izno (talk) 12:21, 3 August 2018 (UTC)

I have modified Module:Citation/CS1/sandbox so that is uses Module:Citation/CS1/sandbox/styles.css, newly created. Module:Citation/CS1/styles.css is now protected in keeping with the protection level of the live cs1|2 modules (even though, at the moment, the live modules do not use templatestyles).

—Trappist the monk (talk) 16:18, 17 August 2018 (UTC)

Headbomb hides the a.external arrow

Moved from User talk:Trappist the monk § CSS for citation templates

Could you have a way of having those icons display if we suppress external link icons normally? I can only see them if I disable this. Maybe this could be done via a different class, like external-access, or some other way that would let us suppress the normal external link icons, but keep the access ones?

I am not a css expert so I don't know if what you want can be accomplished. I don't even know if the rules in Module:Citation/CS1/style.css are properly formed. As I understand it, rules marked by !important override any other applicable rules regardless of when those rules occur.

The rendered html for the title link of this template:

{{cite book/new |title=Title |url=//example.com |url-access=subscription}} → Title.

looks like this:

<span class="cs1_lock_subscription"><a rel="nofollow" class="external text" href="//example.com"><i>Title</i></a></span>

Your rule:

a.external { background:none !important; padding:0 !important;}

unconditionally overrides the template style css because !important. I don't know where class external is defined (it isn't in MediaWiki:Common.css) perhaps it is possible to override something there?

When your rule is enabled, do you see the pdf icon here: [1]

—Trappist the monk (talk) 12:13, 20 July 2018 (UTC)

Nope, PDF icon is hidden, and that's the way I like it, since it's redundant with (PDF) that's automatically appended.

b

} 20:22, 20 July 2018 (UTC)

Avoid the use of important. It basically defeats the purpose of Template Styles. As for external, that class is applied by MediaWiki core to any external link (when not provided for by an inter-site link like [[example:example]]--I am not sure what class those links get). --Izno (talk) 14:51, 20 July 2018 (UTC)

Indeed, !important is a cop-out - usually it's better to increase the specificity of the selector. Imagine if all rules used !important and you needed to override one - there are no levels of importance, nothing that is treated as "more important than !important". --Redrose64 🌹 (talk) 18:39, 20 July 2018 (UTC)

Well !important works. You're free to suggest alternatives that also work, because I have no idea what "increasing the specificity" means, or would look like.

b

} 20:22, 20 July 2018 (UTC)

In a rule like

a.external {
  background: none !important;
  padding: 0 !important;
}

the part before the opening brace is the selector. A selector like a matches all <a>...</a> elements; a selector like .external matches all elements belonging to the class external, and the selector a.external matches all <a>...</a> elements belonging to the class external. Since this third one matches on two conditions which must both succeed, this is more specific than either of the selectors a or .external used alone. See Calculating a selector's specificity. The !important annotation artificially boosts the specificity in a manner that is difficult to override. See Cascading. --Redrose64 🌹 (talk) 22:41, 20 July 2018 (UTC)

Seems like this is pretty much what [2] this rule was. Specifically matching a.external. What I'm asking for here is a way of not matching the access locks, while still matching the other useless icons. If !important gets in the way of that, it's easy enough to remove I suppose, but that still leaves the problem of matching (or not matching) the locks. 03:12, 21 July 2018 (UTC)

Perhaps someone with a better grasp of the intricacies of css can see how this sort of works and can tweak it so that it does:

a.external:not(.cs1_lock_free) {
  background: none;
/*  padding: 0;
*/
}

For me, and my browser, the above hid the normal external link icon but showed all of the access icons; I would have expected only the green access icon to be displayed. Without padding: 0;, there is a significant gap between the link and the next text character where the default external link icon would be were it displayed. If background: none; why the space? If I uncommented padding: 0;, the lock icons moved left to overlap the text. Text adjacent to the blank external link icon also moved left to fill the blank space so that the text renders nicely.

—Trappist the monk (talk) 12:21, 21 July 2018 (UTC)

@

b

} 14:21, 21 July 2018 (UTC)

The

a.external:not(.cs1_lock_free)

was an experiment. I expected that the only visible icon would be the green; all others I expected to be hidden. That expectation was not met because, for me, only the normal external link icon was hidden; subscription and free icons were displayed.

—Trappist the monk (talk) 14:52, 21 July 2018 (UTC)

@

b

} 16:17, 1 August 2018 (UTC)

I do not. I haven't given the problem any significant thought though. I don't really understand who it is you are trying to do this thing for or why that should matter to all of us. :) --Izno (talk) 16:39, 1 August 2018 (UTC)

@

b

} 17:02, 1 August 2018 (UTC)

I'm actually a bit surprised that the above CSS works to hide any of these since the class cs1_lock_free is not on the a element but on a surrounding span. So in that regard, I think the CSS is wrong. You probably want span:not(.cs1_lock_free)/* add other not selectors here by appending more :not(selector) */ a.external {background: none;}. Give that a try. --Izno (talk) 14:01, 5 August 2018 (UTC)

@

Actually, it hides the red+blue/grey locks (green is visible) of the sandbox. So that's sort of progress, but in the opposite direction. I want those displayed (red+grey+green), and the rest hidden.

b

} 17:27, 5 August 2018 (UTC)

Read and review the CSS comment I left. See MDN where they chain the nots together. --Izno (talk) 17:59, 5 August 2018 (UTC)

I can chain the nots, but that still won't hide the things I want it to hide: the external link icons that are not the access locks.

b

} 18:26, 5 August 2018 (UTC)

I can't see another way to deal with it then besides duplicating the locks CSS into your skin's CSS page of choice and placing it after the line which removes the arrows. --Izno (talk) 18:53, 5 August 2018 (UTC)

Alternatively, I don't see why you can't use Ttm's CSS directly. Even if it doesn't work as he expects, that will also take care of the issue if the behavior in your browser is the same as his. --Izno (talk) 18:55, 5 August 2018 (UTC)

Because that TtM's CSS doesn't hide the external links icons.

b

} 19:01, 5 August 2018 (UTC)

Switching gears, how about some sort of CSS logic that instead of being written with a sort of "if not (css_class), hide icons" logic, it would be written with a "hide all icons, but if (css_class), display them" logic instead?

Alternatively, I'd be fine with "duplicating the locks CSS into your skin's CSS page of choice and placing it after the line which removes the arrows.", but I don't know how to do that.

b

} 19:03, 5 August 2018 (UTC)

You just copy and paste the block of CSS for the locks into your CSS page anywhere after the bit of CSS that sets a.external {display:none}. This way, of course, you can also change the image of interest. --Izno (talk) 19:55, 5 August 2018 (UTC)

"copy and paste the block of CSS for the locks into your CSS page anywhere after the bit of CSS that sets a.external {display:none}", again, I don't know how to do that. I don't even know where to find that CSS, it's a LUA mess.

b

} 19:58, 5 August 2018 (UTC)

The styles page should probably be added to the main documentation; you can find it at Module:Citation/CS1/styles.css. --Izno (talk) 20:32, 5 August 2018 (UTC)

While the page parameter is referenced in the documentation for {{cite speech}}, it doesn't appear to be working for me.

Milbank, Alison (2017). Subversive Orthodoxy (docx) (Speech). Liverpool: Diocese of Liverpool. Retrieved 14 June 2018.

{{cite speech |last=Milbank |first=Alison |author-link=Alison Milbank |year=2017 |title=Subversive Orthodoxy |url=http://www.liverpool.anglican.org/userfiles/files/Events/2017/Subversive%20Orthodoxy%20-%20Alison%20Milbank.docx |format=docx |location=Liverpool |publisher=Diocese of Liverpool |page=2 |access-date=14 June 2018}}

Am I doing something wrong here? 142.160.89.97 (talk) 06:25, 18 August 2018 (UTC)

I don't think so. In November 2015 we limited the use of |volume=, |issue=, and |page(s)=; {{

Wikipedia:PUBLISHED

) so one cannot attend a speech presentation and then cite that presentation because the words have disappeared in the instant that they were spoken and cannot be recovered. But, you can cite the proceedings of the event if the speech is included in those proceedings. The proceedings will likely have page numbers. No one contradicted that guess so it remains as I first specified it.

For this "Subversive Orthodoxy", apparently a talk given at a conference, two options appear to me. One is to switch to {{cite conference}} perhaps like this:

{{cite conference |last=Milbank |first=Alison |author-link=Alison Milbank |date=20 May 2017 |title=Subversive Orthodoxy |url=http://www.liverpool.anglican.org/userfiles/files/Events/2017/Subversive%20Orthodoxy%20-%20Alison%20Milbank.docx |format=DOCX |conference=Ken Leech Conference |location=Liverpool |publisher=Diocese of Liverpool |page=2 |access-date=14 June 2018}}

Milbank, Alison (20 May 2017). Subversive Orthodoxy (DOCX). Ken Leech Conference. Liverpool: Diocese of Liverpool. p. 2. Retrieved 14 June 2018.

The other, because the talk is hosted on a website, is to use {{cite web}}:

{{cite web |last=Milbank |first=Alison |author-link=Alison Milbank |year=2017 |title=Subversive Orthodoxy |url=http://www.liverpool.anglican.org/userfiles/files/Events/2017/Subversive%20Orthodoxy%20-%20Alison%20Milbank.docx |format=DOCX |website=The Diocese of Liverpool |page=2 |access-date=14 June 2018}}

Milbank, Alison (2017). "Subversive Orthodoxy" (DOCX). The Diocese of Liverpool. p. 2. Retrieved 14 June 2018.

Pedantically, one might argue that {{cite web}} is the best choice here because a speech is a minor work (

MOS:NOITALIC

).

—Trappist the monk (talk) 11:24, 18 August 2018 (UTC)