Yeah, if people at particular projects (and non-WMF sites using this stuff) really insist on excessively decorating block quotations and badly visually confusing them will pull quotes, which are a different kind of thing, then they can engage in that folly with local CSS that doesn't pollute other projects.

I guess that would explain why I get the "Your institution does not have access" error here:

• https://www-jstor-org.wikipedialibrary.idm.oclc.org/stable/30007350
• https://www-jstor-org.wikipedialibrary.idm.oclc.org/stable/25510432

Both are from Irish journals.

While we're on this topic, people really, really, really need to stop doing |publisher=YouTube. Unless you're citing something like YouTube's own terms-of-use policy (something actually published by YouTube), it's |via=YouTube, and the |publisher= (if not omitted as often completely redundant with the name of the channel, which belongs in |work=, with the specific video title in |title=) must be the name of the entity that editorially controls and originated the content. YouTube is just a conduit/platform/carrier. Doing |publisher=YouTube is like saying that your mobile service provider owns and originated and has editorial control over your phone conversations with your sister.

This paper looks to be working for me.

Yeah, the book link above worked for me, but this paper I've been trying to get for ages still does not: https://academic-oup-com.wikipedialibrary.idm.oclc.org/jiplp/article-abstract/13/11/878/5075860?redirectedFrom=fulltext

In T49544#7198673, @Inductiveload wrote:

This means that it is very difficult to make $3 a div, and also have it share a line with the mw-cite-backlink element robustly (it can work with display:inline; but not if the reference begins with something like <p>.

So you often see the backlinks on their own lines.

Some additional bits:

I would also add that this lame "bar-quote" stuff is a blog style that is no longer even popular on blogs. I recently went through a bunch of tutorials on customizing block- and pull-quote formatting, in various blogging platforms (WordPress, etc.), and virtually none of them recommend this style any longer, and many of them did not even illustrate it at all. So, you've clumsily forced a dead style from about 2005 on everyone, for no reason, on top of not having any concern for local wikis' own style guides. Outside of special circumstances like trying to make a fully functional mobile skin for small-screen, no-mouse devices, there is absolutely no reason for WMF's MW devs to be "pre-styling" any element in invasive ways that diverge sharply from WHATWG- and W3C-recommended defaults. Combine the KISS Principle and the Principle of Least Astonishment when it comes to such things. We may not care much when it comes to MW's own navigational/operational interface elements, but when you start imposing strange effects in the content you're very likely making a mistake.

Vector's display is proper. We've had years of discussions at en.wikipedia about this stuff, and consensus has resolved repeatedly to do what major, mainstream publishers do, which is standard block quotations: same typeface, same size, indented a bit on both sides. No italics, no big font, no little font, no different font, no colored backgrounds or bars, no giant quotation marks. The last RfC on this forced all the "decorative" quotation templates (the thing that look like magazine-style pull quotes) stop doing that in articles, and only emit basic block quotation markup when used in mainspace. If the mobile version is doing something different, then that needs to be fixed. If it is, the only reason that's been allowed to continue is that not enough editors have noticed and objected, being more focused on the default Vector output. Using font, color, and icon gimmicks to drag the reader's eyes to selectively presented quoted material is a serious WP:UNDUE problem. Most of the other Wikipedias follow the style lead of the English one on most matters (and get most of their formatting template code from there as well). Any WMF projects (or other wikis using MediaWiki) are welcome to do whatever they want with quotations, using local CSS. The "MediaWiki:"-namespace interface pages exist for a reason. Decorative hooey of any kind should not be imposed by default by this software. That includes pointless vertical bars (a style adopted from a particular blog platform that has nothing to do with MediaWiki or WMF or its projects).

And add total page size, not just the change in size. I've long found it frustrating that this information is visible in the history list but not in the diffs; many of us page through diffs rather than scrolling up and down in the history list (or after doing so, rather).

Setting CONTENT_MODEL_SCRIBUNTO is probably a poor idea in the long term, since Scribunto is explicitly (though perhaps rather theoretically) intended to eventually support multiple languages, and just happens to only do Lua so far. We need a way to be more specific with CONTENT_MODEL_LUA, I would think. PS: The rest of these things appear to be all-caps (CONTENT_MODEL_CSS, etc.); I'm not sure if "Scribunto" and "SCRIBUNTO" would be treated as equivalent in the contexts for this.

At a discussion over on Meta, someone (Xover) has suggested that the details of this example should be replaced: "Labor History is also a poor example to use for this (cf. the recent VPP discussion) as it's actually published by T&F and so the |via= parameter is of questionable value there. It would be better to use an example from JSTOR or Project MUSE ... Since these to a much larger degree are pure archive services (Project MUSE is run by Johns Hopkins, and some journals are published by Johns Hopkins University Press, but they also have a lot of journals published by others. JSTOR doesn't publish any journals themselves.)" Such an example would be this:

Do pre-existing users need to do anything to turn this on?

Re: "I can't find a smccandlish or mech user in gerrit. Is there another name I should be looking for?"

If it comes down to it, I'm okay with nuking SMcCandlish, smccandlish, and mech on all three systems, so I can create a new, "clean" SMcCandlish on them (provides there's no mech on either of the other two that isn't me; I'm pretty sure the only WMF site I ever used that on, by accident, was Phab). However, I do use SUL's single account across most WMF servers, as SMcCandlish, and I don't know if that complicates things.

Tried that, and it's not working. I'm logged into wikitech as SMcCandlish and login attempts at Gerrit as smccandlish (or SMcCandlish, either way) do not work with the same password (or any other I can think of).

Update: I can login to Phabricator by one but not both of the available methods. I can login to Wikitech, but I cannot login to Gerrit, despite the fact that https://wikitech.wikimedia.org/wiki/Gerrit says that our Wikitech login ID/PW automatically become those for Gerrit. These issues (for me, and I think for a few others) seem to date back to the timespan when the Toolserver was being retired in favor of Phabricator, and the SUL system was being deployed. In my case, I already has pre-existing accounts on various WMF sites, but not all that many, when I created my SUL account. Not sure if that relates. As far as I know, I used "SMcCandlish" on all of them (and definitely did at Wikitech and Gerrit), except I created also a "mech" account at Phabricator, out of habit of using that old-time monicker of mine on some other coding-related sites. I now also have and am using SMcCandlish at Phabricator.

Yep.

Agreed with TheDJ on all counts, except that it's actually worse. What's happening is that particular and well-organized camps of editors are declaring that they refuse in mainspace to use more accessible markup. They are using talk page habituation to the bad markup as a "reason" to abuse description list code for purely visual layout gimmicks in articles we send to all our readers, and to effectively force all editors to do so (by changing our content guidelines to impose the bad style and to remove any mention of more accessible approaches). This is really, really not okay.

Yes, mech is me as well. I don't use that ID on any WMF sites any longer.

This is not an "edge case", it's how millions of links are done, and the hovercards can be at least frustrating and often very confusing as a result. The OP's case is a good one, and I encounter the same problem all the time.

@MattFitzpatrick:

1. The HTML specs say all kinds of things are permissible, but MW doesn't support all of them. That's okay. Heck, there are entire elements MW just ignores.
2. Your "one-item ul" case won't matter: the in-wiki markup will remain *, and the output will look identical. (If we're concerned someone might be doing something special with style, we can give converted-to-div "list" elements a class they can use to match their list styling; edge case probably no one cares about.)
3. When someone comes along and actually uses your placeholder "*" to create a real list with 2+ items, then after saving the page, MW will parse it as a list, not as a styled div. Meanwhile, if there is only one * we get the double benefit of a) screen readers no longer being told there's a "list" but finding only one item, and b) same users being told there's a list but there's nothing there at all, just an empty <li>.
4. <dl role="presentation"> is still going to be invalid without a least one each of <dt> and <dd>, so by all means we should do something like <div class="whatever-dl-pseudo-indent-class">.

Would love to see action on this. This block-element issue seems broader than the test cases provided years ago at what is now http://test.wikipedia.org/wiki/Bug_T7718

On to some more political and PR matters:

Aklapper: I think it has to mean making beta features available in mw-prefsection-beta first. Few wikis are comfortable having features rolled out without extensive testing at the wiki in question. This has caused problems before. Three examples I can think of are: date auto-formatting (which also caused auto-linking – this was a huge debate at en.Wikipedia, eventually leading to an ArbCom case); and deployment of Flow as feature-complete and read-to-use, which some wikiprojects at the same site then implemented for their talk pages, which led to similar controversy; and similar issues with Visual Editor. Making VE opt-in at the user level has been key to getting some communities to accept anything about it, and to work with the devs in ironing out problems with it instead of just objecting to it being used at all (new users at a site like en.WP generally don't know it's available, so it is mostly clueful editors who are testing it and finding out what its limitations and flaws are).

My much earlier comment mistakenly suggested using a stylzed <span> when I meant <div>; indented "things" often contain block-level markup in them.

This does need to be fixed; people *all the time* use block elements in reference citations, most commonly paragraph breaks and short lists, though I've also encountered reasonable uses of small tables, block quotations, divs that do block indentation of material that is not a direct quotation, and so on. This is not a mistake or bad user behavior, it is editors doing what they need to do in references and non-reference footnotes (which also pass through the <ref> system, with templates (at en.Wikipedia) like {{efn}}, etc.).

Just FYI: WMF's failure to fix this simple and obvious bug after over a decade is likely (given where this RfC is going) to result in en.Wikipedia literally PROHIBITING the use of more accessible markup instead of abuse of the <dd> element for visual indentation. This is pretty much an accessibility debacle of stunning proportions, resulting from a combination of editorial ignorance of accessibility and of HTML specs, laziness, and WMF failure to prioritize development. I'm stunned and depressed that it's come to this. I have no idea how an organization with tens of millions of dollars and a dedicated development team with almost all focus on a single software project cannot get it together to fix basic, obvious, and comparatively easy-to-solve problems in its functionality when given over ten years to do it. This should be fixed within this month.

Can you provide any pointers on how to go about that? I've been trying to resolve this for ages. It's not even multiple user IDs in the "SMcCandlish" or "mmodell" sense, but rather two e-mail addresses which can also be used (in theory) to login with – if I understand correctly. I think it took the "mech" part from one of my e-mail addresses, as I don't recall trying to establish that as an actual user ID on here.

This isn't really true:

I'm not sure why this has gone on for so long without resolution. It seems pretty simple to me:

This is still affecting me, too (for a couple of years now). The workaround would probably be to delete the "mech" username associated with this ID, and just keep the SMcCandlish one.

I haven't figured out enough about this system yet (I've barely been able to get into it until recently due to LDAP issues with my account) to know where to start. I assume there's a git or svn repo somewhere. Anyway, not everyone who reports problems here is a programmer. The "this is going to remain on the back burner unless you code up a solution yourself" approach may make sense in, e.g., the GCC compiler development bug tracker over at GNU, but isn't very responsive when it comes to the issue tracker for a system that is mostly used by writers and readers of plain prose. Depending on what language this is written in, I might actually be competent to help, but the average Wikipedian (or user of other wikis) is probably not a coder.

Why is this set to "Low" priority? It's been my experience, with a large number of projects, that marking a report/request low-priority means it will most likely never be dealt with. Having the hovercard show the content that the link actually points to, and stop misleading readers, would appear to be a high-priority item.

This seems to directly relate: T65792 (start displaying from point of anchor given, not just top of page, and allow this to work when on same page as anchor).

It would be hot if the hovercard, or a template-triggerable variant of it, could start showing content starting at the specific anchor used in the link. If this were combined with the ability to trigger it for links on the same page, not just to different pages, this would be insanely great for glossaries (see https://en.wikipedia.org/wiki/MOS:GLOSSARIES and Wiktionary has them, too). For an example, see https://en.wikipedia.org/wiki/Glossary_of_cue_sports_terms]]. The zillion intra-glossary links in that could just pop up the definition in question (as could similar glossary links at articles like https://en.wikipedia.org/wiki/Eight-ball that link to this glossary), instead of the current practices, which are just a tooltip saying what entry it goes to (generated by the https://en.wikipedia.org/wiki/Template:Glossary_link tag) and, in the present hovercard, the top of the glossary's article page, if you are on a different page than the glossary itself. Many articles have embedded glossaries, too; they're not all in separate articles.