{"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\t\t\t\t
\n\t\t\t(
\n\t\t\t
and its cite attribute. \n\n\n\t\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\nThis project will use XHTML1.0 Strict, CSS2.1 and all that malarkey.
\n\n\t
\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- \n\t\t
\n\t\n\t\t\t\n\tThis project will use XHTML1.0 Strict, CSS2.1 and all that malarkey.
\n\t\t- \n\t\t
\n\n\t\t\t\n\tThose bits are simple and bulletproof.
\n\t\t\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 eachand 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\n\t\t\nThis project will use XHTML1.0 Strict, CSS2.1 and all that malarkey.
\n\t\n\t \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": 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": 130, "title": "Faster Development with CSS Constants", "contents": "Anyone even slightly familiar with a programming language will have come across the concept of constants \u2013 a fixed value that can be used through your code. For example, in a PHP script I might have a constant which is the email address that all emails generated by my application get sent to. \n\n$adminEmail = 'info@example.com';\n\nI could then use $adminEmail in my script whenever I wanted an email to go to that address. The benefit of this is that when the client decides they want the email to go to a different address, I only need change it in one place \u2013 the place where I initially set the constant. I could also quite easily make this value user defined and enable the administrator to update the email address.\n\nUnfortunately CSS doesn\u2019t support constants. It would be really useful to be able to define certain values initially and then use them throughout a CSS file, so in this article I\u2019m going to take a look at some of the methods we do have available and provide pointers to more in depth commentary on each. If you have a different method, or tip to share please add it to the comments.\n\nSo what options do we have?\n\nOne way to get round the lack of constants is to create some definitions at the top of your CSS file in comments, to define \u2018constants\u2019. A common use for this is to create a \u2018color glossary\u2019. This means that you have a quick reference to the colors used in the site to avoid using alternates by mistake and, if you need to change the colors, you have a quick list to go down and do a search and replace. \n\nIn the below example, if I decide I want to change the mid grey to #999999, all I need to do is search and replace #666666 with #999999 \u2013 assuming I\u2019ve remember to always use that value for things which are mid grey.\n\n/*\nDark grey (text): #333333\nDark Blue (headings, links) #000066\nMid Blue (header) #333399\nLight blue (top navigation) #CCCCFF\nMid grey: #666666\n*/\n\nThis is a fairly low-tech method, but if used throughout the development of the CSS files can make changes far simpler and help to ensure consistency in your color scheme.\n\nI\u2019ve seen this method used by many designers however Garrett Dimon documents the method, with more ideas in the comments.\n\nGoing server-side\n\nTo truly achieve constants you will need to use something other than CSS to process the file before it is sent to the browser. You can use any scripting language \u2013 PHP, ASP, ColdFusion etc. to parse a CSS file in which you have entered constants. So that in a constants section of the CSS file you would have:\n\n$darkgrey = '#333333';\n$darkblue = '#000066';\n\nThe rest of the CSS file is as normal except that when you come to use the constant value you would use the constant name instead of adding the color:\n\np {\n\tcolor: $darkgrey;\n}\n\nYour server-side script could then parse the CSS file, replace the constant names with the constant values and serve a valid CSS file to the browser. Christian Heilmann has done just this for PHP however this could be adapted for any language you might have available on your server.\n\nShaun Inman came up with another way \n of doing this that removes the need to link to a PHP script and also enables the adding of constants using the syntax of at-rules . This method is again using PHP and will require you to edit an .htaccess file. \n\nA further method is to generate static CSS files either using a script locally \u2013 if the constants are just to enable speed of development \u2013 or as part of the web application itself. Storing a template stylesheet with constant names in place of the values you will want to update means that your script can simply open the template, replace the variables and save the result as a new stylesheet file.\n\nWhile CSS constants are a real help to developers, they can also be used to add new functionality to your applications. As with the email address example that I used at the beginning of this article, using a combination of CSS and server-side scripting you could enable a site administrator to select the colours for a new theme to be used on a page of a content managed site. By using constants you need only give them the option to change certain parts of the CSS and not upload a whole different CSS file, which could lead to some interesting results!\n\nAs we are unlikely to find real CSS constants under the tree this Christmas the above methods are some possibilities for better management of your stylesheets. However if you have better methods, CSS Constant horror stories or any other suggestions, add your comments below.", "year": "2006", "author": "Rachel Andrew", "author_slug": "rachelandrew", "published": "2006-12-02T00:00:00+00:00", "url": "https://24ways.org/2006/faster-development-with-css-constants/", "topic": "process"} {"rowid": 139, "title": "Flickr Photos On Demand with getFlickr", "contents": "In case you don\u2019t know it yet, Flickr is great. It is a lot of fun to upload, tag and caption photos and it is really handy to get a vast network of contacts through it. \n\nUsing Flickr photos outside of it is a bit of a problem though. There is a Flickr API, and you can get almost every page as an RSS feed, but in general it is a bit tricky to use Flickr photos inside your blog posts or web sites. You might not want to get into the whole API game or use a server side proxy script as you cannot retrieve RSS with Ajax because of the cross-domain security settings.\n\nHowever, Flickr also provides an undocumented JSON output, that can be used to hack your own solutions in JavaScript without having to use a server side script.\n\n\n\tIf you enter the URL http://flickr.com/photos/tags/panda you get to the flickr page with photos tagged \u201cpanda\u201d.\n\tIf you enter the URL http://api.flickr.com/services/feeds/photos_public.gne?tags=panda&format=rss_200 you get the same page as an RSS feed.\n\tIf you enter the URL http://api.flickr.com/services/feeds/photos_public.gne?tags=panda&format=json you get a JavaScript function called jsonFlickrFeed with a parameter that contains the same data in JSON format\n\n\nYou can use this to easily hack together your own output by just providing a function with the same name. I wanted to make it easier for you, which is why I created the helper getFlickr for you to download and use.\n\ngetFlickr for Non-Scripters\n\nSimply include the javascript file getflickr.js and the style getflickr.css in the head of your document:\n\n\n\n\nOnce this is done you can add links to Flickr pages anywhere in your document, and when you give them the CSS class getflickrphotos they get turned into gallery links. When a visitor clicks these links they turn into loading messages and show a \u201cpopup\u201d gallery with the connected photos once they were loaded. As the JSON returned is very small it won\u2019t take long. You can close the gallery, or click any of the thumbnails to view a photo. Clicking the photo makes it disappear and go back to the thumbnails.\n\nCheck out the example page and click the different gallery links to see the results.\n\nNotice that getFlickr works with Unobtrusive JavaScript as when scripting is disabled the links still get to the photos on Flickr.\n\ngetFlickr for JavaScript Hackers\n\nIf you want to use getFlickr with your own JavaScripts you can use its main method leech():\n\ngetFlickr.leech(sTag, sCallback);\n\n \n\tsTag\n\tthe tag you are looking for\n\tsCallback\n\tan optional function to call when the data was retrieved.\n \n\nAfter you called the leech() method you have two strings to use:\n\n \n\tgetFlickr.html[sTag]\n\tcontains an HTML list (without the outer UL element) of all the images linked to the correct pages at flickr. The images are the medium size, you can easily change that by replacing _m.jpg with _s.jpg for thumbnails.\n\tgetFlickr.tags[sTag]\n\tcontains a string of all the other tags flickr users added with the tag you searched for(space separated)\n \n\nYou can call getFlickr.leech() several times when the page has loaded to cache several result feeds before the page gets loaded. This\u2019ll make the photos quicker for the end user to show up. If you want to offer a form for people to search for flickr photos and display them immediately you can use the following HTML:\n\n\n\nAll the JavaScript you\u2019ll need (for a basic display) is this:\n\nfunction populate(){\n var tag = document.getElementById('tag').value;\n document.getElementById('photos').innerHTML = getFlickr.html[tag].replace(/_m\\.jpg/g,'_s.jpg');\n document.getElementById('tags').innerHTML = getFlickr.tags[tag];\n return false;\n}\n\nEasy as pie, enjoy!\n\nCheck out the example page and try the form to see the results.", "year": "2006", "author": "Christian Heilmann", "author_slug": "chrisheilmann", "published": "2006-12-03T00:00:00+00:00", "url": "https://24ways.org/2006/flickr-photos-on-demand/", "topic": "code"} {"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\t\nThose bits are simple and bulletproof.
\n\t\n\t\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": 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\n\t\t\nGravity-Defying!
\n\t\tLorem ipsum dolor ...
\n\t