Lots of brain food here - and enough sample code to get you in serious trouble :)
Ahhh. Light goes on. This post shows how to open a file in perl using a particular encoding, which was a faq I guess I never read. It would explain all manner of weirdness and problems I’ve had with encodings, entities and so on.
Knew this must exist somewhere, but didn’t occur to me to look on sourceforge. Add this to my todo list - my resume markup looks like it will map pretty easily to theirs. The project is basically a DTD, with some documentation, and ready-made XSL stylesheets for transforming the XML source into plain text, RTF, HTML and FO (thence to PDF via FOP).
Ha! Ajax. Is that what they call it now? I’m no veteran developer of this stuff, but I’ve watched it emerge as a solution repeatedly. Kind of like how evolution seems to spontaneously throw up the same answer to the same problem in completely unconnected species. My amusement is just that it is the dubbing of the thing - the naming event - that makes it article-worthy (and blog-worthy).
Well I’m all for giving it a name everyone can agree on if it will collect everyone around some common best practices. And I can think of no better place to start the ball rolling than at Adaptive Path.
Now lets roll up sleeves and make it happen.
This page had some answers to some of the stumbling blocks I’ve enountered while dealing with HTML with XML tools and processes.
Finally I’ve got most of the “Lentil 1.0” redesign of Sam-I-Am.com uploaded. This blog (and the others) still need proper templates, but its 99% there otherwise.
I’ve gone with a content-driven model, where the html I store on my server is my structured content, data and meta information all in one standardized and well known format: (x)html. Navigation is built off of an xml structure I build of the directory tree, and transformed via XSLT to make my left nav, and queried to build the breadcrumbs, sitemap and so on.
An apache Handler is defined to route requests for html files through my perl cgi script. It does several jobs, extracting metadata, splicing the content into its presentation template and including the static and navigation pieces. A cacheing layer ensures this expense is only paid when a necessary - checking the content, template and a few other lastModified dates before retrieving the stored, pre-built page from a filesystem based cache.
I got to use a lot of great modules (e.g CGI::Application, HTML::Template, XML::LibXML/XSLT, Cache::FileCache) and wrote a few of my own, gaining significant code reuse across the main handler cgi, the admin interface, 404 handler, directoryIndex handler etc.
Client-side coding: its an all CSS layout; validating XHTML (bar the use of a few iframes); flexible width; highly accessible - with user-scalable fonts, a sensible content flow (roughly: page heading, synopsis, breadcrumbs, main content, main nav and persistent nav) augmented with jump-to links to quickly reach the navigation. Some sparing use of DHTML adds rollovers on the navigation, without cluttering the markup with event handlers.
IA: I’ve reorganized a little, grouping content under 3 main silos: Work, Personal and Play. The physical directory structure is changed in some areas, others not. My 404 handler uses a moved URL lookup file to attempt to either redirect to a new location or suggest a starting point where a 1:1 match cant be made. Its all a part of my “No Page Left Behind” philosophy, fighting link rot at its source - home pages like this.
Phew. It wont pretend it came easy. But it was fun, I learnt lots, and hopefully it’ll make whats already here easier to use and allow for pain-free growth and evolution.
This was new to me. The HTTP Response header can use a status code ‘204 No Content’. This tells the user-agent not to expect any response content, and so to not refresh the current page. For simple interactions where you want to keep the server current on a users selections it looks useful.
Here’s some (old but interesting) browser test results. There’s apparently some disagreement on whether response content accompanying a 204 is an error, or should just be ignored. The safe bet seems to be to not send any content body.
After a little stumbling around looking for a way to create my favicon.ico (favicon.com has withdrawn the nice service they had there for a while), I came across Telegraphics and this file format plugin. It was reportedly tested for Photoshop 4, but I just dropped it into my Plug-Ins\File Formats folder for Photoshop 7 and it worked just great - just Save As: .ico
When I get back in the office I’ll take a closer look at what it actually output in IconFactory, but so far so good in Firefox and windows IE 6.
This is an interesting piece outlining one designer’s process for coming up with web design comps. This addresses some common issues and starting in a vector format gives you some tools for accommodating different browser widths, content lengths, font/graphic proportions.
I agree wholly with his point that moving into the target medium too soon (html/css) is limiting - you can easily end up with colored boxes with varying borders and padding/margins (sound familiar?). But the interactive aspects of a page, and the different uses and contexts a given template might be used in (lots of content, no content) are still a problem. Yes, you can iterate over a load of cases - but who really has time to explore all the options, with every design variation? This needs to be made easier by the tool.
This is where working in the medium can be valuable. Once in html/css, its easier to test a comp by screwing with the browser (expand/contract, bump font sizes up/down, employ your various bookmarklets for grey scaling / graphics off / css off / override color/background colors etc, as well as pushing more/less content into the various content areas.
There’s obviously a balance to be had, and a good process would start with sketching; defining layout and content/design element placement; some visual treatments; prototype in target medium; repeat. The key is that there be a full feedback loop through each step. The more cumbersome any one step is, the less likely it is to be employed with any frequency.
This tutorial goes a little deeper than most.. probably a good bridge between the usual 1 page overview and Jeffrey Friedl’s Mastering Regular Expressions.