Hello Ajaxians, my name is Paul Young and I am the co-founder of Skybound Software. We're the company behind Stylizer, which is a real-time CSS editing tool. We're taking a pretty radical approach to CSS editing, and as such, a lot of what I do is "web technology research", which is looking for better ways of doing things with a web browser, ultimately so that Stylizer can automate more of the web development process. This has allowed me the chance to discover a few things that have had significant impact on a web developer's workflow, as was the case with State Scope Image Replacement.
In conducting some research for a future version of Stylizer I found a way to create a querySelector method for IE 7 and lower. querySelector is a very useful feature of newer web browsers. It takes a CSS selector as string parameter and returns an array containing the HTML elements that match the selector. Unfortunately it doesn't work in IE 7 and lower... until now :)
My querySelector technique works in IE7 back to IE4 (although I only tested it back to version 6). It's only 327 characters minified, and runs ultra-fast because it doesn't parse strings or traverse the DOM. Keep in mind though that it's using the CSS selector engine built into the browser, which means no funky CSS 3 selector features will work, as they weren't implemented old versions of IE.
In order to explain how it works, I'll need to first cover something else I discovered: Single Execution CSS Expressions (SECEs). These are an enormously powerful technique that unfortunately has been made impossible in IE8. We're using these extensively in the built-in CSS reset feature in Stylizer to eradicate bugs and to add critical but missing features in IE 6 and 7.
About CSS Expressions
The problem with IE's CSS expressions feature is that because they're recalculated hundreds of times per second, they're notoriously slow. Fortunately, I've found a way to ensure they're only executed once per matched element. Examine the code below:
There are 3 things you need to know to understand how this works:
CSS expressions are executed regardless of whether the CSS property name is valid. So "-singlex" is just an arbitrary name.
CSS expressions are executed on every matched element. So in the case above, on every div on the page.
Inside a CSS expression, the "this" keyword refers to the current matched HTML element.
The code above checks to see if the matched element has a property called "singlex". If it does, it just returns 0. Otherwise, it executes an inline function, passing it a reference to the matched element. Inside that function, we can perform whatever processing we want. At the end, we set a flag on the element to ensure that the function won't be executed again.
This is how you can do complex processing inside a CSS expression without having to worry about a performance hit. The function only executes on the first execution of the expression, and then on every subsequent execution, 0 is returned instantly. The performance cost of running an if test and returning 0 is negligible, even if you're doing it thousands of times per second. If you paste that CSS into a page with 3 div elements on it, in IE it will alert "DIV" 3 times.
The things you can do with SECE's are basically limited only by your imagination. Here is an example of using one to fake the CSS content property in IE 7 and lower:
You can use SECEs to fake all sorts of things like generated content, min-width and min-height, CSS counters, CSS outlines, and more. But most importantly, you can...
Create a querySelector method with Single Execution CSS Expressions!
Creating a querySelector method is just a matter of dynamically adding a SECE to a page that copies a reference to each matched HTML element into a globally accessible array, and then returning that array. Examine the code below:
/*@cc_on if (!document.querySelector) document.querySelector = function(selector) { // Add a new style sheet to the page var head = document.documentElement.firstChild; var styleTag = document.createElement("STYLE"); head.appendChild(styleTag); // Create a globally accessible element array document.__qsResult = []; // Create the SECE that copies all matched // elements to document.__qsResult. styleTag.styleSheet.cssText = selector + "{qs: expression(this.__qs?0:(function(t){document.__qsResult.push(t);t.__qs=0;})(this));}"; // Reflow the page. Without this, the SECE won't execute. window.scrollBy(0, 0); // Clean up and return head.removeChild(styleTag); return document.__qsResult; } @*/
There you have it! The function is wrapped in a conditional compilation comment to make sure only IE 7 and lower can see it. Here is a minified version for convenience:
I hope you can make use of SECEs and this querySelector method. Maybe it even has a place in jQuery? I don't know. (John Resig, are you reading? :)
UPDATE
After thinking this through a little further, I realized that you don't need to use a SECE at all for this, just a CSS expression added with JavaScript will do. Also, one of the commenters (Jordan1) pointed out that the code wouldn't return elements that had already been queried once. I've posted an update to the code below that should rectify the issue:
Alex Russell has been having a really interesting discussion with some standards folks about what is wrong on the Web right now, and it narrowed down to discuss CSS variables as a case study (it aint perfect, but get DRY and ship it!)
Alex tells it how it is, but people forget that he does this as he is passionate about the Web, and that he does also give credit and positive outlook IF it is due!
His latest post shows this as he talked about CSS 3 progress and specifically the flexible box model that Mozilla and WebKit have had forevaaaaaah:
David Baron (of Mozilla fame) is editing a long-overdue but totally awesome Flexible Box spec, aka: “hbox and vbox”. Both Gecko and WebKit-derived browsers (read: everything that’s not IE) supports hbox and vbox today, but using it can be a bit tedious. Should you be working on an app that can ignore IE (say, for a mobile phone), this should help make box layouts a bit easier to get started with:
The mighty Erik Arvidsson also reminds us of the CSS3 attr() support (already in Firefox, coming in WebKit too) that would enable us to wire up <div class=vbox flex=2>…</div>.
Although you may be thinking "this is great, but freaking IE means that I don't care about it." True. It would be awesome if someone took a shim that could grok this CSS (we built a CSS parser for Thunderhead) and make it work in IE etc. But until that day, or the day that IE implements it (heh) what can you do?
Write iPhone or Palm webOS or Android WebKit apps? You can use it right friggin now!
Firefox 3.6 alpha releases have already arrived and there are already cool new features on the heals of the 3.5 release, as well as rapid speed improvements.
DOM changes to elements using the table display types now work much better.
You can determine whether or not content is being rendered on a touch-enabled device using the new :-moz-system-metric(touch-enabled) selector.
The reorder event is now sent to embedded frames and iframes when their document is loaded. See bug 420845.
The getBoxObjectFor() method has been removed, as it was non-standard and exposed even more non-standard stuff to the web. See bug 340571. Also affects mootools which uses this call for Gecko detection. See this mootools bug.
A new attribute has been created, mozScreenPixelsPerCSSPixel, for obtaining the amount of screen pixels per CSS pixel on nsIDOMWindowUtils. This can be used in conjunction with the new global properties, mozInnerScreenX and mozInnerScreenY, to compute screen coordinates. See
When the page's URI's document fragment identifier (the part after the "#" (hash) character) changes, a new hashchange event is sent to the page. See window.onhashchange for more information.
Geolocation "address" support is now available enabling user-readable position information. See
Matt Thompson has created a fun little jQuery plugin called Chroma-Hash that "dynamically visualizes secure text-field values using ambient color bars":
Password entry can be frustrating, especially with long or difficult passwords. On a webpage, secure fields obscure your input with •'s, so others can't read it. Unfortunately, neither can you—you can't tell if you got your password right until you click "Log In".
Chroma-Hash displays a series of colored bars at the end of field inputs so you can instantly see if your password is right. Chroma-Hash takes an MD5 hash of your input and uses that to compute the colors in the visualization. The MD5 hash is non-reversible, so no one could know what your password just from the colors. Your password will display the same sequence each time, so you can learn to expect "blue, red, pink", for instance; if you instead see "green, purple, yellow", you'll know you typed it wrong.
Weston Ruter has created a very cool library that enables CSS gradients on non-WebKit browsers (at least, a subset). Incredibly cool:
CSS Gradients via Canvas provides a subset of WebKit's CSS Gradients proposal for browsers that implement the HTML5 canvas element.
To use, just include css-gradients-via-canvas.js (12KB) anywhere on the page (see examples below). Unlike WebKit, this implementation does not currently allow gradients to be used for border images, list bullets, or generated content. The script employs document.querySelectorAll()—it has no external dependencies if this function is implemented; otherwise, it looks for the presence of jQuery, Prototype, or Sizzle to provide selector-querying functionality.
The implementation works in Firefox 2/3+ and Opera 9.64 (at least). Safari and Chrome have native support for CSS Gradients since they use WebKit, as already mentiond.
This implementation does not work in Internet Explorer since IE does not support Canvas, although IE8 does support the data: URI scheme, which is a prerequisite (see support detection method). When/if Gears's Canvas API fully implements the HTML5 canvas specification, then this implementation should be tweakable to work in IE8. In the mean time, rudimentary gradients may be achieved in IE by means of its non-standard gradient filter.
CSS Gradients via Canvas works by parsing all stylesheets upon page load (DOMContentLoaded), and searches for all instances of CSS gradients being used as background images. The source code for the external stylesheets is loaded via XMLHttpRequest—ensure that they are cached by serving them with a far-future Expires header to avoid extra HTTP traffic.
The CSS selector associated with the gradient background image property is used to query all elements on the page; for each of the selected elements, a canvas is created of the same size as the element's dimensions, and the specified gradients are drawn onto that canvas. Thereafter, the gradient image is retrieved via canvas.toDataURL() and this data is supplied as the background-image for the element.
An aside. I only just noticed the Gears Canvas API. It doesn't quite do what you think..... I always wanted to implement Canvas in Gears. It is also strange that Gears is so under the radar at Google these days. One blog post per year?. I guess all of the work is going into Chrome / WebKit itself.
The way @font-face works is that whatever font attributes you specify for a @font-face rule, they don’t determine how the font looks but rather when it’s gonna get used. For example if you have the following two rules
Then if you use the “newfont” font-family with weight 200 it’s going to use Arial, but if you use it with weight 300 it’s going to use Calibri. So we can take advantage of that, and since it uses @font-face we don’t even have to worry if the user’s computer has fonts or not.
We posted on TypeKit recently, and we have another playa Kernest in the "fix friggin type on the Web" game.
And for a final little nugget of font goodness, from @schill:
Typekit looks to include jQuery, loads CSS with base64-encoded data:font/otf URLs for @font-face. "Safer" than a plain open .TTF, I suppose.
CSS is great for styling, but can be agonizing for laying out applications. There have been attempts to do JavaScript powered layout, but what about adding more semantics to CSS itself?
This document describes a new set of CSS properties and object specifications that together compose a powerful declarative means to describe complex arbitrary layout criteria that are both reusable and extensible. The new properties are Javascript expressions that are woven together in a constraint resolving system to perform a specified layout. Additionally, a set of global objects defined in the constraint resolution Javascript execution environment enable powerful operations to be expressed succinctly resulting in more readable and compact layout specifications.
Oh, was there some Microsoft plugin launched last week? We don't need no stinkin' plugin!
Charles tells us more:
Larger images load in after 2 seconds for high quality zoomed images.
State changes are handled via CSS.
Reflections use CSS masks instead of a Canvas draw (standard box reflections don’t quite work yet).
Reflections sit on a scaleY(-1.0) coordinate system and are tracked independently, which is surprisingly easy.
This demo pushed a few performance limits and currently avoids drawing and animating a drop shadow and border.
On Leopard, animating transforms with a transform list need to have only 1 function to animate in hardware.
Some expensive CSS selectors are used, and haven’t been fixed yet. (in progress)
Almost all of this is hardware accelerated on Snow Leopard. About the only thing that isn’t is the networked image loading.
Key states are tracked manually (timers handle keyboard delay and repeats) so a smooth motion can be achieved when the keys are held down.
Cell sizes are chosen at initial window load time and don’t change on window resize, although the origin does. It’s rather slow, however, so I may end up changing that.
To give you a sense of the effort involved, this demo was written over 3 days, a few hours each evening.
There have been many tools to help make image spriting easier, by packaging up your images into one large image and splitting it up again via CSS.
Steve Souders just showed off a new little tool he created, Sprite Me at the Velocity conference that kicked off today. He has made it easier to work with sprites by:
finds background images: SpriteMe generates a list of all background images in the page. Hovering over the its URL displays the image.
Each of the DOM elements that use that image are also listed. [DONE]
groups images: It's hard to figure out which images can be sprited together, and how they should be laid out. For example, background images that repeat horizontally must fill the entire width of the sprite. Background images positioned left bottom must be at the right top of the sprite if their container might be bigger than the image. SpriteMe determines which images should be sprited together based on these constraints.[IN PROCESS]
creates sprites: SpriteMe generates the sprite for each grouping of images. This is done using open source tools, such as CSS Sprite Generator. [TBD]
updates CSS: The final tricky part of using sprites is changing the CSS. Sometimes the CSS is a rule in a stylesheet. Or it might be a rule in an inline style block. Or it might be specified in an element's style attribute. Because SpriteMe runs inside your web page, it can find the CSS that needs to be updated. It makes the changes in realtime, so you can visually check to confirm the sprites look right.You can export the modified CSS to integrate back into your code. [TBD]
Great, a simple new bookmarklet to work with Sprites. It is always a good idea to sprite up right? Not exactly.
Vlad Vuki?evi?, a leader in the Mozilla community (and brought us cool stuff like Canvas 3D!) has spoken up on the internals of the browser, which shows you the trade-offs for the spriting approach:
The biggest problem with CSS sprites is memory usage. Unless the sprite image is carefully constructed, you end up with incredible amounts of wasted space. My favourite example is from WHIT TV's web site, where this image is used as a sprite. Note that this is a 1299x15,000 PNG. It compresses quite well — the actual download size is around 26K — but browsers don't render compressed image data. When this image is downloaded and decompressed, it will use almost 75MB in memory (1299 * 15000 * 4). If the image didn't have any alpha transparency, this could be maybe optimized to 1299 * 15000 * 3, though often at the expense of rendering speed. Even then, we'd be talking about 55MB. The vast majority of this image is blank; there is nothing there, no useful content whatsoever. Just loading the main WHIT page will cause your browser's memory usage to go up by at least 75+MB, just due to that one image.
That's not the right tradeoff to make for a website.
What alternatives are there? None right now.... but they are hopefully on the way. Some folks have been talking about the idea of packaging up images in zip files, and then the browser can manage more than just the download process, but also only load up what it needs:
Many browsers have support for offline manifests already; it might be possible to extend that to allow downloading one file (like a jar/zip file) that contains a manifest of resources and equivalent URLs that are contained inside it.
Sprites have the advantage of working right now, but maybe there should be a way to serve up a multipart response with your sprite images as well. That would cut down on CSS rule count and maintenance, but still group the images in one HTTP request. Authors are already giving up the advantages of separate resources in return for speed, so maybe this is worth doing.
You can (in theory… haha) get some of these advantages with HTTP pipelining, but a multipart response would allow the server optimize the response order as they do with sprites today.
How about starting the week with something fun. Zach Johnson has been having fun with 3D effects via CSS such as his isocube above, which is brought to you with simple HTML (including a video tag for a playing video on the surface!) and some CSS like this:
CSS3 properties can greatly improve your workflow, making some of the most time-consuming CSS tasks a breeze and allowing for better, cleaner and more lightweight markup. Some properties are still not widely supported, even by the most recent browsers, but that doesn’t mean we shouldn’t experiment with them or give visitors with modern browsers advanced features and CSS styling.
In this regard, keep in mind that educating our clients is both useful and necessary: websites don’t have to look exactly the same in every browser, and if a difference doesn’t negatively affect the aesthetics or usability of a website, it should be considered. If we continue to waste valuable time and money making every detail pixel-perfect (instead of adopting more flexible and future-oriented solutions), users won’t have an incentive to upgrade their browsers, in which case we would have to wait a long time before older browsers become legacy browsers and robust modern browsers become the standard.
The earlier we experiment with and adapt new CSS3 properties, the earlier they will be supported by popular browsers and the earlier we’ll be able to use them widely.
Have you ever wanted to just <a href="path" action="post">? Remember the hub-ub with the old Google Web Accelerator and how it started to crawl links to delete actions that were mistakenly using GET?
Natalie Downe has written up a piece on styling HTML buttons as links which means that you can somewhat get the same effect. It shows how you can use an inline span to get the hover effect, taking:
John Allsop has created a very cool CSS gradient exploration tool that lets you get the gradient you need, with the resulting sample and code right there.
