295657 - The attribute selectors appear to be static

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[lightsolphoenix]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050526 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050526 Firefox/1.0+

It appears that even in the nightly builds, Gecko doesn't reupdate the attribute
selectors when situations change.  As soon as you type text into the box, the
required text next to it should change color (because the rule that makes it red
has [value=""] in it).

At first, I thought this might be an error in the test itself, but it appears
that it is valid CSS, and other CSS-compatible browsers can handle it.

Reproducible: Always

Steps to Reproduce:
1.Go to the page located above.
2.Enter some text in a required box.

Actual Results:  
The results text stayed red, despite the fact that the rule should not work once
you type in some text.

Expected Results:  
The text should have turned grey, as the [value=""] becomes invalid as soon as
the input box contains any text at all.

Comment 1

[Hermann Schwab]

This test depends on IE-specific code:

<!-- compliance patch for microsoft browsers -->
 <!--[if lt IE 7]>
  <script src="../ie7-standard-p.js" type="text/javascript"></script>
  <script src="../ie7-dynamic-attributes.js" type="text/javascript"></script>
 <![endif]-->

The js files are in a conditional comment, IE proprietary, so not seen from
Mozilla. Dynamic attributes are handled in the secon file below.

http://dean.edwards.name/IE7/ie7-standard-p.js
http://dean.edwards.name/IE7/ie7-dynamic-attributes.js

Comment 2

[lightsolphoenix]

(In reply to comment #1)
> This test depends on IE-specific code:
> 
> <!-- compliance patch for microsoft browsers -->
>  <!--[if lt IE 7]>
>   <script src="../ie7-standard-p.js" type="text/javascript"></script>
>   <script src="../ie7-dynamic-attributes.js" type="text/javascript"></script>
>  <![endif]-->
> 
> The js files are in a conditional comment, IE proprietary, so not seen from
> Mozilla. Dynamic attributes are handled in the secon file below.
> 
> http://dean.edwards.name/IE7/ie7-standard-p.js
> http://dean.edwards.name/IE7/ie7-dynamic-attributes.js


That code is only for IE.  Mozilla should understand the CSS alone, and not need
the Javascript.

fieldset p.required > input[value=""] + sup {
		color: red;
	}

That rule should not be applied the moment you enter text in the input; text in
the input is put into the value attribute, after all.

Comment 3

[Martijn Wargers (dead)]

This bug is invalid, see:
http://dean.edwards.name/weblog/2005/05/ie7-08/#comment1891

Comment 4

[lightsolphoenix]

(In reply to comment #3)
> This bug is invalid, see:
> http://dean.edwards.name/weblog/2005/05/ie7-08/#comment1891

Ah, I had a feeling that might be the case.  I checked it in a few other
browsers, and it worked, so I had a feeling it might be standard behavior.  But
if the CSS specification says it's not, then I guess it's invalid code.

Comment 5

[Hixie (not reading bugmail)]

Which other browsers?

Comment 6

[lightsolphoenix]

(In reply to comment #5)
> Which other browsers?

Opera 7, but it appears to have been fixed in Opera 8.  Of course, my version of
Opera 8 isn't the current version either...

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This has nothing to do with the CSS specification; it's the HTML and HTML DOM
specifications that should make it clear that it's invalid.

Comment 8

[Jim Ley]

David, I really can't see anywhere in the HTML DOM 2 spec that suggests that 
DOM properties are anything but live and settable, 1.6.1 seems pretty clear to 
me, could you clarify why this has been ruled invalid?

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Read the descriptions of checked, value, defaultChecked, and defaultValue in
http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-6043025 and
http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-24874179 .
 They clearly say that the current value of the form control stays in sync with
the DOM value attribute which does not correspond to a markup attribute on the
element; the markup value attribute corresponds to the DOM defaultValue
attribute, used when the form is reset (likewise for *checked).

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And even if that spec never existed, you'd need a specification that said that a
user change to a form control caused a change in the markup/infoset to
demonstrate that this was a bug.

Comment 11

[Jim Ley]

Indeed for defaultChecked etc. the specification is clear, however this bug is 
with respect to class and className, can you please point me to the part of the 
spec that makes that clear, can you also explain the discrepency with 1.6.1 ?  
The problem is not with user changes, it's through property changes on the DOM, 
and 1.6.1 is clear here.  Certainly for defaultChecked etc. it's different, and 
it's also clear, I see no contradiction in the spec.

>And even if that spec never existed, you'd need a specification
>that said that a user change to a form control caused a change
> in the markup/infoset to demonstrate that this was a bug.

This is not a form control bug, so references to form controls are not 
relevant, for non form controls mozilla already has a user change of document 
causing an infoset change - contentEditable.  Of course the WHAT WG person 
hasn't finished specifying this, but I cannot see how contentEditable can be 
specified without requiring a change to the infoset.

Cheers.

Comment 12

[Martijn Wargers (dead)]

(In reply to comment #11)
> Indeed for defaultChecked etc. the specification is clear, however this bug is 
> with respect to class and className, 
As far as I can see here, this is not about class and className (which should
work fine). 
This is about the input[value=""] not 'working', when something has been typed
in the input. e.g., that selector still matches when something has been typed in
the input.