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 231 - noscript elements render when script enabled in IE8 Standards Mode

Issue: #231
Affects: IE8 (Standards Mode), IE9 PP1, IE9 PP2, IE9 PP3, IE9 PP4, IE9 PP6

The <noscript> tag serves 1 basic purpose and that is to provide content when scripting is turned off in the browser.

Years ago the main purpose was to provide alternative content so that your page still worked in browsers without script however these days due to better popup blocking and more interactive content scripting is typically turned on.

Thus the main use of the noscript tag today is to inform the user that JavaScript is turned off and that things won't work until it is turned back on.

[Fake] You need to turn on JavaScript to use the uber cool features on this page. [Fake]

However warnings like this would seem quite out of place when JavaScript is turned on so they are not rendered. Well except that IE8 (Standards Mode) does render the noscript tag container when JavaScript is turned on. This is a regression bug from IE6/7.

Example:

If you are viewing this page in IE8 Standards mode (you'll need to use the IE developer tools [F12] since blogger forces IE7 rendering mode) you will see the outline of noscript tags even when JavaScript is enabled.

Known Workarounds: One. Setting the noscript tag to be display:inline; vs display:block seems to make the container disappear.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 179 - .innerHTML love outside the body is hit and miss

Issue: #179
Affects: IE6, IE7, IE8, Safari 4, Chrome 2

As most developers know, setting the .innerHTML of an element is one of the fastest ways to dynamically set the content of an element. However there are a few issues when setting the .innerHTML on some elements in some browsers.

For example trying to set the .innerHTML on a [Table, THead, TFoot, TBody, TR] in IE it will fail as will trying to set it on a Select, Pre, or even a (Div with overflow:auto).

Thinking outside the <body> tag, there's a few more tags that you might want to set the .innerHTML on.

The <html>, <head>, <title> tags. Now we can argue that the title tag doesn't accept HTML, but well, we'll let the results speak for themselves.

<html>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Works
Chrome: Works
Opera: Works

<head>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works (Partially) resets the title but doesn't update styles or scripts

<title>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works

Known Workarounds: Use DOM methods to update the content of various tags, and document.title to reset the title value. Just keep in mind that there are other bugs with setting the contents of the script tag, and style tag in IE.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 409 - MooTools redundant getElementById(id) method

Issue: #409
Affects: MooTools

If you are developing any web sites or web applications these days you are undoubtedly using a JavaScript Framework or have plans to implement one soon.


This bug is about the MooTools framework, specifically about the Element.getElementById() method.

The docs indicate:
Synopsis: Gets the element with the specified id found inside the current Element.
Example: var myChild = $('myParent').getElementById('myChild');
Notes: This method is not provided for Document instances as document.getElementById is provided natively.


Did you spot it? No? Lets run through it bit by bit.

For starters MooTools uses a very simple $('someID') syntax to get an element by its ID.

Combine that with the fact that the ID attribute of HTML elements must be unique within the document according to the W3C specs... and you've now proven that the .getElementById() method on any other element in the DOM is redundant.

E.g. the above example can also be written as (and in much less code I might add):
Example: var myChild = $('myChild');

Now maybe I'm missing something here that is hidden in the docs that helps explain why verbose, redundant code is somehow helpful or that it provides additional features? If so, please comment and let me know!

Known Workarounds: One. Simply don't use it! Its too bad that the API is cluttered with this extra method but it won't cause any harm to use it.

Example Workaround Code:

  var myChild = $('myChild');

When you consider that your JavaScript Framework is providing an API on top of the existing JavaScript/ECMAScript API... you want your Framework API to be as simple and lightweight as possible. Its a minor bug but one that should be addressed to maintain a clean and tight API.

Related Issues: None.

Bug/Site Feedback |
Submit a bug