Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[css-fonts-4] font-stretch valid values. #2591

Closed
emilio opened this issue Apr 17, 2018 · 7 comments
Closed

[css-fonts-4] font-stretch valid values. #2591

emilio opened this issue Apr 17, 2018 · 7 comments
Labels
Closed Rejected as Invalid css-fonts-4 Current Work

Comments

@emilio
Copy link
Collaborator

emilio commented Apr 17, 2018 •
edited
Loading

https://drafts.csswg.org/css-fonts-4/#font-stretch-prop says:

Values less than 0% are not allowed and are treated as parse errors.

However Safari and Chrome at least treat 0% as invalid:

CSS.supports('font-stretch', '0%') -> false
CSS.supports('font-stretch', '10%') -> true

What's the expected thing here? Is it a typo in the spec, or should 0% really be allowed, and thus a bug in WebKit / Blink?

cc @litherum
@emilio emilio added the css-fonts-4 Current Work label Apr 17, 2018
@emilio
Copy link
Collaborator Author

emilio commented Apr 17, 2018

Also cc @drott. @FremyCompany, what does Edge do here? I couldn't test with a build that supported percentages in font-stretch.

@jfkthame
Copy link
Contributor

Interestingly, in Chrome i get true for

CSS.supports('font-stretch', '0.000000000000000000000000000000000000000000001%')

even though such a tiny value appears to compute to 0%.

@jfkthame
Copy link
Contributor

I checked MSEdge, and confirmed that CSS.supports('font-stretch', '0%') returns true, as per spec. (And correctly returns false for negative values.)

@drott
Copy link
Collaborator

drott commented Apr 18, 2018 •
edited
Loading

Yes, if we the spec stays unchanged, it's a bug in Chrome, we reject for <= 0, should be easy to fix by changing the parse-time check. It's a different discussion how much sense is in 0% as a stretch value. Filed crbug.com/834236.

@tabatkins
Copy link
Member

Doesn't matter whether it makes sense or not; percentages are floats, and so disallowing 0% would make the valid syntax an open range, which is disallowed as a general spec-design rule. (For example, it makes it unclear what value font-stretch: calc(-10%) should clamp to.)

Given that this is just a factor in the font-selection, not something used directly, there's nothing wrong with 0%; it just means you'll select the narrowest available font.

@tabatkins
Copy link
Member

Closing because the spec is clear, Chrome just has a bug.

@drott
Copy link
Collaborator

drott commented Apr 19, 2018

[...] and so disallowing 0% would make the valid syntax an open range, which is disallowed as a general spec-design rule. (For example, it makes it unclear what value font-stretch: calc(-10%) should clamp to.)

Thanks for the clarification, makes sense.

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Apr 23, 2018
@emilio
Bug 1436048: Fix and update other WPT expectations in css-fonts-4 tes…
dbc3c29 
…ts. r=jwatt

The test adjustments are:

  A subtest of variable-presentation-attribute.html is marked as failure,
  pending resolution of w3c/csswg-drafts#2605.

  font-parse-numeric-stretch-style-weight.html is updated to:

    * handle calc per spec (invalid at computed-value time), see
      w3c/csswg-drafts#2590

    * Accept 0% in font-stretch: w3c/csswg-drafts#2591

    * Accept font-weight descriptor ranges where the start is greater than the
      end, per
      https://drafts.csswg.org/css-fonts-4/#descdef-font-face-font-weight, which
      says:

      > User agents must swap the computed value of the startpoint and endpoint
      > of the range in order to forbid decreasing ranges.

  font-shorthand.html is updated to presumably fix a copy-paste error, where
  "oblique 45deg" was expected to compute to "oblique", which is wrong.

The rest is removing failure annotations.

MozReview-Commit-ID: CNJ3LG71KRj
moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this issue Apr 23, 2018
@emilio @moz-wptsync-bot
Fix and update other WPT expectations in css-fonts-4 tests.
f7c389a 
The test adjustments are:

  A subtest of variable-presentation-attribute.html is marked as failure,
  pending resolution of w3c/csswg-drafts#2605.

  font-parse-numeric-stretch-style-weight.html is updated to:

    * handle calc per spec (invalid at computed-value time), see
      w3c/csswg-drafts#2590

    * Accept 0% in font-stretch: w3c/csswg-drafts#2591

    * Accept font-weight descriptor ranges where the start is greater than the
      end, per
      https://drafts.csswg.org/css-fonts-4/#descdef-font-face-font-weight, which
      says:

      > User agents must swap the computed value of the startpoint and endpoint
      > of the range in order to forbid decreasing ranges.

  font-shorthand.html is updated to presumably fix a copy-paste error, where
  "oblique 45deg" was expected to compute to "oblique", which is wrong.

The rest is removing failure annotations.
bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1436048
gecko-commit: b61541f85293fa3fddd7edfe9863624f9a56e92b
gecko-integration-branch: mozilla-inbound
gecko-reviewers: jwatt
moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this issue Apr 24, 2018
@emilio @moz-wptsync-bot
Fix and update other WPT expectations in css-fonts-4 tests.
12a2ed1 
The test adjustments are:

  A subtest of variable-presentation-attribute.html is marked as failure,
  pending resolution of w3c/csswg-drafts#2605.

  font-parse-numeric-stretch-style-weight.html is updated to:

    * handle calc per spec (invalid at computed-value time), see
      w3c/csswg-drafts#2590

    * Accept 0% in font-stretch: w3c/csswg-drafts#2591

    * Accept font-weight descriptor ranges where the start is greater than the
      end, per
      https://drafts.csswg.org/css-fonts-4/#descdef-font-face-font-weight, which
      says:

      > User agents must swap the computed value of the startpoint and endpoint
      > of the range in order to forbid decreasing ranges.

  font-shorthand.html is updated to presumably fix a copy-paste error, where
  "oblique 45deg" was expected to compute to "oblique", which is wrong.

The rest is removing failure annotations.
bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1436048
gecko-commit: b61541f85293fa3fddd7edfe9863624f9a56e92b
gecko-integration-branch: mozilla-inbound
gecko-reviewers: jwatt
Merged
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 7, 2018
@csnardi @chromium-wpt-export-bot
Allow 0% in font-stretch
7976dd8 
Per w3c/csswg-drafts#2591, 0% should be an
allowed value in font-stretch. Remove the check that percentages are >=
0 for font-stretch, as any negative non calc values are already rejected
by kValueRangeNonNegative. Also update a test of valid calc values in
font-stretch, as even though they are outside the allowed range, they
should not be subject to parse-time constraints.

Bug: 834236
Change-Id: I0e728d8cc89b45bac7be956a7662533d4775c511
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 7, 2018
@csnardi @chromium-wpt-export-bot
Allow 0% in font-stretch
3176587 
Per w3c/csswg-drafts#2591, 0% should be an
allowed value in font-stretch. Remove the check that percentages are >=
0 for font-stretch, as any negative non calc values are already rejected
by kValueRangeNonNegative. Also update a test of valid calc values in
font-stretch, as even though they are outside the allowed range, they
should not be subject to parse-time constraints.

Bug: 834236
Change-Id: I0e728d8cc89b45bac7be956a7662533d4775c511
aarongable pushed a commit to chromium/chromium that referenced this issue May 7, 2018
@csnardi
Allow 0% in font-stretch
7cba16c 
Per w3c/csswg-drafts#2591, 0% should be an
allowed value in font-stretch. Remove the check that percentages are >=
0 for font-stretch, as any negative non calc values are already rejected
by kValueRangeNonNegative. Also update a test of valid calc values in
font-stretch, as even though they are outside the allowed range, they
should not be subject to parse-time constraints.

Bug: 834236
Change-Id: I0e728d8cc89b45bac7be956a7662533d4775c511
Reviewed-on: https://chromium-review.googlesource.com/1046926
Commit-Queue: Chris Nardi <cnardi@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556568}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 7, 2018
@csnardi @chromium-wpt-export-bot
Allow 0% in font-stretch
9a879d3 
Per w3c/csswg-drafts#2591, 0% should be an
allowed value in font-stretch. Remove the check that percentages are >=
0 for font-stretch, as any negative non calc values are already rejected
by kValueRangeNonNegative. Also update a test of valid calc values in
font-stretch, as even though they are outside the allowed range, they
should not be subject to parse-time constraints.

Bug: 834236
Change-Id: I0e728d8cc89b45bac7be956a7662533d4775c511
Reviewed-on: https://chromium-review.googlesource.com/1046926
Commit-Queue: Chris Nardi <cnardi@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556568}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 7, 2018
@csnardi @chromium-wpt-export-bot
Allow 0% in font-stretch
bbb7327 
Per w3c/csswg-drafts#2591, 0% should be an
allowed value in font-stretch. Remove the check that percentages are >=
0 for font-stretch, as any negative non calc values are already rejected
by kValueRangeNonNegative. Also update a test of valid calc values in
font-stretch, as even though they are outside the allowed range, they
should not be subject to parse-time constraints.

Bug: 834236
Change-Id: I0e728d8cc89b45bac7be956a7662533d4775c511
Reviewed-on: https://chromium-review.googlesource.com/1046926
Commit-Queue: Chris Nardi <cnardi@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556568}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue May 14, 2018
@csnardi @moz-wptsync-bot
Bug 1459585 [wpt PR 10866] - Allow 0% in font-stretch, a=testonly
d7d45bc 
Automatic update from web-platform-testsAllow 0% in font-stretch

Per w3c/csswg-drafts#2591, 0% should be an
allowed value in font-stretch. Remove the check that percentages are >=
0 for font-stretch, as any negative non calc values are already rejected
by kValueRangeNonNegative. Also update a test of valid calc values in
font-stretch, as even though they are outside the allowed range, they
should not be subject to parse-time constraints.

Bug: 834236
Change-Id: I0e728d8cc89b45bac7be956a7662533d4775c511
Reviewed-on: https://chromium-review.googlesource.com/1046926
Commit-Queue: Chris Nardi <cnardi@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556568}

--

wpt-commits: bbb732773d07230e07f95c551e09b851d450effa
wpt-pr: 10866
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Oct 2, 2019
@marco-c
Bug 1436048: Fix and update other WPT expectations in css-fonts-4 tes…
673d071 
…ts. r=jwatt

The test adjustments are:

  A subtest of variable-presentation-attribute.html is marked as failure,
  pending resolution of w3c/csswg-drafts#2605.

  font-parse-numeric-stretch-style-weight.html is updated to:

    * handle calc per spec (invalid at computed-value time), see
      w3c/csswg-drafts#2590

    * Accept 0% in font-stretch: w3c/csswg-drafts#2591

    * Accept font-weight descriptor ranges where the start is greater than the
      end, per
      https://drafts.csswg.org/css-fonts-4/#descdef-font-face-font-weight, which
      says:

      > User agents must swap the computed value of the startpoint and endpoint
      > of the range in order to forbid decreasing ranges.

  font-shorthand.html is updated to presumably fix a copy-paste error, where
  "oblique 45deg" was expected to compute to "oblique", which is wrong.

The rest is removing failure annotations.

MozReview-Commit-ID: CNJ3LG71KRj

UltraBlame original commit: b61541f85293fa3fddd7edfe9863624f9a56e92b
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Oct 2, 2019
@marco-c
Bug 1436048: Fix and update other WPT expectations in css-fonts-4 tes…
2c6bda9 
…ts. r=jwatt

The test adjustments are:

  A subtest of variable-presentation-attribute.html is marked as failure,
  pending resolution of w3c/csswg-drafts#2605.

  font-parse-numeric-stretch-style-weight.html is updated to:

    * handle calc per spec (invalid at computed-value time), see
      w3c/csswg-drafts#2590

    * Accept 0% in font-stretch: w3c/csswg-drafts#2591

    * Accept font-weight descriptor ranges where the start is greater than the
      end, per
      https://drafts.csswg.org/css-fonts-4/#descdef-font-face-font-weight, which
      says:

      > User agents must swap the computed value of the startpoint and endpoint
      > of the range in order to forbid decreasing ranges.

  font-shorthand.html is updated to presumably fix a copy-paste error, where
  "oblique 45deg" was expected to compute to "oblique", which is wrong.

The rest is removing failure annotations.

MozReview-Commit-ID: CNJ3LG71KRj

UltraBlame original commit: b61541f85293fa3fddd7edfe9863624f9a56e92b
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Oct 2, 2019
@marco-c
Bug 1436048: Fix and update other WPT expectations in css-fonts-4 tes…
6406dd7 
…ts. r=jwatt

The test adjustments are:

  A subtest of variable-presentation-attribute.html is marked as failure,
  pending resolution of w3c/csswg-drafts#2605.

  font-parse-numeric-stretch-style-weight.html is updated to:

    * handle calc per spec (invalid at computed-value time), see
      w3c/csswg-drafts#2590

    * Accept 0% in font-stretch: w3c/csswg-drafts#2591

    * Accept font-weight descriptor ranges where the start is greater than the
      end, per
      https://drafts.csswg.org/css-fonts-4/#descdef-font-face-font-weight, which
      says:

      > User agents must swap the computed value of the startpoint and endpoint
      > of the range in order to forbid decreasing ranges.

  font-shorthand.html is updated to presumably fix a copy-paste error, where
  "oblique 45deg" was expected to compute to "oblique", which is wrong.

The rest is removing failure annotations.

MozReview-Commit-ID: CNJ3LG71KRj

UltraBlame original commit: b61541f85293fa3fddd7edfe9863624f9a56e92b
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Oct 3, 2019
@marco-c
Bug 1459585 [wpt PR 10866] - Allow 0% in font-stretch, a=testonly
3693840 
Automatic update from web-platform-testsAllow 0% in font-stretch

Per w3c/csswg-drafts#2591, 0% should be an
allowed value in font-stretch. Remove the check that percentages are >=
0 for font-stretch, as any negative non calc values are already rejected
by kValueRangeNonNegative. Also update a test of valid calc values in
font-stretch, as even though they are outside the allowed range, they
should not be subject to parse-time constraints.

Bug: 834236
Change-Id: I0e728d8cc89b45bac7be956a7662533d4775c511
Reviewed-on: https://chromium-review.googlesource.com/1046926
Commit-Queue: Chris Nardi <cnardichromium.org>
Reviewed-by: Dominik Röttsches <drottchromium.org>
Cr-Commit-Position: refs/heads/master{#556568}

--

wpt-commits: bbb732773d07230e07f95c551e09b851d450effa
wpt-pr: 10866

UltraBlame original commit: c1590c4fac5713fa4330f04371b486015fca7d82
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Oct 3, 2019
@marco-c
Bug 1459585 [wpt PR 10866] - Allow 0% in font-stretch, a=testonly
2fcf866 
Automatic update from web-platform-testsAllow 0% in font-stretch

Per w3c/csswg-drafts#2591, 0% should be an
allowed value in font-stretch. Remove the check that percentages are >=
0 for font-stretch, as any negative non calc values are already rejected
by kValueRangeNonNegative. Also update a test of valid calc values in
font-stretch, as even though they are outside the allowed range, they
should not be subject to parse-time constraints.

Bug: 834236
Change-Id: I0e728d8cc89b45bac7be956a7662533d4775c511
Reviewed-on: https://chromium-review.googlesource.com/1046926
Commit-Queue: Chris Nardi <cnardichromium.org>
Reviewed-by: Dominik Röttsches <drottchromium.org>
Cr-Commit-Position: refs/heads/master{#556568}

--

wpt-commits: bbb732773d07230e07f95c551e09b851d450effa
wpt-pr: 10866

UltraBlame original commit: c1590c4fac5713fa4330f04371b486015fca7d82
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Oct 3, 2019
@marco-c
Bug 1459585 [wpt PR 10866] - Allow 0% in font-stretch, a=testonly
569dc60 
Automatic update from web-platform-testsAllow 0% in font-stretch

Per w3c/csswg-drafts#2591, 0% should be an
allowed value in font-stretch. Remove the check that percentages are >=
0 for font-stretch, as any negative non calc values are already rejected
by kValueRangeNonNegative. Also update a test of valid calc values in
font-stretch, as even though they are outside the allowed range, they
should not be subject to parse-time constraints.

Bug: 834236
Change-Id: I0e728d8cc89b45bac7be956a7662533d4775c511
Reviewed-on: https://chromium-review.googlesource.com/1046926
Commit-Queue: Chris Nardi <cnardichromium.org>
Reviewed-by: Dominik Röttsches <drottchromium.org>
Cr-Commit-Position: refs/heads/master{#556568}

--

wpt-commits: bbb732773d07230e07f95c551e09b851d450effa
wpt-pr: 10866

UltraBlame original commit: c1590c4fac5713fa4330f04371b486015fca7d82
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Rejected as Invalid css-fonts-4 Current Work
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tabatkins @drott @emilio @jfkthame