Add more HTML spec keys #2405
Add more HTML spec keys #2405
Conversation
github-actions
bot
added
the
feature definition
|
Ok nothing too crazy in here, getting through the sprinkly bits. |
| @@ -41,15 +43,21 @@ compat_features: | |||
| - api.OffscreenCanvasRenderingContext2D.fillRect | |||
| - api.OffscreenCanvasRenderingContext2D.fillStyle | |||
| - api.OffscreenCanvasRenderingContext2D.fillText | |||
| - api.OffscreenCanvasRenderingContext2D.filter | |||
There was a problem hiding this comment.
You've added a bunch of new BCD keys here which are not supported on Safari (filter, letterSpacing, wordSpacing, etc.). I'm OK with this because the corresponding canvas keys are also in the canvas-2d feature (also ignored with a compute_from).
However, I want to note that these are later additions (quite recent in fact) and I lack the domain knowledge to understand if these are seen as separate by canvas users, and whether they'd expect to see them as their own features.
So, nothing to change here for me, other than preparing for potential issues in the future from confused canvas developers wondering why canvas-2d and offscreen-canvas are baseline high when these things are not supported.
There was a problem hiding this comment.
Thanks, I had same thought when adding them. But the group guidance has always been "start big, and split off smaller features over time as needed" vs "make too many features that are later harder to correct", hence this inclusion of non-baseline keys... not just here, but in many many places across the Web Features set.
As I've said more than a few times now: I'd love a consistently applied criteria and process for determining developer POV. We do not have that. I've suggested things like personas, "area peers", a dedicated standards contact... there are so many ways to mitigate the churn and better reflect developer POV which I hope are adopted over time.
| @@ -1,9 +1,12 @@ | |||
| name: Beforeunload | |||
| description: "The `beforeunload` event is fired when the current window is about to be unloaded. Typically this is used to display a dialog to confirm if users really want to leave the page when there is unsaved data that would be lost." | |||
| spec: https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-beforeunloadevent-interface | |||
| status: | |||
| compute_from: api.Window.beforeunload_event | |||
There was a problem hiding this comment.
This is the entry point, and aligns w/ the actual core feature availability better.
No description provided.