The <select> element, long a styling holdout, is finally getting much-needed CSS customization capabilities in Chromium-based browsers. Developers can now style aspects like the dropdown arrow (using appearance: none and pseudo-elements), open state, and even the listbox itself, offering greater control over its visual presentation. This enables better integration with overall site design and improved user experience without resorting to JavaScript workarounds or custom elements. While some pseudo-elements are browser-prefixed, the changes pave the way for more consistently styled and accessible dropdown menus across the web.
Global Privacy Control (GPC) is a browser or extension setting that signals a user's intent to opt out of the sale of their personal information, as defined by various privacy laws like CCPA and GDPR. Websites and businesses that respect GPC should interpret it as a "Do Not Sell" request and suppress the sale of user data. While not legally mandated everywhere, adopting GPC provides a standardized way for users to express their privacy preferences across the web, offering greater control over their data. Widespread adoption by browsers and websites could simplify privacy management for both users and businesses and contribute to a more privacy-respecting internet ecosystem.
HN commenters discuss the effectiveness and future of Global Privacy Control (GPC). Some express skepticism about its impact, noting that many websites simply ignore it, while others believe it's a valuable tool, particularly when combined with legal pressure and browser enforcement. The potential for legal action based on ignoring GPC signals is debated, with some arguing that it provides strong grounds for enforcement, while others highlight the difficulty of proving damages. The lack of clear legal precedents is mentioned as a significant hurdle. Commenters also discuss the technicalities of GPC implementation, including the different ways websites can interpret and respond to the signal, and the potential for false positives. The broader question of how to balance privacy with personalized advertising is also raised.
Open-UI aims to establish and maintain an open, interoperable standard for UI components and primitives across frameworks and libraries. This initiative seeks to improve developer experience by enabling greater code reuse, simplifying cross-framework collaboration, and fostering a more robust and accessible web ecosystem. By defining shared specifications and promoting their adoption, Open-UI strives to streamline UI development and reduce fragmentation across the JavaScript landscape.
HN commenters express cautious optimism about Open UI, praising the standardization effort for web components but also raising concerns. Several highlight the difficulty of achieving true cross-framework compatibility, questioning whether Open UI can genuinely bridge the gaps between React, Vue, Angular, etc. Others point to the history of similar initiatives failing to gain widespread adoption due to framework lock-in and the rapid evolution of the web development landscape. Some express skepticism about the project's governance and the potential influence of browser vendors. A few commenters see Open UI as a potential solution to the "island problem" of web components, hoping it will improve interoperability and reduce the need for framework-specific wrappers. However, the prevailing sentiment is one of "wait and see," with many wanting to observe practical implementations and community uptake before fully endorsing the project.
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.
Eric Meyer reflects on the ten years since the release of his book, "Designing for Performance," lamenting the lack of significant progress in web performance. While browsers have gotten faster, web page bloat has outpaced these improvements, resulting in a net loss for users. He points to ever-increasing JavaScript execution times and the prevalence of third-party scripts as primary culprits. This stagnation is particularly frustrating given the heightened importance of performance for accessibility, affordability, and the environment. Meyer concludes with a call to action, urging developers to prioritize performance and break the cycle of accepting ever-growing page weights as inevitable.
Commenters on Hacker News largely agree with Eric Meyer's sentiment that the past decade of web development has been stagnant, focusing on JavaScript frameworks and single-page apps (SPAs) to the detriment of the core web platform. Many express frustration with the complexity and performance issues of modern web development, echoing Meyer's points about the dominance of JavaScript and the lack of focus on fundamental improvements. Some commenters discuss the potential of Web Components and the resurgence of server-side rendering as signs of positive change, though others are more pessimistic about the future, citing the influence of large tech companies and the inherent inertia of the current ecosystem. A few dissenting voices argue that SPAs offer legitimate benefits and that the web has evolved naturally, but they are in the minority. The overall tone is one of disappointment with the current state of web development and a desire for a return to simpler, more performant approaches.
Cloudflare is reportedly blocking access to certain websites for users of Pale Moon and other less common browsers like Basilisk and Otter Browser. The issue seems to stem from Cloudflare's bot detection system incorrectly identifying these browsers as bots due to their unusual User-Agent strings. This leads to users being presented with a CAPTCHA challenge, which, in some cases, is unpassable, effectively denying access. The author of the post, a Pale Moon user, expresses frustration with this situation, especially since Cloudflare offers no apparent mechanism to report or resolve the issue for affected users of niche browsers.
Hacker News users discussed Cloudflare's blocking of Pale Moon and other less common browsers, primarily focusing on the reasons behind the block and its implications. Some speculated that the block stemmed from Pale Moon's outdated TLS/SSL protocols creating security risks or excessive load on Cloudflare's servers. Others criticized Cloudflare for what they perceived as anti-competitive behavior, harming browser diversity and unfairly impacting users of niche browsers. The lack of clear communication from Cloudflare about the block drew negative attention, with users expressing frustration over the lack of transparency and the difficulty in troubleshooting the issue. A few commenters offered potential workarounds, including using a VPN or adjusting browser settings, but there wasn't a universally effective solution. The overall sentiment reflected concern about the increasing centralization of internet infrastructure and the potential for large companies like Cloudflare to exert undue influence over web access.
The CSS contain property allows developers to isolate a portion of the DOM, improving performance by limiting the scope of browser calculations like layout, style, and paint. By specifying values like layout, style, paint, and size, authors can tell the browser that changes within the contained element won't affect its surroundings, or vice versa. This allows the browser to optimize rendering and avoid unnecessary recalculations, leading to smoother and faster web experiences, particularly for complex or dynamic layouts. The content keyword offers the strongest form of containment, encompassing all the other values, while strict and size offer more granular control.
Hacker News users discussed the usefulness of the contain CSS property, particularly for performance optimization by limiting the scope of layout, style, and paint calculations. Some highlighted its power in isolating components and improving rendering times, especially in complex web applications. Others pointed out the potential for misuse and the importance of understanding its various values (layout, style, paint, size, and content) to achieve desired effects. A few users mentioned specific use cases, like efficiently handling large lists or off-screen elements, and wished for wider adoption and better browser support for some of its features, like containment for subtree layout changes. Some expressed that containment is a powerful but often overlooked tool for optimizing web page performance.
Summary of Comments ( 42 )
https://news.ycombinator.com/item?id=43532830
Hacker News users generally expressed cautious optimism about the ability to finally style
<select>elements with CSS. Several pointed out that this has been a long-requested feature and lamented the previous difficulty in customizing dropdowns. Some praised the detailed explanation in the blog post, while others worried about browser compatibility and the potential for inconsistencies across different implementations. A few users discussed specific styling challenges they'd encountered, like styling the dropdown arrow or achieving consistent behavior across operating systems. There was some concern about the potential for developers to create confusing or inaccessible custom selects, but also acknowledgment that the feature offers powerful new design possibilities.The Hacker News post "The
<select>element can now be customized with CSS" linking to a Chrome developer blog post has generated a number of comments discussing the implications of this change.Several commenters express cautious optimism. While acknowledging that increased customizability is generally good, they point out the historical difficulties and inconsistencies across browsers in styling
<select>elements. Some express concern that this new ability, while welcome, might lead to developers creating inconsistent or poor user experiences by over-styling the element and deviating too far from established platform conventions. They argue that the default select element, while visually simple, offers a familiar and predictable user experience, and excessive customization could compromise usability.One commenter highlights the specific challenges of creating accessible custom select elements, emphasizing the importance of ensuring that custom styles don't negatively impact keyboard navigation or screen reader compatibility. They suggest that developers should carefully consider accessibility implications when implementing custom styles.
Others share practical experiences and anecdotes about past struggles with styling
<select>, expressing relief that more customization will be possible. They discuss the workarounds they've had to employ, such as using JavaScript libraries to create custom select replacements, and anticipate that this change will simplify development.A recurring theme in the discussion is the desire for a balance between customizability and consistency. Commenters acknowledge the need for flexibility in styling to match different design requirements but also emphasize the importance of maintaining a recognizable and predictable user interface for the sake of usability. They suggest that developers should exercise restraint and prioritize user experience when customizing select elements.
Some comments delve into the technical details of the proposed changes, discussing the specific CSS properties and how they might be used. There is also discussion about browser compatibility and the potential for inconsistencies in implementation across different browsers.
A few commenters express skepticism about the necessity of extensive customization, arguing that the default select element is functional and sufficient in most cases. They suggest that excessive styling can lead to unnecessary complexity and potentially degrade the user experience.
Overall, the comments reflect a mix of excitement and apprehension about the ability to customize
<select>elements with CSS. While many welcome the increased flexibility, there's a clear understanding of the potential pitfalls and a shared concern for maintaining usability and accessibility. The discussion emphasizes the importance of thoughtful and responsible implementation of custom styles, prioritizing user experience over purely aesthetic considerations.