New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Cuts the Mustard" test #88

Closed
triblondon opened this Issue Jan 10, 2014 · 17 comments

Comments

Projects
None yet
4 participants
@triblondon
Contributor

triblondon commented Jan 10, 2014

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.

@kavanagh

This comment has been minimized.

Show comment
Hide comment
@kavanagh

kavanagh Jan 10, 2014

Member

('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

Member

kavanagh commented Jan 10, 2014

('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

This comment has been minimized.

Show comment
Hide comment
@kavanagh

kavanagh Jan 10, 2014

Member

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

Member

kavanagh commented Jan 10, 2014

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

@kavanagh

This comment has been minimized.

Show comment
Hide comment
@kavanagh

kavanagh Jan 10, 2014

Member

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.

Member

kavanagh commented Jan 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@triblondon

triblondon Jan 13, 2014

Contributor

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.

Contributor

triblondon commented Jan 13, 2014

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.

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

@dan-searle

This comment has been minimized.

Show comment
Hide comment
@dan-searle

dan-searle Jan 13, 2014

Contributor
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?

Contributor

dan-searle commented Jan 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@triblondon

triblondon Jan 13, 2014

Contributor

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.

Contributor

triblondon commented Jan 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@dan-searle

dan-searle Jan 13, 2014

Contributor

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.

Contributor

dan-searle commented Jan 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kavanagh

kavanagh Jan 13, 2014

Member

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.

Member

kavanagh commented Jan 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@dan-searle

dan-searle Jan 13, 2014

Contributor

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.

Contributor

dan-searle commented Jan 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kavanagh

kavanagh Jan 13, 2014

Member

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?

Member

kavanagh commented Jan 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@dan-searle

dan-searle Jan 13, 2014

Contributor
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).

Contributor

dan-searle commented Jan 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kavanagh

kavanagh Jan 13, 2014

Member

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"?

Member

kavanagh commented Jan 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@dan-searle

dan-searle Jan 13, 2014

Contributor
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')

Contributor

dan-searle commented Jan 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@triblondon

triblondon Jan 13, 2014

Contributor

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.

Contributor

triblondon commented Jan 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@wheresrhys

wheresrhys Jan 16, 2014

Member

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

  • as per @kavanagh's #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:

  1. 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

  2. Also add a property headScript: bool

  3. 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
  4. 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)
       }
    })();
  5. 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)

Member

wheresrhys commented Jan 16, 2014

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

  • as per @kavanagh's #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:

  1. 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

  2. Also add a property headScript: bool

  3. 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
  4. 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)
       }
    })();
  5. 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

This comment has been minimized.

Show comment
Hide comment
@triblondon

triblondon Jan 16, 2014

Contributor

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

Contributor

triblondon commented Jan 16, 2014

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

@triblondon

This comment has been minimized.

Show comment
Hide comment
@triblondon

triblondon Jan 17, 2014

Contributor

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.

Contributor

triblondon commented Jan 17, 2014

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.

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