Entries tagged with ‘standards’

Display:

Tags

  1. Typographers, lend me your pain

    Dear web typographers and designers, I need your help (and your woes!) A couple of days back, Jason Teague, Director of Web Design for AOL Global Programming and member of the W3C CSS3 Working Group made a request for input from designers around the CSS fonts and CSS web fonts modules. He has volunteered to be an advocate for them, and wants our thoughts and feedback on the way forward. It’s a welcome move, and a veritable bag of snakes he’s opening, so congratulations to Jason for volunteering to take the pain. I think we should help him out.

    CSS

    For my part, I’m planning to respond in detail, supported by a few test cases and examples of current rendering. Wish lists are great, but I think empirical evidence is more useful when identifying current issues and areas for improvement in the recommendations. So, if you’re a web typographer or designer and have come across problems or issues that might be worth cataloging, let me know what they are. I’ll promise to try and put together a test case and convert anecdotes to science if I’m able. Alternatively, you can just throw your thoughts into the comments for Jason’s article.

    As an example of what I think might be useful, I’m planning on discussing classic type setting techniques that are either badly supported or absent like old-style versus lining versus small-cap numerals, raised or drop caps, granular glyph weights, ligatures, baseline fixing, etc. I’ll also be mentioning browser-specific hacks I use to achieve better rendering like setting a miniscule opacity value in Firefox on OSX to de-bloat the glyphs and improve larger-size anti-aliasing.

    What do you think?

    Share

  2. Preparing for HTML5 with Semantic Class Names

    HTML 5 DOCTYPE

    Some time ago I was asked in an interview whether I preferred HTML or CSS. It was a bit like being asked if I prefer pens or pencils. I made an instinctive choice. I chose HTML. It’s the typography of data; the inflection in our voices; the grid of meaning upon which presentation can flourish. I find it beautiful when done well, and that’s why watching HTML 5 unfold with new and refined elements is fascinating to me.

    This is a brief introduction to the new structural elements in the HTML 5 Working Draft, and how to use semantic class names in HTML 4.01 or XHTML 1.0 markup that correspond to the names of those structural elements. By doing so, you’ll get a head start in understanding how to use the new elements and also go some way towards using plain old semantic HTML if you’re not already.

    i. Introduction

    HTML 5 will be the first major change to our lingua franca since XHTML 1.0 in 2000; some might say HTML 4.01 in 1999. You’ve probably already seen the HTML 5 Working Draft of the 22nd January this year. The W3C HTML Working Group and WHATWG have been grafting away on our behalf, and trying to satisfy everyone in an open process. Not an easy task. Sometimes, amongst the concerns and the questions it’s easy to forget that, so I’m taking a brief second in between sips of coffee to acknowledge the hard work. Thanks, folks.

    Let’s get to know these new structural elements a little better. If you’d rather go straight to the horse’s mouth before continuing I recommend a comfy chair, and a perusal of HTML 5 differences from HTML 4, edited by Anne van Kesteren. W3C documents seem to be getting easier to read, and this is no exception. If you’re sticking with me for a while, let’s get to it:

    ii. The <header> Element

    The header element is for page or section headings. Not to be confused with a traditional masthead, which often holds just a logo mark, it should also contain one of <h1><h6> in hierarchical rank. It could also contain meta information for that page or section of a page like “last updated”, a version number, or blog entry information like published date, author, etc.

    A simple example for a page using a semantic class name that corresponds to the HTML 5 header might be:

    <div class="header">
    <h1>Page Title</h1>
    </div>
    

    You could include the logo mark and other meta information within the layer. The next example for blog articles includes author and published date information (as well as an example of referencing the section and article elements with semantic class names):

    <div class="section">
    
    <div class="article">
    
    <div class="header">
    <h1>Page Title</h1>
    <p>By <a href="*">Author</a> on [date]</p>
    </div>
    
    [Article content…]
    
    </div>
    
    <div class="article">
    [Repeat as required…]
    </div>
    
    </div>
    

    iii. The <nav> Element

    The nav element should contain a set of navigation links, either to other pages, or fragment identifiers in the current page. Referencing it with semantic class names is simple:

    <div class="nav">
    <ul>
    <li><a href="*">Menu item 1</a></li>
    <li><a href="*">Menu item 2</a></li>
    [Repeat as required…]
    </ul>
    </div>
    

    iv. The <section> Element

    A section element defines a section of a page or a distinct piece of content. It would ordinarily have a header and possibly a footer. This is how we could represent it using semantic class names:

    <div class="section">
    
    <div class="header">
    <h2>Section Title</h2>
    </div>
    
    [Section content…]
    
    </div>
    

    I’ve also been using <div class="section"> to define a group of layers that are related (like news and events). In such an example, those sub-sections would be nested, each with their own <h1><h6> in rank order to maintain heirarchy. For example:

    <div class="section">
    
    <div class="header">
    <h2>News and Events</h2>
    <p>The latest announcements and upcoming conferences</p>
    </div>
    
    <div class="section">
    <h3>News</h3>
    [Section content…]
    </div>
    
    <div class="section">
    <h3>Events</h3>
    [Section content…]
    </div>
    
    </div>
    

    Each section could also have a layer with a semantic class name of header if the content made it necessary.

    v. The <article> Element

    This is how the HTML 5 working draft explains article element:

    “The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.”

    Multiple article elements can also be nested. We looked at the example of a series of blog posts using semantic class names in the header section. This is an example using semantic class names in a unique article page with header and footer:

    <body>
    
    <div class="article">
    
    <div class="header">
    <h1>Title</h1>
    </div>
    
    [Article content…]
    
    <div class="footer">
    [Footer content…]
    </div>
    
    </div>
    
    </body>
    

    vi. The <figure> Element

    The figure element contains embedded media like <img> and the new elements of <audio> and <video>. It also contains an optional <legend> element performing the function of a caption. Our semantic class name version could be like so:

    <div class="figure">
    
    <img src="*" alt="*">
    
    <p class="legend">[…]</p>
    
    </div>
    

    vii. The <dialog> Element

    The dialog element replaces a <dl> to contain converations like transcripts. Using it as a semantic class name is straightforward:

    <dl class="dialog">
    
    <dt>Speaker 1</dt>
    <dd>So I said to him, I said…</dd>
    
    <dt>Speaker 2</dt>
    <dd>You never. You did? Oh my…</dd>
    
    </dl>
    

    viii. The <aside> Element

    To quote the working draft:

    “The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.”

    I’ve been using “aside” as a class name for sidebars with mixed content, but my reading of the draft also indicates it may also be appropriate for pull-quotes and anything partially related to the main content, but not of it. See the sections relating to the ins and img elements for examples. It woud seem appropriate to use it with a semantic class name like this:

    <body>
    
    <div class="section">
    [Section content…]
    </div>
    
    [Repeat sections as required for main content…]
    
    <div class="aside">
    [Aside content…]
    </div>
    
    <div class="footer">
    [Footer content…]
    </div>
    
    </body>
    

    This is what the working draft has to say:

    “The footer element represents the footer for the section it applies to. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.”

    In the changed elements section of HTML 5 differences from HTML 4, it also explains that, “The address element is now scoped by the new concept of sectioning.” This is important, because now, if you have multiple sections in a page, each can have both a header and a footer with a corresponding address in the footer for each if you deem it necessary. However, that would seem to be a rare use-case. Let’s stick with a more common one: A single footer for each page with a single address element; here’s how it might be done using a semantic class name:

    <div class="footer">
    
    <address>[…]</address>
    
    [Other footer content …]
    
    </div>
    

    x. Multiple Class Names

    Let’s recap a little: By using semantic class names, we give the information a semantic boost, and each chunk of related data is self-contained. However, it may have become obvious to some designers reading this that a side-effect of using this method, and eventually using HTML 5 elements themselves, will be lots of different content within containers of the same name. <div class="section">, for example. You might want to present different content very differently in the browser. Multiple class names will enable you to do that. class="section" can becomes class="section news", or class="section sevices". The "section" class name allows us to standardise some of the presentation; say, typography for example. The "news" class name will allow us to present it differently as a section variant.

    So now we have the best of both worlds; the critical structural elements are included by default with more semantic class names providing hooks to apply our creativity to.

    xi. End Notes

    Bear in mind HTML 5 is a working draft so there will probably be some changes before it becomes a recommendation. It would seem unlikely that any of the new structural elements will be removed, but a sharp eye on the draft updates might be a good move.

    Any errors in this article are my own. If you some across any, please let me know and I’ll make corrections.

    xii. References & Further Reading

    1. References:
      1. HTML 5 Working Draft
      2. HTML 5 differences from HTML 4 and specifically, the new structural elements section
      3. Semantic class names
      4. Plain old semantic HTML (POSH)
      5. <header>
      6. <nav>
      7. <section>
      8. <article>
      9. <figure>
      10. <dialog>
      11. <aside>
      12. <footer>
    2. Further Reading:
      1. A Preview of HTML 5 on A List Apart by Lachlan Hunt
      2. HTML 5 Latest Working Draft at WHATWG
      3. WHATWG on Twitter
      4. W3C HTML Working Group

    Share

  3. Adios, IE8 Meta Mayhem!

    I’ve been holding back on a comment on the recent furor about the IE8 meta http-equiv switch. Mainly because the great and the good had it covered, but also because there was already a possible workaround, which John Resig pointed out: Use a HTML5 DOCTYPE.

    Dean Hachamovitch and the IE team put out the fire yesterday with a switch of their own:

    “We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can.”

    Great news! Now the legacy application vendors using IE as the platform, and relying on less-than-perfect rendering will bear the burden of telling IE which rendering engine they need. (Another radical idea might be for folks who are refactoring applications to use conditional comments like any good self-respecting developer should.) At least, with this announcement, the folks producing standards-driven code will not face the bizarre requirement of having to tell IE8 to not use IE7’s rendering engine. Makes sense to me guys, what took you so long? OK, the problem is more complex than that. After all, as Nigel Parker of Microsoft pointed out in his follow-up post to Kiwi Baacamp where he entered the debate:

    “Microsoft’s view [is] to support backwards compatibility for at least 10 years…”

    By anyone’s measure that’s a hefty commitment, and probably leads the field for backwards compatibility. Even more so when you consider that most new “killer apps” are targeted at the cool kids using the latest OS or browser, and often don’t work without Javascript. (Nudge, nudge Twitter.) A fact that always concerns me when you consider that “universality” is at risk of becoming a hackneyed word, and there’s a whole world out there getting online, often with less money than we spend on Starbucks, and the equipment to prove it.

    Anyway, I digress. Congratulations to the IE team and the collective intelligence in our community for reaching scientific solutions, intuitively. It just goes to show all the cynics out there that, as well a flaming each other, we also have a rare capacity for collectively recognising Robert M Pirsig’s metaphysics of quality.

    Share

  4. What Future for Web Typography & Screen Fonts?

    The browser wars of yesteryear were a frustrating period for anyone working on the Web. We’ve come a long way since then. Following the vanguard of Opera, Safari and Firefox, IE8 will be the first Microsoft browser to pass the ACID2 test when it’s released in 2008. Congratulations to the IE team! 2008 may well be a seminal year for Web standards.

    However, the same might not be said for Web fonts. While we have commonly supported standards with which to author information for the Web, we still only have ten core Web fonts to present it, with six most commonly used. There are hundreds if not thousands of outstanding typefaces. A few are shipped by Microsoft, Apple and Adobe with their software, allowing us to use them with font stacks. That leaves a multitude of beautiful, important typefaces that can only be used as text in images or with kludges like sIFR. The current situation is like the browser wars, or perhaps, the type wars.

    In a world where the Web is the platform, having ten core Web fonts makes no sense. It stifles innovation in the same way that poor Web standards support used to.

    The core Web fonts, then & now

    The Microsoft core Web fonts project was started in 1996 and discontinued in 2002. To put that in context, 1996 was the same year that Internet Explorer 3 was released with a CSS gallery to test IE3’s first tentative implementation of W3C CSS.

    Today, the core Web fonts remain in stasis. Apple have renewed the license with Microsoft this year but there are no plans to expand either the typefaces or the font variants. Back in 2006, Andrei Herasimchuk made an excellent proposal closely followed by Jeff Croft’s own worthy suggestion, both of which have unfortunately not come to fruition.

    Other Web fonts with @font-face

    More recently, Web fonts and the @font-face CSS property have come into focus. Håkon Wium Lie’s article on A List Apart started some valuable discussions. Ascender also recently announced new licensing for Microsoft faces which could apply to downloads, and the observations of people like Richard Rutter give us all hope for the future.

    However, as people have already mentioned, @font-face support is not a reality yet and there are questions over support across platforms that have not been addressed. Think mobile phones for example. End-user license agreements (EULAs) will need careful consideration and the methods of protecting type designers’ and foundries’ rights are still a matter for debate.

    Universal Web Type

    If the Web is the platform, and browsers are the gateways to it, then we don’t just need standards for layout and object rendering, but also a standard type library that is universally available to all, with a mechanism to allow new faces to be added over time.

    This is not an alternative to @font-face—there will always be a place for very specialist typefaces for specific uses—but it is a compliment to it.

    I would like to invite you to contribute how you think this might work. This is how I see it:

    1. Organisation: We should form a grass roots organisation to provide universal Web type. It could be part of, or complimentary to the Web Standards Project and the W3C. It would reach out to, and include anyone who has a stake in implementing, creating or using Web fonts.
    2. Structure: The organisation should be co-operative and democratic, with membership open to all. Intellectual copyright and assets would be jointly held by the group on behalf of everyone.
    3. Purpose: The group would strive to find common ground between all stakeholders to research or support common standards, find funding to create a font library with complete typefaces that would be freely distributed.

    The group could be funded by a mixture of micro-finance, donations of time and money, public funding and sponsorship. It would also affirm the right of type designers to proper remuneration for their work, and foster recognition of type’s importance to the Web.

    I’m deliberately publishing this idea to elicit your feedback and comments. The way forward is not clear, and I do not claim to have the answers, but I believe that between all the interested parties—whether individuals, companies or organisations—we have the ability to give everyone a better typographic experience.

    Share

  5. Opera sues Microsoft over Web standards in the EU Court

    Opera and Operati, I love you! There’s a crate of cider at my place if you want to swing by and pick it up. Yesterday, Opera filed an anti-trust complaint in the EU court against Microsoft:

    First, it requests the Commission to obligate Microsoft to unbundle Internet Explorer from Windows and/or carry alternative browsers pre-installed on the desktop. Second, it asks the European Commission to require Microsoft to follow fundamental and open Web standards accepted by the Web-authoring communities.

    Read the Opera press release and treat yourself to a smile. They rely in part on the recent decision taken by the court against Microsoft over bundling MediaPlayer with Windows. Opera accuses Microsoft of stifling innovation by embedding a browser than does not support Web standards as it should. All true. How many compromises, hacks and tweaks have we made over the years for Billy Gate’s browser?

    Of course, if this suit was successful Opera would have a better opportunity to grab themselves some market share. Good on ’em. If Opera had a stripped down version of the browser, but with tools akin to Firebug or Chris Pederick’s Web developer toolbar it would be my primary browser, right now.

    Co-incidentally, I’m just about to pay Microsoft for the priviledge of a new copy of WinXP, all because I can’t run multiple copies of IE for testing on Vista easily. Imagine a world where we could run multiple versions of IE without clever hacks. A world where IE passed the Acid2 Test (like Opera) and conditional comments and IE specific style-sheets became a relic of history. I’m almost salivating at the thought.

    There’s a long way to go before that happens. I’d like to think that Billy’s browser would of made it to the point of goodness regardless but, if Opera’s action helps it along, so much the better. It’s just a shame these kinds of actions seem necessary. Then again, Kim Stanley Robinson’s idea of revolutions by law in Pacific Edge always seemed much more preferable than any other method.

    Good luck to them!

    Share