Skip to content
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 compatibility info for extensionTypes.CSSOrigin #380

Merged
merged 1 commit into from
Sep 15, 2017
Merged

Add compatibility info for extensionTypes.CSSOrigin #380

merged 1 commit into from
Sep 15, 2017

Conversation

snoack
Copy link
Contributor

@snoack snoack commented Sep 15, 2017

tabs.insertCSS() got support for the cssOrigin option In Firefox 53. (Bug 1310026). Since then there is also extensionTypes.CSSOrigin.

Copy link
Collaborator

@wbamberg wbamberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it's helpful to have a separate page for the CCSOrigin type, rather than just documenting it in the insertCSS() page?

I tend to think we overengineer the "Types" docs, and especially for types that are only used in one API, it would be better to document them inline rather than in separate pages. But I'd be interested to know what you think.

"__compat": {
"support": {
"chrome": {
"version_added": "false"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

false not "false"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Sorry, it seems the validation didn't care. :/

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we don't validate version numbers yet, it gets a bit complicated.

"version_added": "53"
},
"opera": {
"version_added": "false"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

false not "false"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@snoack
Copy link
Contributor Author

snoack commented Sep 15, 2017

I don't think that we need a separate page for CSSOrigin. However, we should document that it is part of the extensionTypes object. I did that, and this PR is adding the compatibility information there.

Copy link
Collaborator

@wbamberg wbamberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r+

@wbamberg wbamberg merged commit 7fddc69 into mdn:master Sep 15, 2017
@wbamberg
Copy link
Collaborator

Thanks @snoack !

@snoack snoack deleted the extensionTypes.CSSOrigin branch September 15, 2017 21:11
@snoack
Copy link
Contributor Author

snoack commented Sep 15, 2017

Any idea why the compatibility data for CSSOrigin still don't show up on the article? I force reloaded the page while being logged in, a couple times, meanwhile.

@wbamberg
Copy link
Collaborator

Because we don't pull the data direct from GitHub any more: it now gets published as an npm package, and then there needs to be a deployment of the MDN site itself. It'll probably be updated on Monday.

I think we'll streamline this process eventually.

@snoack
Copy link
Contributor Author

snoack commented Sep 15, 2017

Thanks for explaining.

BTW, I just figured out that the extensionTypes object only exists on Firefox. So the compatibility data (not for CSSOrigin but for the other types) seem misleading, indicating whether the respective feature is supported, unrelated of the presence in the extensionTypesobject. What do you think?

@wbamberg
Copy link
Collaborator

Yes, you're probably right.
(this also suggest that using extensionTypes.foo to check whether a particular API is supported is likely to be unreliable).

@snoack
Copy link
Contributor Author

snoack commented Sep 16, 2017

In order to detect support for cssOrigin it is good enough, as it is a Firefox-only feature anyway. So you can just check whether extensionTyptes exists first, that is what we are doing.

But I guess we should update the compatibility info, for every browser but Firefox, for everything in extensionTypes, either setting version_added to false or using partial_implementation and adding a note that while the feature is supported, extensionTypes is not exposed on that browser.

What do you think?

@queengooborg queengooborg added the data:webext 🎲 Compat data for Browser Extensions. https://developer.mozilla.org/Add-ons/WebExtensions label Aug 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
data:webext 🎲 Compat data for Browser Extensions. https://developer.mozilla.org/Add-ons/WebExtensions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants