Font Color/Size

[TechAngel85]

Discussion topics:
Template:Fc
Template:Fs

---

 

[TechAngel85]

Two things:

1. I added the ability to bold the text to this template. It's implementation requires the "bold" text to be in the third position. Else we would have to edit all instances of this template. I tried to get a {{#if}} to work using a "fontWeight=x" parameter but couldn't manage it, couldn't figure it out, or the wiki didn't like the nesting.
2. I added a "Template" prefix to this forum so that we can start tagging the template threads properly and making them easier to find.

[DoubleYou]

Tech, you do realize that all you need to get bold text on the wiki is enclose it in triple apostrophes...

 

'''This text will be bold'''

{{fc|red|'''This red text will be bold'''}}

[TechAngel85]

I do know that, but was under the assumption that those characters weren't passed through correctly and was the reason we from the {{{1}}} to the {{{text|}}} format on a lot of the templates. Perhaps it was other characters that weren't working...

[z929669]

Tech, you do realize that all you need to get bold text on the wiki is enclose it in triple apostrophes...

 

'''This text will be bold'''

{{fc|red|'''This red text will be bold'''}}

Correct. There is no reason to modify the existing template, so I am reverting the changes to reduce the redundancy. Simply use wiki markup to bold within any template just like normal.

 

I also noticed two colors were switched, which is not desirable, because it messes up the appearance of much of the existing markup. Modify new usage to adjust colors, not the template.

 

I do know that, but was under the assumption that those characters weren't passed through correctly and was the reason we from the {{{1}}} to the {{{text|}}} format on a lot of the templates. Perhaps it was other characters that weren't working...

Numbered parameters were replaced with named parameters in order to eliminate the need to use an '=' sign within templates, which is a problem when including a URL within, say, a Notice.

[TechAngel85]

Cool. Noted. At least I learned something along the way!

[TechAngel85]

I updated this template to fix the behavior of using incorrect keywords. Using a wrong keyword should have resulted in default text color (according the example), however, it was being highlighted, instead. This is corrected.

I would like to challenge the need for each of the keywords used, though. The reason being is I sometime find it confusing and some of them just don't make any sense to me. Ultimately, I think it should be reduced to 3 keywords (max) for each color; less is better though. Here are the current keywords for each color supported:

• magenta
• purple
• addition, enhancement, confirmation, blue
• fix, functional, relevant, green, added
• chartreuse
• issue, unknown, yellow
• instruction, ilheading¹, salmon, notice
• change, modification, orange, updated
• removal, non-functional, irrelevant, warning, red, dropped
• important, highlight
• dimmer

 

Here is what I recommend (using ROYGBIV as standard):

• red, warning, drop
  • "non-functional" I doubt is used 
  • irrelevant seems...irrelevant, ironically.
  • removal and dropped are the same thing, lets just make it "drop"
• salmon, instruction, ilheading¹ 
  • Is ilheading still in use???
  • Why is "notice" here? Our notices are blue...moved that.
• orange, update
  • "change", modification, and "updated" are the same thing, let just make it "update" 
• yellow, issue
  • I doubt "unknown" is used.
• chartreuse, bug
• green, add
  • "functional". "fix" and "relevant" do not seem relevant
  • "addition" makes more sense to be green rather than blue, also since "added" is the same thing we just use the shortest version "add"
• blue, notice
  • "addition" didn't make sense here. Move it to green
  • Our notices are blue so I moved "notice" to here
  • "confirmation" and "enhancement" don't seem relevant
• purple, development
• magenta
• important, highlight
• dimmer, dim

Assuming "ilheading" is still in use, that is a reduction of 9 keywords, which should help to optimize this template even further...considering its heavy use.

[Greg]

I see ilheading in four places (not counting the Fc template itself) and one of these is User:Protocon/Fc. The primary uses are in the SiteColorPalette page and Z's copy of it, and User:Proton/2.3.0. Assuming my search is accurate and this is the extent of it, I think we can replace ilheading with salmon or instruction as appropriate.

EDIT: Including a link to the search I used so it can be verified for accuracy and because I can never remember how to do this search.

https://stepmodifications.org/wiki/index.php?search={Fc|ilheading&title=Special%3ASearch&profile=default&fulltext=1

Search revision since I discovered | is actually or in wiki search syntax. It seems to work for the ilheading case, but it returned lots of irrelevant results when I changed it to notice.

https://stepmodifications.org/wiki/index.php?search="{{fc|ilheading"&title=Special%3ASearch&profile=default&fulltext=1

[z929669]

As long as it's intuitive, it works for me. three max is fine, but we could simplify even further. Just need to know what is in use using what key words so that I can replace without changing anything or conflating changes so that we can't easily revert them.

ilheading was for inline headings. I started that one a while back, because I thought salmon was good for that. Calls out without too much flash

[TechAngel85]

@Greg, @z929669
If we're okay with those changes, I will go ahead and make them and replace without causing any issues. Several that I checked already aren't even being used. The syntax of the template will be updating too, though, which is just adding "text=". This is still the documented way to prevent issues when transcluding certain characters:
{fc|keyword|text=BlahBlahBlah}}

[DoubleYou]

Can't we simply instruct users to use numbered parameters in those cases instead of adding text= to all forms of this template? Even Wikipedia's font color template uses numbered parameters, and it would be a lot of work to change all instances to use text=. 

[Greg]

1 hour ago, DoubleYou said:

Can't we simply instruct users to use numbered parameters in those cases instead of adding text= to all forms of this template? Even Wikipedia's font color template uses numbered parameters, and it would be a lot of work to change all instances to use text=. 

I'm in agreement with DoubleYou on this one. It seems to be an excessive amount of work to add a parameter name to handle an edge case.

[z929669]

I also agree. There are multiple standards, including named/ordered parameters. No need to do anything other than collapse redundant keywords into the few needed.

EDIT: Anonymous params are always simplest to use and what we default to most of the time (like for this one). Numbered/named params are useful only when you are using certain chars in the text. It's rare. I believe it would be possible to allow use of anonymous as well as named/numbered in same template if you really want to make both work. We did this with Notice/alert templates for obvious reasons, but I have never needed to worry about an = symbol with Fc/Fs templates. I never use URLs in those, and if I do, I only style the link text.

21 hours ago, DoubleYou said:

Can't we simply instruct users to use numbered parameters in those cases instead of adding text= to all forms of this template? Even Wikipedia's font color template uses numbered parameters, and it would be a lot of work to change all instances to use text=. 

I do prefer named over numbered params, since the numbers are arbitrarily assigned and provide no indication of what they represent

[TechAngel85]

@DoubleYou, @Greg, @z929669

Numbers must be assigned in the order they are given, else the template breaks. I'm not a fan of this simply because I don't always remember the right order the parameters are in. Thus, I prefer named. Also, unless you dive into the code and know what the numbers represent and which order to put them in, the templates come out broken. Forget a parameter...broken. It doesn't help that 50% or more of our templates are not documented or the documentation is old, which I've been trying to update as I go. You guys are in the bad habit of updating templates without updating the documentation. I say "you guys" because I don't know who (over the years), but I always update it, as needed. Examples too...I've found several examples left in that don't actually work due to changes in the template.

(Seems no one followed and read the linked document or didn't understand it...)
Numbered parameters aren't appropriate for anything used for unknown text...meaning the user can put whatever text they want for the parameter. Specially, "=" characters will mess up the templates when only using numbered parameters for this. This is because the first "=" character is processed as part of the template, thus, again breaking the template. Naming the parameters prevents the majority of these issues. That is why the Alert, Alert Small, PageTile, and other templates have the named parameter "text" or something else where the user is able to enter any text.

As advanced users, we often forget the everyday user's , who is not likely fluent in "wiki", prospective. All most user are going to care about is that the templates are easy to use. It may be more to type, but in most cases named parameters are simply easier to remember vs the arbitrariness that inherently comes with using numbered parameters. It's easier to remember a name (especially when they're consistent across templates) vs numbers, how many numbers, what the order of the numbers represent, etc. for a single template...and we have dozens. Imo, named parameters are more user-friendly by nature.

With all that said, I'm not wanting to change all the templates. Just keeping a consistent standard where it applies, regardless of convenience; else why have the standard if we're going to bend and break it where it pleases us.  In this case, it just so happens to be a bug fix too.

Yes, this template will use a combination of numbered and named. The color is the numbered {{{1}}}. The displayed text will be "text" to stay will the other templates' format. This is also to prevent the bug with the "=" character. Since there are only two parameters and one is named, it will not matter the order these are listed by the user. This makes it user-friendly:

• {{fc|color|text=blah}}  ...works!
• {{fc|text=blah|color}}  ...this works too! But is not recommended, because it makes it harder for maintenance purposes.
• {{fc|text=blah}}   ...we could make this work too, if we wanted to make the default...highlight?

However, having one standard (the first example) makes it much easier for maintenance (like using Replace Text).

On 6/27/2021 at 3:31 PM, DoubleYou said:

... and it would be a lot of work to change all instances to use text=. 

Replace Text makes this a five min task.

[DoubleYou]

I disagree, and I did read and understand the document linked. Why don't we just meet in the middle and use {{{text|{{{2}}} }}} ? This will effectively make both ways work.