[ng-dhtml] style.js

Erik Arvidsson erik at eae.net
Sat Sep 17 17:18:03 CDT 2005


It wasn't meant as critique. I was mostly analyzing some very 
complicated issues. With a hindsight it might have been a bit harsh. 
That was not my intent.

erik

Scott J. Miles wrote:
> 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
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> NG-DHTML mailing list
> NG-DHTML at netwindows.org
> http://netwindows.org/mailman/listinfo/ng-dhtml_netwindows.org




More information about the NG-DHTML mailing list