Opened 11 years ago

Closed 5 years ago

#7332 closed enhancement (wontfix)

ValidationTextBox: change icon placement

Reported by: bill Owned by: nonken
Priority: high Milestone: future
Component: Dijit - LnF Version: 1.1.1
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

As per numerous chats with nonken :-) and the dojo meeting that just ended... want to redesign how validation icon shows up for ValidationTextBox.

Currently it looks like: current behavior

Want to change it so the icon is outside of the box, like: new look

These are the detailed goals:

  • Icon shouldn't be inside <input> box since it's confusing that you can't type into that area
  • style="width: 100px" needs to control the width of the input box, not including the icon, so that it's easy to make TextBox and ValidationTextBox appear aligned
  • page shouldn't jump (reflow) when an icon appears
  • way to control where the validation icon appears, so we can have fields like
     Amount:  <input>USD *icon* 
    

Probably

<input dojoType=... iconPath="#myIconNode">USD <span id="myIconNode></span>

If iconPath not specified then it appears immediately after the <input>.

  • optional green check mark icon to indicate valid input

Some other possibilities:

  • red squiggly underline to show invalid input (in a a11y way).
  • showIcon parameter. Default value is true. Developers switch it to false at their own risk (doing so will break a11y, unless we have the squiggly underline). In the old days some people disliked having the icon to the right of the <input> because it created a blank space (reserved for displaying the icon when there was an error).

BTW, the reason we have an icon at all is for color-blind people that can't see the yellow background for invalid fields.

Attachments (2)

new.png (4.2 KB) - added by bill 11 years ago.
new look
current.png (4.0 KB) - added by bill 11 years ago.
current behavior

Download all attachments as: .zip

Change History (17)

Changed 11 years ago by bill

Attachment: new.png added

new look

Changed 11 years ago by bill

Attachment: current.png added

current behavior

comment:1 Changed 11 years ago by bill

Description: modified (diff)

comment:2 Changed 11 years ago by bill

Nathan suggested "validationNode" instead of "iconPath", and to have it specify an id (validationNode="abc"), as it matches other interfaces like <label for="..."> or Tooltip.connectId

comment:3 Changed 11 years ago by nonken

Status: newassigned

comment:4 Changed 11 years ago by David Schwartz

It could be argued that the icon should actually be along the leading edge (on the left for left-to-right text). Generally, forms are constructed along an invisble grid where elements are aligned along the leading edge. Having the icon on the leading edge allows the user to quickly and reliably scan for offending fields (for non-dynamic, server-side validation, i.e., when validating on 'Submit').

There shouldn't be a need to reserve the space for the icon, right? The field can just flow to toward the trailing edge when the icon is displayed.

comment:5 Changed 11 years ago by bill

The problem with not-reserving space for the icon is that:

  • the contents of the screen can jump if a field becomes invalid (other fields may be forced down a row, etc)
  • if the fields are in a table then one field getting wider will widen the entire column
  • etc.

Surely there are advantages/disadvantages to each approach, but that was the thinking in the meeting.

Note though that the reason we originally put the icon inside of the input box was because developers complained about having a blank area to the right of the widget. So I guess whichever design we pick some one will be unhappy.

comment:6 Changed 11 years ago by bill

Milestone: 1.31.4

comment:7 Changed 11 years ago by Becky Gibson

reference to #7577 - please make sure that the text alternative in high contrast mode is visible and of reasonable size.

comment:8 Changed 10 years ago by bill

Milestone: 1.41.5

comment:9 Changed 10 years ago by bill

Milestone: 1.5future
Type: defectenhancement

Not sure if we'll ever do this, but one of the problems has already been resolved in 1.5, namely that the icon no longer takes up space until it appears (due to a user error).

The work in #10974 should also make it easier to customize the icon position so that the default position becomes less important.

comment:10 Changed 10 years ago by jtoth55

It'd be great if this change could be made, it's super annoying clicking on the right side of a textbox and expecting it to get focus but it doesn't because of the space reserved for the warning icon. When is 1.5 coming out and is there some sort of beta download available so I could give it a try?

comment:11 Changed 10 years ago by bill

Well in 1.5 that "clicking on the right side of a textbox and expecting it to get focus but it doesn't" should be fixed for a number of reasons:

  1. the validation icon is now display:none rather than visibility:hidden
  2. clicking anywhere on a widget calls focus() on that widget

Are you still seeing the issue in the latest code?

comment:12 Changed 10 years ago by jtoth55

If 1.4 is the latest code, then yeah I do still see it. I tried to find 1.5 but couldn't find it anywhere. I ended up adding the following css to fix it:

.dijitValidationIcon { display: none; }

It means that the warning icon never shows, even when there's an error, but that's a lesser evil than taking up part of the textbox, especially since the textbox background color changes and there's a tooltip to make it clear that there's an error.

comment:13 Changed 10 years ago by bill

1.5 isn't released yet (beta is soon) but you can test on http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_validate.html.

The change I'm talking about was made after the 1.4 release.

comment:14 Changed 10 years ago by jtoth55

Thanks, that's a lot nicer how it's handled now. I guess I had an older version of 1.4.

comment:15 Changed 5 years ago by bill

Resolution: wontfix
Status: assignedclosed

Not much point in doing this for 1.x, and I guess there's not much point in keeping the ticket open for 2.0, because 2.0 could be a completely different ball of wax. For example, it could be up to the application to indicate which inputs are invalid.

Note: See TracTickets for help on using tickets.