-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Commit
- Loading branch information
There are no files selected for viewing
3 comments
on commit 3f4b81a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given my previous comments about other sass implementations my preference is to revert/discard this commit before landing this pull request feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to enable sass-supports
to detect differences in implementations' support of existing features, it will need to enumerate more or less every existing feature in Sass. This sounds like a pain, but if you want to work on such an enumeration you're welcome to.
Listing only sourcemaps
just doesn't make any sense, though. There's no reasonable difference in output that a stylesheet would produce based on knowing whether or not sourcemaps could potentially be produced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't agree that the only two options are to list no features, or all the features. For those sass implementations which intend to implement Sass 3.3's feature set, we can provide end-user value by enumerating the features for which there will not be feature parity and a reasonable expectation that it could affect the styles. Honestly, I don't think if there is such a feature in 3.3 at this time, but if @akhleung tells us there is such a situation in libsass, I think it makes sense to list and document those features in this release. For the time being, I am ok to leave the list of features empty.
Nit: unnecessary line.