Monday, June 30th, 2008
We talked about how CSS variables are next a few months back, and now they are here!
WebKit now has an experimental implementation of CSS variables:
You can test this feature using a WebKit nightly
Once again, via Dylan Schiemann.
Friday, June 27th, 2008
Eric Wendelin has taken a look at the general sibling combinator shown above as:
This would affect each <p> element that is a sibling of a preceding <h4> element. This is different from the Adjacent Sibling Combinator (+) in that it affects all following <p> siblings instead of just the immediate sibling. It is very well supported: IE7+, FF2+, Opera 9.5+, Safari 3+, and even Konqueror.
Thursday, June 26th, 2008
Our own Christian Heilmann has created a new JavaScript library Autogrid that marries YUI Grids, the base CSS library, to allow for smart resizing:
I love YUI Grids. I know my CSS and I know how to work around diff erent problems of browsers, but I am also very much bored about having to fix and test and create these workarounds over and over again. While YUI Grids might not be perfect for all cases of web development out there, I am happy to take a pragmatic approach and just create sites that can be done with them (now you also know why I am not a designer).
One problem I keep having when I put some YUI Grids-based sites live is that people complain about me expecting a certain screen resolution or viewport size. YUI grids can either be 100% wide, which can be pretty silly on high resolutions, or optimized for resolutions of either 800×600 or 1024×768. When you optimize for 800 pixels people on higher resolutions will complain about the length of the page and when you go for 1024 people will say they have to scroll to see your side-bar on 800×600. You can’t win.
Or can you? CSS is not dynamic — it has a fixed state and you can only hope that the browser does the right thing with what you give it (well, there are conditional comments for IE, but technically they are HTML, and of course there are media queries in CSS3 and other goodies, but for the sake of the argument let’s say supporting IE6 is a base). JavaScript, on the other hand, is very dynamic and you can read out and check what is happening to the browser currently in use and react to it.
Putting this feature of JavaScript to good use you can create a YUI-Grids-based layout that remains flexible and changes according to needs. All you need to do is use some YUI Dom magic and change IDs and classes accordingly.
Christian has a demonstration page, and the full code:
We continue to see JavaScript libraries working with CSS to great effect.
Monday, June 2nd, 2008
Thomas Fuchs is having some fun at RailsConf, and sent out a fun use of the new WebKit transformations using the medium of the bookmarklet:
Use this bookmarklet (drag to bookmarks bar):
or this one if you want a prompt:
Monday, May 26th, 2008
The CSS Namespace Module has now been bumped up to a "W3C Candidate Recommendation", thanks to the work of Elika J. Etemad and Anne van Kesteren (who built on the earlier work of Peter Linss and Chris Lilley).
The module is simple, but will be a very welcome addition:
This CSS Namespaces module defines the syntax for using namespaces in CSS. It defines the @namespace rule for declaring the default namespace and binding namespaces to namespace prefixes, and it also defines a syntax that other specifications can adopt for using those prefixes in namespace-qualified names.
This example does a good job at showing the namespaces:
Given the namespace declarations:
CSS:
In a context where the default namespace applies:
- toto|A:
represents the name A in the http://toto.example.org namespace.- |B:
represents the name B that belongs to no namespace.- *|C:
represents the name C in any namespace, including no namespace.- D:
represents the name D in the http://example.com/foo namespace.
This is a good step, but what we really wait for is the support in major browsers!
Wednesday, May 21st, 2008
We all want to use input[type=text] but browser support doesn't seem to quite be there (IE 6?).
This lead James Coglan down the path of creating a teeny Rails plugin, classy_inputs:
Good lord do I ever hate input tags. (YUI hates them too, but I’ll leave that story for another time). All the different types should really have been different tag names, and they are a total pain to use with CSS. As such, I used to end up doing tedious stuff like adding a :class option to every form element when writing Rails templates. A while back, I tried to patch Rails to get it to do this automatically, but its test suite totally baffled me at the time by applying the classes in some places but not others.
So, a quick plugin to stave off RSI:
script/plugin install
http://svn.jcoglan.com/classyinputs/trunk/classy_inputs
With that installed, any input tag created using a Rails view method will gain a class name matching its type attribute. Maybe I’ll have another stab at patching Rails, but I’m not promising anything.
Wednesday, May 14th, 2008
Chris Schneider has created a javascript implementation of CSS Effects using the MooTools JavaScript library. It basically parses the css and mimics the new Webkit css animations.
With the introduction of CSS we could seperate the presentation layer and the content layer, but we were not able to add animations via CSS. DHTML fixed this misbehavior, but now the presentation and behaviour layer were mixed.
First I tried the concept of adding something like “-moofx-{property}: {from} {to};†to CSS. The disadvantage of this way is that you have to specify the change twice: First in regular CSS to serve the non-JavaScript-users, then for the animation.
After hearing about WebKit’s CSS Animations I changed my concept of CSS animations. Instead of setting an additional target or starting value, both properties are specified â€normallyâ€. The only thing you have to add is a declaration.
The script uses MooTools soon to be release v1.2 and works in Safari 3, Firefox 2 and mostly Internet Explorer 7. The script degrades in Internet Explorer 6, because no dynamic pseudo-classes are supported.
You can see the script in action here.
Tuesday, May 13th, 2008
Matthew Buchanan had a little fun and created a Timelapse CSS example that lets you walk through the process of how a browser would put together a page if it was a human artist:
When building website templates, I’m constantly switching between a view of my CSS code and a view of the page I’m working on in a browser. At my most fevered I’m switching from one to the other after every couple of amendments, to ensure my additional rules are having the intended effect. Over time, were I to record this incremental buildup, it would paint a reasonably good picture of my approach to converting a design comp to a CSS layout.
With this in mind, I thought it might be useful to try to capture the process automatically and then play it back. I’ve seen this done using a collection of manual screen captures, but that didn’t seem a particularly elegant or easily reproducible solution.
As a proof of concept I cobbled together a (stylistically unsound) function to traverse the stylesheets of the current page (in reverse order) and remove a property from each rule every tenth of a second.
JAVASCRIPT:
Monday, May 12th, 2008
Category: Browsers
, CSS, Performance
Are child selectors slower than more simple brethren? This is a question that Jon Sykes sought out data for after he read the work of Jim Barraud.
His conclusion?
The skinny is that child selectors are a major performance issue.
This seemed to make sense, but to me I needed some sort of proof rather than just being told it's that way by someone, so over the last two days I've tried two approaches to see if I can replicate the issue.
The first one was rather a half-assed idea that afterwards seems fundamentally flawed as a benchmark.
So I took a new approach which does seem to return some valid and rather interesting findings, particularly regarding Safari and Firefox 3 and how they react to child selectors and performance.
The tests show that there is slow down using child selectors over direct class name declarations in IE6, IE7 and Safari 3. Safari 3 being the most impacted by child selectors. Firefox 2 has some impact, and Firefox 3 doesn’t seem to be impacted at all.
That said, this is a very extreme test, it is not often you’d have 20,000 class definitions in a single page or that all of them would use 4 levels of child selector.
Wednesday, May 7th, 2008
Category: CSS
Eric Meyer has felt a lot of pain due to line-height, which means us mere mortals are totally up the creak.
He posted about how line-height is abnormal and goes into detail on his learning curve, and the pain he saw which lead him too:
Why bring all this up? Because I went and poked line-height: normal with a stick, and found it to be both squamous and rugose. As with all driven to such madness, I now seek, grinning wildly, to infect others.
Here’s the punchline: the effects of declaring line-height: normal not only vary from browser to browser, which I had expected—in fact, quantifying those differences was the whole point—but they also vary from one font face to another, and can also varying within a given face.
I did not expect that. At least, not consciously.
He created a tool that visualizes all of this for you, so you can see the magic at work:
Tuesday, May 6th, 2008
After building a slide deck with Ben, you learn the art of a perfectionist. He would love Chris Hester's posting on button padding that shows you how your buttons look on various browsers and operating systems. Even been frustrated when you try to style things on the Mac?
Here are a few of his findings:
Friday, May 2nd, 2008
Category: Browsers, CSS, JavaScript
John Resig "doesn't think there's a single JavaScript developer who isn't excited about the new Selectors API specification (and the upcoming implementations)."
He was asked to provide feedback on the API, and he sent them an email with just that.
He had three concerns:
DOMElement.querySelectorAll returning incorrect elements
This is the most critical issue. As it stands DOM Element-rooted queries are borderline useless to libraries - and users. Their default behavior is unexpected and confusing. Demonstrated with an example, using Dojo:
He then asked other library authors if they agreed:
Andrew Dupont (creator of Prototype's selector engine):
My issue with this is that it violates principle of least surprise and bears no resemblance to the APIs in the wild.
Alex Russell (creator of Dojo's selector engine):
This is a spec bug.
Combinator-rooted Queries
I read about some prior discussion concerning this (especially in relation to DOMElement.querySelectorAll-style queries). This is an important part of most libraries, as it stands. Maciej's proposed solution of using :root to allow for front-leading combinators is perfectly acceptable to me (where :root is made equivalent to the element, not the document element).
JAVASCRIPT:
