It’s nice that at least you’re moving your site to mobile device. It’s really important. Now if you’re using PHP the question is how to detect the mobile browser.
Every PHP developer knows that $_SERVER[‘HTTP_USER_AGENT’] string optionally contain the browser that access your site, but what are the possible values of this string?
in that really really full list of user agent strings: http://www.zytrax.com/tech/web/mobile_ids.html
Yes! Style sheets may block the rendering process in IE. When it comes to media different from the screen, as the print is:
media=print
this, lovely, browser stops the rendering until the sheet is loaded. This is pretty strange when it comes to such media, just because it is not used to render the page in a browser. In fact as Steve Souders says the normal behavior of the browser should be don’t block or even delay the sheets for media that is not the current one.
However for further reading see this post with many thanks to Steve Souders again.
Well I was writing these days about rounded corners and some cross browser techniques that help you do this job. But what’s actually a topic now is that most of the web developers are speaking about making different versions of a site for different browsers. Now this begins to look normal, but it isn’t. The ideal solution is to have everything working fine, in that case rounded corners to be rounded, on every browser.
As I wrote recently there is a way to do this in IE with the use of VML, but yet again this is not working on Opera, and puts another chunk of markup in your document, that leads to more difficult maintain.
The solution can be done with another approach that can be considered as one level beyond the VML usage. Thus you have scripts only in IE and clean CSS.
Everybody now’s using both:
-moz-border-radius -webkit-border-radius
and now’s coming the new wave with:
border-radius
property in CSS3, but as we know it will be maybe present in IE9 and any older MSIE will be discarded.
It stands for HTML components file, which is completely JavaScript code that’s included via CSS as:
behavior: url(border-radus.htc);
Of course you can find such .htc predefined files everywhere on the web and it’s completely working.
is that sometimes after using many HTML tags with border radius IE appears to crash, which is nothing new, but however not desirable.
Yes that’s the reality and when they become more and more bigger the web pages becomes to be irresponsible. The bitter reality is that you load any functionality that slows down the first user impression, but is needed only when you click on a button and so on. That’s a problem because you can load only that chunks you need in the beginning and than after a few seconds to load everything else. Some web applications have more than 100K of javascript which become really bad.
What you can do is to separate the logic into one or more files. Even when the user thinks everything is on the page and he can interact with the application and than to start to load the rest of the functionality.
That’s a pretty good technique. Nobody can start interacting on the 5th second of the load process. Usually the user looks at the interface starts to explore the app and after approximately the 10th second he start interacting with the page.
There are various techniques of loading JavaScript on demand. So I wont cover it, but that pattern of loading it latter when needed is really powerful.
Although I’ve read so many articles about web page optimization there’s not so much about optimizing HTML.
Maybe because nobody things that the HTML source of a page can be optimized or the optimization of it cannot bring some benefit to the page load experience. I don’t thing so. If something can be optimized, even if this does not give you so much, why you shouldn’t do it?
Well there are few things you should do and other that can speed up a little bit but you should not.
What is gzip? Well in breve everything the server generates is sent back to the client in text format. You’ve to possibilities to send it. Either compressed or uncompressed. As you may guess the compressed format is a lot faster than uncompressed. In fact to make it work that way you’d need to enable gzip which is supported by the web server. In the case of Apache web server this can be done by enabling mod_deflate. Take a look of mod_deflated and mod_inflate. This two modules gives you the possibility to make your site a lot faster and the good news is that this is done without a single line change. The bad news, as always there’s a bad news, is that sometimes this cannot help a visitor, simply because his browser doesn’t support such corresponding with the server. According to a research I’ve read recently almost 15% of the web browsers doesn’t support gzip. Sometimes the reason is old browser versions, sometimes because the state policy doesn’t allow it. However this is the first thing you should do to speed up your HTML even it is not related directly to HTML scripts. By the way this will speed up everything which is sent back to the client, especially CSS and JavaScript files and in the case of JavaScript this can improve dramatically the user experience. Continue reading Faster HTML! Why not?