planet.webcompat.com

otsukare by Karl Dubost at

Yet another Webcompat issue with the characters being cut in the bottom, this will join the other ones, such as cross characters not well centered in a rounded box and many other cases. What about it?

The sans-serif issue

All of these have the same pattern. They rely on the intrinsic font features to get the right design. So… this morning was another of this case. Take this very simple CSS rule:

.gsc-control-cse, .gsc-control-cse .gsc-table-result {
    width: 100%;
    font-family: Arial, sans-serif;
    font-size: 13px;
}

Nothing fancy about it. It includes Arial, a widely used font and it gives a sans-serif fallback. It seems to be a sound and fail-safe choice.

Well… meet the land of mobile and your font declaration doesn't seem to be that reliable anymore. Mobile browsers have different default fonts on Android.

The sans-serif doesn't mean the same thing in all browsers on the same OS.

For example, for sans-serif and western languages

  • Chrome: Roboto
  • Firefox: Clear Sans

If you use Chinese or Japanese characters, the default will be different.

Fix The Users Woes On Mobile

Why is it happening so often? Same story, the web developers didn't have time, budget to test on all browsers. They probably tested on Chrome and Safari (iOS) and they decided to make a pass on Firefox Android. And because fonts have different features, they do not behave the same to line-height, box sizes and so on. Clear Sans and Roboto are different enough that it creates breakage on some sites.

If you test only on Chrome Android (you should not), but let says we reached the shores of Friday… and it's time to deploy at 5pm. This is your fix:

.gsc-control-cse, .gsc-control-cse .gsc-table-result {
    width: 100%;
    font-family: Arial, Roboto, sans-serif;
    font-size: 13px;
}

Name the fonts available on mobile OS, you expect the design to be working on. It's still not universally accessible and will not make it reliable in all cases, but it will cover a lot of cases. It will also make your Firefox Android users less grumpy and your Mondays will be brighter.

Otsukare!

When Can I Use updates by Alexis Deveria at

Caniuse has added new options to select exactly which browser versions you're interested in seeing support data for. By default, displayed versions on caniuse are based solely on usage, which is what matters in most cases.

But in some cases you may be specifically interested in supporting browser version ranges starting at a given version, or from a specific date. Your company may have policies on exactly how far back browsers should be supported. The new browser set feature should help in showing you just the information you need.

To get started, look in the Settings panel, find the "browser set" section and click "Add new set".

A browser set is a list of rules (based on browserslist) that determines which browser versions appear in support tables. For example you can now select "last 5 Firefox versions" or "Edge versions > 14" or even "All browser versions released since 2016".

Sets can be imported & exported, and links can be generated that include selected browser set settings so you can share a feature table that includes the exact browsers you care about. If you find any issues with this new tool, please file an issue. Thanks!

otsukare by Karl Dubost at

I'm a uBlock and uMatrix user with a very agressive setting. I block everything. It makes the Web faster, more performant, less prone to bugs and security issues. In my text only version of the Web, there are surprises. Sites entirely made of JavaScript which are not at all readable. It's a kind of Occam's razor where it helps me decide if I should spend time to configure my browser to make the page more readable. If the cost/benefit ratio is too high, I just ignore the site.

But let me introduce you to the "Fatwigoo", an interesting animal which is populating the CSS-less and JS-less landscape of Web pages. You can choose to pronounce it "Fa-twee-goo" or "fat-wee-goo". I prefer the latter. You can partly reproduce the screenshot (below) with going to this article on A List Apart with Firefox and select in the View Menu ➜ Page Style ➜ No Style.

These are created by the inline SVG in the page. These SVG icons are stretching by default to the width of the viewport. Nothing wrong with that, but you can improve the rendering for people like me who prefers sad-boring-peaceful web pages.

How To Solve The Fatwigoo

The icon for twitter in this page is represented by this SVG.

<svg
    version="1.1"
    xmlns="http://www.w3.org/2000/svg"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    x="0px" y="0px"
    enable-background="new 0 0 274 224"
    viewBox="0 0 274 274"
    xml:space="preserve">
    <path d="M273.7,27.2c-10.1,4.5-20.9,7.5-32.2,8.8c11.6-6.9,20.5-17.9,24.7-31c-10.8,6.4-22.8,11.1-35.6,13.6
        C220.3,7.7,205.7,0.9,189.6,0.9c-31,0-56.1,25.1-56.1,56.1c0,4.4,0.5,8.7,1.5,12.8C88.3,67.4,47,45.1,19.3,11.2
        c-4.8,8.3-7.6,17.9-7.6,28.2c0,19.5,9.9,36.6,25,46.7c-9.2-0.3-17.8-2.8-25.4-7c0,0.2,0,0.5,0,0.7c0,27.2,19.3,49.8,45,55
        c-4.7,1.3-9.7,2-14.8,2c-3.6,0-7.1-0.4-10.6-1c7.1,22.3,27.9,38.5,52.4,39c-19.2,15-43.4,24-69.7,24c-4.5,0-9-0.3-13.4-0.8
        c24.8,15.9,54.3,25.2,86,25.2c103.2,0,159.6-85.5,159.6-159.6c0-2.4-0.1-4.9-0.2-7.3C256.7,48.3,266.2,38.5,273.7,27.2z">
    </path>
</svg>

Throw in there a width attribute.

<svg
    version="1.1"
    xmlns="http://www.w3.org/2000/svg"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    x="0px" y="0px"
    enable-background="new 0 0 274 224"
    viewBox="0 0 274 274"

    width="50px"

    xml:space="preserve"></svg>

And suddenly the icon will just be a small 50px icon in the page. It's not an issue because anyway you are already adjusting size, colors, etc. through CSS. The CSS will set the right size for the users who are using Pathécolor web pages.

Before - After

Huge…

Fatwigoo example

Lovely…

Fatwigoo example

Otsukare!

When Can I Use updates by Alexis Deveria at

Variable fonts: OpenType font settings that allows a single font file to behave like multiple fonts: it can contain all the allowed variations in width, weight, slant, optical size, or any other exposed axes of variation as defined by the font designer. Variations can be applied via the `font-variation-settings` property.

Mike Taylor's Web Log by Mike Taylor at

<select> elements have always been kind of awkard, IMO.

web-bug 12553 describes an issue where a pretty famous 3rd party library, FastClick.js turns <select>-level awkward to middle-school-dance-party-level awkward.

(In that the <select> doesn't function at all if you're on Android, unless you're using Chrome Mobile (depending on what FastClick version you're running). Just like middle school—trust me this analogy makes total sense, 7th grade was really hard for me and I'm still working through it, OK.)

The issue here is the result of a web standards interoperability failure (more on that in a second, there's a happy ending I swear) and the inability to predict the future of the web platform and browsers by FastClick (more on that now).

So if you don't know much about FastClick, or why it was so popular, put on 2012's "Now That's What I Call Music! Volume 44" to set the mood and read their GitHub page.

Cover of Now Thats What I Call Music Volume 44 album

Back in 2012, when tapping on things in mobile browsers was slow (because browsers always had a 300ms delay between a touchend event and a click event), it was cool to use FastClick to make tapping on things fast. Noted soda water critic Jake Archibald has a good article on this and how to get rid of it these days (tl;dr make your site's viewport mobile friendly).

(The article is a bit dated given that Firefox didn't support touch-action: manipulation when it was authored, but it does now, so consider that another option.)

OK, so. Anyways. The way this library works is to dispatch its own synthetic click event after a touchend event, without the 300ms delay. This is all great and fine for links. Things get trickier for inputs like <select>, because there's never really been a web standards way to programatically open them via JS.

Per DOM level 3(000), untrusted events (think event.isTrusted == false...except for click) shouldn't trigger the default action. And the default action for <select> is to open the widget thingy and display the 400 countries you don't live in.

OK, back to FastClick in the year 2012. Things either broke on <select> elements, or never worked properly in Chrome Mobile, but developers (being developers) found a workaround with mousedown events for Chrome Mobile (in a stackoverflow thread, naturally), put it into FastClick. This unintentionally broke it for other browsers, and later on some fixes were introduced to unbreak that for Firefox and Blackberry. But... that's only some of the select-related bugs.

Fast foward a few years and Chrome fixed their untrusted events default action bug, and as a result broke <select>s on pages using FastClick. Fortunately for interop, they decided to not back out the fix (except for Android WebView!).

Anyways, this blog post is getting too long.

In conclusion, if you run into bugs with FastClick, you should probably delete it from your app. It's basically unmaintained and they don't want you to use it either.

And besides, we have touch-action: manipulation anyways.

Subscriptions