Remove the overwriting of the default <a> functionality

[JimBobSquarePants]

I thought about adding to the existing discussion on closed issue #38 but I didn't want it to be missed.

Quoting a reply in the discussion.

Phase one of this project is definite more on the CSS framework side of things. Just the stuff you need to get started on a project, with some useful helper classes.

This doesn't seem accurate.

Looking at the code here it seems that the project is already drifting away from basic rules to opinionated design that will have a marked effect on both the ability of developers to overwrite basic styles and the rendering performance within browsers.

https://github.com/jquery/css-chassis/blob/64a51ac31474f7b2c413f8d1767ca776f76228fd/scss/atoms/typography/_typography.scss

Take the code and mixin that is referenced here

p > a {
// Good example of slim underline. We'll want to use this on body copy/quotes
color: inherit;
@include slim-underline;
}

There's now a global selector with a specificity of 0,0,2 that will affect every page the code is added to. It's overwriting the default styles applied to an a tag with behaviour reduces visibility of the link, requires more processing power, and includes hacks for webkit browsers.

https://github.com/jquery/css-chassis/blob/64a51ac31474f7b2c413f8d1767ca776f76228fd/scss/atoms/typography/_mixins.scss

Is this really the intended direction of the project? It seems not.

Chassis is an attempt at creating open standards designed for CSS libraries, JavaScript UI libraries, and web developers in general. This project will define standards for markup and class names for common widgets and patterns, as well as an implementation of those standards. Just like DOM libraries can build upon Sizzle, we hope UI libraries will build upon this.

[sfrisk]

You're right, according to the goals of the project we probably shouldn't have used the mixin and overwritten the default functions of a tag in that way. It (the code) shall be corrected.

[JimBobSquarePants]

Excellent! I'd really love to see something like this succeed and push standards with improved patterns and practise. It'll require strict discipline on the part of everyone involved in order to truly do so though. It's easy (done it myself countless times) to get caught up replacing built in functionality with something shiny.

[jzaefferer]

Might help to rename this issue or replace it with a new one to track down specific issues like the one outlined above.

[sfrisk]

Will do, @jzaefferer, was planning on doing it after today's meeting, so we can specify exactly what we need to replace.

Some of this deals with stuff in the #41 we're working on creating, and we're still figuring out what should (and should not) be in the code.