Comments (11)
This is tough. On one hand, I like to have machine-readable data for things like this. On the other hand, I'm not sure what the compatibility table should do with this information, or a browser plugin, or a caniuse-type display. Available in nightly is interesting for someone who wants to play with a feature, but not for shipping a website. I'm not sure that the machine-readable data is much more useful than a plain note "Available in Nightly as of Aug 30".
from browser-compat-data.
I do feel that having the channel information present is useful. Especially for experimental features that linger on the nightly channel for several releases. You want people to know about them, but also be clear that it's still so deeply experimental it hasn't been riding the trains, so to speak.
I don't see the harm in adding a channel
field which can have values taken from among:
nightly
alpha
beta
release
(optional; ifchannel
field is missing, this is the default)
These are generic terms for the pretty standard channels that exist in most products. It would be up to the front-end to map these to the channel-specific names (like nightly
→ "Canary" for Chrome; and I assume that even though technically it's based on beta now, we'd use alpha
→ "Developer Edition" for Firefox.
Related, this would also let us note in machine-readable terms the progress of a feature along the train; just add another version record for each time it moves to another channel.
from browser-compat-data.
I think the compat data should focus on the following things.
- When a feature/property/value was really added to the stable version of a browser because most users are on stable channel.
- Prefixed version
- Standard version
- Data readability by a program and building the data around it. Which @jwhitlock has already mentioned. Example - The VSCode CSS Language Service needs to have this info in order to give proper autocompletion info in the editor.
Since developers might still need to know which features they can try out in nightlies, whatever UI is build to consume this compat data, that can have a "future" section which can list things which browsers are experimenting with. Right now, every browser has it's own channel of broadcasting what's new or what's coming up. But it can all live here and people get one source. Folks from browser vendor sides can come in and update this data whenever they feel like?
from browser-compat-data.
Couldn't you just put "Nightly" in the version field?
from browser-compat-data.
We already have compile_flag
as type
, which also goes in the direction of not being available normal release versions.
So, while a browser release channel isn't really a "flag", I think it's totally fine to have that info as machine readable data. If it's added to the data, I think the version, in which it got added should also be exposed.
This allows consumers of the data to display some information in the sense of "Be aware, this feature is only available in Firefox Nightly starting from version 60, it is not available in a stable release yet."
Sebastian
from browser-compat-data.
More discussions on this
https://discourse.mozilla.org/t/bcd-safari-tech-preview/33790
https://discourse.mozilla.org/t/bcd-question-flag-and-enabled-by-default-in-nightly-only/33449
#3103
Seems like "version_added": "nightly"
is the latest proposal on this.
There was also a proposal to add a restriction field.
The next steps here are:
- investigate the different proposals
- audit the data in the repo to see how often we have "Nightly" cases
- find out which proposal would suit us best for the found cases
- research how data consumers would display nightly data (first and foremost MDN, but also VS Code) and why these matter to them.
- research how nightly data will be maintained (nightly is a moving target).
from browser-compat-data.
Some thoughts on the next steps listed above (which I think is a good list, btw -- nicely put!):
- While I'm not sure how often we see "nightly" cases specifically, there's certainly the feeling that it's often enough to be worth finding a solution (for me, anyway). Both Chrome and Firefox have features that are added to the experimental or nightly builds (canary or nightly for example) but don't ride their way down to release immediately. It's still worth sharing the availability of many or most of these features, to encourage experimentation and testing, while allowing the consumer of the data to determine how or if to present that information.
- We can't really use
version_added
for this purpose."version_added": "nightly"
loses the information about what nightly version first added the feature. This is why I propose a separate field for this information. - It's worth considering if we want to allow the possibility of including special builds, such as if you have to use a special experimental branch of a browser in order to use a feature. Obviously that's extreme edge case country though.
- I could see MDN, for example, presenting the information by displaying the version the same way we do now, but with perhaps a different background color and with text like "(Nightly only)" or a footnote "Available only in Firefox Nightly builds."
- Others, like perhaps certain compatibility testers, might choose not to even use entries marked as being nightly-only.
- It should be simple enough to create a tool to help monitor these. During each release cycle, you could run a tool that would list out all the channel-limited stuff and let you choose to remove or change the restrictions as appropriate.
The more I think about it, the more I like the idea of a channel
field as I suggested in a previous comment, but with perhaps the addition of a "special"
value, indicating a special build rather than alpha, beta, etc.
from browser-compat-data.
Instead of channel
, maybe call it release-type
. And probably worth allowing release-candidate
as a value. I don't know how many of the browser outfits have RC builds anymore but it's worth allowing for the possibility.
from browser-compat-data.
I'm not trying to revive this issue, but I wanted to make a note while it was on my mind. In #3752, we dropped compile flags. I think however we decide to handle nightly or beta data—that is, variant builds of a browser—needs to square with the idea of omitting compile flag data (maybe this is unsquarable—I have not given it enough thought yet).
from browser-compat-data.
In #5072 (comment) @sideshowbarker expresses a use case for non-release data:
Part of the context here is that in the W3C/WHATWG world, we are now using the BCD data as part of the work we do in evaluating browser conformance to specs. In particular, we’ve been adding mechanisms to our spec-publishing tools that annotate the specs with links to MDN and with data from BCD. And for our purposes, what we care about is if there’s any version of a particular browser which has implemented support for a particular feature — even if it’s only in the current trunk build and not yet in a stable version widely used by developers.
from browser-compat-data.
This was fixed by #10334
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.