Publish minutes of 2024-11-07 meeting #720
Conversation
_minutes/2024-11-07-wecg.md
Outdated
|
|
||
| [Issue 717](https://github.com/w3c/webextensions/issues/717): Request: [ContextMenus] Include `<canvas>`s in the "page" ContextType (or it's own ContextType) | ||
|
|
||
| * [simeon] The only way to match <canvas> elements is to specify “all”. The request is to offer a specific contextType to match <canvas>. |
There was a problem hiding this comment.
| * [simeon] The only way to match <canvas> elements is to specify “all”. The request is to offer a specific contextType to match <canvas>. | |
| * [simeon] The only way to match `<canvas>` elements is to specify “all”. The request is to offer a specific `contextType` to match `<canvas>`. |
There was a problem hiding this comment.
< is a valid way to render < in markdown, at least on Github.
I have applied this suggestion since the title is also using backticks around the canvas; but in the future let's not wrap <canvas> unnecessarily. I try to minimize the amount of unnecessary formatting in the notes because it may be distracting from its content.
_minutes/2024-11-07-wecg.md
Outdated
| * [simeon] Sounds like we're aligned? | ||
| * [rob] I'd like to see more details on use cases. One of the comments was to support a CSS selector to match context menus by selector. That would be a more general way to support this capability. I'm generally in favor of CSS selector. I'm opposed to adding “canvas” ContextType when there is no special context associated with it. | ||
| * [timothy] We'd still have the issue of needing getTargetElement to meaningfully interact with the element | ||
| * [simeon] Agreed, I think we're discussing which solution to issue 717 is the right approach. |
There was a problem hiding this comment.
| * [simeon] Agreed, I think we're discussing which solution to issue 717 is the right approach. | |
| * [simeon] Agreed, I think we're discussing which solution to issue #717 is the right approach. |
There was a problem hiding this comment.
I usually linkify "issue" numbers (e.g. would be [issue 717](https://github.com/w3c/webextensions/issue/717)), but in this case the issue being discussed is the same as the header, so I did not link it.
Is 717 the issue you had in mind, or was it 716?
There was a problem hiding this comment.
You're right, I meant 716. Please link-ify 😄
|
I have not applied these changes to the Google Doc. |
Rob--W
force-pushed
the
meeting-2024-11-07
branch
from
e8efb80 to
703182f
Compare
|
I have applied the requested changes and updated the doc too. Thanks for the review! |
_minutes/2024-11-07-wecg.md
Outdated
| * [simeon] Sounds like we're aligned? | ||
| * [rob] I'd like to see more details on use cases. One of the comments was to support a CSS selector to match context menus by selector. That would be a more general way to support this capability. I'm generally in favor of CSS selector. I'm opposed to adding “canvas” ContextType when there is no special context associated with it. | ||
| * [timothy] We'd still have the issue of needing getTargetElement to meaningfully interact with the element | ||
| * [simeon] Agreed, I think we're discussing which solution to issue 717 is the right approach. |
There was a problem hiding this comment.
You're right, I meant 716. Please link-ify 😄
Rob--W
force-pushed
the
meeting-2024-11-07
branch
from
703182f to
3740adb
Compare
Generated from https://docs.google.com/document/d/1QkwhEMtMS67JBUkl_WVPZ4lRSKoWcQNlLJSf_GwSXg8/edit using the tool and process from #105.
During this meeting we discussed or mentioned issues #718, #531, #708, #711, #713, #715, #716, #717, #719, #527, #532, #501 and PR #546.
In this PR I also included the brief meeting notes of the previous canceled meeting (#709), because I never created a PR for it.