- From: Stefan Wallin <Stefan.W@festiz.com>
- Date: Mon, 12 Mar 2012 20:53:07 +0100
- To: Schalk Neethling <sneethling@mozilla.com>
- Cc: Mounir Lamouri <mounir@lamouri.fr>, www-style@w3.org
- Message-ID: <CA+9vH7CHrg4y3KLnfL149AvdQm-RivDFzByjgo7FXHnR-UYS1w@mail.gmail.com>
Schalk, I totally understand how it's currently supposed to work(yes my previous statement about that the spec was not definite was wrong), I simply do not think it's intuitive that :empty does not check for text in elements which cannot contain children(inputs) Regarding that CSS is not event based I beg to disagree, I will not go through all possible events that are already supported, but :hover and :focus both respond to mouse events. Why should keyboard events be any different? Stefan Wallin ================================ +46 (0) 709-529 036 || stefan.w@festiz.com http://www.stefan-wallin.se http://twitter.com/Stefan_Wallin On Mon, Mar 12, 2012 at 6:37 PM, Schalk Neethling <sneethling@mozilla.com>wrote: > Stefan, > > Remember, whether the input field has text inside it or not, checking for > childNodes on the input element will always give you an empty array as the > text is not a child of the element, hence you will find that your first and > second input elements will have a dashed border and not one solid and one > dashed, as you might be expecting. > > NOTE: This is true if you only specified border color for .toc > input[value=""] and border style as well. For example change your CSS to > this: > > .toc input[value=""] { > border-color: red; > } > > Also, even after adding text to the second input element the border will > remain red as CSS is not even based and will not be triggered based on a > change to the input element. It is simply going to style all empty input > elements a certain way when the document is rendered and that will remain > that way unless you > 1) change the style rules at run time > 2) remove the rule and apply a new one > > So, unless there is concrete support in CSS for reacting to changes in DOM > elements such as change events on input fields, you are going to have to > combine this with a little DOM manipulation. > > Kind Regards, > Schalk > > ----- Original Message ----- > From: "Stefan Wallin" <Stefan.W@festiz.com> > To: "Schalk Neethling" <sneethling@mozilla.com> > Cc: "Mounir Lamouri" <mounir@lamouri.fr>, www-style@w3.org > Sent: Monday, March 12, 2012 5:18:45 PM > Subject: Re: [selectors4] :empty psuedo class and input fields > > Thanks, Schalk. > > > You are true in that assumption. There is a use case where one would want > to visibly show which elements are not filled in differently from those > that are required. The naming of the :empty psuedo selector has a very good > semantic meaning for this and it makes sense for it to be used like this. I > can envision a lot of uneducated developers to make bad assumptions based > on how the spec is written. I'm pretty new at wearing specification reading > glasses, but imho the spec does at this spot say neither against or for > this functionality. > > > If you need it specified in code I've written a small test here. > http://lab.festiz.com/psuedo-empty/ > > > > > > Stefan Wallin > ================================ > +46 (0) 709-529 036 || stefan.w@festiz.com > http://www.stefan-wallin.se > http://twitter.com/Stefan_Wallin > > > > On Mon, Mar 12, 2012 at 3:43 PM, Schalk Neethling < sneethling@mozilla.com> wrote: > > > Mounir, > > I believe what Stefan wants is to style fields that are empty, but not > necessarily required, different so input:required:invalid is not going to > work in this situation. > > Regards, > Schalk > > > > ----- Original Message ----- > From: "Mounir Lamouri" < mounir@lamouri.fr > > To: www-style@w3.org > Sent: Monday, March 12, 2012 4:37:19 PM > Subject: Re: [selectors4] :empty psuedo class and input fields > > On 03/12/2012 11:03 AM, Stefan Wallin wrote: > > This strikes a chord with me, I'd really like to see the possibility to > > style input fields that do not fit to be classed as required but are > > still empty to be styled differently. Today this has to be done with DOM > > scripting, neither input[value=""] or input:empty works as I think it > > should work. > > This use case can already be solved like this: > input:required:invalid { > } > > Assuming you are using the required attribute as specified in HTML. > > Regarding the general proposal. That might be useful assuming there are > use cases different from the one above. > > -- > Mounir > > > >
Received on Monday, 12 March 2012 19:53:59 UTC