Comments (8)
I'm not at ease to mix everything in the same repo. Meta data and compat data are two different beast and I wonder if it will ease or complicate contribution of those data (My intuition goes to the latter).
At that point the question is: do we want smaller repos with each handling a single set of data or a giant repo with everything.
I'm more in favor of a set of smaller repos as it provides some serious benefits:
- Maintenance is easier on smaller chuck of data
- Embedding data is easier as you can pick just what you need
But there is also benefits to centralized repo for data
- Automation is easier
- Coherence is easier to enforce.
- Remote access is centralized
Possibly, we could have one repo per domaine (JS, API, CSS, etc.) and an extra repo using git subtrees (see the git-subrepo tool) to aggregate everything for those who prefer to have a single point of entry.
from browser-compat-data.
This is a good idea, but I'm not sure I agree with your proposed structure - it seems odd to have some categorization by the kind of data (e.g. compat) and some by the domain (e.g. css). But maybe we can just get the benefit of moving everything here now, and reorganize it later if it starts to be a problem.
from browser-compat-data.
Oh, you are absolutely right. We could totally agree on a folder structure just by domain.
from browser-compat-data.
Maintenance is easier on smaller chuck of data
Interesting, I actually find it more difficult if things are cluttered around. Currently the JSONs are somewhere in some macros. No one has a map to our open data. I don't know for sure if one "MDN open data" repository is the answer (though I like the idea, hence this proposal). In the end, I would like to standardize how we store data, either in a single repo, or in several but with a plan. Having it in one repo sounds easiest for now to me in terms of discoverability, tooling/automation, standardization efforts.
Embedding data is easier as you can pick just what you need
I don't know much about this yet. I liked your npm proposal and I would assume that we could still provide our data through different npm modules sourcing from one repo.
I noticed the raw URLs GitHub are nice already, too. I would be something like https://raw.githubusercontent.com/mdn/data/master/css/properties.json
from browser-compat-data.
I tend to agree with Jérémie. Compat data is different from spec. and meta data. I believe it encourages contribution for it if it's held in a separate repo, because all compat data will be centralized.
Also, we could write automated tests checking the compatibility and update the data.
FWIW, the people working on CSS Houdini are also discussing whether to split their repo. One argument for splitting it is that one repo "makes it really hard to inspect outstanding issues".
Sebastian
from browser-compat-data.
Alright, let's go ahead with a new repository for "spec" data. Not sure "spec-data" or "data" are ideal names, any proposal?
from browser-compat-data.
I think just "data" is fine. The data consists of more than just spec. data. E.g. it contains links to guides or grouping information.
Sebastian
from browser-compat-data.
from browser-compat-data.
Related Issues (20)
- api.HTMLInputElement.showPicker - Safari data is incorrect HOT 2
- T
- [Spam]
- Geolocation: watchPosition() - not working properly on oppo and realme device HOT 1
- css.at-rules.counter-style - Safari 17 does not support @counter-style example given HOT 1
- api.SpeechSynthesis - <Bot cannot pronounce minus sign when structured like this as a math query: 5-3. The bot says "5 to 3" or "5 3"> HOT 1
- [Spam] HOT 1
- css.types.calc-constant - Rename to calc-keyword
- CSS property value: `table-caption` value missing from `display`
- [Spam] HOT 1
- Chrome doesn't support FontFace.featureSettings
- api.crossOriginIsolated - <SUMMARIZE THE PROBLEM> HOT 1
- css.properties.glyph-orientation-horizontal - missing
- {svg.global_attributes,css.properties}.{buffered-rendering,color-rendering} - missing
- javascript.operators.import_meta.resolve - latest Node also returns a string
- scripting.RegisteredContentScript: says `world` property is not supported: Support was added in Firefox 128 HOT 2
- api.Navigator.share - Now supported on Chrome on macOS
- svg.elements.a.xlink_href - <SUMMARIZE THE PROBLEM>fariborz HOT 2
- api.History.pushState - <SUMMARIZE THE PROBLEM> HOT 1
- html.elements.input.type_time - widget is not shown on mac on firefox 128 HOT 1
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.