cfpb / cf-core Goto Github PK

The code provided for using our webfont provider's CDN is not cutting it. We need to set up our fonts to be self-hosted. It's essentially a three-step process:

• Upload font files to a location on one of our servers
• Get access controls in place (to ensure fonts can only be accessed from approved hostnames)
• Update the @font-face code in this repo to refer to the new locations.

And then projects will need to update their version of cf-core to use the new self-hosted fonts.

/cc @poorgeek

See: cfpb/consumerfinance.gov#154

This is blocking cfpb/cf-layout#1

as seen here https://github.com/cfpb/cf-core/blob/gh-pages/src/cf-utilities.less#L98

Currently non-CFPB projects have to deal with ripping out Avenir. We should make it easier to replace it by creating variables.

How does the following look to you all?

cf-vars.less

...
@webfont_declarations: "/static/css/licensed-fonts.css";
@webfont_regular: "'AvenirNextLTW01-Regular', Arial, sans-serif"
// Then vars for each version of Avenir.
...

cf-base.less

...
.webfont-regular() {
    font-family: @{webfont_regular};
    font-style: normal;
    font-weight: normal;

    & em,
    & i {
        .webfont-italic();
    }

    & strong,
    & b {
        .webfont-demi();
    }
}
// Then one for each version of Avenir.
...

cf-core.less

...
@import "@{webfont_declarations}";
...

So by default a CFPB project shouldn't have to do anything different. Projects that want to use other font families can point to their own file containing their own @font-face rules. They'd do it like this:

main.less

@import "cf.less"; // Assume that this is a concatenated version of Capital Framework
@webfont_declarations: "/static/css/my-own-font-face-rules.css";
@webfont_regular: "'MyFontFamilyNameForRegular', sans-serif";
// Etc...

CC: @ascott1

Move CF projects toward using a Readme more in-line with https://github.com/cfpb/open-source-project-template. Of particular note:

• Include the LICENSE (or exclude the link from the Readme). See https://github.com/cfpb/cf-typography/issues/31.
• Include installation instructions for generating the docs. E.g. Run npm install, grunt vendor, and grunt and open the HTML page in /docs/ in a web browser (also may be worth noting a server doesn't need to be running).
• Consider captioning the screenshot. The screenshot may be self-explanatory in some cases, but other times it may not be clear what's shown. For example, the cf-typography repo has a paragraph of text that turns into an image of lorem ipsum without any explanation of what the reader is looking at:

Without prior familiarity with the output of the project docs, it's not clear what this image is showing.

This should be in base.less:

img {
    max-width: 100%;
}

@Scotchester can you update these badges in the README please?

Seems like almost everything is in Avenir except longer blocks of text. It might make things easier on the front end if we just used that as the default font family instead of Georgia. Any thoughts?

... or get npm WARN package.json @ No repository field.

TIL that you cannot use traditional CSS /* ... */ comments inside the statement block of our .respond-to mixins. Less will not compile, giving the following error:

>> ParseError: unmatched `/*`

Additionally, you cannot comment out a single, unmatched curly brace inside the .respond-to statement block. Less will get to the end of the document and think that there is an unmatched curly brace missing its partner.

These quirks should be documented alongside the .respond-to mixins.

cc @Scotchester

While testing on IE11, we notice that if a link extended to the 2nd line, the underline style can only be seen on the first line.

Avenir seems to look better with font-smoothing: antialiased;. Note that in Chrome you need -webkit-font-smoothing: antialiased;. Any reason we shouldn't add this?

We should set a max-width on headings to keep line lengths readable.

Each individual Capital Framework module's issue is closing in favor of one issue section at Capital Framework's issue tracker. Please file any issues there.

This issue section will be closed after our readme and contributing.md are updated.

There are classes in cf-core that are only there for IE7- compatibility, such as https://github.com/cfpb/cf-core/blob/gh-pages/src/cf-utilities.less#L115-L121. It might make sense to remove this clutter from the project and move it to a IE-legacy component that contains the IE7- tweaks, which could then be optionally imported if a project needed those hacks.

In some cases it's valuable to use display: table-* properties to build a table, for example:

• As a fallback for flexbox.
• To allow a table row to be a link.
• To use table-like layout in places where a table isn't semantically correct.

Can cf-core provide utility class mappings for table element --> table display property?
Like:

.u-table { display: table; }
.u-table-caption { display: table-caption; }
.u-colgroup { display: table-column-group; }
.u-thead { display: table-header-group; }
.u-tfoot { display: table-footer-group; }
.u-tbody { display: table-row-group; }
.u-col { display: table-column; }
.u-tr { display: table-row; }
.u-td, .u-th { display: table-cell; }

See: https://eager.io/blog/smarter-link-underlines/