"Cuts the Mustard" test #88

triblondon · 2014-01-10T10:07:13Z

We need to define what our CTM test is, so that Origami JavaScript authors know what baseline functionality they can rely on.

The BBC, who invented the expression, use the following test:

('querySelector' in document && 'localStorage' in window && 'addEventListener' in window)

They say that the oldest browsers that support this are:

IE9+
Firefox 3.5+
Opera 9+ (and probably further back)
Safari 4+
Chrome 1+ (they think)
iPhone and iPad iOS1+
Android phone and tablets 2.1+
Blackberry OS6+
Windows 7.5+ (new Mango version)
Mobile Firefox (all the versions tested)
Opera Mobile (all the versions tested)

I propose we throw in classList as well:

('classList' in document.createElement('div') && 'querySelector' in document && 'localStorage' in window && 'addEventListener' in window)

The additional browsers this kicks out vs the BBC's test are:

IE 9 (2 versions old, but currently very popular)
Safari 4 and 5.0 (may be significant?)
Firefox 3.5 (irrelevant)
Chrome 1-7 (irrelevant)
Opera 9-11.1 (irrelevant)
iOS 1-3 (irrelevant)
Blackberry 6 (irrelevant)
Mobile Firefox below 25 (irrelevant)
Mobile Internet Explorer below 10 (irrelevant)

We propose that absolutely no Origami JavaScript will be run in browsers that fail this test. In order to run no JavaScript in these browsers, our non-JS experience has to be good, ie it must be possible to log in, see your sign in status, read articles, use the paywall, see ads and tracking has to work too.

Therefore it's proposed that we split our browser support strategy into CSS and JavaScript lists. The current primary, secondary and unsupported scheme continues to apply in respect of CSS, and therefore the quality of the visual style, and a new, second standard is created for JavaScript with only two levels: cuts the mustard, and doesn't. Only browsers that cut the mustard will have JavaScript-powered features. So, for example, IE9 will look visually perfect, but won't have flyout menus, overlays, animations or (possibly) comments.

This proposal is also taking into account that there will be a lag before we see Origami components used in production, and in that time, the non-compliant browsers will further reduce their share.

Since they're not on Github, I'm soliciting feedback on this from Dan Skinner, Tom Betts and Jay Sethi by email.

The text was updated successfully, but these errors were encountered:

kavanagh · 2014-01-10T10:11:44Z

('classList' in document.createElement('div') && 'querySelector' in document && 'localStorage' in window && 'addEventListener' in window)

+1

Although I think you could then remove 'addEventListener' in window

kavanagh · 2014-01-10T10:12:54Z

Actually +10 for all of that - can I do ten?

kavanagh · 2014-01-10T10:31:38Z

I think also we should recommend that product developers take a versioned library that encapsulates CTM in case it changes in the future. If it does change we will mandate the change and we ought to make that easy to do. I know it's just one line of code but I think in reality forcing the change won't be so easy to manage.

Also this could be nicely wrapped into Modernizr like so

Modernizr.add('ctm', function(){
  return ('classList' in document.createElement('div') && 'querySelector' in document && 'localStorage' in window && 'addEventListener' in window);
});

var cuts_the_mustard = Modernizr.ctm;

And on the DOM as feature clases

<html class="ctm">

or

<html class="no-ctm">

This relates to #86 in that developers could add "ctm" to their origamiconfig to get the CTM implementation.

triblondon · 2014-01-13T11:27:39Z

Yet to establish whether modernizr can be included in Origami builds, but in principle it seems like a good idea to have a versioned bootstrap that loads the bundle. Would a gist be the best way of presenting that? Then it can be included in the docs, but updated as necessary.

dan-searle · 2014-01-13T15:33:53Z

We propose that absolutely no Origami JavaScript will be run in browsers that fail this test.

Can I just check whether we mean no Origami javascript will run, or no javascript at all?

triblondon · 2014-01-13T15:50:33Z

Product developers are free to do whatever they like (Origami principle 4!) so it's just origami modules that would be restricted in this way. In practice, I would hope they'd choose to put their JS in the same bundle, so it would apply to theirs as well.

dan-searle · 2014-01-13T15:59:39Z

OK, yep make sense.

In that case, revealing the content of the noscript tags is slightly more complicated as it won't be all noscript tags. There should be a means of identifying which tags are opting in (or out) to the CTM condition.

kavanagh · 2014-01-13T16:20:15Z

as it won't be all noscript tags.

Why? Is allowing this statement to be true the thing that's complicated?

Otherwise it's trivial to add <noscript class="ctm"></noscript> to filter the query.

dan-searle · 2014-01-13T16:43:49Z

Yep, that bit is trivial (and I did say 'slightly more complicated' :-))

But it does mean there's a greater number of circumstances:

no JS at all
JS, but doesn't cut the mustard:
- only Origami JS exists
- combination of Origami, product, third-party JS
JS, does cut the mustard:
- only Origami JS exists
- combination of Origami, product, third-party JS

BTW, I'm all for the approach proposed in this issue, although I'm concerned it'll be a barrier for adoption of Origami components by products.

kavanagh · 2014-01-13T16:49:15Z

Just to clarify my last comment. Dan said my last one didn't make sense ;-)

I would prefer not to have this case:

JS, but doesn't cut the mustard:
- and some noscript elements should not be unwrapped because they should not be on the DOM.

Why would you want to prevent some noscript elements from being unwrapped or replaced with div elements?

dan-searle · 2014-01-13T16:55:43Z

Why would you want to prevent some <noscripts> from being unwrapped?

Well, ads spring to mind. If ft-cms were to start using some Origami modules and used the CTM test to determine whether to run those modules' JS, then if the CTM test failed, you wouldn't want the ads' noscript being revealed (resulting in the GIF ads being shown as well as the full flash ads).

kavanagh · 2014-01-13T17:00:18Z

So for script libraries we don't have control of?

And do we have control of the noscript elements they create? i.e should the filter be noscript class="ctm" or noscript class="no-ctm"?

dan-searle · 2014-01-13T17:26:55Z

And do we have control of the noscript elements they create?

For ads in ft-cms we do. But that was just one example.

i.e should the filter be noscript class="ctm" or noscript="no-ctm"?

noscript class="no-ctm" I think (assuming that means 'only reveal if browser doesn't cut the mustard')

triblondon · 2014-01-13T17:35:50Z

This isn't strictly within the Origami realm - we simply advise the product developer when they're allowed to load the Origami components. But I think our suggested class should simply be origami. I'll update the gist.

wheresrhys · 2014-01-16T10:52:47Z

Late arriving at this discussion, but I can see a couple of issues that perhaps aren't addressed above:

as per @kavanagh's "Cuts the Mustard" test #88 (comment), if ctm is changed to be more restrictive in future then, without a coordinated effort to upgrade, lots of modules would suddenly lose their js functionality in browsers they actually support
some scripts need including in the head of a page (unrelated issue really, but slots in quite well to my suggestion below)

So, how about something like the following:

In origami config add a property ctm1: bool. If false the module is recommended to internally wrap itself in its own cut the mustard lite
Also add a property headScript: bool
Build service (making liberal use of browserify's externals config to ensure no duplication) generates max of 4 bundles
1. scripts to be included in the head that don't cut the mustard
2. scripts to be included in the head that do cut the mustard
3. scripts to be included in the foot that don't cut the mustard
4. scripts to be included in the foot that do cut the mustard

Script returned by buildservice/js/list-of-modules:

(function () {
    // modernizr custom build

    // bundle i
    // lazy load bundle iii

   if (cuts the mustard) {
      // bundle ii
      // lazy load bundle iv (lazy loader must be careful to wait for bundle iii)
   }
})();

When cut the mustard is changed modules must set ctm2: bool if they support it and the buildservice includes both ctm[current] and ctm[previous] tests for a transitional period, giving module authors a chance to upgrade (this point, about upgrading ctm, I think is important even if origami disallows all scripts that don't cut the current version of mustard)

triblondon · 2014-01-16T12:09:18Z

See #86 for modernizr discussion. This issue is about what we recommend as a good CTM test.

triblondon · 2014-01-17T18:27:14Z

As part of the fallbacks and polyfills discussion we now have a mechanism for modules to declare their requirements, so we no longer need an explicit CTM test to be recommended by Origami, but we can still provide a recommendation for a mechanism for running a test.

wheresrhys mentioned this issue Jan 10, 2014

Treatment of hover state on devices without hover capability #65

Closed

triblondon added a commit that referenced this issue Jan 13, 2014

Add CTM draft (see #88)

6ec6776

triblondon closed this as completed Jan 17, 2014

triblondon removed For approval labels Feb 25, 2014

addyosmani mentioned this issue Jan 26, 2015

Add "Cutting the Mustard" test google/web-starter-kit#616

Merged

gvonkoss mentioned this issue Sep 3, 2018

[WIP] Component documentation Financial-Times/origami-website#11

Merged

sjparkinson mentioned this issue Jan 4, 2019

You need to enable JavaScript to run this app brittonjg/jbritton.uk#2

Closed

notlee mentioned this issue Feb 20, 2019

Migrates JavaScript Standards Financial-Times/origami-website#52

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

"Cuts the Mustard" test #88

"Cuts the Mustard" test #88

triblondon commented Jan 10, 2014

kavanagh commented Jan 10, 2014

kavanagh commented Jan 10, 2014

kavanagh commented Jan 10, 2014

triblondon commented Jan 13, 2014

dan-searle commented Jan 13, 2014

triblondon commented Jan 13, 2014

dan-searle commented Jan 13, 2014

kavanagh commented Jan 13, 2014

dan-searle commented Jan 13, 2014

kavanagh commented Jan 13, 2014

dan-searle commented Jan 13, 2014

kavanagh commented Jan 13, 2014

dan-searle commented Jan 13, 2014

triblondon commented Jan 13, 2014

wheresrhys commented Jan 16, 2014

triblondon commented Jan 16, 2014

triblondon commented Jan 17, 2014

"Cuts the Mustard" test #88

"Cuts the Mustard" test #88

Comments

triblondon commented Jan 10, 2014

kavanagh commented Jan 10, 2014

kavanagh commented Jan 10, 2014

kavanagh commented Jan 10, 2014

triblondon commented Jan 13, 2014

dan-searle commented Jan 13, 2014

triblondon commented Jan 13, 2014

dan-searle commented Jan 13, 2014

kavanagh commented Jan 13, 2014

dan-searle commented Jan 13, 2014

kavanagh commented Jan 13, 2014

dan-searle commented Jan 13, 2014

kavanagh commented Jan 13, 2014

dan-searle commented Jan 13, 2014

triblondon commented Jan 13, 2014

wheresrhys commented Jan 16, 2014

triblondon commented Jan 16, 2014

triblondon commented Jan 17, 2014