search

JohnAlbin / normalize-scss

This is the Sass version of Normalize.css, a collection of HTML element and attribute rulesets to normalize styles across all browsers.
https://github.com/JohnAlbin/normalize-scss#latest-versions
MIT License
1.44k stars 254 forks source link

Upgrade to Compass 1.0.0's support and vertical-rhythm modules #18

Closed trmb closed 10 years ago

trmb commented 10 years ago

At least it looks that way: http://beta.compass-style.org/CHANGELOG/

When running alpha versions of Compass 1.0.0 a warning will be issued due to the fact that _normalize.scss sets $legacy-support-for-ie6 and $legacy-support-for-ie7. I solved this problem by simply moving the variables below the compass imports around line 42 since they are still expected later on in _normalize.scss. Of course, for people wanting legacy IE support this probably isn't the best solution as Compass itself isn't being configured.

The warning issued when compiling:

WARNING: Compass has changed how browser support is configured. See the CHANGELOG for more details. The following configuration variables are no longer supported: $legacy-support-for-ie6, $legacy-support-for-ie7.

JohnAlbin commented 10 years ago

Yeah, this is awkward at the moment. The new Compass 1.0.0 variables use a Sass map which is a new feature in Sass 3.3. Since that is still a release candidate, we can't provide both sets of variables in the partial.

I've been thinking about this. The best I can do is make an alpha release of normalize that supports Compass' 1.0.0-alpha-* releases. And leave the stable release as Sass 3.2-compatible.

gussyboy commented 10 years ago

An alpha version sounds perfect, you've got my vote.

JohnAlbin commented 10 years ago

Past midnight here. Going to wait until morning before merging this into master.

JohnAlbin commented 10 years ago

hmm… If I do an alpha release, it can't be 2.1.3-alpha.1 since that is "in the past" relative to the current 2.1.3 for Sass 3.2. So… it will be a 2.1.4-alpha.1 release containing a 2.1.3 normalize.css. :-p

Either the versions numbers need to be completely independent from normalize.css or they need to be in sync.

They way I handled this situation before was to add a build number to the end to show a new version of the Sass with the same version of normalize. e.g. 2.0.1+build.2. (That meant it was the second version of the sass project with normalize 2.01.) So we could go with normalize.scss 2.1.3+sass.3.3.

Pros: version numbers stay in sync with normalize.css. Cons: The Sass 3.3 version of this software is really not backwards compatible with normalize.scss 2.1.3. So calling it 2.1.3+sass.3.3 doesn't actually follow the Semantic Versioning spec. http://semver.org Breaking backwards compatibility requires a major version number to be updated. Even small bug fixes require a version number bump, so my 2.0.1+build.2 version didn't follow the semver spec either.

Hmm… alternatively, we could make the versions independent and add the normalize version as a build number. e.g. 3.0.0-rc.1+normalize.2.1.3 That's a mouthful, but follows the semantic versioning spec exactly.

Pros: Build numbers show exactly what version of normalize is being used. Allow independent versions for the Sass code. Cons: "+normalize.2.1.3" is a very long build number. The last time I used a build number, bower couldn't parse it. https://github.com/bower/bower/issues/188 But it looks like that's fixed now. https://github.com/bower/bower/commit/1ca8eb2d06825e513768193744f48e55969569ac

I'll think about this a bit while adding some tests. Anyone have thoughts?

JohnAlbin commented 10 years ago

Tests added in https://github.com/JohnAlbin/normalize.css-with-sass-or-compass/issues/20

JohnAlbin commented 10 years ago

Good thing I added tests. Found a bug in Compass' support module that made it impossible to turn off IE 7 styling. https://github.com/chriseppstein/compass/pull/1524