cloudfour / cloudfour.com-patterns Goto Github PK

As discussed on #58

I wonder if it's time to order the sidebar views? Feels like Overview, Typography, Icons and Components might be better. It feels weird having Typography at the end because it's so foundational.

We just need to update src/views/layouts/includes/f-nav.html.

We currently use the defaults for Autoprefixer. I don't remember what they are.

When we decide which browsers we need to target for Autoprefixer, we can easily do so with a browserslist config file in the root of our project.

https://github.com/ai/browserslist#config-file

cssnext should pick up these settings automatically.

The "Our Work" photo has an outer border that creates a visual "gap" between the photo and the viewport edge in narrow windows:

This also contradicts the style of the Thumbnail pattern, which uses an inset shadow so the border color is within the image (rather than outside):

Similar to #40, this same logic kind of should also be applied to the .TextBlock component.

October 31st through 2nd 😆

PHP isn't highlighted properly right now. Here's a sample post: http://c4site.staging.wpengine.com/javascript-gzip-compression-in-wordpress-whats-possible-and-what-hurts/

We should include a custom Modernizr build so we can do feature tests.

I've really enjoyed gulp-modernizr for personal projects, as it dynamically generates the custom build (making maintenance much easier).

I noticed that hyphens is set to auto in our body definition. Firefox take this as all the excuse it needs to put hyphens everywhere. I think this makes things harder to read and @megnotarte agrees with me. Can we just take this out or is there a reason it is there?

http://c4site.staging.wpengine.com/made/

See #16 (comment)

We currently have theme.css and theme-map.css.

theme.css

This defines the theme in fundamental terms, but not how it is applied to
the components. That is done in theme-map.css.
https://github.com/suitcss/theme/blob/master/lib/theme.css

Our themes.css looks pretty good currently. It's very low-level and mentions no component or content specifics. Our theme-map.css is almost empty, which is what we should address next.

theme-map.css

The purpose of this file is to map the abstract custom properties from theme.css into more specifically named groups. And from those more specific groupings, we can have a basis for our even more specific component properties. For example:

/* theme.css */
:root {
  --color-black: #222;
}

:root {
  --spacing: 1rem;
  --spacing-sm: .5rem;
}

/* theme-map.css */
:root {
  --base-color: var(--color-black);
}

:root {
  --component-spacing: var(--spacing-sm);
}

/* some-component.css */
:root {
  --SomeComponent-color: var(--base-color);
  --SomeComponent-padding: var(--component-spacing);
}

Tasks

We currently have a small but growing number of components that define their own custom properties, but with many values being repeated in multiple files. We need to replace those values with var() references to properties within theme-map.css.

• Come up with a sensible convention for grouping and naming properties in the theme map
• Come up with a sensible convention for what can or cannot go into the theme map
  • For example, no new values may occur, properties must only reference values from theme.css
• Replace static component properties with references to the theme map (where applicable)

As a result of #117, the inputs are all messed up:

Thanks @saralohr for mentioning in #120.

Creating an issue to track something @lyzadanger and I discussed. There have been a number of adjustments to this repo that puts it quite a ways ahead of cloudfour/fabricator. We should probably have a plan for keeping these in better sync in the future.

Overview

The JavaScript for this pattern library currently consists of:

• Proof-of-concept modules for low-level utility things (like object merging and DOM iteration)
• Some modules for animation-related things (used only by the Sky/Nav component)
• Some component modules that evolved from sandbox demos (Sky, FloatLabel)
• Externals: a custom Modernizr build, svgxuse

src/assets/toolkit/scripts/
├── lib
│   ├── component
│   │   ├── float-label.js
│   │   └── sky.js
│   ├── dom
│   │   ├── attributes.js
│   │   └── core.js
│   ├── fx
│   │   ├── easing.js
│   │   └── tween.js
│   └── util
│       └── object.js
└── toolkit.js

What it currently lacks:

• DOM library
• Polyfills
• Any system for routing (or initializing things on specific pages)

Questions

Polyfills or modules for things like classList and Object.assign?

IMO, polyfills are a better solution. I would look into what http://polyfill.io has to offer. We can either include the hosted script, or directly bundle in the specific polyfills used for each feature we depend on.

Is Modernizr still the best feature detection solution?

@tylersticka pointed out a potential alternative: http://featurejs.com.

It differs from Modernizr in a few ways:

• It doesn't auto-run its tests when the page loads (they are executed cleverly upon first access)
• It doesn't automatically add classes to the <html> element (we would need to do that if needed)
• It is smaller in scope for what you can detect
• It is smaller in file size

I think feature.js would be a fine fit. Even though we already have a system in place for Modernizr, we aren't really using many of the feature detections yet, so the transition should be mostly reductive.

Do we need a DOM library?

We've been getting by without one, but I'm not sure. Some things to consider:

• We currently only have two components that need JS.
• Will we need more complex DOM scripting as complete pages start coming together?
• Will we need any async request handling?
• Are we sacrificing consistency by rolling our own DOM manipulations? (example)
• If using a library, it may need some webpack finessing

FWIW, I think Bliss looks like a nice fit, if we decide to use anything. I believe the consensus is that jQuery is too hefty, but I'm not 100% sure on that.

TODOs

• Remove the stuff we aren't using (looking in the lib directory)
• Decide on the inclusion of a DOM library
• Decide on the feature detection library. If using feature.js:
  • Remove Modernizr script
  • Remove Modernizr Gulp integrations
  • Update existing instances of Modernizr usage in the JS (if any)

/CC @tylersticka @saralohr @nicolemors

We should update the ones that we can.

Package                   Current  Wanted  Latest  Location
babel-loader                5.0.0   5.0.0   5.3.2  babel-loader
del                         1.2.0   1.2.1   2.0.1  del
fabricator-assemble         1.1.5   1.1.9   1.1.9  fabricator-assemble
gulp-imagemin               2.2.1   2.3.0   2.3.0  gulp-imagemin
babel-core                  5.1.5   5.1.5  5.8.23  babel-core
gulp-postcss                5.1.9  5.1.10   6.0.0  gulp-postcss
browser-sync                2.7.6   2.9.1   2.9.1  browser-sync
gulp-util                   3.0.5   3.0.6   3.0.6  gulp-util
gulp-svg-sprite             1.2.5   1.2.9   1.2.9  gulp-svg-sprite
postcss-bem-linter          0.4.0   0.4.0   1.0.1  postcss-bem-linter
postcss-discard-comments    1.2.0   1.2.1   1.2.1  postcss-discard-comments
moment                     2.10.3  2.10.6  2.10.6  moment
cssnext                     1.8.0   1.8.4   1.8.4  cssnext
postcss-easings             0.2.0   0.2.0   0.3.0  postcss-easings
postcss-reporter            0.1.0   0.1.0   1.1.0  postcss-reporter
postcss-discard-empty       1.1.1   1.1.2   1.1.2  postcss-discard-empty
run-sequence                1.1.0   1.1.2   1.1.2  run-sequence
handlebars                  3.0.3   3.0.3   4.0.2  handlebars
webpack                    1.9.10  1.12.1  1.12.1  webpack

There should be a page that documents all available icons (kinda like this).

See also: #29

There seem to be two types of embeds included as part of blog content.

Some (YouTube, Vimeo, SlideShare, etc.) embed via an <iframe>. Because this is markup-only, it's pretty straightforward. The recent addition of FlexEmbed (see #44) will get us 90% of the way there with these.

But the others use a <script> tag, by itself or (more often) with fallback content.

Examples

CodePen

With "result" tab visible by default:

<p data-height="480" data-theme-id="0" data-slug-hash="EjdPKm" data-default-tab="result" data-user="tylersticka" class='codepen'>See the Pen <a href='http://codepen.io/tylersticka/pen/EjdPKm/'>Shifty Tiles: Part 3</a> by Tyler Sticka (<a href='http://codepen.io/tylersticka'>@tylersticka</a>) on <a href='http://codepen.io'>CodePen</a>.</p>
<script async src="//assets.codepen.io/assets/embed/ei.js"></script>

With "HTML" tab visible by default:

<div data-height="268" data-theme-id="0" data-slug-hash="QbZpab" data-default-tab="html" data-user="tylersticka" class='codepen'>
  <pre><code>&lt;div class=&quot;Tiles&quot;&gt;
    &lt;div class=&quot;Tile&quot;&gt;
      &lt;div class=&quot;Tile-content&quot;&gt;
        Tile 1
      &lt;/div&gt;
    &lt;/div&gt;
    &lt;div class=&quot;Tile&quot;&gt;
      &lt;div class=&quot;Tile-content&quot;&gt;
        Tile 2
      &lt;/div&gt;
    &lt;/div&gt;
    &lt;div class=&quot;Tile&quot;&gt;
      &lt;div class=&quot;Tile-content&quot;&gt;
        Tile 3
      &lt;/div&gt;
    &lt;/div&gt;
    &lt;div class=&quot;Tile&quot;&gt;
      &lt;div class=&quot;Tile-content&quot;&gt;
        Tile 4
      &lt;/div&gt;
    &lt;/div&gt;
    &lt;div class=&quot;Flyout is-open js-flyout&quot;&gt;
      &lt;div class=&quot;Flyout-content&quot;&gt;
        Flyout 1
      &lt;/div&gt;
    &lt;/div&gt;
    &lt;div class=&quot;Flyout Flyout--2of4 js-flyout&quot;&gt;
      &lt;div class=&quot;Flyout-content&quot;&gt;
        Flyout 2
      &lt;/div&gt;
    &lt;/div&gt;
    &lt;div class=&quot;Flyout Flyout--3of4 js-flyout&quot;&gt;
      &lt;div class=&quot;Flyout-content&quot;&gt;
        Flyout 3
      &lt;/div&gt;
    &lt;/div&gt;
    &lt;div class=&quot;Flyout Flyout--4of4 js-flyout&quot;&gt;
      &lt;div class=&quot;Flyout-content&quot;&gt;
        Flyout 4
      &lt;/div&gt;
    &lt;/div&gt;
    &lt;div class=&quot;Tile&quot;&gt;
      &lt;div class=&quot;Tile-content&quot;&gt;
        Tile 5
      &lt;/div&gt;
    &lt;/div&gt;
    &lt;div class=&quot;Tile&quot;&gt;
      &lt;div class=&quot;Tile-content&quot;&gt;
        Tile 6
      &lt;/div&gt;
    &lt;/div&gt;
    &lt;div class=&quot;Flyout js-flyout&quot;&gt;
      &lt;div class=&quot;Flyout-content&quot;&gt;
        Flyout 5
      &lt;/div&gt;
    &lt;/div&gt;
    &lt;div class=&quot;Flyout Flyout--2of4 js-flyout&quot;&gt;
      &lt;div class=&quot;Flyout-content&quot;&gt;
        Flyout 6
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;</code></pre>
  <p>See the Pen <a href='http://codepen.io/tylersticka/pen/QbZpab/'>Shifty Tiles: Part 1</a> by Tyler Sticka (<a href='http://codepen.io/tylersticka'>@tylersticka</a>) on <a href='http://codepen.io'>CodePen</a>.</p>
</div>
<script async src="//assets.codepen.io/assets/embed/ei.js"></script>

Gist

<noscript>
  <a href="https://gist.github.com/9358004.git">View GitHub Gist</a>
</noscript>
<script src="https://gist.github.com/tylersticka/9358004.js"></script>

Speaker Deck

<script async class="speakerdeck-embed" data-id="4facdb4907fa81001f014061" data-ratio="1.3333333333333333" src="//speakerdeck.com/assets/embed.js"></script>

Twitter

<blockquote class="twitter-tweet" lang="en">
  <p><a href="https://twitter.com/adamconnor">@adamconnor</a> <a href="https://twitter.com/nickf">@nickf</a> Every &quot;expert&quot; I&#39;ve consulted has acknowledged that responsive design is ineffective for complex transactional web pages.</p>
  <p>&mdash; Walter Anasagasti (@freediverx) <a href="https://twitter.com/freediverx/statuses/354698695041744896">July 9, 2013</a></p>
</blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

Points of exploration

I'm creating this issue more as a starting point for discussion than anything. These are some of the questions this stuff has raised for me.

Performance

It his performant? A quick look at a page with multiple embeds (my recent CodePen-heavy post) shows that, because the file path is the same, the script is only requested once, which is good. I was also pleased to see almost every example I could find included the async attribute, which is awesome. But does every <script> result in re-executing of that logic? I assume it would, but I don't know! And I'm not sure how that would compare in terms of performance to one loop through all occurrences.

Cleanliness

I'm not sure if it's wrong or not, but it feels icky having <script> tags littered around the site. Also irritating is that they are typically wrapped with <p> by the WordPress editor (even in Markdown mode). The Gist <noscript> even included <br> tags (blech!).

There's also inconsistency. Speaker Deck doesn't include any fallback content for example, so before the script runs any preceding paragraphs might not make any sense. I love that tweets fallback to a blockquote, but it might not be consistent with the rest of the blockquotes on our site.

Is there some way to de-couple our fallback markup from the "progressive enhancement" of the actual embeds, to take control of the non-JS experience? Is there something out there that can help us with that? What the heck is oEmbed anyway? (Honest question.)

That kinda brings me to my next point...

Maintainability

I find it a little weird/scary that there is logical code inter-mingling with old embeds that may never be updated unless the third-party decides to update whatever URL I used at the time. It also seems totally stupid that it's 2015 and we're still pasting inline <script> tags directly into our markup.

We could adopt a rule that embeds must be included via a WordPress plugin... but oftentimes I've been more appalled by the markup (and additional JS dependencies) plugins provide than I have with what the sites generate themselves when you click "embed"!

Ideally, I'd love it if embeds would work like Slack or Basecamp, where just pasting a certain URL results in the embed just kind of happening... but that gets us further away from the markup control I mention earlier. Maybe these things are not compatible. I'm not sure.

Currently, the larger headings aren't very functional at narrow screen sizes. We should make the range of sizes between "smallest" and "largest" gradually increase in proportion to the screen width.

Not a huge deal, but it's a convenient tool. The icon is fixed to the bottom of the page content, rather than the viewport, and it doesn't do anything when clicked.

The industry jargon section wraps oddly on small screens. I think it would look better as two columns are small breakpoints.

In review of #28, @erikjung pointed out that it might be a good time to decide how we want to structure JS modules for this project. I wanted to document this need with an issue we could reference later.

Based on @lharding's talk (slides here), it sounds like the candidates would be Browserify or Webpack.

(I personally would like the ability to reference small, recurring utility modules for things we typically rely on jQuery for. I think it would show how forward-thinking cloudfour.com is if we do not rely on gargantuan libraries unless we find that they are absolutely needed. But that may not be realistic!)

@erikjung @lyzadanger @lharding @mrgerardorodriguez

We have an unescaped em dash in our blockquote cite styles. This should be replaced with the backslash character code, as it's causing issues in server-side environments...

http://c4site.staging.wpengine.com/contributes/

Can reproduce on safari on iPhone 6, as well as Chrome on Galaxy S7 (browserstack), but not regular ol' OSX Safari

Because of block comments within :root blocks, our CSS output has many instances of:

:root {
}

We should think about:

• Changing how :root blocks are commented (perhaps doing away with the /* n */ annotations)
• Implementing https://github.com/ben-eb/postcss-discard-comments as well

The indent is off in our source code examples:

When invoking the fabricator task via gulp as we do, we need to pass additional opts for beautify.

The obvious way to do this is to pass a literal opt object when invoking the fabricate task via gulp.

js-beautify claims that it will respect a .jsbeautifyrc file in the path. This may or may not work depending on what the path is considered to be at fabricate-time. I think it's worth a try.

Note that the current organization of our gulp file and tasks is inherited from fabricator and isn't our standard/ideal form. There was a ticket once about this on our fork, but I decided that it wasn't strictly necessary to fix at the time. Anyway, something to be aware of. My comment that "we know what we like" vis-a-vis gulp is probably not fair WRT @mrgerardorodriguez as he hasn't been exposed to it :).

I'm seeing a few files that still have tabs. We should probably nuke them.

A few targets, for example:

• src/views/sandbox.html
• src/views/pages.html
• src/views/index.html

iPhone 6, safari

http://c4site.staging.wpengine.com/portland-device-lab/

Some of our current posts include line numbers in the code snippets (http://blog.cloudfour.com/getting-all-javascript-into-the-footer-in-wordpress-not-so-fast-buster/). Looks like there might be a prism plugin that will support this.

Not urgent at all. Just wanted to note this.

This one's specific to Microsoft Edge... it works fine in IE11 and every other browser I tried. Everything else about the animation works flawlessly, it's only the inner content that isn't displaying. Even more mysterious: The clip-path is working, because the white screen color is being clipped to the correct size. 😕

https://zaim.github.io/webcolors/

There was some discussion about this a few months ago. Imposing this constraint guideline on color names will prevent our variables from gradually mutating into a mess of unmaintainable variations. We should end up with a list of colors that fall within this grouping:

/** 
 * Example from https://github.com/zaim/webcolors/blob/master/mrmrs/index.css 
 */

:root {
  --color-aqua: #7FDBFF;
  --color-blue: #0074D9;
  --color-lime: #01FF70;
  --color-navy: #001F3F;
  --color-teal: #39CCCC;
  --color-olive: #3D9970;
  --color-green: #2ECC40;
  --color-red: #FF4136;
  --color-maroon: #85144B;
  --color-orange: #FF851B;
  --color-purple: #B10DC9;
  --color-yellow: #FFDC00;
  --color-fuchsia: #F012BE;
  --color-gray: #AAAAAA;
  --color-white: #FFFFFF;
  --color-black: #111111;
  --color-silver: #DDDDDD;
}

We need some styles in place for "core" elements such as:

• Body copy
• Headings
• Rules
• Additional normalization or resets

Anchors styled with the .Button class are now slightly out of alignment with their non-anchor brethren. They are also inheriting pseudo-states from a (which makes sense considering #52).

Compare the inner bottom corner to the inner top corner:

@tylersticka says we need to add the .u-cf class to the container so this doesn't happen:

I noticed while contributing to #30 that the size modifiers for .Separator and .TextBlock differed from those in .Icon. The former are full words (large and small) while the latter uses abbreviations (lg and sm).

This also made me remember a peeve of mine when working with classes for some of our clients who use that type of abbreviation for both breakpoints and element size: It's really difficult to tell which one a class is referring to! Often position is the only thing to go on.

So I think it would be better if we standardized.

The abbreviations xs, sm, md, lg and xl can continue to be used for variables and for class names that apply at specific breakpoint sizes. Because breakpoint classes are often more repetitive than others (a grid cell could contain several), they benefit from the conciseness.

But if the goal of the modifier is to make something smaller or larger, then we should use the full word.

This also makes more sense when you look at how the class names typically relate to the initial state of an element:

Tasks

• Review typographic modifiers for consistency
• Revise .Icon modifiers
• Revise documentation

Currently, there is an existing FootnoteLink component:

This should be updated to reflect the newer visual appearance seen in the blog post prototype:

We have a lot of verbose code samples in the blog, and I think the wrapping is ugly. Example:

We should consider making this a good ol' pre rather than pre-wrap, and maybe doing something with overflow-x on the container.

Same update was made here: #169

I think when we removed the toggle functionality from fabricator:

our Headings and Notes got turned off as well.

In the source code the class f-u-hidden is being added to those elements.

After removing class:

'Tis messed up:

Needs some left margin to account for top-left badge:

This could be accomplished by altering the viewBox attribute of the container. Will also need to be updated on staging.

@nicolemors @saralohr @aileenjeffries

• Add --font-family-mono: "Source Code Pro", monospace
• Apply it to all monospace-loving elements

http://c4site.staging.wpengine.com/presents/
Event content overlaps as shown. Also, at other breakpoints, the alignment looks odd when the date box is vertically centered and the text next to it is longer.

Reading through a comment here got me wondering...are we going to implement some sort of JS testing? We probably should, but wasn't clear and figured I should capture the thought as it came to mind.

@erikjung pointed out in the already-merged #69 that Fabricator already has an iterate helper, making #times redundant.

• Replace occurrences of #times with #iterate
• Remove #times helper from source

It seems like every dd requires some bottom padding.

http://c4site.staging.wpengine.com/a-comprehensive-guide-to-mobile-statistics/

See MoOx/postcss-cssnext#209

Currently, some of the cssnext plugins will fail if we update our PostCSS version to 5.x and attempt to use cssnext as a plugin.

• Update cssnext once it supports PostCSS 5.x
• Update any other related postcss-* packages