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

Autosizing Twemoji by text size #56

Closed
lewisje opened this issue Mar 30, 2015 · 3 comments
Closed

Autosizing Twemoji by text size #56

lewisje opened this issue Mar 30, 2015 · 3 comments

Comments

@lewisje
Copy link

lewisje commented Mar 30, 2015

It would be nice if there were a parameter to control whether the Twemoji node-parser first determines the text size of the element to add the emoji to, instead of picking just one size that may be much too large or much too small; I tried making the images text-size-dependent without hacking Twemoji itself, but every time I tried, the browser kept loading the images serially.

My idea is to call the parameter options.sizing and then, in parseNode, if options.sizing warrants it, check the text size of each text node's parent and set options.size to a suitable value (my idea is '16x16' if text size is less than 36 pixels or not found, '36x36' if text size is at least 36 but less than 72 pixels, and '72x72' otherwise) before executing the callback function.

Maybe the size thresholds could be lowered a bit, but I'm afraid of breaking layouts by making these inline images much larger than the text; if I weren't, my idea would be based on geometric means: '36x36' if text size is between 24 and 50.91 pixels inclusive, '16x16' if below, '72x72' if above. (Maybe arithmetic means: 26 and 54? Maybe I should figure out how to specifically get the height of the capital letters and test that against the thresholds?)

In my experiments, I've set options.sizing to specify this text-dependent emoji sizing by default, but maybe you don't want to change the semantics of Twemoji for existing users; the reason I'm not sending in a pull request yet is that I don't know whether the new semantics would be such an improvement that they ought to be pushed out to users who don't opt out.

I am using the following helper function to find the text size ('fontSize' specifically) of each text node's parent node, a cross-browser alternative to getComputedStyle:

  function getStyle(el, cssprop) {
    if (document.defaultView && document.defaultView.getComputedStyle)
      return document.defaultView.getComputedStyle(el, '')[cssprop]; // W3C
    if (el.currentStyle) return el.currentStyle[cssprop]; // IE8 and earlier
    return el.style[cssprop]; // try to get inline style
  }
@WebReflection
Copy link
Contributor

twemoji.js gives you this ability, everything else might fit or not users needs and expectations.

As example, I would never want different sizes for the following reasons:

  • users won't benefit from CDN anymore
  • having too many different sizes per page is confusing anyway

You can parse headers a part or before the rest of the document via querySelectorAll or even getElementsByTagNames and use the big one there, and stick with default for the rest.

The way we've done until today, the way that works already since the beginning, is specified in the README

img.emoji {
   height: 1em;
   width: 1em;
   margin: 0 .05em 0 .1em;
   vertical-align: -0.1em;
}

The reason what you suggest won't work is also that size is relative, and IPS (retina) might need different ratio than the one I decide.

As summary: the lower level ability to parse with different sizes is built-in, how you want to use it is up to you. Another option that does so much magic does not seem to be a good fit for this library, maybe you can write a jQuery plugin or something that does this through this library API.

Feel free to ask more, if needed.

@WebReflection
Copy link
Contributor

P.S. also consider the SVG version, that scales any size but it's slightly less compatible ( old browsers won't show them, slower too in non modern hardware )

@lewisje
Copy link
Author

lewisje commented Mar 30, 2015

I was interested in picking out the PNGs by size-classes, so that even if I do decide to have the browser scale them up or down, they'll have the best image quality, while also being supported in older browsers. I'll keep my fork going.

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

No branches or pull requests

2 participants