Site Navigation

Home | Welcome | FAQ | Submit a bug | Site Feedback |

Saturday, February 23, 2008

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
Posted by xyz at 8:47 PM
Labels: , , , , , , , ,

Sunday, February 17, 2008

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
Posted by xyz at 7:38 AM
Labels: , , , , , ,

Tuesday, February 12, 2008

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
Posted by xyz at 5:15 PM
Labels: , , ,

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
Posted by xyz at 4:51 PM
Labels: , , , , , , ,

Friday, February 1, 2008

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
Posted by xyz at 6:13 PM
Labels: , , , , , , ,
Subscribe to: Posts (Atom)