Comments (7)
You say that the ID will be stored within the JSON, though in the examples they are missing. Also, it's unclear to me, what you mean with "bottom of the ID".
Sebastian
from browser-compat-data.
1 file for a large set of features (like WebExtensions). We privileges here the simplicity to do batch changes.
This isn't the main reason WE has one massive file. The main reason is that I want to be able to generate pages like this: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs. It's not clear to me how I could do this if the compat data was split up into lots of individual files.
I don't think I really understand this proposal either. At the moment WE JSON looks something like this:
{
"i18n": {
"getUILanguage": {
...[compat data]
},
"LanguageCode": {
...[compat data]
},
...[more i18n APIs]
},
"cookies": {
"getAllCookieStores": {
...[compat data]
},
...[etc]
So I guess the "ID" would be i18n/getUILanguage
etc., and all i18n APIs are properties of i18n
: this makes it easy for code to do "get compat data for i18n", to build tables like https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/i18n#Browser_compatibility.
How would this differ under the current proposal, and how would I build these aggregate tables?
from browser-compat-data.
@SebastianZ: sorry I've not been clear enough. The id of line-height would be css.properties.line-height.
@wbamberg: the proposal is not fundamentally different than the one of WE. The main difference is that the ID will be unique through all the files, being one, or being multiple. This means that the id must be unique not only inside a file, but throughout all the files. This is enforces at review time, helped by a simple id scheme.
The possibility to use one large file, or several small files, is left to the curator of each area. Ideally, in the future macros will use a DB and the notion of file will disappear.
In the case of WebExtensions, there will still be one large file, with similar ids. The ids will be a bit longer.
Instead of: i18.cookies, it will be webextensions.i18.cookies (or similar):
{
"webextensions": {
"i18n": {
"getUILanguage": {
...[compat data]
},
"LanguageCode": {
...[compat data]
},
...[more i18n APIs]
},
"cookies": {
"getAllCookieStores": {
...[compat data]
},
...[etc]
}
}
That way we can easily merge different files, or separate them as the id scheme is universal throughout all browser compat data.
from browser-compat-data.
Thanks for the clarification @teoli2003 ! I'm +1 on this proposal now.
from browser-compat-data.
@SebastianZ: sorry I've not been clear enough. The id of line-height would be css.properties.line-height.
Ah, I see. You call the JSON path down to an entry the "ID". 😄 With your description I would have expected a key "id" containing "css.properties.line-height".
So, yes, your proposal is fine for me.
Sebastian
from browser-compat-data.
I like the proposal.
The _compat
element is vital for code to be able to walk the tree of data, so that the data walker knows it should expect compatibility data, rather than look for new child elements. I think you'll need to describe in more detail how that is used.
If it is just "_compat": true
, you can't mix ID and compatibility data. For example, you can't add support information to "webextensions.i18n", only to "webexetensions.i18n.getUILanguage". You'll have to use a trick like "webextensions.i18n.basic_support" if you want to talk about support in a more general way:
{
"webextensions": {
"i18n": {
"basicSupport": {
"_compat": true,
[generic, caniuse-style compat data]
},
"getUILanguage" {
"_compat": true,
[specific, MDN-style compat data]
}
}
}
}
Alternatively, you compatibility data could appear under the _compat
element, so you know there is compat data attached to that node.
{
"webextensions": {
"i18n": {
"_compat": [generic, caniuse-style compat data],
"getUILanguage" {
"_compat": [specific, MDN-style compat data],
}
}
}
}
Update: Issue #114 specifies the second form, that data appears under the __compat
element.
from browser-compat-data.
I think we've come to an agreement here and the new schema reflects that. Please open new issues if you have new feedback on identifiers.
from browser-compat-data.
Related Issues (20)
- api.ClipboardEvent.clipboardData - Incorrect availability banner HOT 1
- css.properties.letter-spacing - <Google chrome handle letter spacing diff> HOT 1
- html.textarea.spellcheck - duplicated global attributes
- api.fetch - Safari 17.2 supports setting priority of fetch HOT 3
- html.elements.image - <SUMMARIZE THE PROBLEM> HOT 1
- http.headers.Alt-Svc - Safari Alt-Svc compatibility is outdated
- html.elements.mark - Support in screen readers is mixed HOT 15
- http.status.503 - <SUMMARIZE YOUR PROBLEM> HOT 1
- http.status.504 - <SUMMARIZE THE PROBLEM> HOT 1
- api.File.type - duplicated data between `api.File.type` and `api.Blob.type`
- css.selectors.has - Baseline status banner incorrect HOT 1
- api.RTCRtpReceiver.transform - Chrome support encoded stream transform HOT 3
- api.HTMLAnchorElement.hrefTranslate&html.elements.a.hreftranslate - Missing browser compat data HOT 1
- api.KeyboardEvent.keyCode - <SUMMARIZE THE PROBLEM> HOT 1
- webextensions.api.userScripts - Chrome now supports userscripts HOT 2
- css.selectors.host - Discrepancies between the baseline widget and the full compatibility table HOT 1
- css.properties.font-family - < is not working> HOT 2
- api.File - The type of python file in Windows's browser is not recognized HOT 1
- html.elements.input.type_file - The type of python file in some Windows's browser is not recognized HOT 1
- webextensions.manifest.browser_specific_settings - `gecko_android` for `Firefox` should not be No HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from browser-compat-data.