62838 - quirk.css does not override forms.css

Status: NEW

(Core :: Layout: Form Controls, defect, P3)

Description

[[e-mail]]

quirk.css has several styles to set the border of input[type=image]

Unfortunately they only work if you manually add !important,
because forms.css styles input[type=image] with no border,
and for some reason this is overriding quirk.css which I assume it shouldn't.

While you're looking at this, I suggest you show the focus for image inputs with
no border using -moz-outline, i.e.

input[type=image][border=0]:focus {
  -moz-outline: 1px dotted WindowText;
}

Note that if you decide to add this to forms.css (because inputs without quirks
have no border by default) you would have to override this in quirk.css for
images with a border, i.e.

input[type=image]:focus {
  border-style: dotted;
  -moz-outline: 0px;
}

Comment 1

[[e-mail]]

Attachment: testcase

Comment 2

[Marc Attinasi]

The problem is that forms.css is loaded AFTER quirk.css, so from the CSS cascade
perspective, it is correct that the ruls in forms.css will override rules in
quirk.css. However, since the rules in forms.css were once in html.css, which is
loaded before quirk.css, this represents a regression. Namely, that rules in
quirk.css which used to override rules that are now in forms.css no longer
override them.

Since Hyatt moved the rules from html.css to forms.css I'm assigning this bug to
him. I only see two ways to fix it really: 1) make the rules in quirk.css more
specific, either with !important or by adding to the selector specificity, or 2)
@import the forms.css file from ua.css before the @import of quirks.css - which
won't allow the logic that is currently used to distinguish between
xbl-forms.css and forms.css.

There is no real problem, as far as I am concerned, with using !important in
quirk.css, but it will impact the ability of authors to override those rules, so
it must be considered carefully.

BTW: was the migration of the rules to form.css reviewed by pierre or rods? I
must admit that I was not aware of this change until now...

Comment 3

[David Hyatt]

I'm happy to solve this any way you like.  Let me know what approach you'd most
like to see.  If you want me to just revert us back to the way things were, I
can do that too.

Comment 4

[Hixie (not reading bugmail)]

IMHO we should really fix this by putting the @import _into_ the ua.css file and
using DOM-style tricks to enable/disable the stylesheets just like we do with
the quirk stylesheet. How does that sound?

Comment 5

[Peter Trudelle]

->moz0.9

Comment 6

[Vladimir Ermakov]

QA Contact Update

Comment 7

[Peter Trudelle]

->0.9.3, limbo candidate

Comment 8

[Blake Ross]

Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.

Comment 9

[Pierre Saslawsky]

It is a bit related to bug 43220.  Marking dependency.

Comment 10

[Christopher Hoess (gone)]

Various rearragnements to our UA CSS seem to have gotten this working. 
Resolving WORKSFORME.

Comment 11

[[e-mail]]

No, this is still a problem. To observe:
1. Notice that the last image in the test case has no border
2. Notice that tabbing to the first image in the test case shows an outline,
   quirk.css says it should change the border style to dotted.

Comment 12

[Boris Zbarsky [:bzbarsky]]

is this still a problem?  If so, could you point to the exact rules in 
forms.css and quirks.css that are not interacting in the right way?

Comment 13

[[e-mail]]

Basically the rules at lines 39-54 of quirk.css:
/* Quirk: input images have a blue border (b=28010) */

/* default border */
input[type=image] {
  border: 2px solid blue;
}

/* border when focused -- only change style to dotted */
input[type=image]:focused {
  border-style: dotted;
}

/* border when focused -- only change color to gray */
input[type=image][disabled] {
  border-color: GrayText;
}
are ignored because the rule at line 271 of forms.css:
input[type="image"] {
  ...
  border: none;
  ...
}
is overriding them.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment 2 basically describes the problem: at the moment, forms.css is _not_
imported from ua.css or html.css.  It's loaded via the chrome registry's
GetAgentSheets method and is inserted into the style set in
DocumentViewerImpl::CreateStyleSet.  This method does the following:

GetAgentSheets();
append them to the agent list in the style set one by one;
append ua.css to the list;

Unfortunately, style sets store sheets in order from most important to least
important, so this puts forms.css (and things like the scrollbar sheet) "later"
in the cascade than ua.css.

This may even be correct for the scrollbar sheet, but is definitely wrong for
forms.css

We have a few options:

1)  Change the order of sheets in the document viewer (this will also make
    html.css override forms.css, so it may not be such a great option).
2)  Insert the forms sheet into the ua sheet by hand instead of inserting it
    into the style set by hand (and put it right before quirk.css).
3)  Implement XBL form controls, lose the old forms.css, and import the xbl one
    from ua.css in the proper place in the cascade (after html.css, before
    quirk.css).

I like option 3, myself... ;)