Reset link styles

[AntonTrollback]

Link styles can instead be applied using the following techniques:

• u-link (could be added to the official utils-link collection)
• Button--link (could be added to the Button component, but maybe not)
• With some kind of .Type component. Mine includes link styles and is used for any wysiwyg output and most interface copy.

I have been testing this out in a few projects and really like it.

[simonsmith]

How do you mean? Should the base undo some browser defaults?

[AntonTrollback]

Yep. It's already removing button styles and margins.

[simonsmith]

Yeah, I tend to extend base with my own one that then adds things to links, headers and paragraphs. basically element selectors only.

It sounds sensible that this package could remove colours, underlines and such

[necolas]

i've come to think of any tag-level styles as an anti-pattern. once a component depends on these kinds of tag style resets, its rendering is that much less predictable.

[timkelty]

@necolas Philosophically I agree, but when it comes to dealing with user generated content (e.g. something from a CMS), I tend to always need a component with some tag-level dependents for basic typography.

[simonsmith]

It tends to depend on your app I suppose. A lot of the time I write components that aren't shared amongst projects but are reused in the same one. This does allow you some control over element selectors.

If I were to publish components outside of that domain I would agree depending on existing base styles as risky.

[giuseppeg]

I agree with @necolas on this one. I like the u-link and Type idea better. In fact I use it for my blog http://git.io/vcQzB.

[timkelty]

@giuseppeg Yep, i employ a similar approach as your example. I'm all for resetting link styles here, then.

On a related note, I've found it curious is that utils-link seems to rely on the assumption that links are styled with underlined hovers.

[simonsmith]

So would this mainly effect just the text underline? I feel like colours are theme domain

[AntonTrollback]

What I had in mind, rendering links as plain text:

a {
  color: inherit;
  text-decoration: inherit;
}

I try not to extend base with any global tag-level styles. I basically move that stuff, like page background and a global font-family, to a .Site or .Page component.

[timkelty]

Makes sense to me.

[simonsmith]

@AntonTrollback Want to PR this?

[simonsmith]

I jumped in and added it, just a small change

[giuseppeg]

rendering links as plain text

This is wrong imho because it resets the defaults for active and visited states and in general makes it look like normal text. Personally I would keep the browser defaults.

[timkelty]

@giuseppeg, @necolas: I'm seeing your points here, except couldn't you make the same case for all the styles here? For instance, button is reset to not look like buttons, and any Component relies on that reset will have the same pitfalls.

This repo seems like an exception, as it is more a convenient way to get a blank start. If you were worried about your components relying on any resets, then I would say just don't use suitcss-base.

That said, I don't feel super strongly either way about the particular case of the a reset, so whatever the consensus is works for me.

[simonsmith]

What's the consensus? I'm also on the fence. It's something I define in every project anyway

[giuseppeg]

What I would reset from normalize is margins and box-sizing only. The rest is something I define in every project anyway.

[simonsmith]

Maybe we should leave this then

[timkelty]

Side note: an option could be to deprecate this package and condone the use of sanitize.css

[AntonTrollback]

My experience with global tag-level styles is that they become annoying when creating navigations and generic stuff like Component-action. Especially when components could be shared across different apps and you no longer know what styles to take into concern.

once a component depends on these kinds of tag style resets, its rendering is that much less predictable.

The more I think about this the more I feel like normalize.css is about the only thing a generic component should depend on. It solves the problem above and is probably a better approach than reseting everything.

I'll try it out :) I'm fine with closing this issue.