598716 - Gradients on nested elements don't show

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Shiv Kumar]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6

I have a simple html form with a <input> type submit button.

The form has a gradient applied to it, like so:
form {
  background-image: -moz-linear-gradient(top, #ffffff, #f2f2f2);
}

The submit button has a gradient applied to it as well, like so:

input[type=submit] {
  background-image: -moz-linear-gradient(top, #ffffff, #cfcfcf);
}

The form gets the desired gradient, but the button does not.

Reproducible: Always

Steps to Reproduce:
use a simple <form> in an html page with a <input type="submit"> button in it.

Then use the following CSS

form {
  background-image: -moz-linear-gradient(top, #ffffff, #f2f2f2);
}

input[type=submit] {
  background-image: -moz-linear-gradient(top, #ffffff, #cfcfcf);
}
Actual Results:  
The form shows a gradient but the submit button does not.

Expected Results:  
The submit button should have its own gradient.

FYI: Works in Chrome and not Safari.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

Works fine.  Please reopen if you attach a testcase showing the problem.

Comment 3

[Shiv Kumar]

Attachment: It is a jpeg image showing working in Chrome, not working in FF

The attached image shows it is not working in Firefox but does work in Chrome.

The same test case Olli attached to Bug #598726 shows this issue for me.

Comment 4

[Boris Zbarsky [:bzbarsky]]

That page has:

        input:valid {
            background:url("images/ok.png") no-repeat 340px 5px;            
        }        

which matches the submit and has higher specificity than the rule with the gradient.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Oh, you may want to file a bug on Chrome about not doing that right...

Comment 6

[Shiv Kumar]

So you're saying a submit button has a "valid" and "invalid" state?

Comment 7

[Shiv Kumar]

Ok, I fixed it by changing that style to

input:valid:not([type=submit]) {
 background:url("images/ok.png") no-repeat 340px 5px;			
}

So now I get what I would expect. However, I'm not sure a submit should match a input:valid CSS rule.

This is more a question since I'm not fully aware of the specs.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> So you're saying a submit button has a "valid" and "invalid" state?

According to the current HTML5 spec text, yes.

Comment 9

[Mounir Lamouri (:mounir)]

(In reply to comment #8)
> > So you're saying a submit button has a "valid" and "invalid" state?
> 
> According to the current HTML5 spec text, yes.

And this is completely stupid and useless. We should change that.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Bug filed on the spec?

Comment 11

[Mounir Lamouri (:mounir)]

Emailing the list about that is in my TODO list. (let me know if you think a bug should be filed)

Actually, all submit controls can be invalid. I suspect the specifications let that so the authors can have some kind of UI when the form is invalid. But our :-moz-submit-invalid pseudo-class should be much more appropriate.

Comment 12

[Shiv Kumar]

I think a bug should be filed otherwise we'll have an incompatibility issue running around. This was my first realy attempt at building a form using all the bells and whistles and I hit apon it in no time flat. Had me foxed untill you noted the specificity thing and it made sense and didn't.

I'll let you guys to the honors :) and back you if/when needed.

I find it quite frustrating, can't imagine what it's like for you!

Good to know that FF is doing it right as per the spec though.

And you guys have been incredibly responsive to the bugs I've filed. Very impressive indeed.

Comment 13

[Shiv Kumar]

By the way, while I have your attention and you know the spec far better than I do....

If you look at the image attache to #598726 (you know, the one I referred to earlier), you'll notice that FF puts a red border around all the required fields.

The state of the form as you see it in the image is that I've just loaded the page. I haven't submitted the form yet.

So it seems that FF is validating all fields on form load? Is that the correct behavior? Or is the spec not specific about when to validate or is it in fact saying you should validate on load?

Other browsers (Chrome, Safari, Opera) don't do this.

Comment 14

[Boris Zbarsky [:bzbarsky]]

:valid and :invalid matching should be dynamic; that's the only sane way to do it.  So the validation should be happening at control creation time, then any time the value changes.

It's possible that those other browsers just don't support :valid/:invalid yet.  Or they may have bugs in their support, of course.  One would have to write a testcase with some obvious :valid/:invalid styles to tell.

Comment 15

[Shiv Kumar]

I know that do support :valid/:invalid. the styles change (visually) as expected.

The only difference is that all fields show invalid from the get go in FF. As a result the :required pseudo class (or the styles defined for it) don't show.

If you look at the image you'll see I have orange stars for "required" and a red excalmation for "invalid". you don't see it but a green check mark for valid and it all works as expected so I'd say they do support this stuff.

Honestly, I don't like how FF is doing it in th is case:
1. From a usability point of view if the user starts of see all fields in valid. That would be terrible.
2. One can never style required elements since they'll always start as invalid.

Validation should be done when a form is submitted. There is no need to validate before that.

Another question - are the events rasied when validation is done on load?

Comment 16

[Shiv Kumar]

Correction - the other browsers tell you a field is invalid when it receives focus. That is the :invalid style takes effect.

Comment 17

[Boris Zbarsky [:bzbarsky]]

> the styles change (visually) as expected.

Change in what sense?  If an element is required and empty, it should have :invalid styling applying even if the user hasn't interacted with it, per the spec.  The spec says:

  :invalid
    The :invalid pseudo-class must match all elements that are candidates for
    constraint validation but that do not satisfy their constraints.

And, for example, section 4.10.7.2.5 of HTML5 says that a mutable empty text input with @required set does not satisfy its constraints.  Therefore such an element must match :invalid.

> There is no need to validate before that.

That's not what the spec currently says (and it's not even how scripted validation on many sites behaves).  At least for purposes of :valid/:invalid matching.

Now when the form is submitted there are _additional_ things the UA is supposed to do (reporting validation issues via some sort of UI, etc).
> Another question - are the events rasied when validation is done on load?

I would assume not; the event firing is done during the "statically validate the constraints" step, which is not the same as determining whether :valid/:invalid match.  Not that the event firing (and canceling of said event) allows script to affect the results of the static validation but NOT what rules individual controls match.

Comment 18

[Boris Zbarsky [:bzbarsky]]

So I just tried this testcase:

  <!DOCTYPE html>
  <style>
    :invalid { border: 10px solid red; }
  </style>
  <input required>

On loading this, I see a red border in current Gecko, current Webkit, current Opera.  So I have no idea where the "Other browsers (Chrome, Safari, Opera) don't do this." thing in comment 13 comes from.

Comment 19

[Shiv Kumar]

>That's not what the spec currently says (and it's not even how scripted
>validation on many sites behaves).  At least for purposes of :valid/:invalid
>matching.

Ok, I didn't doubt FF was doing what the spec says and thanks for citing the various parts of the spec. I haven't see this behaviour on other sites and I wouldn't design it like this myself :). I'd show the user that the field is required and only after the fill in the field would I show them that the data they filled in is in valid.

At the time of submitting I'd highlight all invalid fields again. Not one by one as Opera does today.

I guess folks in your team believe this is the correct implementation (barring what the spec says)?

Comment 20

[Boris Zbarsky [:bzbarsky]]

I believe what we have now is correct, yes.

Perhaps your real issue is with the default UA style we have for :invalid?

Comment 21

[Shiv Kumar]

No I can remove that. My conceren is the fact that I see the invalid icon rather than the required icon.

Comment 22

[Mounir Lamouri (:mounir)]

With:
:invalid { box-shadow: none; }
:invalid:not(:required) { /* put your :invalid style */ }
:invalid:required { /* put style for invalid + required */ }
:required { /* put style for required */ }

You should have what you want.
You should know the :invalid behavior might change in Firefox until the release though.

By the way, please come by on #developers on irc.mozilla.org if you want to talk about that or send emails but bugzilla isn't the right tool for that.