Tags: detection

18

sparkline

Wednesday, February 2nd, 2022

“Evergreen” Does Not Mean Immediately Available | CSS-Tricks - CSS-Tricks

Smart advice on future-proofing and backward-compatibility:

There isn’t a single, specific device, browser, and person we cater to when creating a web experience. Websites and web apps need to adapt to a near-infinite combination of these circumstances to be effective. This adaptability is a large part of what makes the web such a successful medium.

Consider doing the hard work to make it easy and never remove feature queries and @supports statements. This creates a robust approach that can gracefully adapt to the past, as well as the future.

Thursday, January 16th, 2020

Intent to Deprecate and Freeze: The User-Agent string - Google Groups

Excellent news! All the major browsers have agreed to freeze their user-agent strings, effectively making them a relic (which they kinda always were).

For many (most?) uses of UA sniffing today, a better tool for the job would be to use feature detection.

Thursday, April 11th, 2019

Accessibility Events | CSS-Tricks

If you’re using Apple’s VoiceOver, both your phone and your computer will broadcast your assumed disability to the entire internet, unless and until you specifically tell it to stop.

Thursday, April 4th, 2019

Apple’s new feature a step towards digital apartheid - Axess Lab

I also discussed this accessibility events feature with my friend who is a screen reader user herself. She said it feels like it’s a first step towards a well-meant digital apartheid.

Thursday, February 21st, 2019

A tiny lesson in query selection

We have a saying at Clearleft:

Everything is a tiny lesson.

I bet you learn something new every day, even if it’s something small. These small tips and techniques can easily get lost. They seem almost not worth sharing. But it’s the small stuff that takes the least effort to share, and often provides the most reward for someone else out there. Take for example, this great tip for getting assets out of Sketch that Cassie shared with me.

Cassie was working on a piece of JavaScript yesterday when we spotted a tiny lesson that tripped up both of us. The script was a fairly straightforward piece of DOM scripting. As a general rule, we do a sort of feature detection near the start of the script. Let’s say you’re using querySelector to get a reference to an element in the DOM:

var someElement = document.querySelector('.someClass');

Before going any further, check to make sure that the reference isn’t falsey (in other words, make sure that DOM node actually exists):

if (!someElement) return;

That will exit the script if there’s no element with a class of someClass on the page.

The situation that tripped us up was like this:

var myLinks = document.querySelectorAll('a.someClass');

if (!myLinks) return;

That should exit the script if there are no A elements with a class of someClass, right?

As it turns out, querySelectorAll is subtly different to querySelector. If you give querySelector a reference to non-existent element, it will return a value of null (I think). But querySelectorAll always returns an array (well, technically it’s a NodeList but same difference mostly). So if the selector you pass to querySelectorAll doesn’t match anything, it still returns an array, but the array is empty. That means instead of just testing for its existence, you need to test that it’s not empty by checking its length property:

if (!myLinks.length) return;

That’s a tiny lesson.

Sunday, January 29th, 2017

Detecting text in an image on the web in real-time - Tales of a Developer Advocate by Paul Kinlan

The text detection API is still in its experimental stage, but it opens up a lot of really interesting possibilities for the web: assistive technology to read out text, archiving tools for digitising text …it’s all part of the nascent shape detection API.

Friday, January 15th, 2016

Feature.js

A lightweight alternative to Modernizr. It doesn’t add classes to your markup so it’s up to what you do with the results of any test.

It’s perfect for cutting the mustard on a case-by-case basis.

Tuesday, December 8th, 2015

Cutting the Mustard Revisited — sixtwothree.org

Jason revisits some cutting-the-mustard techniques, as started by the BBC and refined by Jake. This kind of feature-testing is indispensable for progressive enhancement.

Personally though, I’m still uncomfortable with the assumptions baked into equating particular features with particular browsers …maybe I’ve known PPK too long.

I much prefer to cut the mustard on a case-by-case basis by feature testing the actual APIs I’m about to use in a script. I realise that might be harder to scale, and it’s more verbose, but it’s the only way to be absolutely sure.

Monday, August 4th, 2014

The Mobile Web should just work for everyone - IEBlog

One more reason why you should never sniff user-agent strings: Internet Explorer is going to lie some more. Can’t really blame them though—if developers didn’t insist on making spurious conclusions based on information in the user-agent string, then browsers wouldn’t have to lie.

Oh, and Internet Explorer is going to parse -webkit prefixed styles. Again, if developers hadn’t abused vendor prefixes, we wouldn’t be in this mess.

Thursday, November 7th, 2013

isMobileDevice and the death of innocence

A nice bit of sleuthing to trace the provenance of one piece of ill-advised user-agent sniffing JavaScript code.

Good luck getting that script updated for the thousands of sites and applications, you say to yourself, where it’s laying dormant just waiting to send devices the wrong content based on a UA substring.

Monday, March 25th, 2013

Brett Jankord – Active development on Categorizr has come to an end

I think it’s a bit of a shame that Brett is canning his mobile-first device-detection library, but I totally understand (and agree with) his reasons.

There is a consensual hallucination in the market, that we can silo devices into set categories like mobile, tablet, and desktop, yet the reality is drawing these lines in the sand is not an easy task.

Monday, February 25th, 2013

gaia/build/ua-override-prefs.js at master · mozilla-b2g/gaia · GitHub

And this is why user-agent sniffing not a future-friendly technique. A new mobile browser comes along, and it has to spoof a fake UA string to all of these sites.

It’s a Red Queen arms race.

Monday, February 11th, 2013

Responsive typography demo

This is a pretty wacky experiment in altering font size based on the user’s distance from the screen (allow the page to access your camera and enable the “realtime” option for some real fun). I don’t know how much real-world application this has, but it’s a cute’n’fun exercise.

Wednesday, February 29th, 2012

LukeW | Which One: Responsive Design, Device Experiences, or RESS?

Luke outlines three different solutions to delivering a site to multiple devices.

Monday, January 30th, 2012

Detection

When I wrote about responsible responsive images a few months back, I outlined my two golden rules when evaluating the various techniques out there:

  1. The small image should be default.
  2. Don’t load images twice (in other words, don’t load the small images and the larger images).

I also described why that led to my dissatisfaction with most server-side device libraries for user-agent sniffing:

When you consider the way that I’m approaching responsive images, those libraries are over-engineered. They contain a massive list of mobile user-agent strings that I’ll never need. Remember, I’m taking a mobile-first approach and assuming a mobile browser by default. So if I’m going to overturn that assumption, all I need is a list of desktop user-agent strings.

I finished by asking:

Anybody fancy putting it together?

Well, it turns out that Brett Jankord is doing just that with a device-detection script called Categorizr:

Instead of assuming the device is a desktop, and detecting mobile and tablet device user agents, Categorizr is a mobile first based device detection. It assumes the device is mobile and sets up checks to see if it’s a desktop or tablet. Desktops are fairly easy to detect, the user agents are known, and are not changing anytime soon.

It isn’t ready for public consumption yet and there are plenty of known issues to iron out first, but I think the fundamental approach is spot-on:

By assuming devices are mobile from the beginning, Categorizr aims to be more future friendly. When new phones come out, you don’t need to worry if their new user agent is in your device detection script since devices are assumed mobile from the start.

Monday, September 19th, 2011

Detection

One of the recurring themes at the Mobilism conference earlier this year—and more recently at the Breaking Development conference—was the subject of server-side user-agent detection. I posed the question in absurdum on the Mobilism browser panel:

A useful tool for developers or spawn of Satan: which is it?

It’s a contentious issue, as Alex’s strident defence illustrates. Personally, I’ve never been a fan but that’s mostly because of the long history of really, really bad UA-detection in the past. When I discussed this issue with Lyza we came to a détente, agreeing that there is nothing inherently wrong with server-side UA-detection: it’s what you do with it that counts.

In their presentation at Breaking Development Bryan and Stephanie outlined the kind of detection that they have used. Crucially, it assumes a very basic small-screen default—rather than assuming a desktop browser—and later double-checks the profile on the client-side using feature detection.

Luke recently outlined another kind of cautious device detection that he’s calling RESS: Responsive Design + Server Side Components, sending subtly-different DOMs to different classes of device. He also recently wrote about why Bagcheck has a separate mobile site and it strikes me that RESS could alleviate the concerns he mentioned regarding responsive design for Bagcheck.

I think that RESS could be a very useful technique as long as it assumes a safe default: a small-screen, low-bandwidth default. That way, any UA detection would be done against a fairly limited set of user agents: desktop browsers and maybe tablets. To me, that seems far more reasonable than trying to pattern-match against the sprawling jungle of mobile devices in the wild …not to mention the swampy morass of licensing issues with Device Atlas (and now too).

As ever, smart defaults are really important. Just as truly responsible responsive web design goes hand-in-hand with a mobile/content first approach, I think that any server-side detection should do the same. It completely inverts the problem space. Instead of thinking “How can I stop this nice-to-have content/functionality being sent to mobile devices?” you can assume a mobile device by default and then your question becomes “How can I make sure that this nice-to-have content/functionality is only sent to desktop devices?” (the answer probably involves some kind of conditional loading with JavaScript).

A thornier problem with server-side UA-sniffing is that, regardless of whether you’re testing against a list of mobile devices or you’re testing against a list of desktop devices, you’re still committing yourself to an arms race. You are now obligated to keep your list of browsers up to date.

Still, the rate of desktop browser releases is a lot slower than the rate of mobile browser releases. So if a new desktop browser is released and it ends up being served a mobile-optimised DOM, I think that’s better than inadvertently serving a desktop-optimised DOM to a whole bunch of mobile devices.

That’s just my opinion of course. As ever, the standard disclaimer applies.

Friday, May 14th, 2010

The All-In-One Almost-Alphabetical No-Bullshit Guide to Detecting Everything - Dive Into HTML5

A really handy list of really short JavaScript code for HTML5 feature detection.

Saturday, December 16th, 2006

Mozilla Labs Blog » Blog Archive » Introducing Operator

A microformat detection extension for Firefox 2. This looks more human-friendly than the existing Tails extensions.