Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Utilize text-wrap: balance when supported #11

Open
adamschwartz opened this issue Jul 6, 2023 · 0 comments
Open

Utilize text-wrap: balance when supported #11

adamschwartz opened this issue Jul 6, 2023 · 0 comments

Comments

@adamschwartz
Copy link

adamschwartz commented Jul 6, 2023

Now that text-wrap: balance is supported in Chrome (as of 114), it might make sense to reconfigure this library as more of a fallback.

This is the current initialization:

// pass in a string of selectors to be balanced.
// if you didnt specify any, thats ok! We'll just
// balance anything with the balance-text class
var textBalancer = function (selectors) {

Perhaps instead we could change that to something like the following:

var textBalancer

if (CSS.supports('text-wrap: balance')) {
   textBalancer = function(selectors) {
     // Either noop, or perhaps console.log something about deferring to the native CSS
   }
   
} else {
  textBalancer = function (selectors) {
     // Actually initialize the library...
  }
}

Where text-wrap: balance is supported, this would speed up runtime initialization as the library would never need to be initialized. But more importantly there would likely be great rendering performance benefits to a native balancing algorithm than one implemented in the way this library works. With an implementation like this, of course authors would need to know they additionally need to place text-wrap: balance in their CSS code for the selectors they pass in. Alternatively, instead of a noop, the library could apply this CSS to the selectors for them, but to me this seems unnecessary when longterm the solution will (likely, hopefully) be to use CSS and remove the library entirely.

Curious to hear others’ thoughts!

(Also @mbeswetherick, happy to take a stab at a PR if you support the idea!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant