Monday, 4 January 2010

funny font size in safari on the iPhone

picture of an iphone I finally decided I needed to sort out the font size in safari mobile, after a little tinkering it turns out you can just set the -webkit-text-size-adjust to "none" and that stops the browser from resizing the text.


body {
-webkit-text-size-adjust:none;
}

Wednesday, 23 December 2009

hasLayout problems after all these years

Having terrible trouble with all version of IE trying to get some peekaboo text to stay put. In this scenario a div was not paying ball at all, after setting hasLayout on pretty much every element in the entire page I realised that the system was outputting HTML without a DTD, dogh, I feel like i've just called tech support to complain about not being able to print, only to find out that the cleaner unplugged the printer.

Note to self, always check the most obvious thing first!

In IE7 I have a normal input type = button which as the behaviour that when you scroll the text in the button gets visually corrupted. So very slowly scrolling the button into view will wipe the text and the button will appear empty. The offending button is fine in IE6 and IE8, I was tempted to ignore this and mark it down as a bug in the browser but weakened and decided to fix it.

After tinkering with the CSS for a while I couldn't find any hack/fix for this issue, setting the writing-mode style to top to bottom, did fix it but didn't think having the button text written out vertically would go down well!

In the end....


window.attachEvent ('onscroll', function(){
// layout fix for IE7 disappearing text, element has layout so resorting to this madness!
document.getElementById('buttonMoreSections').style.backgroundColor=(document.documentElement.scrollTop % 2)? '#fff':'white';
})


total MADNESS !

Wednesday, 16 December 2009

Image Replacement, but only if images are enabled

The fact that you don't know whether the user has images enabled or not is a real problem with image replacement. You can't hide the existing text if images are disabled as the user will just end up with nothing, the standard way to handle this problem is to keep the text visible and have an image bigger than the text and place the image over the text, if the user doesn't have images they will still see the text. This is only ok if your replacing a header where the image is bigger than the text, but no good for any small images like icons where the text is always going to be bigger.

One way round this is to only add images if your sure the user has images enabled and to keep the text in the HTML flow for screen reader users.

One way of testing for images is to use JavaScript and set a class name on the HTML element if image are enabled/supported, then you can apply styles based on the existence of this class name, using this technique you'll only do image replacement if the user has JavaScript, CSS and Images enabled which is a good thing. If the user doesn't have any of these three you probably don't want to mess with the UI at all.

See the image replacement test page for some uses.


Tuesday, 10 November 2009

IE, butters text after filter is applied

IE8 logo In my little world IE8 usage over took IE7 for the first time last month, so decided to try to sort out my JavaScript fades which I disable for IE. The problem with the fades is after the fade in ends the text is blurred, fuzzy and generally butters!

TODO: add image of butters text...

I haven't looked into this in any great depth, but the problem seems to be with clearType text in IE and obj.style.filter. If you apply the Alpha(opacity) filter the text gets mashed up, so setting obj.style.filter="Alpha(opacity=100)" breaks the anti-alias on text.

One work around is to set a background colour on the element your going to apply a filter to. If you don't know which elements your going to fade in advance you can reset the filter after the fade has run, which isn't ideal but better than nothing.

I user a method similar to the bellow for setting opacity

/** @id Transition.SetOpacity */
function SetOpacity(el,opacity){
opacity = (opacity>=100)? 100 : opacity;
el.style.opacity = (opacity / 100);
el.style.MozOpacity = (opacity / 100);
el.style.KhtmlOpacity = (opacity / 100);

// private method to set opacity in IE
setIEOpacity(el,opacity)

function setIEOpacity(el,opacity){
if (!el.currentStyle.hasLayout){
// give element layout
el.style.zoom = 1;
}
if (!el.originalFilter){
// save the original filter, if one exists, so you can replace it after fade
el.originalFilter = el.currentStyle.filter || 'none';
}
// if opacity = 100 put the original filter back
el.style.filter = (opacity == 100) ?
el.originalFilter :
'progid:DXImageTransform.Microsoft.Alpha(opacity='+ opacity + ')';
}
}

NB. for a fade to work in IE at all, the element needs to have layout (obj.currentStyle.hasLayout) this is a read only attribute, to set it to true you need to give the element a style that will trigger it to set .hasLayout to true. I normally set the zoom style to 1 in an IE only stylesheet. For other ways of tringering hasLayout see haslayout.net

Wednesday, 7 October 2009

Forms, field by field error checking

Pyramidal neurons forming a network in the brainLike most developers for the past couple of years I've been implementing form checking on a field by field basis so when a user is filling in a form field the client side error checking is run. This has a couple of advantages, firstly the users gets the errors there and then, so when they get to the end of the form it should be valid and ready to submit, also it's quite fun to implement!

However, I was reading some research (which I have now temporarily misplaced!) which calls this approach into question. The basic premise was that in regard to form filling, the brain works in two different modes, the 'create' mode and the 'edit' mode.

In light of this the best way to handle forms is to allow the user to fill in the form (brain is in create mode) then validate all the elements in one go, so the user can go back over the form (brain in edit mode) to fix any errors. This was tested and found to be better than making the user switch from create to edit mode on a form field by field basis.

I'll try to find the relevant article, unfortunately my brain is in permanent 'confusion' mode so that may take some time!

Tuesday, 16 June 2009

Good bye browser matrix...

Is it time to just say "So long, and thanks for all the fish" to the browser matrix?


The browser matrix was quite handy in days of yor, when browsers worked in quite fundamentally different ways from each other (remember NS4 vis IE4?). Nice then to just pick a couple of browsers to support, you couldn't really expect your site to work on anything that you hadn't tested it on anyway.

So why don't we need it anymore?
Well, for a start if your using progressive enhancement you could expect your site will work on any user-agent that understands HTML. In which case what does "Support" actually mean? The notion that a website supports a specific browser OS combination is an old school way of looking at the web.

What's really the problem with saying that a site supports a particular browser though?
Well, let's look at what we really want from our website in the first place, we put our site up on the Internet, it's available to anyone, so we want it to work as well as possible, on as many user-agents as possible.

How should we achieve this?
The browser matrix method encourages developers to adopt a blinkered approach, we ask developers to build a site that works on browsers A, B and C. They build it using A and then debug on B and C, job done.

So where does that leave users of browser D?
Testers don't check browser D because its not on the matrix and any bugs that do get raised by users get rejected as "Unsupported user-agent" for the same reason. So, over time the browser matrix is a self for filling prophecy, the site will only work on browsers A, B and C.
There is another interesting aspect though, the notion of a browser being "Supported" changes the responsibility of the developer, if browser C has a bug in it that results in a visual formatting issue, the fact that the problem is a bug in the browser is irrelevant, because browser C is supported the developer has to accommodate the bug in the website, this means hacks and work-a-rounds in the code. The result of which means the more supported browsers in the matrix the more bloated your site gets as more and more browser bugs get accommodated for.

So what's the alternative?
The best alternative to having a browser matrix, is to NOT have a browser matrix!

Let's look at a scenario; we ask our developer to build the site to work on a text only browser, and give them a visual design or two of how the site should look on a desktop browser. The developer makes semantic, working HTML and enhances it to match the visual design, not having a matrix to work from the developer checks the enhanced look and feel on the browsers they have on their machine, likely the latest versions of the main browsers, the developer then hands the site over to testing.

The testers, without a browser matrix to follow, will start testing the site, they are likely to check the analytics of the site, or of a similar site, to see what user-agents people are using and organise their test effort accordingly, as well as that, they will test on any user-agent they have to hand, they can't help them selves!

Other people in the company will also raise bugs as the user-agent they are using is no longer "Unsupported".

Okay, so we have anarchy!
Our developer has loads of bugs assigned against the UI, how do we handle them all?

In actual fact, it's quite easy, bugs can be prioritised quite quickly by assessing a number of factors:

* What is the impact of the bug to the user? (is it a show stopper?)
* What is the frequency of the effected user-agent? (is it a high frequency browser?)
* How easy is it to fix
* What is the negative impact of fixing the bug? (e.g. do you have to introduce code forking?)

For example; bugs come in around visual layout in IE6, impact on users is fairly high, it's a high frequency browser, easy to fix and impact on other browsers is nil as we can fix issues using conditional comments for IE6 only, these can be done ASAP. So basic common sense really!

In the end the simple fact that more issues are know about will help and the site get better over time, since it won't get held back by the existence of a Browser Matrix.

Wednesday, 3 June 2009

Font size switching, yes again!

I was just having the font-size switching conversation with someone. I was banging on about our policy which is tell users how to change the font size in their browser, rather than duplicating this functionality with client side script.

All very well, but down at Shaw-Trust they (pretty much everyone) prefers the click to change method (e.g. three varying size "A"s next to each other and you click on the one you like the size of... www.webcredible.co.uk).

But, I complained, if you set the size of text you like in your browser then text in all websites sites, that aren't fixed size text, will be the right size?

Yes, but some sites don't support changing text size and break.

What do you mean? Either a site will be coded old school with fixed font size, in which case it wont change or it be relative size and will work?

No, some sites have relative font size but don't support larger sizes so if you change the font size in your browser the layout will be broken and you'll need to change it back in order to use the site.

You can't be serious, show me a site like that...

www.virginmedia.com (try IE with anything other than default font size)

oh...


IE6 Screen shot with larger and normal font size...

IE6 Screenshot with larger and normal font size
 

Note: the opinions on this page don't represent that of my employer in anyway. And, actually only vaguely represent my opinions on the date of publication. (Unlike Ms T, I am very much for turning)