Font Color/Size

[z929669]

See my previous. There is just no reason to change templates Fc and Fs. They are used all of the time and work as intended. I am all for reducing the number of terms for each, but I think it is senseless to force use of an equals sign. URLs do not matter with these templates. They do for Alerts, so we use them there.

I am a fan of leaving it alone but for reducing the terms. Please.

EDIT: I also followed the linked document ... and I have read it many times. They are ALL standards. You are making assumptions that really aren't valid for these templates. We just never have cause to use URLs with query parameters in colored or resized text. Why would anyone color or resize text of a URL?? Nor have I ever had cause to use an = symbol in these situations.

ANONYMOUS params are simplest to use and implement and that's always what should be used unless there is clear reason to use named params. I also don't like numbered params, because they are arbitrarily assigned (unless they are 'scaled' params).

Also, I had changed some of your Bootstrap class uses, but I mixed up x/y and corrected. class="mt-5 mb-5" can be more succinctly done as class="my-5"

Doing anything more than '5' has no effect, and they can't be stacked either like "my-5 mb-5" ... I believe the last one wins, so it is redundant.

 

1 hour ago, DoubleYou said:

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. 

absolutely, positively, completely agree with this approach, but for these templates, {{{2}}} works without issue as it always has. If you guys want to change it like this, it will cause no cleanup issues and cannot break anything if done right. I just see no reason to change this stuff or debate it at length, because it's a non-issue. The responsive design stuff is more important, IMO. That's why I got on it ... so it's waiting for sign-off as I posted.

[TechAngel85]

On 6/28/2021 at 8:32 PM, z929669 said:

See my previous. There is just no reason to change templates Fc and Fs. They are used all of the time and work as intended. I am all for reducing the number of terms for each, but I think it is senseless to force use of an equals sign. URLs do not matter with these templates. They do for Alerts, so we use them there.

I am a fan of leaving it alone but for reducing the terms. Please.

EDIT: I also followed the linked document ... and I have read it many times. They are ALL standards. You are making assumptions that really aren't valid for these templates. We just never have cause to use URLs with query parameters in colored or resized text. Why would anyone color or resize text of a URL?? Nor have I ever had cause to use an = symbol in these situations.

ANONYMOUS params are simplest to use and implement and that's always what should be used unless there is clear reason to use named params. I also don't like numbered params, because they are arbitrarily assigned (unless they are 'scaled' params).

Also, I had changed some of your Bootstrap class uses, but I mixed up x/y and corrected. class="mt-5 mb-5" can be more succinctly done as class="my-5"

Doing anything more than '5' has no effect, and they can't be stacked either like "my-5 mb-5" ... I believe the last one wins, so it is redundant.

 

absolutely, positively, completely agree with this approach, but for these templates, {{{2}}} works without issue as it always has. If you guys want to change it like this, it will cause no cleanup issues and cannot break anything if done right. I just see no reason to change this stuff or debate it at length, because it's a non-issue. The responsive design stuff is more important, IMO. That's why I got on it ... so it's waiting for sign-off as I posted.

See: https://stepmodifications.org/wiki/User:TechAngel85/Sandbox3

If you're okay with broken things, fine. I'll yield. Regardless if you have never had an issue...the bug is there and the potential is there.

{{{text|{{{2}}}}}} would still have to be defined as "text=" since named parameters have to be called. You can try it, but I don't think that'll work.
EDIT: I did this in Dev and the issue remains, but it does work without "text="...isn't just still broken: https://stepmodifications.org/wikidev/User:TechAngel85/Sandbox3

[TechAngel85]

Since "{{{text|{{{2}}}}}}" works, this gives the fix (if needed) while will allowing users to skip the "text=" in most cases, I agree this is the best of both worlds.

So if we can agree on that and the keyword reduction is a go, I will go ahead and post my changes to Dev for review. I have everyone ready in Notepad. Just been waiting to nail down the final draft.

[z929669]

30 minutes ago, TechAngel85 said:

See: https://stepmodifications.org/wiki/User:TechAngel85/Sandbox3

If you're okay with broken things, fine. I'll yield. Regardless if you have never had an issue...the bug is there and the potential is there.

{{{text|{{{2}}}}}} would still have to be defined as "text=" since named parameters have to be called. You can try it, but I don't think that'll work.

It's not broken. It's also much simpler to use anonymous parameters, which is why it 's the most common implementation in most wikis and examples. There is very, very rarely justification to use '=' in font resize or color template. In the rare case that it is justifiable, it is easily circumvented. For Alerts, that's not the case, so we use named params.

And @DoubleYou's example will work fine I think. The param is anonymous and being set to the equivalent of 'text'.

 

---

On another note, I am poised to make the keyword changes to Template:Fc, because I want to bring up another likely point of contention. I think the use of our highlight text color for use with inline headings is yuck ... especially when many are used together. It's too bright for one (brighter than our actual headings) and was meant for use with things like Template:Ui and emphasis text, where we really do want to make the text very obvious without using a specific color.

This is why I have always used salmon for inline headings. It is close to neutral and has a color temp very close to our standard text, so it's easy to identify without too much bling. See the Wiki Maintenance guide as an example. This looked terrible (killed my eyes) with Template:Ui and Template:Fc using ilheading. It functions exactly as intended now though.

So ... I want to repurpose the ilheading keyword to salmon and collapse the others to 2 at most for any one color. Let the debate begin.

[TechAngel85]

3 minutes ago, z929669 said:

And @DoubleYou's example will work fine I think. The param is anonymous and being set to the equivalent of 'text'.

 

---

On another note, I am poised to make the keyword changes to Template:Fc, because I want to bring up another likely point of contention. I think the use of our highlight text color for use with inline headings is yuck ... especially when many are used together. It's too bright for one (brighter than our actual headings) and was meant for use with things like Template:Ui and emphasis text, where we really do want to make the text very obvious without using a specific color.

This is why I have always used salmon for inline headings. It is close to neutral and has a color temp very close to our standard text, so it's easy to identify without too much bling. See the Wiki Maintenance guide as an example. This looked terrible (killed my eyes) with Template:Ui and Template:Fc using ilheading. It functions exactly as intended now though.

So ... I want to repurpose the ilheading keyword to salmon and collapse the others to 2 at most for any one color. Let the debate begin.

See update to previous post and reply.

RE: Inline Heading
Honestly, I rarely do this so you guys can do what makes most sense to you. I exclusively used the wiki markup for headings. I agree the hltx should be used only for emphasis, when needed. The only other one that would need 3 is red. Others I'm fine with 2.

 

[z929669]

12 minutes ago, TechAngel85 said:

Since "{{{text|{{{2}}}}}}" works, this gives the fix (if needed) while will allowing users to skip the "text=" in most cases, I agree this is the best of both worlds.

So if we can agree on that and the keyword reduction is a go, I will go ahead and post my changes to Dev for review. I have everyone ready in Notepad. Just been waiting to nail down the final draft.

Works for me as long as no existing template calls break. That satisfies all criteria then and everyone is happy. If we do this, all I ask is that 'text=' NOT be used unless required for compat purposes. So always default to anonymous names, else we will have an inconsistency with that template (all future Replace Text changes having 'gotchas').

[TechAngel85]

Well, I guess we don't need really dropped, add or update.

[z929669]

4 minutes ago, TechAngel85 said:

Well, I guess we don't really dropped, add or update.

don't really 'need' u mean? (Also see my previous response to your previous)

[TechAngel85]

3 minutes ago, z929669 said:

don't really 'need' u mean? (Also see my previous response to your previous)

LOL. Updated.

 

5 minutes ago, z929669 said:

Works for me as long as no existing template calls break. That satisfies all criteria then and everyone is happy. If we do this, all I ask is that 'text=' NOT be used unless required for compat purposes. So always default to anonymous names, else we will have an inconsistency with that template (all future Replace Text changes having 'gotchas').

Works without needing to use Replace Text. However, anywhere the "fix" is used so that "=" character will display would include "text=". Other than that, there would be only the default, anonymous parameters in use. So DY's solutions works for both, but would require two Replace Text runs for future changes.

[z929669]

12 minutes ago, TechAngel85 said:

LOL. Updated.

Works without needing to use Replace Text. However, anywhere the "fix" is used so that "=" character will display would include "text=". Other than that, there would be only the default, anonymous parameters in use. So DY's solutions works for both, but would require two Replace Text runs for future changes.

Go ahead and do your worst to Fc/Fs in DEV then to see if there are any gotchas. If you are OK with it, please add 'heading' or 'ilheading' keyword for salmon. If it all works like we want, I will port this update to live along with all of the other page/template updates I have going in DEV once we have the RD stuff finalized.

[TechAngel85]

Okay it's on up on Dev. The only things that are broken on those using keywords no longer supported, which is what Replace Text will be used for. I made a few additional changes to the color table and included the edits from the live page. Definitely need to refine Usage in the table as I just quickly put those in. All advanced editing beyond this template is pointed to the Site Color Pallet, so this one is focused down.

@Citizens
Those that may be reading and keeping up, we apologize that you don't get to see the products "in-the-making" due to us using our development environment. However, we felt we could be more open with our development processes. Therefore, you are all getting a glimpse into our development process in action (our back-and-forth, debating and comprising, testing of several integrations before release, teamwork, etc.) As such, please free to jump in with any comments, feedback, questions, and/or suggestions! 

[z929669]

13 minutes ago, TechAngel85 said:

Okay it's on up on Dev. The only things that are broken on those using keywords no longer supported, which is what Replace Text will be used for. I made a few additional changes to the color table and included the edits from the live page. Definitely need to refine Usage in the table as I just quickly put those in. All advanced editing beyond this template is pointed to the Site Color Pallet, so this one is focused down.

You may want to look at some of the changes I made to the Project:SiteColorPallet No changes to theme colors, just the doc.

This will need to be updated in accordance with the template table (or we can simply refer to the template table and omit the keywords from the SiteColorPallet table). I'm setting this page up to articulate with the wiki guidelines so that it can be used as a quick reference for editors.

[TechAngel85]

4 minutes ago, z929669 said:

You may want to look at some of the changes I made to the Project:SiteColorPallet No changes to theme colors, just the doc.

This will need to be updated in accordance with the template table (or we can simply refer to the template table and omit the keywords from the SiteColorPallet table). I'm setting this page up to articulate with the wiki guidelines so that it can be used as a quick reference for editors.

Yeah, we'll just need to update the keywords on the Site Color Pallet. I, or anyone, can do that, if the keywords are final. I did update them from what I posted here, so look them over.

I liked the idea of less maintenance so I removed the add, drop, and update keywords and provided usage scenarios instead for guidance. Removed "important" and opted for "brighter" stead. Did the same for dimmer, which is now "dim" and "darker".

[TechAngel85]

It'll be a lot to replace up front, but once complete it'll be much more optimized and easier to maintain in the future...assuming we don't let bloat creep back in. Considering this template's high use, I thought it was important to optimize it as much as made sense to reduce its load. Thanks for taking the time!

[Greg]

2 hours ago, TechAngel85 said:

Since "{{{text|{{{2}}}}}}" works, this gives the fix (if needed) while will allowing users to skip the "text=" in most cases, I agree this is the best of both worlds.

So if we can agree on that and the keyword reduction is a go, I will go ahead and post my changes to Dev for review. I have everyone ready in Notepad. Just been waiting to nail down the final draft.

I must be missing something because this seems to work fine for me:

{{fc|1=highlight|2=So what you are saying is that we don't care about bugs regarding the "=" character in the template?}}