• 200721 Oct

    As we mentioned at the end of last month, the W3C have released a working draft of their first annual snapshot. The snapshots are intended to show which specs are stable enough to be considered part of the current state CSS.

    The 2007 snapshot is:

    The browser with the least support for the snapshot is, as you’ve probably already guessed, Internet Explorer. Opera has implemented all of the new selectors, but doesn’t yet have support for RGBA & HSL/A colours, which both the forthcoming Safari 3 (Webkit) and Firefox 3 (Gecko 1.9) have implemented. FF3 doesn’t do well with many of the new selectors, however, which Safari does.

    While it would be nice to have included text effects and backgrounds & borders in this snapshot, differing browser implementations means they’re just not ready yet.

    Even if this working draft becomes a recommendation shortly, no current or imminent browser fully supports the modules contained within; and with Firefox 3, Safari 3, and Opera 9.5 due for release over the next few months, it’s not impossible that none will do so until the latter half of next year. It could even be the case that IE.Next swoops in to beat the others!

    With the CSS Eleven set to provide feedback to the W3C over the next few months, the 2008 snapshot could be a little more adventurous than that of 2007.

  • 200718 Oct

    Here at css3.info we have a limited amount of resources, yet I’d like to push this site a little further then it’s already going, so I’m hoping you guys out there can help us out! What we need, are test cases for the different modules. The first that comes to mind, or actually was a request of Eric Seidel, Webkit developer: multi-column layout testcases.

    Our current preview page doesn’t match the last version of the module, and browsers like Safari 3 are catching up, so we need more tests of it! If you make a testcase which we publish you will of course receive full credit for it in the footer of such a testcase.

  • 200718 Sep

    Until the Advanced Layout and Grid Layout modules are implemented, we have to get by with the existing tricks of the trade. One of those is the use of faux columns, a background image which simulates equal-height columns. This is a good technique, but the drawback is that it only works with fixed-width columns.

    That problem was overcome with the advent of liquid faux columns, which uses some background-position trickery and a bit of maths to create a variable-width effect.

    With the (tentative) introduction of background-size in Safari and Opera, however, faux columns are about to become a lot easier; all you need to do is create a background image and assign a percentage value to background-size, allowing the image to expand or contract with its containing box.

    Take a look at this example (only tested in Safari 3 and Opera 9.5; may work in Konqueror 3.5.7 also). If you resize your browser window, the text and columns should maintain their proportions.

    The way this is done is with a simple PNG image; I’ve made it 1000px wide, with two coloured columns of 250px each, so that it’s easier to calculate column widths (25%,50%,25%).

    I’ve set this as the background-image on the html element, which has been assigned a width of 90%. Inside this there is a container div with a width of 100%, and my three columns with the widths set at the same ratio as the background image:

    <div id="container">
    	<div id="one">
    	</div>
    	<div id="two">
    	</div>
    	<div id="tre">
    	</div>
    </div>
    
    #container {
    position: relative;
    width: 100%;
    }
    #one {
    margin: 0 25%;
    }
    #two, #tre {
    position: absolute;
    top: 0;
    width: 25%;
    }
    #two { left: 0; }
    #tre { right: 0; }

    The html element has the background-size declaration applied to it, with a percentage value to make it liquid, using the browser-specific prefixes followed by the proposed declaration (for safety):

    html {
    background-image: url('opera_bg.png');
    -khtml-background-size: 100%;
    -o-background-size: 100%;
    -webkit-background-size: 90%;
    background-size: 100%;
    background-position: 50% 0;
    background-repeat: repeat-y;
    width: 90%;
    

    You’ll notice that the Webkit value is different from the others; during this test, it seems that Webkit obtains its width from the entire browser window, not from the containing element; therefore, we have to set this value to be equal to the width of the containing element. I haven’t tested this thoroughly yet, so I’m not sure if this is a persistent bug or if there’s something I’m doing wrong. Anyway, Opera 9.5 behaves as expected.

    After that I’ve added the background-position and background-repeat declarations; background-repeat to tile the image down the page, and background-position because Webkit seems to ignore the margin values and puts the image at top left of the browser window; this is only necessary if you’re centre-aligning your page.

    Apart from a little tidying up, that’s it; once the module becomes a recommendation and the browser-specific prefixes are dropped, it will require only a few lines of code for the simple effect. In the meantime, remember that this is for experimentation purposes only and shouldn’t be used in a live environment. This is just a sketch of the technique at the moment, and requires more testing.

  • 200705 Sep

    We’re busy here at css3.info! Our interview with H&kon was cool of course, but then Opera 9.5 was released and we had to update and add quite a few pages… Because all these pages were still static html, that was quite a bit of work. Tonight I took the time to move all of them into WordPress, and after I’d done that, I’ve refined the search function and results a bit, so it now shows the pages in the searches as well!

    We’ll probably be adding new preview pages in the coming days, I’ve already updated the existing ones which Opera 9.5 supports now (cool, cool stuff, you should really have a look at it).

    Ow and because of the many complaints about it, I removed the text-shadow from the text in the menu tabs.

  • 200704 Sep

    Here’s the concluding part of our interview with Håkon (you can read the first part here).

    1. Name the top five CSS3 features you’d like all major browsers to support in their next major release.

      Here’s some of my favorites:

      Also, we must not forget Generated content, and tables from CSS2.1. These are great features that still can’t be used due to lack of support from one browser.

    2. Do you think there should be a Acid3 that focuses on CSS3 features that designs want supported as soon as possible?

      Yes, I think it’s time for another Acid test — all major browsers but one (guess which one!) support Acid2 by now. I believe Acid3 should test CSS3 features that a critical mass of browsers can agree to implement. Also, it should probably test features from the upcoming HTML5 and the DOM.

    3. Do you have a favourite designer who you admire their work, either from a design or technical respect?

      I can’t give you one name. I often show designs from the CSS Zen garden when I give talks; I like many of them.

      I can name two favorite fonts designers, though: Ray Larabie and Dieter Steffmann.

    4. How do you think designers can get more involved with the CSS3 progress, to make sure features designed by designers themselves are added to the spec, instead of the features the spec writers might think are important? Is there a way this can be done without designers (many who don’t have much free time to spare) having to read through long mailing list histories and understanding a lot of very technical implementation details (I’m thinking such as having a appointed advisory board of designers for example that advise what features they want, and gather feedback from others, then the implementers can discuss this and come back with issues or start to draft specs for those features)?

      We’ve always encouraged designers to be part of the CSS Working Group, and there has always been strong designer presence in www-style. Many of the choices we’ve made along the way are based on input from designers. For example, you wouldn’t find Backgrounds and borders on top of my list if it hadn’t been for designers. The idea of an advisory board may be a good one.

    5. How do you feel about being nicknamed “the father of css”?

      I often refer to CSS as my baby, and I’m fine with being called the father :-) It must be emphasized, though, that the child was shaped by a community. Bert Bos was the first to join the efforts, he came with a proposal of his own that we worked into CSS. Thomas Reardon and Chris Wilson of Microsoft were also influential in the time before the CSS WG and and the www-style mailing list was started.

    6. What do you think of the Brazilian band CSS?

      Wow. Right. Change of mindset. Music, right? When it comes to music, I prefer Opera!

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

  • 200725 Jul

    Since the idea of CSS2.2 was raised, there’s been some discussion as to what it should encompass, who should be responsible for the spec, and what it should be called; here’s what I think:

    First, it doesn’t matter what it’s called. Whether it’s referred to as CSS2.2, CSS2.1+, CSS3 Interim, or whatever, makes no difference. It doesn’t need to have a name at all; the important thing is that we have it.

    Second, it doesn’t need to be an official recommendation from the W3C; in fact, it may be easier if it’s not. The optimal solution would be communication between developers and browser manufacturers, and – crucially – between the browser manufacturers themselves. What’s needed is an agreement as to which features are implemented, and to make sure those features are implemented in the same way; a de facto standard.

    Finally, what feature should it include? For me, it has to be the elements which have already been implemented and tested in at least one browser for an amount of time sufficient for developers to have used them.

    The most-requested feature is multiple background images; if you’re going to have that, background clip, origin and size would be wanted too. Border images would also be useful, as would an agreement on implementation of border radius.

    Opacity, and with it RGBA and HSLA, box shadow, and text shadow would round off the decorative declarations.

    Even if those few could be agreed on, a lot of workarounds could be avoided.

    I would have said that multi-column layouts were less urgent, but as they are already part of the Gecko engine and about to be introduced in Safari 3, it seems that that should be part of the standard. Media queries would be pretty necessary as we move into the mobile era, too.

    Nothing I’ve mentioned above would be unrealistic; most have already been implemented in at least two current or imminent browsers. As they are available, why are we being kept waiting before we can use them? Think of all the extraneous markup we could be freeing ourselves from!

    Come on, browser makers: open up lines of communication and get talking to one another; float the ideas on your company blogs, see what your readers have to say. There’s a whole big community of developers who love to download nightly builds and test new features, and are hungry to improve their pages.

  • 200710 Jul

    The Short Answer:

    None of it.

    The Slightly Longer Answer:

    I’m in the process of updating the Preview area at the moment (sneak preview), and what’s immediately apparent is the low level of implementation of the new CSS 3 features across the major browsers. As IE6 is still the most widely-used browser, roughly 50% (and, slowly, falling) of the market has next to no CSS 3 support at all. A sobering thought.

    With IE7 introducing support for attribute selectors, roughly 50% of the market can use those. You will still have to provide fall-back support for IE6, however, either with conditional comments or through graceful degradation.

    Next most-widely implemented property is opacity; with support in all the key browsers other than IE, perhaps 25% of site visitors will see this effect if you use it. Again, make sure that your designs degrade gracefully if tempted to add this to your code.

    After that, you can more or less forget it. The properties in the Backgrounds and Borders module have patchy implementation in browsers, and almost all use browser-specific prefixes, which you probably want to steer away from in a production environment as they are subject to change (see the border-radius conflict as a good example of why they are tricky to implement).

    text-shadow should gain support from Safari 3 and Opera 9.5, but even being generous that’s only around 5-10% of the market. Most of the other properties have little or no cross-browser support.

    What You Can Do About It:

    Get behind Andy Budd’s ‘CSS 2.2′ idea. Think about it. If you have a blog, discuss it there. Write to browser manufacturers and the W3C. We’re putting together a campaign website to promote the idea, so get in touch with us and offer support.

    We want – no, need – these new properties, to do away with many of the non-standard or non-semantic solutions we have to use today to provide complex solutions for simple problems. CSS 3 provides many of those solutions, but they won’t be implemented cross-browser until they become standard; that can be via the W3C, or a de facto standard agreed by browser manufacturers. But however that standard is made, it won’t happen unless there’s concerted pressure from the development community.

Page 3 of 6:

OUR SPONSORS

Advertise here?

Hosting by: