CSS namespaces
Locked
 
|
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 |
|
|
I agree that it would be helpful if pier css were more constrained.
For example, I wanted to apply my own css to a wiki-generated table. But doing so messed with all the tables that pier uses (like for edit forms). I went ahead with my css ('cause it was end-user facing) but I'd rather that the css didn't clash. David ---- 1 Squeak/Seaside/Pier site deployed On Feb 28, 2009, at 9:59 AM, 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 _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
In reply to this post by NorbertHartl
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? Cheers, Doru 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 |
|
|
On Sat, 2009-02-28 at 20:25 +0100, Tudor Girba wrote:
> 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? 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. Btw. some trivial things to note: If you try to remove the css in "edit design" completely you get an MessageNotUnderstood: UndefinedObject>>asByteArray And you have to make sure that SULibrary is added before PRJavascriptSupport. 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 |
|
|
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. Cheers, Doru > 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 |
|
|
On Sun, 2009-03-01 at 16:37 +0100, Tudor Girba wrote:
> 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. We have a layout that displays green header that spawns the whole browser width. In the header there is from left to right: a logo, navigation links, an orange box and a search field. As soon as I include the blueprint stuff the header gets a vertical offset (there is white space between the browser top and the header). The logo and navigation links are displayed correct but the orange box and search field are displayed below the header. So I'm not sure if blueprint does some global stuff that interferes our layout. And I don't know what can be the cause of this. > > 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. > stuff and the css as well. I checked with the current markup we produce in the standalone application. Beside the css classes pier puts in the body element it is the same. Only the existance of blueprint changes the effect. But I think I have to boil this down myself. > > > 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. > Event.observe(window, "load", function() { So I get an Event.observe is not a function if the SULibrary is not preceeding the PRJavascriptSupport in the application settings. Norbert > > > 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 _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
> Well, line 1 of PRJavascriptSupport>>pierJs says
> > Event.observe(window, "load", function() { > > So I get an Event.observe is not a function if the SULibrary is > not preceeding the PRJavascriptSupport in the application settings. Load the latest version of Pier-Seaside and Pier-EditorEnh, they do not depend on the Prototype and script.aculo.us JavaScript libraries anymore. The only thing that requires SULibrary is the autocompleted search widget. If you don't use it, you don't need to include those large libraries anymore. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
In reply to this post by Tudor Girba-3
On Sun, 2009-03-01 at 16:37 +0100, Tudor Girba wrote:
> 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. > I think I found the cause of the problem. It has to do with the precedence of css selectors. We had some styles like * { margin: 0px; } 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; } I find this too general. But thanks for your help, Norbert _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
> > 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; > } > Keith _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
You can always edit blueprint.css in the image. I changed mine to 1.25em
On Sun, Mar 1, 2009 at 12:39 PM, Keith Hodges <[hidden email]> wrote:
_______________________________________________ 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 On 1 Mar 2009, at 18:57, John M wrote: > You can always edit blueprint.css in the image. I changed mine to > 1.25em > > On Sun, Mar 1, 2009 at 12:39 PM, Keith Hodges <[hidden email] > > wrote: > > > > > 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 > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "Sometimes the best solution is not the best solution." _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
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 <[hidden email]> wrote: Hi, _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
John M wrote:
> 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 > I am using the content with style framework myself. Keith _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
In reply to this post by John McKeon
Thanks for the feedback.
I am happy that you found the talk useful. My problem with it is that it is too long. I now added it here: http://www.piercms.com/doc/screencasts Cheers, Doru On 1 Mar 2009, at 20:31, John M wrote: > 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 <[hidden email]> > 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 -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower." _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |