IE10 also validates special character escape sequences

Most of the pages have been rendering pretty consistently in Internet Explorer 10. I was perturbed that one particular page was giving a problem on IE10, but, not on Chrome and Firefox. When I opened the developer tools, I saw the following two error reports:

HTML1402: Character reference is missing an ending semi-colon “;”.

and

HTML1403: Numeric character reference does not resolve to a valid character.

On going to the relevant line of HTML code, I found that there was a comment section which contained data curtailed beyond 30 characters.

What the developer had done in fact was to encode the single quote in the comment before inserting it into the database and then extract the first 30 characters via code before rendering it. As a result the single quote ( ‘ ) translated into its escape sequence [& # 3 9 ;] and got cut off to some text ending in &#3.

Chrome did not even report a warning about this malformed escape character. Neither did Firefox.

To set matters straight, firstly, we need to encode after curtailing and not before.

We could also try the following css which actually curtails on the basis of width. The good thing about it is that it considers the rendered text and not the html text. Therefore, you will never have a situation where a portion of your escape sequence is curtailed.

<style>
.curtail {width: 329px; white-space: nowrap; overflow: hidden; text-overflow: ellipsis;}
</style>
try it on the following html in your page
<p class=”curtail”>
This is some text interspersed with single quotes’ to ensure that it is going to be a lot more longer than hundred pixels.
</p>

–Updated on December 5, 2012

Thanks to my colleagues who were trying the above class on a span and found that it was ineffective. All we had to do was a little tweak. Basically span is an inline element and as such does not take widths. We updated the class to make it behave like an inline-block element and it worked!

<style>
.curtail {width: 329px; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; display: inline-block;}
</style>
try it on the following html in your page
<span>
This is some text interspersed with single quotes’ to ensure that it is going to be a lot more longer than hundred pixels.
</span>

Personally, HTML conformance is a good thing. However, most programmers, who treat HTML with disdain may be in for trouble if they continue to ignore malformed HTML when handling it in their code.

Validate doctype XHTML 1.0 strict on w3 validator correctly

In our Visual Studio settings, the default doctype for pages is XHTML 1.0 transitional. However, in recent days, after getting the Internet Explorer 10 update, I found that I could not debug the page because the browser kept indicating an error about the wrong doctype. My site is not expected to run in HTML 5 mode, but, the recommendation was for using the HTML 5 doctype.

I found that using XHTML 1.0 strict doctype resolved the problem. Still digging deeper, I found a very interesting answer to the difference between strict and transitional mode in http://stackoverflow.com/questions/3735979/browser-rendering-difference-between-strict-transitional-doctypes

Notably, the following extract is of interest,

The final piece of the puzzle is that all modern browsers render pages with a strict DOCTYPE in ‘strict’ mode and pages with a transitional DOCTYPE in ‘almost strict’ mode.

The next problem was that the br tag gave an error despite closing it (
). Initially, I was led to believe that either we will have to get away from strict mode also or live with the errors in W3C validator. But reading the error details carefully I realized, that the validator expected it to be inside a container tag like div, p, etc. and not directly in the body. You can see the gallery below to see the difference yourself.

The following link is great to understand what you can and should not do in strict mode. I do kind of agree that how the page looks should be part of CSS and not the HTML.

http://24ways.org/2005/transitional-vs-strict-markup

Fix bgiframe related JavaScript issues in IE9+

For quite a few months one of the pages in my custom project planning and tracking application would not open any pop ups in IE9 but would work fine in other browsers. The simple work around was to open that page in Chrome. Finally, when IE10 came, I decided to troubleshoot the issue.

The issue reported in the developer console was:

SCRIPT5022: InvalidCharacterError

Ultimately, with the help of the following URL it was discovered that the issue pertains to bgiframe using a regular expression which errors out in internet explorer (because of the faulty regex for IE9+).

http://stackoverflow.com/questions/6424526/bgiframe-plugin-causes-error-in-ie9

All that was done to resolve the issue was replace

$.browser.msie && /6.0/.test(navigator.userAgent)

with

$.browser.msie && /msie 6\.0/i.test(navigator.userAgent)

How to optimize CSS use and improve performance

I just went through this great article on how to optimize CSS use and improve performance. After all, JavaScript is not the only area where we can improve performance, right?

I tried posting the link to digg.com, but it just kept rejecting it as spam. If you want to go through it and the video, the link is, http://www.stubbornella.org/content/2010/07/01/top-5-mistakes-of-massive-css/

The brief of the article is below:

The top 5 mistakes

  • 42% Don’t GZIP CSS
  • 44% Have more than 2 CSS external files
  • 56% Serve CSS with cookies (yummy to eat, bad for static content)
  • 62% Don’t minify (check out the YUI Compressor!)
  • 21% Have greater than 100K of CSS

More Advanced Techniques

Declaration Worst Offender > 10 > 100 Reasonable
float 733 56% 13% If you have a good nestable grids system, you shouldn’t need many floats. The worst offender in the Alexa Top 1000 sites declared the float property more than 700 times! Aim for less than 10.
h1-6 511 56% 9% There are only so many usable font sizes on the web. Below 10px in most fonts is legible only by mice and few sites use really large typography as a design element. Imagine that a site chooses to use 24px as their max. That leaves 14 different sizes, however, we need to divide that number by two because most users can’t see subtle differences like a 1px change in font size. That leaves seven different heading sizes, which means 56% of sites in the Alexa top 1000 have too many heading declarations.
margin: 0 518 64% 14% Different browsers have different default stylesheets. These stylesheets define how elements should look if you haven’t chosen an alternate style. It is important to get all browsers to the same starting point because it eliminates bugs and time wasted testing simple browser compatibility issues. This is should be accomplished using a reset stylesheet such as the one included in YUI. When a reset stylesheet isn’t used, margin zero tends to be sprinkled throughout the stylesheet as developers try to cope with browser differences in the absense of an abstracted solution. Setting the default margins to zero is the most basic job of a reset stylesheet, which means that 64% of the Alexa Top 1000 sites could benefit from including reset.css.
padding: 0 510 62% 10% Excessive declarations of padding zero are similar to margins (see the above description). The worse offender in this case declared padding zero 510 times.
font-size 889 78% 23% Headings (h1-6) often get hidden in class names, which can disguise typography efficiency issues. It is helpful to grep “font-size” to get an idea how many hidden headings exist on the site. The same rules apply to font-size that were explained under h1-6, so in fact the problem is much worse than our initial estimate. These figures mean that 78% of the Alexa Top 1000 sites have excessive heading declarations when we consider hidden headings. In addition, 22% of sites may not be getting the SEO benefits of properly using heading elements.
!important 526 12%* Important overrides all other declarations specificity, so it can be dangerous. If used correctly, only on leaf nodes, it can be a powerful tool for creating typography and spacing mixins that stand outside of the normal cascade. On the other hand, excessive use of important is a sure indication of specificity wars. Specificity wars are what happens when developers start trying to beat each others specificity, rather than having a real solid architecture and code standards. Eventually, like the worst offender in this case with 526 important properties, you can end up in a case where nearly every property is marked important. This means that 12% of the Alexa Top 1000 Sites probably has an internal specificity war in it’s web team.

Finally HTML 5 wins!

For years, there have been two protocols in the works at W3C. XHTML 2.0 and HTML 5.

Looking at the fact that most modern browsers have started supporting HTML 5 while nothing concrete came out on the XHTML 2.0 front, it was quite obvious where the support was from all the major companies.

I first got an inkling when I read the following article – http://stuffandnonsense.co.uk/blog/about/keep_calm_and_carry_on_with_html5/

So I googled a bit and found the following:

http://www.w3.org/News/2009#entry-6601

A more detailed understanding can be taken from http://www.w3.org/MarkUp/Activity

Of course, even the HTML 5 has been given the signal to be the upcoming standard, it does not mean that it is without its deficiencies. However, things had stagnated on the HTML standards front in the last 2-3 years and at least that part of things will get better!

You can learn more about HTML 5 from http://www.w3schools.com/html5/html5_reference.asp

Of course, despite all this euphoria, IE users will have to wait till IE 9 comes out – http://digg.com/d31AaBH

You use IE6 as your browser because…

IE6 usage has been falling consistently in the last 1 year. However, in the last one month, that slide has lessened. It is very intriguing why people are not abandoning it in a hurry. Microsoft has announced that it will stop support for it by 2014. Please answer the following poll if you are an IE6 user.