IP.Board 3.3 Beta: please, remove '<strong>' from user name on moderating team page

[Adriano Faria]

Now it is like that:

<td><strong>{parse template="userHoverCard" group="global" params="$info"}</strong></td>

If we use a hook to show group colors on user links, will show everybody as if they were from the same group, when they're not: User1 is different of User2; I mean, they're from different groups and the way it is now, will appear both like: User1 and User2.

Since the group separation won't be reverted, at least let us show the groups as how they really are.

Thank you.

[Ryan H.]

This is also a problem in the profile comments/feed area and Recent Status Updates block in 3.2.

[Marcher Technologies]

....my 2 cents....

font-weight:bold;

... why in the blazes are strong tags being used "at all" anywhere.
its akin to using center.... why?
This is not the 90's.... HTML tag usage for styling instead of classes is flat annoying, and highly dated.

[Michael]

<strong> is perfectly fine, it's purpose is not to bold the text, that's just how browsers choose to display it's intended purpose (to give an element strong emphasis).

[Ryan H.]

....my 2 cents....

font-weight:bold;

... why in the blazes are strong tags being used "at all" anywhere.
its akin to using center.... why?
This is not the 90's.... HTML tag usage for styling instead of classes is flat annoying, and highly dated.

Not really; it's actually a semantic tag, like em or the h# titles. The browser assumes certain styles in each case.

If you're using it just for the style, then yes, maybe you're doing it wrong.

[Marcher Technologies]

Not really; it's actually a semantic tag, like em or the h# titles. The browser assumes certain styles in each case.

If you're using it just for the style, then yes, maybe you're doing it wrong.

I do not use it... I vastly prefer a consistent experience across all browsers.
Letting the browser "assume" how something looks is..... I mean really now?
How is that a good idea? How is it anything more than lazy?
And what semantic value is gained from a <strong>?
Have not seen any crawler pick it up especially over any css usage.
H tags, but of course...

[Ryan H.]

I do not use it... I vastly prefer a consistent experience across all browsers.

Letting the browser "assume" how something looks is..... I mean really now?

How is that different from any other tag you use on a daily basis? Standards mean that every element has some styles implied, and with small exceptions those are pretty much identical in every single browser. A list always has certain margin and padding and solid bullets. A header tag always has a certain font size. Links are always underlined and the same blue/red/purple colors. ...a strong tag is always bold.

But this is totally off topic.

[Marcher Technologies]

How is that different from any other tag you use on a daily basis? Standards mean that every element has some styles implied, and with small exceptions those are pretty much identical in every single browser. A list always has certain margin and padding and solid bullets. A header tag always has a certain font size. Links are always underlined and the same blue/red/purple colors. ...a strong tag is always bold.

But this is totally off topic.

(It is off-topic, a quite large assumption was made there)
The difference is, we do not let these implied styles just sit useless.
A link may be redefined color-wise, as may a list.
Strong makes an invalid assumption to the skin.
Once an element is set to a font-weight:bold, it is working backwards to not apply it within....
which is precisely why using a <span style='font-weight:normal;'> as group prefix does not resolve the issue at hand.
hence my utter beef with the strong tag as a whole... you cannot make it act properly in any manner, it outweighs any css defined within it regarding font-weight.
It is an assumption that the skinner does not want normal font-weight.... or will go clean them out.
in a nutshell, strong does more than imply the browser stock, it enforces it.

[Rikki]

Strong is semantic and fine to use. Our CSS reset takes care of making it consistent. I'm not sure why you're all arguing about it :)

That said, I see the issue with using it here. I'll submit a bug so we can remove that.