Checker used at W3C to validate the compliance of Technical Reports with publication rules
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 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
.