The window.prompt() function when it first became available would allow a user to add 1 (one) line of text as an input value using a modal dialog supplied by the browser.
It turns out though, that Safari now allows users to enter more than one line of text (Enter is treated as a request for a carriage return, not to accept the value and submit the dialog).
I don't consider this a bug, but rather an enhancement to the existing dialog. (In Safari's case, it could do with a scrollbar, since it does allow more than the 3 lines it visually displays)
However this is something that developers will want to be aware of... that line breaks should be expected in the return value from the prompt call.
As more and more applications go online in this Web 2.0 world, interactions with forms are critical to an applications success. Safari leads the way with built-in textarea resizing but it has a major issue with form field focus.
Since data entry in forms is a crucial part of online forms, ensuring that your forms are both keyboard and mouse navigable is important. Unfortunately in Safari the keyboard navigation breaks if you use the mouse on radio or checkbox elements. This becomes a major issue because although radio and checkbox elements are keyboard accessible, in general users prefer to use the mouse to make their selection(s).
The issue is this. If you use the mouse to select a radio or checkbox field one expects that that field has the focus and thus a 'Tab' will take you to the next available field (or whatever is defined in the tabindex order). When the user presses 'Tab' in Safari, the focus resets to the first form field on the page!
If you use the mouse for other types of fields, or use only the keyboard the issue doesn't occur.
Round Two - Safari changes your styles did you know?
We're back again with another round of "Bug or Feature?" (see round one) highlighting a particular behavior in one or more browsers, that, well, could be a Bug, or it could be a Feature... we'll open up the comments for your vote and opinion.
Alright, what's todays "Bug or Feature"?
Synopsis: In Safari, usability of textarea elements has been greatly improved by allowing the user to decide how wide and how tall it should be, by making a grippy that the user can drag to stretch. Its a great feature, that many other browsers are looking into (Ask ASA, it's on his top 10 for Mozilla Firefox).
What is interesting, is that as a developer, if you ask for the .innerHTML of an element that wraps a textarea in JavaScript, it will report back exactly what you supplied... *except* if the user changed the dimensions of the textarea, the style attribute is now filled with margins, paddings, width and height values that you didn't specify.
If I have the following HTML, I would expect it to return the same content:
Example HTML snippet:
<div> <textarea name="a_textarea" cols="40" rows="4"> Hello World </textarea> </div>
Expected [div].innerHTML returned:
<textarea name="a_textarea" cols="40" rows="4"> Hello World </textarea>
Question:
If the user stretches the textarea in Safari (or later in other browsers), and you asked for the .innerHTML and got something different than the HTML fragment above...
Try it yourself.
(ignore the br tag in the alert (blogger auto-inserts this)
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.
According to the JavaScript documentation, the onload event can be handled for the body, iframe, img, frameset & object tags. However not all browsers obey this the same.
Supports iframe onload: Firefox - Yes IE6, IE7 - Yes Opera - Yes Safari - No
Supports object onload: Firefox - No IE6, IE7 - No Opera - No Safari - Yes
So, take this into consideration if you are planning to use object versus an iframe in your next project.
CSS was meant to be the solution to applying global styling, without interfering with the content of a page. For the most part, it works really well, although IE has been very slow to catch up to the other major browsers in this arena.
Case in point. The option element is used inside a select element to provide options for the user to select from. In IE, you can style it any way you want, as long as all you want to style is the font and the color... because all other styling options just won't work!
View the following samples in Firefox, Safari or Opera and they will work like a charm*. In IE the colors work, but after that, it just ignore the styling requests.
Example:
Note: In Safari (on the Mac), the background colors do work, but the background images do not.
For those familiar with the MacOS platform, Safari is likely your native tongue.
However Safari on Windows, is relatively new, and brings another great browser to the Windows world with all its shiny aqua goodness.
As a new browser on the Windows platform, it has some excellent features, and a few bugs that I'll point out below.
Features: 1.) It is Fast, blazing Fast! 2.) It has a built in JavaScript Console 3.) Built on the WebKit codebase (same as Konqueror), it is one of the most standards compliant browsers out there! 4.) Fancy shmancy form field highlighting 5.) Built in resizable textareas 6.) Built in bug submission. Right into the browser! Simply give some brief details (the url of the page you are on is sent automatically) and submit! All browsers could use this feature!
Bugs: 1.) It doesn't respond to the windows command [WinKey]+ M or [WinKey] + D to minimize all windows and display the desktop. 2.) You can only resize the window, by the bottom right corner, or double-clicking th e title bar.
If you haven't tried this browser out yet, I'd highly recommend it!
Modern Browsers: I expect this to be a moving target, but as of mid-2007 I would only qualify the following as "Modern Browsers". You should expect to see little support, and very few features for browsers not listed here. If your Web Browser is not listed here, it IS time to upgrade.
*IE8 was just announced, in theory it should be a better version than IE7, however there has been no information about it so far, so it is too early to tell)
*Firefox 3.0 is now in its third public beta release (beta 345RC1RC2RC3) and is very near a full release (Will be available Tuesday June 17th, 2008). You can download the betaRC (Release Candidate) in your choice of 30+ languages for Windows, Mac or Linux here. Note: This is still a beta release, and as such a few bugs along the way should be expected.
*Firefox 1.5 is a modern web browser for sure, but with the fast pace of Firefox development, full support for this version has already moved on. If you are using Firefox 1.5 we strongly suggest you upgrade to Firefox 2.x or, if 3.x when it is available.
Drag/Right-Click and save to your Bookmarks
View generated source of a page in IE View Source
Show Rendering Mode for IE6/7 Render Mode
Show Rendering Mode for IE8 IE8 Render Mode
About Me
xyz
Web Developer - Dealing with the quirks and pains of Browser Bugs.
