Buddypress rem font sizing & twentyfifteen theme issues

[hnla]

The impending release of Twentyfifteen demonstrates the weakness and possible issues that can arise fom BuddyPress stating font sizes too emphatically.

In this instance BP states a font-size of font-size: 0.8rem; on a grouped ruleset for buttons and other classed elements ( overriding already set font sizes in the bp sheet oddly )

Problem is that at present (2015 is at this date still ?beta) twentyfifteen is attempting to use the html body font reduction technique to arrive at an easy calculations for setting rem/em sizes at a rounded value e.g '1' == 10px '1.4' == 14px and we then are inadvertently saying .button(font-size: 0.8rem) or 8px. 8px is below what is considered legible and we'll need to do something about this.

Our options are limited and none are infallible; we could simply not state a size and leave that up to themes or devs to handle or we could change to using percentage units (my first consideration and which means that we would calculate that value from the body size in this instance)

Any relative measure is however going to have possible issues and is too an extent unpredictable as to resulting interpreted size.

I have seen issues with BP on some themes as we have some percentage units lying about and those in the themes suffer from compound errors and are computing to be similarly small in size.

We may have only one safe option in reality, which I mentioned a while back, that of using the largely historically neglected 'keywords'.

Keywords were generally considered unsafe due to the lack of specification to computed sizes and thus wide variences amongst browsers, this I believe is not such an issue any longer.

I would suggest we change this BP ruleset to use the keyword 'small' (in testing computing to 13px & 'medium' to 16xp & in twentyfourteen is almost equal to the size we achieve using 80%)

ruleset @L761:

#buddypress button,
#buddypress a.button,
#buddypress input[type=submit],
#buddypress input[type=button],
#buddypress input[type=reset],
#buddypress ul.button-nav li a,
#buddypress div.generic-button a,
#buddypress .comment-reply-link,
a.bp-title-button {
	background: #fff; /* Old browsers */
	border: 1px solid #ccc;
	color: #777;
	font-size: .8rem;
	cursor: pointer;
	outline: none;
	padding: 4px 10px;
	text-align: center;
	text-decoration: none;
}

[DJPaul]

At WCSF, we had a few discussions around this type of problem. I need to write up a trac ticket, but remind me at the London contributor day tomorrow and you can tell me what you think, and then we'll loop back to here.

[hnla]

Darn never CCed myself on this ticket(wish we could change trac to auto include ticket creator)

bumping this so we don't forget, we'll need to bite the bullet on this and audit bp styles for all font properties and find a better approach before WP lands with 2015 and we release 2.2

[boonebgorges]

WP 4.1 is out, which means that Twenty Fifteen is out. What's the status of this?

[hnla]

Pending!
Checked again in an updated copy of 2015 and the issue persists.

Think we have no viable option than to change ALL font size units expressed as '%', 'em', 'rem' primarily where we are attempting to produce a smaller scaled font size, which is where the trouble really occurs in illegible text. I have noticed some oddities with 2015 where it sets rather large font size for text input giving rise to variances where we set size on dir search but don't on filter select.

It will mean a rather careful scan through our styles halting at each ruleset evaluating the font size and element it's targeting for a change to keyword, then checking that through the range of twenty* themes.

As above my initial checks seemed to uphold the assertion that the keyword use does pretty much approximate to our original intent in visual size using '%' or 'rems' with any actual variance being really quite negligible and doubt would be noticed.

I see no reason we can't get this dealt with before BP RC1, it's not great fun but we haven't got too many font size properties declared, main chore is checking in each twenty* theme.

I have an suggestion as to another approach to making this change that would avoid affecting all themes known and unknown which would be to provide complimentary stylesheets that would be loaded for twenty* themes keeping BP working smoothly with each of those WP themes, adjusting rules only where absolutely necessary (twentyfourteen has issues in it's narrow template which could be adjusted for BP screens with a simple targeted rule, that would be great to be able to apply)

My initial thought was a simple switch checking for loaded theme name and adding a sheet 'bp-2014.css'

No this doesn't address many themes but we can't do that but we could perhaps present BP as being and checked style wise for all the wp default themes?

[boonebgorges]

As above my initial checks seemed to uphold the assertion that the keyword use does pretty much approximate to our original intent in visual size using '%' or 'rems' with any actual variance being really quite negligible and doubt would be noticed.

This plan sounds fine to me. Let's go with the keyword approach, as long as it looks pretty good in the twenty* themes.

provide complimentary stylesheets that would be loaded for twenty* themes

The team has definitely discussed this before, but perhaps in IRC. I think this idea deserves its own Trac ticket. I'm not sure I think it's a great idea, but in any case it's a much bigger change than what's being suggested here, so I wouldn't want to hold up the current improvement by dwelling on the broader topic.

[hnla]

Ok we'll go with changes based on keywords, and a checking routine to include the twenty* themes.

If, though, there were issues between those themes and the changes we would be a little stuck for approaches to filtering rules/properties but we can cross that bridge as/when... or - having another staggering brainwave - we added a new body class, dropping the theme name in.

I'll try and get a patch up by end of weekend or late Monday.

[hnla]

Patch adjusts font sizes to font keywords where issues are found in 2015 theme.

Checks across the twenty* themes to ensure changes are acceptable. Changes have at most a 1.4 pixel variance that will have little consequence but gains from expressing proper pixel value not a point division forcing browsers to round up/down

All font size properties checked in turn to ensure no issues; where percentage sizes are used in lists these prove to mainly be acceptable and not causing any particular issues as their parent sizes are set and these are adjustments up or down from those.

[hnla]

Font size unit adjustments

[boonebgorges]

hnla - Thanks so much for doing this review. The change looks good to me, but I would like to get sign-off from another dev before moving forward with it.

[hnla]

but I would like to get sign-off from another dev before moving forward with it.

Absolutely concur, in fact half considered a bpdevel post just to highlight these changes and request any feedback/confirmation on them as appearing ok in 2015. I think I was fairly thorough checking each ruleset in turn that described a font size property against screen rendition but may have have missed something.

Working through all the BP acreens in 2015 did bring me back to thinking again about the notion of adding small support styles for individual WP twenty* themes, there are times when BP component screens really do look sub optimal in layout and need tweaking to display better.

[djpaul]

In 9279:

Templates: improve theme compatibility for how we set small font sizes.

The change is best demonstrated by the TwentyFifteen theme, which uses the HTML body font size reduction technique to facilitate easy calculations for setting REM/EM font sizes; e.g. 1 == 10px, 1.4 == 14px. Whwn we use a REM size < 1, we're reducing these font sizes even further, and can sometime get too small and hinder legibility (specifically for the .button element).

Using small is our current best idea for smaller font sizes across all different types of themes / font sizing techniques.

Fixes #6022, props hnla