In 2008, amidst controversy surrounding its initial Chrome End User License Agreement (EULA), Google clarified that the license only applied to Chrome itself, not to user-generated content created using Chrome. Matt Cutts explained that the broad language in the original EULA was standard boilerplate, intended for protecting Google's intellectual property within the browser, not claiming ownership over user data. The company quickly revised the EULA to eliminate ambiguity and explicitly state that Google claims no rights to user content created with Chrome. This addressed concerns about Google overreaching and reassured users that their work remained their own.
The Chrome team is working towards enabling customization of the <select> element using the new <selectmenu> element. This upcoming feature allows developers to replace the browser's default dropdown styling with custom HTML, offering greater flexibility and control over the appearance and functionality of dropdown menus. Developers will be able to integrate richer interactions, accessibility features, and more complex layouts within the select element, all while preserving the semantic meaning and native behavior like keyboard navigation and screen reader compatibility. This enhancement aims to address the longstanding developer pain point of limited styling options for the <select> element, opening up opportunities for more visually appealing and user-friendly form controls.
Hacker News users generally expressed frustration with the <select> element's historical limitations and welcomed the proposed changes for customization. Several commenters pointed out the difficulties in styling <select> cross-browser, leading to reliance on JavaScript workarounds and libraries like Choices.js. Some expressed skepticism about the proposed solution's complexity and potential performance impact, suggesting simpler alternatives like allowing shadow DOM styling. Others questioned the need for such extensive customization, arguing for consistency and accessibility over visual flair. A few users highlighted specific use cases, such as multi-select with custom item rendering, where the proposed changes would be beneficial. Overall, the sentiment leans towards cautious optimism, acknowledging the potential improvements while remaining wary of potential drawbacks.
Chromium-based browsers on Windows are improving text rendering to match the clarity and accuracy of native Windows applications. By leveraging the DirectWrite API, these browsers will now render text using the same system-enhanced font rendering settings as other Windows programs, resulting in crisper, more legible text, particularly noticeable at smaller font sizes and on high-DPI screens. This change also improves text layout, resolving issues like incorrect bolding or clipping, and makes text selection and measurement more precise. The improved rendering is progressively rolling out to users on Windows 10 and 11.
HN commenters largely praise the improvements to text rendering in Chromium on Windows, noting a significant difference in clarity and readability, especially for fonts like Consolas. Some express excitement for the change, calling it a "huge quality of life improvement" and hoping other browsers will follow suit. A few commenters mention lingering issues or inconsistencies, particularly with ClearType settings and certain fonts. Others discuss the technical details of DirectWrite and how it compares to previous rendering methods, including GDI. The lack of subpixel rendering support in DirectWrite is also mentioned, with some hoping for its eventual implementation. Finally, a few users request similar improvements for macOS.
Some websites display boxes instead of flag emojis in Chrome on Windows due to a font substitution issue. Windows uses its own Segoe UI Emoji font for most emoji, but defaults to a lower-quality bitmap font called "Segoe UI Symbol" specifically for flag emojis. This bitmap font lacks the necessary glyphs for many flag combinations, resulting in the missing emoji. Websites can force Chrome to use the correct, vector-based Segoe UI Emoji font by explicitly specifying it in their CSS, ensuring flags render properly.
Commenters on Hacker News largely discuss the technical details behind the issue, focusing on the surprising interaction between Chrome, Windows, and the specific way flags are rendered using two combined code points. Several point out the complexity and unexpected behaviors that arise from combining characters, particularly when dealing with different systems and fonts. Some users express frustration with the inconsistency and lack of clear documentation around emoji rendering. A few commenters offer potential workarounds or solutions, including using a fallback font or pre-rendering the flags as images. Others delve into the history and evolution of emoji standards and the challenges of maintaining compatibility across platforms. A compelling comment thread explores the tradeoffs between using the combined code points for flags versus using dedicated single code points, highlighting the performance implications and rendering complexities. Another interesting discussion revolves around the role of fonts and the challenges of designing fonts that support a rapidly expanding set of emojis.
Summary of Comments ( 16 )
https://news.ycombinator.com/item?id=43217309
HN commenters in 2023 discuss Matt Cutts' 2008 blog post clarifying Google's Chrome license agreement. Several express skepticism of Google, pointing out that the license has changed since the post and that Google's data collection practices are extensive regardless. Some commenters suggest the original concern arose from a misunderstanding of legalese surrounding granting a license to use software versus a license to user-created content. Others mention that granting a license to "sync" data is distinct from other usage and requires its own scrutiny. A few commenters reflect on the relative naivety of concerns about data privacy in 2008 compared to the present day, where such concerns are much more widespread. The discussion ultimately highlights the evolution of public perception regarding online privacy and the persistent distrust of large tech companies like Google.
The Hacker News post discussing Matt Cutts' clarification on the Google Chrome license agreement from 2008 has a substantial number of comments, many of which delve into the nuances of software licensing and the concerns surrounding Google's data collection practices.
Several commenters express skepticism about Google's motivations, despite Cutts' explanation. They argue that while the license agreement might not grant Google explicit rights to user-created content, Google still collects vast amounts of user data through Chrome and other services. This data collection, they contend, is the real concern, regardless of the specifics of the license agreement. They see the license clarification as a way to address a specific criticism without acknowledging the broader issue of data privacy.
Some comments highlight the distinction between the Chrome license agreement and Google's terms of service. They point out that the terms of service, which users agree to when using Google's services, likely grant Google broader rights to user data. This distinction is crucial, they argue, because users might be misled into thinking the Chrome license agreement covers all of Google's data practices.
A few commenters offer more technical analyses of the license agreement itself. They discuss the specific clauses and compare them to other software licenses. These comments provide a deeper understanding of the legal implications of the agreement.
Some commenters draw parallels to other Google products and services, noting how Google has handled user data in those contexts. They use these past practices to support their skepticism about Google's current assurances.
There's also a thread discussing the importance of open-source software and how it provides greater transparency and control to users. These comments suggest that using open-source browsers might be a better option for users concerned about data privacy.
Finally, a few commenters express a general distrust of large tech companies and their data collection practices. They see the Chrome license agreement controversy as another example of how these companies prioritize profit over user privacy.
Overall, the comments reflect a complex and nuanced understanding of the issues surrounding software licensing and data privacy. While some commenters accept Cutts' explanation, many remain skeptical and express deeper concerns about Google's overall approach to user data. The discussion highlights the importance of carefully reviewing software licenses and understanding the implications of using online services.