While testing how hard it will be to bring my site into pier I discovered some css class clashes. For people it is quite normal to assign classes like header, footer and the like. In my opinion a cms like pier should try to step out of the way of any usage conflict. Therefor I would propose to namespace the css classes. A pr_header, pr_footer will do I think. Or do I missunderstand something completely? For me it was not possible to reconstruct our layout without haveing to remove all librares for the application. But then it is tedious to work with pier as the edit boxes and stuff are too small. What is the best approach to bring in the own developed design and having pier still functioning? thanks, Norbert _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Hi Norbert, The default look and feel is based on the blueprint css framework. This is provided via the PRBlueprintLibrary library. This framework is a generic one and it mostly provides css classes for laying out the pages into columns. It also provides some default styles for basic html tags like textarea or input which is what gets eventually used for editing pier. See the project page for more details: http://code.google.com/p/blueprintcss/ The CSS that is specific to the look and feel of the default webpage is available to you via the Edit Design command. This is where .footer and .header is defined. So, you have complete control over the look and feel without removing the libraries. The provided css features some commented to point out where the large parts out. So, all you have to replace the Pier css (or part of it) with your css in the provided area and to modify the template accordingly. Is this helpful?

On 28 Feb 2009, at 17:59, Norbert Hartl wrote: > While testing how hard it will be to bring my site > into pier I discovered some css class clashes. For > people it is quite normal to assign classes like > header, footer and the like. > > In my opinion a cms like pier should try to step > out of the way of any usage conflict. Therefor I > would propose to namespace the css classes. A > pr_header, pr_footer will do I think. > > Or do I missunderstand something completely? For me > it was not possible to reconstruct our layout without > haveing to remove all librares for the application. But > then it is tedious to work with pier as the edit boxes > and stuff are too small. > > What is the best approach to bring in the own developed > design and having pier still functioning? > > thanks, > > Norbert > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "Being happy is a matter of choice." _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Hi Norbert, My answers are inlined below. >> The default look and feel is based on the blueprint css framework. >> This is provided via the PRBlueprintLibrary library. This framework >> is >> a generic one and it mostly provides css classes for laying out the >> pages into columns. It also provides some default styles for basic >> html tags like textarea or input which is what gets eventually used >> for editing pier. See the project page for more details: >> http://code.google.com/p/blueprintcss/ >> >> The CSS that is specific to the look and feel of the default webpage >> is available to you via the Edit Design command. This is >> where .footer >> and .header is defined. So, you have complete control over the look >> and feel without removing the libraries. The provided css features >> some commented to point out where the large parts out. So, all you >> have to replace the Pier css (or part of it) with your css in the >> provided area and to modify the template accordingly. >> >> Is this helpful? > > Not really. I have to investigate this somewhat deeper. I understand > what you are trying to say. But in my case it is different. If I > have the libraries loaded and in "edit design" the css removed > completely the design of my page is broken. So there are things that > conflict. I'm not that good in css but I hope I'll be able to figure > it out. I even did a dummy component inside the page that does > updateRoot: to be sure mine is the last loaded. Hmm, then it seems I do not understand your situation. Let's try to clarify it a bit. When you say broken, what exactly do you mean? Of course that the layout and colors are not going to be the same, but the forms will still have proper dimensions, which is what seemed to have spawned the first problem.

The last to get loaded is the css in Edit Design. So, why is it not enough to add your definitions at the end of that file? Usually a css comes with an html template. In this case, you would have to also change the structure of your environment anyway, and then it would fit with your custom css definition. And as the basic functionality of Pier does not depend on the css that is in Edit Design, you should not have a problem with that.

> Btw. some trivial things to note: > > If you try to remove the css in "edit design" completely you get an > MessageNotUnderstood: UndefinedObject>>asByteArray Thanks for reporting, I added an issue here: http://code.google.com/p/pier/issues/detail?id=79 > And you have to make sure that SULibrary is added before > PRJavascriptSupport. I am not sure I understand this. Why do we have to make this sure? In fact, you do not need SULibrary at all, except for debugging seaside behavior. As for PRJavascriptSupport, Lukas has removed all dependencies to the Prototype and Scriptaculous, so this Library will not be needed either.

> Norbert > >> >> On 28 Feb 2009, at 17:59, Norbert Hartl wrote: >> >>> While testing how hard it will be to bring my site >>> into pier I discovered some css class clashes. For >>> people it is quite normal to assign classes like >>> header, footer and the like. >>> >>> In my opinion a cms like pier should try to step >>> out of the way of any usage conflict. Therefor I >>> would propose to namespace the css classes. A >>> pr_header, pr_footer will do I think. >>> >>> Or do I missunderstand something completely? For me >>> it was not possible to reconstruct our layout without >>> haveing to remove all librares for the application. But >>> then it is tedious to work with pier as the edit boxes >>> and stuff are too small. >>> >>> What is the best approach to bring in the own developed >>> design and having pier still functioning? >>> >>> thanks, >>> >>> Norbert >>> >>> >>> >>> _______________________________________________ >>> SmallWiki, Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> -- >> www.tudorgirba.com >> >> "Being happy is a matter of choice." >> >> >> >> >> _______________________________________________ >> SmallWiki, Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "Obvious things are difficult to teach." _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Hi Norbert, My answers are inlined below. >> The default look and feel is based on the blueprint css framework. >> This is provided via the PRBlueprintLibrary library. This framework >> is >> a generic one and it mostly provides css classes for laying out the >> pages into columns. It also provides some default styles for basic >> html tags like textarea or input which is what gets eventually used >> for editing pier. See the project page for more details: >> http://code.google.com/p/blueprintcss/ >> >> The CSS that is specific to the look and feel of the default webpage >> is available to you via the Edit Design command. This is >> where .footer >> and .header is defined. So, you have complete control over the look >> and feel without removing the libraries. The provided css features >> some commented to point out where the large parts out. So, all you >> have to replace the Pier css (or part of it) with your css in the >> provided area and to modify the template accordingly. >> >> Is this helpful? > > Not really. I have to investigate this somewhat deeper. I understand > what you are trying to say. But in my case it is different. If I > have the libraries loaded and in "edit design" the css removed > completely the design of my page is broken. So there are things that > conflict. I'm not that good in css but I hope I'll be able to figure > it out. I even did a dummy component inside the page that does > updateRoot: to be sure mine is the last loaded. Hmm, then it seems I do not understand your situation. Let's try to clarify it a bit. When you say broken, what exactly do you mean? Of course that the layout and colors are not going to be the same, but the forms will still have proper dimensions, which is what seemed to have spawned the first problem.

> > which is really not a good idea. Any other that does the same a little > more precise will win out. So we are the root cause of the problem. > But then I also do not understand why blueprint is defining globals, > e.g. > > body { > line-height: 1.5; > } > Blueprint is simply trying to set a common baselie between browsers Keith _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Hi, Changing the default blueprint library is not the best way. It's better to create your own library and load this after the blueprint, or directly add your definitions to the css in Pier. Like this, you can update to the latest Pier code without needing to change anything. Cheers, Doru

Good advice, thank you Doru I have also used the other two methods you mention. BTW EXCELLENT video at ESUG 2008. It made everything clear to me! I wish I would have noticed it a month ago when it was posted. Thanks also to James Robertson for providing the service. I highly recommend that you give this video prominence on the Pier site. John On Sun, Mar 1, 2009 at 2:24 PM, Tudor Girba <girba(a)iam.unibe.ch&gt; wrote: Hi, Changing the default blueprint library is not the best way. It's better to create your own library and load this after the blueprint, or directly add your definitions to the css in Pier. Like this, you can update to the latest Pier code without needing to change anything. Cheers, Doru _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki