• 200806 May

    Shaun Inman did a very interesting post yesterday on what he describes as “CSS Qualified Selectors”. The idea is nice, he wants to be able to do:

    a {
        text-decoration: none;
        color: #A10;
        border-bottom: 1px dashed #A10;
    }

    And then for images:

    a < img { border: none; }

    So if <img> has a parent <a>, the border isn’t there.

    What’s most interesting about the post though is the comments. It seems, as Eric Meyer states there, that this kind of selector has been discussed quite a few times on the CSS mailing list, and isn’t doable. Dave Hyatt, one of the core WebKit developers, comments with a good explanation of why it can’t be done. It’s a nice read, and a good insight into the difficulties of developing a new standard.

  • 200808 Feb

    While thinking about suggestions for new features wanted in CSS3, my mind strayed onto image replacement methods. At the moment we have a cornucopia of methods, none of which resolves the style on/images off problem without extra markup (I’m referring to CSS-only techniques).

    CSS3 should be able to solve this problem for us, shouldn’t it? Isn’t that what it’s for? My initial idea was to suggest a pseudo-class that detected whether or not images were disabled and changed the content accordingly; something like:

    h1 {
    background-image:  url('image.png');
    text-indent: -9999px;
    }
    
    h1::no-images { text-indent: 0; }

    After doing a quick search, I found out that a solution has already been proposed, and it is much more elegant than mine! It uses the content declaration to replace the content, with a fallback option given after a comma:

    h1 { content: url('image.png'), contents }

    On the unofficial CSSWG wiki, the idea has been taken even further and the require-font function added; using this will allow you to instruct the browser to use a required font if available, download it if not, display an image if that’s not possible, or display in the fallback font style if none of the previous apply:

    h1 { 
    content: require-font('FF Meta Serif'), url('image.png'), contents;
    }

    A very neat solution! The drawback? Although accepted, this is not in the Generated and Replaced Content draft yet; and the module has been assigned a low priority.

  • 200731 Oct

    The Webkit team have certainly been busy recently; since we mentioned the introduction of web fonts, they’ve also implemented transformations and animations.

    Transformations, via the -webkit-transform property, allow you to scale, rotate and skew block elements; reader Ain Tohvri has put together an impressive test suite. At the moment this property doesn’t affect layout, so behaves more like a relatively positioned element.

    Animation, which uses the -webkit-transition family of properties, allows you to set timings for fades, rotation, expansion, collapses, and more. They work in the same way as many current JavaScript libraries.

    I’m in two minds about this; while it’s always welcome to see more innovation from browser manufacturers, I can’t help but think that they’re focussing their energies in the wrong direction. As I mentioned above, all of the above effects can be replicated with JavaScript libraries, and I don’t think that CSS should be used for controlling behaviour so explicitly. Users who don’t like to see animated pages currently have the option of disabling scripts, but they won’t have the option of disabling CSS in the same way.

    Also, IMHO, there are a more pressing areas of CSS that need investigating; the Advanced Layout or Grid Layout modules are more important to the future of CSS than animations and transformations.

    On the positive side, the Webkit team have promised to release technical documents which explain the proposed spec in detail.

    If these new features float your boat, you can test them out by downloading the latest Webkit nightlies.

  • 200704 Oct

    The latest Webkit builds now support an open implementation of the @font-face rule, which we wrote about some time ago. Recent articles by Håkon Wium Lie had indicated that Opera might be first to market with this, but the Webkit team seem to have beaten them to it.

    In short, @font-face allows you to download fonts to the visitor’s browser, meaning you can use any licensed font to display your pages. An example of use would be:

    @font-face {
    font-family: 'The New Font';
    src: url('http://www.example.net/newfont/');
    }

    It’s a step forward for the web, and I’m delighted it’s here. Congratulations to the Webkit team, and here’s hoping that Opera push forward with their plans to implement it too. It seems like Firefox 3 won’t support this rule, so late 2008 may be the earliest we see this in Mozilla browsers.

    As for Internet Explorer, they’ve actually implemented @font-face since version 4! However, it only works with their proprietary font format, .eot, and never took off. I wonder if they will reimplement it with Open- or True-Type fonts now.

    @font-face isn’t actually new in CSS 3, it’s been around since CSS 2. However, as it’s never been properly introduced I think it’s okay to include it here!

  • 200729 Aug

    Since the move away from tables to CSS-based layouts, lists have become more important in producing semantic markup; in Andy Clarke’s Transcending CSS, he seems at times to be on the verge of saying all content can be marked up with lists!

    Yet the basic list itself is let down by the range of markers available; for unordered lists you have disc, circle or square, or images which are implemented so differently across browsers that it’s better not to use them. Perhaps most annoying of all, you can’t have the glyph be a different colour from the content without extra markup:

    <li><span>Lorem ipsum</span></li>

    That could be set to change with the proposed new lists module which allows a much wider range of glyphs, markers and counters and, more notably, the ability to style them with the ::marker pseudo-element. In a nutshell, this allows you to treat the list-style-type as a separate entity and style it accordingly.

    The working draft doesn’t specify exactly what declarations you’ll be able to apply, although it does mention borders, margin, and padding so it’s not a great stretch to imagine that you could add colour and font styles to that also – meaning lists could be set to become a lot more decorative:

    li::marker {
    background-color: #fff;
    border: 2px dotted #f00;
    color: #f00;
    font-size: 2em;
    height: 4em;
    text-align: center;
    width: 4em;
    }

    Do I have to include the usual disclaimer? This is still only a working draft of a proposal (and a low priority one at that), and browser support currently stands at nil.

  • 200721 Aug

    I was reading Veerle’s blog today; the excellent article A CSS styled table version 2, to be precise. All good, practical stuff, and well-presented as usual. But what stood out for me was the technique to stripe the table rows: either through classes, or Javascript.

    Of course, both of those are valid techniques; but really, neither should be. It’s pretty easy to forget, when we see how far CSS-based design has come in the last few years, just how reliant on workarounds and tricks we are in order to perform what should be basic functions.

    Presented below are some of those workarounds that I’d love to see consigned to the dustbin of history; not because they are bad – on the contrary, they are extremely inventive – but because CSS 3 should allow the effects to be replicated without the extra mark-up, script or code.

    Tiger-striping on table rows

    Whether done with background images, DOM scripting or just adding classes to the markup, none of the techniques are as easy as using the nth-child pseudo-class:

    tr:nth-child(odd) { color: blue; }

    ‘Sliding Doors’

    Requires no extra mark-up but a lot of CSS jiggery-pokery, most of which could be avoided with multiple background images:

    li {
    background: url('image0.png') no-repeat left top,
     url('image1.png') no-repeat right top;
    }

    Rounded corners

    Which do you prefer: multiple lines of Javascript? Or a single line of CSS?

    div { border-radius: 1.5em; }

    Drop shadows

    Even the simplest solutions seem to rely on an extra image and plenty of CSS tweaks. CSS 3 resolves it with one declaration:

    img { box-shadow: 10px 10px 5px; }

    Of course, the problem is that perennial one: lack of support. No modern browser currently supports all of the examples shown above, and it will be many years before we can stop using the workarounds altogether. But I do look forward to the time when they become a secondary consideration – and to what extensive use of the new declarations reveals in terms of creating new workarounds to future problems.

Page 1 of 3:

Hosting by: