Entries tagged with ‘HTML’

Display:

Tags

  1. Quotation Marks & Texture

    Single quotation marks pattern.

    In the last entry, I stopped using double quotation marks and started using the single version. Some super-observant folks may have noticed but if you didn’t that’s also a good thing. Permit me to explain:

    The final test for running text is legibility, so failing to notice would mean the style was not imposing on the text. The texture was good. When they occur, stylistic interruptions provide me with food for thought. If the punctuation interrupts the meaning, it demands fresh scrutiny. Double quotation marks seemed to interrupt by emphasising too heavily. Emphasis is sometimes required, but to my mind, with my style of writing, it seemed to impose on the text, altering the meaning by changing the silent voice in my head reading the text.

    Legibility is subjective, and typographers can debate the nuances of style to achieve the best form until the end of time. However, context, typeface, and content are such varied beasts that trying to style them with one set of rules is unnatural, no matter how attractive it can seem. Whatever rules we follow, being consistent is a rule that’s truly universal. Knowing why we use a particular form is another. If we can’t justify a particular usage, the chances are we’ve probably not considered it enough.

    Context is important here. American English is the lingua franca of web design, from the properties of CSS, to the majority of text we read. The best-selling handbook of American writing style, The Elements of Style by Strunk and White, only provides examples with double quotation marks followed by singles for quotations within quotations:

    “This is a quotation with ‘another quotation’ inside it in the American style.”

    However, I’m British. I live and work in the UK. In the UK, double quotation marks are also used, but there’s also a tradition of single inverted commas being used as the primary, with double inverted commas contained within them as needed:

    ‘This is a quotation with “another quotation” inside it in the British style.’

    To my mind the latter imposes much less and suits me much better. I agree with book designer Jost Hochuli in Detail in Typography:

    ‘A more attractive appearance is achieved by using single quotation marks for the more frequently occurring quotations, and the double version for the less frequent occurrence of quotations within quotations.’

    Robert Bringhurst advises us to:

    ‘Consider the face as well as the text when deciding which convention to follow in marking quotations.’

    I agree with him but on the Web a face can change dramatically depending on the browser and operating system that’s rendering it. To my mind, we have to choose an optimal version — Safari in my case — and accept degradation after that. That’s also the case with other punctuation like spacing. I’ve just used hair spaces around the em dashes in the sentence before last, but you will see regular spaces unless you’re reading this using Safari — the only browser I know of that substitutes a hair space from the system fonts if one is not available from the specified face.

    Different languages also have different quotation marks like guillemets («»), and baseline inverted commas used as left quotation marks („); they are in common use in Germany, Russia, and Poland as Piotr Fedorczyk showed me recently. Punctuation within (or without) quotation marks is another topic altogether with a set of rules that depends on context and form. For example, American English puts commas inside. British English puts them outside depending on whether or not the comma (or full stop [period], or exclamation mark) is part of the quoted text.

    My view is, whatever style we choose, we should know why, and be prepared change it if necessary. Any rules we apply should aid legibility. Web typography is immature; the constraints and opportunities of the medium may take us down many different paths but the goal of legible, beautiful text is constant.

    Good typography in running text is subtle and ambient. It enhances the text without interrupting it. It delivers meaning with clarity. In books, speech is mainly quoted in single marks. It’s a light touch. The typography removes itself from the picture being painted in our minds, and by doing so, allows it to shine. I’d like to achieve the same kind of light touch, here. I doubt my text will shine, but at least the typography will not distract you from my thorny prose.

    Share

  2. Naked in Tahiti (where’s Ms CSS?)

    Naked!

    Naked again. Why, oh why every year do I feel the urge to cast off the perfidity of style and expose my structure to the world? A question never to be answered, but merely enjoyed on CSS naked day!

    Love my semanticness (sp?). Love my form, my structure, my HTML, your browser (which is actually styling the HTML right now,) and markup in general raw and unabridged.

    Hey, on an unrelated note, did I tell you about that time in The Seychelles when I was naked and kinda playing guitar with my…

    Oi! You have a filthy mind. Enjoy the day folks, long may the tradition continue!

    Share

  3. 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 services". 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

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

  5. Designer PHP: A Dynamic Menu with If and Else

    Recycling PHP and HTML

    In the simple PHP include article I covered how to re-use one file in many pages. If you’re new to using PHP, read that first. Now it’s time to make file includes a bit more useful. In this article, we’ll include one file for main navigation, but make individual menu items “live” depending on the page they appear on.

    This is an article in the “Designer PHP” series of guides to using PHP for interface production. Previously:

    1. A Simple Include

    To perform this feat, we need to do three things:

    1. Declare a variable on each page to tell the menu what markup to display.
    2. Create a file with “live” and regular markup for each menu item. Add PHP to enable us to switch the markup according to the variable.
    3. Include the menu on every page.

    Declare the PHP Variable

    The variable declaration must be in every page the menu will appear on. It must be before the line of code that includes the menu so the menu can pick it up. I would normally insert it above the <!DOCTYPE… to separate the PHP from my HTML as much as possible. This is the variable declaration for the home page:

    (This variable declaration or PHP statement has two key parts: The variable reference, or name $page, and the variable value "home".)

    <?php 
    $page = 'home'; 
    ?>
    <!DOCTYPE…
    
    1. The variable name $page does not change. You can change it to whatever you like, just make sure it’s the same on every page.
    2. The value 'home' will be different for each page to tell the menu what to display.

    I usually have the value match the area of the site, so in the example we’re building it will be 'home' on the home page, 'about' on the about page, and so on. You can change the value to whatever you like, and have as many values as you need for individual pages.

    Create the Menu File to be Included

    For our purposes, we’re going to create a dynamic menu for a fictitious site with three pages: “Home”, “About” and “Contact”. You can extend this to apply to as many pages as you like. This is the basic HTML for the menu:

    <div id="nav">
    <ul>
    <li><a href="index.php">Home</a></li>
    <li><a href="about.php">About</a></li>
    <li><a href="contact.php">Contact</a></li>
    </ul>
    </div>
    

    We want two different sets of markup for each menu item: “live” markup and regular markup. In this example we’re going to attach a class to the “live” item — <li class="live"> — and wrap the link in an <em> to differentiate it even if styles are disabled. For example, on the home page, the “live” home menu item will end up looking like this:

    <li class="live">
    <em><a href="index.php">Home</a></em>
    </li>
    

    To switch between “live” and regular markup, we will use PHP “if, and else statements”. This is the menu HTML with PHP:

    (White space and line breaks inserted for legibility. PHP is emphasised in red. Disable styles to see it in italics if you need to.)

    <div id="nav">
    <ul>
    
    <?php if ($page == 'home') { ?>
    <li class="live">
    <em><a href="index.php">Home</a></em>
    </li>
    <?php } else { ?>
    <li><a href="index.php">Home</a></li>
    <?php } ?>
    
    <?php if ($page == 'about') { ?>
    <li class="live">
    <em><a href="about.php">About</a></em>
    </li>
    <?php } else { ?>
    <li><a href="about.php">About</a></li>
    <?php } ?>
    
    <?php if ($page == 'contact') { ?>
    <li class="live">
    <em><a href="contact.php">Contact</a></em>
    </li>
    <?php } else { ?>
    <li><a href="contact.php">Contact</a></li>
    <?php } ?>
    
    </ul>
    </div>
    

    Copy the code to a new file in your editor. Save it as nav.php inside an inc directory in your site root.

    I have deliberately separated the PHP and HTML as much as possible. There are other ways to achieve the same result, but this removes PHP completely from within HTML tags, hopefully making it easier to read and edit.

    Let me explain what the PHP does: Each menu item is marked up in two different ways: the “live” version and a regular version. The variable we declared tells the PHP in the menu which to display. For example, if $page = 'home'; is declared, the if statement ( <?php if ($page == 'home') { ?> ) will display the “live” markup. If home is not declared then the <?php } else { ?> statement takes over, and the regular markup is displayed.

    To make any of the other menu items “live”, you adjust the variable. The menu picks it up and switches the HTML. Simple. That’s our menu created and ready for use. The next step is to include it on every page.

    Include the Menu

    To do this we use the same technique explained in the simple include article, except this time we’re including the menu file, which we’ve called nav.php. This is the PHP you need:

    <?php include 'inc/nav.php'; ?>
    

    Insert that in each page at the point you wish the menu to be displayed. The path ( 'inc/nav.php' ) pointing to the nav.php file is relative — make sure you change it if your pages are not all in the site root. Each of your site pages will now look something like this (with the variable value * edited as required):

    <?php 
    $page='*'; 
    ?>
    <!DOCTYPE… >
    <html>
    <head>… </head>
    <body>
    
    <?php include 'inc/nav.php'; ?>
    
    …content
    
    </body>
    </html>
    

    That’s all! Now you can get to the fun bit of styling your menu with CSS. If you need to change anything, you simply edit the nav.php file and every page will be updated. Easy, isn’t it? Let’s end with a few tips about errors and security.

    PHP Error Debugging

    If you get a heap of PHP errors on a page instead of the menu, the chances are your include file path is wrong. Check it is pointing correctly to nav.php from the location of the page calling it.

    It’s useful to know that you can navigate straight to the include file directly in your browser and see the markup.

    (E.g. http://yoursite.com/inc/nav.php)

    If the file path is wrong, you will get a 404 error.

    If no menu items are active, or one is incorrectly active in a certain page, check the variable declared at the top of the page. Does it match the on in the if condition that precedes the item you want “live” in nav.php?

    If you’ve done all that, and you’re still having problems, check your syntax line by line. The chances are you’ve missed a tiny mistake. It’s a pain but a good way to learn.

    Security

    I grabbed a moment with web application security guru, Chris Shiflett to have him check my PHP. This is what he said:

    Whenever you’re working with a server-side programming language such as PHP, it’s good to be aware of potential security problems, because a simple mistake is all it takes to create one. If you follow Jon’s example, you’re safe, but what happens when you need to modify it to suit your own unique needs?

    Rather than complicate a wonderful tutorial, I’ll just point out that you should research further before doing either of the following:

    1. Add any additional PHP code to your includes.
    2. Use a variable in your include statement, e.g. include "inc/$template".

    If you need to do either of the above, you should first read a little more about remote code execution.

    Further Reading

    Control structures on PHP.net

    Can You Translate?

    After a wonderful response to the em and elastic layout article, I’d love to hear from anyone who’d like to translate this, or any other article in the series. I’ll be happy to host your work, like the previous Italian translation, or you’re welcome to publish it yourself. Just drop me a line.

    Share

  6. Designer PHP: A Simple Include

    Years ago I was introduced to PHP. Since then, using simple PHP includes has saved me huge amounts of time in revising and editing HTML, so I thought I’d share some basic tips and hopefully save you some time, too.

    This is the first article in a series of basic designers’ guides to using PHP for interface production.

    Including CSS style sheets, JavaScript files, and image files in HTML pages will be familiar to most people. PHP includes work in a similar way: Create one file with a chunk of HTML in it (like a menu or a footer) and include it in multiple pages using a bit of PHP. Change the contents of that one file and every page that includes it displays the change. Sexy, eh? Let’s get started:

    What is PHP?

    In case you don’t already know: PHP is a programming language that works on the server—server-side scripting—in much the same way that JavaScript works in the browser (“client-side scripting”).

    All good hosting services have PHP installed on the server. You can find out what version and modules you have installed using phpinfo(). PHP also powers many of the most popular sites in the world. However, all we need to know for our simple purpose is this:

    PHP allows us to create a single file on the server, and include the contents of that file in multiple pages before they are delivered to the browser.

    Creating PHP Files

    Make sure your hosting service supports PHP. Then, instead of saving your site files with a .html or .htm extension, save them with a .php extension. They won’t render any differently in the browser, the extension just tells the server that the file may contain PHP which will need to be executed before the file is served.

    Before creating PHP includes, I usually create the first page of a site in the normal way, but save it as .php. I only pull chunks of HTML out to includes when I start building other pages in the information architecture.

    Example: A Regular HTML Footer

    Web sites usually have a footer that is constant across all pages making it perfect to be included using PHP. This is a simplified example of a regular page with the footer included inline as usual:

    <!DOCTYPE… >
    <html>
    <head>… </head>
    <body>
    
    …main content
    
    <div id="footer">
    …footer contents
    </div>
    
    </body>
    </html>
    

    Making the Footer a PHP Include

    1. Create a directory in your site root called inc to contain all of your includes and keep your files organised.
    2. Remove the whole of the footer markup and paste it into a new file in your editor. Save that file to the inc directory as footer.php (it can be whatever you wish).
    3. In the regular site pages, where the footer would usually be, replace it with a bit of PHP to include the footer.php file:
    <?php include ("inc/footer.php"); ?>
    

    Important: The file path ("inc/footer.php") is relative to the location of the page including it — make sure it points to the right place from any given page in your site.

    With that bit of PHP in your pages, the footer.php will be included in the page at that place.

    Change the markup in footer.php and it will change for every page where you have included it. Now, when you need to change the date in the footer to include the new year, or change anything about it, you only have to change it once in the include. That’s it! You can make any bit of markup an include.

    More Complex Includes

    PHP becomes even more useful for designers when the state of HTML objects needs to change depending on what page they appear in. For example, the markup and style of main navigation items will change to indicate which item is active. I often apply a class and either disable a link or wrap it in <em> tags. You can do all that in a single menu include. In the next article I’ll show you how. In the meantime, if this is new to you but you’re enthused by it, take a look at if/else statements yourself.

    Further Reading

    1. PHP tutorial from PHP.net
    2. PHP introduction from W3schools

    Share