feature 266 - window.prompt() in Safari is multiline capable!

Issue: #266
Affects: Safari 3.1

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.


Try it!:



Related Issues: (bug 109), (bug 139).

Bug/Site Feedback |
Submit a bug

Bug or Feature? - Round Three

Round Three - If more than one ID, which one matches?

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:
The HTML id attribute is designed to uniquely identify a particular element.

However, what if you accidentally end up with 2 or more elements with the same ID?
Obviously this is a bug, but how different browsers handle it, is what makes it interesting.

All browsers tend to return the first matching element in the DOM order with the same id when using .getElementById(id). However if you have an HTML Label element, with a for attribute that points to the id attribute of a field, things aren't quite so clear.

Firefox, Safari & Opera all link to the first form element with the matching id.
Internet Explorer links to the last form element with the matching id.

Question is, is IE's different behavior a bug? or a feature?

Example HTML snippet:

<label for="obj1_prop1">Size:</label>
<input id="obj1_prop1" type="text" size="5">
<label for="obj1_prop1">Quantity:</label>
<input id="obj1_prop1" type="text" size="5">

Question:
Does linking to the last element vs. the first element expose a feature? or is it a bug?

Test it for yourself, click on the labels Size and Quantity:
Size:

Quantity:


Is this a Bug? Or a Feature?

Vote "Bug" or "Feature", and add your thoughts.

Bug or Feature? - Round Two

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)

Is this a Bug? Or a Feature?

Vote "Bug" or "Feature", and add your thoughts.

Bug or Feature? - Round One

Round One - Live .innerHTML in IE

We're adding a new post type here, called "Bug or Feature?". It highlights 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.

Ok, so what is the "Bug or Feature" for today? - Glad you asked.

Synopsis:
In IE, if you ask for the .innerHTML of an element, you will get a 'DOM' fragment representing the inner HTML content (and every other browser will do the same). However there is a catch.

If I have the following HTML, I would expect it to return the same content:

Example HTML snippet:

<div>
<input type="text" name="yourname" value="first last" size="25"/>
</div>

Expected [div].innerHTML returned:

<INPUT size=25 value="first last" name=yourname>

Not quite what was entered, but in IE you'll get your tags in UPPERCASE, attributes with no spaces returned with no quotes, no "type" attribute if its a text field and no self closing tag "/" (slash).

Question:

If the user typed "Joe Bloggs" into the field after the page loaded, and you asked for the .innerHTML, (unlike other browsers) IE returns:

<INPUT size=25 value="Joe Bloggs" name=yourname>

Try it yourself.

Is this a Bug? Or a Feature?

Vote "Bug" or "Feature", and add your thoughts.