MDN Browser Compatibility Report If every single rendering, regardless ofplatform, would follow the standard as closely as possible, that would be a beautiful world. - A Web Developer The challenge of making web sites and applications work consistently across browsers is well known to web developers and designers. In the 2019 MON Developer Needs Assessment, we learned that indeed it appears to be the overall top pain point when building for the web, with four of the top five frustrations/needs being related: 1. Having to support specific browsers (e.g., IE11). 2. (Outdated or inaccurate documentation for frameworks and libraries.) 3. Avoiding or removing a feature that doesn't work across browsers. 4. Testing across browsers. 5. Making a design look/work the same across browsers. The MON Browser Compatibility Report is a deeper dive into these issues, attempting to identify specific issues causing a lot of frustration, and what could be done to improve the situation. The research consisted of a survey focused on browser compatibility\ followed by interviews with 13 volunteers among the survey participants. This research was conducted by MON, reviewed by the MON Product Advisory Board and led by Philip Jagenstedt (Google), Robert Nyman (Google) and Kadir Topal (Mozilla). See acknowledgments for full details.
1 In the web standards community, the term interoperability is commonly used to mean an API is implemented and works the same way in multiple browser engines. Compatibility often refers to web compatibility, meaning that an implementation works with web pages in the wild. In this report, the terms are used interchangeably and refer to browser compatibility, with the same meaning as interoperability.t
Table ofContents
2
Table of Contents
Summary
5
Survey
6 6
Categorizing Responses Filtering Responses Results Satisfaction with the Web vs. browser compatibility Overall top pain points Feature areas that cause issues
7 7 8 10 11 12 13 14
Layout/styling feature that cause issues Browsers/platforms that cause issues Questions
15
Interviews
17 17 17 17 19 20 20 20 20 20 21 22 22 22 24 24 26 26 27 30
Findings
Features
CSS Flexbox
Web developer quotes Flexbox in Internet Explorer See also
Chrome bugs Firefox bugs Safari bugs
CSS Grid
Web developer quotes Grid in Internet Explorer See also
Responsive layout Viewport
Web developer quotes See also
Scrolling
Web developer quotes See also
JavaScript
31
Web developer quotes
32
See also
34
Performance
34
Web developer quotes
35
Forms
36
Web developer quotes
36
Browsers
38
Chrome
38
Web developer quotes
38
Edge
39
Web developer quotes
39
Internet Explorer
39
Web developer quotes
39
Firefox
40
Web developer quotes
40
Safari
40
Web developer quotes
41
Samsung Internet
42
Web developer quotes
42
Other Themes
43
Access to devices
43
Web developer quotes
43
Breaking changes
44
Web developer quotes
44
Ongoing Work
46
CSS Flexbox & Grid
46
Microsoft Edge
46
Browser Compatibility Data
46
Acknowledgments
48
Appendix A: Survey Design
49
Appendix B: Top Pain Point Categories
53
Appendix C: Survey Results
63
Appendix D: Survey Results Excluding IE
74
Appendix E: Interview Study
83
Study Goals
83
Discussion Guide
83
Appendix F: Interview Transcripts
86
Participant 1
86
Participant 2
87
91
Participant 3
Participant 4
95
Participant 5
97
Participant 6
98
Participant 7
100
Participant 8
103
Participant 9
104
Participant 10
108
Participant 11
109
111
Participant 12
Participant 13
119
Summary Both in the 2019 MDN Developer Needs Assessment and historically we’ve seen that by far the biggest challenge for web developers is with regards to browser compatibility. We wanted to learn exactly what areas and features are causing this pain, and importantly what we can do to alleviate these, or even make them go away. To be able to do that we have aimed to provide as much detail and extensive reporting as possible to create a foundation for browser vendors to gain an understanding of the issues and offer them a starting point with as much actionable feedback as possible. We found that a lot of developers are struggling in particular with layout and styling issues: CSS Flexbox, CSS Grid and problems achieving consistent layout in recent browsers with dynamic viewport sizes and scrolling. JavaScript was often mentioned, but turned out not to be problems with the core language and instead numerous challenges with achieving browser compatibility with various Web APIs. We heard about challenges with all major web browsers, and the largest number of compatibility challenges were reported for Internet Explorer and Safari. By preemptively sharing initial findings with browser vendors and working closely with engineering teams, we’ve already seen concrete results and improvements regarding:
● CSS Flexbox and Grid improvements in Chromium and WebKit ● Commitment to improved browser compatibility data on MDN
WIth Chromium-based Edge rolling out with Windows updates we believe reported issues with Microsoft Edge Legacy and Internet Explorer will decrease. We further plan to run the MDN Developer Needs Assessment survey again to both surface new issues and see if existing ones have been addressed, and establish an even closer collaboration between browser vendors to ensure compatibility for a better platform for web developers.
Survey The goal of the survey was to identify which individual features and browsers contribute the most to web developer pain points around browser compatibility. The target audience for the results is browser vendors, and we wanted the findings to be as actionable as possible and make sense as input for prioritization. In short, the survey asked about: ● Overall satisfaction with the Web (on a scale) ● Satisfaction with browser compatibility (on a scale) ● Overall top pain point with browser compatibility (free-form text) ● Feature areas that cause issues (fixed options) ● Browsers/platforms that cause issues (fixed options)
See appendix A for the full set of questions.
The survey was run on MDN in February/March 2020, and was also promoted on Twitter , web.dev and developers.google.com in that period. The 3,236 complete responses are available in redacted form in a public spreadsheet. (The free-form responses were removed as they could and did occasionally include personally identifiable information.) Categorizing Responses The survey’s main free-form question “Overall, what is your top pain point with browser compatibility?” was categorized by hand and used to filter the results. Only 64% of the responses answered this question, and those 2000+ answers were categorized manually into 46 categories, up to 5 categories per answer. We used the first or most prominent issue as the first category. For example “I don't really like that chrome and firefox handles images inside flexbox differently” was categorized as Flexbox, Chrome and Firefox, with Flexbox taken to be the top issue.
See appendix B for all categories and examples.
Responses that looked like bot activity or not possible to interpret were classified as invalid. These were 20% of the total number of responses. This process resulted in 1,429 valid responses (44%) and 1,807 excluded responses (56%) where the latter includes both missing responses (36%) and invalid responses (20%). Filtering Responses In our analysis, we decided to include only the valid responses, effectively using our free-form question as a screening question. Generally, in the excluded subset, the distribution between options is more even, which is consistent with more random noise. However, it was not just noise and some proportion of those responses must be from real, experienced web developers. Unfortunately, it’s not possible to identify them without making some assumption about what a good response looks like, which would likely only bias the results to what we already think is reasonable. This represents a flaw in the survey design. The free-form question should have been required so that more of the responses could be identified as valid. This likely biased the results in some way. Because of this screening and that only 29% of the used responses came from MDN, the results can’t be directly compared to the 2019 MDN Developer Needs Assessment . Results The high-level survey results are summarized here. See appendix C for full results, and the Findings section for a synthesis of survey and interview results with much more granularity.
Satisfaction with the Web vs. browser compatibility Overall for the Web, almost 75% are satisfied or very satisfied, which is very close to the 2019 MDN Developer Needs Assessment results. The comparable number for browser compatibility is 44%. This is a marked difference:
Overall top pain points The ranking of overall top pain points is based on the aforementioned categorization of free-form text responses. The percentages indicate what percentage of valid responses mentioned the issue, and do not add up to 100%.
Top pain points (up to 5)
25.0%
1. 24% Internet Explorer 2. 20% Layout and styling 3. 17% Safari 4. 10% General (expressing the broad problem of browser compatibility) 5. 7% Old browsers 6. 6% Chrome 7. 5% JavaScript 8. 4% None (expressing that browser compatibility isn't a pain point) 9. 3% Slow adoption
10. 3% Firefox 11. 3% PWAs 12. 3% Edge
Feature areas that cause issues
What feature areas cause the most issues? (up to 3)
50.0%
1. 48% Layout and styling (CSS, responsive layout, etc.) This is further broken down below. 2. 26% JavaScript (core language)
Understanding this became a focus of our interviews, see findings. In our estimation, JavaScript itself does not appear to be a major problem. 3. 19% Performance (APls, scrolling, smooth animations) See findings for more details. Scrolling was also a focus of our interviews, see also those findings. 4. 16% Forms (autocomplete, styling, etc.) See findings for more details.
5. 13% Web Components (shadow DOM, custom elements) 6. 13% Installable web apps (installation, notifications, etc.) 7. 13% DOM APls (modifying elements, editing, selection, etc.)
This ranking is fairly consistent with the top paint points ranking, but Web Components were mentioned less frequently in the free-form responses than PWAs (installable web apps) and APls.
Layout/styling feature that cause issues
We anticipated that layout and styling would be among the top pain points, and asked a second question for those who chose it. (685 responses)
What layouUstyling features cause the most issues? (up to 3)
e'
0�
-� °-'
,/'
-,,{"
�� o.,
� o
,1>-4,
�o
f/j
o-s'
�
�-
� o '
,,__,;p
.;:;,ef.
oc,
�c,
c : P
o +
t ?
,§'
,,__,'If
v
�o
O
cl
0 -<:!
,1>�
G
0 0
(T<:$
�
,,__ e -'<'
�v
1. 39% Flexbox See findings for more details. 2. 35% Grid layout See findings for more details. 3. 31% Responsive layout See findings for more details. 4. 25% Form elements See findings for more details. 5. 23% Scrolling See findings for more details. This ranking is largely consistent with the top paint points ranking, although forms were mentioned more than CSS Grid, and responsive layout wasn't one of the categories for that question. Browsers/platforms that cause issues What browsers/platforms cause the most issues? (up to 3) 80.0% Internet Explorer Safari on Safari on Edge on Chrome Firefox on Chrome Edge on Firefox on Other mobile desktop desktop on desktop desktop on mobile mobile mobile • 70% Internet Explorer • 50%/ 46% Safari on mobile/ desktop respectively • 21%/ 8% Edge on desktop/ mobile respectively • 12%/ 11% Chrome on desktop/ mobile respectively • 12%/ 7% Firefox on desktop/ mobile respectively This ranking is consistent with results of the top paint points ranking, with the exception of Edge which was mentioned less than Firefox there. See findings for more details on each browser. Questions After reviewing the survey responses we had some questions about things that we had not expected or didn’t understand in the results. In particular, we were surprised to see JavaScript (core language) rank #2 among feature areas. For layout/styling features we also wanted to understand more about the pain points participants had in mind when choosing responsive layout. Finally, we wanted to get a few more concrete examples of pain points around Internet Explorer, Safari, CSS Flexbox and Grid, as these were the top categories in overall top pain points . However, these were deprioritized after a few interviews, see below. Interviews To add more detail to our survey results, we recruited participants to an interview study from those who agreed to be contacted again. Roughly 100 survey respondents were contacted, based mostly on what they had written in the free-form survey questions. The accept rate was higher than expected, so we ended up conducting 13 interviews. Most of the interview participants were very experienced, with 2 participants having 20 years of experience and 8 more falling in the 5-15 range. We don’t know if this is representative of all survey participants, but suspect the interview participants were more experienced on average. Most of the participants were building for both desktop and mobile. We had a mix of developers working in-house vs. agencies, and also a mix of public (general audience) vs. internal web properties. We did not ask exactly the same questions of all participants, and after the second day of interviews we decided to deprioritize the goals/questions around Internet Explorer, Safari, CSS Flexbox and Grid. This was because we found there was more to learn about the other topics, where we had more unanswered questions. These deprioritized topics still came up naturally in some interviews, however. The main findings from the interviews were: ● Responsive layout : When asked about responsive design, most participants brought up issues around viewport size/units, scrolling, as well as their use of Flexbox, Grid, etc. These led to the detailed findings below. Contrary to our expectations, we did not hear about challenges with media queries, one of the building blocks of responsive design . ● Viewport : Covers dealing as a developer with the dynamic viewport size on mobile and adapting the content to the visual viewport. A lot of this is around how the vh unit interacts with the URL bar on mobile browsers, and originally being different across mobile browsers. Getting desired results is still hard for developers. ● Scrolling : A number of challenges around scrolling were detected, such as customization of scrolling, APIs to control it, events that fire during scrolling, and scroll performance. We’ve confirmed that there are many differences between mobile browsers, causing a lot of developer pain. Identified use cases include when JavaScript scrolling has been implemented to address native scrolling shortcomings, such as overscroll and scroll snapping. ● JavaScript : Most participants had no issues with the JavaScript language itself, and many of them attributed this to use of transpilers like Babel. Even those few participants that wrote mostly vanilla JavaScript without any tooling didn’t feel that browser compatibility was a big problem. We suspect that when survey participants selected “JavaScript (core language)”, this was driven mostly by issues related to JavaScript, but usually not the core language. These and other findings are incorporated into the following section. See appendix E for the full study goals and discussion guide, and appendix F for partial interview transcripts. Findings This section brings together findings from the survey and interviews with some additional context to try to paint as detailed and nuanced a picture as possible of the top pain points relating to browser compatibility. It is organized into features , browsers and other themes . Features Through the survey and interviews we heard about many issues, ranging from very specific bugs to a general sense that a feature isn’t ready to use. In this section we cover roughly the top four feature areas that cause issues . The first two of these were the focus of our interviews. CSS Flexbox Flexbox was the most selected option (39%) for layout/styling features causing issues . It was also the specific feature most often mentioned (39 times, 2.7%) in free-form survey responses. That compatibility issues with Flexbox are top-of-mind is consistent with the high awareness and usage of the feature. In the State of CSS 2019 survey almost everyone knew about Flexbox and 95% used it. Usage in the wild is around 70% of page views, per chromestatus.com . We heard about issues both with old browsers like Internet Explorer, but also difficulties achieving a consistent layout in recent browsers. Notable issues are support for gap (gutters) and bugs around the sizing of “replaced content”, like images and fieldset. Several of these are in the process of being fixed at the time of writing. Web developer quotes A selection of quotes from the survey responses: Flexbox bugs in all major browsers except for the old EdgeHTML version of Edge I still find differences in flexbox and grid. I also had one with object fit recently. When the image was 100% tall Chrome would shrink the image height. Other browsers tried to show the full image height as expected. 1 1 don't really like that chrome and firefox handles images inside flexbox differently Chrome's calculation of flex with overflow really bit me. While Firefox and Safari were doing the calculation correctly. I had to read a bunch of bug tickets to find out that adding min-height to my div was needed. I Chrome doesn't support the gap property with Flexbox. https://bugs.chromium.org/p/chromium/issues/detail?id=762679 I Internet Explorer (still supporting 11) especially regarding Flexbox. I Long standing bugs in only one browser, such as the flexbox bug with fieldset in chrome. Just fix it already. Flexbox also came up in some interviews. One participant reported this as their main pain point, especially with vertical layouts: Most of the problems I've had have been with Flexbox. Especially when you apply Flexbox in a layout you have to be aware of the different syntax for different browsers, and that's really painful. If you forget something you can have issues in some browsers. I've had a lot of problems with vertical Flexbox and Safari, for example. Even having a specific syntax it doesn't behave the same way, I think, in vertical Flexbox. Where you apply Flexbox to columns and not rows and want to center whatever content vertically, I've had a lot of issues with that. Specifically things like flex auto, flex 100%, I've been having to apply that specifically for Explorer and Edge. [...] I wasn't able to fix it, so I had to get rid of Flexbox, finally, and apply table displays for what I wanted to achieve. [...] The layout was: everything was vertically centered in the layout, the whole content, and it had to be always centered in the screen, in the browser, and I couldn't use Flexbox for that. I also think we normally tend to use Flexbox for things that it's not intended for, and I think that's because we didn't have CSS Grid until now, until very recently. Another interview participant reported problems achieving the same height of Flexbox layouts cross-browser: We had a carousel, and all the slides should have the same height, the height should be dependent on the highest slide. So Flexbox, Flexbox, another Flexbox, all nested inside each other. We didn't start from scratch, obviously, we just used a slider component that was already there. The slider component is not the issue here, in this case. Flexbox had differences between Firefox and WebKit- or Blink-based browsers. We couldn't achieve these equal height slides on anything but Gecko. In Gecko it worked fine, in all other browsers it did not, so we also needed to have a JavaScript solution here. Doing layout calculations in JavaScript is never clean, it always feels a bit dirty, but in this case the slider's based on JavaScript anyway, so we made this tradeoff. [...] The way Glide.js works is you get a container where all the slides are stored and it uses Flexbox for display values, as far as I know. You should usually be able to give each slide the same height, but it didn't work in anything but Firefox. Don't know why. Among the things that bug me the most, it's mostly little differences in Flexbox implementation. Of course we have to support IE11, but even in other browsers you see a lot of differences. This is something you face almost on a daily basis. You know your way around it, especially with IE11, after a while. But I think there are still some bugs that remain, even in modern browsers. Finally, one interview participant expressed that Internet Explorer had been especially problematic with regards to Flexbox: All the Flexbox gotchas that IE has are pretty frustrating, and I'm intimately aware of many of them. This is actually the first time I've not had to support IE in my career, so it's pretty nice. [...] A lot of the flex issues were around height and flex-grow or flex-shrink. Just simple things like explicitly setting a height on the flex child would fix the issues. Flexbox in Internet Explorer Internet Explorer 11 supports Flexbox without prefixes but with a number of well-known issues, many of which were fixed in Edge. Several comments suggested that Flexbox is a bigger pain point when supporting Internet Explorer. In appendix D we looked at the survey responses that did not indicate any issue with Internet Explorer, and Flexbox was no longer the most selected option for layout/styling features causing issues . However, it does still appear to be a significant pain point. See also ● Flexbox on MDN ● Flexbox and gap on caniuse.com ● Flexbox test results on wpt.fyi ● Flexbugs list of flexbox issues and cross-browser workarounds Chrome bugs These are the specific Chromium bugs we were able to identify: ● [css-flex] Add gutters support in Flexbox ● [css-flex][css-grid] Flexbox/grid layout model does not work on fieldset elements ● [img flex-basis] Flexbox doesn't scale down images correctly Firefox bugs This is the specific Firefox bug we were able to identify: ● [css-flexbox] A non-default "flex-basis" incorrectly prevents min-size:auto from being clamped by specified size ● [css-flexbox] Implement row-gap and column-gap for flex layout ● [css-flexbox] min-height: auto not applied to nested flexboxes ● [css-flexbox] min-height:auto not updated after an image loads when the image has a specified height and width CSS Grid Grid was the 2nd most selected option (35%) for layout/styling features causing issues . It was also frequently mentioned (23 times, 1.6%) in free-form survey responses. Safari bugs These are a few specific WebKit bugs we were able to identify: The State of CSS 2019 survey suggests very high awareness but less usage of Grid than Flexbox. Usage in the wild is around 6% of page views but growing steadily, per chromestatus.com . The source of frustration with Grid appears to be different to Flexbox. When supporting old browsers, mainly Internet Explorer, Grid support is limited. In more recent browsers, one issue that came up multiple times is support for Subgrid , which at the time of writing is only supported in Firefox. We did not hear about other issues, and one developer saw Grid as a success story. Web developer quotes One interview participant expressed that supporting Internet Explorer limits the use of the latest grid features: We have to support IE11 and Grid support is limited. This often requires heavy workarounds, so you always have to do a lot of things with the help of additional JavaScript that you wouldn’t need to do otherwise. Simple grids work in IE11 as well, it’s often much easier to do things even without having all the latest grid features available. For other projects I’m starting to transition to grid layout. I wouldn’t say I use it 100%, Flexbox also has its use cases. I think back then I avoided using Grid, I still try to get around it especially with older devices in mind. Another participants, who also did support IE11, instead expressed how CSS Grid has been a success story for them, in terms of being implemented in all browsers and behaving correctly: We’re starting to use it right now. I think it’s kind of becoming stable right now, all browsers have implemented CSS Grid. I don’t think you can use it for every kind of layout, either, it depends on the layout you want to implement, but it’s really useful. And it behaves correctly, I think that’s been one of the great things, because every vendor has implemented that, and that’s been like a success for us. Because you’re sure you can use it and you’re not going to have big issues with it. So that is great, yes. See also the Responsive layout section for a related finding, where Bootstrap’s grid system was credited with fixing (or avoiding) some issues. (Note that Bootstrap’s grid system is built on Flexbox, not Grid, so this doesn’t say much about CSS Grid.) Finally, a selection of quotes from the survey responses: Not being able to use ES6 or CSS Grid years after their introduction, having instead to still rely on outdated, hacky workarounds. Slowness in Chrome to implement new CSS layout like gap for Flexbox or subgrid. I want to use css grid, flexbox etc but I still need to support legacy safari Grid in Internet Explorer Internet Explorer 11 supported an -ms-prefixed version of CSS Grid. In appendix D we looked at the survey responses that did not indicate any issue with Internet Explorer. In layout/styling features causing issues , Grid then appears to be much less of a problem, falling from #2 to #6 in the ranking. This together with interview comments suggest that when supporting Internet Explorer, Grid is a significant source of issues or cannot be used, but that in more recent browsers, Grid is much more interoperable and less of a pain point. See also ● Grid and Subgrid on MDN ● Grid and Subgrid on caniuse.com ● Grid and Subgrid test results on wpt.fyi ● Gridbugs list of bugs, incomplete implementations and interop issues ● [css-grid] Implement subgrid support Chromium bug ● [css-grid] Add support for subgrid (Grid Level 2) WebKit bug Responsive layout Responsive layout (or responsive design ) can mean many things, and in our extra question about layout and styling features we did not specify exactly what this meant. This option was ranked #3 overall and tied for #1 when excluding IE . However, “responsive” was only directly mentioned a handful of times in free-form survey responses. Rather, the clearest theme that might be related was dealing with the dynamic viewport size on mobile: mainly how viewport units work and the effect of URL bar on the viewport size and scroll/resize events. Understanding the pain points that web developers associate with responsive layout became a main study goal for the interviews. The question to interview participants was typically asking for a recent time when they’d had trouble making a design work on both desktop and mobile, only sometimes directly mentioning “responsive layout” or “responsive design.” This often led to a discussion of issues pertaining to scrolling, and where not we would sometimes ask about that separately. Findings from these part of the interview study are in the following sections: ● Viewport issues, namely dealing with the dynamic viewport size on mobile and adapting the content to the visual viewport. ● Scrolling issues, like customizing vertical and horizontal scrolling, APIs for scrolling, events that fire during scrolling, and scroll performance. It’s also notable that two interview participants mentioned using the Bootstrap grid system when asked about desktop/mobile/responsive issues. One of them explained why it’s helpful: We use a grid system from a project called Vuetify , which is part of the Vue ecosystem. It’s based on the Bootstrap grid system . It’s well tested, it’s cross-browser, so fortunately we don’t have to worry too much about layout issues. […] Just having a grid system that’s well supported and tested by other parties is a super helpful tool. The other participant reported running into a problem on that same day, which was fixed by a newer Bootstrap release: My colleagues asked me for support for a newly made application in another team. It was due to a bug in Bootstrap 3. There was a box which went on a new line in only iOS, just today. It was a bug on the grid of Bootstrap 3, which was fixed in Bootstrap 4. While we did not get details about these cases, clearly frameworks smooth over some differences between browsers, and developers can benefit from that. Viewport The viewport is the part of a page visible to the user, and is something every web page designed to work on mobile devices has to consider. The issues raised were mostly about how the vh unit interacts with the URL bar on mobile browsers, explained in the “ The trick to viewport units on mobile ” article on CSS-Tricks. Another factor here might be about not having a specification for the viewport . These issues are tightly linked to scrolling . Part of the frustration can be attributed to the behavior of vh units originally being different across different mobile browsers. It could also be about a discrepancy of understanding about the vh unit between developers and the CSS WG, see [css-values-4] Add vhc value . While Chrome 56 changed its behavior to match Safari on iOS , some developers may not have noticed this, and it remains difficult to achieve the desired effect. There is an open CSS Working Group issue to address this. In the meantime some developers have turned to -webkit-fill-available or JavaScript workarounds. The effect of scrollbars on the vw unit also came up, and was the subject of another CSS Working Group issue , resolved as “Drop the requirement to subtract scrollbar size from vh/vw units for overflow scroll.” While not a browser compatibility issue, a platform compatibility issue of sorts remains, as some platforms have classic scrollbars and some have overlay scrollbars. Some are also implementing their own scrollbars and hiding the native one. In response to these findings, Chrome’s input team did some investigation of viewport units , confirming that Chrome and Safari now have the same behavior. Web developer quotes In our interviews, one participant told us about viewport sizing issues and the workaround they use: Then there’s the odd viewport sizing in iOS that was a little bit of an annoyance. I kind of read the whole, long bug tracker thread in the WebKit forum about why they decided to size the viewport units the way they did. And it makes sense, I understand the logic, but we did have to figure out a few workarounds for a couple of our screens. On iOS, as I'm sure you know, as you're scrolling the address bar will collapse. The viewport size is calculated based on the collapsed size of the header. If you want, say a full page screen, that fills the screen but no more, then you can't use viewport units. There is some webkit-specific stuff baked into Safari that we ended up using that will avoid that problem. But that was one of our initial stumbling blocks when we were trying to have a full-screen, non-scrollable view in mobile Safari. We use -webkit-fill-available to handle that. That was the primary fix we found for the 100vh size issue in mobile Safari. Two other interview participants also reported having issues with viewport units, either accepting that things didn't look right or using JavaScript workarounds: It was either something about vw or vh for the viewport width and height. Or percentages for widths and heights. It was some irregularity with that, and although it was perfect on Chrome and Firefox, it just did not look correct on Safari. We still support it, because it still works with the dashboard that we've been building, but some of the things don't just quite look right. Also things like vh, the viewport height [...] I don't entirely remember all the details, I just remember that it was different across browsers. I think whether the scrollbar is considered part of vh height is a little bit undefined, and it's definitely different in Safari and Chrome. [...] The scrollbar thing in many cases might not be a big problem, if you do 100vw then it's going to be a problem because you're going to have differences on the browser edge, but if it's 50% of the browser width then you're probably not going to care so much if scrollbars are included or not. Then just individual workarounds. If you really needed to be, maybe do it with a bit of JavaScript, with resize event listener and check the browser properties window.clientWidth, whatever works, test which combination of these is going to work to fix a given problem. Finally, a few quotes from the survey responses: I ls the URL bar part of 100vh? Mobile browser compatibility regardless to when I'm trying to set the web page height to 100% (or flex stretch, or via JavaScript window.innerHeight). This is because of browsers top/bottom native UI bars inconsistency (which appear/disappear on scrolling). The treatment of viewport units, especially on mobile devices. For desktop: 100vw includes vertical scrollbar width, therefore nigh unusable esp. for windows because it causes hor. scrollbar (often not recognized by developers on macs) For mobile: treatment of 100vh and browser GUI is a PITA. Touch screen devices are problematic. There are bugs but also it would be handy to have more control of display of keyboard, etc. See also ● Virtual Keyboard API , a proposal for changing the interaction between the virtual keyboard and the viewport size on mobile. The “more control of display of keyboard” in the above quote is likely about this, but it didn’t come up in interviews like we had expected . Scrolling A few different types of scrolling-related issues came up in the survey and interviews: ● The effect of shrinking/hiding URL bar when scrolling on mobile devices on the viewport size. Developers sometimes hardcode the expected height of the URL, which is a risky approach. Some of this is covered in the viewport section . ● Difficulties controlling native scroll, sometimes falling back to using JavaScript instead. This includes overscroll behavior, scroll snapping, etc. ● Differences in behavior or support for scrolling-related APIs like scrollIntoView. In response to these findings, Chrome’s input team did some investigation of scroll behavior , confirming that there are indeed many differences between mobile browsers. Web developer quotes One interview participant went into great detail about the challenges getting touch interactions to work well on mobile for a "room planner" mobile web app. A condensed excerpt of the transcript of that interview follows: But what was really difficult was to get all the touch interaction right. It's really not a page [...] you can pan, you can zoom, you have all of these interactions and it's really not a page that you want to scroll on. We just struggled with stuff like the browser bar. If you want to scroll, maybe you have a scroll container somewhere inside, and then the browser bar appears and disappears. And you don't get resize events when the browser bar is in the process of disappearing, it just resizes after the browser bar disappears completely. Maybe in between it's not going to look so nice. Like what Google Maps does [...] you can pull it up from the bottom, then you have the details about a place. We had something similar to that for individual products on the wall. First we wanted that to have that be a native scroll interaction because we thought if it's just a native scroll it's going to be fast, it's going to be hardware accelerated, it's going to feel the nicest. But if you're working with native scroll it's very difficult to control it, because for example scroll event listeners are - for a good reason - passive now. I made the mistake of trying to use native scroll for something where I wanted to have too much control, again. If you scroll and there's a certain scroll velocity, and you lift your finger up and it keeps on scrolling, and it reaches a certain threshold and you want to have it snap there. [...] If you want to do it by JavaScript you can set the scroll position. On iOS I think that's going to stop the scroll velocity immediately. On Chrome it snaps to that point but it keeps on scrolling with the same velocity. [...] So it's pretty much impossible to control that. In the end I think we had to completely redo the scrolling [...] and just do all the scrolling by JavaScript. I wanted to build a "simple" horizontal slider on a completely different project. I first thought it's just horizontal scrolling, if I'm going to use native scroll that's going to work fine.[...] Again I ran into a problem, if you want to control that, you want to have your own snapping behavior, and control the snapping via JavaScript. I think there's now the CSS snap points API, which is kind of covering that. I haven't heard that much about it, either because I just didn't know about the API, or it's really, really new and it's not widely supported. [...] I think the API would kind of cover that use case, and you can just have snap points defined in CSS and don't need JavaScript at all because it's all handled natively. Also it's important to differentiate between a single touch and a scroll. [...] If the user starts moving the carousel and then decides to also move their finger up and down, you don't want the browser to suddenly start a scroll interaction. You can do it on iOS, because on iOS you can call preventDefault() on the touchmove event, if the touchmove event hasn't led to a scroll yet. [...] On Chrome you can't do that and you have to stop the touchstart event [...] but then you don't know in which direction the user is scrolling. [...] Finding these things out is very difficult and very time intensive. I've done a lot of demos and codepens experimenting with browsers. It's very frustrating because there's not really standards for it, or documentation and stuff. [...] It was just very difficult to get these things working, like really, really, really difficult. We did a lot of iteration, a lot of testing, over time. I kind of got really obsessed with making scrolling really nice on mobile and trying to make native-like applications on the web that don't feel like they're just a glitchy web page. Extra thanks to the anonymous participant who volunteered their time and expertise here, to help shed light on this complex set of problems. Another interview participant explained how they need to use a JavaScript library to just get consistent scroll behavior across all browsers: What gives me the most headaches is typically scrolling behavior of iOS. If I need to display a modal or something like a typical hamburger menu. It annoys me that I need a JavaScript library just to get this right, so that if I get a modal, that the background doesn't scroll on iOS. I think that's basically the worst issue that you stumble across in almost every project. [...] The goal is always that you lock scrolling completely. There's a good library for that, it's not even large, it's a small JavaScript dependency. But it annoys me that you need these workarounds for doing simple stuff like that. The library was later confirmed to be body-scroll-lock , where bodyScroll L ock.js indeed does a bunch of work only for iOS. It has 269k npm downloads per week, which has to be considered a lot for a browser compat workaround. Another developer had issues with scrolllntoView's "smooth" mode not being supported on Safari, also requiring the use of a JS workaround: For "scroll to element", there's a "smooth" property [...] I think it's Safari that doesn't support [it]. We just added a polyfill for it, it's like 2 KB so it's not a big deal. Fortunately the build systems we have are pretty good at putting in a polyfill for what's not widely supported. That same developer had also encountered issues on Firefox for iOS: I've encountered a scroll issue in Firefox on iOS where there's something about the way that Safari is embedded in the iOS app that messes up scroll position sometimes. Because I think that Safari embedded is calculating internal values based on what it thinks is the viewport, and the app is actually wrapped in a smaller viewport because of the UI controls. That's my guess. So the scroll is a little bit off and I have to scroll with two fingers sometimes to get it to like jump out of the containing window. The overscroll behavior of mobile browsers, sometimes called scroll bouncing" or elastic scroll, came up in multiple interviews: Apple adds a little custom scroll at the end of pages. There's a special effect when you scroll to the end. That behavior was kind of disturbing us in one of our layouts that we had built for desktop and mobile. The scroll worked fine in Chrome on iOS and in Chrome and Safari on macOS. But in Safari for iOS [...] that scroll was interfering with our scroll. Sometimes, if you slide somewhere it would scroll and if you slide with a different angle or you slide very fast then the scroll wouldn't work directly. That was an issue where there was no solution or help on the internet, so we had to get creative and redesign some of the screen to get around this problem. I don't really know what that problem actually is, but most of the internet help we found was about Apple’s custom scroll animation at the bottom interfering with the browser, or something like that. Differences in timing of events and callbacks also came up: I did notice that scroll events are fired differently in Safari vs. everyone else. Safari would… I took a few stabs at this and in the first stab, Safari would only fire the scroll event after the scroll had finished. So I ended up… the workaround I used for that was to just use touchmove and just call the same… Basically I had a render loop running, in a requestAnimationFrame loop, and I would update things in the touchmove event in addition to the standard scroll on Safari. That was one issue I came across. Finally, a few quotes from the survey: Controlling scroll behavior: when does a touch lead to a scroll? Is it cancelable? […] Does resize fire for browser elements appearing and disappearing? When does it fire?” content behind dialog scrolls in safari - no easy way to disable this "feature" the HtmlElement.scrollIntoView() method which is rather well supported, but if you need to scrollIntoView on the horizontal axis, only Firefox supports it (Chrome and Safari don't). CONTROL OVER HOW PARTS OF THE PAGE SHOULD BEHAVE WHEN SCROLLING See also ● CSS Scroll Snap on MDN ● CSS Scroll Snap on caniuse.com ● CSS Scroll Snap test results on wpt.fyi ● CSS overscroll-behavior on MDN ● CSS overscroll-behavior on caniuse.com ● CSS overscroll-behavior test results on wpt.fyi ● scrollIntoView on MDN JavaScript We asked in the survey about feature areas that cause issues , and “JavaScript (core language)” was the 2nd most chosen option, chosen by 26% of survey respondents. The “core language” parenthetical was added to direct survey takers to other options where appropriate, especially DOM APIs. Unfortunately, the boundaries between JavaScript and the rest of the web platform are not easy to understand. For example, encodeURIComponent is defined in the ECMAScript Language Specification while the URL interface is defined in the URL Standard. Understanding if web developers do face a compatibility problem with JavaScript itself became a main study goal for the interviews. We typically asked "can you talk about a recent time you had a browser compatibility problem with JavaScript" and listened to what the interview participants had to say. The pattern that emerged from our interviews, and which is consistent with the free-form survey responses that mentioned JavaScript, is that most web developers don’t face big issues with browser compatibility for JavaScript as a language. Use of transpilers like Babel appears widespread, and even those who wanted to avoid transpilers did not say it was very difficult to deal with browser compatibility. When asking about issues with JavaScript, the concrete things raised were mostly not part of ECMAScript, but the wider web platform. However, no specific issue came up twice. There is likely a long tail of issues affecting all parts of the platform, which can manifest in JavaScript code, and which together could explain why JavaScript showed up the way it did in the survey results. It is worth noting that in both survey responses and in some interviews, we heard from web developers who would perhaps rather not use transpilers, either due to the added complexity or the increased code size. Finally, a small caveat. The web developers who volunteered for our interviews were very experienced. It is plausible that more novice web developers would not work around JavaScript compatibility issues using transpilers or polyfills as readily. Web developer quotes In the survey responses, no specific parts of JavaScript (ECMAScript) were pointed out, but there was a theme of not knowing what's supported and needing transpilers or polyfills: I Sometimes just can figure out what version of ECMAscript is OK on a specific version of browser. I ES6 features support on old browsers. We need to write polyfills for old browsers I new ES6 features are still incompatible with firefox chrome etc. babel do this job but conversion takes much time to debug code. I The javascript part, I know if I use webpack and babel it could save my problem. But native support is always what i looking for. I Running code through transpilers often means that code is bloated and large file sizes I Supporting IE browsers without having polyfills installed for ES6 features. Most of our interview participants expressed that dealing with JavaScript isn't very problematic, attributing this mainly to the rise of transpilers like Babel in recent years: Obviously there are differences in support, but these are really not that problematic because you know what's supported and not, and it's very easy to deal with that. [...] In most projects I have a fairly common stack of Babel andWebpack, and also Babel polyfills. Babel became very popular for all the syntax stuff in the last couple of years, and I kind of see it as a given now, even though I also think that now, a couple years after it really became adopted, maybe starting from 2020 it actually should be an option to think about, if you actually need Babel in your build stack. [...] There's a project from the New York Times, polyfill.io, that does testing for browser features and lazy loads the polyfills. I always thought that was interesting to consider but [...] for now my approach is to keep the amount of polyfills we load in not too big, just see it as a necessary evil of probably 30% I overhead of the bundle is just damned polyfills you don't need in modern browsers. [...] It was easier on our build stack to do it like that. Fortunately it's pretty good these days. We support pretty much the last two major versions of any major browser, so JavaScript is in a state where it's pretty solid. We do use polyfills for things that are not supported and that's managed by our build system. We have the Typescript compiler adding in its polyfills. [...] By and large I think most of the JavaScript we're using is pretty standard now, it's pretty well supported. With Babel and preset-env available, it kind of polyfills things that aren't there, so I didn't notice anything. I'm very grateful that the Babel team has made those types of incompatibilities a worry of the past, because everything gets polyfilled automatically. Thank god now we have transpilers which do the dirty job for you. [...] Lately not much concern with JavaScript/ECMAScript/TypeScript compatibility because we have very, very good polyfills and transpilers, so there is not much concern about ECMAScript. 1 1 used to work with full JavaScript but having Webpack to fix different compatibility issues is less work done for better work done. The only concrete example we heard about concerning JavaScript language support came up when asking about Internet Explorer, and was quickly identified and resolved: I think it was a missing polyfill, a JavaScript polyfill [...] Something around Object.entries() or something like that [...] so I just opened the IE devtools, saw the error and understood a polyfill was needed. That was a polyfill available in the core-js library, which is a library that has a lot of polyfills for modern JavaScript features, ES6 and more, and you can cherry-pick the feature you want so that you don't have to import a full library of polyfills, just import the one you need. Much as we had expected, some participants raised issues which were found in JavaScript code, but which aren't about the JavaScript language itself:
Made with FlippingBook - professional solution for displaying marketing and sales documents online