{"rowid": 133, "title": "Gravity-Defying Page Corners", "contents": "While working on Stikkit, a \u201cpage curl\u201d came to be.\nNot being as crafty as Veerle, you see.\nI fired up Photoshop to see what could be.\n\u201cAnother copy is running on the network\u201c \u2026 oopsie.\n\nWith license issues sorted out and a concept in mind\nI set out to create something flexible and refined.\nOne background image and code that is sure to be lean.\nA simple solution for lazy people like me.\n\nThe curl I\u2019ll be showing isn\u2019t a curl at all.\nIt\u2019s simply a gradient that\u2019s 18 pixels tall.\nWith a fade to the left that\u2019s diagonally aligned\nand a small fade on the right that keeps the illusion defined.\n\n\n\nCreate a selection with the marquee tool (keeping in mind a reasonable minimum width) and drag a gradient (black to transparent) from top to bottom.\n\n\n\nNow drag a gradient (the background color of the page to transparent) from the bottom left corner to the top right corner.\n\n\n\nFinally, drag another gradient from the right edge towards the center, about 20 pixels or so.\n\nBut the top is flat and can be positioned precisely\njust under the bottom right edge very nicely.\nAnd there it will sit, never ever to be busted\nby varying sizes of text when adjusted.\n\n
\n\t
\n\t\t

Gravity-Defying!

\n\t\t

Lorem ipsum dolor ...

\n\t
\n
\n\nLet\u2019s dive into code and in the markup you\u2019ll see\n\u201cis that an extra div?\u201d \u2026 please don\u2019t kill me?\nThe #page div sets the width and bottom padding\nwhose height is equal to the shadow we\u2019re adding.\n\n\n\nThe #page-contents div will set padding in ems\nto scale with the text size the user intends.\nThe background color will be added here too\nbut not overlapping the shadow where #page\u2019s padding makes room.\n\nA simple technique that you may find amusing\nis to substitute a PNG for the GIF I was using.\nFor that would be crafty and future-proof, too.\nThe page curl could sit on any background hue.\n\nI hope you\u2019ve enjoyed this easy little trick.\nIt\u2019s hardly earth-shattering, and arguably slick.\nBut it could come in handy, you just never know.\nHappy Holidays! And pleasant dreams of web three point oh.", "year": "2006", "author": "Dan Cederholm", "author_slug": "dancederholm", "published": "2006-12-24T00:00:00+00:00", "url": "https://24ways.org/2006/gravity-defying-page-corners/", "topic": "design"} {"rowid": 137, "title": "Cheating Color", "contents": "Have you ever been strapped to use specific colors outlined in a branding guide? Felt restricted because those colors ended up being too light or dark for the way you want to use them?\n\nHere\u2019s the solution: throw out your brand guide.\n\ngasp!\n\nOK, don\u2019t throw it out. Just put it in a drawer for a few minutes.\n\nBranding Guides be Damned\n\nWhen dealing with color on screen, it\u2019s easy to get caught up in literal values from hex colors, you can cheat colors ever so slightly to achieve the right optical value. This is especially prevalent when trying to bring a company\u2019s identity colors to a screen design. Because the most important idea behind a brand guide is to help a company maintain the visual integrity of their business, consider hex numbers to be guidelines rather than law. Once you are familiar enough with the colors your company uses, you can start to flex them a bit, and take a few liberties.\n\nThis is a quick method for cheating to get the color you really want. With a little sleight of design, we can swap a color that might be part of your identity guidelines, with one that works better optically, and no one will be the wiser!\n\nColor is a Wily Beast\n\nThis might be hard: You might have to break out of the idea that a color can only be made using one method. Color is fluid. It interacts and changes based on its surroundings. Some colors can appear lighter or darker based on what color they appear on or next to. The RGB gamut is additive color, and as such, has a tendency to push contrast in the direction that objects may already be leaning\u2014increasing the contrast of light colors on dark colors and decreasing the contrast of light on light. Obviously, because we are talking about monitors here, these aren\u2019t hard and fast rules.\n\nCheat and Feel Good About It\n\nOn a light background, when you have a large element of a light color, a small element of the same color will appear lighter.\n\nEnter our fake company: Double Dagger. They manufacture footnotes. Take a look at Fig. 1 below. The logo (Double Dagger), rule, and small text are all #6699CC. Because the logo so large, we get a good sense of the light blue color. Unfortunately, the rule and small text beneath it feel much lighter because we can\u2019t create enough contrast with such small shapes in that color.\n\nNow take a look at Fig. 2. Our logo is still #6699CC, but now the rule and smaller text have been cheated to #4477BB, effectively giving us the same optical color that we used in the logo. You will find that we get a better sense of the light blue, and the added benefit of more contrast for our text. Doesn\u2019t that feel good?\n\n\n\nConversely, when you have a large element of a dark color, a small element of the same color will appear darker.\n\nLet\u2019s look at Fig. 3 below. Double Dagger has decided to change its identity colors from blue to red. In Fig. 3, our logo, rule, and small text are all #330000, a very dark red. If you look at the rule and small text below the logo, you will notice that they seem dark enough to be confused with black. The dark red can\u2019t be sustained by the smaller shapes. Now let\u2019s look at Fig. 4. The logo is still #33000, but we\u2019ve now cheated the rule and smaller text to #550000. This gives us a better sense of a red, but preserves the dark and moody direction the company has taken.\n\n\n\nBut we\u2019ve only touched on color against a white background. For colors against a darker background, you may find lighter colors work fine, but darker colors need to be cheated a bit to the lighter side in order to reach a good optical equivalent. Take a look below at Fig. 5 and Fig. 6. Both use the same exact corresponding colors as Fig. 1 and Fig. 2 above, but now they are set against a dark background. Where the blue used in Fig. 1 above was too light for the smaller elements, we find it is just right for them in Fig. 5, and the darker blue we used in Fig. 2 has now proven too dark for a dark background, as evidenced in Fig. 6.\n\n\n\nYour mileage may vary, and this may not be applicable in all situations, but consider it to be just another tool on your utility belt for dealing with color problems.", "year": "2006", "author": "Jason Santa Maria", "author_slug": "jasonsantamaria", "published": "2006-12-23T00:00:00+00:00", "url": "https://24ways.org/2006/cheating-color/", "topic": "design"} {"rowid": 134, "title": "Photographic Palettes", "contents": "How many times have you seen a colour combination that just worked, a match so perfect that it just seems obvious? \n\nNow, how many times do you come up with those in your own work? A perfect palette looks easy when it\u2019s done right, but it\u2019s often maddeningly difficult and time-consuming to accomplish.\n\nChoosing effective colour schemes will always be more art than science, but there are things you can do that will make coming up with that oh-so-smooth palette just a little a bit easier. A simple trick that can lead to incredibly gratifying results lies in finding a strong photograph and sampling out particularly harmonious colours.\n\nPhoto Selection\n\nNot all photos are created equal. You certainly want to start with imagery that fits the eventual tone you\u2019re attempting to create. A well-lit photo of flowers might lead to a poor colour scheme for a funeral parlour\u2019s web site, for example. It\u2019s worth thinking about what you\u2019re trying to say in advance, and finding a photo that lends itself to your message.\n\nAs a general rule of thumb, photos that have a lot of neutral or de-saturated tones with one or two strong colours make for the best palette; bright and multi-coloured photos are harder to derive pleasing results from. Let\u2019s start with a relatively neutral image.\n\nSampling\n\n\n\nIn the above example, I\u2019ve surrounded the photo with three different background colours directly sampled from the photo itself. Moving from left to right, you can see how each of the sampled colours is from an area of increasingly smaller coverage within the photo, and yet there\u2019s still a strong harmony between the photo and the background image. I don\u2019t really need to pick the big obvious colours from the photo to create that match, I can easily concentrate on more interesting colours that might work better for what I intend.\n\nUsing a similar palette, let\u2019s apply those colour choices to a more interesting layout:\n\n\n\nIn this mini-layout, I\u2019ve re-used the same tan colour from the previous middle image as a background, and sampled out a nicely matching colour for the top and bottom overlays, as well as the two different text colours. Because these colours all fall within a narrow range, the overall balance is harmonious.\n\nWhat if I want to try something a little more daring? I have a photo of stacked chairs of all different colours, and I\u2019d like to use a few more of those. No problem, provided I watch my colour contrast:\n\n\n\nThough it uses varying shades of red, green, and yellow, this palette actually works because the values are even, and the colours muted. Placing red on top of green is usually a hideous combination of death, but if the green is drab enough and the red contrasts well enough, the result can actually be quite pleasing. I\u2019ve chosen red as my loudest colour in this palette, and left green and yellow to play the quiet supporting roles.\n\nObviously, there are no hard and fast rules here. You might not want to sample absolutely every colour in your scheme from a photo. There are times where you\u2019ll need a variation that\u2019s just a little bit lighter, or a blue that\u2019s not in the photo. You might decide to start from a photo base and tweak, or add in colours of your own. That\u2019s okay too.\n\nTonal Variations\n\nI\u2019ll leave you with a final trick I\u2019ve been using lately, a way to bring a bit more of a formula into the equation and save some steps.\n\n\n\nStarting with the same base palette I sampled from the chairs, in the above image I\u2019ve added a pair of overlaying squares that produce tonal variations of each primary. The lighter variation is simply a solid white square set to 40% opacity, the darker one is a black square at 20%. That gives me a highlight and shadow for each colour, which would prove handy if I had to adapt this colour scheme to a larger layout.\n\nI could add a few more squares of varying opacities, or adjust the layer blending modes for different effects, but as this looks like a great place to end, I\u2019ll leave that up to your experimental whims. Happy colouring!", "year": "2006", "author": "Dave Shea", "author_slug": "daveshea", "published": "2006-12-22T00:00:00+00:00", "url": "https://24ways.org/2006/photographic-palettes/", "topic": "design"} {"rowid": 135, "title": "A Scripting Carol", "contents": "We all know the stories of the Ghost of Scripting Past \u2013 a time when the web was young and littered with nefarious scripting, designed to bestow ultimate control upon the developer, to pollute markup with event handler after event handler, and to entrench advertising in the minds of all that gazed upon her.\n\nAnd so it came to be that JavaScript became a dirty word, thrown out of solutions by many a Scrooge without regard to the enhancements that JavaScript could bring to any web page. JavaScript, as it was, was dead as a door-nail.\n\nWith the arrival of our core philosophy that all standardistas hold to be true: \u201cseparate your concerns \u2013 content, presentation and behaviour,\u201d we are in a new era of responsible development the Web Standards Way\u2122. Or are we? Have we learned from the Ghosts of Scripting Past? Or are we now faced with new problems that come with new ways of implementing our solutions?\n\nThe Ghost of Scripting Past\n\nIf the Ghost of Scripting Past were with us it would probably say: \n\n\n\tYou must remember your roots and where you came from, and realize the misguided nature of your early attempts for control. That person you see down there, is real and they are the reason you exist in the first place\u2026 without them, you are nothing.\n\n\nIn many ways we\u2019ve moved beyond the era of control and we do take into account the user, or at least much more so than we used to. Sadly \u2013 there is one advantage that old school inline event handlers had where we assigned and reassigned CSS style property values on the fly \u2013 we knew that if JavaScript wasn\u2019t supported, the styles wouldn\u2019t be added because we ended up doing them at the same time.\n\nIf anything, we need to have learned from the past that just because it works for us doesn\u2019t mean it is going to work for anyone else \u2013 we need to test more scenarios than ever to observe the multitude of browsing arrangements we\u2019ll observe: CSS on with JavaScript off, CSS off/overridden with JavaScript on, both on, both off/not supported. It is a situation that is ripe for conflict.\n\nThis may shock some of you, but there was a time when testing was actually easier: back in the day when Netscape 4 was king. Yes, that\u2019s right. I actually kind of enjoyed Netscape 4 (hear me out, please). With NS4\u2019s CSS implementation known as JavaScript Style Sheets, you knew that if JavaScript was off the styles were off too.\n\nThe Ghost of Scripting Present\n\nWith current best practice \u2013 we keep our CSS and JavaScript separate from each other. So what happens when some of our fancy, unobtrusive DOM Scripting doesn\u2019t play nicely with our wonderfully defined style rules?\n\nLets look at one example of a collapsing and expanding menu to illustrate where we are now:\n\nSimple Collapsing/Expanding Menu Example\n\nWe\u2019re using some simple JavaScript (I\u2019m using jquery in this case) to toggle between a CSS state for expanded and not expanded:\n\nJavaScript\n\n$(document).ready(function(){\n\tTWOFOURWAYS.enableTree();\n});\nvar TWOFOURWAYS = new Object();\nTWOFOURWAYS.enableTree = function ()\n{\n\t$(\"ul li a\").toggle(function(){\n\t\t$(this.parentNode).addClass(\"expanded\");\n\t}, function() {\n\t\t$(this.parentNode).removeClass(\"expanded\");\n\t});\n\treturn false;\t\n}\n\nCSS\n\nul li ul {\n\tdisplay: none;\n}\nul li.expanded ul {\n\tdisplay: block;\n}\n\nAt this point we\u2019ve separated our presentation from our content and behaviour, and all is well, right?\n\nNot quite.\n\nHere\u2019s where I typically see failures in the assessment work that I do on web sites and applications (Yes, call me Scrooge \u2013 I don\u2019t care!). We know our page needs to work with or without scripting, and we know it needs to work with or without CSS. All too often the testing scenarios don\u2019t take into account combinations.\n\nTesting it out\n\nSo what happens when we test this? Make sure you test with:\n\n\n\tCSS off\n\tJavaScript off\n\n\nUse the simple example again.\n\nWith CSS off, we revert to a simple nested list of links and all functionality is maintained. With JavaScript off, however, we run into a problem \u2013 we have now removed the ability to expand the menu using the JavaScript triggered CSS change.\n\nHopefully you see the problem \u2013 we have a JavaScript and CSS dependency that is critical to the functionality of the page. Unobtrusive scripting and binary on/off tests aren\u2019t enough. We need more.\n\nThis Ghost of Scripting Present sighting is seen all too often.\n\nLets examine the JavaScript off scenario a bit further \u2013 if we require JavaScript to expand/show the branch of the tree we should use JavaScript to hide them in the first place. That way we guarantee functionality in all scenarios, and have achieved our baseline level of interoperability. \n\nTo revise this then, we\u2019ll start with the sub items expanded, use JavaScript to collapse them, and then use the same JavaScript to expand them.\n\nHTML\n\n\n\nCSS\n\n/* initial style is expanded */\nul li ul.collapseme {\n\tdisplay: block;\n}\n\nJavaScript\n\n// remove the class collapseme after the page loads\n$(\"ul ul.collapseme\").removeClass(\"collapseme\");\n\nAnd there you have it \u2013 a revised example with better interoperability.\n\nThis isn\u2019t rocket surgery by any means. It is a simple solution to a ghostly problem that is too easily overlooked (and often is).\n\nThe Ghost of Scripting Future\n\nWell, I\u2019m not so sure about this one, but I\u2019m guessing that in a few years\u2019 time, we\u2019ll all have seen a few more apparitions and have a few more tales to tell. And hopefully we\u2019ll be able to share them on 24 ways.\n\nThanks to Drew for the invitation to contribute and thanks to everyone else out there for making this a great (and haunting) year on the web!", "year": "2006", "author": "Derek Featherstone", "author_slug": "derekfeatherstone", "published": "2006-12-21T00:00:00+00:00", "url": "https://24ways.org/2006/a-scripting-carol/", "topic": "code"} {"rowid": 126, "title": "Intricate Fluid Layouts in Three Easy Steps", "contents": "The Year of the Script may have drawn attention away from CSS but building fluid, multi-column, cross-browser CSS layouts can still be as unpleasant as a lump of coal. Read on for a worry-free approach in three quick steps.\n\nThe layout system I developed, YUI Grids CSS, has three components. They can be used together as we\u2019ll see, or independently.\n\nThe Three Easy Steps\n\n\n\tChoose fluid or fixed layout, and choose the width (in percents or pixels) of the page.\n\tChoose the size, orientation, and source-order of the main and secondary blocks of content.\n\tChoose the number of columns and how they distribute (for example 50%-50% or 25%-75%), using stackable and nestable grid structures.\n\n\nThe Setup\n\nThere are two prerequisites: We need to normalize the size of an em and opt into the browser rendering engine\u2019s Strict Mode.\n\nEms are a superior unit of measure for our case because they represent the current font size and grow as the user increases their font size setting. This flexibility\u2014the container growing with the user\u2019s wishes\u2014means larger text doesn\u2019t get crammed into an unresponsive container. We\u2019ll use YUI Fonts CSS to set the base size because it provides consistent-yet-adaptive font-sizes while preserving user control.\n\nThe second prerequisite is to opt into Strict Mode (more info on rendering modes) by declaring a Doctype complete with URI. You can choose XHTML or HTML, and Transitional or Strict. I prefer HTML 4.01 Strict, which looks like this:\n\n\n\nIncluding the CSS\n\nA single small CSS file powers a nearly-infinite number of layouts thanks to a recursive system and the interplay between the three distinct components. You could prune to a particular layout\u2019s specific needs, but why bother when the complete file weighs scarcely 1.8kb uncompressed? Compressed, YUI Fonts and YUI Grids combine for a miniscule 0.9kb over the wire.\n\nYou could save an HTTP request by concatenating the two CSS files, or by adding their contents to your own CSS, but I\u2019ll keep them separate for now:\n\n\n\n\nExample: The Setup\n\nNow we\u2019re ready to build some layouts.\n\nStep 1: Choose Fluid or Fixed Layout\n\nChoose between preset widths of 750px, 950px, and 100% by giving a document-wrapping div an ID of doc, doc2, or doc3. These options cover most use cases, but it\u2019s easy to define a custom fixed width.\n\nThe fluid 100% grid (doc3) is what I\u2019ve been using almost exclusively since it was introduced in the last YUI released.\n\n\n\t
\n\n\nAll pages are centered within the viewport, and grow with font size. The 100% width page (doc3) preserves 10px of breathing room via left and right margins. If you prefer your content flush to the viewport, just add doc3 {margin:auto} to your CSS.\n\nRegardless of what you choose in the other two steps, you can always toggle between these widths and behaviors by simply swapping the ID value. It\u2019s really that simple.\n\nExample: 100% fluid layout\n\nStep 2: Choose a Template Preset\n\nThis is perhaps the most frequently omitted step (they\u2019re all optional), but I use it nearly every time. In a source-order-independent way (good for accessibility and SEO), \u201cTemplate Presets\u201d provide commonly used template widths compatible with ad-unit dimension standards defined by the Interactive Advertising Bureau, an industry association.\n\nChoose between the six Template Presets (.yui-t1 through .yui-t6) by setting the class value on the document-wrapping div established in Step 1. Most frequently I use yui-t3, which puts the narrow secondary block on the left and makes it 300px wide. \n\n\n\t
\n\n\nThe Template Presets control two \u201cblocks\u201d of content, which are defined by two divs, each with yui-b (\u201cb\u201d for \u201cblock\u201d) class values. Template Presets describe the width and orientation of the secondary block; the main block will take up the rest of the space.\n\n\n\t
\n\t
\n\t
\n\t
\n\n\nUse a wrapping div with an ID of yui-main to structurally indicate which block is the main block. This wrapper\u2014not the source order\u2014identifies the main block.\n\n\n\t
\n\t
\n\t
\n\t
\n\t
\n\t
\n\n\nExample: Main and secondary blocks sized and oriented with .yui-t3 Template Preset\n\nAgain, regardless of what values you choose in the other steps, you can always toggle between these Template Presets by toggling the class value of your document-wrapping div. It\u2019s really that simple.\n\nStep 3: Nest and Stack Grid Structures.\n\nThe bulk of the power of the system is in this third step. The key is that columns are built by parents telling children how to behave. By default, two children each consume half of their parent\u2019s area. Put two units inside a grid structure, and they will sit side-by-side, and they will each take up half the space. Nest this structure and two columns become four. Stack them for rows of columns.\n\nAn Even Number of Columns\n\nThe default behavior creates two evenly-distributed columns. It\u2019s easy. Define one parent grid with .yui-g (\u201cg\u201d for grid) and two child units with .yui-u (\u201cu\u201d for unit). The code looks like this:\n\n
\n\t
\n\t
\n
\n\nBe sure to indicate the \u201cfirst\u201c unit because the :first-child pseudo-class selector isn\u2019t supported across all A-grade browsers. It\u2019s unfortunate we need to add this, but luckily it\u2019s not out of place in the markup layer since it is structural information.\n\nExample: Two evenly-distributed columns in the main content block\n\nAn Odd Number of Columns\n\nThe default system does not work for an odd number of columns without using the included \u201cSpecial Grids\u201d classes. To create three evenly distributed columns, use the \u201cyui-gb\u201c Special Grid:\n\n
\n\t
\n\t
\n\t
\n
\n\nExample: Three evenly distributed columns in the main content block\n\nUneven Column Distribution\n\nSpecial Grids are also used for unevenly distributed column widths. For example, .yui-ge tells the first unit (column) to take up 75% of the parent\u2019s space and the other unit to take just 25%.\n\n
\n\t
\n\t
\n
\n\nExample: Two columns in the main content block split 75%-25%\n\nPutting It All Together\n\nStart with a full-width fluid page (div#doc3). Make the secondary block 180px wide on the right (div.yui-t4). Create three rows of columns: Three evenly distributed columns in the first row (div.yui-gb), two uneven columns (66%-33%) in the second row (div.yui-gc), and two evenly distributed columns in the thrid row.\n\n\n\t\n\t
\n\t\t\n\t\t
\n\t\t\t
\n\t\t\t\t\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t
\n\t\t
\n\t\t\n\t\t
\n\t
\n\n\nExample: A complex layout.\n\nWasn\u2019t that easy? Now that you know the three \u201clevers\u201d of YUI Grids CSS, you\u2019ll be creating headache-free fluid layouts faster than you can say \u201cPeace on Earth\u201d.", "year": "2006", "author": "Nate Koechley", "author_slug": "natekoechley", "published": "2006-12-20T00:00:00+00:00", "url": "https://24ways.org/2006/intricate-fluid-layouts/", "topic": "code"} {"rowid": 144, "title": "The Mobile Web, Simplified", "contents": "A note from the editors: although eye-opening in 2006, this article is no longer relevant to today\u2019s mobile web.\n \n \n \n Considering a foray into mobile web development? Following are four things you need to know before making the leap.\n\n1. 4 billion mobile subscribers expected by 2010\n\nFancy that. Coupled with the UN prediction of 6.8 billion humans by 2010, 4 billion mobile subscribers (source) is an astounding 59% of the planet. Just how many of those subscribers will have data plans and web-enabled phones is still in question, but inevitably this all means one thing for you and me: A ton of potential eyes to view our web content on a mobile device.\n\n2. Context is king\n\nYour content is of little value to users if it ignores the context in which it is viewed. Consider how you access data on your mobile device. You might be holding a bottle of water or gripping a handle on the subway/tube. You\u2019re probably seeking specific data such as directions or show times, rather than the plethora of data at your disposal via a desktop PC.\n\nThe mobile web, a phrase often used to indicate \u201caccessing the web on a mobile device\u201d, is very much a context-, content-, and component-specific environment. Expressed in terms of your potential target audience, access to web content on a mobile device is largely influenced by surrounding circumstances and conditions, information relevant to being mobile, and the feature set of the device being used. Ask yourself, What is relevant to my users and the tasks, problems, and needs they may encounter while being mobile? Answer that question and you\u2019ll be off to a great start.\n\n3. WAP 2.0 is an XHTML environment\n\nIn a nutshell, here are a few fundamental tenets of mobile internet technology:\n\n\n\tWireless Application Protocol (WAP) is the protocol for enabling mobile access to internet content.\n\tWireless Markup Language (WML) was the language of choice for WAP 1.0.\n\tNearly all devices sold today are WAP 2.0 devices.\n\tWith the introduction of WAP 2.0, XHTML Mobile Profile (XHTML-MP) became the preferred markup language.\n\tXHTML-MP will be familiar to anyone experienced with XHTML Transitional or Strict.\n\n\nSummary? The mobile web is rapidly becoming an XHTML environment, and thus you and I can apply our existing \u201cdesktop web\u201d skills to understand how to develop content for it. With WML on the decline, the learning curve is much smaller today than it was several years ago. I\u2019m generalizing things gratuitously, but the point remains: Get off yo\u2019 lazy butt and begin to take mobile seriously.\n\nI\u2019ll even pass you a few tips for getting started. First, the DOCTYPE for XHTML-MP is as follows:\n\n\n\nAs for MIME type, Open Mobile Alliance (OMA) specifies using the MIME type application/vnd.wap.xhtml+xml, but ultimately you need to ensure the server delivering your mobile content is configured properly for the MIME type you choose to use, as there are other options (see Setting up WAP Servers).\n\nOnce you\u2019ve made it to the body, the XHTML-MP markup is not unlike what you\u2019re already used to. A few resources worth skimming:\n\n\n\tDevelopers Home XHTML-MP Tutorial \u2013 An impressively replete resource for all things XHTML-MP\n\tXHTML-MP Tags List \u2013 A complete list of XHTML-MP elements and accompanying attributes\n\n\nAnd last but certainly not least, CSS. There exists WAP CSS, which is essentially a subset of CSS2 with WAP-specific extensions. For all intents and purposes, much of the CSS you\u2019re already comfortable using will be transferrable to mobile. As for including CSS in your pages, your options are the same as for desktop sites: external, embedded, and inline. Some experts will argue embedded or inline over external in favor of reducing the number of HTTP connections per page request, yet many popular mobilized sites and apps employ external linking without issue.\n\nStocking stuffers: Flickr Mobile, Fandango Mobile, and Popurls Mobile. A few sites with whom you can do the View Source song and dance for further study.\n\n4. \u201cCell phone\u201d is so DynaTAC\n\nIf you\u2019re a U.S. resident, listen up: You must rid your vocabulary of the term \u201ccell phone\u201d. We\u2019re one of the few economies on the planet to refer to a mobile phone accordingly. If you care to find yourself in any of the worthwhile mobile development circles, begin using terms more widely accepted: \u201cmobile\u201d or \u201cmobile phone\u201d or \u201chandset\u201d or \u201chandy\u201d. If you\u2019re not sure which, go for \u201cmobile\u201d. Such as, \u201cYo dog, check out my new mobile.\u201d\n\nMore importantly, however, is overcoming the mentality that access to the mobile web can be done only with a phone. Instead, \u201cdevice\u201d encourages us to think phone, handheld computer, watch, Nintendo DS, car, you name it.\n\nSimple enough?", "year": "2006", "author": "Cameron Moll", "author_slug": "cameronmoll", "published": "2006-12-19T00:00:00+00:00", "url": "https://24ways.org/2006/the-mobile-web-simplified/", "topic": "ux"} {"rowid": 128, "title": "Boost Your Hyperlink Power", "contents": "There are HTML elements and attributes that we use every day. Headings, paragraphs, lists and images are the mainstay of every Web developer\u2019s toolbox. Perhaps the most common tool of all is the anchor. The humble a element is what joins documents together to create the gloriously chaotic collection we call the World Wide Web.\n\nAnatomy of an Anchor\n\nThe power of the anchor element lies in the href attribute, short for hypertext reference. This creates a one-way link to another resource, usually another page on the Web:\n\n\n\nThe href attribute sits in the opening a tag and some descriptive text sits between the opening and closing tags:\n\nDrew McLellan\n\n\u201cWhoop-dee-freakin\u2019-doo,\u201d I hear you say, \u201cthis is pretty basic stuff\u201d \u2013 and you\u2019re quite right. But there\u2019s more to the anchor element than just the href attribute.\n\nThe Theory of relativity\n\nYou might be familiar with the rel attribute from the link element. I bet you\u2019ve got something like this in the head of your documents:\n\n\n\nThe rel attribute describes the relationship between the linked document and the current document. In this case, the value of rel is \u201cstylesheet\u201d. This means that the linked document is the stylesheet for the current document: that\u2019s its relationship.\n\nHere\u2019s another common use of rel:\n\n\n\nThis describes the relationship of the linked file \u2013 an RSS feed \u2013 as \u201calternate\u201d: an alternate view of the current document.\n\nBoth of those examples use the link element but you are free to use the rel attribute in regular hyperlinks. Suppose you\u2019re linking to your RSS feed in the body of your page:\n\nSubscribe to my RSS feed.\n\nYou can add extra information to this anchor using the rel attribute:\n\nSubscribe to my RSS feed.\n\nThere\u2019s no prescribed list of values for the rel attribute so you can use whatever you decide is semantically meaningful. Let\u2019s say you\u2019ve got a complex e-commerce application that includes a link to a help file. You can explicitly declare the relationship of the linked file as being \u201chelp\u201d:\n\nneed help?\n\nElemental Microformats\n\nAlthough it\u2019s completely up to you what values you use for the rel attribute, some consensus is emerging in the form of microformats. Some of the simplest microformats make good use of rel. For example, if you are linking to a license that covers the current document, use the rel-license microformat:\n\nLicensed under a Creative Commons attribution license\n\nThat describes the relationship of the linked document as \u201clicense.\u201d\n\nThe rel-tag microformat goes a little further. It uses rel to describe the final part of the URL of the linked file as a \u201ctag\u201d for the current document:\n\nLearn more about semantic markup\n\nThis states that the current document is being tagged with the value \u201cMicroformats.\u201d\n\nXFN, which stands for XHTML Friends Network, is a way of describing relationships between people:\n\nDrew McLellan\n\nThis microformat makes use of a very powerful property of the rel attribute. Like the class attribute, rel can take multiple values, separated by spaces:\n\nDrew McLellan\n\nHere I\u2019m describing Drew as being a friend, someone I\u2019ve met, and a colleague (because we\u2019re both Web monkies).\n\nYou Say You Want a revolution\n\nWhile rel describes the relationship of the linked resource to the current document, the rev attribute describes the reverse relationship: it describes the relationship of the current document to the linked resource. Here\u2019s an example of a link that might appear on help.html:\n\ncontinue shopping\n\nThe rev attribute declares that the current document is \u201chelp\u201d for the linked file.\n\nThe vote-links microformat makes use of the rev attribute to allow you to qualify your links. By using the value \u201cvote-for\u201d you can describe your document as being an endorsement of the linked resource:\n\nI agree with Richard Dawkins.\n\nThere\u2019s a corresponding vote-against value. This means that you can link to a document but explicitly state that you don\u2019t agree with it.\n\nI agree with Richard Dawkins\nabout those creationists. \n\nOf course there\u2019s nothing to stop you using both rel and rev on the same hyperlink:\n\nRichard Dawkins\n\nThe Wisdom of Crowds\n\nThe simplicity of rel and rev belies their power. They allow you to easily add extra semantic richness to your hyperlinks. This creates a bounty that can be harvested by search engines, aggregators and browsers. Make it your New Year\u2019s resolution to make friends with these attributes and extend the power of hypertext.", "year": "2006", "author": "Jeremy Keith", "author_slug": "jeremykeith", "published": "2006-12-18T00:00:00+00:00", "url": "https://24ways.org/2006/boost-your-hyperlink-power/", "topic": "code"} {"rowid": 129, "title": "Knockout Type - Thin Is Always In", "contents": "OS X has gorgeous native anti-aliasing (although I will admit to missing 10px aliased Geneva \u2014 *sigh*). This is especially true for dark text on a light background. However, things can go awry when you start using light text on a dark background. Strokes thicken. Counters constrict. Letterforms fill out like seasonal snackers.\n\n \n\nSo how do we combat the fat? In Safari and other Webkit-based browsers we can use the CSS \u2018text-shadow\u2019 property. While trying to add a touch more contrast to the navigation on haveamint.com I noticed an interesting side-effect on the weight of the type. \n\n\n\nThe second line in the example image above has the following style applied to it:\n\n \n\nThis creates an invisible drop-shadow. (Why is it invisible? The shadow is positioned directly behind the type (the first two zeros) and has no spread (the third zero). So the color, black, is completely eclipsed by the type it is supposed to be shadowing.)\n\n \n\nWhy applying an invisible drop-shadow effectively lightens the weight of the type is unclear. What is clear is that our light-on-dark text is now of a comparable weight to its dark-on-light counterpart.\n\n \n\nYou can see this trick in effect all over ShaunInman.com and in the navigation on haveamint.com and Subtraction.com. The HTML and CSS source code used to create the example images used in this article can be found here.", "year": "2006", "author": "Shaun Inman", "author_slug": "shauninman", "published": "2006-12-17T00:00:00+00:00", "url": "https://24ways.org/2006/knockout-type/", "topic": "code"} {"rowid": 123, "title": "Fast and Simple Usability Testing", "contents": "Everyone knows by now that they should test the usability of their applications, but still hardly anybody actually does it. In this article I\u2019ll share some tips I\u2019ve picked up for doing usability tests quickly and effectively.\n\nRelatively recent tools like Django and Ruby on Rails allow us to develop projects faster and to make significant changes later in the project timeline. Usability testing methods should now be adapted to fit this modern approach to development.\n\nWhen to test\n\nIn an ideal world usability tests would be carried out frequently from an early stage of the project. Time and budget constraints lead this to be impractical; usability is often the first thing to get dropped from the project plan.\n\nIf you can only test at one stage in the project, whatever the size, the most valuable time is before your first public beta \u2014 leaving long enough to fix issues and not so late that you can\u2019t rethink your scope.\n\nThere are three main categories of usability test:\n\n\n\tTesting design mockups\n\tTesting a new working application\n\tTesting established applications\n\n\nEach category requires a slightly different approach. For small modern web projects you are most likely to be testing a new working application. You will of course have already done functional tests so you won\u2019t be worried about the user breaking things. The main differences between the categories apply in how you word The Script.\n\nTesting an established application is the most fun in my opinion. Humans are remarkably adaptable and rapidly develop coping strategies to work around usability issues in software they are forced to use. Uncovering these strategies may lead you to understand previously unspoken needs of your users. Often small changes to the application will have a dramatic affect on their everyday lives.\n\nWho to test\n\nWhen you have built a project to scratch your own itch, your intended audience will be people just like you. Test subjects in this case should be easy to find \u2013 friends, co-workers etc.\n\nThis is not always the case; your users may not be like you at all. When they are not, it\u2019s all the more important to run usability tests. Testing on friends, family and co-workers is better than not doing usability tests at all, but it can\u2019t be compared to testing on actual samples of your intended audience. People who would use the system will provide more genuine feedback and deeper insight.\n\nNever let your test subjects put themselves in the shoes of your \u2018actual\u2019 users. For example, you should discourage comments like \u201cWell, I would do this BUT if I was a bus driver I\u2019d do that\u201d. Users are not qualified to put themselves in the position of others. Inaccurate data is often worse than no data.\n\nAim for five or six test subjects: any more and you probably won\u2019t learn anything new; any less and you\u2019re likely to be overwhelmed by issues stemming from people\u2019s individual personalities.\n\nThe Script\n\nThe Script is a single side of A4 (or letter) paper, consisting of questions for your testers and reminders for yourself. Have a balance of task-based questions and expectation analysis. This helps maintain consistency across tests. Expectation analysis is more important for testing designs and new applications: \u201cWhere would you find X?\u201d, \u201cWhat would you expect to happen if you clicked on Y?\u201d. In an established system users will probably know where these things are though it can still be illuminating to ask these questions though phrased slightly differently.\n\nTask-based questions involve providing a task for the user to complete. If you are testing an established system it is a good idea to ask users to bring in tasks that they would normally perform. This is because the user will be more invested in the outcome of the task and will behave in a more realistic fashion. When designing tasks for new systems and designs ensure you only provide loose task details for the same reason. Don\u2019t tell testers to enter \u201cChantelle\u201d; have them use their own name instead. Avoid introducing bias with the way questions are phrased.\n\nIt\u2019s a good idea to ask for users\u2019 first impressions at the beginning of the test, especially when testing design mockups. \u201cWhat are the main elements on the page?\u201d or \u201cWhat strikes you first?\u201d.\n\nYou script should run for a maximum of 45 minutes. 30-35 minutes is better; after this you are likely to lose their attention. Tests on established systems can take longer as there is more to learn from them. When scheduling the test you will need to leave yourself 5 minutes between each one to collate your notes and prepare for the next. Be sure to run through the script beforehand.\n\nYour script should be flexible. It is possible that during the test a trend will come to light that opens up whole new avenues of possible questioning. For example, during one initial test of an established system I noticed that the test subject had been printing off items from the application and placing them in a folder in date order (the system ordered alphabetically). I changed the script to ask future participants in that run, if they ever used external tools to help them with tasks within the system. This revealed a number of interesting issues that otherwise would not have been found.\n\nRunning the tests\n\nTreat your test subjects like hedgehogs. Depending on your target audience they probably feel a little nervous and perhaps even scared of you. So make them a little nest out of straw, stroke their prickles and give them some cat food. Alternatively, reassure them that you are testing the system and that they can\u2019t give a wrong answer. Reward them with a doughnut or jam tart at the end. Try to ensure the test environment is relaxed and quiet, but also as close as possible to the situation where they would actually use the system.\n\nHave your subjects talk out loud is very important as you can\u2019t read their minds, but it is a very unnatural process. To loosen up your subjects and get them talking in the way you want them to, try the Stapler Trick. Give them a stapler or similar item and ask them to open it, take the staples out, replace them, shut the stapler and staple some paper \u2013 talking all the time about what they see, what they expect to happen, what actually happens and how that matches up. Make them laugh at you.\n\nSay how long the test will take up front, and tell your subject why you are doing it. After the test has been completed, conclude by thanking them for their time and assuring them that they were very useful. Then give them the sugary treat.\n\nWhat to look for\n\nPrimarily, you should look out for incidents where the user stops concentrating on her tasks and starts thinking about the tool and how she is going to use it. For example, when you are hammering in a nail you don\u2019t think about how to use a hammer; good software should be the same. Words like \u2018it\u2019 and \u2018the system\u2019 and are good indications that the test subject has stopped thinking about the task in hand. Note questioning words, especially where testers question their own judgement, \u201cwhy can\u2019t I find \u2026\u201d, \u201cI expected to see \u2026\u201d etc. as this indicates that the work flow for the task may have broken down.\n\nAlso keep an eye on occasions where the user completely fails to do a task. They may need some prompting to unstick them, but you should be careful not to bias the test. These should be the highest priority issues for you to fix. If users recover from getting stuck, make a note of how they recovered. Prolonged periods of silence from the test subject may also require prompting as they should be talking all the time. Ask them what they are thinking or looking for but avoid words like \u2018try\u2019 (e.g. \u2018what are you trying to do?\u2019) as this implies that they are currently failing.\n\nBe wary of users\u2019 opinions on aesthetics and be prepared to bring them back to the script if they get side-tracked.\n\nWriting it up\n\nEven if you are the only developer it\u2019s important to summarise the key issues that emerged during testing: your notes won\u2019t make much sense to you a week or so after the test.\n\nIf you are writing for other people, include a summary no longer than two pages; this can consist of a list or table of the issues including recommendations and their priorities. Remember to anonymise the users in the report. In team situations, you may be surprised at how many people are interested in the results of the usability test even if it doesn\u2019t relate directly to something that they can fix.\n\nTo conclude\u2026\n\nSome usability testing is better than none at all, even for small projects or those with strict deadlines. Make the most of the time and resources available. Choose your users carefully, make them comfortable, summarise your report and don\u2019t forget to leave a doughnut for yourself!", "year": "2006", "author": "Natalie Downe", "author_slug": "nataliedowne", "published": "2006-12-16T00:00:00+00:00", "url": "https://24ways.org/2006/fast-and-simple-usability-testing/", "topic": "process"} {"rowid": 122, "title": "A Message To You, Rudy - CSS Production Notes", "contents": "When more than one designer or developer work together on coding an XHTML/CSS template, there are several ways to make collaboration effective. Some prefer to comment their code, leaving a trail of bread-crumbs for their co-workers to follow. Others use accompanying files that contain their working notes or communicate via Basecamp.\n\nFor this year\u2019s 24ways I wanted to share a technique that I has been effective at Stuff and Nonsense; one that unfortunately did not make it into the final draft of Transcending CSS. This technique, CSS production notes, places your page production notes in one convenient place within an XHTML document and uses nothing more than meaningful markup and CSS.\n\nLet\u2019s start with the basics; a conversation between a group of people. In the absence of notes or conversation elements in XHTML you need to make an XHTML compound that will effectively add meaning to the conversation between designers and developers. As each person speaks, you have two elements right there to describe what has been said and who has spoken:
and its cite attribute. \n\n
\n\t

This project will use XHTML1.0 Strict, CSS2.1 and all that malarkey.

\n
\n\nWith more than one person speaking, you need to establish a temporal order for the conversation. Once again, the element to do just that is already there in XHTML; the humble ordered list.\n\n
    \n\t
  1. \n\t\t
    \n\t\t\t

    This project will use XHTML1.0 Strict, CSS2.1 and all that malarkey.

    \n\t\t
    \n\t
  2. \n\t
  3. \n\t\t
    \n\t\t\t

    Those bits are simple and bulletproof.

    \n\t\t
    \n\t
  4. \n
\n\nAdding a new note is as simple as adding a new item to list, and if you prefer to add more information to each note, such as the date or time that the note was written, go right ahead. Place your note list at the bottom of the source order of your document, right before the closing tag. One advantage of this approach over using conventional comments in your code is that all the notes are unobtrusive and are grouped together in one place, rather than being spread throughout your document.\n\nBasic CSS styling\n\nFor the first stage you are going to add some basic styling to the notes area, starting with the ordered list. For this design I am basing the look and feel on an instant messenger window.\n\n\n\nol#notes {\n\twidth : 300px; \n\theight : 320px; \n\tpadding : .5em 0; \n\tbackground : url(im.png) repeat; \n\tborder : 1px solid #333; \n\tborder-bottom-width : 2px; \n\t-moz-border-radius : 6px; /* Will not validate */\n\tcolor : #000; \n\toverflow : auto; \n}\nol#notes li { \n\tmargin : .5em; \n\tpadding : 10px 0 5px; \n\tbackground-color : #fff; \n\tborder : 1px solid #666; \n\t-moz-border-radius : 6px; /* Will not validate */ \n}\nol#notes blockquote { \n\tmargin : 0; \n\tpadding : 0; \n}\nol#notes p { \n\tmargin : 0 20px .75em;\n\tpadding : 0; \n}\nol#notes p.date { \n\tfont-size : 92%;\n\tcolor : #666; \n\ttext-transform : uppercase; \n}\n\nTake a gander at the first example.\n\nYou could stop right there, but without seeing who has left the note, there is little context. So next, extract the name of the commenter from the
\u2019s cite attribute and display it before each note by using generated content.\n\nol#notes blockquote:before { \n\tcontent : \" \"attr(cite)\" said: \"; \n\tmargin-left : 20px; \n\tfont-weight : bold; \n}\n\nFun with more detailed styling\n\nNow, with all of the information and basic styling in place, it\u2019s time to have some fun with some more detailed styling to spruce up your notes. Let\u2019s start by adding an icon for each person, once again based on their cite. First, all of the first paragraphs of a
\u2019s that includes a cite attribute are given common styles.\n\nol#notes blockquote[cite] p:first-child {\n\tmin-height : 34px;\n\tpadding-left : 40px; \n}\n\nFollowed by an individual background-image.\n\nol#notes blockquote[cite=\"Andy\"] p:first-child { \n\tbackground : url(malarkey.png) no-repeat 5px 5px; \n} \n\nIf you prefer a little more interactivity, add a :hover state to each
and perhaps highlight the most recent comment.\n\nol#notes blockquote:hover { \n\tbackground-color : #faf8eb; \n\tborder-top : 1px solid #fff; \n\tborder-bottom : 1px solid #333; \n}\nol#notes li:last-child blockquote { \n\tbackground-color : #f1efe2; \n}\n\n\n\nYou could also adjust the style for each comment based on the department that the person works in, for example:\n\n
  • \n\t
    \n\t\t

    This project will use XHTML1.0 Strict, CSS2.1 and all that malarkey.

    \n\t
    \n
  • \n
  • \n\t
    \n\t\t

    Those bits are simple and bulletproof.

    \n\t
    \n
  • \nol#notes blockquote.designer { border-color : #600; }\n\nTake a look at the results of the second stage.\n\nShow and hide the notes using CSS positioning\n\nWith your notes now dressed in their finest, it is time to tuck them away above the top of your working XHTML/CSS prototype so that you can reveal them when you need them, no JavaScript required. Start by moving the ordered list of notes off the top of the viewport leaving only a few pixels in view. It is also a good idea to make them semi-transparent by using the opacity property for browsers that have implemented it.\n\nol#notes { \n\tposition : absolute; \n\topacity : .25;\n\tz-index : 2000; \n\ttop : -305px; \n\tleft : 20px; \n}\n\nYour last step is to add :hover and :focus dynamic pseudo-classes to reposition the list at the top of the viewport and restore full opacity to display them in their full glory when needed.\n\nol#notes:hover, ol#notes:focus {\n\ttop : 0; \n\topacity : 1; \n}\n\n\n\nNow it\u2019s time to sit back, pour yourself a long drink and bask in the glory of the final result. Your notes are all stored in one handy place at the bottom of your document rather than being spread around your code. When your templates are complete, simply dive straight to the bottom and pull out the notes.\n\nA Message To You, Rudy\n\nThank-you to everybody for making this a really great year for web standards. Have a wonderful holiday season.\n\nBuy Andy Clarke\u2019s book Transcending CSS from Amazon.com", "year": "2006", "author": "Andy Clarke", "author_slug": "andyclarke", "published": "2006-12-15T00:00:00+00:00", "url": "https://24ways.org/2006/css-production-notes/", "topic": "process"} {"rowid": 140, "title": "Styling hCards with CSS", "contents": "There are plenty of places online where you can learn about using the hCard microformat to mark up contact details at your site (there are some resources at the end of the article). But there\u2019s not yet been a lot of focus on using microformats with CSS. So in this installment of 24 ways, we\u2019re going to look at just that \u2013 how microformats help make CSS based styling simpler and more logical.\n\nBeing rich, quite complex structures, hCards provide designers with a sophisticated scaffolding for styling them. A recent example of styling hCards I saw, playing on the business card metaphor, was by Andy Hume, at http://thedredge.org/2005/06/using-hcards-in-your-blog/. While his approach uses fixed width cards, let\u2019s take a look at how we might style a variable width business card style for our hCards.\n\nLet\u2019s take a common hCard, which includes address, telephone and email details\n\n
    \n\t

    Web Directions North\n\t\t\n\t\t\t\"download\n\t

    \n\n\t\n\t\t 1485 Laperri\u00e8re Avenue \n\t\t Ottawa ON K1Z 7S8 \n\t\tCanada\n\t\n\n\t\n\t\tPhone/Fax: Work: 61 2 9365 5007\n\t\tEmail: info@webdirections.org\n\t\n\n\nWe\u2019ll be using a variation on the now well established \u201csliding doors\u201d technique (if you create a CSS technique, remember it\u2019s very important to give it a memorable name or acronym, and bonus points if you get your name in there!) by Douglas Bowman, enhanced by Scott Schiller (see http://www.schillmania.com/projects/dialog/,) which will give us a design which looks like this\n\n\n\nThe technique, in a nutshell, uses background images on four elements, two at the top, and two at the bottom, to add each rounded corner.\n\nWe are going to make this design \u201cfluid\u201d in the sense that it grows and shrinks in proportion with the size of the font that the text of the element is displayed with. This is sometimes referred to as an \u201cem driven design\u201d (we\u2019ll see why in a moment).\n\nTo see how this works in practice, here\u2019s the same design with the text \u201czoomed\u201d up in size\n\n\n\nand the same design again, when we zoom the text size down\n\n\n\nBy the way, the hCard image comes from Chris Messina, and you can download it and other microformat icons from the microformats wiki.\n\nNow, with CSS3, this whole task would be considerably easier, because we can add multiple background images to an element, and border images for each edge of an element. Safari, version 1.3 up, actually supports multiple background images, but sadly, it\u2019s not supported in Firefox 1.5, or even Firefox 2.0 (let\u2019s not mention IE7 eh?). So it\u2019s probably too little supported to use now. So instead we\u2019ll use a technique that only involves CSS2, and works in pretty much any browser.\n\nVery often, developers add div or span elements as containers for these background images, and in fact, if you visit Scott Shiller\u2019s site, that\u2019s what he has done there. But if at all possible we shouldn\u2019t be adding any HTML simply for presentational purposes, even if the presentation is done via CSS. What we can do is to use the HTML we have already, as much as is possible, to add the style we want. This can take some creative thinking, but once you get the hang of this approach it becomes a more natural way of using HTML compared with simply adding divs and spans at will as hooks for style. Of course, this technique isn\u2019t always simple, and in fact sometimes simply not possible, requiring us to add just a little HTML to provide the \u201chooks\u201d for CSS.\n\nLet\u2019s go to work\n\nThe first step is to add a background image to the whole vCard element.\n\n\n\nWe make this wide enough (for example 1000 or more pixels) and tall enough that no matter how large the content of the vCard grows, it will never overflow this area. We can\u2019t simply repeat the image, because the top left corner will show when the image repeats.\n\nWe add this as the background image of the vCard element using CSS.\n\nWhile we are at it, let\u2019s give the text a sans-serif font, some color so that it will be visible, and stop the image repeating.\n\n.vcard {\n\tbackground-image: url(images/vcardfill.png);\n\tbackground-repeat: no-repeat;\n\tcolor: #666;\n\tfont-family: \"Lucida Grande\", Verdana, Helvetica, Arial, sans-serif;\n}\n\nWhich in a browser, will look something like this.\n\n\n\nNext step we need to add the top right hand corner of the hCard. In keeping with our aim of not adding HTML simply for styling purposes, we want to use the existing structure of the page where possible. Here, we\u2019ll use the paragraph of class fn and org, which is the first child element of the vcard element.\n\n

    Web Directions Conference Pty Ltd \"download

    \n\nHere\u2019s our CSS for this element\n\n.fn {\n\tbackground-image: url(images/topright.png);\n\tbackground-repeat: no-repeat;\n\tbackground-position: top right;\n\tpadding-top: 2em;\n\tfont-weight: bold;\n\tfont-size: 1.1em;\n}\n\nAgain, we don\u2019t want it to repeat, but this time, we\u2019ve specified a background position for the image. This will make the background image start from the top, but its right edge will be located at the right edge of the element. I also made the font size a little bigger, and the weight bold, to differentiate it from the rest of the text in the hCard.\n\nHere\u2019s the image we are adding as the background to this element.\n\n\n\nSo, putting these two CSS statements together we get\n\n\n\nWe specified a padding-top of 2em to give some space between the content of the fn element and the edge of the fn element. Otherwise the top of the hCard image would be hard against the border. To see this in action, just remove the padding-top: 2em; declaration and preview in a browser.\n\nSo, with just two statements, we are well under way. We\u2019ve not even had to add any HTML so far. Let\u2019s turn to the bottom of the element, and add the bottom border (well, the background image which will serve as that border).\n\nNow, which element are we going to use to add this background image to?\n\nOK, here I have to admit to a little, teensie bit of cheating. If you look at the HTML of the hCard, I\u2019ve grouped the email and telephone properties into a div, with a class of telecommunications. This grouping is not strictly requred for our hCard.\n\n
    \n\t

    Phone/Fax: Work:\n\t\t61 2 9365 5007

    \n\t

    Email: info@webdirections.org

    \n
    \n\nNow, I chose that class name because that is what the vCard specification calls this group of properties. And typically, I do tend to group together related elements using divs when I mark up content. I find it makes the page structure more logical and readable. But strictly speaking, this isn\u2019t necessary, so you may consider it cheating. But my lesson in this would be, if you are going to add markup, try to make it as meaningful as possible.\n\nAs you have probably guessed by now, we are going to add one part of the bottom border image to this element. We\u2019re going to add this image as the background-image.\n\n\n\nAgain, it will be a very wide image, like the top left one, so that no matter how wide the element might get, the background image will still be wide enough. Now, we\u2019ll need to make this image sit in the bottom left of the element we attach it to, so we use a backgound position of left bottom (we put the horizontal position before the vertical). Here\u2019s our CSS statement for this\n\n.telecommunications {\n\tbackground-image: url(images/bottom-left.png);\n\tbackground-repeat: no-repeat;\n\tbackground-position: left bottom;\n\tmargin-bottom: 2em;\n}\n\nAnd that will look like this\n\n\n\nNot quite there, but well on the way. Time for the final piece in the puzzle.\n\nOK, I admit, I might have cheated just a little bit more in this step. But like the previous step, all valid, and (hopefully) quite justifiable markup. If we look at the HTML again, you\u2019ll find that our email address is marked up like this\n\n

    Email: info@webdirections.org

    \n\nTypically, in hCard, the value part of this property isn\u2019t required, and we could get away with\n\ninfo@webdirections.org\n\nThe form I\u2019ve used, with the span of class value is however, perfectly valid hCard markup (hard allows for multiple email addresses of different types, which is where this typically comes in handy). Why have I gone to all this trouble? Well, when it came to styling the hCard, I realized I needed a block element to attach the background image for the bottom right hand corner to. Typically the last block element in the containing element is the ideal choice (and sometimes it\u2019s possible to take an inline element, for example the link here, and use CSS to make it a block element, and attach it to that, but that really doesn\u2019t work with this design).\n\nSo, if we are going to use the paragraph which contains the email link, we need a way to select it exclusively, which means that with CSS2 at least, we need a class or id as a hook for our CSS selector (in CSS3 we could use the last-child selector, which selects the last child element of a specified element, but again, as last child is not widely supported, we won\u2019t rely on it here.)\n\nSo, the least worst thing we could do is take an existing element, and add some reasonably meaningful markup to it. That\u2019s why we gave the paragraph a class of email, and the email address a class of value. Which reminds me a little of a moment in Hamlet\n\n\n\tThe lady doth protest too much, methinks\n\n\nOK, let\u2019s get back to the CSS.\n\nWe add the bottom right corner image, positioning it in the bottom right of the element, and making sure it doesn\u2019t repeat. We also add some padding to the bottom, to balance out the padding we added to the top of the hCard.\n\np.email {\n\tbackground-image: url(images/bottom-right.png);\n\tbackground-position: right bottom;\n\tbackground-repeat: no-repeat;\n\tpadding-bottom: 2em;\n}\n\nWhich all goes to make our hCard look like this\n\n\n\nIt just remains for us to clean up a little.\n\nLet\u2019s start from the top. We\u2019ll float the download image to the right like this\n\n.vcard img {\n\tfloat: right;\n\tpadding-right: 1em;\n\tmargin-top: -1em\n}\n\nSee how we didn\u2019t have to add a class to style the image, we used the fact that the image is a descendent of the vcard element, and a descendent selector. In my experience, the very widely supported, powerful descendent selector is one of the most underused aspects of CSS. So if you don\u2019t use it frequently, look into it in more detail.\n\nWe added some space to the right of the image, and pulled it up a bit closer to the top of the hCard, like this\n\n\n\nWe also want to add some whitespace between the edge of the hCard and the text. We would typically add padding to the left of the containing element, (in this case the vcard element) but this would break our bottom left hand corner, like this\n\n\n\nThat\u2019s because the div element we added this bottom left background image to would be moved in by the padding on its containing element.\n\nSo instead, we add left margin to all the paragraphs in the hCard\n\n.vcard p {\n\tmargin-left: 1em;\n}\n\n(there is the descendent selector again \u2013 it is the swiss army knife of CSS)\n\nNow, we\u2019ve not yet made the width of the hCard a function of the size of the text inside it (or \u201cem driven\u201d as we described it earlier). We do this by giving the hCard a width that is specified in em units. Here we\u2019ll set a width of say 28em, which makes the hCard always roughly as wide as 28 characters (strictly speaking 28 times the width of the letter capital M). \n\nSo the statement for our containing vcard element becomes\n\n.vcard {\n\tbackground-image: url(images/vcardfill.png);\n\tbackground-repeat: no-repeat;\n\tcolor: #666;\n\tfont-family: \"Lucida Grande\", Verdana, Helvetica, Arial, sans-serif;\n\twidth: 28em;\n}\n\nand now our element will look like this\n\n\n\nWe\u2019ve used almost entirely the existing HTML from our original hCard (adding just a little, and trying as much as possible to keep that additional markup meaningful), and just 6 CSS statements.\n\nHoliday Bonus \u2013 a downloadable vCard\n\nDid you notice this part of the HTML\n\n\n \"download\n\nWhat\u2019s with the odd looking url\n\n tag for each and naturally went to click on the text rather than the form control itself, he was going straight for the control (and missing the sneaky little I\u2019d placed around the text). Bah! There goes my time-saver.\n\nSo, what did I learn? That a web professional who has used the Internet for years had neither heard of the Play the animation\n\nThis could be rewritten by removing the onclick attribute, and instead doing the following from within your JavaScript.\n\ndocument.getElementById('anim-link').onclick = playAnimation;\n\nIt\u2019s all in the timing\n\nOf course, it\u2019s never quite that easy. To be able to attach that onclick, the element you\u2019re targeting has to exist in the page, and the page has to have finished loading for the DOM to be available. This is where the onload event is handy, as it fires once everything has finished loading. Common practise is to have a function called something like init() (short for initialise) that sets up all these event handlers as soon as the page is ready.\n\nBack in the day we would have used the onload attibute on the element to do this, but of course what we really want is:\n\nwindow.onload = init;\n\nAs an interesting side note, we\u2019re using init here rather than init() so that the function is assigned to the event. If we used the parentheses, the init function would have been run at that moment, and the result of running the function (rather than the function itself) would be assigned to the event. Subtle, but important.\n\nAs is becoming apparent, nothing is ever simple, and we can\u2019t just go around assigning our initialisation function to window.onload. What if we\u2019re using other scripts in the page that might also want to listen out for that event? Whichever script got there last would overwrite everything that came before it. To manage this, we need a script that checks for any existing event handlers, and adds the new handler to it. Most of the JavaScript libraries have their own systems for doing this. If you\u2019re not using a library, Simon Willison has a good stand-alone example\n\nfunction addLoadEvent(func) {\n\tvar oldonload = window.onload;\n\tif (typeof window.onload != 'function') {\n\t\twindow.onload = func;\n\t} else {\n\t\twindow.onload = function() {\n\t\t\tif (oldonload) {\n\t\t\t\toldonload();\n\t\t\t}\n\t\t\tfunc();\n\t\t}\n\t}\n}\n\nObviously this is just a toe in the events model\u2019s complex waters. Some good further reading is PPK\u2019s Introduction to Events.\n\nCarving out your own space\n\nAnother problem that rears its ugly head when combining multiple scripts on a single page is that of making sure that the scripts don\u2019t conflict. One big part of that is ensuring that no two scripts are trying to create functions or variables with the same names. Reusing a name in JavaScript just over-writes whatever was there before it.\n\nWhen you create a function in JavaScript, you\u2019ll be familiar with doing something like this.\n\nfunction foo() {\n\t... goodness ...\n}\n\nThis is actually just creating a variable called foo and assigning a function to it. It\u2019s essentially the same as the following.\n\nvar foo = function() {\n\t... goodness ...\n}\n\nThis name foo is by default created in what\u2019s known as the \u2018global namespace\u2019 \u2013 the general pool of variables within the page. You can quickly see that if two scripts use foo as a name, they will conflict because they\u2019re both creating those variables in the global namespace.\n\nA good solution to this problem is to add just one name into the global namespace, make that one item either a function or an object, and then add everything else you need inside that. This takes advantage of JavaScript\u2019s variable scoping to contain you mess and stop it interfering with anyone else.\n\nCreating An Object\n\nSay I was wanting to write a bunch of functions specifically for using on a site called \u2018Foo Online\u2019. I\u2019d want to create my own object with a name I think is likely to be unique to me.\n\nvar FOOONLINE = {};\n\nWe can then start assigning functions are variables to it like so:\n\nFOOONLINE.message = 'Merry Christmas!';\nFOOONLINE.showMessage = function() {\n\talert(this.message);\n};\n\nCalling FOOONLINE.showMessage() in this example would alert out our seasonal greeting. The exact same thing could also be expressed in the following way, using the object literal syntax.\n\nvar FOOONLINE = {\n\tmessage: 'Merry Christmas!',\n\tshowMessage: function() {\n\t\talert(this.message);\n\t}\n};\n\nCreating A Function to Create An Object\n\nWe can extend this idea bit further by using a function that we run in place to return an object. The end result is the same, but this time we can use closures to give us something like private methods and properties of our object.\n\nvar FOOONLINE = function(){\n\tvar message = 'Merry Christmas!';\n\treturn {\n\t\tshowMessage: function(){\n\t\t\talert(message);\n\t\t}\n\t}\n}();\n\nThere are two important things to note here. The first is the parentheses at the end of line 10. Just as we saw earlier, this runs the function in place and causes its result to be assigned. In this case the result of our function is the object that is returned at line 4.\n\nThe second important thing to note is the use of the var keyword on line 2. This ensures that the message variable is created inside the scope of the function and not in the global namespace. Because of the way closure works (which if you\u2019re not familiar with, just suspend your disbelief for a moment) that message variable is visible to everything inside the function but not outside. Trying to read FOOONLINE.message from the page would return undefined.\n\nThis is useful for simulating the concept of private class methods and properties that exist in other programming languages. I like to take the approach of making everything private unless I know it\u2019s going to be needed from outside, as it makes the interface into your code a lot clearer for someone else to read. \n\nAll Change, Please\n\nSo that was just a whistle-stop tour of a couple of the bigger changes that can help to make your scripts better page citizens. I hope it makes useful Sunday reading, but obviously this is only the tip of the iceberg when it comes to designing modular, reusable code.\n\nFor some, this is all familiar ground already. If that\u2019s the case, I encourage you to perhaps submit a comment with any useful resources you\u2019ve found that might help others get up to speed. Ultimately it\u2019s in all of our interests to make sure that all our JavaScript interoperates well \u2013 share your tips.", "year": "2006", "author": "Drew McLellan", "author_slug": "drewmclellan", "published": "2006-12-10T00:00:00+00:00", "url": "https://24ways.org/2006/writing-responsible-javascript/", "topic": "code"} {"rowid": 143, "title": "Marking Up a Tag Cloud", "contents": "Everyone\u2019s doing it. \n\nThe problem is, everyone\u2019s doing it wrong. \n\nHarsh words, you might think. But the crimes against decent markup are legion in this area. You see, I\u2019m something of a markup and semantics junkie. So I\u2019m going to analyse some of the more well-known tag clouds on the internet, explain what\u2019s wrong, and then show you one way to do it better. \n\ndel.icio.us \n\nI think the first ever tag cloud I saw was on del.icio.us. Here\u2019s how they mark it up. \n\n
    \n\t.net\n\tadvertising\n\tajax\n\t...\n
    \n\nUnfortunately, that is one of the worst examples of tag cloud markup I have ever seen. The page states that a tag cloud is a list of tags where size reflects popularity. However, despite describing it in this way to the human readers, the page\u2019s author hasn\u2019t described it that way in the markup. It isn\u2019t a list of tags, just a bunch of anchors in a
    . This is also inaccessible because a screenreader will not pause between adjacent links, and in some configurations will not announce the individual links, but rather all of the tags will be read as just one link containing a whole bunch of words. Markup crime number one. \n\nFlickr \n\nAh, Flickr. The darling photo sharing site of the internet, and the biggest blind spot in every standardista\u2019s vision. Forgive it for having atrocious markup and sometimes confusing UI because it\u2019s just so much damn fun to use. Let\u2019s see what they do. \n\n

    \n\t\u00a006\u00a0\n\t\u00a0africa\u00a0\n\t\u00a0amsterdam\u00a0\n\t...\n

    \n\nAgain we have a simple collection of anchors like del.icio.us, only this time in a paragraph. But rather than using a class to represent the size of the tag they use an inline style. An inline style using a pixel-based font size. That\u2019s so far away from the goal of separating style from content, they might as well use a tag. You could theoretically parse that to extract the information, but you have more work to guess what the pixel sizes represent. Markup crime number two (and extra jail time for using non-breaking spaces purely for visual spacing purposes.)\n\nTechnorati \n\nAh, now. Here, you\u2019d expect something decent. After all, the Overlord of microformats and King of Semantics Tantek \u00c7elik works there. Surely we\u2019ll see something decent here? \n\n
      \n\t
    1. Britney Spears
    2. \n\t
    3. Bush
    4. \n\t
    5. Christmas
    6. \n\t...\n\t
    7. SEO
    8. \n\t
    9. Shopping
    10. \n\t...\n
    \n\nUnfortunately it turns out not to be that decent, and stop calling me Shirley. It\u2019s not exactly terrible code. It does recognise that a tag cloud is a list of links. And, since they\u2019re in alphabetical order, that it\u2019s an ordered list of links. That\u2019s nice. However \u2026 fifteen nested tags? FIFTEEN? That\u2019s emphasis for you. Yes, it is parse-able, but it\u2019s also something of a strange way of looking at emphasis. The HTML spec states that is emphasis, and is for stronger emphasis. Nesting tags seems counter to the idea that different tags are used for different levels of emphasis. Plus, if you had a screen reader that stressed the voice for emphasis, what would it do? Shout at you? Markup crime number three. \n\nSo what should it be? \n\nAs del.icio.us tells us, a tag cloud is a list of tags where the size that they are rendered at contains extra information. However, by hiding the extra context purely within the CSS or the HTML tags used, you are denying that context to some users. The basic assumption being made is that all users will be able to see the difference between font sizes, and this is demonstrably false. \n\nA better way to code a tag cloud is to put the context of the cloud within the content, not the markup or CSS alone. As an example, I\u2019m going to take some of my favourite flickr tags and put them into a cloud which communicates the relative frequency of each tag. \n\nTo start with a tag cloud in its most basic form is just a list of links. I am going to present them in alphabetical order, so I\u2019ll use an ordered list. Into each list item I add the number of photos I have with that particular tag. The tag itself is linked to the page on flickr which contains those photos. So we end up with this first example. To display this as a traditional tag cloud, we need to alter it in a few ways: \n\n\n\tThe items need to be displayed next to each other, rather than one-per-line\n\tThe context information should be hidden from display (but not from screen readers)\n\tThe tag should link to the page of items with that tag\n\n\nDisplaying the items next to each other simply means setting the display of the list elements to inline. The context can be hidden by wrapping it in a and then using the off-left method to hide it. And the link just means adding an anchor (with rel=\"tag\" for some extra microformats bonus points). So, now we have a simple collection of links in our second example. \n\nThe last stage is to add the sizes. Since we already have context in our content, the size is purely for visual rendering, so we can just use classes to define the different sizes. For my example, I\u2019ll use a range of class names from not-popular through ultra-popular, in order of smallest to largest, and then use CSS to define different font sizes. If you preferred, you could always use less verbose class names such as size1 through size6. Anyway, adding some classes and CSS gives us our final example, a semantic and more accessible tag cloud.", "year": "2006", "author": "Mark Norman Francis", "author_slug": "marknormanfrancis", "published": "2006-12-09T00:00:00+00:00", "url": "https://24ways.org/2006/marking-up-a-tag-cloud/", "topic": "code"} {"rowid": 131, "title": "Random Lines Made With Mesh", "contents": "I know that Adobe Illustrator can be a bit daunting for people who aren\u2019t really advanced users of the program, but you would be amazed by how easy you can create cool effects or backgrounds. In this short tutorial I show you how to create a cool looking background only in 5 steps. \n\nStep 1 \u2013 Create Lines\n\n\n\nCreate lines using random widths and harmonious suitable colors. If you get stuck on finding the right colors, check out Adobe\u2019s Kuler and start experimenting.\n\nStep 2 \u2013 Convert Strokes to Fills\n\n\n\nSelect all lines and convert them to fills. Go to the Object menu, select Path > Outline Stroke. Select the Rectangle tool and draw 1 big rectangle on top the lines. Give the rectangle a suitable color. With the rectangle still selected, go to the Object menu, select Arrange > Send to Back.\n\nStep 3 \u2013 Convert to Mesh\n\n\n\nSelect all objects by pressing the command key (for Mac users), control key (for Windows users) + the \u201ca\u201d key. Go to the Object menu and select the Envelope Distort > Make with Mesh option. Enter 2 rows and 2 columns. Check the preview box to see what happens and click the OK button.\n\nStep 4 \u2013 Play Around with The Mesh Points \n\n\n\nPlay around with the points of the mesh using the Direct Selection tool (the white arrow in the Toolbox). Click on the top right point of the mesh. Once you\u2019re starting to drag hold down the shift key and move the point upwards. \n\n\n\nNow start dragging the bezier handles on the mesh to achieve the effect as shown in the above picture. Of course you can try out all kind of different effects here. \n\nThe Final Result\n\n\n\nThis is an example of how the final result can look. You can try out all kinds of different shapes dragging the handles of the mesh points. This is just one of the many results you can get. So next time you haven\u2019t got inspiration for a background of a header, a banner or whatever, just experiment with a few basic shapes such as lines and try out the \u2018Envelope Distort\u2019 options in Illustrator or the \u2018Make with Mesh\u2019 option and experiment, you\u2019ll be amazed by the unexpected creative results.", "year": "2006", "author": "Veerle Pieters", "author_slug": "veerlepieters", "published": "2006-12-08T00:00:00+00:00", "url": "https://24ways.org/2006/random-lines-made-with-mesh/", "topic": "design"} {"rowid": 136, "title": "Making XML Beautiful Again: Introducing Client-Side XSL", "contents": "Remember that first time you saw XML and got it? When you really understood what was possible and the deep meaning each element could carry? Now when you see XML, it looks ugly, especially when you navigate to a page of XML in a browser. Well, with every modern browser now supporting XSL 1.0, I\u2019m going to show you how you can turn something as simple as an ATOM feed into a customised page using a browser, Notepad and some XSL.\n\nWhat on earth is this XSL?\n\nXSL is a family of recommendations for defining XML document transformation and presentation. It consists of three parts:\n\n\n\tXSLT 1.0 \u2013 Extensible Stylesheet Language Transformation, a language for transforming XML\n\tXPath 1.0 \u2013 XML Path Language, an expression language used by XSLT to access or refer to parts of an XML document. (XPath is also used by the XML Linking specification)\n\tXSL-FO 1.0 \u2013 Extensible Stylesheet Language Formatting Objects, an XML vocabulary for specifying formatting semantics\n\n\nXSL transformations are usually a one-to-one transformation, but with newer versions (XSL 1.1 and XSL 2.0) its possible to create many-to-many transformations too. So now you have an overview of XSL, on with the show\u2026\n\nSo what do I need?\n\nSo to get going you need a browser an supports client-side XSL transformations such as Firefox, Safari, Opera or Internet Explorer. Second, you need a source XML file \u2013 for this we\u2019re going to use an ATOM feed from Flickr.com. And lastly, you need an editor of some kind. I find Notepad++ quick for short XSLs, while I tend to use XMLSpy or Oxygen for complex XSL work. \n\nBecause we\u2019re doing a client-side transformation, we need to modify the XML file to tell it where to find our yet-to-be-written XSL file. Take a look at the source XML file, which originates from my Flickr photos tagged sky, in ATOM format.\n\nThe top of the ATOM file now has an additional instruction, as can been seen on Line 2 below. This instructs the browser to use the XSL file to transform the document.\n\n\n\n\n\nYour first transformation\n\nYour first XSL will look something like this:\n\n\n\n\t\n\n\nThis is pretty much the starting point for most XSL files. You will notice the standard XML processing instruction at the top of the file (line 1). We then switch into XSL mode using the XSL namespace on all XSL elements (line 2). In this case, we have added namespaces for ATOM (line 4) and Dublin Core (line 5). This means the XSL can now read and understand those elements from the source XML. \n\nAfter we define all the namespaces, we then move onto the xsl:output element (line 6). This enables you to define the final method of output. Here we\u2019re specifying html, but you could equally use XML or Text, for example. The encoding attributes on each element do what they say on the tin. As with all XML, of course, we close every element including the root.\n\nThe next stage is to add a template, in this case an as can be seen below:\n\n\n\n\t\n\t\n\t\t\n\t\t\t\n\t\t\t\tMaking XML beautiful again : Transforming ATOM\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\n\n\nThe beautiful thing about XSL is its English syntax, if you say it out loud it tends to make sense. \n\nThe / value for the match attribute on line 8 is our first example of XPath syntax. The expression / matches any element \u2013 so this will match against any element in the document. As the first element in any XML document is the root element, this will be the one matched and processed first.\n\nOnce we get past our standard start of a HTML document, the only instruction remaining in this is to look for and match all elements using the in line 14, above.\n\n\n\n\t\n\t\n\t\t\n\t\n\t\n\t\t
    \n\t\t\t

    \n\t\t\t\t\n\t\t\t

    \n\t\t\t

    \n\t\t\t\t\n\t\t\t

    \n\t\t\t
      \n\t\t\t\t\n\t\t\t
    \n\t\t
    \n\t
    \n
    \n\nThis new template (line 12, above) matches and starts to write the new HTML elements out to the output stream. The does exactly what you\u2019d expect \u2013 it finds the value of the item specifed in its select attribute. With XPath you can select any element or attribute from the source XML. \n\nThe last part is a repeat of the now familiar from before, but this time we\u2019re using it inside of a called template. Yep, XSL is full of recursion\u2026\n\n\n\t
  • \n\t\t

    \n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t

    \n\t\t

    \n\t\t\t()\n\t\t

    \n\t\t

    \n\t\t\t\n\t\t

    \n\t\t\n\t
  • \n
    \n\nThe which matches atom:entry (line 1) occurs every time there is a element in the source XML file. So in total that is 20 times, this is naturally why XSLT is full of recursion. This has been matched and therefore called higher up in the document, so we can start writing list elements directly to the output stream. The first part is simply a

    with a link wrapped within it (lines 3-7). We can select attributes using XPath using @. \n\nThe second part of this template selects the date, but performs a XPath string function on it. This means that we only get the date and not the time from the string (line 9). This is achieved by getting only the part of the string that exists before the T. \n\nRegular Expressions are not part of the XPath 1.0 string functions, although XPath 2.0 does include them. Because of this, in XSL we tend to rely heavily on the available XML output. \n\nThe third part of the template (line 12) is a again, but this time we use an attribute of called disable output escaping to turn escaped characters back into XML. \n\nThe very last section is another call, taking us three templates deep. Do not worry, it is not uncommon to write XSL which go 20 or more templates deep!\n\n\n\t\n\t\t\n\t\t\t\n\t\t\t\ttag\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\n\t\t \n\t\n\n\nIn our final , we see a combination of what we have done before with a couple of twists. Once we match atom:category we then count how many elements there are at that same level (line 2). The XPath . means \u2018self\u2019, so we count how many category elements are within the element. \n\nFollowing that, we start to output a link with a rel attribute of the predefined text, tag (lines 4-6). In XSL you can just type text, but results can end up with strange whitespace if you do (although there are ways to simply remove all whitespace). \n\nThe only new XPath function in this example is concat(), which simply combines what XPaths or text there might be in the brackets. We end the output for this tag with an actual tag name (line 10) and we add a space afterwards (line 12) so it won\u2019t touch the next tag. (There are better ways to do this in XSL using the last() XPath function). \n\nAfter that, we go back to the element again if there is another category element, otherwise we end the loop and end this .\n\nA touch of style\n\nBecause we\u2019re using recursion through our templates, you will find this is the end of the templates and the rest of the XML will be ignored by the parser. Finally, we can add our CSS to finish up. (I have created one for Flickr and another for News feeds)\n\n\n\nSo we end up with a nice simple to understand but also quick to write XSL which can be used on ATOM Flickr feeds and ATOM News feeds. With a little playing around with XSL, you can make XML beautiful again.\n\nAll the files can be found in the zip file (14k)", "year": "2006", "author": "Ian Forrester", "author_slug": "ianforrester", "published": "2006-12-07T00:00:00+00:00", "url": "https://24ways.org/2006/beautiful-xml-with-xsl/", "topic": "code"} {"rowid": 121, "title": "Hide And Seek in The Head", "contents": "If you want your JavaScript-enhanced pages to remain accessible and understandable to scripted and noscript users alike, you have to think before you code. Which functionalities are required (ie. should work without JavaScript)? Which ones are merely nice-to-have (ie. can be scripted)? You should only start creating the site when you\u2019ve taken these decisions.\n\nSpecial HTML elements\n\nOnce you have a clear idea of what will work with and without JavaScript, you\u2019ll likely find that you need a few HTML elements for the noscript version only.\n\nTake this example: A form has a nifty bit of Ajax that automatically and silently sends a request once the user enters something in a form field. However, in order to preserve accessibility, the user should also be able to submit the form normally. So the form should have a submit button in noscript browsers, but not when the browser supports sufficient JavaScript.\n\nSince the button is meant for noscript browsers, it must be hard-coded in the HTML:\n\n\n\nWhen JavaScript is supported, it should be removed:\n\nvar checkJS = [check JavaScript support];\nwindow.onload = function () {\n\tif (!checkJS) return;\n\tdocument.getElementById('noScriptButton').style.display = 'none';\n}\n\nProblem: the load event\n\nAlthough this will likely work fine in your testing environment, it\u2019s not completely correct. What if a user with a modern, JavaScript-capable browser visits your page, but has to wait for a huge graphic to load? The load event fires only after all assets, including images, have been loaded. So this user will first see a submit button, but then all of a sudden it\u2019s removed. That\u2019s potentially confusing.\n\nFortunately there\u2019s a simple solution: play a bit of hide and seek in the :\n\nvar checkJS = [check JavaScript support];\nif (checkJS) {\n\tdocument.write('');\n}\n\nFirst, check if the browser supports enough JavaScript. If it does, document.write an extra