Category - HTML

  1. What I cannot create, I do not understand

    Jeff Atwood blogged about a problem he is having with HTML sanitization on Stack Overflow. The argument that Dare Obasanjo and Jon Galloway were trying to make to Jeff is that it doesn’t make sense to re-invent the wheel. People have solved this problem before and their code is available for re-use. Jeff’s argument is that he’s a professional developer and he should be able to solve this problem. He punctuates his argument with a quote from Richard Feynman, “what I cannot create, I do not understand.”

    This is a fine argument if Jeff were a Nobel Prize winning Physicist working on the fundamental building blocks of the Universe. However, and I’m sad to report this, he isn’t. Software Development is not science. Some of us may use the scientific process for finding and fixing bugs, but at its heart software development is an engineering profession. What that means is that most of the hard problems have been solved before. Although it is important to understand how the solution works, it isn’t necessary to re-invent the wheel.

    For example, given the inspiration and the need I could rewrite jQuery, but I don’t. Why? Because someone else who does have the time and inspiration already did it. More importantly, many thousands of people have already used it and reported enough bugs on it to make that library very stable and robust. The important part of this example though is that at any time I can, and have, opened it up and read through the code to make sure that it makes sense to me. I’m not proposing that Jeff use someone else’s HTML scrubber blindly, I’m saying he should use someone else’s HTML scrubber after reviewing it for himself to ensure that it meets his quality bar.

    I also chose jQuery for this example because Jeff uses it extensively on Stack Overflow. He did not go out and write his own. In fact Jeff also uses the ASP.NET MVC framework, the ASP.NET framework, and the .NET Framework. All of these are software that he could have written given enough time and inspiration. At some point it comes down to ego. An HTML scrubber is a simple enough thing that he should be able to write it, but he really shouldn’t.

  2. First Full SilverSpine Implementation

    Today we soft launched the first site that is using the full implementation of SilverSpine. The SQL Server Energy site has gone live. Over the next couple of weeks we will be launching this same site in 15 languages all using the same exact codebase, but the content back (the SilverSpine) will have translated code. This is truly an exciting time.

    The site will look similar if you have Silverlight 2 (beta 2) installed or if you don’t have Silverlight at all. We are working on the Silverlight 2 RTW version but for obvious reasons (Silverlight 2 RTW hasn’t been released yet) we didn’t go live with that.

    This was a tremendous effort from a lot of people, but we’d like to call special attention to MSCOM for doing their best to stop the launch. We won, you lost. ;-)

    Check it out here: SQL Server Energy

  3. Now Loading – A Public Service Announcement

    This is a web page. The browser says that it is done. There’s nothing obvious going on with the screen and for all that I know the page just won’t render. However, if you look really closely at the top left, in browser default font there is a number that is counting up. Eventually it reaches 100 and the site finally appears, but considering I have a truly blazing Internet connection I don’t usually expect to wait 30 seconds to see anything on a site. The thing I really dislike about Flash and Silverlight sites is the loading time. I’m guilty of it too as I had to put a “Now Loading” screen in Server Unleashed, but I at least gave the user something to let them know the page is actually loading. This example of a loading screen is unacceptable from P.F. Changs. All of you web developers and designers out there, please remember that if your site is going to take more than 5 seconds to load even on a really fast Internet connection, let the user know that something is going on.

  4. Difference in Margin Between HTML and XAML

    The Margin attribute of XAML elements acts different than in HTML. There are still the three ways of describing this information. The first way is simply, make all sides the same. These are identical in HTML and XAML (except that margin is capitalized in XAML).



    margin: 10px Margin=”10”

    XAML only allows you to work in pixels. So you do not need to mark the 10 with a "px" as you do in HTML. This will give the object a nice 10 pixel margin on all sides.

    What if you wanted the top and bottom to have one margin and the left and right to have a different one? Well to do that will describe the first difference between HTML and XAML:



    margin: 10px 20px; Margin-“40,20”

    Wait... What?!?

    There are a couple of things going on here. The first is that you describe the left/right margin first in XAML and you describe top/bottom first in HTML. The second thing to notice is that in XAML you add the left to the right or the top to the bottom and enter that value. The HTML and XAML will both produce 10 pixels of margin at the top, 10 pixels of margin at the bottom, 20 pixels of margin on the right, and 20 pixels on the left. But keep in mind that XAML lists the left/right first and you add the two together.

    Think you got it? Well now for the final element of twist:



    margin: 5px 10px 15px 20px; Margin="20,5,10,15"

    I bet you had it all figured out didn't you? Well this is also simple, but you need to keep it in mind when doing Silverlight. XAML expects Margin to be listed as Left, Top, Right, Bottom. HTML is Top, Right, Bottom, Left. They both go clockwise around the box, but HTML starts on the top and XAML starts on the left.

    I hope this helps anyone out there.

  5. Paragraph Elements are not for Spacing

    A friend of mine just launched a new business venture called stackoverflow. Jeff will be doing what he does best, and hopefully that will mean that we can contract him out to help us from time to time.

    The reason I'm blogging about it here is his web site was clearly just thrown together to get it up on the web. For someone who spends his day finding new ways of dampening the sound on his Rock Band drum kit, I would think he'd be a little bit more 21st century (or even Web 2.0) about his web site.

    Granted the web site is just an image and some text, the interesting thing here is the code. View source on his web site and you will find an example of an HTML technique that I thought was left back in 1996. That is he is using an unclosed paragraph element for spacing the text blocks on his page. Paragraph elements are for paragraphs.

    "The P element represents a logical paragraph"

    Although in HTML it does not need to be closed, it seems to have been the best practice since about the time people were really hot on migrating to XHTML.

    Because my wife is standing here telling me I can't just insult Jeff's new web site, I've decided to correct the HTML. Jeff, if you read any of my blogs, this is for you:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    ""> <html> <head> <title>stackoverflow</title> <meta name="description" content="Stackoverflow is sort of like
    the anti-experts-exchange (minus the nausea-inducing sleaze and
    quasi-legal search engine gaming) meets wikipedia meets
    programming reddit." /> </head> <body> <div style="text-align:center; margin-top:100px;"> <img src=
    " width="435" height="496"
    alt="I think you should be more explicit here in step two."
    title="I think you should be more explicit here in step two." /> </div> <h2>Wondering what will be?</h2> <p>Listen to <a href="
    stackoverflow-podcast-001.mp3">the first stackoverflow
    podcast</a> with <a href="">Joel
    Spolsky</a> and <a href="">Jeff
    Atwood</a>. (MP3 file, 8.32 MB, 46:12).</p> <p>If you'd like to submit a question to be answered in our next
    episode, record an audio file and mail it to <a
    href=""></a>. Remember, it <em>must</em> be an
    audio question -- 90 seconds or less, please.</p> </body> </html>

  6. Silverlight SEO

    So you've downloaded the SDK, and you finally installed Visual Studio 2008. You crack it open and get your "Hello World" project running. Now you are ready to dive head first into a complete Silverlight site.

    Getting buy-off from the various organizations will be your first hurdle. They are interested in how well the site will perform in the search engines. You don't really care about that because you want to be able to have a stronger fidelity between what your designer has created and what you can deliver to the web.

    Search Engine Optimization will be the engine that drives traffic to your site, but if the search engine's spider cannot crawl your site then your site may not even exist. So what are you to do?

    The official line from Microsoft is that they are working with the major search engine sites to help them crawl XAML files. After all XAML is just XML and is plain text. However, with Silverlight 2 all of those XAML files will most likely be packaged up into a XAP file. A XAP file is essentially a ZIP and I'm not sure that search engines have the time to unzip the XAP just to index the contents.

    Well if you think about it, what do search engines index very well? If you guessed HTML pages then you'd be right. If you wrote your HTML page with content only then it is 100% pure gold for search engines.

    Not to get off track here, but I am a big proponent of the Semantic Web. Although I probably won't go so far as to say that you should be writing RDF triplets only, but I believe in the ideas of using elements that make sense. If you are writing a paragraph of text enclose it in a <P> tag. If you want to emphasize something enclose it in an <EM> tag. Also careful use of ID's and Classes make your HTML much more readable and makes it more friendly to search engines.

    Why do I bring that up? If you are careful enough to keep your style information in CSS and your dynamic actions in JavaScript you should be able to just transform your HTML into XAML and let Silverlight control the display, style, and actions. JavaScript can be used to translate the HTML into XAML if you are in Silverlight 1.0, but if you are using Silverlight 2.0 then just use the .NET Framework's XML classes to do an XSLT transform on your XHTML into XAML.

    Although this will create a bit of work for you in creating the XSLT the benefits you'll get go beyond just SEO. I'll investigate this more in a brief series of posts that will be published over the next couple of days.

  7. More on Silverlight SEO

    In my last post I described a method of building web sites that have the ability for search engines to crawl the site. This is important in Silverlight because traditionally all of the content within a Silverlight site is contained within the XAML. With the method described, all the content is still in the HTML.

    The question remains, though, why do I care? The first and most obvious answer is: if you don't how will anyone ever find your content?

    The second answer is a little more complicated. When you write a commercial web application you want to increase its visibility in search engines because another method of getting people to your site includes paid search. What does one have to do with the other you ask? Well if your site performs well in the search engine, then the cost of your paid search placement will go down. The closer to #1 your site is when you search your keyword terms, the less you have to pay for the targeted paid search.

    I'll describe more benefits to using this method of creating your Silverlight sites, but if any of this post doesn't make sense, please comment and I'll try to explain it better in a future post.

  8. Silverlight Centrally Managed Content

    In my previous posts about creating a Silverlight site that plays well with search engines I have only focused on SEO and SEA. There are a lot of other benefits to this model and I hope to map them out in a few posts. The difficulty is in finding out where to start.

    The main crux of this idea came from the Server Unleashed site that I was working on at the time has a separate HTML version of the site. This was particularly frustrating to me because I am a firm believer in the write once and test it then never write it again. That includes content. Content in one place makes it easier to make changes as they come in, and it actually makes it easier to localize a topic I'll get into in a few posts.

    There are thousands of Content Management Systems (CMS) on the market. I would even be willing to bet that every day sees the birth of at least one more. My own web site that you are reading right now uses a custom CMS that I wrote because I wanted bragging rights. Now I see the trouble with doing your own custom CMS is that you have to maintain it. Maintaining a site for someone that is willing to pay time and materials is one thing, but finding time to make changes to your own code is a bit more difficult. That's why there are some issues with this site that haven't been updated in a few years.

    I digress. If your CMS is a static HTML file or if it's Microsoft Office SharePoint Server 2007 as long as your content exists in one place you are in good shape to maintain the content moving forward. If you find that your content needs updating you only have to make the change and test it in one place.

  9. Silverlight Accessibility and Portability

    What's the big deal with having your content in a separate file anyway? Beyond SEO and the single responsibility principle there is what I consider to be the single most important reason: Accessibility.

    When I write about accessibility I really am talking about 508c compliance. If the person viewing your web site is hard of sight or cannot see at all then your site is worthless to them. I won't go into the legal reason of why your sites should be accessible (search "Target accessibility web site" to know more about that). Your site should function without the flashy bells and whistles that CSS, JavaScript, and Silverlight provide. The page should make sense to navigate in its pure text form. You should have main site navigation, but perhaps that should be near the bottom of the page. The most important thing about the page is the content, not the navigation. Maybe have a named link at the top of the page to quickly scroll to the navigation section, but make sure that the site content is first on the page.

    The site navigation should be simple and you should have a site map. All of these suggestions are SEO best practices, but really you are doing a favor for anyone that is coming to your site that relies on a screen reader to navigate the web.

    I'm not going to go through all the best practices of accessibility here, I'm sure over time I'll compile a full list of suggestions. Just know that you need to keep this in mind as you are building your site. If your HTML is clean and free of design elements or extra JavaScript cluttering up the page your are well on your way to building an accessible site.

    Since writing the content HTML is the first step of building a site. Launch it. Use the site without CSS or JavaScript. Can you get to all the content. If you turn off images, is there enough information on the screen to understand what the image was?

    Once you've reached this step you can do two more things. You can build a simple CSS for people that want to print your site. In this print version of your CSS turn off the navigation and anything that is not content.

    Next add a little bit of flair with CSS to your site and make things look better than 12pt black Times New Roman on white background. Throw in a little color and some font sizes here and there. Use this as the WAP version of your site.

    Constantly building from the rock solid framework of content only HTML and adding CSS and JavaScript using external files will help you create a site that can be used on all of the lowest common denominator systems out there.

    Once you've finished with this, you can finally go to the holy land... Silverlight. This is when you can turn on all of the bells and whistles. You will need to invest some time in writing an HTML to XAML converter, but it will be worth it. When you launch your site and everyone on the Internet can enjoy your site you will have a site worth being enjoyed.

  10. Localizable Silverlight

    In my previous post I discussed Silverlight SEO, and the strategy I'm using to enable search engines to crawl my sites. Even though most of my site is in Silverlight, search engines are able to crawl it because the content itself is actually in the HTML of the page. Then I transform it using some basic JavaScript.

    At McCann Worldgroup one of the most important tasks is making a site easy for subs to localize. Most of the time the subs don't have the experience with Silverlight or the money to pay for localizing an HTML version and a Silverlight version. With this method that I am trying to describe here, the subs only need to localize the HTML. All of these international groups have experience converting US English HTML into their language/dialect. With this methodology they can retain those same techniques to localize the HTML site and the Silverlight site at the same time.

    In order to do this though, you need to be conscious of the fact that not all languages have the same length of words as we do in the US. Beyond the obvious problem that many English words have extra characters (colour?) there are words in German that will put a strain on your design. Also Chinese is a bit of a problem, but I don't have any direct experience with that one yet.

    When designing a site for Silverlight (or even CSS/JavaScript) you should keep in mind that what content will fit in your 250px by 300px box looks great in US English may well not work at all in another language.

  11. The Little BR that Should Not…

    Last time I explained why you shouldn't use <B> and <I> and alternatives that are semantically correct. Today I'd like to complain about the over-use of <BR /> in the web.

    <BR /> is a line break. Some people just type <BR> and they shouldn't do that. You should always close your tags, even if they are empty. I'm happy that more than half of the BR's that I see are closed, but at the end of the day they shouldn't even be used.

    <BR /> is a line break. Yeah, I know I just said that but the thing is that <BR /> is a line break. Was the third time the charm on that one? No? Well, how about this: A line break isn't data. It is formatting. There is no semantic value in <BR />. You wouldn't sell a stock because the stock price had a line break in it. You wouldn't change medication because the news report on it had a line break in it. It is purely formatting.

    What have I said about formatting? It belongs in the CSS, not in the HTML. HTML is for data only. For that reason the next tag that I am going to eliminate from my vocabulary is:
    <BR />

  12. Death to B and I

    In the first of what I am sure will be many posts regarding HTML, I would like to bid farewell to my old friends <B> and <I>.

    You may find them in various places on my current web sites, but from now on they will just be elements that I once ran with. The reason is that they hold no semantic value, and they really are just elements for styling the data. The web is comprised of three legs: HTML, CSS, and JavaScript. (I really need a graphic for that... maybe I'll work on that as well.) These three legs nicely separate data, style, and function. There really shouldn't be any mixing of rights between them.

    Some people may think that the proper usage is to replace <B> with <strong> and <I> with <em>. In most cases that is correct, but not for the reason they are thinking. Although many browsers default to displaying <strong> as bold text, the reason to use <strong> over <B> is that semantically you are marking that bit of data as important. The same is true with <em>, you are trying to emphasize that bit of data so you surround it with the <em> element.

    You should not rely on the browser's default for styling these two elements. Proper use of CSS will ensure that these two tags appear the way you want them to, but that is a CSS discussion. Remember, HTML should only contain data. HTML is not the place for style or functionality.

  13. Coding Horror on Observing Users

    Coding Horror has a post today with a title, "Don't Ask -- Observe". In it he documents how if you ask a user what features from a set they want they will tell you they want them all. Technically he cites a "digital device" and when asked to chose from 25 features most people wanted about 80% of them. However, in using the object with all those features they longed for the simpler object.

    You should read the article because it's a very good analysis of user interaction design and why you shouldn't ask, but observe the users using various versions of a product, be it a web site or an application.

    View article...

  14. Input type=file value

    I had a bug this morning where the input field for a file upload box was being cleared during a postback to the server. The bug suggested that the server action should not clear the field because we weren't uploading the file yet. In ASP.NET you cannot change the value of that field.

    After thinking about this for a while, it makes sense. The vulnerability would be that some rogue web page would set the value to something private like your Quicken datafile and you'd unknowingly upload that to the server.

    It is good that I as a programmer cannot set a value to this field, but am I looking at this correctly? Can anyone out there confirm that this is the expected behavior of <input type="file"> ?

  15. HTML Validation: Choosing a DOCTYPE

    A while back, I asked the question of what the XHTML 1.1 doctype is. The answer is found on the site here. It is this:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "">

    They suggest that the xmlns and xml:lang attributes be set for the html tag like this:

    <html xmlns="" xml:lang="en">

    Also, if you are up to it, add the xml declaration to it (<?xml version="1.0" encoding="UTF-8"?> at the top).

    I am interested in this because I've been working on redesigning my main web site to make it more colorful, easier to update, and more modern in the code. When it's finished I'll be sure to post everywhere to let you know.