bug 114 - border dashing and rounding not an option in Firefox

Issue: #114
Affects: Firefox 2.x
Fixed in: Firefox 3 (Beta 3 & Final)

Rounded corners make simple boxes look so much more appealing on the Web. CSS3 defines the border-radius CSS property, but of course Firefox, Safari and others implemented their own versions long ago before CSS3 was finalized.

In Firefox, specifying "-moz-border-radius: 5px;" for a block element will give a nice gentle curved corner to any box.

However, if your border is more than 1 (one) pixel in width, and you have it set to dashed, or dotted (e.g. not solid), then Firefox will not show the dashed/dotted pattern, but instead show a solid line.

The good news is that Firefox 3 (currently in Beta) appears to have fixed this issue.

Example:

<style type="text/css">
  div.fancy {
    border: 2px dashed #000066;
    -moz-border-radius: 5px;
  }
</style>
<div class="fancy">
This box should have a:<br/> dark blue<br/> 2 pixel<br/> dashed border<br/> with 5 pixel radius<br/> rounded corners.
</div>

This box should have a:
dark blue
2 pixel
dashed border
with 5 pixel radius
rounded corners.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 229 - not everything is absolute in IE

Issue: #229
Affects: IE6, IE7
Fixed in: IE8 Beta 1

The css "position:absolute" property works well to position a block element in an exact location on screen. However reader Xogede pointed out to us that there are scenarios where IE displays the element correctly, but it doesn't fire events on the element unless the event was triggered on the "text" portion inside the element.

To see this in action, save the code below and open it up in IE6 or IE7. If you click on the text, the onclick event fires and you'll see an alert. If you click anywhere else inside the DIV no event will fire. I've set the cursor to "pointer" so that you can see exactly where the event will fire, but it will turn to the default arrow anywhere that the event firing will fail. Load it up in any other browser and you can click anywhere in the DIV to fire the event.

Example:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
  <title>bug 229 - not everything is absolute in IE</title>
</head>
<body>
<div style="position:absolute;cursor:pointer;top:10px;left:10px;width:200px;border:1px solid black;height:50px;" onclick="alert('Clicked!')">Absolute</div>
</body>
</html>

What is truly odd about this bug, is that it happens in Standards Mode (you know, the one that is supposed to be "closest" to the specs).

The good news is, that this bug can be fixed. All you need to do is specify a background color, e.g. just add this to the DIV's style attribute:
"background-color:#ffffff;"

Known Workarounds: One. Set a background color.

Example Workaround Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
  <title>bug 229 - not everything is absolute in IE</title>
</head>
<body>
<div style="position:absolute;cursor:pointer;top:10px;left:10px;width:200px;border:1px solid black;height:50px;background-color:#fffedf;" onclick="alert('Clicked!')">Absolute</div>
</body>
</html>

Related Issues: None.


Bug/Site Feedback |
Submit a bug

Browser Features - Poll Results

After reviewing the results of the last poll, we opened up the Browser Features Poll asking you what Browser features you cared about most. As a site delivering content mainly to Web Developers, the results obviously cater to a developers perspective but the results are interesting none the less.


Browser Features Poll Results:

Surprise, surprise! Developers care most about the JavaScript/DOM Support. Web 2.0 depends heavily on decent JavaScript/DOM Support and what troubles developers most is the lack of consistency across Major Browsers. CSS support and Security took a close 2nd, followed by Bug Tracking and Rendering Speed.

On the low end was Bookmarks and RSS. Not too surprising since these aren't the most critical parts of a browser, and other Manager/Aggregaters tend to be better at this role anyway.

A new poll will be up shortly, so be sure to check back soon.

Thanks for voting!

Bug/Site Feedback |
Submit a bug

bug 139 - javascript dialogs don't center correctly in IE

Issue: #139
Affects: IE6, IE7, IE8, IE9 PP4
Partially Affects: Safari 3 (alert & confirm only)
Status Fixed in Safari 4 Beta

MSIE Feedback ID: 333954

JavaScript has 3 dialogs for user interaction;
Alert,
Confirm,
& Prompt.

You've already read that the prompt dialog is in serious need of an overhaul (bug 109), but even the alert() and confirm() dialogs need help too.

So, what's wrong with the alert() and confirm() dialogs? The Centering.

They center on the Desktop, not the Browser Window.

Why is this wrong? Well if you surf with a full screen window, you won't ever notice, but if you have a wide screen LCD, or 2 or more monitors your desktop is wide enough to see 2, or even 3 applications/web pages at once.

So, if you have a wide screen, the dialogs appear out of the browser window, out of context... but if you have a dual screen setup, the dialogs appear SPLIT! across 2 screens making them completely unreadable.

Known Workarounds: None.

Related Issues: (bug 109).

Bug/Site Feedback |
Submit a bug

bug 132 - slow checking checkboxes required in IE

Issue: #132
Affects: IE6, IE7, IE8, IE9 PP4
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

Checkboxes are the perfect form control to select multiple items. In fact they are so good, that the original element designed for this (<select multiple="multiple">) is hardly used because it is so user unfriendly.

They get used everywhere, especially in a long list of items (it could be emails, tasks in a TODO list, or picking your any number of options).

However there is a bug in IE, that forces you to make sure you pick options slowly. The bug is that if you press the Tab key, and the Space bar at the same time, the checkbox control gets "locked" in a strange state, renders "disabled", and stops any other interaction with the rest of the form, the page, the toolbars, the menu or even the window itself!

So, lets analyze this. First off, why would a user press Tab + Space on a checkbox in the first place? Well, if you want to check/uncheck a series of checkboxes quickly, you can Tab through them, and press the Space bar to toggle their status. Once you've mastered this trick, you'll find yourself using it all over the Web.


Example:


Then Tab to the checkboxes, press Space to toggle them, then press Tab and Space at the same time on one.
One
Two
Three
Four
Five
Six
Seven
Eight

Known Workarounds: None. There's no workaround for this issue from a programming perspective, but you can as an end user, press Escape to clear the lock.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 263 - beware of DoubleClick in IE

Issue: #263
Affects: IE6, IE7, IE8, IE9 PP1, IE9 PP2, IE9 PP3
Fixed In: IE9 Platform Preview 4 both the extra mousedown and click events now fire!

Satus Update: IE9 Platform Preview 2 shows some improvement and actually does fire the 2nd mousedown event - however it still does not fire the 2nd click event.

Attempting to track events in the process of a doubleclick event in IE will be entertaining to say the least.

The normal sequence of events fired leading up to a doubleclick go as follows.

• mousedown


• mouseup


• click


• mousedown


• mouseup


• click


• doubleclick

but in IE, if you doubleclick on a link, and image or any element, the events fired are:

• mousedown


• mouseup


• click


• mousedown


• mouseup


• click


• doubleclick

Thats right, no second mousedown?, and no second click!
As a developer, if you are tracking mousedown, mouseup, and click events... you need to be aware of this because if your users doubleclick by accident any actions that are designed to "stop" onmouseup might try and reference something that wasn't started... and if the onclick was being used to quit listening for example... that event may never fire.

Example:


Double Click Me To Test!

Event Log

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Internet Explorer 8 (IE8) - Facts and Fiction

Microsoft is well underway with development of their new Web Browser Internet Explorer 8. As development moves ahead into the Alpha/Beta 1, Beta 2 RC1 testing stages this post will attempt to condense the knowns and the unknowns to give you a better idea of what to expect in IE8.

Release Schedule:

• Beta 1: Released March 5th, 2008 (IE Blog post, Download Link, IE8 Feedback (Bug Tracker for IE8 (invite only))
  


• Beta 2: "Later this year" - Chris Wilson [MSFT], Helen [MSFT]


• Beta 2: "August 28th, 2008" - Mary Jo Foley [ZDNet], Helen [MSFT]


• Beta 3: ???


• PR1: Partner Release 1 - A semi-private release was made available on Dec. 10th, 2008



• RC1: RC1 Released Jan. 29th, 2009 (Dean on IE Blog)


• RC2?,RC3?: Q1 2009 (Dean on IE Blog)


• Final RTM: "November 2008" - Mary Jo Foley [ZDNet], Helen [MSFT]

Operating System Support:

• Microsoft Windows
  
  
  
  • Windows XP
  
  
  • Windows Vista
    The User Agent string was confirmed, it will be:
    
    
    
    • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)

Fixed / Implemented:

• Passes ACID2 CSS Stress Test ⁽¹⁾


• CSS display: table implemented ⁽¹⁾


• HTML <abbr/> implemented ^(?)


• Object Fallback ^(?)


• Data URIs ^(?)


• CSS position: fixed ⁽¹⁾


• CSS generated content ^(?)


• WBT (bug 101) - Fixed in IE8 Beta 1


• WBT (bug 152) - Fixed Properly in IE8 Beta 2


• WBT (bug 163) - Fixed in IE8 Beta 2


• WBT (bug 190) - Fixed in IE8 Beta 2


• WBT (bug 229) - Fixed in IE8 Beta 1


• WBT (bug 341) - Fixed in IE8 Beta 1


• WBT (bug 403) - Fixed in IE8 Beta 2




• The following are untested, but according to IE8 DOM whitepapers (here) are apparently fixed! ;-)
  
  
  
  • getAttribute()!, setAttribute()!, getElementById()!, <button> element submits the correct value attribute!,
  
  
  
  

Remains Unfixed (e.g. Intentionally not fixed):

• {nothing confirmed}


• WBT (bug 126) - MSFT Status: Will not fix in IE8


• WBT (bug 193) - Tested, Still Broken in IE8 Beta 1


• WBT (bug 256) - Tested, Still Broken in IE8 Beta 1, IE8 Beta 2


• WBT (bug 263) - Tested, Still Broken in IE8 Beta 1, IE8 Beta 2


• WBT (bug 280) - Tested, Still Broken in IE8 Beta 1, IE8 Beta 2


• WBT (bug 291) - Tested, Still Broken in IE8 Beta 1


• WBT (bug 293) - Tested, Still Broken in IE8 Beta 1

Possibly Fixed?:

• JavaScript and DOM Fixes? Feb 4th post by Web Standards group indicates Microsoft may address many open issues.

Caveats:
?.) Unknown
1.) In "IE8 Standards Mode"

IE8 Standards Mode:
The current trigger for IE8 Standards Mode is under heavy debate over on the IE Blog, A List Apart, WaSP, John Resig (jQuery), Dean Edwards, Robert O'Callahan (Mozilla), and Maciej Stachowiak (Safari). The proposal below *may* be revoked in favor of a more clever approach.

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

or it can be sent as an HTTP header:

X-UA-Compatible: IE=8

or if you want to live on the bleeding edge, and always render in the strictest mode possible, use this meta tag:

<meta http-equiv="X-UA-Compatible" content="IE=edge"/>

Information Sources:
MSDN: Channel 9 Video with IE Team on ACID2 Test Milestone
A List Apart: Beyond Doctype
IE Blog: ACID2 | IE8 Standards Mode | User Agent String

WinVistaClub: IE8 Beta release date

Bug/Site Feedback |
Submit a bug