Forms and Flash Messages about ui_alchemy-rails HOT 15 CLOSED

Do we want to distinguish between "disabled" and "readonly" attribute?

from ui_alchemy-rails.

I would argue yes as they imply two different mindsets to the user. Disabled to me implies there is something, somehow that I could do to enable modification this element in my current view of the page. Readonly (at least the way Katello currently implies read-only via no form element but rather just the text) implies that I cannot change that particular element no matter what I do.

from ui_alchemy-rails.

+1 @ehelms

from ui_alchemy-rails.

Question mark which is next to label is currently implemented by ":before" pseudo-class.
Advantages:

• no special HTML markup needed -> clearer structure

Disadvantages:

• can't do "hover" only on question mark (needs to be at whole label)
• IE10 takes input hover as label hover -> help for label displays on input hover (unwanted)

Possible solution - create special markup for question mark:
%i.question_mark
%label
...

Do we want to solve this issue by adding new element? SImple form would take care of it (no extra coding for developer).
Advantages:

• hover only on question mark
• fixed issue for IE10

Disadvantages:

• Additional element in HTML structure

from ui_alchemy-rails.

My vote would be for the special markup version you mention. I suppose because the question mark looks like an icon and would then be treated in the HTML and css just like any other icon we were providing for use within the project.

from ui_alchemy-rails.

@CoufalJ do you mind doing a mockup in codepen? i'm having a hard time visualizing this

from ui_alchemy-rails.

Looks awesome! I have one update request related to the highlight. Try the following to reproduce what I found:

• hover over and click to put your cursor in a field with the mouse. This of course causes the highlight to show.Type something in that field
• tab to the next field to keep filling out the form, and so on
• notice that the original field maintains the focus highlight because the mouse was left there. This seems a bit odd.

It may be a strage effect due to testing on Mac OSX, which uses blue highlight on focused field. Anyone else see this on Fedora, etc?

from ui_alchemy-rails.

Well yes, this is reproducable everywhere, regardless OS type. There are 2 options if we want to keep highlighting on hover:

• don't highlight on hover if any field is focused (it would seem odd, when sometimes field highlights and sometimes not)
• highlight on each hover no matter any focused field

Do you see any other possibility here?

from ui_alchemy-rails.

I don't know that the highlight on hover is entirely necessary. While this
is a nice feature, this does sort of break from the typical mold for forms
and highlight activation. If we keep highlighting I would vote for the
first option you presented.

For the read-only field, I have been a big fan of not even showing a "form
input" when an item is read-only but rather just showing the text. This
might break the form mold and flow but my two cents anyhow.

-Eric

On Tue, Sep 18, 2012 at 11:10 AM, Jaromír Coufal
[email protected]:

Well yes, this is reproducable everywhere, regardless OS type. There are 2
options if we want to keep highlighting on hover:

• don't highlight on hover if any field is focused (it would seem odd,
  when sometimes field highlights and sometimes not)
• highlight on each hover no matter any focused field

Do you see any other possibility here?

—
Reply to this email directly or view it on GitHubhttps://github.com/Katello/converge-ui/issues/39#issuecomment-8658107.

Go Pack and War Eagle,
Eric D. Helms

Ph.D. Student - North Carolina State University

from ui_alchemy-rails.

ACK for highlighting, I fixed that for more decent hover effect and soon will push to my openshift so you can check that.

As for read-only... I partly agree with you. Depends on use. If there are forms, where are fields which you can sometimes change and sometimes it's pre-filled without possibility to change that, I would vote for current read-only look in order to keep the views consistent. For the rest of cases there is "informative text". I wouldn't use a read-only field for information which you never ever can change and works just as additional information for user (also from semantic point of view). So if we have some item, which can't be changed and we want to show user what it's value is, I would use "informative text".

from ui_alchemy-rails.

Fixed hover highlighting: You can see preview here: http://convergeui-jcoufal.rhcloud.com/form

from ui_alchemy-rails.

@jcoufal One other small issue that I wanted to bring up was the color of the text in the error tip. I think it would be best for readability if we used the same gray/black text as the regular field tip. It is clear enough with the colored stoke/highlight and the icon that the colored text hurts more than it helps.

from ui_alchemy-rails.

+1 @kybaker

from ui_alchemy-rails.

ACK, corrected: https://github.com/jcoufal/converge-ui/commit/a3be6bb2e63ed14287d19cc112f4b7ace95a2900
(also reflected in my openshift example)

from ui_alchemy-rails.

Closing due to acceptance of https://github.com/Katello/converge-ui/pull/73
Any bugs or enhancements should be opened as new issues or pull requests.

from ui_alchemy-rails.