A base16 entry point for using default HTML font size (16px)

[yvonnetangsu]

READY FOR REVIEW/NOT READY

• (Edit the above to reflect status)

Summary

• Add an entry point for anyone who wants to use the default HTML root font size

Needed By (Date)

• When does this need to be merged by?

Urgency

• How critical is this PR?

Steps to Test

1. Do this
2. Then this
3. Then this

Affected Projects or Products

• Does this PR impact any particular projects, products, or modules?

Associated Issues and/or People

• JIRA ticket
• Other PRs
• Any other contextual information that might be helpful (e.g., description of a bug that this PR fixes, new functionality that it adds, etc.)
• Anyone who should be notified? (@mention them here)

See Also

• PR Checklist

[yvonnetangsu]

An idea - what do you think? It's working well in the preview. (it won't generate a netlify preview because I'm basing this off of v8 but local preview looks good to me)

Devs can still use py-123, text-123 etc and they'll calculate so that it still renders 123px

[yvonnetangsu]

This is the trick - updating this scale factor I use for the text-__ and spacing (eg, py-___) utilties

[yvonnetangsu]

I might get rid of this and just add a multiplier in the utility instead, that way both index and index-base16 can share the same set of these variables

[sherakama]

This seems like a useful thing; however, my knee-jerk reaction to this is that it seems like a lot of extra code for the project and maintainer (you) to keep in sync with any future changes or additions. Does this work stem from the BM settings?

[yvonnetangsu]

This seems like a useful thing; however, my knee-jerk reaction to this is that it seems like a lot of extra code for the project and maintainer (you) to keep in sync with any future changes or additions. Does this work stem from the BM settings?

Nope - not related to the BM settings at all. One reason is that the 10px effective HTML root font size is somewhat of an older practice and it was just there to encourage developers to use rem units. It does add extra work sometimes for developers who want to use outside component libraries, eg, MUI - even though we do use our own font sizes anyway, but it would be nice to have things look reasonable without custom styling when we install them. Also, the way the TW v4 utilities can take multiplers means I can make the developer experiences just as good as if we use a 10px root font size, ie, they can still do text-100 = font-size: 100px (but in rem equivalent). it was actually not much added code because of the multiplier.

[yvonnetangsu]

This seems like a useful thing; however, my knee-jerk reaction to this is that it seems like a lot of extra code for the project and maintainer (you) to keep in sync with any future changes or additions. Does this work stem from the BM settings?

This was also a pain point that was brought up a couples times before by some devs, so I'd like to offer this option 😄 Thankfully with TW v4, the amount of extra code and effort is way lower

[sherakama]

Also, the way the TW v4 utilities can take multiplers means I can make the developer experiences just as good as if we use a 10px root font size, ie, they can still do text-100 = font-size: 100px (but in rem equivalent). it was actually not much added code because of the multiplier.

If the DX is still just as good, and the output is still good, what is the reason to go with the 10px base at all?

[yvonnetangsu]

Also, the way the TW v4 utilities can take multiplers means I can make the developer experiences just as good as if we use a 10px root font size, ie, they can still do text-100 = font-size: 100px (but in rem equivalent). it was actually not much added code because of the multiplier.

If the DX is still just as good, and the output is still good, what is the reason to go with the 10px base at all?

Partly for backward compatibility, eg, I want to upgrade an old project to decanter v8 quick, but I don't want to have to go back and change all the places where I added top-[10.2rem] etc. I think the 16 base dev experience is almost as good, but not 100% equivalent, eg, if they don't use the TW classes without the brackets (eg, py-123) in cases but rather straight CSS is used, they'll to do the manual conversion to rem unit themselves (divide px value by 16).

We do have a choice here though, do we want to make base16 the default (import 'decanter' and not import 'decanter/base16') or base10 the default?

[sherakama]

It seems reasonable to move towards the default base of 16. Another option for you to consider is leaving the base 10 for Decanter 8 and shortly after releasing a base 16 Decanter 9. Spreading out the amount of changes will make it easier for those to catch up.

[yvonnetangsu]

It seems reasonable to move towards the default base of 16. Another option for you to consider is leaving the base 10 for Decanter 8 and shortly after releasing a base 16 Decanter 9. Spreading out the amount of changes will make it easier for those to catch up.

That's possible too. Hmmm this could be a topic for dev chat 😄

[rebeccahongsf]

Chiming in with my two nickels!

So the decoupled Drupal starter was built with a mix of Tailwind and Decanter custom utilities. Because of how it’s configured, all styles (aside from Decanter modular typography/spacing) in that ecosystem use a base 16. The reasoning behind that was to make referencing Tailwind documentation easier.

While I’m a big fan of base 10 for simpler calculations and less mental math, we should consider providing an option for both bases in v8 especially since this would increase the appeal of upgrading the decoupled Drupal side to fully move to Decanter v8. Setting the default to base 16 would also let us more easily point newer folks to Tailwind documentation and could help reduce the amount of custom documentation we need to maintain in that area.

With that all said, supporting both bases long term may mean maintaining multiple paths which might not be ideal, especially from a maintenance standpoint. I’d personally love to keep both options butI’ll defer to Yvonne on the maintenance and future upgrade strategy.

+1 -- I'd love to hear other dev's thoughts as well so perhaps a topic to have during our next dev chat (I'll go ahead and add it as an agenda item) 😆

[yvonnetangsu]

Chiming in with my two nickels!

So the decoupled Drupal starter was built with a mix of Tailwind and Decanter custom utilities. Because of how it’s configured, all styles (aside from Decanter modular typography/spacing) in that ecosystem use a base 16. The reasoning behind that was to make referencing Tailwind documentation easier.

While I’m a big fan of base 10 for simpler calculations and less mental math, we should consider providing an option for both bases in v8 especially since this would increase the appeal of upgrading the decoupled Drupal side to fully move to Decanter v8. Setting the default to base 16 would also let us more easily point newer folks to Tailwind documentation and could help reduce the amount of custom documentation we need to maintain in that area.

With that all said, supporting both bases long term may mean maintaining multiple paths which might not be ideal, especially from a maintenance standpoint. I’d personally love to keep both options butI’ll defer to Yvonne on the maintenance and future upgrade strategy.

+1 -- I'd love to hear other dev's thoughts as well so perhaps a topic to have during our next dev chat (I'll go ahead and add it as an agenda item) 😆

Thank you for your helpful feedback @rebeccahongsf! It's good to know that the decoupled Drupal starter uses base 16. In this case, I'm leaning towards making base16 the default, but still providing backward compatibility support for base10. However, I'll be deprecating base10 in Decanter v8, so starting v9, I'll remove support for base10.