Posted by Dan Eastwell
Thu, 08 Jan 2009 13:35:00 GMT
A quick test of IE8 shows a 'bug' ( It may be correct behaviour, it's not clear from the spec), where if you have two floated elements (e.g. an a, containing a span), the background colour for the child element will not show on the hover state, if the background-color for the normal state is not specified.
See this test case for an example:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>IE8 Test page</title>
<style>
body{ font-family:sans-serif;}
a{
background-color:#ffcc00;
color:#000;
padding-left:10px;
text-decoration:none;
float:left;
}
a span{
float:left;
}
a:hover{
color:#fff;
text-decoration:underline;
}
a:hover span{
background-color:#000;
}
</style>
</head>
<body>
<a href="#">
<span>Text</span>
</a>
</body>
</html>
Specifying the background-color on the span in this example will cause the a:hover span background-color to show. Setting it to transparent will not.
Posted in Browsers, CSS | Tags background, bug, bugs, class, color, css, debugging, exlporer, explorer, hover, ie8, internet, internet, psuedo, state | 2 comments | no trackbacks
Posted by Dan Eastwell
Mon, 28 Jan 2008 14:34:00 GMT
Just come across a problem that may occur again - if you're trying to create a button using background images for button tops and bottoms and a span for an icon (for example), then be careful that the 'hand' cursor appears in Internet Explorer (IE), in all latest versions (5.5, 6, 7).
If you have HTML of the form:
<div class="button">
<a href="#"><span>Button text</span></a>
</div>
you might well set the span to display:block in order to have a background image show. In this case, IE will render the default cursor for span, rather than the hand ('pointer') you're expecting
in this case, set the CSS to:
div.button span{
cursor:hand;
}
in your IE only css file (or add cursor:pointer;cursor:hand if you don't filter out Internet Explorer using conditional comments). The hand for the link will now show.
Posted in Browsers, CSS | no comments | no trackbacks
Posted by Dan Eastwell
Fri, 21 Dec 2007 11:06:03 GMT
"We get to drive a few makes of cars (browsers) on the (information) highway. When we want new features, we have to wait for a new model to come out, and recently it feels like Cuba. The top selling car is a 1950’s Chevy."
Dion Almaer in an article about Google Gears
Posted in Browsers | no comments | no trackbacks
Posted by Dan Eastwell
Sat, 07 Apr 2007 20:08:00 GMT
A bit of shameless self promotion, here, but I've made the effort, so why not let people know?
There's a few new articles on my main site:
Boots Expert: Progressive enhancement: Javascript enhancement to pages, and CSS systems analysis, to tight accessibility requirements.
This project went live at the end of last week, and I'm fairly proud of how the project went and the outcomes. The site is very accessible and has been well reviewed and tested. I think the design is great (not my work!) and I'm happy with the soundness of the XHTML and the CSS, especially, which I think has been nicely modularised.
Energy Saving Trust: Ajax modules: Reskin work on existing coldfusion-driven modules, creating javascript to enhance the look of the output code. Ajax modules written to enhance HTML forms.
Design Council: Complex Modular Site: A complex modular site using transparencies, and intricate CSS structure.
I worked on this last year and now the site is live. This was a large project with many templates necessary to match the designs, it's lead me to think a lot about the status of interface architecture for the web (or CSS/XHTML, if you will…) as a discipline requiring the same level of forethought as any other software-based discipline, when dealing with projects with any level of scale or complexity.
Posted in Usability, Browsers, CSS, XHTML, Interface Development, Design, Javascript and the DOM | no comments | no trackbacks
Posted by Dan Eastwell
Sat, 07 Apr 2007 10:14:00 GMT
i'm writing this from my phone-an instrument with a numeric keypad and a joystick suited to a hamster. my connection takes me back to 1996. i can read my gmail, but can't send to flickr. twitter doesn't want to know either through opera mini or text. it's baby steps at the moment, and even with a phone only a year old, high technological barriers.
Read more...
Posted in Browsers, Interface Development, Design, The Web | Tags mini, mobile, opera, sms, text, web | 2 comments | no trackbacks
Posted by Dan Eastwell
Wed, 21 Mar 2007 12:45:00 GMT
I like the The nested-objects method of embedding flash into a web page but it has its drawbacks
It gets rid of the embed element and uses conditional comments in order to hide classid and codebase parameters from non-IE browsers, which includes the W3C validator.
However, in the limited testing I've done, although this method loads swf files into Firefox, the specific example I'm working on uses contained flv video files, and the controls don't work. It may be the video, or it may be the controls, either way a javascript workaround may have to be the answer in this instance..
Update: You know what it was? <param name="wmode" value="transparent" /> This bit of code will stop controls in swf flash movies from working when using the 'nested-objects' or conditional comments flash embedding method.
My guess would be this is also true for < 1.5 Firefox and older Netscape browsers.
Posted in Browsers, XHTML, Interface Development | no comments | no trackbacks
Posted by Dan Eastwell
Thu, 15 Mar 2007 17:10:23 GMT
Links don’t work in transparent elements in IE6 using the filter:progid:DXImageTransform.Microsoft.AlphaImageLoader method, when the container the filter is applied to is absolutely positioned.
One (extra) hack to get round this is to change the sizingMethod to crop and then make sure that the links are only going to be over an area that is transparent.
The only other hack is to move the filter up onto the link container, as per here:
http://www.satzansatz.de/cssd/tmp/alphatransparency.html
or serve IE a flat background, as it’s all it can robustly cope with…
Posted in Browsers, CSS | no comments | no trackbacks
Posted by Dan Eastwell
Mon, 29 Jan 2007 10:14:00 GMT
You'd think that with IE7's zoom feature, we'd get rid of one real testing headache when creating scalable layouts with CSS.
That's true in the vast majority of cases, but there are still issues with techniques we've come to get used to.
Take this example: www.digitaluk.co.uk.
With one level of zoom, you find that the calculation for the centering of the navigation gives a different result to that for the main content:
And is greater at the second level:
This may be due to the fact that the navigation is absolutely positioned, within a relative parent container, a technique for getting main content first on the page (normally for SEO), but not first when viewed in the browser.
This may be an issue we front-end developers need to tackle, or it may be a bug in IE7's zoom facility, I've not tested this thoroughly enough yet, but there is an issue that needs resolving.
Posted in Browsers, CSS, XHTML, Interface Development | Tags css, html, IE7, resize, resizing, zoom | 1 comment
Posted by Dan Eastwell
Fri, 12 Jan 2007 11:05:46 GMT
If you have a containing element (.container) with two elements, floated left and right, with fixed widths, the implied space between them wont show within Safari, unless the containing element's width is specified.
If the width is not specified, all browsers except safari assume the container takes up 100% of the space it has to go in. Safari was assumes it takes up 100% of the space its components occupied.
The margin between objects is 'implied', in that it was 'the space between objects'. In safari, this means there is no implied space between these floated elements.
Setting:
div.container{
width:100%;
}
sorts it out.
Posted in Browsers, CSS | 1 comment | no trackbacks
Posted by Dan Eastwell
Wed, 03 Jan 2007 15:57:00 GMT
One of the biggest banes of today's modern internet is how to clear elements that appear after a floated element.
This has been covered well, within this article on easyclearing from position is everything. However, the solution for firefox is a bit of a hack - you don't need to add an invisible dot after the content.
Now that IE7 has hit the ground running and has better standards support, we can make use of this to solve our problem
What we actually need is a selector that applies to everything immediately after our floated element, or its container. The W3C spec already has this element: the adjacent selector: A + B.
This will apply styling to B, where it is the first sibling of A - in our example the thing that follows our floated element, or its container.
Apply to all
We'd like to have all types of element that follow our floated element to be cleared. There's a CSS selector that allows us to do that: the universal selector *
Thus we have the following code:
div.container + *{
clear:left;
}
What about other browsers?
Now, this is recklessly untested at the moment, but should work in Firefox and IE7. IE6 will still require clearing from the old easyclearing hack ({height: 1%;}), although that would probably be best placed in a conditionally commented file, rather than using the old * html hack.
Edit: This method doesn't appear does seem to work in Safari.
Edit: This method 'causes problems' in IE5.01, so will need to be hacked out in your tweaks file, possibly using this method:
@media all{
* html div#container + * {
clear: none;
}
}
The main point still stands, though, no hack is needed to get clearing in standards compliant browsers and the existing hacks are needed in < standards compliant browsers. Shame about IE5.10 ruining the party for everyone. Again.
Posted in Browsers, CSS, Interface Development | Tags adjacent, clear, css, easyclearing, float, selector, universal | no comments | no trackbacks
