Template talk:Cyrl

I just removed "font-family /**/:inherit;" from the template. Until last October it would have been a good part of the template. But then the wiki software was changed to disallow comments in inline styles. ("/**/" is an empty comment.) As a result of this change the presence of this IE hack breaks the template. --teb728 05:54, 11 June 2006 (UTC)Reply

Apparently (as discussed elsewhere) Cyrillic italics look quite different from Cyrillic non-italics, to the point that we wish to avoid using Cyrillic italics at all on the English Wiktionary. So, wouldn't it make sense for this template to include font-style: normal; in its CSS, so as to negate any containing italicization? —Ruakh_TALK 05:55, 22 August 2007 (UTC)Reply

That sounds important but whenever I copy-paste something that was italic into here, the italicization disappears. As such, I thought that italics would only appear when the editor included two apostrophes on either side on purpose and they could do so outside the braces if they were determined to make it italic. I haven't tried italicizing tags so I could be way off track. Thecurran 02:28, 5 September 2007 (UTC)Reply

Text within this template would only appear in italics either if the template is contained in some block of text that's italicized (whether directly or via a further template, whether explicitly or via an HTML class with a CSS hook), or if the content of the template included italicizing markup (ditto). In the former case, I believe this template should de-italicize its own text. In the latter case, I don't it's the template's business to interfere with its content, and I'm not suggesting it do. —Ruakh_TALK 02:47, 5 September 2007 (UTC)Reply

Now that this template has been altered, Russian acute accents now appear to be flying very high and off to the right of the letter they’re over, exactly as it used to be before we began using templates. If this is left as it is, the template can be deleted and we can stop using it altogether. The effect of this change is even worse than what happened to the IPAchar template: ска́т. —Stephen 16:30, 16 March 2008 (UTC)Reply

If we really need to force the fonts for all browsers, then the rule in MediaWiki:Common.css should be altered to remove "inherit" rule that forces browsers other than IE6 to use their default fonts. Using inline fonts for some scripts and not others means that users either have to use !important in all of their CSS rules to override our choices or have intimate knowledge of which fonts are inline and which aren't. I certainly don't think that we should break the correctness of our display, so if we really need to force the fonts to make things work for a large segment of our users, then we should do it in MediaWiki:Common.css for browsers other than IE6. For what it's worth, the accent shows up for me in the correct place with my default fonts. Mike Dillon 16:54, 16 March 2008 (UTC)Reply

What are you using? in WinXP/Firefox, it doesn't work, but with the font list: ска́т is fine. Robert Ullmann 17:52, 16 March 2008 (UTC)Reply

Firefox and Seamonkey under Linux, which is obviously a tiny tiny minority. Like I said, if forcing the fonts makes life easier for a lot of our readers, I have no problem with removing the "inherit" hack for .RU in MediaWiki:Common.css to allow the first "font-family" declaration there to stick. Mike Dillon

I use/Firefox, but I used to use Win2000/IE, which had the same problem. —Stephen 18:37, 16 March 2008 (UTC)Reply

WinXP/IE7 has the same problem. I don't really understand the interaction between the template list, the CSS list and "inherit", but in any case this should be set up to work by default on these platforms. (Don't know anyone with Vista; don't want to, XP is bad enough.) Robert Ullmann 18:57, 16 March 2008 (UTC)Reply

Here's how it works based on a simplified view of the CSS specificity rules:

1. MediaWiki:Common.css defines font-family for .RU (specificity = 10 because it's a single class selector)
2. MediaWiki:Common.css overrides font-family for .RU to change back to "inherit", but it is done in such a way that IE6 does not sees it using a CSS hack (same specificity as above when it is recognized)
3. Inline style defines font-family for all browsers (specificity = 1000 because its inline)

Besides the fact that this means that a user who is willing to edit their monobook.css has to use !important, the high specificity of the inline rule means that we can't have Cyrl use different fonts in different contexts without using !important ourselves. So if we wanted to do something like this TT .RU { font-family: ... } to use different fonts for Cyrl embedded in a TT element, we couldn't do it with normal CSS rules.

The way to fix all of this, if we want to always use a fixed font list, is to simply remove inherit rule and the inline styles. This way the first rule in MediaWiki:Common.css will be seen by all browsers, unlike the current situation where only IE6 uses it. Mike Dillon 19:24, 16 March 2008 (UTC)Reply

I don’t understand any of that. I’m sure I’ll regret asking this, but since these templates worked before, but do not work now, what is wrong with putting them back the way they were? —Stephen 20:35, 16 March 2008 (UTC)Reply

The problem is that the old method limited users' ability to customize and use their own fonts — which, frankly, does not strike me as our top priority. However, once caches clear and everything, Mike Dillon's new suggestion should be fine: we provide sensible default fonts regardless of how a user's browser handles weird CSS edge cases (i.e., regardless of whether the user is using IE6), and users can easily override if they want. Where I do differ from Mike Dillon is on the issue of timing: we should fix MediaWiki:Common.css now, and fix the templates later, after most users' caches will have cleared — say, in a month or so. That way, our "readable and usable for most users" goal is given the priority it merits over our "customizable for CSS-savvy users" goal. —Ruakh_TALK 22:39, 16 March 2008 (UTC)Reply

(Apologies to Stephen up front for techy talk...) You're right that my timing was wrong. I've now updated Common.css to remove the inherit and reverted myself here. Some of the Squid caches have been purged and are showing the new version of Common.css based on my tests, but others are showing the inherit hack still with an "Expires" date of April 16. We should be able to redo the changes here then. (I really wish Wikimedia gave us a deterministic hook for getting things purged from the Squid caches...)

As for user caches, that's a tricky issue. The expected average lifetime of someone whose browser has the stylesheet cached is 15 days, since the Squid caches will send out the same copy for 30 days without changing the expires header. If we could get all of the Squid caches to clear, that would mean we'd expect those people who have it in their cache to take an average of 15 days to get the new version. However, according to research done by Yahoo , only 50% of visitors to the Yahoo home page have assets in their cache at any given time. Since Yahoo is pretty heavily used as a home page, I'd expect our number is probably lower. Then there are accelerator caches for large ISPs... Anyways, I'm not trying to make excuses, my timing was wrong as Ruakh says.

Lastly, regarding the point of this change, it isn't only for CSS-savvy users, as I said above. The current setup of having inline fonts in script templates prevents us from doing any contextual styling in a graceful way. However, since we aren't planning on adding styles for monospaced Cyrillic right now as far as I know, this point is probably moot too. Sorry for the trouble; we can revisit removing this still in a month or so once everyone's cache has caught up. Mike Dillon 05:00, 17 March 2008 (UTC)Reply

Thanks! :-) —Ruakh_TALK 22:38, 17 March 2008 (UTC)Reply

"... the high specificity of the inline rule means that we can't have Cyrl use different fonts in different contexts without using !important ourselves. So if we wanted to do something like this TT .RU { font-family: ... } to use different fonts for Cyrl embedded in a TT element, we couldn't do it with normal CSS rules."

That doesn't seem right. The CSS rule "tt .RU" is more specific than the simple rule ".RU" in common.css, so overriding it in this way in your user style sheet should just work. (More about CSS specificity at HTML Dog)

Oops, I see that the rule is in both the style sheet and applied inline in a <span> element. Sorry. —Michael Z. 17:31, 25 March 2008 (UTC)Reply

I am using Safari/Mac. As far as I can tell, all foreign scripts just work in my browser, so I'd prefer not to have the style sheet pick fonts for me. At leas it could pick a Mac-specific font. "Arial Unicode MS" is now installed by default in Mac OS X 10.5, but it is lacking a bold font, and frankly it is an unattractive typeface. Can someone add "lucida grande" at the front of the list for .RU? This font family is present on all Macs, has a very broad Unicode range, and includes a bold font. —Michael Z. 17:27, 25 March 2008 (UTC)Reply

Please add your voice to the stalled discussion at WT:BP#Forcing fonts in script templates. Mike Dillon 04:53, 26 March 2008 (UTC)Reply

As long as there are changes being made here, is there any reason not to start to transition the class name to "Cyrl", since it is used for the Cyrillic writing system, and not just Russian language?

It should be easy to do: just add a second selector to MediaWiki:Common.css (.RU, .Cyrl {...}) and leave it for a month or two. Once the cache has expired, all of the templates can be updated to use the new class name. —Michael Z. 04:52, 6 April 2008 (UTC)Reply

I can't seem to find the utility of this template (documentations anywhere? Sorry, I'm new here...). At this entry, it doesn't seem to bring any benefit. At least in my browser, that Russian sentence is displayed as a smaller-sized, italicized font! It's Unreadable! Any reason to refrain me from removing the use of this template in that entry (and possibly other ones) for the sake of font visibility? ~> SilvioRicardoC 02:35, 12 August 2008 (UTC)Reply

It's a script template, which helps certain browsers display properly, as well as allowing users to control how the encapsulated text is displayed. Please do not remove it. I have undone the italicizing in прикол (prikol). -Atelaes λάλει ἐμοί 05:40, 12 August 2008 (UTC)Reply