Bug or Feature - Round Six

Round Six Enabling the non-Disabled.

Other rounds: [One|Two|Three|Four|Five|Six]

We're back again with another round of "Bug or Feature?" 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 today's "Bug or Feature"?

Synopsis:
Everyone knows that form elements [button|input|select|textarea] can be disabled to stop users interacting with them and to ensure they are not "successful controls" when a form is submitted.

So... what happens if you disable non form elements?

In most browsers... Just like you'd expect... absolutely nothing because it isn't supported.

However in IE there is a different behavior.

In IE when you set the disabled flag on an element it "kinda-sorta" disables all the child elements.

Example:

<div disabled="disabled">
  Email:
  <input type="text" name="foo" value="bar"/><br/>
  Send me spam:
  <input type="checkbox" name="baz" value="yes" checked="checked"/><br/>
</div>

So is it expected that the child elements render disabled? What if you wanted one or more of the children enabled?

Known Workarounds: None.

Related Issues: None.



Bug/Site Feedback |
Submit a bug

Bug or Feature? - Round Five

Round Five Getting funky with the Cheez whiz!

Other rounds: [One|Two|Three|Four|Five]

We're back again with another round of "Bug or Feature?" 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 today's "Bug or Feature"?

Synopsis:
Everyone knows the basic form elements [button|fieldset|input|textarea|select]. Within the [input] element there are several types: [button|checkbox|file|hidden|image|password|radio|reset|submit|text].

However there is a quirk/loophole/bug/feature with the <input> element that some browsers are taking advantage of.

By default, if you don't specify the type attribute, or specify a value that isn't recognized as one of the above types the browser should default to "text" (and every browser does) - however some browsers take advantage of certain key types and then render the field in their own special ways.

For example if you use: <input type="search" value="Keywords..."/> in Safari and Chrome it will render like this:



As you can see a little 'x' is provided automatically to allow users to clear the value with a mouse click.

If you don't specify a value Safari will provide a faded tip in the box indicating what the field is for:



Ok, what about other types? and other browsers?

For example if you use: <input type="email"/> in Opera it will render like this:



The little email icon helps identify the field as being a field expecting an email address as the input value and it also increases the default size of ~20 characters to ~25characters (depending on your font selection)

If you use: <input type="url"/> in Opera it will render like this:



Again Opera adds a little icon and increases the field size to ~28 characters.

Know of any other values for type that one or more browsers treat in a special way? If so, let us know!


So now the Question is...

Is this a Bug? Or a Feature?

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

---

Update: 100 bonus points for Rafael! As noted in the comments below the "url" and "email" types that Opera rendered uniquely just happen to be 2 of the types specified in Web Forms 2.0 and they happened to be 2 of the less decorated fields. The full set of new field types is supported in Opera and they look and work great! We'll post some screen shots of these fields shortly.



Opera's Web Forms 2.0

Date:



DateTime (local):



DateTime:



Time:



Month:



Week:



Number:



Range: (numbers added for visual aid only)







Bug/Site Feedback |
Submit a bug

Bug or Feature? - Round Four

Round Four - Please Don't Stop The Music?

Other rounds: [One|Two|Three|Four|Five]

We're back again with another round of "Bug or Feature?" 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 today's "Bug or Feature"?

Synopsis:
The (now deprecated) embed element (use object instead) allows you to embed content in your page like audio and video. Adding audio on demand in your site can be an ideal way to add some multimedia interaction without having to resort to a full blown flash or silverlight plugin.

We can dynamically insert the embed element, and even start it by setting the autostart attribute to true.

If we remove the element, the audio stops, since it is no longer in the DOM... well it stops in Firefox, Safari, Opera, etc. but in IE it keeps on playing and there is no way to stop it. Since there is also a loop attribute that we can set to true, this opens up a very interesting behavior.

So the Question is...

Is this a Bug? Or a Feature?

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

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

Issue: #266
Affects: Safari 3.1/Win, 4.0 Beta/Win (readers report that this feature isn't available on the Mac)

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?

Other rounds: [One|Two|Three|Four|Five]

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?

Other rounds: [One|Two|Three|Four|Five]

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

Other rounds: [One|Two|Three|Four|Five]

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.