-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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.
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
Add conic-gradient #6661
Add conic-gradient #6661
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spotted a few typos while reading.
|
||
It follows the same rendering rule as CSS <span>conic-gradient</span>. The <var>position</var> is | ||
the center defined by <var>x</var> and <var>y</var> in the coordinate space. This function is | ||
equivalent to CSS conic-gradient(from <var>startAngle</var> deg at <var>x</var> px <var>y</var> px, <var>angular-color-stop-list</var>), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the convention (e.g. in https://html.spec.whatwg.org/#flow-content-3:is-modal) is to wrap CSS expressions in single quotes '
.
equivalent to CSS conic-gradient(from <var>startAngle</var> deg at <var>x</var> px <var>y</var> px, <var>angular-color-stop-list</var>), | ||
where <var>angular-color-stop-list</var> is to be applied to the <code>CanvasGradient</code> by | ||
calling <span data-x="dom-canvasgradient-addColorStop">addColorStop</span>. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does anything need to be said about the coordinate spaces involved? Like, are CSS pixels the same as the canvas pixels?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it helps the clarification, i can add something. I see CSS pixel
defined and used in Canvas, (ex: actualBoundingBoxRight). I can may add it in the previous paragraph where i explain what is x
and y
<p>The <dfn method for="CanvasFillStrokeStyles"><code | ||
data-x="dom-context-2d-createConicGradient">createConicGradient(<var>startAngle</var>, <var>x</var>, | ||
<var>y</var>)</code></dfn> method takes three arguments, the first argument, <var>startAngle</var>, | ||
represents the angle in degree at which the gradient begins, and the last two arguments, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see where it has been defined that angle
should be in degree.
In #5431 (comment) @nt1m was asking if this should be in radians or degrees, but it seems there hasn't been any response in that thread, and given current Nightly still uses radians in the implementation, I guess they haven't been made aware of that decision to use degrees.
For what it's worth, if it's still time to have this discussion, I feel as a web-author that having the angle in degrees is very confusing: If I'm not mistaken, it is the only place in the whole canvas API that we would have an angle expressed in degrees instead of in radians. So if we want to play with that angle and e.g the transformation of the context, or the start/end angles of an ellipse, we'd have to convert between degrees and radians, not to mention the mental gymnastic of remembering where to use what...
If the goal was to have a simpler mapping from CSS, then note that only the <angle> 0
can have the unit omitted, and that CSS has a rad
unit.
Note that there is already a discrepancy with arc
(and ellipse
), where both startAngle
and endAngle
are relative to the x-axis, while CSS conic gradients asks that "0deg points to the top of the page", but that one sounds a bit less dramatic to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(@Kaiido to be clear, now is definitely the time. Thanks for raising this! See also https://whatwg.org/working-mode#changes if you want to get more familiar with the process in general.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for radians. I'm not an expert, but all the JS APIs I know of use (e.g. the Math
functions) use radians, and canvas should definitely be internally consistent.
The inconistency between axes does seem problematic though. Would it make sense to make the mapping (startAngle + Math.PI / 2)
radians so that it matches other canvas APIs? We could also even add a counterclockwise boolean like those APIs have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I implemented this many months ago and cannot remember why I chose degrees. I think I was trying to match some CSS behaviour.
I also would prefer radians, personally. +1 to rotating everything by PI/2 as well to match arc
and ellipse
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strong agree that an angle number without additional type info should be interpreted as radians, coming from a JS API.
Argh at the mismatch of canvas api start angle. CSS copied from SVG, using "bearing angles". I think we should match existing canvas precedent here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am so glad we have this discussion here now before i change more Canvas API.
+1 for radians and rotating everything by PI/2. Canvas API should be consistent. Changing spec. I will also change our implementation to map this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed some editorial tweaks. It now LGTM!
However I noticed that the tests at https://github.com/web-platform-tests/wpt/pull/24299/files seem rather basic. They all use zero angle, so they would not detect the change we made here to radians or to offsetting by pi/2. And if I am reading them right, they all test only a single color (0,255,0,255
), even though they use multiple color stops. Can we improve the test coverage here?
Due to this change, I updated the tests accordingly -> https://chromium-review.googlesource.com/c/chromium/src/+/2891049 I will also add another test for argument validation. What are the other tests you would suggest? I am happy to address them in a later cl. |
I'm still not seeing any tests that actually test the gradient-ness: every pixel test is testing against the same Are there tests that I am missing which test more than one color? Or am I misunderstanding the test suite? I do see a test under |
Thank you for the feedbacks! I added much more tests in https://chromium-review.googlesource.com/c/chromium/src/+/2896865 |
Excellent, that's perfect! I'm happy to merge this now. I'll give this until Monday in case @annevk or anyone else wants to have a final look, then I'll press the merge button. |
Added the new tests pull request in the description. web-platform-tests/wpt#29002 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modulo nits this seems okay. At some point we also need to modernize these method definitions.
<dd> | ||
<p>Returns a <code>CanvasGradient</code> object that represents a | ||
conic gradient that paints clockwise along the rotation around the center | ||
represented by the arguments.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: indentation and wrapping is off and misses an end tag.
data-x="dom-context-2d-createConicGradient">createConicGradient(<var>startAngle</var>, <var>x</var>, | ||
<var>y</var>)</code></dfn> method takes three arguments, the first argument, <var>startAngle</var>, | ||
represents the angle in radians at which the gradient begins, and the last two arguments, | ||
(<var>x</var>, <var>y</var>), represent the center of the gradient in <span data-x="'px'">CSS pixels</span>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: exceeds a 100 columns.
At least two implementers are interested (and none opposed):
Tests are written and can be reviewed and commented upon at:
Implementation bugs are filed:
(See WHATWG Working Mode: Changes for more details.)
/canvas.html ( diff )
/infrastructure.html ( diff )