Gradient

edit

{{editprotected}} hi, please use template:gradient on this template. thanks.--ebraminiotalk 15:11, 2 January 2011 (UTC)Reply

I can't replicate the exact dimension with the gradient template, but this should be close enough. EdokterTalk 22:11, 2 January 2011 (UTC)Reply

Roundup to avoid gaps & Add Quaternary

edit

Hi, Could you please change the following simultaneously in {{Fossil_range/bar}}, {{Phanerozoic 220px}} & {{Geological_range}}.

These changes add the Quaternary period and make the bar longer to fit. Unfortunately, Quaternary is too small (2My/650My) to show up properly when drawn to scale. They also close gaps between the bars, and make other minor fixes.

Test cases are at: Phanerozoic 220px sandbox, Fossil_range/bar sandbox & Geological range sandbox but the changes can't be directly copied because they include bar/sandbox references, and test code. They've been developed in Chrome and tested in Firefox, Safari & IE (latest Windows versions).

Direct copies can be made from Phanerozoic 220px copy-paste version, Fossil_range/bar copy-paste version & Geological range sandbox version.

Or, you can make the following changes by hand:

1. replace in {{Fossil_range/bar}}

left: ... px; width: ... px;

with

left:{{#expr:(650-{{period start|{{{1}}}}})/650*220}}px;
width:{{max|{{#expr: (({{period start|{{{1}}}}}-{{period end|{{{1}}}}})/650*220)+1}}|8}}px;
This makes the minimum width 8px, and adds 1 to widths to fix gaps

2. replace in {{Phanerozoic 220px}} outer div

clear:both; width:220px;

with

clear:both; width:227px;
This adds 7px to the template for Quaternary (which starts slightly before 220px, so 7px allows the end border to overlap the difference), but slightly warps the "220px" name (this shouldn't be an issue as the distance on the 220px bar have not changed for {{Geological range}}, which never worked for Quaternary anyway - I'm working on fixing it at the moment)

3a. replace in {{Phanerozoic 220px}}

border-style: ... ;

with

border-style:solid solid solid none;

3b. remove

<div id="end-border" style="position:absolute; height:100%; background-color:#666; width:1px; left:219px"></div>
This fixes the border to avoid the need for a border div

4. replace in {{Phanerozoic 220px}} inner div

left:0px; width: ... px;

with

left:0px; width:{{#expr: ({{period start|Cambrian}}/650*220)+1}}px;
This adds 1 to the PreC width to fix gaps, and fixes a leftover 250 to 220


5. replace in {{Phanerozoic 220px}}

{{fossil range/bar|Neogene|<small>N</small>}}

with

{{fossil range/bar|Neogene|<small>N</small>}}
{{fossil range/bar|Quaternary|<small>Q</small>}}
This adds the Quaternary period as per Geological era#Terminology


6. replace in {{Geological_range}}

width:220px;

with

width:227px;

to keep the widths consistent

The final bar should look like the Phanerozoic 220px sandbox and Geological range testcases with no gaps or overlaps, and the added Q on the end. Thanks! twilsonb (talk) 17:04, 6 April 2011 (UTC)Reply

  Done Next time, please remove the /sandbox from the code! I almost put them into the templates! ;) Thanks, Woody (talk) 21:23, 15 April 2011 (UTC)Reply
It seems that these edits have since been reverted by User:Bob the Wikipedian. Discussion seems to be at Template talk:Geological range#Quaternary added to time scale? — Martin (MSGJ · talk) 07:49, 19 April 2011 (UTC)Reply

Є and Ꞓ

edit

This template uses Є to refer to the Cambrian. That's the Ukrainian Ye; the standard Unicode character for the Cambrian is Ꞓ. Would there be any objections to my changing the two instances of Є in this template to Ꞓ? — PinkAmpers&(Je vous invite à me parler) 13:56, 16 April 2015 (UTC)Reply

On my display, "Ꞓ" appears as a square box (missing character), unlike "Є". It would be good to know how many readers experience the same. --Stemonitis (talk) 10:59, 21 April 2015 (UTC)Reply
Oh dear. Do you think I should revert? — PinkAmpers&(Je vous invite à me parler) 06:04, 22 April 2015 (UTC)Reply
I've just installed a new typeface with better Unicode support, so it does now display for me, but there must be others out there experiencing the same problem. Without knowing how many they are, it's difficult to know how best to proceed. --Stemonitis (talk) 15:13, 23 April 2015 (UTC)Reply
I suppose it comes down to the question of which is more important, using the right Unicode symbol or using the symbol that the maximum number of readers' devices will be able to render. Personally I lead slightly torward the former, but definitely see the case for the latter. Is there any policy or guideline on this topic? — PinkAmpers&(Je vous invite à me parler) 03:32, 24 April 2015 (UTC)Reply
Reverted for now. The characters falls inside the 0xA7xx range, which has piss-poor support in regulare fonts, even recent OS fonts. Proper Unicode is preferable, but only as long as it does not hurt accessability. In such cases, an (svg) image with the proper character may be the better option. -- [[User:Edokter]] {{talk}} 08:51, 14 June 2015 (UTC)Reply
Just chiming in to say that my monitor also displays a square box with gibberish. I think a technically incorrect but close-enough symbol, for the time being, is vastly superior to a "correct" but illegible symbol that cannot be seen by even a significant minority. We should cater to readers as much as possible, not put the burden on them/expect them to have the most up to date system tools. --Animalparty-- (talk) 10:16, 14 June 2015 (UTC)Reply
Agree with the reversion. I also saw a box in the current Firefox on Windows Vista. This is just for navigation and should work for people trying to navigate. The character http://www.fileformat.info/info/unicode/char/A792/index.htm was added to Unicode 6.1.0 in January 2012 and seems to still have lousy support. The other character http://www.fileformat.info/info/unicode/char/0404/index.htm looks sufficiently similar and is from Unicode 1.1.0 in June 1993 with good support. PrimeHunter (talk) 12:19, 14 June 2015 (UTC)Reply
Please revisit the Ꞓ issue. 98.198.244.185 (talk) 21:09, 19 February 2017 (UTC)Reply
A lot of time has passed and Ꞓ is widely supported now. 2A02:A457:9497:1:FC02:BA11:1BDD:392F (talk) 21:21, 27 March 2020 (UTC)Reply
hey!‚ anyone! please do it already‚ eventually >.< … the time has really come! 91.193.176.30 (talk) 05:23, 25 May 2020 (UTC)Reply

I hope an admin or template editor can help address the issue of the incorrect character, as it's more than five years on from the previous discussion and font support has expanded since then. In brief, the template uses a Ukrainian letter, Є (Ye), to represent the Cambrian, while the character is actually supposed to be (C with bar). In 2015 some people reported seeing a box instead of the Ꞓ character, but it seems that the character has wider font support now. It appears using default font selection in Windows 10, Androids 8 through 10, and Ubuntu 18.04. It appears in a Windows 7 machine too but it may not be using a stock font, I'm unable to check for sure. I'm unable to verify one way or the other with any Apple devices. ☽Dziban303 »» Talk☾ 17:45, 12 July 2020 (UTC)Reply

I see a box (on Windows 7) * Pppery * it has begun... 22:19, 12 July 2020 (UTC)Reply
Does Microsoft even support Win7 anymore? Looks like an idea whose time has come, so   done. P.I. Ellsworth  ed. put'r there 01:25, 13 July 2020 (UTC)Reply

Proposal for fixing text wrapping issue in infobox and MinervaNeue skin

edit

While you visit Paleogene article on your phone, you always see its abbreviation Pg is display as this:

P
g

This abbreviation is covered by <small>...</small> tag, which doesn't supported in MinervaNeue (mobile) skin, that's really hurt content layout. As my investigation, you should insert white-space: nowrap !important; property for fix. The proper code is available at Template:Phanerozoic 220px/sandbox. Great Brightstar (talk) 17:13, 5 February 2022 (UTC)Reply

  Done I did not add the !important, since it is generally reserved for true edge cases. I think it is working now; it works for me in mobile, at least. I also adjusted the font sizing per MOS:FONTSIZE. – Jonesey95 (talk) 17:49, 5 February 2022 (UTC)Reply