• 200719 Jun

    With the release of Safari 3, there are now two browsers with (browser-specific) implementations of border-radius; unfortunately, the two implementations are different. The problem is that there is an unresolved ambiguity in the CSS 3 working draft.

    The draft proposes four declarations, which describe the four corners of a block:

    border-top-left-radius
    border-top-right-radius
    border-bottom-right-radius
    border-bottom-left-radius

    Each of them should accept two values, which define the radii of a quarter ellipse that defines the shape of the corner; this allows for irregular curves (take a look at the diagram in the draft if you need clarification, or see this example of a box with border-radius: 5px 20px, horribly rendered in Safari for Windows).

    Safari, with the prefix -webkit-, accepts these. Mozilla, with the prefix -moz- (and differing declarations), accepts only a single value and, therefore, only regular curves.

    At first glance, it would appear that Mozilla are in the wrong; however, their implementation is due to the ambiguity I mentioned earlier.

    This ambiguity comes about in the border-radius shorthand property; if you enter a double value in this you’d expect to apply the irregular curves to all four corners:

    border-radius: 5px 10px;

    If you wanted to have four different irregular curves on the box, you’d have to provide eight values to the declaration:

    border-radius: 5px 20px 10px 5px 10px 20px 20px 5px;

    But what if you wanted to have two corners with one value, and two corners with a different value?

    border-radius: 5px 10px 10px 20px;

    The problem is that this could be confused for four corners with regular curves. In order to get around this, you’d still have to provide eight values:

    border-radius: 5px 5px 10px 10px 10px 10px 20px 20px;

    In fact, from the brief testing I’ve done (and I can’t find any documentation), it seems you can’t do any of that; unless I’m missing something, the shorthand declaration in Safari accepts only 1 or 2 values, to provide either regular or irregular curves which are applied to all four corners. If you want different irregular corners, you have to supply values to all four declarations:

    border-top-left-radius: 5px 20px;
    border-top-right-radius: 10px 5px;
    border-bottom-right-radius:  10px 20px;
    border-bottom-left-radius:  20px 5px;

    Mozilla avoid this by going against the spec and allowing only regular curves; so you can provide 1, 2, 3 or 4 values and it’s all perfectly clear.

    This problem is down to interpretation of the draft. I personally think Mozilla’s non-standard solution is better – it’s less flexible, but easier to understand – but can’t blame the Safari team for following the standard in their implementation.

    It will be interesting to see which comes out on top; in the meantime, if you want to use border-radius in your code the only way to get them to appear the same on both browsers is with a single value for four regular corners:

    -moz-border-radius: 10px;
    -webkit-border-radius: 10px;
  • 200722 Mar

    After the issue of the overhauled CSS3 Text module recently, I wonder if the Fonts module is due for similar treatment? The current working draft states:

    The working group believes this draft is stable and it therefore issues a last call for comments, before requesting the status of Candidate Recommendation for the draft. The deadline for comments is 30 August 2002.

    Four and a half years ago! That’s a long feedback process!

    The module introduces a few new features into the coder’s lexicon, and although none of them are truly essential, they would be very useful; there is so much text on the web, but typography is the least-developed aspect of CSS.

    font-size-adjust lets you preserve the height of type even if the user doesn’t have your first-choice font installed. Certain fonts have higher height aspect than others, so type that you’ve carefully styled to appear at a certain height could suddenly appear smaller if font substitution was used. font-size-adjust let’s you overcome that problem. The module provides some examples of font height aspects.

    font-stretch is useful when displaying font families with condensed or extended faces, such as Arial. You can select absolute (condensed, extended, etc) or relative (narrower, wider) values.

    font-effect allows you to apply ‘special effects’ to your font; choose from embossed, engraved, or outlined text.

    font-smooth switches anti-aliasing on or off. Fonts look so ugly without anti-aliasing, I can’t imagine a situation where you’d ever turn it off!

    Finally, three declarations with limited use outside of East Asia: font-emphasize-style and font-emphasize-position, along with the shorthand font-emphasize. These are used only to set emphasis on East Asian characters.

    Will this module make it to recommendation in this form? Or will it make a comeback in altered form? I suspect the latter. But I think the most radical change to web typography will come not from the implementation of this module, but from the implementation of @font-face, which will facilitate the use of non-core fonts.

    By the way, anyone interested in web typography should, if they haven’t already, read Richard Rutter and Mark Boulton’s Web Typography Sucks presentation. It’s a 4MB PDF download, but well worth ten minutes of your time.

  • 200707 Mar

    Back in May 2003, the CSS3 Text Module made it to Candidate Recommendation status, meaning:

    [The] W3C believes the specification is ready to be implemented.

    Before it made the next step to Proposed Recommendation status, however, it was decided that a complete overhaul was needed. Four years later, and the renamed CSS Text Level 3 has been issued as a Working Draft.

    This module:

    … defines properties for text manipulation and specifies their processing model. It covers line breaking, justification and alignment, white space handling, text decoration and text transformation.

    This is still a very rough document, with some intended declarations not defined yet – text-overflow, for example. You can see how it differs from the previous version with this list of changes.

  • 200610 Nov

    It’s all gone a bit quiet round here… sorry about that, but there’s not a lot of movement on CSS3, and I know the authors here are quite busy personally.

    Anyway, potentially big news is that the WHATWG are asking for developer feedback on HTML5.

    I’m still wading through the document, but of what I’ve read so far, of most interest to CSS fanatics will be a group of new, semantic tags; for example

    ,

    Of course these aren’t directly related to CSS3, but it should help save a lot of classes, ids and tag soup if implemented – and that’s the key. Even if it turns into a recommendation, how long until HTML5 is supported in IE – if at all. Many questions, many variables; but stay positive, and give your opinion.

Page 5 of 6:

Hosting by: