I explored using LLMs for checking web API browser compatibility. Existing LLMs struggle with outdated data, so I experimented with MDN's Browser Compat Data (BCD). Initial trials using raw BCD JSON with GPT-4 had limitations. To improve this, I converted the BCD into English descriptions of API support and loaded it into a Polymath instance. This allows natural language queries about API compatibility across browsers, like "Is CSS Grid supported in Safari, Firefox, and Chrome?" or "When was CSS acos available in Chrome?". The results are promising, but further refinement is needed to ensure accuracy and reliability.
I've added a new feature to time-to-stable that lists experimental APIs across browsers using BCD. This helps developers track experimental APIs, understand their stability, and consider the implications for website integration. It helps answer questions about cross-browser compatibility and potential deprecation, informing decisions about using these APIs.
This post explores browser compatibility data, focusing on features present in some browsers but not others. I've created a tool, "Not yet Stable," to visualize these differences and help developers understand the current web platform landscape. While high-level comparisons are interesting, the real value lies in identifying smaller, unexpected compatibility issues that can cause frustration. The tool allows for granular comparisons between specific browsers (e.g., Chrome vs. Firefox, Safari vs. Firefox) to pinpoint these inconsistencies. I've observed significant discrepancies in media-related features, such as Web Codecs API, Picture-in-Picture, and MediaStreams. The goal is to leverage this data for better understanding and ultimately improve web compatibility.
I've created a tool called "Now Stable" using Browser Compat Data (BCD) to help developers determine when web APIs become stable across different browsers. This addresses the challenge of keeping up with browser updates and helps developers confidently choose APIs for their projects. The tool allows users to select their target browsers (e.g., Chrome, Safari, Firefox) and see a chronological list of when APIs became available across those browsers. I'm looking for feedback on how this tool can be improved and how developers would use this data.
This post discusses the challenges web developers face due to the constantly evolving web platform. It highlights the difficulty in keeping up with changes, browser inconsistencies, and the lack of clear documentation. It then outlines the efforts made to address these issues, focusing on improving communication about the web platform, enhancing compatibility and interoperability across browsers (Compat 2021, Interop 2022), and investing in better documentation like MDN's Browser Compat Data. These initiatives aim to create a more stable and predictable web development experience, fostering innovation.
This blog post discusses the top challenges faced by web developers in 2021 based on a quarterly survey. The findings reveal that the top pain points remain consistent with previous years, including browser compatibility, testing, documentation, debugging, framework usage, and security/privacy concerns. The survey data highlights the difficulties developers face in keeping up with evolving web standards and the ever-expanding ecosystem of tools and frameworks. Cross-browser compatibility and testing remain significant hurdles. While initiatives like Compat 2021 aim to address these challenges, their impact is yet to be fully realized. The data consistently shows the need for improved developer tooling and a more streamlined web development experience.
I sincerely apologize to the Safari team for misrepresenting their compatibility score in our Chrome Dev Summit presentation. Due to a combination of personal circumstances, a reliance on outdated Safari Tech Preview data from wpt.fyi, and the rush leading up to the event, we displayed an incorrect improvement score (64 => 85 instead of 64 => 92). This was my mistake, and I take full responsibility. While we attempted to rectify the situation, it was too late to change the presentation. Our intent was never malicious, but rather to highlight the collaborative effort to improve web compatibility. I've learned valuable lessons from this experience: triple-check data, consult with relevant engineers, focus on stable release data, and communicate with browser teams transparently. Going forward, we'll prioritize broad browser support and emphasize the user experience in stable releases.
Web compatibility is a major developer concern. While projects like Compat 2021 aim to address these issues, data-driven analysis is crucial for understanding the web's evolving compatibility landscape. This post highlights Browser Compat Data (BCD), a valuable resource from Mozilla that offers detailed compatibility information for web APIs. BCD bridges the gap between raw Web Platform Tests data and user-friendly tools like caniuse.com. I've created a demo app, "The Web Of...", utilizing BCD to visualize API availability across different browsers at specific points in time. This data empowers developers to make informed decisions about API usage, assess compatibility across browser engines, and track the overall progress of web compatibility. The availability of such data opens up possibilities for new metrics like a "CompatIndex" to quantify web compatibility. Contributions to the BCD project are encouraged to further enhance this valuable resource.
The MDN Browser Compatibility Report 2020 surveyed web developers to identify pain points in cross-browser compatibility. Layout and styling issues, especially with Flexbox and Grid, topped the list, along with challenges related to viewport units, scrolling on mobile, and achieving consistent form styling. Internet Explorer and Safari were frequently cited as problematic browsers. While JavaScript was initially flagged as a concern, interviews revealed that transpilers like Babel largely mitigate core language issues, shifting the focus to browser APIs and their inconsistencies. The report highlighted ongoing efforts to improve compatibility, including fixes for Flexbox and Grid in Chromium and WebKit, the transition to Chromium-based Edge, and a commitment to enhancing MDN's browser compatibility data.
This post discusses the importance of developer satisfaction, particularly for web developers, and how the MDN Web Developer Needs Assessment has influenced Chrome's web platform priorities for 2020. My hypothesis is that improving the web platform will lead to increased developer satisfaction, more content creation, and happier end-users. Based on the MDN survey data, key areas for improvement include browser compatibility, testing, documentation, debugging, framework integration, and privacy & security. Chrome is committed to working with the web ecosystem to address these challenges and increase developer productivity and satisfaction. We'll share more specific plans in the coming weeks and welcome your feedback on these focus areas and how Chrome can better engage with the developer community.
WebMessaging (postMessage) seems simple but has quirks. Different browsers handle data differently (structured clones vs. strings). The biggest problem is sending messages to a newly opened window/iframe. You can't just send a message immediately; you have to wait for the window to load and signal back. This adds complexity, requiring the new window to postMessage back to the opener, which then sends the actual data. A workaround involves passing data via window.name, but this has security implications as the data's origin is uncertain and the name persists, potentially exposing data.
I've given my website a fresh new look with a template of my own design! I'm currently working on ensuring it's compatible with Internet Explorer. Your feedback and suggestions are greatly appreciated!
The IE team has announced that some CSS hacks used to fix issues in IE5 and IE6 won't work in IE7. This means web developers targeting IE7 will need to update their sites to address these breaking changes. The IE team encourages developers to check for common CSS hacks and replace them with standards-compliant code or conditional comments. While a CSS-based solution would be ideal, there currently isn't a standard for this issue, prompting a call to action for developers to update their code and support the move towards better standards compliance.
I've just finished creating a proxy script that allows access to the Yahoo Content Analysis API Term Extraction service from any browser, bypassing cross-site scripting issues. It works by taking a POST request, forwarding it to Yahoo, and returning the XML response. The code (Perl) is included in the post, and I've successfully tested it with IE6, IE7, and Firefox. Feel free to email me if you have any questions.
In part 2 of my AJAX application journey, I'm tackling browser compatibility issues between Firefox and Internet Explorer. Key differences include handling XML node text, event triggers for synchronous XmlHttpRequests, and table object model inconsistencies. Looking ahead, I'm planning to componentize my JavaScript for better management and browser caching, and create an event-driven object model for my next application to improve structure and cross-browser functionality. My focus will be on supporting the lowest common denominator for broader browser compatibility.
I've noticed a difference in how Internet Explorer (versions 6 and 7) and Firefox handle synchronous XmlHttpRequests. In both browsers, you can send requests using JavaScript. However, after the synchronous send() call, Internet Explorer still triggers the onreadystatechange event, while Firefox does not. I need to research which behavior is correct and according to spec. If you happen to know, please email me!
