Skip to content

Commit

Permalink
Don't have any known features in the 3.3 release.
Browse files Browse the repository at this point in the history
  • Loading branch information
chriseppstein committed Jun 11, 2013
1 parent e3f1f9c commit 3f4b81a
Show file tree
Hide file tree
Showing 4 changed files with 10 additions and 7 deletions.
5 changes: 3 additions & 2 deletions doc-src/SASS_CHANGELOG.md
Expand Up @@ -60,8 +60,9 @@ Thanks to Alexander Pavlov for implementing this.
return a CSS identifier that is unique within the scope of a single CSS file.

* You can now detect the presence of a Sass feature using the new function
`sass-supports($feature)`. For now, `sass-supports(sourcemaps)` is the
only value for which the function returns true.
`sass-supports($feature-name)`. There are no detectable features in this
release, this is provided so that subsequent releases can begin to
use it.

### Backwards Incompatibilities -- Must Read!

Expand Down
1 change: 0 additions & 1 deletion lib/sass/features.rb
Expand Up @@ -7,7 +7,6 @@ module Features

# This is the set of features that can be detected.
KNOWN_FEATURES = Set[*%w{
sourcemaps
}]

# Check if a feature exists by name. This is used to implement
Expand Down
6 changes: 4 additions & 2 deletions lib/sass/script/functions.rb
Expand Up @@ -1321,9 +1321,11 @@ def type_of(value)
# Returns true if the feature name specified exists in this version of Sass.
#
# @example
# sass-supports(sourcemaps) => true
# sass-supports(whatisthisidontknow) => false
# sass-supports(some-feature-that-exists) => true
# sass-supports(what-is-this-i-dont-know) => false
#
# @param feature [Sass::Script::Value::String] The name of the feature to check
#

This comment has been minimized.

Copy link
@nex3

nex3 Jun 14, 2013

Contributor

Nit: unnecessary line.

# @return [Sass::Script::Value::Bool] Whether the feature is supported in this version of Sass.
def sass_supports(feature)
Sass::Script::Value::Bool.new(Sass.has_feature?(feature.value))
Expand Down
5 changes: 3 additions & 2 deletions test/sass/functions_test.rb
Expand Up @@ -978,9 +978,10 @@ def test_type_of
end

def test_sass_supports
assert_equal("true", evaluate("sass-supports(sourcemaps)"))
Sass::Features::KNOWN_FEATURES << "my-test-feature"

This comment has been minimized.

Copy link
@nex3

nex3 Jun 14, 2013

Contributor

Add an "ensure" clause to remove this after the test has run.

assert_equal("true", evaluate("sass-supports(my-test-feature)"))
assert_equal("false", evaluate("sass-supports(whatisthisidontevenknow)"))
assert_equal("true", evaluate("sass-supports($feature: sourcemaps)"))
assert_equal("true", evaluate("sass-supports($feature: my-test-feature)"))
end

def test_unit
Expand Down

3 comments on commit 3f4b81a

@chriseppstein
Copy link
Author

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.

@nex3
Copy link
Contributor

@nex3 nex3 commented on 3f4b81a Jun 14, 2013

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.

@chriseppstein
Copy link
Author

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.

Please sign in to comment.