Skip to content
This repository has been archived by the owner on Oct 2, 2020. It is now read-only.

Get rid of legacy.css #126

Closed
kentcdodds opened this issue Jun 16, 2016 · 4 comments
Closed

Get rid of legacy.css #126

kentcdodds opened this issue Jun 16, 2016 · 4 comments

Comments

@kentcdodds
Copy link
Member

This file is causing a bit of grief. I'd really like to get rid of it.

I think the first thing we need to do is to identify the styles that it has that are no longer in use (whether it be the class names no longer appear in the site or specificity causes it to be unused).

I'd like to get an initial PR that removes all the styles from legacy.css that are not in use. Then we can work on migrating the remaining stuff to aphrodite 👍

@housseindjirdeh
Copy link
Contributor

I can take this on, will get that initial PR by tomorrow hopefully 👍

housseindjirdeh pushed a commit to housseindjirdeh/site that referenced this issue Jun 18, 2016
kentcdodds pushed a commit that referenced this issue Jun 20, 2016
* Remove unused styles in legacy css. For #126

* Added space children class back to episodes page
@housseindjirdeh
Copy link
Contributor

Will get a PR in the next day or so (migrating all the CSS to aphrodite and removing the legacy file) 👍

@housseindjirdeh
Copy link
Contributor

housseindjirdeh commented Jun 21, 2016

@kentcdodds I noticed in the other issue you mentioned a potential workaround for the descendant selection of pseudo-states, but it also seems that aphrodite doesn't officially support styling by tagnames instead of class.

I'm thinking of how I can migrate everything as cleanly as possible and the legacy file has a bunch of descendant tags (h1, h2, h3, hr...).

Do you think we can apply this workaround for now until we can come back and fix it later when it's supported? If so, I can apply that in-line to parent components (like EpisodePage) and that should take care of all its descendant tags.

@kentcdodds
Copy link
Member Author

Ah yeah, let's put those things in aphrodite-shortcomings.css. The other way to do it is to make our own H1 component and use that everywhere, but I think that's not necessary. These styles aren't really component-level, they're more global, and I'm ok with that. I realize that means that we'll be adding a lot of css to that file. I'm ok with that I think.

Thanks!

housseindjirdeh pushed a commit to housseindjirdeh/site that referenced this issue Jun 22, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants