headers
Boris Zbarsky | 3 Nov 2003 18:51
Picon
Favicon

Re: getComputedStyle / getOverrideStyle


> After writing the results of the animations into the override style
> declaration (the one returned by getOverrideStyle) Is the style declaration
> found in getComputedStyle modified to contain the new computed values

The computed style always includes all styles applied to the element in
question.

Boris
--

-- 
"This isn't right.  This isn't even wrong."

                -- Wolfgang Pauli on a paper submitted 
                   by a physicist colleague
Permalink | Reply | 10 comments |
headers
Sigurd Lerstad | 6 Nov 2003 18:33
Picon

Re: getComputedStyle / getOverrideStyle


>
> > After writing the results of the animations into the override style
> > declaration (the one returned by getOverrideStyle) Is the style
declaration
> > found in getComputedStyle modified to contain the new computed values
>
> The computed style always includes all styles applied to the element in
> question.
>

I know that getComputedStyle always includes all the computed properties of
the element, but if getComputedStyle also contains the result of the
animated properties, what's the point of getOverrideStyle? since
getOverrideStyle would just return the same property values that are in
getComputedStyle.

The way I hope this works is that getComputedStyle contains the base values
of all the properties, and getOverrideStyle contains any animated property
values, but I need confirmation that this is how it works.

thanks,

--
Sigurd Lerstad
Permalink | Reply | 8 comments |
headers
Boris Zbarsky | 6 Nov 2003 20:14
Picon
Favicon

Re: getComputedStyle / getOverrideStyle


> I know that getComputedStyle always includes all the computed properties of
> the element, but if getComputedStyle also contains the result of the
> animated properties, what's the point of getOverrideStyle?

The point (such as it is) is that getOverrideStyle is _writable_ and allows you
to effectively set inline style even if the document language does not support
such a concept.  Computed style is readonly.

Are there any UAs which actually implement getOverrideStyle?  None of the
browsers do, but do any of the SVG implementations?

Boris
--

-- 
Economists state their GNP growth projections to the
nearest tenth of a percentage point to prove they have a
sense of humor.
                             -- Edgar R. Fiedler
Permalink | Reply | 6 comments |
headers
Sigurd Lerstad | 6 Nov 2003 21:07
Picon

Re: getComputedStyle / getOverrideStyle


>
> > I know that getComputedStyle always includes all the computed properties
of
> > the element, but if getComputedStyle also contains the result of the
> > animated properties, what's the point of getOverrideStyle?
>
> The point (such as it is) is that getOverrideStyle is _writable_ and
allows you
> to effectively set inline style even if the document language does not
support
> such a concept.  Computed style is readonly.

Yes, but in this case, animations setting animated properties into
getOverrideStyle (as specified in the SVG spec), it's the UA itself that
does that, and the UA of course also has write-permission into
getComputedStyle

> Are there any UAs which actually implement getOverrideStyle?  None of the
> browsers do, but do any of the SVG implementations?
>

I'm trying to implement it in my LXViewer, and that's why I need to know how
it works. Are you saying that writing into getOverrideStyle (by UA itself or
a user), that also changes the values that are in getComputedStyle?
If that's true, I can see how that works now, For a given element, the UA
computes the computed properties based on stylesheets etc. and then looks at
the override style on the element to see if there are any properties there,
and then "overrides" the computed style with those.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Boris Zbarsky | 6 Nov 2003 21:18
Picon
Favicon

Re: getComputedStyle / getOverrideStyle


> Yes, but in this case, animations setting animated properties into
> getOverrideStyle (as specified in the SVG spec), it's the UA itself that
> does that, and the UA of course also has write-permission into
> getComputedStyle

"the UA" is not a monolithic entity... for example, most of Mozilla code cannot
write into the computed style declaration.

> I'm trying to implement it in my LXViewer, and that's why I need to know how
> it works. Are you saying that writing into getOverrideStyle (by UA itself or
> a user), that also changes the values that are in getComputedStyle?

Correct.

> If that's true, I can see how that works now, For a given element, the UA
> computes the computed properties based on stylesheets etc. and then looks at
> the override style on the element to see if there are any properties there,
> and then "overrides" the computed style with those.

Not quite.  The UA just computes based on stylesheets, period. The override
style is just another author sheet, one that has priority over other author
sheets (you can think of it as coming after all other author sheets).

In particular, user !important rules override the override style.

Boris
--

-- 
Economists state their GNP growth projections to the
nearest tenth of a percentage point to prove they have a
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sigurd Lerstad | 7 Nov 2003 02:31
Picon

Re: getComputedStyle / getOverrideStyle


Okay, thanks, that makes sense, this has been bugging me for a while now.

--
Sigurd Lerstad

>
>
> Not quite.  The UA just computes based on stylesheets, period. The
override
> style is just another author sheet, one that has priority over other
author
> sheets (you can think of it as coming after all other author sheets).
>
> In particular, user !important rules override the override style.
>
Permalink | Reply | 0 comments |

Gmane