惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

爱范儿
爱范儿
博客园_首页
W
WeLiveSecurity
S
Secure Thoughts
S
Security @ Cisco Blogs
Recent Commits to openclaw:main
Recent Commits to openclaw:main
Hugging Face - Blog
Hugging Face - Blog
www.infosecurity-magazine.com
www.infosecurity-magazine.com
H
Hacker News: Front Page
Project Zero
Project Zero
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
U
Unit 42
N
News and Events Feed by Topic
N
News and Events Feed by Topic
Hacker News - Newest:
Hacker News - Newest: "LLM"
Forbes - Security
Forbes - Security
T
Tor Project blog
I
Intezer
B
Blog
F
Full Disclosure
Security Archives - TechRepublic
Security Archives - TechRepublic
F
Fortinet All Blogs
Schneier on Security
Schneier on Security
T
Threat Research - Cisco Blogs
AI
AI
Google DeepMind News
Google DeepMind News
L
LINUX DO - 最新话题
Cloudbric
Cloudbric
L
Lohrmann on Cybersecurity
WordPress大学
WordPress大学
博客园 - 聂微东
雷峰网
雷峰网
P
Privacy International News Feed
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
PCI Perspectives
PCI Perspectives
Y
Y Combinator Blog
Spread Privacy
Spread Privacy
Simon Willison's Weblog
Simon Willison's Weblog
罗磊的独立博客
Vercel News
Vercel News
A
Arctic Wolf
The Register - Security
The Register - Security
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Microsoft Azure Blog
Microsoft Azure Blog
H
Heimdal Security Blog
Know Your Adversary
Know Your Adversary
P
Proofpoint News Feed
C
Cybersecurity and Infrastructure Security Agency CISA
P
Proofpoint News Feed

Sass Blog

New JS API Release Candidate is Live Sass: Request for Comments: New JS API Sass: The Discontinuation of node-fibers Sass: LibSass is Deprecated Request for Comments: HWB Functions
Request for Comments: First-Class Calc
Natalie Weiz · 2021-03-15 · via Sass Blog

Posted 15 March 2021 by Natalie Weizenbaum

One of the absolutely most-requested features in Sass is the ability to more easily work with calc() expressions. These expressions have historically been parsed opaquely: between the parentheses, you can put any text at all, and Sass will just treat it as an unquoted string. This has simplified Sass’s parser, since we don’t have to support the specific calc() microsyntax, and it’s meant that we automatically support new features like the use of CSS variables within calc().

However, it comes at a substantial usability cost as well. Because each calc() is totally opaque to Sass’s parser, users can’t simply use Sass variables in place of values; they have to interpolate variables explicitly. And once a calc() expression has been created, there’s no way to manipulate it with Sass the way you can manipulate a plain number.

We’re looking to change that with a new proposal we call "First-Class Calc". This proposal changes calc() (and other supported mathematical functions) from being parsed as unquoted strings to being parsed in-depth, and sometimes (although not always) producing a new data type known as a "calculation". This data type represents mathematical expressions that can’t be resolved at compile-time, such as calc(10% + 5px), and allows those expressions to be combined gracefully within further mathematical functions.

To be more specific: a calc() expression will be parsed according to the CSS syntax, with additional support for Sass variables, functions, and (for backwards compatibility) interpolation. Sass will perform as much math as possible at compile-time, and if the result is a single number it will return it as a normal Sass number type. Otherwise, it will return a calculation that represents the (simplified) expression that can be resolved in the browser.

For example:

  • calc(1px + 10px) will return the number 11px.

  • Similarly, if $length is 10px, calc(1px + $length) will return 11px.

  • However, calc(1px + 10%) will return the calc calc(1px + 10%).

  • If $length is calc(1px + 10%), calc(1px + $length) will return calc(2px + 10%).

  • Sass functions can be used directly in calc(), so calc(1% + math.round(15.3px)) returns calc(1% + 15px).

Note that calculations cannot generally be used in place of numbers. For example, 1px + calc(1px + 10%) will produce an error, as will math.round(calc(1px + 10%)). This is because calculations can’t be used interchangeably with numbers (you can’t pass a calculation to math.sqrt()), so we want to make sure mathematical functions are explicit about whether or not they support calculations by either wrapping all of their math in calc() or using normal Sass arithmetic.

For backwards compatibility, calc() expressions that contain interpolation will continue to be parsed using the old highly-permissive syntax, although this behavior will eventually be deprecated and removed. These expressions will still return calculation values, but they’ll never be simplified or resolve to plain numbers.

Let us know what you think!Let us know what you think! permalink

If you’re interested in learning more about this proposal, read it in full on GitHub. It’s open for comments and revisions for the next month, so if you’d like to see something change please file an issue and we can discuss it!