The case of the non-stringifyable value

Raphael Schweikert — Tue, 05 Sep 2023 15:24:40 +0000

When I see someone calling someVar.toString(), I usually advise them to use String(someVar)¹ instead, as it handles null and undefined cases gracefully (depending on the definition of gracefully, of course) instead of throwing².

For the longest time I was under the impression that calling String(someVar) would never throw, for any value of someVar. However, I was wrong. There are two cases where it also throws:

When passed an object whose Symbol.toPrimitive exists but isn’t callable or calling it with 'string' as first argument returns a non-primitive or throws.
When passed an object that doesn’t have a Symbol.toPrimitive property and toString or valueOf each either don’t exist, aren’t callable, return a non-primitive, or throw.

Most likely you’ll encounter the case where none of these methods are declared when handling an object that doesn’t have a prototype, e.g. if it was created using Object.create(null). In that case, my advice wouldn’t have been better or worse because both approaches throw.

But we can also craft an object specifically to throw when passed to String but not when calling toString on it:


    
const o = {
  [Symbol.toPrimitive]() {
    return {};
  },
};
console.log(o.toString());
console.log(String(o));

In this case, my initial advice would be completely wrong and toString would have been the better option.

Of course, we could also easily have crafted the opposite:


    
const o = {
  [Symbol.toPrimitive]() {
    return "cool string";
  },
  toString: 42,
};
console.log(String(o));
console.log(o.toString());

I stand by the stance that String(someVar) is usually the better approach in real-world scenarios (it also looks nicer) but I’ve come around to thinking that being explicit about null and undefined is better than being implicit so I always advice for having null checks anyway.

Investigating this also helped me clear up another misconception. The String construction (when used as a function) doesn’t just apply the abstract operation ToString as defined by ECMAScript.

ToString is specified as follows:

But I already knew that String(Symbol('a')) doesn’t throw, so something else must be going on there.

The specification of String(value) clarified things:

That’s it, symbols are special-cased in String(value), they won’t ever throw!

But symbols will throw when used in an untagged template string literal as there, the ToString operation is used.

Or ${someVar} in a template string literal, which amounts to almost the same thing. ↩
Technically, it’s not toString that throws, it’s the property lookup on someVar that throws. ↩

What to do about sub-pixel media-queries?

Raphael Schweikert — Wed, 07 Jul 2021 17:35:21 +0000

I came across an interesting conundrum today¹. I had zoomed into a webpage that uses both max-width and min-width media queries. I noticed that, while resizing the browser window, there was a brief moment where the layout was totally messed-up.

Turns out I seem to be the last web developer using Firefox². And Firefox treats media queries much more literally than WebKit/Blink-based browsers.

When zoomed in, the viewport can assume sub-pixel sizes. Say my window is 401px wide and zoom is set to 200%, the visual viewport width will be 200.5px wide.

Assume the following CSS³:

#max200, #min201 {
    display: none;
}

@media screen and (max-width: 200px) {
    #max200 {
        display: block;
    }
}

@media screen and (min-width: 201px) {
    #min201 {
        display: block;
    }
}

While Safari and Chromium will round up the actual value of the visual viewport to 201 when matching against media queries, Firefox will happily try to match 200.5 pixels against the given queries and neither of them will match, which will result in Firefox displaying neither the #max200 nor the #min201 element⁴.

One could argue this is a bug in Firefox but it seems like the behaviour is simply under-specified.

Now, how can this be solved? A simple workaround would be to use @media screen and (max-width: 200.999px) for the first query but this will result in an overlap where both elements are shown on all browsers. It seems when parsing the media query, all browsers agree an rounding, treating max-width: 200.999px the same as max-width: 201px⁵.

What do you think would be the right course of action here and who’d need to take it? Should Firefox follow suit and take control over sub-pixel values away from devs? Should media-queries be extended with a min-width-exclusive and max-width-exclusive construct?

Should web developers just live with this and hope no-one zooms and resizes their windows? Or should we restrict ourselves to only either use min-width or max-width queries but never mix them?

Discuss!

As with most interesting conundrums, it plays out mostly in the fringes; this one more literally than others. ↩
And, as it increasingly seems to me, one of the few who doesn’t just care about getting things to work but getting them to work on grounds of principle as opposed to accident. ↩
Try it on my test page. ↩
Interestingly, on 5x zoom level, Chrome also briefly hides both elements. I attribute this to rounding errors. Safari doesn’t but it also zooms to max 3x so maybe the rounding problems don’t manifest. ↩
Also, it would be ugly even if it worked, as it relies on the fact that browsers don’t have infinite zoom capability (and users don’t have infinite desires for zooming in). ↩

DEV Community: Raphael Schweikert

The case of the non-stringifyable value

What to do about sub-pixel media-queries?