[ng-dhtml] style.js

Scott J. Miles sjmiles at turbophp.com
Sat Sep 17 14:52:07 CDT 2005


Erik,

Thank you very much for your notes. I want to address your points in some
detail, but first I wanted to highlight two issues that I need some guidance
on.

The first issue is that in some cases getXXX[Width|Height] cannot calculate
the appropriate value and my implementation returns NaN. When we discussed
it briefly before, Paul noted that he wasn't fond of this solution, so I was
wondering what other options should be entertained.

Aside: FF/Mozilla passes all tests (never returns NaN) because the
getComputedStyle (apparently) always has values in 'px' (except for 0 values
which are in 'pt' for some reason). Of course, it's possible (likely?) that
I omitted some important case from my test logic.

The second issue is that I only tested DIVs. I know other elements have
their own sizing quirks. I don't know how to solve or even test this problem
in general.

On to Erik's critique,
 
To be clear, I didn't write much of the code to which you refer. I (mostly)
only worked on the code that attempts to implement the get/set size
functions.

>> with dojo.style [inline vs class vs ...] distinctions are not available.
<<

Yes, I believe the idea with dojo.style was to return the 'active' value for
any property. I'm a little nervous about saying/doing too much here because
I'm not sure what the original philosophy was. 

Do you suggest that there should be separate functions for acquiring
properties from the various style specifications?

>> IE has a way to get the cascaded CSS value (W3C does not). This is 
called currentStyle. W3C has a way to get the computed value (IE does 
not). This is done using getComputedStyle. <<

As I mentioned, I didn't implement getStyle, so there may be issues I'm not
aware of. I believe I understand the problem you bring up and I will try to
come up with a better function.
 
>> I find your definition of inner and outer width/height confusing.
>> ...
>> // values: margin-box, border-box, padding-box and content-box as
>> // proposed by CSS3

My experience lies in other fields than DHTML so I frequently use the wrong
terms of art. You suggestion is logical and I appreciate the input.

>> You are not consistent with tabs and spaces and therefore the ASCII art 
is not correctly lined up. <<

Sorry. I will try to fix that ASAP. I also plan to make a proper diagram
(image) at some point.

>> Dean Edward's IE7 supports all unit types. It is open source so maybe 
you can grab some code from there to support more units? <<

Wow, I've never seen that before. Lots of goodies there.

I don't know anything about totalOffset, opacity, or insertCss functions. I
think somebody else should look at your notes there.

Regards,
Scott 

-----Original Message-----
From: NG-DHTML-bounces at netwindows.org
[mailto:NG-DHTML-bounces at netwindows.org] On Behalf Of Erik Arvidsson
Sent: Saturday, September 17, 2005 11:41 AM
To: the Dojo project contributor's discussion list
Subject: Re: [ng-dhtml] style.js

Hello,

Some comments...

The whole concept of computed style, cascaded style, override style and 
inline style is lost here. I know it is very hard (impossible?) to do 
this correct. I have throughout my years come to regret doing it the way 
you are doing too often to remember. Take this common scenario:

.foo {
    display: inline;
}

.bar {
    display: block;
}

<el class="foo">...</el>
<el class="bar">...</el>

Then to hide it we do something like:

el.style.display = "none";

and to show it again:

el.style.display = "";

Your code makes it impossible to get "" from dojo.style.getStyle(el, 
"display"). Maybe not the best example but with dojo.style these 
distinctions are not available.

Both IE and DOM (not Mozilla last time I checked) has a way to set and 
get the override style. A way to set a value with highest priority 
without changing the DOM. In IE this is called the runtimeStyle and in 
W3C getOverrideStyle.

IE has a way to get the cascaded CSS value (W3C does not). This is 
called currentStyle. W3C has a way to get the computed value (IE does 
not). This is done using getComputedStyle. It is important to remember 
that the computed style is not the same as the cascaded style. For example:

p { visibility: visible }
div { visibility: hidden }
div p { visibility: inherit }

For a p inside a div:

computed value: "hidden" (or some other fixed/absolute value)
cascaded value: "inherit"

When the cascaded value is "inherit" we can go up in the DOM tree and 
hopefully find an absolute value. However it is very common that we end 
up with an "auto" value and I don't know any way to get the computed 
value from that.

I find your definition of inner and outer width/height confusing. 
Usually the outer size is the border-box size and not the margin-box 
size and inner size is the padding-box size. Maybe using something like 
this would be clearer?

// values: margin-box, border-box, padding-box and content-box as
// proposed by CSS3

dojo.style.boxSizing = {
    marginBox: "margin-box",
    borderBox: "border-box",
    paddingBox: "padding-box",
    contentBox: "content-box"
};

getWidth(sBoxSizingType)
setWidth(sVal, sBoxSizingType)

You are not consistent with tabs and spaces and therefore the ASCII art 
is not correctly lined up.

Dean Edward's IE7 supports all unit types. It is open source so maybe 
you can grab some code from there to support more units?

totalOffset* is incorrect. It needs to take scrolling into account. Both 
IE and Mozilla have more efficient ways to calculate this. IE has 
el.getClientRect() and Mozilla has document.getBoxObjectFor(el).

insertCssRule etc: passing index as 0 will not work correctly. Maybe it 
is better to pass the css selector to insert before or remove? Or 
alternative provide access to the rule objects or create a wrapper for 
those?.

The following will return incorrect value when the opacity is 0

var opac = node.style.opacity || node.style.MozOpacity ||
			node.style.KhtmlOpacity || 1;

Shouldn't this

// Safari doesn't say "transparent"
if(color.toLowerCase() == "rgba(0, 0, 0, 0)") { color = "transparent"; }

be something like

// Treat fully transparent as "transparent"
if(/^rgba\(\d+,\s*,\d+,\s*\d,\s*0\)$/i.test(color)) { color = 
"transparent"; }

erik

Scott J. Miles <sjmiles at turbophp.com> wrote:
> Hello,
> 
> I did a lot of work on "style.js". And then I talked to Paul and I went
and
> did a lot *more* work. 
> 
> I don't want to commit it yet, because there are still some unresolved
> issues. In particular, I won't do anything until Paul says it's ok (or
not).
> 
> The bottom line is that there are certain values that (afaik) cannot be
> calculated on some browsers. In particular, the margins resulting from
> margin: auto cannot be calculated on IE (and Safari in OSX 10.3). Also, in
> some browsers and some styles, values not specified in 'px' cannot be
> resolved. In these cases, the getXXX functions return "NaN", and the
> setOuterWidth|Height functions return "false".
> 
> There are other limitations too. I believe these functions are incredibly
> useful, but they must be used only under controlled conditions. This is a
> point of tension.
> 
> You may want to inspect these two (maybe ridiculous) unit tests:
> 
> Tests setOuterWidth against a variety of DIV stylings: 
> 
> http://itch.homeip.net:8080/turboajax/dojo/tests/test_style2.html
> 
> Displays get[Content|Inner|Outer][Width|Height] against a variety of DIV
> stylings: 
> 
> http://itch.homeip.net:8080/turboajax/dojo/tests/test_style.html
> 
> Be advised that these tests can take awhile to load (I didn't bother
trying
> to optimize them).
> 
> Unfortunately, there are still many more permutations. In particular, the
> tests only run against DIVs. Various other elements have other quirks.
> 
> My proposed style.js is available here:
> 
> http://itch.homeip.net:8080/turboajax/dojo/src/style.js
> 
> Regards,
> Scott
> 
> 

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.1/104 - Release Date: 9/16/2005
 




More information about the NG-DHTML mailing list