Internet Explorer 6

Published | 16.32, 11th of March 2010, by Jay Vincent | Technical

You may have seen several headlines in recent weeks about Microsoft's web browser internet explorer 6 (ie6):

"Google has begun to phase out support for Internet Explorer 6, the browser identified as the weak link in a cyber attack on the search engine."
http://news.bbc.co.uk/1/hi/8488751.stm

For people who aren't web designers/developers, the outcry against ie6 might seem irrational and trivial so I wanted to try and explain why this is such a big deal, and why Artlines Media will follow suit in dis-regarding ie6 in our browser-compatibility testing.

Security

The security (or lack thereof) of ie6 is predominantly what has prompted google to drop its browser support - essentially the straw that broke the camel's back. Vulnerabilities and flaws exist not only in the browser but also in the implementation of ActiveX controls, which allow programs to be installed through internet explorer. Malware, such as computer viruses and spyware, can be accidentally installed from malicious websites using ActiveX controls.

CSS Standards

Probably the most noticeable errors an ie6 user would experience is poor display of webpages - elements not appearing where they should, unwanted gaps, etc. This is due to ie6's terrible implementation of CSS, the styling language used to position and control presentation of a webpage. All modern web browsers now interpret CSS according to the W3C CSS 2.0 specification, with few discrepancies between browsers. And with CSS 3 just round the corner, it is holding the web back when websites must also cater for ie6 with its many CSS bugs and terrible CSS implementation. (check out http://www.positioniseverything.net/explorer.html to see some of these bugs)

PNG Support

PNG is an image file-type which allows for transparency and semi-transparency. Use of PNG images in modern web designs is on the up, yet ie6 does not support them. ie6 instead removes all transparency and displays the image with a solid colour background (usually grey). To get PNGs to work in ie6 requires long-winded javascript-based fixes, which are non-compliant themselves.

"Quirks Mode"

Microsofts poor attempts to follow set guidelines on CSS and javascript implementation has resulted in what they have branded "quirks mode" - a not quite there version of compliance. This has been a long-running joke in the web industry, but I feel 9 years of dealing with it has taken the joke too far.

So in conclusion...

It is so so frustrating for a web developer to create a website which follows all modern web standards and works perfectly in standards-compliant browsers such as firefox, only for the client to complain of ie6 issues. Accommodating for these issues has always been time-consuming and frustrating.

So from now on, when we design and develop websites for our clients, ie6 compatibility will be seen an extra service in our web development process.

No comments | Make a comment (Average rating | 4.38 / 5)

Integrating Instant Messenger with your website

Published | 14.27, 13th of May 2009, by Chris van Aurich | Technical

After recently doing some research on live messenger integration, I have found an easy way to incorporate Microsoft Instant Messenger with your website.

Uses for IM on a website

• Instant support for existing/new clients
• Instant sales enquiry activity
• Live on-line tutorial support
• No MSN Messenger required plus the visitor remains anonymous
• Maximise your customer interaction
• IT - Support existing clients by offering IM via a secure log in area
• Accounts - Deal with Invoice queries in an instant

If you are interested in this facility, contact us and we will be happy to help.

No comments | Make a comment (Average rating | 3.67 / 5)

My standard CSS resets for default element properties

Published | 16.01, 30th of March 2009, by Jay Vincent | Technical

Whenever I start a new CSS build, I use a pre-made stylesheet and add to it, rather than create one from scratch. There are a few reasons for this:

• HTML elements have default browser-inherited properties: for example, unstyled text usually display as 16px times new roman.
• Different browsers may apply slightly different default values. In interner explorer, the h1 tag displays at 300% in relation to its parent element font-size, where as firefox displays at 200%.
• Re-declaring these values ensures all browsers are using the correct styles and are displaying uniformly and as intended.

Good practise for font-size declarations is to set the size in the body tag using em's or a percentage (not pixels), so a user can over-ride the values using the browser's 'increase text-size' functions. All other font-size declarations should then be made relative to this.

Example:

We want to have a font-size of 12px for the body text and h1 tags of 24px:
note: The browser's default font-size setting is 16px, so 75% amounts to 12px.

body
{
     font-size: 75%;
     font-family: arial, helvetica, sans-serif;
     color: #000;
     background: #fff;
}

h1
{
     font-size: 200%;
}

There are other values and properties which require attention, most notably element margins of block elements, but the best way to find out what CSS works best for you is thorough mulit-browser testing and a passion for web design and self-improvement :)

No comments | Make a comment (Average rating | 4.67 / 5)

Let's (not) make some forms

Published | 16.15, 23rd of January 2009, by Jay Vincent | Technical

One of the most unenjoyable tasks I often have to undertake is the creation of forms - simple web-to-email forms. Therefore, I've decided to create a little wizard-like application to allow non-webbies to create them, so I don't have to. A few points to consider for anyone doing this are as follows:

1. The PHP page which will process the form will need to be generic, and able to handle any input type thrown at it - a checkbox group is read as an array, where as radio button values are simply strings.
2. The PHP proccessing page will need to recognise which fields are marked as required fields.
3. If required fields are left blank, the PHP processing page will need to send the user back to the form, with values the user has already inputted preserved.
4. Inputted values will run through a PHP regular expressions function which will allow only white-listed characters. This security measure will prevent form hi-jacking.
5. The PHP processing page will need to verify it is receiving data from its own website. This is done by checking the $_SERVER['HTTP_REFERER'] variable.
6. The recipients email address will be cross-referenced in a database table by a unique ID. This ID is what will be specified on the form page. This security measure means a hacker can't alter the recipient email address.
7. The form will need to specify a redirect page the user will be sent to upon successful submission.

The creation of the form itself will be wizard-like - WYSIWYG almost, with the user specifying which type of input, its possible values, required fields, etc. Each form and its contents will be stored in a mySQL database table.

This will be a fun little mini-project for me to work on, and when its done it will either be attached onto Arena (our custom CMS) and/or sold here on our website!

No comments | Make a comment (Average rating | 4.33 / 5)

In Flash Replacement - Controlling fonts and text-smoothing (anti-aliasing)

Published | 16.23, 15th of January 2009, by Jay Vincent | Technical

I'm coming across more and more websites using this technique, buzzwordly-named IFR (Inman Flash Replacement)

IFR is displaying text through flash - dynamically feeding a text string into a SWF file, which in turn displays the string in a font style specified by the SWF. Doing this ensures text is always displayed in a smooth anti-aliased fashion, and allows for non-web fonts to be used on web pages.

The most desirable application of the IFR technique is for text in header tags (h1, h2, h3, etc), but these tags are very important to search engine spiders and contribute quite heavily to how the page is read, so replacing them with flash files is a big no-no. Search engine's don't read text within flash (or images for that matter).

The solution is a clever mix of javascript and css:

1. h1, h2, h3, etc. tags are set to display: none by default.
2. Once the DOM (document object model) has loaded, a javascript function is triggered which reads the text in these tags, and inserts the SWF file into the tag with the text as a parameter.
3. The original text is then wrapped in a span tag.
4. The h1, h2, h3, etc tags are set to display: block, and span tags within these tags are set to display: none;

Thats how I think I'd do it anyway... although setting h1 tags to display: none by default scares me a little, perhaps visibility: hidden would be better. There would also need to be flash detection at stage 2...

Example - http://www.yourstreet.com/ - Uses IFR quite extensively on the homepage, but select 'no styles' and you'll see the text as normal web text - readable to us and search engines.

Personally, I'm not too keen on this technique although I can see its purpose. I'd prefer to use PHP's GD library and the freetype library because I feel dynamic content should be handled and processed at the server, not the client. Doing this eliminates the need to test the client machine environment for flash, activeX, browser, etc...

No comments | Make a comment (Average rating | 5.00 / 5)

Showing blog entries 1-5 of 9.

Page | 1 | 2 | 3 | 4 | 5