Category - JavaScript

  1. Windows CompactOverlay Mode

    The Creators Update of Windows is coming soon. One of the new features coming with it is a way to keep your UWP app on the screen above all other windows. It’s called CompactOverlay mode, but you probably know it better as Picture-in-Picture.

    All of the examples that I’ve found online of how to do CompactOverlay mode (all? I mean all one of them) is written in C#. In my work on a day to day basis I work in JavaScript. Converting from C# to JavaScript in this case is fairly easy.

    First you want to check and see if CompactOverlay mode is supported:


    Then you’ll want to switch to the CompactOverlay mode. In this example it’s based on a click of a button:


    What this will give you is a small window containing your app! That’s the first step. From here you can customize the experience by specifying the height and width of the window:


    There are other great things you can do like specify a different display to be used while in CompactOverlay mode. I recommend reading the blog entry on Microsoft and if you have any questions about conversion to JavaScript give me a shout @spatacoli.

  2. Bower is Dead

    Starting from a blank piece of paper or an empty notepad can be a daunting task. Where do I start? How do I get to the productive place? Most of the help that I find on the Internet start with, “Run these 15 npm install commands and then copy this code into these files.” Sure, doing that gets you to someone’s productive place, but rarely does it get me to my productive place. Also, you are now bound to that person’s setup for all future projects. I don’t like that especially as the web is a fluid landscape and changes all the time.

    This changing landscape is what bought me to my problem that I am trying to solve right now. There are many tools available to download and install JavaScript frameworks. In the case of ASP.NET 5 some of the guidance shows using NPM and Bower. Using Bower for the front end, client side scripts and libraries and NPM to help manage all the development time stuff.

    Bower has the advantage over classical NPM in that it produces a flat tree of dependencies. NPM would nest the dependencies and create quite the tree. NPM 3 though creates as flat a tree as it can. When coding we are taught to “Don’t Repeat Yourself” or DRY. Well if we aren’t supposed to repeat ourselves in code, why would we do it in the tools we end up using. The real crazy part of all of this is that we use NPM to install Bower. NPM can be used to install all of the frameworks that I use so why not just use it instead of Bower?

    This started in my mind because there was a Tweet that I can’t find right now stating that Bower is dead and we should all use NPM. That’s great news. It’s one less tool that I have to keep sharp in my tool belt. Turns out that the Bower group is alive and kicking and looking for more volunteers.

    Where was I going with all of this? Right, I don’t want to use Bower anymore. Don’t get me wrong here. Bower is great. You can specify a .bowerrc file and in it tell Bower where to put the libraries you download so they are immediately available. Like in the /wwwroot/libs folder. NPM always puts its downloads in the node_modules directory. This requires an extra step in Gulp to get the libraries moved into the specified folder.

  3. You Canot MouseLeftButtonDown if you have no Mouse

    I’m in the middle of a fairly large scale code review and I wanted to stop and alert everyone to a common mistake I am seeing in a lot of code that I read. You should use the Click event in about 99.99% of the cases that most people are using the MouseLeftButtonDown event. The reason for this is that if you have no mouse, there is no left button, and if there is no left mouse button it cannot go down.

    Imagine if I am a keyboard only user, I would tend to Tab my way though a web page to find the button or link I want to activate. I would then press either the Space Bar or the Enter key to activate it. In POSH any Hyperlink would fire using either of these methods. In Silverlight either of these two methods will activate the Click event, but it will not substitute in for a MouseLeftButtonDown event.

    I think this stems from Silverlight 1 where the only way to detect a click was to listen for the MouseLeftButtonDown event, but those days are long behind us.

    If your intention is to actually capture an actual mouse event, then use MouseLeftButtonDown. However, if your intention is to capture a Click, use the Click event.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. JavaScript Intellisense in Visual Studio 2008

    With Visual Studio 2008 I've done something I never thought I'd do. I'm actually using a beta of Visual Studio to write production code at work. I'm doing that not because it's the most stable platform, it's at beta 1 quality right now. I'm using it because of all the great features it adds as well as the unique ability that it can now target a .NET Framework that is different from the one it was written for. More on that in another post.

    The reason that I'm writing this post is to point you to a blog by Scott Guthrie that he posted yesterday. It is describing the great and wonderful features of JavaScript Intellisense in Visual Studio 2008. I highly recommend reading this post:

  11. Be Excellent to Other Onload Events

    I've noticed a disturbing trend lately with regards to the onload event of an HTML page. This trend includes one developer overwriting the onload event with their own function. I've seen some web pages that have this for the body tag:

    <body onload="myLoadFunction();">

    And because this doesn't seem to work for them they put this right before the closing body tag:

    <script type="text/javascript">

    They do this without first finding out why the onload doesn't work. The issue is that in one of the many script libraries that they've included in their document is a function that destructively adds its own onload function into the DOM.

    In a JavaScript book that I read a while ago the author included this code for adding an onload function in a non-destructive way:

    function addLoadEvent(func)
        var oldonload = window.onload;
        if (typeof window.onload != 'function')
            window.onload = func;
            window.onload =

    To use this after your function that you want to add to the onload event just call:


    I believe I got this function from the O'Reilly book "JavaScript: The Definitive Guide" by David Flanagan.

    If you are using the Prototype framework you can just use the observe method on the Event object to do this. More information can be found here.

  12. Death to AJAX?

    Lately there's been a slew of new technologies promising to kill AJAX once and for all. Those technologies include Silverlight, Flex, and JavaFX. The problem with this theory is that all three require the user to install a plug-in. You cannot expect that a user will have your plug-in installed, and you shouldn't expect the user to install your plug-in just because you tell them to.

    Personally I dislike Flash web sites. They are slow and bulky and they ruin the bookmark/Forward/Back experience of the web browser. Now there's promise that one of these new technologies will take over your browser, well I wouldn't count on it.

    I'll grant you that AJAX itself also breaks the bookmark/forward/back mechanism, but that's only when it's not used correctly. I think there is a danger that these new technologies will be used to build entire web sites (as this is what is what we were told we could do last week at Mix 07). They should be used to enhance web pages, but don't forget that visitors to your site want to be able to move around in a method that is familiar to them.