Extract CSS Attributes from external CSS file

[melody]

Is it possible to retrieve CSS attributes applied by referencing CSS
classes in an external class.

For instance if I have a CSS below.


.wrapper {
padding:5px 5px 5px 5px;
background-color:#c3daf9;
}

Then I create a Widget and apply the CSS

Widget w = new Widget();
w.setStyleName("wrapper");

How can I get the value of the padding style attribute above from the
widget?

Thanks,

Melody

[Ian Bambury]

First, your widget must, of course, use the attribute you are trying to get

 

Second, for some attributes (width, height and other sized things, probably including padding) the widget must be attached to the DOM (but it can be not visible)

 

Then you can use DOM.getStyleAttribute

 

--
Ian
http://examples.roughian.com
__________________________________________

Stuff the environment - print this email
__________________________________________

[melody]

Thanks Ian.

It would seem that DOM.getStyleAttribute() only returns something of
the style attributes are inline (set using DOM.setStyleAttribute or
set as part of the HTML of the element like so

<div id="wrapper" class="wrapper" padding="padding:5px 5px 5px 5px">

I can extract padding from the above DIV using DOM.getStyleAttribute()
but I cannot get padding applied using the former method where the
style is defined externally in a style document or style section.

I am almost convinced that there must be a way but I cannot find it?

It just seems to make sense that you should be able to retrieve CSS
attributes whether or not they are applied inline?


And yes, the widgets I am dealing with are indeed attached to the DOM
and even visible when I tried to use DOM.getStyleAttribute() and it
returned nothing.


Thanks,

Melody

[Peter Blazejewicz]

hi Melody,
you've good mood about things (CSS styles), There are "style",
"computedStyle", "currentStyle" properties that should be used to get
your example implemented - and that requires deffered bindings because
of our beloved IE,
see descriptive blog entry:
http://blog.stchur.com/2006/06/21/css-computed-style/
you can digg how dojo or jquery deal with cross-browser padding
computation by reading their sources ,

regards,
Peter

[melody]

Thanks Peter.

Just in case someone finds this useful. Here is the JSNICode I ended
up using:

public static native String getStyleProperty(Element _elem, String
_style) /*-{
var computedStyle;
if (typeof _elem.currentStyle != 'undefined')
{
computedStyle = _elem.currentStyle;
}
else
{
computedStyle =
document.defaultView.getComputedStyle(_elem, null);
}
return computedStyle[_style];
}-*/;

[melody]

I am back with another IE/FireFox headache. I am glad there is GWT to
shield me from most of the headaches with these browsers from hell.
But then I also wish GWT anticipated all the use cases so that I would
not have to drill down to JSNI for anything unless I really wanted to,
not because I have to, like retrieving computed styles.

Anyway enough complaining.

The JSNI code above apparent works only is IE and does not work in all
Gecko browsers, Opera and Safari. Here is a variation of the above
code that I changed after reading the Mozilla developer docs. It uses
the CSSStyleDeclaration method getPropertyValue(String) thus

<code>
public static native String JSNIGetStyleProperty(Element elem, String
strCssRule) /*-{
var strValue = "";
if(document.defaultView && document.defaultView.getComputedStyle){
var foo = elem.cloneNode(false);
strValue = document.defaultView.getComputedStyle(foo,
"").getPropertyValue(strCssRule);
}
else if(elem && elem.currentStyle){
strCssRule = strCssRule.replace(/\-(\w)/g, function (strMatch, p1){
return p1.toUpperCase();
});
strValue = elem.currentStyle[strCssRule];
}
return strValue;
}-*/;
</code>

Now this beautiful code works wonders in IE. It is also wonderful
because I can pass the property names as they are in the CSS document
like so

<code>
String css = JSNIGetStyleProperty(Element, "padding-left");
</code>

IE expects the property name to be "paddingLeft" so the code does the
conversion.

The rest of the browsers expect the property name as passed which is
cool, if only they could return a the correct value.

The Problem:
FireFox, Opera etc always return 0px no matter what you are trying to
retrieve. It seems that the problem (I actually think bug) is in the
element as it is passed from firefox to JSNI. It seems that the CSS
binding is not available when the element is passed to JSNI (in
FireFox etc). I say that because I know that a similar javascrip
function embedded in an html page with no GWT works and actually does
retrieve the CSS properties even in firefox. Here is an example of
code that actully works in an html page. Notice how the getStyle JS
function is exactly the same as the JSNI code above.


<code>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
TR/html4/strict.dtd">
<html>
<head>
<link rel='stylesheet' href='Progeny.css' type='text/css'>
<title>getComputedStyle table margin bug</title>
<style type="text/css">
table{margin:100px;}
.wrapper {
margin: 5px;
padding: 10px 10px 10px 10px;
background-color:#dfe8f6;/*#c3daf9*/
border: 1px solid magenta; /*TODO*/
display: block;
width: 1920px;width: 1920px !important;
height: 1022px;height: 1022px !important;
}
</style>
<script type="text/javascript">
function getStyle(oElm, strCssRule){
var strValue = "";
if(document.defaultView && document.defaultView.getComputedStyle){
strValue = document.defaultView.getComputedStyle(oElm,
"").getPropertyValue(strCssRule);
}
else if(oElm.currentStyle){
strCssRule = strCssRule.replace(/\-(\w)/g, function (strMatch, p1){
return p1.toUpperCase();
});
strValue = oElm.currentStyle[strCssRule];
}
return strValue;
}

</script>
</head>
<body>

<div id="wrapper" class="wrapper">

<div class="toolbar" valign="middle">
<div id="toolbar" valign="middle"></div>
</div>
<div class="tabbar-wrapper" >
<div id="tabbar-wrapper"></div>
</div>
<div class="content-wrapper" id="content-wrapper">
<h1>YYYYYYYYYYYYYYYY</h1>
</div>
</div>
<table id="foo"><tr><td>Actual margin is set to 100px</td></tr></
table>
<script type="text/javascript">
var foo = document.getElementById('wrapper');
alert('Padding-Right: '+ getStyle(foo, 'padding-right'));
alert('Margin-Right: '+ getStyle(foo, 'margin-right'));
</script>
</body>
</html>

</code>


Any thoughts?

Is this a bug in GWT that only manifests in non-IE browsers?

I have already spent too much time on this that I am afraid I could be
fired for incompetence. Somebody please help.

I am tempted to enter it as a bug but I am really not sure.

And if anybody knows about GWT1.5, does the new Style Object help with
retrieving style information from external files. I looked up the docs
(1.5) but its not clear whether the Style object encapsulates inline
styles or computed styles or both?


Thanks,

Melody

[jchimene]

Hi,

Maybe there's another way to address the issue. What problem are you
trying to solve?

-30-

[melody]

>>>
Maybe there's another way to address the issue. What problem are you
trying to solve?
>>>>

Well the thing is my application has widgets that must fit exactly
into provided windows and it also has to respond to WindowResize
events so that the containers and/or heir children are sized
correctly. Because externally injected CSS styles introduce things
like padding, margin and borders to a widget, it is important for me
to know how much of that space (margin + padding + border) has been
applied to a widget before I can determine the correct size of the
contents or child(ren) widget.

When I set the widget size I also need to know (something I found out
with a kind of rude awakening) how much of that size goes to the
contents, contents + padding, or contents + padding + border. As you
might know, IE (in quiks mode) sets the size to the latter while
firefox (I believe Opera too) give the size you set to the contents
unless you set the box-sixing CSS property (see
http://developer.mozilla.org/en/docs/CSS:-moz-box-sizing) on that
element appropriately.

I sure would have wanted a different way so if there I would be happy
to know. I particularly do not like the fact that I have to use JSNI
to determine what CSS style properties were applied to a widget.

As far as the problem I had was concerned, it turns out the reason the
code was working in IE and not in FF is that I was errorneously using
the javascript style of accessing the DOM document thus

[code]
var computedStyle = document.defaultView.getComputedStyle(element,
null);
[/code]

This would not work because GWT (as I later found out) access the DOM
document object using $doc and not document as I was doing.

[code]
var computedStyle = $doc.defaultView.getComputedStyle(element, null);
[/code]


The IE part of the code (see above) did not access document like that
so it worked fine.

[melody]

In fact to see what I am talking about, take a look at this test
application (everything is fine in IE but in FF the properties are
returned as zero). Also notice how the window size changes to sizes
you dont expect (in FF) when you apply the borders and/or margins

http://progeny-fiat.raideil.net/TestLayout

[Jeff Chimene]

Hi Melody,

Thank-you for the detailed answer!

I don't envy your task, laboring as you certainly are under constraints of which I'm blissfully unaware.

The requirements you describe seem contradictory w/r/t/ absolute positioning and allowing on-demand window resizing, and you've probably moved beyond the requirements definition phase.

• Can you set margin, padding, border to zero in the external CSS?
• Do you need Quirks mode? Are you calling out a DTD? ISTR GWT specifically recommends using the Transitional HTML DTD.
  
• Perhaps it's worth considering only resizing to integral multiples of the nominal window size; which constraint might simplify subsequent widget dimension calculations.
• How wedded is the customer to arbitrary window dimensions? Perhaps it's worth disabling the resizing feature to concentrate on the first version of the product.
  
• The HTML DOM may be the wrong tool for this effort. How about XForms or PDF forms?

Buena suerte,
jec

[Ian Bambury]

Just a suggestion to think about, I haven't tried this, but it's what I'd try.

You can forget all modes (quirks, strict etc) if you have a div (SimplePanel) with no decoration at all and set its width to 100%. It will then fit and return a genuine width.

Inside that, put your unrestricted but decorated panel. This will expand to fit the wrapper. Width-wise, job done.

Height. This is where you have a real problem if you have a fixed height and have to scroll content within it. If you can just expand to whatever height you need, then you are OK.

It is also easier if the decoration is constant around the box - i.e padding, border and margin are constant for all edges.

If you need to set the height, too, then let me know the details and I'll think about it :-)

[melody]

Jeff
Thanks for the response.
I dont know about xForms and/or PDF forms and how they would work with
GWT. We chose GWT because of the power it gives you to write a desktop
like application.

Also the CSS styles cannot be static. I have a web designer who is
responsible for setting the CSS and styling the application. It would
be a travesty for me to have to ask him not to set margins and padding
and borders (especially borders) just because the application cannot
size itself correctly.

Also I hear you about fixing the size of the app. I dont think it
would fly so we have indeed labored to ensure that whatever the user
does to resize the app, the containers and widgets inside them do
resize correctly to fit.

As for quirks mode, no I dont specifially need quirks mode but I have
run into some more problems when I removed the quirks mode. Maybe
someday we will move to standards mode when IE (6 7,8 and newer)
interpret standards mode correctly without hassles.

Maybe a quick peek at the application my help you see what I am
dealing with.

Logon to the application here :


http://progeny-fiat.raidel.net/

userid: guest
password: guest

Comments are welcome if you still thin xForms and/or PDS forms or even
fixing the app window size would fly (I tend to think not)

Thanks,

Melody

[Ian Bambury]

Shurley shome mishtake?

 

http://progeny-fiat.raideil.net

2008/7/11 melody <mped...@stuart.iit.edu>:

Stuff the environment - Print this email
_______________________________________

[Ian Bambury]

And the login failed for me

[melody]

Sorry my bad. The password is try12345 and not guest.

Thanks.

[Ian Bambury]

Can't get that to work either.

 

But the second time you fail to log in (using anything), it shows you a screen albeit with loads of little popups telling you "Operation Cancelled : Invalid userid or password specified"

2008/7/11 melody <mped...@stuart.iit.edu>:

Sorry my bad. The password is try12345 and not guest.

Thanks.

[melody]

Sorry instead of typing the username and password, just click on the
log. It will fill in the username and password for you

[melody]

> just click on the log.

I meant on the LOGO. Sorry again for causing so much trouble while
asking for help. Thanks for you Patience and willingness to help.

[gregor]

Hi Melody,

I can see your UI now, which as you say is big help understanding
where you are coming from.

> Also the CSS styles cannot be static. I have a web designer who is
> responsible for setting the CSS and styling the application. It would
> be a travesty for me to have to ask him not to set margins and padding
> and borders (especially borders) just because the application cannot
> size itself correctly.

I think you should reconsider this view. Unlike the old JSP/Struts
situation where there was a pretty good division of responsibility
between "java programmers" and "web page designers" in GWT there isn't
really. I think it is fine for your web designer to for example knock
up HTML prototypes of the desired UI layout, but after that I think
you should work together within GWT on how to implement it (and don't
give up!). I just don't think it's viable for your web designer to
change e.g. CSS properties independently and expect your GWT code to
accommodate it just like that.

I can see exactly why you want to grab the CSS padding/margin/border
settings programmatically for resizing algorithms. I tried to do this
too originally but I couldn't find a way to do it either, so where I
needed to know the size of these decorations, I used constants to
reflect the CSS values. Because I hated copying values like this, I
got very niggardly about it, and this led to me working out how to
reduce and simplify the algorithms necessary to resize the UI and get
the right fit across the browsers. I got rid of most of them in the
end.

> Also I hear you about fixing the size of the app. I dont think it
> would fly so we have indeed labored to ensure that whatever the user
> does to resize the app, the containers and widgets inside them do
> resize correctly to fit.

Bear in mind that once you get the thing right (which may take a bit
of experimentation) you will probably find a) you can certainly do
what you want and b) it will probably be simpler than you fear it will
be at the moment. Don't give up.

> As for quirks mode, no I dont specifially need quirks mode but I have
> run into some more problems when I removed the quirks mode. Maybe
> someday we will move to standards mode when IE (6 7,8 and newer)
> interpret standards mode correctly without hassles.

I think stick with quirks mode - I've just been looking at a
discussion over on the contributors group about strict mode issues,
and it seems to be a nightmare. I don't think it's a way forward for
you here.

> Maybe a quick peek at the application my help you see what I am
> dealing with.
>

Yep, I think you may have fallen into something like the same traps I
did last autumn doing something similar. Basically I didn't realize a)
that getting widgets to size up correctly is not straight forward, and
b) the real shocker, that the browsers didn't behave the same way
doing it.

What I do now, having been severely bitten on the backside myself by
this, is to follow this procedure:

1) Design the principle layout components up front. I use pencil,
paper and rubber, but HTML editors are good for this too. By this I
mean a primary container for the layout (say a DockPanel) and the the
main secondary components (e.g. a header for tool bars/menus/logos
etc), a navigation section, a main data display panel, and a footer).
2) Especially identify any a) Horizontal/VerticalSplitPanels,
StackPanels and internal ScrollPanels needed as these are the most
difficult to get right
3) Build a main Composite class based on, say, DockPanel, that will
manage the main secondary components.
4) Build a set of secondary Composites for the main UI elements that
will act primarily as containers for the real widgets.
5) Build a set of test widgets to mock up what will eventually be used
- by this I mean things like an example Tree, a Table, a StackPanel
etc.
6) Work on the styling of this framework to get the look I want
7) Test this framework extensively against all browsers for resizing
and styling problems until it's right.

I find that if these secondary components are managed within the
primary container, a single sizing method can manage all of them
mostly driven from a resize listener.Once you have this main resizing
method working correctly so all the main "container boxes" look and
resize right, most widgets can be coaxed into filling their containers
properly on the basis of simple percentage widths and heights.

The exception is ScrollPanels. For example in your app you seem to
have a navigation tree top left, and you have a set of navigation
buttons bottom left. So if the tree gets big I assume you will want to
put it in a ScrolPanel so that the buttons don't scroll off the bottom
of the screen. AFAIK you have to give ScrollPanels a straight pixel
value for height (width is OK percentage-wise though) so in this case
you would need to cascade a ScrollPanel.setHeight(..) instruction from
the main resizing method to get the Tree to scroll properly within
it's alloted container.

Also I note you haven't used Horizontal/VerticalSplitPanels: if there
is any danger of you wanting to introduce some of these then I think
you should do so now rather than later. They take some controlling
because they have their own internal ScrollPanels which you often want
to override.

Anyway, to continue my story, I got myself into a hell of a mess over
this. My code was all over the place as a disparately tried to get the
thing to resize properly but once I found that fixing one problem
caused another problem to pop up (sort of "whack-a-rat" style) I
stopped and decided to cut my losses and start over a new iteration as
I described above. In fact it only took me about two days to get the
outer framework working right across the browsers, and I found I could
reuse most of what I had written before for the trees, tabs, tables
etc and just slot it in. In the end I had a working app that looked
much better, had about 25% less code that was _much_ more readable.

Actually to be a bit more precise about this, what I did was to start
a new project to figure out how to get the main framework to resize
properly with the intention of refactoring the lessons learned back
into the original project (to get round the "whack-a-rat" problem).
However I was so pleased with the structure of the new code I that I
did it the other way round.

Anyway, I hope these ramblings are of some help. Remember Martin
Fowler's first law of refactoring: where it is clear that a system
would benefit from refactoring, and there is a danger management won't
agree to it, don't tell them.

regards
gregor

[melody]

Perhaps someone from GWT can weigh in and let us know what the best
practice should be. Anytime I spend time doing something where I need
to descend to JavaScript, I always pause and ask myself if I am so
smart that I am the only person who could ever want to know this, or
if I am so stupid that I am the only person who doesnt know how to do
something using a well know best practice. But I think there is a
middle ground, and that is you can be average and still run into a use
case that the API providers did not think about.

I just wanna know what GWT designers think about the marriage between
GWT and CSS, its effect on sizing, taking into account the CSS box-
sizing property and if indeed they should try in the future (if
nothing has been done already) to abstract CSS (I know there is
always DOm.setStyleAttribute but we know its far from adequate) styles
from GWT programmers just like they have done with JavaScript. We all
know that a lot the problems in web apps emanate from differences in
browsers's treatment of CSS.

Why not have a GWTCSS file that has GWT styles that can be converted
to either standard CSS or browser specific CSS styles where there are
differences.

I say this as someone who loves and thinks GWT is the holy grail of
Ajax programming. I also say that because I have seen excellent
technologies that have failed at the margins because some small detail
was not paid attention to. We all know about Java APplets power they
gave a web developer (well Java Developer). You can do anything you
want in a Java Applet but the web is full of many more Flash
applications today not because flash is any better than Applets. They
just have a much better depolyment mechnisam for the Flash plugin. We
know how applets ceded their otherwise well earned place in the
internet revolution because of (1) deployment problems plagued by JRE
size and difficulty to install (2) inability to interact with the
browser DOM and with otherw browser internals (3) and a few other
issues.

I just dont wanna see GWT fall into the same traps and be doomed
because of a) failure to anticipate the frustration developers face
because of CSS problems and (b) lack of a coherent graphics API, all
things that can be considered to be at the margins.

[Jeff Chimene]

Melody,

This app appears designed for a select group of customers, or is it open to anyone on the Interwebs w/ a browser and credit card?

I'm asking because it's not clear the advantage of time spent developing a browser agnostic app.

-30-

[melody]

It is for a specific market but we cannot predict what browser the
users are going to use. They may use it on an Intranet or over the
Internet.

[Peter Blazejewicz]

hi gregor,


On Jul 12, 2:58 pm, gregor <greg.power...@googlemail.com> wrote:
> I think stick with quirksmode- I've just been looking at a

> discussion over on the contributors group aboutstrictmodeissues,
> and it seems to be a nightmare. I don't think it's a way forward for
> you here.

oh yes, there is already white flag waving on subject:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/2cdd89f9eeed6020#
However as you pointed there is nothing that can stops from using
strict mode wisely in GWT,

regards,
Peter

[Brandon Donnelson]

getStyleProperty worked good for me.

Thanks,

Brandon