(Update: Wow! They have a new address
, and they are looking even better!) has been my home page for a while, both at home and at the office. It is the only thing out there that is better for me than about:blank
. It is not very fast to load, but it loads much content in an asynchronous way (the A in AJAX). It is full of nice features and ticks and I am a such a newbie in Web development. It is difficult to even imagine how they do all this.
fortunately, there I met Scott Isaacs' blog
. His insights are a little different than the others. Here
, for instance is his post about how to do wonderful things in CSS without the hackery we are used to get from others
. You should read Scott post, but for short, he recommends you get the server to inject special class attributes on the HTML tags, including the browser type and version. This way you can use html.browsername.version
selectors on your CSS for style sheet that are tailored to a specific browser.
Scott's timing is excellent. I am doing a lot of ASP.NET 2.0
programming, and in the meanwhile I am learning CSS. I should better say that I have already learned CSS, and I am still learning how bad current implementations are. I am hating it, and I was about to go to the dark side, when Scott saved me.
Thanks a lot!
Anyway, I am open minded regarding any hack that would provide me a decent "abstraction layer" and that would offer reasonable forward compatibly.
I just want to add a very simple implementation of this pattern for ASP.NET 2.0:
I put this on my default master page:
<body class="<%= Me.GetBrowserCssClass %>">
I am not using the HTML tag as Scott suggests because VS says a class attribute there breaks the standard.
Then I add this to the code behind class:
Protected Function GetBrowserCssClass() As String
If Session("BrowserCssClass") Is Nothing Then
Dim b As HttpBrowserCapabilities = Request.Browser
Session("BrowserCssClass") = _
LCase(b("browser") & _
" m" & _b("majorversion") & _
" d" & Replace(b("minorversion"), ".", "", 2) & _
" " & Left(b("platform"), 3))
I am not sure saving the string in the Session is a good thing. I think the Capabilities collection is going to be populated anyway, so it is possible as much work to retrieve the string from the session as it is to build it again. Only testing would tell.
And I know the way I create the string is a little naive, but it works with what I have at hand for testing. I don't know how the platform string looks for browsers running in other operating systems.