RFC: Browser Support Minbar for v9#22889
Conversation
📊 Bundle size report🤖 This report was generated against 9bdcf7a94d2a89e77533e2ec850ba247fa6ba68d |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit fc05585:
|
Asset size changesSize Auditor did not detect a change in bundle size for any component! Baseline commit: 9bdcf7a94d2a89e77533e2ec850ba247fa6ba68d (build) |
|
Should we put in place some kind of audit process (i.e. every year/6 months) to review and update this browser support matrix ? |
Maybe sync it with the Firefox ESR release calendar or Safari releases? |
Went with basing it on Safari major releases since that browser is the new IE |
I'd suggest to setup a support window matrix/roadmap. Good example of what Im referring to can be seen here https://github.com/DefinitelyTyped/DefinitelyTyped#support-window |
|
|
||
| ## Summary | ||
|
|
||
| Fluent v9 is currently lacking a defined browser support matrix so this RFC proposes a set of major browser versions compatible with the library to act as the source of truth. As mentioned below, Fluent developers are expected to conform to these browsers and ensure no incompatible syntax, browser APIs or CSS features are introduced to the library. Consumers who require older browser support that aren't covered in this matrix are responsible for performing downlevel transpilations and/or using polyfills themselves. |
There was a problem hiding this comment.
responsible for performing downlevel transpilations and/or using polyfills themselves.
is this saying we will not use polyfills ? I'd suggest to rephrase or remove this completely to avoid any statements out of topic
There was a problem hiding this comment.
This was intended to say that Fluent wont be providing polyfills for features that we expect our browser matrix to already support (i.e. ResizeObserver) - i'll rephrase it
There was a problem hiding this comment.
I see, what I was trying to point out is that we cannot guarantee this as it cannot be baked by tooling to 100%. So we might end up shipping "some" polyfills.
To give you better context, based on this RFC our build process will look like following:
- browserlist config with browser matrix
- babel consuming browserlist and transpiling according to that
Now one can use ECMA features beyond 2019 and it will just work because babel will transpile that + provide according polyfill from corejs
What about TypeScript?
well we will still use target and lib specification - which will be used only for type declarations. Now for production code this might become problematic as target/lib cannot be matched to browser matrix in any way, so we'll end up by "approximate" target boundaries specification on type safety level.
There was a problem hiding this comment.
We're seeing some of these same things pop up in MADS (admin-controls) as well in terms of target and lib. I like the line drawn. We also use nullish coalescing so I think ES2020 is our line. Do you plan to look at that as well? It's very helpful to avoid pesky falsey bugs when looking for values.
There was a problem hiding this comment.
@brandonthomas We definitely want to support ES2020 features like nulling coalescing which is why I ensured this browser matrix supports all ES2020 features so no downlevel transpilation need to occur when we do move our target to ES2020. So in essence, this does draw the line at ES2020 for now
|
|
||
| ### Browser Support Going Forward | ||
|
|
||
| With an eye towards being a modern library, Fluent will follow a yearly audit process to evaluate and update the current browser support matrix to keep pace with the ever evolving ecosystem of the web. This will allow the team to utilize modern tools and improve overall engineering efficiency while also providing consumers with performance and bundlesize improvements. Due to the nature of how Safari browser updates are tied to MacOS versions, Safari will be the browser that ultimately holds the library back from fully adopting modern browser versions across the board. Because of this, the proposed timeframe for when these audits occur should be whenever a Safari major release occurs. These tend to happen annually during the month of September so Fluent can target an annual audit around that time. |
There was a problem hiding this comment.
the proposed timeframe for when these audits occur should be whenever a Safari major release occurs.
not sure if this is the right metric. platform features are being added on feature releases as well, I'd suggest to rethink this process.
There was a problem hiding this comment.
I think this auditing process will be heavily influenced by partner browser support needs so yearly audits seemed like a reasonable timeframe to evaluate, decide and give notice - totally open to suggestions here though!
There was a problem hiding this comment.
I'd suggest to remove the "blaming" on safari and keep the wording as you mentioned - yearly audits etc. wdyt ?
There was a problem hiding this comment.
Sounds good - i’ll rephrase this too
|
Updated the proposed browser matrix to |
Hotell
left a comment
There was a problem hiding this comment.
awesome work @TristanWatanabe 🙌
|
@TristanWatanabe one other thing I forgot to mention that I think is important to consider here is CSS's logical properties. It makes positioning for things like RTL, BiDi, etc much easier to deal with and we no longer need to do things like flip positions/margins etc. I'm starting to use these in the MADS library now that support for them is quite high. |
This RFC proposes a browser minbar support matrix for v9 to conform to. To get breakdown that led to this matrix, please read this document.
Preview👀
Current global browser coverage of proposed browser matrix: 88%
Related Issue(s)
Fixes #22273