Adds UA blacklist to @font-face test as a stopgap for false positives #1147

Merged
merged 1 commit into from Dec 6, 2013

Projects

None yet

9 participants

@Wilto
Contributor
Wilto commented Dec 6, 2013

… at least until we can come up with a mo’ better feature test. Ref. issue #1120.

@davatron5000

+1 on this. I know Modernizr tries to avoid UA sniffs, but this should be a pretty select group of known false positives that most @font-face detection people aren't making accommodations for.

@paulirish
Member

@davatron5000 it's all good. We value accuracy more than theoretical purity. We have a few other UA blacklists in the suite. ;)

@patrickkettner
Member

only one code nit, then im good to merge.

@davatron5000 we do it from time to time, as a last resort.

see fileinput, history, and data-uri's

@paulirish
Member

Actually one larger thing.

Let's skip the testStyles() call completely if we hit the blacklist. Don't need to do all the work on these shitty device if we know we're going to ignore their answer anyway.

@patrickkettner
Member

ah, great call @paulirish

@Wilto
Contributor
Wilto commented Dec 6, 2013

Cheah cheah; on it.

@stucox
Member
stucox commented Dec 6, 2013

… at least until we can come up with a mo’ better feature test. Ref. issue #1120.

e.g. inject a custom font with some defining feature we can use to distinguish it from a native font, like a excessively wide character we can measure? Although that would have to be asynchronous 😦

@patrickkettner
Member

@stucox that was my thought.
Might be able to do a font-face that just renames a local monospace one, and compare widths. That wouldn't catch the IE bug, though. I wonder what the computed property of IE's font-face'd stuff is

@Wilto
Contributor
Wilto commented Dec 6, 2013

Refactored based on the above, tested on the following:

Android 1.6: Passes naturally
Android 2.0: Unconfirmed, but should be blacklisted
Android 2.1: Blacklisted
Android 2.2: Passes naturally
WP 7: Blacklisted
WP 7.5: Blacklisted
WP 7.8: Blacklisted
WP 8: Passes naturally
WP 7.5: Blacklisted
WebOS 1.4: Blacklisted
WebOS 2.0: Blacklisted
WebOS 2.0.1: Blacklisted

All the grown-up browsers pass as expected—current Safari, Chrome, Firefox, iOS, Android native/Chrome. Additionally, here are a few posts that mention @font-face support breaking as of 2.0, but working as expected as of the 2.2 update:
http://stackoverflow.com/questions/3200069/css-fonts-on-android
http://archivist.incutio.com/viewlist/css-discuss/115960

@patrickkettner
Member

could you rebase to a single commit?

@Wilto Wilto Adds UA blacklist to @font-face test as a stopgap.
This addresses the issue of false positives on WebOS, Android 2.0/2.1,
and Windows Phone 7-7.8 while we consider a more robust feature test.
Ref. #1120.
949d770
@Wilto
Contributor
Wilto commented Dec 6, 2013

Done and done.

@paulirish
Member

👍

@patrickkettner patrickkettner merged commit 61e72d2 into Modernizr:master Dec 6, 2013

1 check passed

default The Travis CI build passed
Details
@patrickkettner
Member

Thanks, @Wilto!

@Integralist

Good to see it's not only us at BBC News who had to blacklist certain devices because of false positives. See this post by @kaelig http://blog.kaelig.fr/post/33373448491/testing-font-face-support-on-mobile-and-tablet back in Oct 2012.

@patrickkettner
Member

Ah, thanks for adding this. Headsup, @kaelig, the github link is broken. I believe you are looking for https://github.com/Modernizr/Modernizr/search?q=font-face&type=Issues&state=open :]

@patrickkettner
Member

For what its worth, it seems that android 2.1 has the same behavior as windows (ie it can @font-face local fonts only).

heres a demo

@kaelig
kaelig commented Dec 9, 2013

Thanks @patrickkettner, I updated the link.

@paulirish
Member

cc @viljamis for good measure

@RoelN
RoelN commented Dec 11, 2013

@patrickkettner Sorry to wiggly my way into this discussion, what's the IE bug? If you're talking about the solution @stucox mentioned (which is what mine does), I'm not aware of a bug. Or are you talking about the fact that IE8 and older need the external EOT font file?

I find this stuff very interesting but I'm still quite new to writing these kinds of tests, so pardon my n00bness. Is UA sniffing preferable because it's synchronous?

@patrickkettner
Member

Not at all, @RoelN. I was referring to mobile IE's local-only font-face support. You can use @font-face, and use a local: "fontname" to rename fonts, which is pretty much useless.

UA sniffing is preferred at the moment just because it is known quantity. synchronous is always preferred. We can't do any external downloads in modernizr, so we would need to base64 the font file, which causes a lot of bloat in the test.

@RoelN
RoelN commented Dec 11, 2013

I see, thanks! Yeah, the base64'ed TTF added about 1150 bytes to the Javascript. Base64'ing the EOT isn't possible as that's not supported by IE8 and below. (Just to be clear, all other browser don't need an external file.)

@timohanninen

When will this be included to the production version? Sorry that I'm bothering you guys and asking, but I am absolute worthless in reading Github.

Member

Hey @timohanninen, once we ship v 3, this will be included. You could always clone the repo and build it yourself though.

@stucox stucox referenced this pull request Mar 2, 2014
Closed

v3.0 release notes #805

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