Bumps @mdn/browser-compat-data from 5.1.5 to 5.2.31.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Superseded by #234.

Bumps @mdn/browser-compat-data from 5.1.5 to 5.2.32.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Update from Github

Update from Github

adding results for tolino

Merge pull request #292 from w3c/tolino-results

Tolino Test Results

Adding results for the tolino web reader.

Update from Github

minutes 2023-01-27

Merge branch 'extending-the-WG-charter' into main

We've received Dev Trial feedback from a major ISV that the state changes between "serious" and "fair" pressure states are too rapid as illustrated below:

This suggests the spec should add an informative note that recommends implementers to add hysteresis to the notify pressure observers algorithm and amend the algorithm steps accordingly to allow an implementation to bail out without notifying if the threshold has not been reached. This seems particularly important at the top-end of the range based on the feedback received.

Adding hysteresis in the implementation as opposed to in the JS logic would also further improve privacy by lowering the entropy of the overall system. This improvement could be noted in the security and privacy considerations section.

(The mathematical model is formalized as Preisach model of hysteresis and is being used in various fields of science and engineering.)

Right, and actually I would have preferred the other syntax for two reasons.

First, the trailing ? in [[[<rg-ending-shape> || <rg-size>]? [at <position>]?] || <color-interpolation-method>]? is useless, which does not seem right to me.

Second, the result is not consistent with the result from parsing other gradients.

conic-gradient(red, cyan), linear-gradient(red, cyan), radial-gradient(red, cyan), produce the following pseudo-representations:

ConicGradient(
  Omitted('[[[from <angle>]? [at <position>]?] || <color-interpolation-method>]')`,
  ColorStopList(Keyword('red'), Keyword('cyan')),
)
LinearGradient(
  Omitted('[[<angle> | to <side-or-corner>] || <color-interpolation-method>]')`,
  ColorStopList(Keyword('red'), Keyword('cyan')),
)
RadialGradient(
  List(
    List(Omitted('<rg-ending-shape> || <rg-size>'), Omitted('at <position>')), 
    Omitted('<color-interpolation-method>')
  ),
  ColorStopList(Keyword('red'), Keyword('cyan')),
)

I let you see if the following asides/ideas are worth creating a new issue:

Aside 1:

<rg-ending-shape> could be replaced by <basic-shape> to allow new shapes of radial gradients.

circle or ellipse (possibly qualified with <extent-keyword>) would be aliases of circle(100% at center center) and ellipse(100% 100% at center center).

Aside 2:

<rg-size> is <rg-extent-kewyord> + <length-percentage> for radial-gradient(), and is <rg-extent-kewyord> + sides for <ray()>.

I think the related productions would be better defined without <size>, whose semantic seems too broad to me:

<radial-gradient()> = radial-gradient( [ ... || [ <extent-keyword> | <length> | <length-percentage> ] ] ... )
<ray()> = ray( [ ... && [ <extent-keyword> | sides ] && ... ] )

<extent-keyword> = closest-corner | closest-side | farthest-corner | farthest-side

Update from Github

Update from Github

Update from Github

Update from Github

Update from Github

Update from spreadsheets

Update from TR

Update study reports from Webref data

Using Webref commit d985a7fb97203f4c7592df3f25520a0a4d4aba03.

Update of ED report from new reffy run

Using reffy commit 11.4.0.

Implementation data update

MathML Full has scriptminsize. This does precisely what @dginev is asking for. The spec says:

However, changes to the font size due to scriptlevel changes should never reduce the size below scriptminsize to prevent scripts becoming unreadably small. The default scriptsizemultiplier is approximately the square root of 1/2 whereas scriptminsize defaults to 8 points;

Looking through the issues, I see the 29/4/19 meeting says

scriptsizemultiplier, scriptminsize: remove them.

However, there is this 2019/03/19 comment by @fred-wang that says

the scriptminsize feature could probably be replaced with CSS's new font-min-size property. Note that this is not exactly the same, since scriptminsize is only supposed to affect the change due to scriptlevel, so we cannot just map to font-min-size. However, I believe it still addresses the use cases for which scriptminsize was introduced.

Unfortunately, that feature never made it into CSS: the basis for making the decision turns out to no longer be true. Hence, the issue should be reopened and the decision reconsidered. Perhaps there is another way to do it with CSS or perhaps we really should have scriptminsize.