abs() function: update parameter and return value

[estelle]

syntax copies anchor()

original made it seem like the parameter had to be a number. made it clear what the options are.

Samsung is the only non-supporting browser.

[github-actions]

[mdn-linter] _{reported by reviewdog 🐶}

Suggested change

	- : An expression, or calculation, which resolves to a {{cssxref("number")}}, {{cssxref("length")}}, {{cssxref("percentage")}} or a {{cssxref("calc-keyword"). .
	- : An expression, or calculation, which resolves to a {{cssxref("number")}}, {{cssxref("length")}}, {{cssxref("percentage")}} or a {{cssxref("calc-keyword"). .

[github-actions]

Preview URLs

• /en-US/docs/Web/CSS/abs

Flaws (2)

URL: /en-US/docs/Web/CSS/abs
Title: abs()
Flaw count: 2

• macros:
  • Macro produces link /en-US/docs/Learn_web_development/Core/Styling_basics/Fundamental_CSS_comprehension which is a redirect
  • Macro produces link /en-US/docs/Learn_web_development/Core/Styling_basics/Cool-looking_box which is a redirect

(comment last updated: 2025-09-03 21:25:14)

[Josh-Cena]

Is this the new convention? Because this would go against all other references that use "Parameters", which all generally only include a DL. Our page template: https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Page_structures/Page_types/CSS_function_page_template#parameters also does not include this part. This should probably go into the syntax box above:

/* abs( <calc-sum> ) */
abs(20% - 100px)

(In other news we need to remove width: and property: from the syntax)

I'm not against the convention you are proposing here, but we should document it in the page template here, which may also help resolve #40500, alternatively we should consider #40500 a prerequisite, because if we settled on the approach I proposed above, then we can simply remove all this introduction.

[dipikabh]

I also don't think we should add syntax to the "Parameters" section. The first and most obvious reason is that that would make this section inconsistent with our template for CSS functions. Another is that this syntax is too simplistic compared to what we show in Formal syntax, where each value expands into more further underlying expressions - this could become a problem if we try to apply this approach to other function pages.
(side note: not sure why "Formal syntax" is not showing up in the preview, it's there on prod)
A third reason is that we don't follow this convention on property pages either (in the "Values" section), so adding it here would introduce more inconsistency.

anchor() is probably not the best example to follow for this. asin() and clamp() are better aligned with the template (minus the "Syntax" block).

As for the "Syntax" block, although the template says:

Only include the function itself, not a complete declaration in which it occurs....Don't end the syntax lines with semicolons: this should emphasize that we are not showing complete valid CSS code here, just the syntax usage.

Currently this is pretty inconsistent across our function pages.
I don't quite agree with this part of the CSS function template (I believe there was extensive discussion around it before settling on that convention). Since our "Syntax" blocks are really more like "example usage", I think this block should include the complete usage with the property name and ;.

[Josh-Cena]

A function is not a property value. Writing property: function(x); in a syntax box assumes more context than readers can assume. Using this syntax, we cannot possibly infer that calc(1px * abs(x)) is valid syntax, because in fact, we do have CSS functions that only work at a property-value-level and cannot be nested; currently the only case is toggle() which is unimplemented but specified, but this remains a real concern. In JS and Web API, our method syntax is minimal for this purpose: we don't say const y = await someObject.doSomething(x), we say doSomething(x), because someObject may be inferred as an identifier, where in fact it can be substituted by any JS value; the method may not be necessary awaited; and it may not be necessarily assigned to an identifier. we only document the syntax that readers can absolutely expect, not peripheral things that may be composed with it.

[dipikabh]

I also don't think we should add syntax to the "Parameters" section. The first and most obvious reason is that that would make this section inconsistent with our template for CSS functions. Another is that this syntax is too simplistic compared to what we show in Formal syntax, where each value expands into more further underlying expressions - this could become a problem if we try to apply this approach to other function pages.
(side note: not sure why "Formal syntax" is not showing up in the preview, it's there on prod)
A third reason is that we don't follow this convention on property pages either (in the "Values" section), so adding it here would introduce more inconsistency.

anchor() is probably not the best example to follow for this. asin() and clamp() are better aligned with the template (minus the "Syntax" block).

As for the "Syntax" block, although the template says:

Only include the function itself, not a complete declaration in which it occurs....Don't end the syntax lines with semicolons: this should emphasize that we are not showing complete valid CSS code here, just the syntax usage.

Currently this is pretty inconsistent across our function pages.
I don't quite agree with this part of the CSS function template (I believe there was extensive discussion around it before settling on that convention). Since our "Syntax" blocks are really more like "example usage", I think this block should include the complete usage with the property name and ;.

[dipikabh]

we should keep the fact that it takes only one parameter

[dipikabh]

as per the Formal syntax, length should be dimension?

Suggested change

	- `<calc-sum>`
	- : An expression, or calculation, which resolves to a {{cssxref("number")}}, {{cssxref("length")}}, {{cssxref("percentage")}} or a {{cssxref("calc-keyword").
	- `<calc-sum>`
	- : An expression or calculation that resolves to a {{cssxref("number")}}, a {{cssxref("dimension")}}, a {{cssxref("percentage")}} or a {{cssxref("calc-keyword")}}.

[dipikabh]

Suggested change

	- if `<calc-sum>`'s numeric value is positive or `0⁺`, return `<calc-sum>`.
	- Otherwise, returns `-1 * <calc-sum>`.
	- If `<calc-sum>`'s numeric value is positive or `0⁺`, the function returns `<calc-sum>`.
	- Otherwise, it returns `-1 * <calc-sum>`.