- From: jackalmage <jackalmage@gmail.com>
- Date: Thu, 24 Sep 2009 11:13:32 -0500
- To: Garrett Smith <dhtmlkitchen@gmail.com>
- Cc: www-style list <www-style@w3.org>
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. > An associated "dirty" state property would be useful for form change events. > > if(FormManager.isFormDirty(form)) { > // re-enable button. > } > > var FormManager = {}; > > FormManager.isFormDirty = function(form) { > var formDirty; > // Native code performance boost! > if(typeof form.dirty == "boolean") { > formDirty = function(form) { > return form.dirty; > } > } else { > // hand-rolled fallback. > formDirty = function(form){ > var dirty = false; > // manual check. > return dirty; > } > } > return (FormManager.isFormDirty = formDirty(form)); > } > > This is more of a DOM related issue than CSS, but somewhat related to > the "dirty" idea. Could definitely be useful, but yeah, that's something for WHATWG to decide. I'd definitely say that elem.dirty and :dirty should match, if the two exist. >> 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. >> I propose a :dirty pseudoclass be added to CSS UI. It would match any >> input that the user has significantly interacted with, in the opinion >> of the UA. In standard browsers it would match as soon as the user >> triggered a change event, but the exact details of when it matches are >> up to the UA. >> > > 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. ~TJ
Received on Thursday, 24 September 2009 16:14:28 UTC