The Chrome and Web Developer Relations team is significantly expanding in 2022. Open roles span program management, Chrome extensions, CSS, rendering, DevTools, web performance, the Privacy Sandbox, and web ecosystem. The team is seeking program managers, developer relations engineers, technical writers, and infrastructure specialists to contribute to various initiatives, including Chrome Dev Summit, Google I/O, web.dev, and improving the overall web platform.
I built a Material Design-style Floating Action Button (FAB) without using any JavaScript. This was achieved using only HTML and CSS, leveraging anchor links and the ":target" selector to control visibility and create the open/close functionality. Clicking the FAB opens a menu with links to different actions, and clicking a close button hides the menu. This approach does have the trade-off of adding entries to the browser history, but it's a pure HTML/CSS solution for a common UI element.
Chrome 81 finally fixes a long-standing bug where images taken in portrait mode on phones were displayed in landscape. Now, images will respect the orientation from the EXIF data by default, unless overridden with the CSS attribute image-orientation: none. Check out the demo!
I added dark mode to my blog! Inspired by Jeremy Keith, I used CSS custom properties and media queries to switch between light and dark themes based on the user's preference. I also included a fallback for browsers that don't support custom properties and a temporary CSS class for testing since Chrome DevTools didn't yet have dark mode emulation.
I recently used Page Speed Insights for Mobile to improve my blog's page load time and one of the key recommendations was to reduce render-blocking CSS above the fold. This led me to explore the concept of critical CSS, which is the minimum CSS required to render the initial view of a page. I developed a proof-of-concept tool (bookmarklet and devtools snippet) that analyzes the DOM and extracts the critical CSS by iterating through visible elements and using window.getMatchedCSS(). This tool helps identify unnecessary CSS, integrate into build processes for optimization, and potentially generate page-specific CSS files for improved performance. It currently has limitations, working only in WebKit/Blink, ignoring media queries, and not handling pseudo-elements.
I've been working on making html5rocks.com more mobile-friendly, focusing on reducing "Time to first read". The main culprit was the Table of Contents (ToC). My initial experiment with an offscreen ToC using CSS had cross-browser inconsistencies. Now, using existing JS, the ToC is fixed to the footer and toggled into view. I'm still exploring pure CSS solutions. Initially, I favored a small scrollable ToC at the bottom, but Paul Lewis suggested a full-screen ToC, which proved better. It minimizes distractions and clutter, provides more screen space for a readable, easily navigable ToC with larger touch targets and subtle hierarchy, even for long lists. The before/after screenshots demonstrate the improvement.
I'm experimenting with mobile-friendly table of contents designs for HTML5Rocks. The current ToC takes up too much screen space, hindering access to content. My goal is to improve user experience by getting readers to the content faster. My "Bottom ToC" experiment anchors the ToC to the bottom, expanding on tap and collapsing when the main content is tapped. It uses position: fixed and the :active pseudo-class, requiring no JavaScript and keeping the rendered HTML consistent between desktop and mobile. Though it has minor scrolling issues, it effectively minimizes initial ToC screen coverage while remaining accessible.
I wanted a traffic light system on iwanttouse.com to visually represent feature support. Initially, I used simple CSS classes like .good (green), .ok (amber), and .bad (red), but this required clunky conditional logic to handle the color transitions based on percentage support. Paul Lewis suggested using HSL which allows for smooth transitions between red, amber, and green by adjusting the Hue value (0-359). Now, I can dynamically set the color using element.styles.color = \"hsla(\" + ((percentage / 100) * 90) + \", 50%, 50%)\"; which maps the percentage support to a Hue value between 0 (red) and 90 (green).
I'm excited about Mozilla's consideration of implementing webkit prefixes and starting a conversation around this. I believe that switching prefixes should only happen if the vendor is willing to drop their existing prefix in favor of another for the sake of standardization. Developers often target specific prefixes based on the dominant browser for their target audience (like WebKit for mobile). While I appreciate Remy Sharp's take, I disagree with his proposed solutions. I think prefixes should be dropped only when committing to another, and that the "production ready browser" idea is unrealistic. We should focus on educating developers on tools for handling prefixes.
I have mixed feelings about SVG. I find it complex and requiring specific tools, and its integration with the web is clunky. It feels like a context switch between HTML and SVG DOM. However, SVG is scalable, vector-based, and has powerful graphical capabilities like filters and paths, enabling things not possible with regular web technologies. I wish path could be a CSS property, simplifying its usage and allowing text or even block elements to be rendered along a path. This would be more efficient than embedding SVG within HTML elements.
Styling file input elements has always been tricky due to browser inconsistencies. WebKit-based browsers offer a clever way to style these elements. You can style the text and color of the file input using standard CSS. Additionally, the ::-webkit-file-upload-button pseudo-element allows customization of the OS-specific button's appearance, like changing it from rounded to square, going beyond basic styling.
I recently discovered a cool trick in WebKit that lets you use a canvas element as a background image, which opens up a ton of creative possibilities. It's a powerful feature, allowing for dynamic, programmatic manipulation of background images. I've included a simple demo showing how to draw a square on a div's background, but imagine the possibilities for games or complex animations! While currently WebKit-specific, I hope other browsers will adopt it soon. More demos to follow!
Just tested the blogging feature from Microsoft Word 2007 and it's pretty cool if it works as expected. I'm loving the new interfaces for Excel, Word, and PowerPoint, especially the ribbon. Visio, however, seems a bit stale. Smart Art looks promising, like CSS taken to the next level. I might just switch to Word 2007 for good!
I've updated my C# regex for extracting CSS class names to correctly handle URLs in CSS properties like url(someimage.png). The previous version incorrectly matched file extensions. The improved regex uses a negative lookbehind assertion (?<!url\s*\(.*) to prevent matching class names within url() declarations. It now accurately extracts class names, even with variations in spacing within the url() function.
I've just downloaded Beta 2 of the IE Developer Toolbar and while it's incredibly useful for diagnosing web page issues, there are still some bugs that need fixing. The element outlining in frames and scrollable divs is completely off, and re-enabling CSS after disabling it doesn't render the page correctly. If these issues are resolved, it has the potential to be one of the best developer tools out there.
IE7 Beta 2 fixes a rendering issue present in IE6 where select boxes would always appear as the topmost element, overlapping other elements like menus. This fix improves the visual presentation of web pages with select boxes. For more details, refer to the provided MSDN blog link. Further testing with CSS styles is pending.
In a previous post, I shared a regular expression for extracting CSS class names, and a reader asked for clarification. This post addresses the question with a corrected regex and C# code example using Regex.Split and Regex.Match. The regex is designed to capture class names from CSS, even those containing escaped characters, and the example code demonstrates splitting a CSS string by class names and suggests using Regex.Match for obtaining the names themselves.
As part of my ongoing project to build a CSS 2.0 parser in C#, I've developed a regular expression based on the CSS 2.0 specification to extract class names from CSS files. This regex is a step towards creating a complete CSS 2.0 parser, and I plan to develop more regular expressions for other CSS elements in the coming days. Check out my related side project about creating a CSS 2.0 parser in C# for more context.
I'm diving into the official CSS 2.1 specification to build a C# based token reader for CSS parsing. The document itself is quite dense, but it lays out the syntax and provides regular expressions to guide the implementation. This is going to be a challenging but interesting project.
A visitor searched Google for a "c# css parser" and landed on my site. Intrigued, I explored existing C# CSS parsers but found nothing. This sparked an idea for a personal project: creating my own parser. I envision distinct classes for each CSS type, managing their rules and attributes. A "Finder Class" would locate CSS classes and instantiate corresponding C# objects.
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 just read on the IE Team's Blog that Internet Explorer 7 will have native support for XMLHttpRequest and a rebuilt, windowless select element. This is huge! Native XMLHttpRequest means no more ActiveX security issues. And a windowless select element? Finally, we might have proper layering and styling. Fingers crossed these features make it into Beta 2!
In a previous post, I failed to test the alpha transparency feature. This post rectifies that. I've included an image with a green fade to white against a black background to demonstrate the effect. It may be garish, but it effectively showcases the alpha transparency.
I've been trying out IE7 Beta 1 and have some mixed feelings. While I like the tabbed browsing and the new tab placement, I'm not sure it's the ideal UI. It makes it difficult to compare sites side-by-side and to see open pages in the taskbar like I could with separate windows. A hybrid approach, like Office's per-document window or better taskbar tooltips, might be a good compromise. Also, my ATOM feed isn't being auto-discovered, and I'd like to know how IE7 handles feed discovery in general. I'm looking forward to the improved CSS support in Beta 2, although some rendering bugs are already fixed in this build.
