Closed Bug 93431 Opened 23 years ago Closed 23 years ago

Can't get css's properties when define in an external file

Categories

(Core :: DOM: CSS Object Model, defect)

Product:
Core
Component:
DOM: CSS Object Model
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: krinn, Assigned: jst)

References

(
URL
)

Details

When trying to access css properties that are define in an external css file, js
report nothing...
When trying to access css properties that are define internally (in a html
page), js report it successfuly.

It's really bad (can't create a layer in an external css file), and can't get
any values.
I don't really know from where that bug came (js, dom, css or me :( )
ps: i haven't do test to SET the property of a css that was create with an
external file... but i think this part might be bug too.
Browser, not engine --> DOM Style for further triage
Assignee: rogerl → jst
Status: UNCONFIRMED → NEW
Component: Javascript Engine → DOM Style
Ever confirmed: true
QA Contact: pschwartau → ian
This is not a bug, element.style does, and should, only reflect the inline style
of the element, that is, the style that is defined in the style="..." attribute
on the element (<div> in this case), to access the current style used by an
element you should use document.defaultView.getComputedStyle(element,
"").getPropertyValue('color') to examine the actual color used to draw the
element. Alternatively if you're only interested in examining the styles defined
in the stylesheet you can accss that through document.styleSheet[n]...

Marking INVALID.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
ok... here some comments again
X refer to document.defaultView.getComputedStyle().getPropertyValue() function
Y refer to document.element.style() function

- There still something <strange>. i have update the dev-test/frames.html test
page with X
I must admit it works as you said... 
BUT check the page, you will remark 2 things
1- The X get the style no difference if the style was created internally (with
style="") or externally (with <link rel>). The Y only get the style internally
created. So why this function exist ? This funtion should exist only if X can't
get internal style, else nobody will use it (useless).
2- You will also remark that, X & Y return different value for the same stuff.
If you define background-color: RED, X return #FF0000 & Y return RED, of course
X return the hex color (witch is correct) but that two methods could only make 1
thing -> create bug
- X should return RED (as define by the programmer in the css, best choice)
- or Y should return #ff0000 (to be like X)

ps: where can i get document.function list ? i look in js 1.5 ref & dom 1.0 ref
within success.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Sorry, re-resolving invalid.  As far as document.* things go, consider looking
in the DOM2 spec as well.  :)  Explanation of what you see follows.

document.element.style is not a function.  It is an object of type
CSSStyleDeclaration.  If you look at
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-ElementCSSInlineStyle
(part of the DOM 2 Style spec) you will see that every element that can have a
style attribute implements the ElementCSSInlineStyle interface.  This interface
has a style attribute, so that's what you get with document.element.style.

Now, this CSSStyleDeclaration represents the contents of the style attribute as
the programmer entered them and essentially allows changing the inline style of
the element on the fly.  This CSSStyleDeclaration is both writable and
readable.  So you could call getPropertyValue()/setPropertyValue() methods of
the document.element.style object and they would work. See
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSSStyleDeclaration

document.defaultView.getComputedStyle() returns a CSSStyleDeclaration as well. 
This CSSStyleDeclaration is read-only and represents the computed values of all
the CSS properties of the element.  This means that it will include inline
style, internal and external stylesheets, the UA stylesheet, and possibly HTML 4
presentational markup in the values of the properties.  This CSSStyleDeclaration
allows you to see what all the CSS properties on the element are set to once the
cascade is taken into account.  This CSSStyleDeclaration returns absolute values
only -- sizes in em/ex/pt are converted to their pixel equivalents, as are
percentage and auto widths.  Colors are converted to a 6-digit hex notation
(which you saw).  You saw this with your RED example.  For more information, see
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-OverrideAndComputed

All the behavior you describe is precisely per the DOM2 spec.

If some part of what I said does not make sense, please feel free to mail me.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
*** Bug 93987 has been marked as a duplicate of this bug. ***
OK, i will just put comments here, but i don't reopen the bug (everybody already
think i'm mad).

I have taken a look at the references you give me and i still think there is
someting wrong.
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-OverrideAndComputed
This is the reference for document.defaultView.getComputedStyle() looking in the
text you will see that:
"This interface represents a CSS view. The getComputedStyle method provides a
read only access to the computed values of an element."
Clicking on "computed values" gives you that :
http://www.w3.org/TR/1998/REC-CSS2-19980512/cascade.html#computed-value
and you see:
"Specified values may be absolute (i.e., they are not specified relative to
another value, as in 'red' or '2mm') or relative (i.e., they are specified
relative to another value, as in 'auto', '2em', and '12%'). For absolute values,
no computation is needed to find the computed value"

So when you return the #ff0000 i think you are wrong, because :
1/ the css was RED (not #ff0000), and it's funny they take the same sample, RED
in the W3C example is define as an already computed value (absolute). No
computation is need (so no convertion should be made)
2/ where did you see that ? "Colors are converted to a 6-digit hex notation"
3/ Did you really find logic that one function return RED & another one #ff0000 ?
So when you said: "This CSSStyleDeclaration returns absolute values
only" you are totally right, but RED isn't a relative value ! it's an absolute
value.
RED vs. #ff0000 is not a matter of the value being absolute or relative, the
reason you get #ff0000 and not red is that mozilla (naturally) stores colors as
numbers for performance and space reasons, not as strings. One could argue that
mozilla should convert #ff0000 to RED, but there's not always a one-to-one
mapping between numeric representations of colors and color names, and storing
both would be a waste of space.

Feel free to file a new bug on this #ff0000 vs. RED problem.
FWIW the CSS working group is discussing canonicalisation rules which would make
it very clear whether the CSS DOM should return "#ff0000" "red" "RED" "#FF0000"
"#F00" "#f00" "rgb(100%,0,0)" "rgb(100%, 0, 0)" "rgb(255,0,0)" "rgb(255, 0, 0)"
or any number of other possibilities, so I wouldn't worrying about filing bugs
on it yet. The spec is currently extremely ambiguous about this.
Status: RESOLVED → VERIFIED
Ok this bug isn't really important, workaround is easy... but if CSS working 
group (CSSWG) still working on something i think it's up to mozilla working 
group to standardize the way the values should be return.
Am i the only one to think that if both functions return "red" or "#ff0000" we 
will have a better life ?
More... the CSSWG *might* not be aware of that issue. Some of you should contact 
it and explain the situation and gives a suggestion of standardization. Else we 
will get back to old time.
My workaround is : STOP use red, blue... in the CSS declaration, both functions 
are able to return hex color codes so use only hex colors codes.

krinn@altavista.net, there is no "Mozilla working group".

And Ian's on the CSS Working Group, so if he says they're discussing it then
they're discussing it....
krinn, "red" and "#ff0000" mean exactly the same thing, so why is this a problem?


Johnny here an example why it's bad:
I always work with external css files (i prefer, any change on it is reflect on
many html pages)
Generic code follow (# is comment):
<div id="testDiv"></div> # i have define in the css the color <Red> for background
var divList=document.getElementsByTagName("div");
var bug=divList["testDiv"].style.backgroundColor;
if ( bug == "Red" ) { do something } # do something will never execute because
this function will return #ff0000

Johnny, Red and #ff0000 are the same, but you see how we can create a bug...
Ian, i hope all this comments will help you speed up things ;)
I agree that this bug is serious and will negatively impact both adoption of
Mozilla and use of CSS in large scale web projects. As a senior web consultant I
frequently encounter organizations which wish to put styles in external
stylesheets so they may swap them quickly and easily, but also put some styles
directly in elements. Because of this bug this means the Javascript programmer
doesn't know where to look in the DOM to get correct style information.
Expecting them to go poking around for it and guess at the correct method is
unreasonable: on a large site with thousands of pages, the site should not be
forced to choose one location for styles in advance and stick with it to the
exclusion of the other.

I believe this bug should be reopened and fixed.
Please file a new bug about the colour thing instead of morphing this one.
The CSSWG has decided that user agents may return the data in whatever form it
likes (I think this is stupid, but...). Mozilla is encouraged to use my c14n
proposal: http://www.damowmow.com/mozilla/canon.txt
> Because of this bug this means the Javascript programmer doesn't know where to
> look in the DOM to get correct style information.

Sure she does.  It's in the currentStyle object in IE and in the CSS declaration
returned by getComputedStyle() in Mozilla (the latter is what the DOM CSS
specification requires).  That same specification _also_ requires that
element.style return a CSS declaration corresponding to inline style _only_.

If you're talking about the color thing, we should be aiming to return 
"rgb(R, G, B);" everywhere.  I know that computed style will be returning this
starting a few days from now...  And as Ian says, please file a separate bug on
that if it's the color thing bothering you in particular.
Just a note since there have been a few complaints about the output of our
computed colors, the fix for rgb(R, G, B) output in computed style is now in
the tree.  The next nightlies should have color values output in that format
when called with getPropertyValue() and should return an RGBColor object when
called with getPropertyCSSValue().  See the spec on RGBColor objects:
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-RGBColor
You need to log in before you can comment on or make changes to this bug.