You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
functiongetStyle(el,cssprop){if(document.defaultView&&document.defaultView.getComputedStyle)returndocument.defaultView.getComputedStyle(el,'')[cssprop];// W3Cif(el.currentStyle)returnel.currentStyle[cssprop];// IE8 and earlierreturnel.style[cssprop];// try to get inline style}
The text was updated successfully, but these errors were encountered:
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
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.
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 )
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.
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, inparseNode
, ifoptions.sizing
warrants it, check the text size of each text node's parent and setoptions.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 togetComputedStyle
:The text was updated successfully, but these errors were encountered: