Initial base typography #57

MichaelArestad · 2015-03-15T23:09:55Z

Still in progress. Will keep pecking away at it.

sfrisk · 2015-03-17T15:36:26Z

typography.html

@@ -0,0 +1,158 @@
+<!doctype html>


Do we want to include this as part of the commit? A page like this would probably count as being part of the "Pattern Library," and probably shouldn't be kept in the home directory

arschmitz · 2015-03-17T15:53:11Z

scss/atoms/typography/_typography.scss

+	background-repeat: repeat-x;
+	background-size: 2px 2px;
+	background-position: 0 em( 22px );
+	outline: 0;


Outlines should only be modified using :focus. Use of outline: none or outline: 0 should be limited to :focus rules. (outline-none)

Why? I'm not opposed to the change, but I'm curious as to the reason.

Its a pretty big accessibility issue because the outline property is what makes the focus highlight in most browsers. So if you set it to 0 on all a elements now there is no focus indication on any links on the page. Here is a good explination in detail if your interested. https://github.com/CSSLint/csslint/wiki/Disallow-outline%3Anone

I'm aware, but that's a non-issue if there are other visual focus styles in place, which there are.

The only focus style i see here is setting a background size, position, repeat and a gradient, which does not really do anything besides make the underline slightly bolder unless i'm missing something? I consider that a pretty big accessibility issue.

This can be seen tabbing through your demo too. I don't think think people would even notice the focus indicator here in general.
http://view.css-chassis.com/typography/typography.html
Compare this to the focus style on a normal link without any styles applied.
http://jsbin.com/waxeyo/1

I personally am against changing the focus outline at all from what the native is.

Just to give some context on why i don't think we should alter native focus outlines. We used to have non native focus styles in jQuery UI and had TONS of complaints, until we removed it.
Based of the accessibility concerns involved with focus indication i think its best to leave the style users are familiar with on their particular device.

I do however also think we should provide a visual focus style for certain situations like showing a focus indication where native can't. An example is toolbars or accessible styled radio buttons and checkboxes. This situation came up recently and after consulting with several accessibility experts this is what we came up with.
http://view.jqueryui.com/button-classes/demos/checkboxradio/default.html
You can see tabbing a visual focus outline ( that may depending on your browser / os actually look native )

The problem is the visual button is a label. Labels can't receive focus they transfer to the underlying input which is accessibly hidden. So this means there is no focus outline visible. So we created a class that adds a visual focus indicator to the label. Problem here is the visual focus style and the regular focus style can be inconsistent on some platforms.

We add our own focus style everywhere for this same reason in jQuery mobile and this solves the issue of visual inconsistency however not the issue of user complaints ( or my own person desire to keep things as simple as possible for end users, navigating through a page via keyboard, by keeping important visual indicators native, as the way people are familiar with, in style ).

arschmitz · 2015-03-17T15:55:15Z

Now that there is an html file we need to add the html task to add html linting. It's already in package.json

sfrisk · 2015-03-17T15:57:43Z

Not to mention we need to rework the HTML style guide.

On Tue, Mar 17, 2015 at 11:55 AM, Alexander Schmitz <
[email protected]> wrote:

Now that there is an html file we need to add the html task to add html
linting. It's already in package.json

—
Reply to this email directly or view it on GitHub
#57 (comment).

Sarah Frisk
sarahfrisk.com

Twitter: twitter.com/SarahFrisk
LinkedIn: linkedin.com/in/sarahfrisk
Github: github.com/sfrisk

arschmitz · 2015-04-07T04:48:01Z

oops wrong number reopening

arschmitz · 2015-04-07T05:10:29Z

I pushed the latest update on this to view.css-chassis.com

arthurvr · 2015-04-07T07:22:26Z

demos/typography.html

+	<meta name="description" content="Typography skeleton for styling">
+	<meta name="viewport" content="width=device-width, initial-scale=1">
+	<link rel="stylesheet" href="../dist/css/chassis.css">
+	<link href='http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,600,700,400italic,700italic' rel='stylesheet' type='text/css'>


single quotes?

no what I meant is that this tag uses single quotes and all the rest doubles. We use double quotes.

Ha! Will change.

MichaelArestad · 2015-04-10T00:13:39Z

Updated a few things. It's a good base that's ready to merge IMO. We can then iterate, add colors, etc, in other PRs.

MichaelArestad · 2015-04-14T01:36:26Z

Failed check because of the hyphen in the attribute name, BTW.

arschmitz · 2015-04-14T01:38:21Z

package.json

@@ -59,6 +59,7 @@
    "grunt-csscomb": "3.0.0",
    "grunt-git-authors": "2.0.0",
    "grunt-html": "1.6.0",
+    "grunt-htmllint": "^0.2.7",


We use firm versions to do our best to avoid weird issues with different people having different versions.

Cool. Will change.

arschmitz · 2015-04-14T01:48:56Z

I'm wondering if we really want the x-ua-compatible meta since this forces the browser mode. while on production sites i would always use this, the demos are as much for our own visual testing, as they are for demos, i think i would prefer to leave it out.

Also just as a side note, we have never included this on the ui or mobile demos and there has never been an issue. We do of course keep it on our production WP sites though.

arschmitz · 2015-04-14T01:53:51Z

Can you also add demos.css to the csslint settings?

MichaelArestad · 2015-04-14T03:32:05Z

@arschmitz Changes made:

added hard version.
removed x-ua-compatible
added demos.css to csslint

arthurvr · 2015-04-14T07:40:39Z

demos/typography.html

+<html>
+<head>
+	<meta charset="utf-8">
+	<meta content="ie=edge">


If we remove the x-ua-compatible there's no deal with including this anymore.

arthurvr · 2015-04-14T07:41:10Z

demos/typography.html

+	<meta name="viewport" content="width=device-width, initial-scale=1">
+	<link rel="stylesheet" href="../dist/css/chassis.css">
+	<link rel="stylesheet" href="demos.css">
+	<link href="http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,600,700,400italic,700italic" rel="stylesheet" type="text/css">


Remove the type="text/css"

sfrisk · 2015-05-01T17:54:56Z

Any more updates on this?

MichaelArestad · 2015-05-03T21:26:11Z

@sfrisk Good to go.

arschmitz · 2015-05-03T21:30:33Z

scss/atoms/typography/_mixins.scss

@@ -0,0 +1,26 @@
+// ==========================================================================


Sorry i didn't notice the before but the style guide mandates /* comment */ style comments since these are the only valid style in normal css. @MichaelArestad can you please switch all the comments here to use this style.

Is using multiline comments the plan for the Sass guide?

I just realize this style has slipped in already in other files, we should switch these to match the style guide in a separate PR

@MichaelArestad well its not necessarily multi line it the only valid style in normal css. I personally don't think its good practice to use different comment styles in different files so we should stick to valid css comments i don't think using // has any benefit over /* */ other then not typing 2 chars which git stripped out in real build anyway i think clarity and consistency should prevail here. @sfrisk what do you think?

There are minor benefits which are situational. No single line comments end up in output CSS files whereas multiline comments do depending on output style. This is handy for when you want to comment things like functions without it ending up in the output code or when you are generating a theme file and want to curate which comments end up in the compiled CSS file.

No single line comments end up in output CSS files whereas multiline comments do depending on output style

So no comments at all end up in minified files which is really what matter. We also use the "Expanded" style which outputs both single and multi line comments so there is no difference here either.

This is handy for when you want to comment things like functions without it ending up in the output code or when you are generating a theme file and want to curate which comments end up in the compiled CSS file.

This would be true if our output style accommodated this however it does not. Only the compressed output style accommodates this

Expanded does not output single line comments. No style does.

Compressed, expanded, and nested support outputting multiline comments (without doing a forced comment /*! */).

@MichaelArestad Your right sorry i looked this up and misread. You are correct here.

So in this case there is basically one major case that makes sense to use single line comments which is where we have a comment that would end up with no context and make no sense if it ended up in an uncompressed output file. This would likely be the case for most functions. Most other places should probably stick to multiline i think still. Since we have both css and scss files in this repo i would like to try to keep things as clear and consistent as possible. Also i think anything that deserved a comment in the scss file should still have one in the uncompressed development build file.

@MichaelArestad how does that sound to you?

Yeah. Probably functions and comments that are implementation instructions for mixins as well. Will change on another PR.

Probably functions and comments that are implementation instructions for mixins as well.

I think a general rule of "will this lose context when its in the built file" could apply for what should use single line.

On a slight aside these sorts of comments in these 2 cases should probably eventually move to the documentation ( once such a thing exists ) but for now yes i agree.

jquerybot added the CLA: Valid label Mar 15, 2015

sfrisk reviewed Mar 17, 2015
View reviewed changes

sfrisk added the [Status] In Progress label Mar 17, 2015

arschmitz reviewed Mar 17, 2015
View reviewed changes

arschmitz closed this in 206014c Apr 7, 2015

arschmitz reopened this Apr 7, 2015

arthurvr reviewed Apr 7, 2015
View reviewed changes

arschmitz mentioned this pull request Apr 8, 2015

Button Re-write jquery/jquery-ui#1513

Closed

MichaelArestad added 2 commits April 9, 2015 17:47

Build: Initial typographic styles

81ff091

Build: minor style tweaks

76bfa64

MichaelArestad force-pushed the add/typographic-styles branch from e1e7ae1 to 76bfa64 Compare April 9, 2015 23:47

MichaelArestad added 3 commits April 9, 2015 18:03

Build: Updated focus styles

46906db

Build: UpRemoved extra markup and added comments

17baf5e

Build: added mixin

308ea27

MichaelArestad added 2 commits April 13, 2015 19:26

Build: added stock htmllint

013745f

Build: string fix

87d8f1d

arschmitz reviewed Apr 14, 2015
View reviewed changes

Build: minor lint updates

780fdf6

arthurvr reviewed Apr 14, 2015
View reviewed changes

arthurvr mentioned this pull request Apr 21, 2015

Component: Meter Styling #73

Closed

Build: removed ad fixed typo

127f034

Build: removed ie meta info

9d945e3

arschmitz reviewed May 3, 2015
View reviewed changes

arschmitz closed this in 64a51ac May 5, 2015

MichaelArestad deleted the add/typographic-styles branch May 7, 2015 03:36

arschmitz mentioned this pull request Aug 4, 2015

Style Guide: Initial commit of SCSS style guide #112

Open

		@@ -0,0 +1,26 @@
		// ==========================================================================

Initial base typography #57

Initial base typography #57

Uh oh!

Conversation

MichaelArestad commented Mar 15, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arschmitz commented Mar 17, 2015

Uh oh!

sfrisk commented Mar 17, 2015

Uh oh!

arschmitz commented Apr 7, 2015

Uh oh!

arschmitz commented Apr 7, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MichaelArestad commented Apr 10, 2015

Uh oh!

MichaelArestad commented Apr 14, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arschmitz commented Apr 14, 2015

Uh oh!

arschmitz commented Apr 14, 2015

Uh oh!

MichaelArestad commented Apr 14, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sfrisk commented May 1, 2015

Uh oh!

MichaelArestad commented May 3, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!