Add versions to CanvasRenderingContext2D for features in CanvasPath mixin #6393
Conversation
ghost
added
the
data:api 🐇
|
There's no way to withdraw approvals. Shouldn't these methods be listed on the APIs that use the mixin? A mixin is just a convenience to save browsers from duplicating information in multiple places. Not only is there (as far as I know) no requirement for vendors to use these, duplicating this on MDN forces web developers to understand what's in browsers' source code. Such information is not available on all browsers. |
|
(I guess this PR is filed to force us to have the mixin debate?) I'm actually the original author of the Canvas API docs and my take on the mixin debate for canvas has been to not expose these to MDN readers when I wrote these docs. I haven't looked into this API in a long time, but as far as I know So, with this PR, you would need to present the information as
Or maybe as:
And the MDN pages at https://developer.mozilla.org/docs/Web/API/CanvasPath/rect and https://developer.mozilla.org/docs/Web/API/CanvasPath/ellipse will need to talk about the Canvas2D context and the OffScreenCanvas context. It will need to have 2 spec links also for both contexts, it will need to have 2 examples for each context, etc. So, if we would merge this PR, there is quite some follow up work to be done on MDN. Who would do this work? The alternative, and this is the road I was going with canvas docs, is to flatten the spec mixins. That is, ignore that idl files have mixins like CanvasPath, CanvasText, and friends and document the methods and properties under the interface that is exposed to web developers, which in this case are In BCD, this would mean:
On MDN, this would mean:
Which way to go here has been argued about at random times in the last years. I prefer more to flatten and not expose mixins on MDN and to web devs. This means creating more MDN pages, but I think it is worth it. Other people would prefer to not flatten and present mixins to web devs and then also have less pages on MDN. An argument is that information is duplicated, so you have e.g. two quite similar pages that talked about So given this new PR, I'm curious if you have any new insights that would favor mixins in BCD and MDN? See also |
|
That all makes sense, yeah -- I had a few of those questions when I was working on this PR myself. To summarize, we should probably undo the separation, and instead just update the version numbers on |
No. It just worked out that way. 🙂 |
Yes.
Yes.
No. Members of |
queengooborg
changed the title
It might be better to just say, don't assume either way. Sometimes interfaces with mixins are created together. Sometimes the mixin isn't created until it's recognized that some feature set needs to be on multiple interfaces. |
A number of features in the
CanvasRenderingContext2DAPI are a part of a mixin known asCanvasPath. As described in the spec, this mixin is also included in thePath2Dinterface.This PR
splits the functions of theadds the missing version numbers for when support was added based upon manual testing (checking to see if the function is defined onCanvasPathmixin into its own file, andCanvasRenderingContext2D), as well as fixing some instances where support was indicated asfalsefor certain browsers which is inaccurate (Firefox Android, Safari iOS, WebView...).The new file also references MDN pages that have not been created, so they will need to be written up as well.