Re: [css-ui] Request for :dirty pseudoclass

On Thu, Sep 24, 2009 at 9:13 AM, jackalmage <jackalmage@gmail.com> wrote:
> On Thu, Sep 24, 2009 at 12:25 AM, Garrett Smith <dhtmlkitchen@gmail.com> wrote:
>> On Wed, Sep 23, 2009 at 8:42 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> I recently opened a bugzilla ticket on the HTML5 tracker[1] asking for
>>> :invalid and related pseudoclasses to not match until the input was in
>>> some sense "dirty", that is, until the user had directly interacted
>>> with the control.  Hixie closed the ticket with WONTFIX and provided a
>>> good reason for doing so - there are many reasons why you *would* want
>>> immediate validation - as well as providing a suggestion for manually
>>> implementing 'dirty' detection in a way that would interact with CSS
>>> appropriately.
>>>
>>
>> What does the :dirty pseuodoclass apply to? FORM, FIELDSET, or just
>> form controls?
>>
>> form:dirty    *:invalid {
>>  border: 1px solid red;
>> }
>>
>> fieldset:dirty   *:invalid {
>>  font-weight: 800;
>> }
>
> I'd say that it's up to the host language to define what elements can
> be dirtied. All HTML form controls are obviously on the list, but
> having forms and fieldsets be dirtyable would very likely be useful as
> well, as you've illustrated in your examples.
>

You mentioned the "change" event earlier.

A change event does not fire when:
 text is dropped on a text input
 A form control's property is changed by script

If the user changes value of a control and changes it back again, is
the control dirty?

[example]

>>  }
>>  return (FormManager.isFormDirty = formDirty(form));

Uh, that looks wrong. Maybe:

return (FormManager.isFormDirty = formDirty)(form);

seems right.

>> This is more of a DOM related issue than CSS, but somewhat related to
>> the "dirty" idea.
>

Native FORM dirty notification can be used to inform the user of the
state of the form.

Sorry, I think I am leading this topic astray from your proposal. What
I am bringing up is how I interpreted the term "dirty", and my
interpretation seems to be not in line with your proposal. I might as
well mention it anyway:

<form-dirty-notification-aside>
Example:
User can update data and save it in-page without a refresh.

When the form data is changed, if the form is dirty, enable the
button, otherwise, disable the button.

When the data is submitted, disable the submit button.

If the submission fails (including timeout), enable the button and
present a message to the user: "updating data failed, please try
again."

If the form becomes "clean" again, then the user's notification of
"dirty" state must be changed.

State change notification could be as a state property, but would be
even nicer with an event.

form.ondirty = formDirtyCallback;
</form-dirty-notification-aside>

>
>>> This seems silly to have to do manually, though, as most of the time
>>> you *will* want to delay error messages until the user has interacted
>>> with the input.  As well, it depends on js, which means that users
>>> without js won't see the validation styling at all (without some
>>> annoying hacks around the issue).
>>>
>>
>> Programmers care about data format. Obviously designers might have a
>> different opinion on what the user gets presented with.
>
> I'm not sure what you mean here.
>

Was trying to understand the difference of use case and the reaction
of WONTFIX.

User interaction designer would care about when the error is
displayed. The programmer would care that the data is correctly
entered. Errors being presented early seem like a benefit to the
second type of thinking.

Not taking sides, just trying to see the perspective you mentioned:

| This is generally unacceptable from a design standpoint
| - we only want to tell a user they've made a mistake *after
| they've actually made a mistake*.


- compared to Ian's comment: -

| Surely if the user loads a form, sees there's nothing
| wrong, and hits submit, that's worse than if the user
| loads a form and sees a lot of red before typing anything?

Each perspective addresses a similar, yet different objective. An
actual example of a real form with error messages and some feedback
from an interaction designer would be helpful.

The subject of Native FORM dirty notification (the "aside") would
probably be best reserved for another thread.

[...]

>>
>> It seems necessary to define "significantly interacted with".
>
> I did offer a suggestion - as soon as a form element fires a change
> event, it's dirty.  That only works for HTML, of course, but that's
> obviously the main target we're aiming at.  In general, though, it's
> up to the language that CSS is interacting with.
>
> On Thu, Sep 24, 2009 at 8:42 AM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
>> On Wed, Sep 23, 2009 at 11:42 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> I propose a :dirty pseudoclass be added to CSS UI.
>>
>> I think ":changed" would be a better name.  An ":unchanged" selector
>> might also be useful.
>
> That is likely a better name, yes.

I think so, too. I think "dirty" means something different.

Garrett

Received on Friday, 9 October 2009 07:13:40 UTC