The proposal outlines several possible avenues for extending HTML syntax and considers their repercussions for functionality and backwards compatibility. Most of the extension choices can be supported in older browsers using JavaScript to backfill support for the HTML attributes the browser doesn’t understand.

I like the idea of allowing any element, even large blocks, to have an optional link associated with it. This improves the scope of reference to more naturally reflect the semantic structure of the referring document. If you quote a whole paragraph from somewhere else, doesn’t it make more sense that the entire quote be a live link to the original source? The current HTML link patterns force you to inject awkward transition text into the article just so you can have something to hang a link off of. I find such callouts disruptive to the flow of narrative text. Callouts often give the reference too much visibility relative to the content around them – another distraction.

Decreasing the need for artificial link phrases could be a benefit and burden for search engines. Search engines typically place a lot of weight on what words are used in the reference to associate some keyword digest of what the referenced page is about. This is a key technique for finding images with text search queries. How does a search engine deduce that “DSC10034.jpg” is an image of a horse? By noting that three different pages link to it, and the text of the links contains the word “horse”.

A block quote or table row that references another document would likely overload the simple referring text search engine technique with too much data, so the link would not be as strong of a keyword signal as two or three word phrase calculated by a human semantic engine. On the other hand, human digests are notoriously bad. Mislabeling is extremely common on the web, either by ignorance, apathy, or malicious intent. (Somebody actually tagged my photo of an Adelie penguin as a “parrot”! Gah!)

Eric has a demo page showing how one of the HTML extension options might look like, and how JavaScript can backfill for browsers that don’t understand the extensions.

Keep in mind while tinkering with the demo that the proposal is about extending what information can be represented in HTML syntax – the proposal is not about how an HTML renderer would present that information on the screen. I absolutely not want entire blocks or table rows drawn with the traditional underscored text of a hyperlink.

Certainly, a page that uses links for blockquotes or table rows could define its own CSS style elements to make the linked element less obnoxious to the eye. I would hope for more subtle visual cues that let the reader know that the linked element has more information, more depth of content, available for drilldown without disrupting the flow of the eye across the page. I would also hope that browsers that support these HTML link extensions will consider these distinctions between a “hard” a link and a more subtle content drill-down link when setting their default rendering styles.

Discovered via Ajaxian

Share/Bookmark

United Media cited “unfavorable market conditions” for the withdrawal, but Cowen & Co. analyst Jim Friedland puts it more bluntly: “We expect the Classmates.com subscriber base to peak in the first half of 2008, followed by a steady decline to zero by 2012.”

Ouch!

Classmates.com is a paid subscription site that apparently doesn’t have much of a plan for how to compete against free sites like Facebook that provide better services and larger social networks.

Share/Bookmark

Here it is:  IE has a handy document.namespaces object that reflects the namespaces defined in attributes of the HTML element of the page. 

The gotcha:  document.namespaces does not track with attributes that are dynamically added to the HTML element after page load.

The situation: “blocks” in Popfly can emit HTML code to set up shop in the application host page, but they do not have control over the host page’s HTML tag.  Since our web controls pretty much requires namespaces (that’s a bug - they should work with or without namespaces), we tossed in a quick fix in the Popfly block:  look up the html element and use setAttribute to set the namespace attributes we would have set on the html tag if we had access to it.

Result:  worked great in Firefox, but that was only because Firefox doesn’t provide any support for namespaces in HTML docs.  I ranted on this awhile back.  You have to serve up content type text/xml in order to get Firefox’s namespace support to kick in, but doing that kills all the JavaScript on your page, among other things, and in general one should not take lightly renaming HTML as XML or visa-versa.  It’ll sneak up and bite you when you least have time to deal with it.

Result2: Didn’t work in IE.  Our bootstrap code in the contacts control takes advantage of document.namespaces in IE, and falls back to savage spelunking to find the namespace attributes the hard way in Firefox and other browsers.  document.namespaces is populated when the html document is being loaded and is not updated after it has loaded.  Our quick fix of adding the namespace attributes to the html element in our Popfly code block had no effect because they were added after document.namespaces was locked down.

Solution:  Change the Popfly code block to call document.namespaces.add() if document.namespaces exists, otherwise add the namespace attributes to the html element.  Do it. Test it. Ship it. Whew!

This post was originally published on my MSDN blog while I was at Microsoft.

Share/Bookmark

Always program window.open() very defensively…

Always try catch any calls to window.open() and if you are retaining a reference to the window (e.g., var w = window.open(…)), always make sure the “w” is a valid object (and again try catch your first attempt to leverage the window). 

Last, it was recently discovered that Symantec’s internet products have a popup blocker that actually augments the web page with their own custom script. This script disables any calls to window.open() that may occur before the onload event of the page. Therefore, if the user quickly clicks a hyperlink that calls window.open before the page loads, the user will see either nothing happen or receive a script error. 

I heartily agree.  The variable assigned the return value of window.open() (“w” above) is particularly obnoxious.  It can fail to be initialized if the window.open() failed or took an unexpected detour due to popup blockers.  Once the popup window is up and running, the “w” variable will again be at risk when the user closes the popup window.  The “w” variable will be unusable after the window it refers to is closed – it’s almost as though the object it refers to has been garbage collected out from under the variable.  Any reference to the variable will raise an exception.  Testing for typeof w == “undefined” isn’t entirely reliable across browsers because for the brief period while the window is closing “w” may be unusable but not undefined.

For the Windows Live Contacts web control we ultimately solved these quasi state problems with the popup window variable once and for all by eliminating the variable!  Instead of having the main page hold onto a variable pointing to the popup window so that the main window code could check the state of what’s going on in the popup, we turned everything inside out so that the popup calls or writes back to the main window.  This arrangement allows the main window to create the popup, set a state variable to indicate that the popup is up, and then forget about it.  When the popup is closed, it will call back to the main page to clear the state variable and set the result of the operation.

Another thing to watch out for when you have multiple windows in your web app:  Firefox 1.x does not do well with executing script while a window is closing.  If the popup window is in the process of closing and calls into a JavaScript method on the main page which fires off a new XMLHttpRequest, chances are high that the XMLHttpRequest will implode in its onReadyStateChanged event.  Accessing any field or method of the XMLHttpRequest object will throw an exception, and all subsequent XMLHttpRequests (even new instances) will be fried.  The only way to clear this state appears to be to reload the main page.  I don’t recall offhand if this has been fixed already in Firefox 2.0, but it’s a known, logged issue in Firefox 1.x

The best solution is to avoid the problem by not initiating an XMLHttpRequest in a call chain started by a window close event.  Use a short timer to decouple the closing popup window’s call context from the desired XMLHttpRequest action.

This post was originally published on my MSDN blog while I was at Microsoft.

Share/Bookmark