Ajaxian

Let’s get one question out of the way, the question "which one is right for you?" Answer… none of the above. It’s like templates. There’s nothing wrong with templates but you don’t put together your client’s site based on a template, right? They can be a good starting point for ideas but you do your own designs. If you’re going to use a framework, it should be yours; one that you’ve created. You can look at existing frameworks for ideas and hack at it. But the professionals in this room are not well served by picking up a framework and using it as-is.

Eric put together a grid of features and which frameworks support those features. Every framework does reset, colours, and fonts. The fact that every framework has a reset is evidence of the frustration we all feel with the inconsistencies between browsers. The rules for colour tend to be much more minimal. Font styling, on the other hand, is more fully-featured generally. Whereas the colour might just be set for the body element, font sizes and faces are specified throughout. Usually that font face is Helvetica. Most frameworks steer away from trying to style form elements. Almost all of them do layout, usually combinations of columns. Four of the nine frameworks included print styles. Three of the nine included hacks.

Expanding the IE conditional statement syntax we get:

Of course, browsers are getting better and better with their CSS rendering, but in this way those annoying little CSS bugs which always seem to crop up can be worked around. It can also make maintenance of style sheets much easier since it is no longer necessary to maintain separate 'hack' files for the various IE versions. For example the following block can be used to overcome some of the issues faced with the button tag:

Conditional-CSS is an open source project and is currently available in three different source languages: PHP, C and C#, all with identical feature sets. It can readily be deployed on Apache, IIS or any other web-server with a CGI interface. Conditional-CSS can also be run from the command-line such that a style sheet with conditional statements in it can be pre-parsed for IE and included using standard conditional comments in the HTML.

Adding any form of macros or additional scopes and indirections, including symbolic constants, is not just redundant, but changes CSS in ways that make it unsuitable for its intended audience. Given that there is currently no alternative to CSS, these things must not be added.

This PHP version proves that it is not necessary to add constants to CSS. Just like the existence of the WebKit implementation cannot be taken as proof that constants in CSS are useful, so the PHP implementation cannot prove that either. But the PHP implementation has the benefit of letting authors determine the usefulness for themselves, without modifying CSS on the Web.

It is quite likely that somebody who is trying to learn CSS will give up learning it when he sees that style sheets that occur on the Web don't actually look like the tutorials he started from. Difference in upper- and lowercase or in pretty-printing are hindrances to learning, too, but limited ones: you soon learn to ignore those differences. But symbolic constants are different in each style sheet and have to be interpreted and understood each time anew.

People who understand CSS in principle may still have trouble understanding the indirection provided by the em unit, many have trouble with the advanced selectors in level 3, and many more won't understand, e.g., any of the properties that have to do with bi-directionality or vertical text. For each feature that is added to CSS there must be a careful balance (based on an informed guess, because these things are difficult to test) between the number of users that will be excluded by that feature and the number for whom it is essential that it be added.

Treating symbolic constants as an independent module would make them available for use in other contexts than CSS, would make them available to precisely the people who need them without hindering other people, would allow them to be developed without impact on CSS, and allow them to be developed more easily into what they are sure to develop into anyway: full macros, able to replace anything, not just CSS values, and able to make files shorter instead of longer.

This script adds near-native PNG support with alpha opacity to IE 5.5 and 6. Now you can have full translucency and no more ugly grey borders! It requires only one line in your CSS file, and no changes to your website HTML. <IMG> tags and background images are both supported.

WebKit now has an experimental implementation of CSS variables:

You can test this feature using a WebKit nightly

Test cases

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.

Use this bookmarklet (drag to bookmarks bar):

flip

or this one if you want a prompt:

flip2.

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.

Given the namespace declarations:

In a context where the default namespace applies:

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 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.

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.

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.