http://www.dind.com/blog/xhtml/ en-us Fri, 18 May 2012 20:06:58 PDT Fri, 18 May 2012 20:06:58 PDT SiteCrafting.com GearBox 1.1 (beta) http://www.sitecrafting.com/blog/nested-table-abyss-1/ While I was taking some time to evaluate a 3rd-party application for a customer I took a peak at their site's HTML. I was pretty shocked when I found some very strictly organized code that contained gobs of nested tables. At one count I found a structure that was 10 tables deep! I suppose since enjoying creating clean mark-up and mostly table-less designs for the last few years I've forgotten my roots.Warning: Don't click to enlarge the following unless you have a strong stomach.Table-heavy layouts used to be big and I was certainly guilty of a few back 'round the turn of the century. Nevertheless, it's pretty shocking for me to see pages laid out like this today. They are even kind enough to include plenty of inline styles so we know what's what color. Yikes! I'm pretty sure I speak for everyone here in the office when I say, "Good riddance!"Tables are good for propping food up to where it's easily eaten not for propping up modern web designs. Fri, 13 Oct 2006 16:56:00 PDT http://www.sitecrafting.com/blog/navigation-nightmare-pt-1-1/ foreach ($left_elements AS $le) {    ?>    <table class="leftnav_<?=$le['class']?>">        <tr>            <td class="leftnav_<?=$le['class']?>">                <a href="<?=$le['target']?>" class="<?=$le['theme']?>"><?=$le['name']?></a>            </td>        </tr>    </table>    <?}Nobody wants to see that. Especially not seven different times with seven tiny variants covering seven different if conditions.Each higher 'class' number is a deeper indentation. Apparently it's necessary for this class identification to be repeated for the table, table cell and link. Converting this to a nested list format (part of my current task) is going to be an adventure.Well... at least it's indented nicely. Wed, 18 Oct 2006 10:46:00 PDT http://www.sitecrafting.com/blog/bulletproof-critique/ I ran across a neat article from Sitepoint via Stylegala that you all should read on how to make your HTML 'perfect'. In the world of design, the concept of perfect is non-existant. There is no solution that will work for solving every problem, and there are exceptions to every rule. This article is no different. Read the full article, and then check out my comments.FAQ #1-#7I can't really say anything about these, because they are factual definitions.#8 Yes, HTML 4.01 Strict is a good choice, but XHTML 1.0 Strict, or even better, XHTML 1.1, is preferable. If you need to use deprecated tags or attributes, you really should use HTML 4.01 Transitional. We use XHTML 1.1, for a number of reasons, but we do use some prohibited attrributes (title on tags other than abbr and acronym, target) and syntax (our rich text editor in the cms mucks up the code). We do this because we know the strengths and weaknesses of each decision we make, and we don't make them lightly.#9It's good to make sure your markup validates, but I know that this article won't and I know why. Some errors can be tolerated (like the ending '/' on image tags.), and some can't - a misplaced </table> destroys your layout.#10Too many times I've seen sites where the HTML was terrible, but it rendered properly. Most designers want to make their sites look right, but it's the attention to detail that separates the good from the great.#11-#14Again with factual definitions. I also got bored halfway through #12 - Charset.#15Be careful with using character entities outsite your charset, because The entire range from  through Ÿ are invalid characters. I bet you didn't know that, did you? It's ok, I didn't either until I read this article on A List Apart.#16-#18Not a whole lot I can say about these, but there are some details to pay attention to, like using h# tags in sequential order.#19You can make block level elements look like inline elements, or inline elements look like they are block I am a div displayed inline, and so am I.and I am a span displayed block.The article states this, but I wanted to make a little clearer.#20 & #21If you didn't know this already, please make sure to read it again.#22This item should have been much earlier in the article, at least #8. They've been using semantic for awhile, but they just get around to defining it  now?#23Again, make sure you are using the tags as they were meant to be used. If something needs to be italic, use <i>, if it needs emphasis, use <em>.#24This deserves to be said again: table layouts are bad, for all the reasons in the article.#25<div> is not the new <table>, and documents should not have <div> soup. The div element is a generic block-level tag. It is best used to store other elements in meaningfully connected ways. For example, <div id="header"> is common here, but having six div's within that for each the page title, navigation, login information, and to separate those items is bad. Be like us, resist the urge to replace <table> with <div>#26Just remember to use <table> for the right reason.#27-#31This is all very useful information, much of which I didn't know. Make sure you get it all.#32I would much rather use target="_blank" than Javascript to open new windows, especially because all browsers support the target attribute, and most don't let javascript open new windows with user intervention anymore. In this case, the ideal solution is broken because of the era of the pop-up.#33Actually, the alt attribute should be omitted, but only rarely. At SiteCrafting, we use image icons to add meaning to links, for example, a plus sign on links to add new enteries to a database. If I added an alt attribute to that image, and it didn't display, my link would look like [Add] Add Item rather than Add Item. #34You can have many elements of a given class, but only one element (on a page) with a given id. This does make you wonder why getElementsByClassName isn't in the Javascript core.#35 & #36Essential, but I can't add anything to these.#37This reminds me of the era of frames. Frames were bad, and undead frames like object include and iframes should not be allowed to work. But we had to use iframes a couple of times, because there was no other option to make the system work. Here's the bottom line: Learn the rules of HTML, and this article is a good place to start. Then when you have learned the rules, you can bend them, or even break them, as long as you know why you are doing it. Wed, 01 Nov 2006 09:16:00 PST http://www.sitecrafting.com/blog/email-newsletters-in-outlook-2007/ One thing that we frequently build in conjunction with new websites is a tool for sending out email newsletters.  For the most part, we stick to XHTML/CSS and try to stay away from using "old" layout techniques (i.e. tables) for the newsletters.  This allows the greatest flexibility between the large number of email clients (e.g. Outlook, AOL, Yahoo!, Eudora, Thunderbird, Pine, etc.).  Businesses love being able to quickly communicate with their customers, and email newsletters are a great way to do this.  But things are changing, and if you use HTML newsletters, you'll need to make some changes too.An article I discovered via digg earlier this week was pretty surprising, though at the same time not surprising at all.  It turns out that with the newest version of Microsoft Office, Outlook 2007 will change the engine that renders HTML email from Internet Explorer to Word.  It's all related to Microsoft's push for security, but instead of just creating a trimmed down rendering engine that met the security needs, Microsoft decided to use the engine that comes with Word.  Problem is, the engine used by Word is very limited and doesn't support some of the HTML and CSS attributes that designers and developers use consistently in newsletters.So what does this mean for your email newsletters?  Well, your newsletter templates will most likely need an overhaul to ensure that they still look good in your subscribers' inboxes.  It may also mean that some of your templates need to be cut back on features.  Less images, no background images, a simpler layout.  You may love your existing newsletters, but be prepared for a redesign or some time to re-engineer them.Interested in learning more or hearing other folks' take on this change?  Check out the links below for even more info on this change.Broken HTML/CSS Rendering in Outlook 2007Get your HTML newsletters and emails ready for Outlook 2007Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 1 of 2) Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 2 of 2) Thu, 18 Jan 2007 12:03:00 PST http://www.sitecrafting.com/blog/cleaner-forms-collapsible-textareas/ Some really large forms can be a bit of an eyesore especially to the people filling them out. One thing that always bothered me was how bulbous most textareas had to be just to make enough room for a user to feel they could type what they needed. So I set out to figure a good way to clean up my forms a bit while still allowing the multi-line input of textareas.I'm not much for surprises so here's the final working example. The idea is to make any textarea on a page look just like a normal text input field. Once a user puts their cursor inside it expands to let them know they can type more than just a line. First you should determine how tall you want the textarea when it's collapsed and when it's expanded. I recommend matching the collapsed height to any other text input fields in your form. Next add a class to the form(s) you'd like to convert to use collapsable textareas. With that, some CSS and a couple JS functions, we're there!You didn't think I'd leave you hanging, did you? Here's some code:/* first some CSS */.collapse_tareas input, .collapse_tareas textarea { font: 10pt arial, sans-serif; border: 1px solid #888; }.collapse_tareas textarea { height: 1.45em; }.collapse_tareas textarea.compact { height: 1.45em !important; }.collapse_tareas textarea.expanded { height: 5em !important; }Next comes the JavaScript:// find all the forms with textareas we want// to allow to collapsefunction setupTextareas() {  var pageForms = document.getElementsByTagName("form");  for( var j=0; j    var formArea = pageForms[j];    if( formArea.className.indexOf("collapse_tareas") > -1 ) {      var txtAreas = formArea.getElementsByTagName("textarea");      for( var i=0; i        var thisTxtArea = txtAreas[i];        if( thisTxtArea.addEventListener ) {          thisTxtArea.addEventListener("focus", bigSmlTextarea, false);          thisTxtArea.addEventListener("blur", bigSmlTextarea, false);        } else { // IE          thisTxtArea.attachEvent("onfocus", bigSmlTextarea);          thisTxtArea.attachEvent("onblur", bigSmlTextarea);        }      }    }  }}// collapse or expand a textareafunction bigSmlTextarea(e){  var node = ( e.target ? e.target : e.srcElement );  if( node.className.indexOf("expanded") == -1 )    node.className += " expanded";  else    node.className = node.className.replace(/expanded/gi, "");  }// prep the the desired textareas to// collapse and expandwindow.onload = setupTextareas;By including the above CSS and JS on a page, any form with the "collapse_tareas" class will convert any textareas to collapsible ones. View the example and enjoy! It's an easy way to help clean up those unsightly forms. Mon, 12 Mar 2007 10:27:00 PDT http://www.sitecrafting.com/blog/got-api/ gotAPI.com is one of the most useful online resources I've come across, primarily because it places resources spread all over the internet into one simple site. I've been using this for quite some time, and have for the most part I have taken its usefulness for granted. Then it occurred to me that I might not be the only one that could find this tool useful (I know, it was a big 'DUH!' moment). So now I will share this gem with others...gotAPI acts as a portal to almost any API/language reference available on the internet. Wondering what that PHP string function is that splits a string into an array? Pour yourself a nice tall glass of gotAPI and find it in seconds. Or if JavaScript is more your thing, browse the DOM to find the function or property you need. The advantage is that it can all be accessed from here, no need to remember countless URLs or stumble through a poorly designed site to find the documentation page. Simply hit up the site and you're set.Customization is another advantage, with the tabbed interface allowing you to pull up multiple reference pages (all searchable with an expandable tree view to your left). Load up all the API's related to your current project finding an obscure function is now seconds away. Fantastic!The fact that I am still excited about this site after months of using it should tell you just how nifty it is. So stop wasting time reading blogs and go check it out!Link: gotAPI.com Mon, 31 Mar 2008 11:40:00 PDT http://www.sitecrafting.com/blog/web-semantics-blog-comment/ So, whenever I meet up with good friend of mine, Scott Schiller from Flickr, we often talk about geeky things such as Web Semantics and the "proper" way to mark up different things. I know there are a few of you out there who enjoy this topic so here is my question to you.What do you think is the "proper" way to markup a blog comment in this image? Tue, 12 Aug 2008 16:39:00 PDT http://www.sitecrafting.com/blog/draft-css-animations-in-webkit/ WebKit, the muscle behind both Safari and Google Chrome has recently added CSS animation support to its nightly build. While a long way from being supported in any widely used browser, this does give a bit of a preview for what we can expect in the future. It's hard to say whether these new animations will be widely adopted, and if they simply become the new "blink tags" of the modern web world.CSS animations are applied using the concept of keyframes which is well known among other animation-oriented mediums. To better understand keyframes, imagine a timeline depicting the progress of an animation. To move a tag from point (x,y) to point (X,Y), you could apply a keyframe denoting the starting point, and another denoting the ending point. In the context of CSS, these keyframes would be specific styles applied at certain times during the animation. The browser would then be allowed to handle the actual execution of this animation. Mon, 09 Feb 2009 10:00:00 PST http://www.sitecrafting.com/blog/adobes-browserlab-goes-live/ It is an unfortunate fact of internet life that not all browsers are made equal. Pages viewed in Firefox may look completely different in Internet Explorer or Safari. Most developers consider this a very frustrating part of the development process, and often wish there was an easier way to test things out. Enter Adobe's BrowserLab. Given a publicly accessible URL, BrowserLab will generate full-size images that depict how a given page will appear in various browsers. The free service Browsershots and the paid service Litmus also attempt to address this need, but Adobe's offering is the first to bring together both a well-designed interface and a price tag of $0.One of the most useful features of BrowserLab are the viewing options available. Aside from the standard 1-up view (viewing the page with a single browser) a 2-up view is also available. This will render a page in two browsers of your choice side-by-side and will even lock scrolling to make it easier to compare the two.The "Onion Skin" view is the third option, which is a unique view that will lay one browser's view over another. This view comes with a slider that allows you to transition from one browser to the other. If you want everything consistent down to the last pixel, this is going to be your favorite.While the selection of available browsers is not comprehensive, it does cover the most common use scenarios which is acceptable for most cases. Opera and Google Chrome are the most obvious omissions from the list. While not a deal-breaker for me, it is something to be aware of if compatibility with browsers is important for your project. Another shortcoming is that, being images, you cannot interact with the page being tested. This means that testing for JavaScript and CSS events is not possible.Adobe's offering is very compelling, and currently holds the crown, at least in my opinion, for the most effective cost-free option for testing multiple browsers. It's sleek interface, viewing options, and reasonable selection of browsers make it a snap to ensure your site looks consistent across the board. Fri, 23 Oct 2009 08:30:00 PDT http://www.sitecrafting.com/blog/mobile-safari-keyboard-selection/ While running through my morning blogs, I came across one by Jon Snook on HTML5 Form Elements. He talks about some interesting, future-looking elements that will hopefully be in the browser of tomorrow. But the part I found most interesting was talking about Mobile Safari and how it handles input elements.Mobile Safari on the iPhone has the advantage of using a dynamic keyboard. As an App developer, you can actually tell your native code what keyboard to show (number mode, url mode, email mode, etc.). It turns out, you can do this keyboard selection in input tags right now.<input type="number"><input type="url"><input type="email">The browser doesn't do any validation of the data, and the keyboard can be changed by the user, but it is surely a nice feature to make your web app feel smoother. Fri, 09 Apr 2010 00:14:00 PDT http://www.sitecrafting.com/blog/opera-on-iphone/ click to zoom inI got my team together this afternoon to give the newly approved Opera Mini for iPhone/iPod touch/iPad a try. Overall we agree it's great to see another browser in this space but they've got an uphill battle if they ever hope to overtake mobile Safari. Check out the rundown of our thoughts after the jump!Pro's snappy load times (via 3rd party server caching) responsive scrolling without as much "rubber-banding" of content below finger background loading of pages over multiple tabs back arrow used for both back and zoom out multiple search engine choices Con's only two levels of scaling/zoom (fit to screen and full res) zoomed out rendering choppy, aliased tab access pretty but pointless since current page can't be used in any way un-characteristic double taps needed to select from URL bar dropdown, close tabs two top toolbars if not in "full screen" mode take up valuable screen real estate Bottom line competition always good to keep browser tech moving forward (we're looking at you Mozilla and Google) privacy concerns raised with 3rd party caching/optimization of content might keep it on last screen of apps for testing purposes in Opera Mini mobile mode uphill battle to fight against Safari already embedded into OS some solid ideas but overall poor implementationWhat do you think? What would you add to this pro/con list? Tue, 13 Apr 2010 17:02:00 PDT http://www.sitecrafting.com/blog/browser-cache-multiple-tabs/ While writing a PHP script this weekend I ran into an interesting problem. The script watches for an empty text file to be filed with text. It does this with a sleeping loop and compares the file size every second or so. This works really well for one browser tab. But when I had two tabs, in parallel, the second one wouldn't display anything until the previous one had completed. So I wrote up the following test case. $i = 10;while(--$i) {    echo "$i";    flush();    sleep(1);}echo "Done";This will count down from 10 to 0, then echo "Done". The flush() command will send the current HTML to the browser, giving it a chance to render the content it's been sent so far.When running this on a single tab it worked as expected. With two tabs open, the second one would remain blank until the first tab had completed the count down. Then the second tab would display the count down all at once. So what's happening?After a little research, and some talk around the office, it turns out the browser does some odd things when loading the same page on two tabs. IE, Chrome, and Safari all have the same behavior. Each tab/window is independent and load separately. Firefox does this also, except the second tab waits for the first one to load before loading itself (sometimes pulling from cache, sometimes downloading anew). Opera does something completely strange. It keeps the two windows synced, such that giving a gap of a few seconds between tab refreshes still show the same point in the count down.Each browser has it's own way of handling multiple tabs with the same address, and there is no clear standard on what the behavior should be. From a developer stand point, I think IE and Webkit (Safari and Chrome) have it correct. Keeping the two tabs separate makes the most sense and this behavior makes the developer have to worry less about parallelism (race cases, timing, rendering issues, etc.).Browser Versions tested:Firefox 3.6.11Opera 10.63Chrome 7.0.517.41Safari 5.0.2Internet Explorer 6, 7, 8 So how do you think the browsers should behave in these cases? Mon, 25 Oct 2010 10:40:00 PDT