Granularity

[wheresrhys]

In optimising the head css across apps a recurring theme is we have to include o-teaser/o-teaser collection in their entirety in head.css whenever n-teaser is used above the fold. This is for a number of reasons:

• the logic of which kinds of n-teaser config result in which kinds of teaser is not exposed (or I can't find it)
• some of the logic is contained in templates too, which is difficult to access
• the options of n-teaser don't map neatly to the options of o-teaser and o-teaser-collection's mixins
• vicious cycle - need to know what variants to inline before rendering, but need to render in order to know which variants to inline. Take inlining out of hbs? Create a 'hotline' from the presenter back to the controller?

Any thoughts on how we can tackle this @andygnewman @i-like-robots @onishiweb

[andygnewman]

Some thoughts;

There are two dimensions to teasers;

• data presentation - this is what the template equates to
• presentation - these are the origami options that dictate what styling to apply - these come from the classModifiers in the presenter concatenated with any mods passed through from the template.

There is some small overlap (eg. image and video where content drives styling).

Then there is the anomaly that is package teasers, which is very specific and I have little understanding of.

So the type of n-teaser template is broadly irrelevant to the styling so that won't really help.

What you would need to have in order to understand the css variants is an array of unique o-teaser--?????? class values from the final html. Which is your viscous circle issue.

The only separation out that I can see that is simple and doesn't require any understanding of the real content / template is the Big Story variants that are only used on the home page and at the top of that page - so could be hard code configured easily.