Blog about my research into extremely advanced client-side web development topics including Ajax development, XML based development, ECMAScript dynamics, dynamic graphics, widget creation, and various other browser-related topics.
For all those interested I just updated my e-chapter on JavaScript Graphics Development, an introduction to using JavaScript and Ajax concepts to do manual graphics development. It also touches briefly on concepts involving interactive graphics and widget creation.
Anyhow, here's the link:One of the most powerful and appreciated extensions for Firefox is the Web Developer toolbar. This is the extension that helped convert me from an independent IEvangelist to a Firefox promoter and standards advocate. This tool puts the keys to client-side web development into the hands of the developer.
With a quick click of the mouse, the developer can now see all elements of a certain type, can disable or enable various portions of development ( i.e. JavaScript), or can view otherwise hidden form information. It's such a powerful tool that you'll never be able to do client-side web development again without it.
I do apologize for being so slow in the posting of these videos. There will be a few more in the future. These videos are from September 2005 and are for Firefox 1.0.x, but are still appropriate for Firefox 1.5.x.
So beta 2 of IE7 is finally out. In case you don't know, a Microsoft beta 2 is usually very representative of the final product. I don't mean that as an insult, but as a compliment. Their beta 2 are actually very stable and almost usually mostly feature complete. .NET 2.0, for example, went to a go-live licence state at beta 2 and WCF (Windows Communication Foundation a.k.a. Indigo) is currently in beta 2 and in their go live stage (meaning they feel comfortable with people using it in production--Heck, I'm using it in production and it's amazing!).
IE7 is a massive quantum leap in Microsoft web browser. I mean a HUGE jump. A quantum leap not on the quantum scale, but on the level of general relativity. It's improvement over IE6 now allow IE to finally complete with Firefox pre-alpha 0.1. In a few years when Microsoft releases a minor release (what we call service-packs) Microsoft should have another major jump allowing IE7 SP1 to compete with Firefox pre-alpha 0.2.
Some day in the future IE8 will allow Microsoft's IE team to complete head on with Firefox beta 0.5! One day the Acid 2 test will be a thing of the past and IE will paint the screen red with Acid 3! Go IE team go!!
Current Acid 2 results
Here's an interesting link. It's google's analysis of over a billion webpages (text/html only though). It shows you what the top elements and top attributes are that people use. I'm not surprised to see that more people are still using the obsolete <script language="javascript"> instead of the proper <script type="text/javascript">, but I am surprised that the usages are as close as they are.
You really need to have Firefox 1.5 to view the page, but other "browsers" will auto install a plugin. Well, they will try to...have fun with that.
So what makes a good web developer? There are a few things, but the first is the most definitive and it's the one that so so generic that it is really an answer to the question "what makes someone at good anything?" The answer is: the ability to paradigm shift. Without this skill a person is utterly useless. If you come at new technology with comments like "that seem so stupid" or "uh, that makes no sense", then you're probably not only going to be a failure in the web, but also in all of life. In a world where medical science has a half life of four years and technology has a half life of two, you have to be able to adapt to new things with little to no whining.
With respect to the technical skills, there are a few fundamental things that really defines what makes web development, a web developer at all. Back in 1999 when I was in the business of pioneering web application development, having a solid foundation in server-side classical of web development was something that was really a requirement. I remember single-handedly porting our corporate VB applications to ASP in no time at all. The kind of skills required in this was an entire host of web development tricks to help maintain state and other things. This of course was only half the story. The other half of web development was the browser-side.
Back then, the web really got away from standardization and IE was the "standard" browser. So, I was able to build my web applications with a ton of [now extremely icky] "DHTML". Not only that, more advanced web applications could tap into the world of remote scripting (this was 1999, not 2005--anyone who thinks Ajax is new is obviously new to web development) So, while around the beginning of the new millennium web development was a big complexity on the server-side, it was very simple on the client side: there was no pride taken in client-side web development and there was only one "supported" browser. I should also mention that this was not the beginning of web development. I've been building advanced JavaScript applications since 1995 and back then we had Netscape Navigator 2/3, which allowed for the creation of very powerful client-side web apps. In those days, server-side development wasn't even a big deal..and client-side, well...no one knew you could do half the stuff you could do (people would still be freaked out by the stuff I built in 1997.)
So that's an old school web developer: classical (ASP/PHP) serverside language and support for basically just one web browser. Here's the kicker though: a web developer back then with no new skills is NOT a web developer today, he or she is really just a legact support developer. By standing by and doing nothing, a web developer, doing nothing different and losing no skills, loses his or her standing as a web development even though he or she still innapropriately holds the title.
The new professionalism is one of purity and respect for the web and focus on the solution more than the mechanics of the system. Today, there is absolutely no excuse for a Microsoft shop to use ASP.NET 2.0 for their server side technology. There's no need to do any voodoo with state management or any magic with form validations--it all just happens with ASP.NET. The other part of modern web development is of course the client-side. Today, however web development for the clientside has grown much more complex. The blame for this in my mind lays almost entirely on the shoulders of Internet Ex. (forgive me-- I can't bring myself to write that name out). By having absolutely no respect for the laws that the W3C has set forward, IE has actively damaged our world's information infrastructure, ironically without legal repurcussions or action from Geneva. Fortunately, today we have what I call the savior to the web: Firefox. With it's focus on purity and respect for the web, it brings a glimmer of hope to the future of the Internet as a whole. Firefox however is NOT part of the new professionalism for the client-side! I want to make this very clear: while an old school veteran web developer (someone from 1999-2000) "optimized" for specific browsers, a web developer today writes for the specifications (what some call "standards") just like a C++, Java, or C# developer would. That is, web developers today do not ask the question "What's the target browser?", we just write something that is for the W3C/ECMA specifications ("standards"). If it doesn't work somewhere, fine...we will add backward compatibility for that particular part of the system. The other day someone said to me "I'm not into standards as much as you". Clearly this person isn't a programmer. Programmers know that if you dont' follow the rules, your code doesn't compile.
Now what are some of the fundamentals of modern web development?
First, you would your C++ code to be syntax checked at compile time, so it follows you should write your XHTML/CSS/JavaScript to be syntax checked at "compile" time. Writing something and saying it works because you "tested" it, does not mean it's right or even wors. Furthermore, focusing on making something "work" isn't even the point. No one initially writes C++ code to work. A programmer writes his or her C++ code to first to be syntaxicly correct and then makes it works. Without the former, you can't even test the latter! The same pattern goes for modern web development. This is the same not only for JavaScript, but also for XHTML page structure and CSS page style. This is why validation is not just a good idea, but is absolutely required.
Second, modern web development deals with code-behinds. That is, there is a clear separation between different types of coding. On the client-side there is the page structure (XHTML), the page style (CSS), and the logic (JavaScript). On the server side, there is the declarative page (ASP.NET) and there is the code-behind (C#). Each of these things are in their own files, clearly separated from the others.
The purpose is multifold, but the two main purposes are...
The one thing that I find odd about developers (no just web developers) is that there seem to be two massive camps that both flaw in their understanding of this. There is the side people that knows to separate their page structure and their server-side code behind. These are the ASP.NET programmers. Then there's the camp that knows to separate their page structure from their page style. These are the linux-ish web developers. The former camp doesn't really understand why there is a separation of style from the structure on the client-side and the latter camp usually thinks it's odd that there's a code separation on the server-side. You would think that each would step back and have their own "aha!!" moments saying something to the effect of "OHHHH I'm all for code separation...Duh!! You're doing the same thing as I am doing! Rockin'!!" As it is though, people just don't seem to like that level of consistency.
Third, Modern web development has a simplified page structure model. HTML was a presentational language and HTML 4.0 was a nightmare. The rules in HTML 4.0 frankly didn't make much sense. Fortunately, HTML is obsolete. Today we use XHTML, which feels a bit like HTML 3.2, but it's written as XML -- so there at least some logic to the page! XHTML is a structure format, not a presentational format. It has no style elements. Sure, the browser can do some stuff by way of default styles or holding to tradition ( i.e. h1 is bigger than h6), but in the end XHTML has no presentation. It gets it's presentation from CSS.
A modern web developer builds what the page "is" in XHTML and how the page "views" in CSS. A related principle is a principle take from object-orientation: development based on what things are, not what things do. Ideally you want to tell technology what you want, not how to give you want you want; this is at the heart of abstraction. A great first step towards this is to think about what things "are", not what things "do". For example, in the past we thought about lines and page breaks. Put some text down, then a <br/>, then more text and then another <br/>. In this model, we are telling the technology how to do it's job, when we should just be telling it what you want and let it deal with the details. That's why in the XHTML/CSS model you never use <br/> (save for some advanced CSS tricks). In the new model you have paragraphs (<p>text</p> ), because that's what they are!
Fourth, modern web development is for devices, not for browsers. In this world where a ton of people have Internet on their cell phones, there's no way to just write something that is for a browser. This is one reason HTML is obsolete. You can't really get the uselessness of HTML into a cell phone. You can however get XML (XHTML) into a cell phone. This is possible due to the fact that XHTML has no presentation (because XML has no presentation--as I say, the presentation XHTML does have is by browser defaults and tradition). So, you can actually have a media specific CSS pages for each device. You can have one page structure-- that is, one definition of what the page is and have multiple "views" associated with it. There can be one view (one CSS page) for hand held devices, one view for your printer, one view for your monitor, one "view" for audio devices for the hearing impaired, and other views for other devices. This is the beauty of XML-- it really is extensible!
That's another point of irony--the ASP.NET people who are seriously into XML just can't seem to get it through their heads how web development is XML based now adays. That leads to the common problem of ASP.NET (1.x) developers not even being able to spell CSS.
Fifth, modern web development is tableless. This one probably the most frustrating for new web developer. You could be a 10-year veteran, but if you don't know XHTML/CSS web development--you are in the camp of new web developers. Table layouts used to be an extremely powerful tool for development. I can remember when tables first became popular many, many years ago. I thought they were the coolest thing since the popularizing of the mouse. After I finally figured how the pattern of "tr" and "td" I was virtually unstoppable! Table's however have many problem.
First of all they are very rigid. Secondly, they severely break the model of programming to what things are, not what things do. With you setup a table you are way too involved in the intricate implementation of something, when we should be telling the system what we want (i.e. a product list) and have it do the work. Thirdly, they really don't make logical sense in the flow of a page. You read a page from top to bottom and then all the sudden you have this complex puzzle called a table. You went from simple to complex way too fast. That's not a smooth curve to complexity as is desired, that a jolt into madness.
That leads to another major problem: tables are WAY too complicated! Writing them is a breeze, a skilled table writer can come up with a table to match virtually any rigid scenario. Reading them however is another story. They are a complete nightmare to edit, and cause a complete nightmare in the editing of elements in particular table cells.
Sixth, modern web development doesn't go gung ho with JavaScript, but will however see ECMAScript as a valuable tool and will know when to use and when to avoid it. I'm a veteran JavaScript programmer. I jumped on it in it's first release over a decade ago and I've been working with most of the great JavaScript (and proprietary DHTML-style ickyness) APIs since their preview stages. I've seen browsers do things 10 years ago that would make some people still gets getty even today. That said, I think the use of JavaScript (or more appropriately ECMAScript) in public websites is almost slanderous. For web application however it can be a great tool, but to a certain point.
I've been playing with the new Yahoo Mail and I have to give it about 2 stars out of 10. Their use of remote scripting is a bit overboard and things just don't seem intuitive at all. Gmail on the other hand is what I consider one of the greatest gifts to the world! It's use of JavaScript is very nice. Everything is very responsive and there isn't much by way of annoying and inappropriate "desktop application" emulation like what you see in Yahoo Mail or the newer versions of Outlook Web Access in IE. So, I don't consider JavaScript/"Ajax" part of the mindset of modern web development. That said, there are a few things a modern web developer will see with regard to client-side scripting.
First, DHTML is an obsolte term and generally reffers to IE-only client side work. Secondly, the appropriate technology for client-side web scripting is the standardized "ECMAScript", which completely replaces JavaScript. When it comes to ECMAScript, I am a huge fan of using it to create simple applications or to subtly support application. Last year I wrote a children's application in about 15 lines of pure XHTML (including the doctype and all that jazz) and about 2,000 lines of pure ECMAScript.
The difference between old school web development and modern web development is really is the purpose and placement of the code. Things like "window.open" for a website pop-up are extremely annoying. It drives me nuts that my favorite electronics store requires me to deal with a lame "window.open" pop-up that to pay my bill online. I would much rather ctrl-click to have that open up in a new tab in Firefox! The use of JavaScript in that scenario is not a convenience, but a severe annoyance. Gmail on the other hand as I say works with JavaScript beautifully. There are also a few amazing and clean Mozilla applications around written in ECMAScript. If I were to put a rule of thumb of this I would have to say that a wise web developer only uses JavaScript (well, "ECMAScript") when the website's foundation is based upon JavaScript. Websites are not based on JavaScript, they are based on XHTML. Applications like Gmail however are based on JavaScript. Furthermore, going overboard and trying to inappropriately emulate desktop applications like Yahoo Mail is trying to do, is however a big no-no.
Those are some of what I consider to be the fundamental mindsets at the very heart of modern web development. This isn't really a complete list, but it does give somewhat of a feel of what is required of someone before he or she can seriously be called a web development now adays.
Here's the next video in the Firefox Web Developer series: Using the Firefox Console. The Firefox Console is a tremendously underused tool built right into Firefox. It allows for safe and efficient JavaScript development that may otherwise be a complete nightmare. This tool is also an absolute must for remote scripting developers (yes, I still refuse to call it "Ajax").
I say it in the video as well, but let me emphasis it here: the Firefox console is not the JavaScript console. Firefox is a complete standalone Web Development Suite -- not just a web browser. These tools are not addons, plugins, or extensions, but rather are natively built-in tools in Firefox. In later videos I will discuss other tools also built right into Firefox.
OK, so here ya go...
Firefox comes with many incredible utilities right out of the box. One of these tools is the JavaScript console. Most developers who have done any web development at all utilizing Firefox has used this great tool, but few know of some of the more powerful features. In this video I touch lightly on a few features that you may have overlooked.
In the next video we will dive hard core into some code to see the Firefox Web Development suite in action.
Finally! Here's the long awaited part 1 of my Firefox for ASP.NET 2.0 Developers Video Series. I will be releasing more parts to the series over the next few weeks.
This video is titled "Setting up your Firefox Development Environment" and contains valuable information on setting up your web development environment for maximizing efficiency. More setup information relating to this video will be mentioned in future videos as the utilities used in future videos of course also require setup.
Furthermore, this video is valuable not only to the professional web developer (as well as the non-professionals who still use tables for layout), but it's also valuable for anyone interested in maximizing their web experience.
Below is the link to part 1 of the Firefox for ASP.NET 2.0 Developers video series. You can download Visual Web Developer 2005 Express and Firefox 1.5 below as well.
In September I recorded a video series I entitled the Firefox Web Developer Series. I've since renamed it to the Firefox for ASP.NET 2.0 Developers Video Series (clearly because the original title wasn't long enough). I put the project on hold because of the .NET 2.0 course I was teaching, which took almost all my time, but now I'm ready to take the time to get back into videos.
This series is for web developers who want to enhance their ECMAScript (JavaScript) skills and see how the powerful web development suite known as Firefox as simplify their lives. In the series I use beta 2 of Visual Web Developer 2005 and Firefox 1.0, but everything should be good for the final version of VWD2005 and for Firefox 1.5. The beta version of VWD2005 I was using had some issues which were completely fixed in the final edition.
I will be releasing videos from this series over the next few weeks. For now, here is my introduction.
You can download the first video from the video below. You can download Visual Web Developer 2005 Express and Firefox 1.5 below as well.
One thing you will inevitably notice when working with the ultra strict XHTML 1.1 is how the ampersand (&) works. In HTML you never had to worry much about the ampersand, though you could use it to implant an HTML space ( ). Now given that XHTML is XML, you simply can't get by with the rules of HTML. In the XML world, if you want to save an XML document with an ampersand, then you have to escape it. If you are familiar with C-based programming languages, then you know all about special characters like this. In those languages you have to "escape" certain characters such as the backslash (\), with another backslash.
In fact, in Altova's XMLSpy application you will get a stopping warning if you have XML that looks something like <b>&</b>. The appropriate way to have an ampersand in XML is to write it as &. This is very similar to what you could do wit hthe space in HTML and it's not that far off from what we already do. For instance, if you wanted to write . In fact if you want to write &nbsp; you have to write &amp;nbsp. So, if you know HTML, you already know the fundamentals of this rule. It's just taht in the strict world of XHTML 1.1, you can no longer let little mistakes enter your code.
Now this rule about dealing with ampersands doesn't end with standalone ampersands, but also applies to ampersands in links. For instance, you can't just have a link like default.aspx?id=3&category=5. Your link has to transform to default.aspx?id=3&category=5.
Fortunately ASP.NET 2.0 is smart enough to deal with things like this in your databinding. For instance, look at the following code...
ASP.NET 2.0 Code
<asp:GridView ID="gvLinks" runat="server"></asp:GridView>
Code Behind
C#
string[] links = new string[] { "http://jampad.net/default.aspx?id=1&name=2", "http://jampad.net/default.aspx?id=1&name=2&frog=3", "Amburgers & Wootbeer" };
gvLinks.DataSource = links;
gvLinks.DataBind( );
Believe it or not, ASP.NET will output produce the following...
<table cellspacing="0" rules="all" border="1" id="gvLinks" style="border-collapse:collapse;"> <tr> <th scope="col">Item</th> </tr> <tr> <td>http://jampad.net/default.aspx?id=1&name=2</td> </tr> <tr> <td>http://jampad.net/default.aspx?id=1&name=2&frog=3</td> </tr> <tr> <td>A&W</td> </tr> </table>
While I'm not a big fan of looking at table code, I am however a huge fan of automation. As you can see here, you don't have to fight with manually escaping data binding ampersands. Thus, you can give ampersands in XHTML data binding a vote towards deterministic.
When doing serious data binding in ASP.NET you may want to reconsider using XHTML 1.1 or XHTML 1.0 Strict at all. The rule is simple: use the document type that can be deterministicly proven to be proper in your situation. Put another way, unless you have deterministicly proven that there will never be any invalid markup in the data, you should always use XHTML 1.0 Transitional.
If the binding data has some odd markup, then you will end up sending invalid XHTML 1.0 sent to IE breaking validation or sending invalid XHTML 1.1 markup to browsers such as Firefox, halting the rendering.
But what does it mean to be deterministicly proper? To put it simply it means to absolutely garuntee that the data will always be proper, that is, to be able to always predict the properness of data. This does not mean "well, it worked for 100,000 tests, so it's good enough", but rather it means that it absolutely will always work 100% of the time. You can get this level of determinism by looking at the symantics of what is going to be bound. For example, if you are binding a table with numbers, which will always be numbers, then you should have a level of determinism here. However, if you are binding a table with unvalidated under input, then you do not have determinism as you have no idea what a user will input. The user could input <b><i></b></i>, which will break the page. You have no idea. Having a proven, not demonstrated, view of data is what this is all about.
Here are a few guidelines that should help you with determining what is and not deterministic.
These things are never deterministic...
Given symantical care, these things should be deterministic...
To reiterate: only use the document type that is deterministicly proven to always be proper.
One of the great things about XHTML 1.1 is that you are never allowed to serve it's content as text. You can send every type of XHTML 1.0 as text all day long, but never XHTML 1.1. You say you never send as text anyhow? Sure you do... that's what the text/html content-type is all about. The default for every web server (that I know of) is to send "browser" content (i.e. HTML, XHTML) as the text/html content-type. To use a different content-type you have to specifically say so.
The typical way to send XHTML 1.1 content is actually with the application/xhtml+xml content-type. To server a page using this type in .NET, you simply state the following in the early parts of your .NET page rendering (at the Init or Page events).
C# Response.ContentType = "application/xhtml+xml"; VB.NET Response.ContentType = "application/xhtml+xml"
When you do this, you kick modern web browsers, like Firefox, into what I like to call "parsing mode", "ultra strict mode", or "application mode" depending on my mood, but what it really is is XML parsing mode. In my lectures I often say "HTML is fundamentally unparsable". What I really mean is "HTML is fundamentally unparsed". That is, browsers tokenize HTML (via scanning), rather than parse it via XML parsing. Not to say that web browsers parse XML per se, but they could fundamentally do so it they wanted to. XHTML is XML and therefore "XHTML is parseable". Kicking modern web browsers into this ultra strict mode actually forces the browser to parse the page in an XML centric manner. What's this mean? It means that if your XML (XHTML) is not wellformed, it will throw an error. It's important to note that when you are in this ultra strict mode, the browser is not a validator (that would be REALLY cool), but is more of a wellformedness checker and is the closest things we have to a runtime compiler (which, I know, seems like an oxymoron.)
So, why do this work to get this ultra strict mode? For one simple reason: QA! Quality assurance requires that you take your work seriously. You can't just throw together a bunch of pages and throw them out on the web. If you were writing C#, C++, or Java you would be forced to run your code through a compiler to check for errors. By using ultra strict XHTML mode, you again get this forced compliance.
One word of caution...and it's a common word of caution. Gosh, no matter what I say or what I do on the web it always seems to be the same word of caution: this doesn't work in IE! This is because IE, by default, has absolutely no idea what application/xhtml+xml is. If you try to send this type of content to IE, it will probably try to download the file locally. Now there are times when it will load fine, but what usually is happening in these cases is that the content type is specified in the Windows registry to tell IE how to render it. Since we are talking about the web here, and not the Intranet world we have to follow the universal rules of the W3C, ECMA, and...well least common modern denominators (I throw the word modern in there just in case anyone wants to say that Netscape Communicator 4 is the LCD...and for the record, I don't care about any 4th generation browsers.)
So we need to make sure that IE doesn't get this ultra strict content type. Consequently, we won't have ultra strict mode in IE. Now, if you're paying attention at all you will notice that we have a page with at least two content-types required to support two different planets of browsers (IE, the rest of Earth). You can't send two at the same time. Not a problem. All we need to do is whip out a quick condition based upon what the browser can and cannot do.
When it comes to server-side browser detection some people like like to rely on the useragent string of the browser. This is actually a very bad idea due to how easy it is to modify a browser's useragent strubg (especially in IE with all the IE toolbars out there!). I actually read somewhere where someone said that "using the UserAgent is the fastest way to hell" I'd have to go along with that hyperbole.
Here's what you really do: test if the browser can accept the application/xhtml+xml content-type. If they can use it, use it. If not, don't. That's all there is to it, but before I get into the code there's one more thing. We're not talking just about the content-type here, were also talking about the document type (the DTD). If the condition comes back negative, that is, it does not accept xhtml+xml, then you can't use XHTML 1.1 either. So you also have to control the content-type nad the document type in the same shot. This is also not a problem.
Here's a standard method I use in the pages I want to be in ultra strict mode.
In the ASP.NET page, I replace the doctype with the following.
<asp:literal id="litDoctype" runat="server"></asp:literal>
Now in the code-behind I do the following...
C#
bool debugMode = false;
private void SetDoctype( ) {
bool mimeTypeOverride = false;
if (Request.QueryString["xhtml"] != null && Request.QueryString["xhtml"] == "1") {
mimeTypeOverride = true;
}
bool realBrowser = false;
if (Request.ServerVariables["HTTP_ACCEPT"] != null || mimeTypeOverride) {
string httpAccept = Request.ServerVariables["HTTP_ACCEPT"];
if (httpAccept != null && httpAccept.IndexOf("application/xhtml+xml") > -1 || mimeTypeOverride) {
realBrowser = true;
}
}
if (realBrowser && !debugMode) {
Response.ContentType = "application/xhtml+xml";
litDoctype.Text = "";
litDoctype.Text = "\n";
litDoctype.Text += "\n";
}
else {
Response.ContentType = "application/xml";
litDoctype.Text = "\n";
}
}
VB.NET 2.0
Dim debugMode As Boolean = False
Sub SetDoctype()
Dim mimeTypeOverride As Boolean = False
If Request.QueryString("xhtml") <> Nothing And Request.QueryString("xhtml") = "1" Then
mimeTypeOverride = True
End If
Dim realBrowser As Boolean = False
If Not (Request.ServerVariables("HTTP_ACCEPT") Is Nothing) Or mimeTypeOverride Then
Dim httpAccept As String = Request.ServerVariables("HTTP_ACCEPT")
If Not (httpAccept Is Nothing) And httpAccept.IndexOf("application/xhtml+xml") > -1 Or mimeTypeOverride Then
realBrowser = True
End If
End If
If realBrowser And Not debugMode Then
Response.ContentType = "application/xhtml+xml"
litDoctype.Text = ""
litDoctype.Text = "" & vbNewLine
litDoctype.Text += ""
Else
Response.ContentType = "application/xml"
litDoctype.Text = ""
End If
End Sub
This code is actually longer than you might expect, but this version is a bit more robust than a simple condition. The first to notice about this code is obvious: it checks to see if the browser can accept the application/xhtml+xml content type by checking the HTTP_ACCEPT server variable. Depending on the result, the browser either gets application/xhtml+xml content type and the XHTML 1.1 doctype or text/html content type and XHTML 1.0 Transitional.
Secondly, as you can also see, I've included a debug mode which, if set to true, will tell the page to serve the "less-strict" doctype. This comes in handy when you want to make sure you get the "less-strict" doctype. I'm using a private class boolean field named debugMode as a means to put the entire page into debugMode. You could also use a query parameter to put just this one part into debug mode.
Finally, you can see something rather odd towards the beginning of the code. Even though we are doing all of this to guarantee well formed XML, this does not in any way give us any information about validation. That's where this other part comes in. If you were go point the W3C validator at this page it would actually get the XHTML 1.0 Transitional doctype with the text/html content-type. That's all well and good for validating against that doctype, but you technically have two different versions of the same page here. You need to validate against the XHTML 1.1 version as well. So, with the inclusion of a quick query parameter check I'm allowing for the ability to give the W3C validator a Url such as default.aspx?xhtml=1 which will force the page to be in XHTML 1.1 mode. This is a little easier than always having to tell the W3C validator the XHTML 1.1 override (I never much liked the warning it gives you anyways when you do it their way anyhow). As I mentioned previously, you could use a similar technique for for it into the "less-strict" mode. One idea would be to set default.aspx?xhtml=0 to kick in "less-strict" mode.
I think my favorite new feature in Firefox 1.5 is the inclusion of the canvas. A canvas allows you to dynamically create images based on simple ECMAScript syntax. Creating boxes, lines, or even more advanced shapes with shadings is no problem at all with canvases. You can actually compare canvases to Microsoft's Windows Presentation Foundation (WPF) in its rendering quality.
The really great thing about canvases is that they aren't just in Firefox 1.5! They are also being added to Opera 9. Furthermore, they have been in Safari for a while!!! So, once again that other buggy/nasty browser with version numbers 6 and 7 is shown to be useless!
What types of things are possible with canvases? Basically anything you can dream up, really. This includes interactive dynamics. That is, you can also interact with the graphics in a way which feels very much like Flash itself. Below are some links including demos and tutorials relating to canvases. The first of which is the wikipedia article which contains a number of canvas links to examples. The second link is somewhat of an old ray-casting looking example which demonstrates more than anything else the speed of canvas interaction. It's really fast compared to what you would have to do manually in JavaScript, though much slower than Flash for doing complicated graphics. I think we can thank the lightning fast Gecko for the speed it does have. As with all things on the web, this is slower in Presto (Opera).
The last 32 days rocked! The release of .NET 2.0 and now Firefox 1.5. Both are absolutely revolutionary in their technology.
So, go get it! Woohoo!!! The link is in the list below.
Also, I remind everybody about my "What's new in Firefox 1.5" video, which is also in the list of links below.
...and yes, Chris Pederick's Web Developer Toolbar works great with Firefox 1.5. His page link is also below...
A few months ago I thought of a weird experiment. I wondered if a webpage could save where a user moved his or her mouse in the window area. Turns out that yeah it is possible. You simply have to trap the x and y coordinates of the mouse and XmlHttp them back to the server for persistence. Yehaw...boring.
But, to take the boredom to another level I thought of something even lamer. So I altered my algorithm a bit from tracking the user's cursor to following the user's cursor. Ergo, my obsessed fan demo...
It's old news now, but I had my 15-minutes back in September with my Firefox 1.5 preview video. The video is for end-users and briefly touches on some of the new features in Firefox 1.5. It also lets the users in on why "standards" are so important.
So, in case you haven't seen my video yet...here it is.
The other day in my .NET Complete course I gave a lecture on Web-Standards development. I covered the history of web-standards and gave an overview of the mindset, simplicity, and beauty of XHTML/CSS development.
For the complete synopsis of my lecture see my .NET Complete page at .NET Complete
In my mind, one of the coolest things tht modern web browsers can do is deal with base64 PNG images. PNG images are the "new standard" in web images. They can be very small in size or they can be larger as true color images depending on your needs. They don't replace everything, but they do replace a lot.
A base64 PNG image is a PNG image encoded as base64. Base64 encoding is a way to encode non-printable characters (stuff you can't see, but the computer can read) into printable characters (things like letters and numbers).
Base64 PNG images (which are text) can actually be read by modern web browsers as real images. In fact, it's one of my qualification requirements for being a modern web browser (actually there are MANY requirements in my mind). You can actually use base64 PNG images directly in CSS. Here's an example...
background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAlgAAABkCAYAAABaQU4jAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAAC6ZJREFUeF7t3c1xHLkZBuC9++Lj+iD55AScgCNQBM7AGTiFra2ltso3xcAkmMUmQ3qABjBfY4D+IcUy5Xm2iiWJ09M/TzeJd4EPmJ9+8h8BAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgACBDyHw+feXv4++/vLr898+xAmePIlPvz3//Pm35399+vr87/zn5d9Hd1Hfd3T7tN2f//Pyp+SX/jzzPtv+bwTq/Tpy9Lrtj/qzcOQabUOAAAEC7yCQg9XXl5fp18PzHymovMOh32WXnx6ef/l8Oef2la4t/fvr8z/3DvjXh5d/ZIfL9nvbxtdzkLu870dyOnN9/2/b1vuVnv29a2vbPjw/7W3rdQIECBAg0ARawCpBKjUo7evh+XEJJ5fwcAkuH50tNoa11yqHpnIN6e9b13DZ7knA+uh3+e3nJ2C93dAeCBAgQGBHIASs4f+h59dLj9BHx6zn2Q8Jpt6rEhK/za7hEiC/1SCmB+uj3+m3nZ+A9TY/7yZAgACBAwJ7ASvtovXsTIZUcs1TqOPaq3lK9Sxx+73TjNvP9l2H9y5B6XG0v3S8WR3N5T1fliHSSxB7RZicDRH2x6zXfBMAi91enc9Z53zvwn1J/66W06AZ7uXe+fT737vv/TFj3drWeZ15Vo6c0yxgRd96rmHY2BDh3g+q1wkQIEDgKnAwYOWappFbCjSt56fWcqXhxkHQyY1oHYaLdV+TGqnSe7YM2+3suzWal6L2M/c3FzEv55t7t75rwFrC2uX8S3BbX8OX3KB3HvU8+ms445zem0NjGRoNdk/te4OwPDnG06hWKXvf7n9432eBt9at5d7DahPOK004mBxjOFxdhoNHz8uq53IUsFpPbQna9Zzrz8csuJ951mxLgAABAncksBWwUgCojd+oBis3yEt91rdVD1ZpMPuw0LZPjXPtWQm9RrEHpISxXP+VG9qyfWuMu6Lj2MvWGv/SG7VVfF5DRZ0B+A4BK4fTfE7pGtK11ML7EkRTMNiqFTvr3OxKcE3HTfuv+8nH7wJW9Yv3MtS0/RHvTezVyX/v7s0sJMYfq1j7VwNuOl67D8Eph8VyDeE8VyFr73mJ59QHrBqyay/m6DxNYLijX4oulQABAt9DYDWLMM6+q38vAWrYC1F6aDZeW/V6lfByM9RSZv49xSGpFgYGPVItZIXXQoF67qVJ25SgVQvXb45bw05qwFuPxfccIpwU18cws2rMS6joG/OZ26zHrdqNivpHw71tiLP04g3PKfRIhu2bW+41Kz1ypwPWoDetBt1R71nt1Tr6vPS1eX3AuvYi3s40bT1YP9BM2u/xe8E+CBAgQOCNAl1PQgon8astdzDqwdo69KgnqA33HBjG2+pJGtXFxIDVr0fVeuFCI1nCQBsafLeANZjePwo5OSyVJTPOWE+dJ0O6o2PX781qrvpjxNmaR+q0hgG8XusguOzV0+VA3i2LsfW89PVd9fzXQ4rjZTwErDf+gvF2AgQI3KvAXg3Wuk7othEqw4hp7amlvif0fKW/R9faMIYhsqf0vb6R3gl9SwDs1quahZZ0/NzAdtv3Q4MfKWCla+mfx6POe/dzErCWodh1uF4H7cvr9T7VcNrXxR1Za6w5bwSsvXXF+gC2d803lmXdshb4L9e2tYRH7hHVg3WvvyJdNwECBF4ncKRxms2kirPuUuMc19Ca9SiUWqDrkgiluDkWER8KWOl4YdhqK2Dl3qEw9BeGBh9X637Vwu2wJtgR1ekswskQ6l4PVh+wzjjv3c9XBqwctm6C8FKEfi2cP7Go61bP0F7A6q9x75qnAaus71bD5exe52fnQK/rkWfFNgQIECBwJwJHGqcYeCpL7BWa1snsrIie9xFmitWhsbDvw1Pj27DVZMX2GLCu226sYH9iRff3DFhnnffu5zRg7dyrvR+HFpwPuh0KWJPFbUNAXmZ+1k8jOLjaej/jtA05zo6XAtaBVd/3jLxOgAABAnckcKRxqgt1xp6VUOg8nDLf92Cluqj0ntFQzKSmapl9N/gcwTxclod5rkOWW3U7fWCrny/XZjLGz2KsQ5zle0cehfcMWGed+966/vxHAes6u3Bch1R7+eq+tj6vca8nse1jY4hwL2C3SQ7h/m/VYNXzrbV5w2UaJhMSjtx/2xAgQIAAgRuBrYCVa21WazhdG+CwOvrNwp5xev+gx+u2vqh+ll/oQdia2TaaRViCRVkDaR0URg3y7FHYaqhn73nPgHXWOZ3jqKg/+5QV7ftlGmLAvVkEtc5sjLMIy/Ic/bBZW+7gQG/YXvF4C2pdj2R+32CmZ+iFWq95tcxsXK3jNgpYeSmIUocW77MPe/ZLkwABAgReJXBkmYbZx8y0IuFafxU/aHkwVNSCzrKMwi+5Z6Q21pfv9bP/YjF73T587yaoxbWQ+mUaYr3WFtRHC1itR6o0/sXs+oHWI+caKsoSG73zaB2s7t7kJS7ivYn1V53zUsdW7/3BD73eC1iTYyy1e8vzs1oiYhWw++exWzx0FLBWwXQQ9Pu6uFf9sHkTAQIECNyPQFtdfTKDLDVG04+YqQuRhtmDqaFO26fGeRRqcuPWzThM7+nDVb0DpUYrzlDMxfTT3qTROZ2YATY7781QVou9u0Losq+bzz/MYWZQNF7vRXo9Hq8t+HrCud6DEEgeV8sSjFdy/1JnV4b3fRsN0/b7L9uniQc3wWdk1567jeLxyXU/bi0NUZ6v62zWZTLE6pzqM9Xvp82YTe8pQ9N12/6e3M9vCFdKgAABAgQIZIFaWzbiqOH27OcGoiVAgAABAgQI3LVAHUYdri+2sfr+XaO5eAIECBAgQIDAlkD4vMM8nJp6tNrQ2VKXdWgYjzIBAgQIECBAgEAQaOuLleUHztZIwSRAgAABAgQIENgQsEimx4MAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgU2B/wJmPk0do+6gLAAAAABJRU5ErkJggg==);
Well, it's not SUPPOSED to be small! It's supposed to be embeddable. And it is. But think for a moment. You can take an image (not just PNG mind you, GIF can do this as well) and turn it into Base64. Now, can't you dynamically load images on the client? Well, yes you can... All you have to do is do a remote call to somewhere which will send the Base64 stream back.
One you get the stream back all you have to do is prefix the base64 stream with "data:image/png;base64," and assign the entire value to the src property (attribute) of an img object.
Here's an example I put together a few months ago of how you can do all this... Firefox users only please! IE6 won't get NEAR base64 images.
Actually, this is also a great example of how to work with web remoting (I just CAN'T call it Ajax, that's too weird) and how to dynamically work with XML files.
Ever wanted to do some type of graphics in the browser? Well, you can do it and you have many options. One of the options is something I'll blog about in a little while, but another way to do it is via shapes created directly in JavaScript.
By itself it's rather useless, but you can use JavaScript graphics as the basis for many other things including Widgets...
At any rate, here's my unedited draft of my "Introduction to Javascript Graphics" chapter. Have fun...
Well, well, well it looks like Opera is getting closer to being usable. They recently added support for XSLT. Personally, I love XSLT. So much so that I keep my primary resume in XML and make it viewable via a XSLT. Soon Opera 9 users will be able to view my resume as well as other XSLT based pages I expose to the web.
As another positive, Opera 9 also comes VERY close to passing the ACID 2 test.
Opera 9 however did NOT fix some of it's major problems. Here's a list of things which must be fixed before I stop telling people to avoid it.
In addition to my WinFX blog I'm also going to be working on this new dynamics blog, called Dynamic Bliss. This blog will cover client-side topics such as XML based, out-of-band procedure calling ("Ajax" though I don't approve of that name), ECMAScript dynamics, dynamic graphics, widget creation, and a few other browser-related topics.
This blog is the replacement of a book I was working on regarding the same topic. I'm a strong believer that blogging is the new book (for technology at the moment) and we should all submit to that. Parts of the blog will include video chapters from the my video book.
