SmartClient size reporting bugs & deficiencies

[nick.shrayer.2]

Hi Isomorphic,
we're using SC for building SPA containing many-many pages. We've found (and resolved) couple of problems related to content sizing:

1. When individual page needs to perform custom styling, we want all it's CSS declarations to be contained under single container CSS class (that container CSS class could be assigned to specific screen top-level Canvas). Specifying borders, paddings and margins by cascading CSS rules does not work good with SmartClient though. After digging into SC source code it's clear this is due to the fact SC analyzes CSS classes by applying them to tester DIV. Container class names are not taken into account though.

2. The Canvas.getScrollWidth() method checks this.useClipDiv although it does not seem to be relevant there. As a result clipDiv existence is not taken into account (borders+paddings width is not calculated). The problem does not exist in Canvas.getScrollHeight() which only checks clipDivDrew without referencing this.useClipDiv

3. When inner Canvas is sized based on parent Canvas size, especially in a "width:100%, height:100%" way, there is a kind of misbehaviour. The percent resolution is made relative to innerWidth/innerHeight. It's pretty obvious that at
least in case of "100%" (I would say in all other cases too) the innerContentWidth/innerContentHeight should be used to prevent sizing over defined parent paddings

4. In case outer Canvas is automatically sized to resolve overflow (overflow=="VISIBLE"), there is a problem with the fact SC is using scrollWidth and scrollHeight DOM properties when margins are specified on inner Canvas. The behavior is different in different browsers. In Chrome scrollWidth does not take right margin into account (it does take left margin though) and scrollHeight does take top and bottom margins. In IE neither right nor bottom margins taken into account

I've build a script which "resolves" issues 1,2 and 3. I did not resolve issue 4 because it would require to make modifications (and not just replace) to SC methods and we tend to use minified version supplied by you
Issues 1,2 and 3 are resolved but resolution involved replacing some methods in a minified code which I don't like as well.

Attached are:
SmartClientSizingFixes.js ( SmartClientSizingFixes.js )--> "Resolution" code

TestCase.htm --> HTML showing number of scenarious ------ I WAS NOT ABLE TO ATTACH IT for some reason (the system shown "Invalid image..." message?!?)



BeforeFix.png ( ) --> Picture showing above HTML output without SmartClientSizingFixes.js applied


AfterFix.png ( ) --> Picture showing above HTML output with SmartClientSizingFixes.js applied

[Isomorphic]

Thanks for taking the time to put these together and sharing them with us. We'll review them and follow up with you.
For the HTML test case - if it's not too enormous, perhaps you could simply include the source inline in a [code] block? Alternatively feel free to zip it up and mail it to support@isomorphic.com, including a link to this thread in your mail for context.

Regards
Isomorphic Software

[nick.shrayer.2]

Thanks. I've put all related stuff together into ZIP (88K all together including images) and sent to support@isomorphic.com. I appreciate your involvement!

Regards,
Nick

[nick.shrayer.2]

Hello, Isomorphic
Any news on this?

[Isomorphic]

Hi Nick,
This is not forgotten. It's currently under internal review by the development team. We'll follow up when we have more information for you.

Regards
Isomorphic Software

[Isomorphic]

Hi Nick
A quick status update for you:
----
Issue #2 is a simple bug. This is now resolved in the 11.0 and 11.1 branch.
----
Issue #3 is something we are taking on (not yet resolved).
There is a known, longstanding issue here - though it's not quite what you describe.

The padding for a Canvas should not impact the size/position of absolutely positioned children of that canvas. In other words, if you create a parent widget with padding set to 10, and a child positioned at 0/0 with width/height set to "100%", they fill the parent entirely, rather than appearing to be 10px inset inside the parent.
This is the intended behavior and it works fine for explicitly specified padding.

[There is an exception with Layouts if paddingAsLayoutMargin has been set to true, but that's achieved via a separate mechanism]

Padding applied as part of a css styleName applied to the Canvas also has no impact on the size of absolutely positioned children in some browsers, but not all.
Under the covers, in some browsers SmartClient renders a double-div structure for each canvas, and in this case the css class is applied to the outer div, while children are rendered inside the inner div -- this means the padding does have an impact on the position of the children.
This is a longstanding known bug - but you've prompted us to revisit and tackle it. We will follow up here when it is resolved.
This change will likely go into 11.1d only.

----
On issue #1 - SmartClient's handling of descendant selectors:
We acknowledge that this isn't currently handled - as you have found, in some places we explicitly look up attributes for a styleName and use the results in sizing calculations. These lookups do not take the element hierarchy / cascaded styles like this into account, and so you can get some sizing differences.
We're still investigating whether to add logic to handle this - there are some possible concerns about performance, as well as some further analysis to be performed on our end around what edge cases need to be handled, etc.
We'll follow up on this when we have a decision.
----
On issue #4 - We are unable to reproduce this problem without the use of descendant selectors. Have you seen this occur outside of that scenario? If so, could you show us a simple code snippet to reproduce the problem


Thanks
Isomorphic Software

[nick.shrayer.2]

Hello Isomorphic,

thanks for investigation and taking described into consideration. Sorry for not checking the thread for long time and so delaying with resonse
Here are my comments on your answer:

#3. I understand what you mean. It does make sense but would you also evaluate a possibility of adding additional property, like paddingAsLayoutMargin for Layouts, which would change the behavior of any Canvas to treat padding in a way whch would affect children positioning?

#1. Taking into account you are extensively caching results of CSS lookup and the chain of patents having styleName defined is typically not long, I believe handling of descendant selectors will only be appreciated. We personally need it in our project. :-) If you have doubts with performance implications, it's always possible to make switchable on/off based on some global flag

#4. The problem is really reproduced with attached test case. I'm attaching another picture which points the problem. Again, the code is originally attached and also sent to you via mail




I have also additional question. Is this intensional or historical decision not to use multiple CSS classes and rather use combind names? For instance, you would use Button, ButtonOver, ButtonDisabled etc instead of applying multiple separate classes - one "Button" and another one "Over" or "Disabled" or whatever else. Multiple CSS classes would make CSS so much simpler... It's of especial issue for un now, when we're performing styling of our SmartClient-based application. BTW, because of some objectives we're using LESS, not SASS (as you most probably use)

[nick.shrayer.2]

Hello Isomorphic,

could you please give an update on status of the issues on this thread?

[Isomorphic]

#3 we don't plan to do this. snapTo positioning, which allows offsets, could be used in various places where offsetting by padding is necessary. If this is somehow a recurring issue for you, consider Feature Sponsorship as a way to get a feature like this added.

#1 even if the flag was off by default, we would still have to document and support what it does when it's turned on, and it's very very complicated to even characterize when this would be expected to work or not, especially given all the browser bugs in this area. So right now, we don't plan to implement something like this.

#4 this one is still pending

About stateful styling: the main reason we use compound state names is non-orthogonal additive states. For example, selected+over is often a double-darkening of the background color, and may involve darkening the font color only when the background has been double-darkened. This isn't something that can be achieved by adding two separate CSS styles to a base state - at least not without using CSS techniques that are significantly more expensive (like a translucent background image to darken further, when just a color code would have worked with compound state names).