Template talk:Physics particle

(Redirected from Template talk:Physics particle/testcases)
Latest comment: 9 years ago by Timothy Gu in topic Non-screenreader friendly

Forced bold?

edit

I applaud the idea of having standardized templates for all subatomic particles, but it looks like the current version of {{PhysicsParticle}} always displays the particle's symbol in a bold font, which is distracting in most contexts. In particular, since this template is used in {{SubatomicParticle}}, we get particle names like
e
(electron) or
γ
(photon), which is rather uncommon in my experience. Perhaps the default should be non-bold, but with an optional parameter for requesting bold/italic symbols? Hqb (talk) 13:29, 20 March 2008 (UTC)Reply

Done. I originally made them bold because the page I based the first version off was using bold. These templates are there to facilitate making all physics pages have the same look and feel and the Category:Nuclide templates aren't bold either, so neither should this one.
There should be no need for make it available as an argument, as it is simpler to use single quotes like so: ''{{SubatomicParticle|electron}}'' ->
e
and '''{{SubatomicParticle|electron}}''' ->
e
.
My TODO list includes rewriting the various Category:Nuclide templates to use this template as well, making it possible to change the look and feel of everything in one place. That should save vandals a lot of work :)
- SkyLined (talk) 20:02, 20 March 2008 (UTC)Reply
Great, thanks! Hqb (talk) 20:16, 20 March 2008 (UTC)Reply

Urgent: link= parameter?

edit

The support for link= was recently removed by this edit, but it's still listed in the documentation. And though {{SubatomicParticle}} does not use link=, several other templates, such as {{Element}} do, and are currently broken (i.e., do not create a link even when asked for). Consequently, several WP articles (such as Radium) are missing useful links.

Clearly something needs to be fixed, and quickly. I'd revert the change above, but I'm not sure that having a link= argument to PhysicsParticle is really the right approach in the first place. Are there situations where {{PhysicsParticle|link=pagename|...}} is supposed to behave differently than [[pagename|{{PhysicsParticle|...}}]]? If not, it seems both simpler and more efficient to let the caller of PhysicsParticle (which will almost always be another template, such as {{SimpleNuclide}}) create the link directly, instead of passing the request off to PhysicsParticle. Hqb (talk) 19:17, 10 May 2008 (UTC)Reply

It makes sense to have the link be made by the caller - I don't recall why I added it in the first place. I will revert the changes now to restore proper links. Then later I will modify all callers to stop using the link parameter and add their links themselves. I'll check to make SURE that nobody's using it before I remove it again.     — SkyLined {talkcontribs 05:12, 11 May 2008 (UTC)Reply
Hi there, and sorry for the problems my edit seems to have inadvertently caused. I was working fast to resolve this problem, and so I wasn't able to check my actions as thoroughly as I would have liked. My checking process basically consists of using AWB to scan the text of all pages transcluding the template, to look for characteristic syntax (in this case, |link=yes). For some reason, this usually reliable method seems to have failed to pick up on the use of this feature in templates like {{element}}, so sorry for causing this disruption.
The preprocessor-node-count issue on List of baryons highlights the extent to which these templates could do with overhauling. They serve a very important, even vital, purpose in wikipedia articles, but do so very inefficiently and with considerable redundancy and duplication of function. I think when I have time I would like to go through the whole system and see if it would be possible to create a more manageable and streamlined set of templates. How many templates are involved in the display of symbols like this? I am aware of {{SubatomicParticle}} and its subpages, {{PhysicsParticle}}, and Category:Nuclide templates. {{su}} is also related. Are there any others? Happymelon 16:43, 11 May 2008 (UTC)Reply
I'm the one who started all this, anything I did is on my main page, have a look there for a list. A lot of this could be done more CPU efficient by not including sub-templates, but that would seriously impact maintainability: Everything I needed to do more than once, I created a sub-template for, so that if I needed to make an adjustment, I only needed to make it in one location ({{su}} is vary good example of this). If there was a way to output a <TABLE> without wikipedia automatically putting <P> tags around stuff (which messes up the layout), we could replace {{su}} with a simple inline table, which would simplify and speed things up a lot.     — SkyLined {talkcontribs 05:46, 15 May 2008 (UTC)Reply

Photon symbol should be a gamma

edit

The symbol generated for a photon by this template is |photon=
γ

It looks like a "Y" instead of a gamma.
The gamma generated by the math template...  would be much better.--Vectorboson (talk) 13:52, 14 May 2008 (UTC)Reply

In my setup, your two examples actually look identical (both use the Unicode "Greek small letter gamma" character of the default browser font). I assume you have your math preferences set to "Always render PNG", which forces Computer Modern (or whatever <math> is configured to use). But that is not generally recommended, because it's quite a bit more resource-intensive (WP now has to generate and transfer an entire bitmap image instead of just a single character). It can also look really odd, when the symbols for other particles (electrons, protons, etc.) use the standard browser font. Maybe you could configure your browser to use another font, in which &gamma; looks less like a "Y"? Hqb (talk) 14:19, 14 May 2008 (UTC)Reply

Interesting. Browser-wise I run Safari and I tried changing my default encoding to Unicode (UTF=8) and that didn't help. I tried changing my Wiki-math-preferences away from the default that were set when I joined (tried "Recommended for modern browsers" and also "MathML if possible") but that didn't help either. Really though the issue isn't what I see on my browser, rather it should be what the average user sees on his browser...and the average user should see a gamma and not a Y.--Vectorboson (talk) 14:44, 14 May 2008 (UTC)Reply

Don't know much about what I'm doing...but here is some additional info to help you analyze. When I view the html source of this page here is what I see... for the one that shows up like a Y...
γ
and for the one that shows up like a gamma...

γ
You will have to view the source for this page to see the difference in html--Vectorboson (talk) 15:37, 14 May 2008 (UTC)Reply

Ooh, indeed. It's exactly the same character "γ" in both cases, but the latter one is inside a <span class="texhtml">γ</span>. The standard WP CSS definition for "texhtml" apparently reads,
span.texhtml { font-family: serif; }
which happened not to make any difference in my browser, but I can certainly see how it might do so for others. Still, I guess there's no guarantee that any particular choice of font will look optimal for everyone. How do text-mode ν vs. math-mode   for the neutrino look to you? Hqb (talk) 18:39, 14 May 2008 (UTC)Reply

As you might expect, the text mode looks like a "v" while math mode looks like a nu. I agree that we can't guarantee what it will look like on someone's browser but there is a minor point that we should shove them out with the same html so they look the same. Now that I understand this is primarily a browser problem, I leave it to wiser heads as to whether it is worth a lot of trouble.--Vectorboson (talk) 18:59, 14 May 2008 (UTC)Reply

The font does suck, but that is not wikipedia's fault. I liked your suggestion and tried it out, only to find out it messed up the layout when the symbol had an overline (on Opera). I'm hoping to find a way to use <TABLE> to generate the sup/sub text, which might resolve this problem and allow us to use class="texhtml"     — SkyLined {talkcontribs 05:59, 15 May 2008 (UTC)Reply
I think the quality of the font does matter. The point of having a template is create a uniform look and feel for WP and for quality control purpose. To get a good font should not be a burden for the viewer. We should make sure we get the best possible results. The only way to do that is by using math mode. If you do it like this ν, it looks awfull. If you do it like this  , it still looks prety bad. Now, if you do it like that  , it looks much better. I have to say that I will probabily avoid using these templates until a better solution is implemented Dauto (talk) 21:15, 18 January 2009 (UTC)Reply
Math mode is actual quite bad when used inline. Since it creates an image of the character instead of the character it will not be properly aligned with the baseline, nor will it in general be the proper font size. (TimothyRias (talk) 09:55, 19 January 2009 (UTC))Reply
That may be true. But it still beats a nu that looks like a v any day of the week. (or a mu that looks like an u, or a gamma that looks like an y, or a tau that looks like a t, etc...) the font used right now is pretty awfull. The point of creating a template is to give WP a consistent look and feel and improve its quality. Right now all it's doing is make WP particle physics pages look consistently bad. Dauto (talk) 21:43, 19 January 2009 (UTC)Reply

position lower indices

edit

The template has a problem with the positioning of the lower indices. (On FF3 and IE7, at least) the position of the lower index varies greatly depending on the presence of an upper index. Compare


Ad
c
with
A
c

The main issue is that the one with only a lower index positions the index way to low. The problem is caused by the {{su}} template behaving funny when the parameter "p=" passed with an empty parameter. I have (partially) implemented a fix for this in the sandbox. This indeed fixes the problem:

p
pAAZsd
c
s
with p
pAAZs
c
s

However it causes IE to render the following cases badly:

p
b
pAAZsd
c
s
and pa
b
pAAZs
c
s

any ideas for a better fix?(TimothyRias (talk) 09:47, 8 January 2009 (UTC))Reply

OK, I have implemented a new fix by completely by passing the {{su}} template. The implementation uses only css and works with IE7 and FF3. Can people with older browsers check if this implementation als works for them. (TimothyRias (talk) 11:18, 8 January 2009 (UTC))Reply

I dunno what's going on, but you're messing every article with the template. I'm reverting to the stable version. Use a sandbox or something. Headbomb {ταλκκοντριβςWP Physics} 22:04, 19 January 2009 (UTC)Reply

No need to get rude. For your information this version has been in the sandbox for nearly two weeks now. It has worked perfectly with all browsers I have tested it with, which includes IE7, FF3 and Opera 9.xx . And since nobody has objected to the changes, the next logical step was to implement it in the actual template. So instead of, going jeez, "use a template or something" you might actual want to provide some useful feedback, like what was broken, in which browser and with which skin.
Anyway, something needs to be done because the current version is broken, as it does not provide consitent postions of the lower indices. (TimothyRias (talk) 22:22, 19 January 2009 (UTC))Reply
Sorry if it came across as rude, it wasn't in my mind.Headbomb {ταλκκοντριβςWP Physics} 08:24, 20 January 2009 (UTC)Reply
Also the current sandbox version seems to display everything correctly, so I don't know why it came across all messed up. Was there any difference between the sandbox version and the one used in the template prior to my revert?Headbomb {ταλκκοντριβςWP Physics} 08:27, 20 January 2009 (UTC)Reply
There's a small problem with alignments. See p
pAΩZs
bbb
s
for example. The minus should be aligned on the left. Headbomb {ταλκκοντριβςWP Physics} 08:33, 20 January 2009 (UTC)Reply
Fixed. That incidently was the only difference between the sandbox version and my last edit to the template yesterday. I noticed the alignment problem when viewing the {{SubatomicParticle/list}}. After that fix all elements on that list showed up fine for me (on FF3). (except for any issue with sub/superscripts starting with ∗ that also plagues the current template.) What was showing messed up for you yesterday and in what way and with which browser? Also did you try purging the relevant page? (TimothyRias (talk) 09:03, 20 January 2009 (UTC))Reply
Yes I tried purging and it with every browser (FF2/3, IE7). As for how messed up it was, well the various subscript were all over the page. Something like
Ω++
ccc
would've displayed like (without the dash box around it)
  ++
Ω
                 ccc
Anyway, the current version seems to be working fine now, whatever the problem was back then.Headbomb {ταλκκοντριβςWP Physics} 10:06, 20 January 2009 (UTC)Reply
OK, so how do you feel about implementing the current sandbox version. If it breaks stuff again we can then revert and copy the offending instanced to the testcases page to figure out what is going wrong. Since I gather that the testcases page is showing the sandbox version fine for you, I don't really understand what could have caused the mess up. (I expect that the new implementation might break in older browsers with poor standards compliance, but since the problem also occured for you with FF3 and IE7, I'm at a loss.) (TimothyRias (talk) 10:38, 20 January 2009 (UTC))Reply
Sure, let's try it again.Headbomb {ταλκκοντριβςWP Physics} 10:39, 20 January 2009 (UTC)Reply
Take 2 commenced. :) So far so good. {{SubatomicParticle/list}} is fine on IE7 and FF3 on my system (win XP). (TimothyRias (talk) 11:29, 20 January 2009 (UTC))Reply

Everything looks fine to me. Guess we'll never know what produced the garbled mess I saw.Headbomb {ταλκκοντριβςWP Physics} 12:14, 20 January 2009 (UTC)Reply

Awfull font

edit

The font currently used by this template isn't very good in my opinion. Its gamma looks like an y, the nu looks like a v, the mu looks like an u and the tau looks like a t. I find it hard to believe we can't do better than that. Dauto (talk) 00:09, 21 January 2009 (UTC)Reply

Small note: Although I agree with you mostly. This isn't actually the template that controls the characters used for particles. I'm currently advocating a serif font for (at least) all lower case greek symbols at Template_talk:SubatomicParticle/Symbol. Please join me there. (TimothyRias (talk) 06:35, 21 January 2009 (UTC))Reply

Slow

edit

There's currently a discussion at VP regarding the redesign of {{subatomic particle}}. The suggestion there was to replace the twelve hundred or so subtemplates with #switches. Of course, the question of effeciency came up (since large #switches are pretty bad in that respect). Various different ideas were proposed. One approach that really seemed to speed {{subatomic particle}} up was its getting rid of {{physics particle}}. The down-side is that editors might want to subst {{subatomic particle}} to get {{physics particle}} and that wouldn't be possible if we just get rid of it. So if {{physics particle}} is slowing {{subatomic particle}} down, couldn't we speed {{physics particle}} up? This is where the discussion is at now.

What's slowing the template down? This template relies on four other templates to function.

  • Two subtemplates are used to put symbols together.
    • If an overline (for antiparticles) is needed, {{physics particle}} calls {{overline}}.
    • If superscripts or subscripts are needed, it calls {{su}} (twice if needed on both sides).
  • Two subtemplates are used for linking.

What if we were to put all of this on one page? Such a code can be found in the sandbox. This code has been tested against the current code using approximately twelve hundred calls in terms of template limits with the following results.

NewPP limit report for {{physics particle/testcases/current}}
Preprocessor node count: 67398/1000000
Post-expand include size: 1046048/2048000 bytes
Template argument size: 303838/2048000 bytes
Highest expansion depth: 11/40
Expensive parser function count: 0/500
NewPP limit report for {{physics particle/testcases/sandbox}}
Preprocessor node count: 38666/1000000
Post-expand include size: 716846/2048000 bytes
Template argument size: 35310/2048000 bytes
Highest expansion depth: 5/40
Expensive parser function count: 0/500

The sandbox version has

  • almost halved the preprocessor node count,
  • taken about 30% off the post-expand include size,
  • reduced the template argument size to about a nineth and
  • more than halved the highest expansion depth.

I propose that we replace the current code with this new version. JIMp talk·cont 06:56, 13 June 2012 (UTC)Reply

Non-screenreader friendly

edit

Currently the template uses <br>'s to typeset corners, but this is extremely non-text browser or screenreader-friendly. Here's the output of:

This is a weird particle {{Physics particle|A|TL=a|TR=d|BL=b|BR=cc}} from Timothy.

in w3m:

This is a weird particle a
bAd
cc from Timothy.

Same goes with Lynx.

In your browser:

This is a weird particle a
b
Ad
cc
from Timothy.

Is there a way to improve this?

Timothy G. from CA (talk) 21:04, 21 March 2015 (UTC)Reply