[ng-dhtml] style.js

Erik Arvidsson erik at eae.net
Sat Sep 17 13:40:53 CDT 2005


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
> 
> 




More information about the NG-DHTML mailing list