I explored the concept of "magic iframes" and using adoptNode to move iframes between windows. Initially, I thought I'd found a way to preserve iframe state during the move. However, after discussing with Jake Archibald, it turns out that appendChild already handles node adoption, making adoptNode redundant. Furthermore, moving iframes causes them to reload, negating the perceived benefit. While moving DOM elements between documents is still interesting, the original premise for iframes doesn't hold. The post includes a demo and discusses the potential of the <portal> API.
In my quest to understand how to detect when a field has been autofilled, I needed a way to monitor the events of an element that doesn't exist yet. I created a helper function, waitForElement, that uses MutationObserver to wait for an element with a specific ID to be added to the DOM. Once the element is added, the promise resolves and returns the element. This, combined with my previously created monitorEvents function, allows me to start logging events on dynamically created elements, getting me closer to solving the autofill detection puzzle.
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 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.
I'm super excited about the new classList API! It's like having jQuery's class manipulation, but built right into the browser. This means we can easily add, remove, toggle, and check for classes without messy string parsing. Currently supported in Firefox 3.6+ and Chrome 7+, the classList API uses the DOMTokenList interface and is way more convenient. I'll have a better demo up on the blog soon!
Tired of recursive DOM traversal headaches? Check out the DOM TreeWalker API! This powerful tool lets you efficiently navigate the DOM, filtering nodes as you go. It's perfect for tasks like finding specific text nodes or elements, highlighting content, or even building Chrome extensions. I've included a simple example of how to use TreeWalker to find and linkify Twitter usernames on a page. Give it a try and see how much easier DOM manipulation can be!
I've been experimenting with XLinq in C# 3.0, but I'm not impressed with its querying capabilities. It seems to require loading the entire XML document into memory, which caused problems when I tried to process a 900MB file. A simple XML reader was much more efficient for this task. I'd like to see an XLinq implementation that can process XML data in a streaming fashion, similar to SAX or XmlReader, to avoid memory issues. This would make it more practical for large documents. Perhaps XLinq already supports this, but I haven't found how. For now, it seems best suited for smaller files.
I've encountered a bug in IE6/7 where dynamically created checkboxes lose their checked status after being added to the document. Setting the checked property after appending the element seems to be a reliable workaround. If anyone knows why this behavior occurs, please contact me!
I'm excited to announce the release of the IE Developer Toolbar, a free tool for exploring HTML documents in both IE6 and IE7. It offers features like DOM exploration, disabling IE settings, viewing element information, outlining, image control, resizing, a ruler for pixel-perfect measurements, and standards validation with links to W3C specs. Download it now and share your feedback and bug reports!
In this final part of "The Failures of my First AJAX Application" series, I reflect on the cross-browser compatibility issues I encountered. Focusing on Internet Explorer during development led to problems in Firefox, particularly with security errors (cross-domain data retrieval) and differences in the XML DOM model. The key takeaway is to consider cross-browser support from the outset, anticipating discrepancies between browsers and coding around missing features, similar to CSS development. The next version will prioritize cross-browser compatibility, potentially including Safari. This series has been invaluable for shaping the requirements of the upcoming version.
In my last post about Perl, I forgot to mention my upcoming need for XML processing. Before I start looking at XML parsers, I'd appreciate recommendations for a lightweight Perl XML parser. My requirements include: lightweight, XPath support (potentially), SAX-like reader functionality, DOM support, and the ability to create XML documents (preferably via DOM or similar methods). Email me your suggestions!
