RE: [Rainbowportal-devel] How to support Module specific .css styles
Brought to you by:
danijel_kecman,
manudea
Menu
▾
▴
RE: [Rainbowportal-devel] How to support Module specific .css styles
|
From: Jeremy E. <es...@ma...> - 2003-04-28 15:11:20
|
Bradbury Software's TopStyle Pro will do it. http://www.bradsoft.com/topstyle/index.asp Jes1111 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Cory Isakson Sent: 28 April 2003 15:44 To: rai...@li... Subject: RE: [Rainbowportal-devel] How to support Module specific .css styles One of the first things I attempted to do in my own IBS variation before Rainbow was to solve try and solve this very problem. I never did have a "great" solution, but what I was working toward was a dynamic style sheet that was rendered with each page. I prefer the methods that have been discussed here. One of the things I was looking for and have still never found is a good CSS editor that runs in the browser. I would like to be able to define styles for modules and tabs from a browser based style builder. Has anyone ever seen anything like that? It would be great to see the styles applied as you select them and save them into a style library. Cory Jeremy Esland <es...@ma...> wrote: I agree with you that this is a problem that needs taking care of. Currently the usage of CSS in Rainbow is somewhat disjointed and inefficient. Most certainly, this will be addressed when the overall Layout/Them area is updated, as has been discussed. But in the meantime we must be careful not to introduce any "temporary" solution that may compromise or complicate backward compatibility. In the long term, the solution lies in the proper usage of two CSS "features". Firstly, a page sent to a browser can specify multiple stylesheets: there is no need to merge them. Secondly, the inheritance rules of CSS provide a full override mechanism at multiple levels. Thus if a module appears on a page, it would be a trivial matter to add its CSS stylesheet to the end of a list which is then injected into the HEAD section of the page. That stylesheet could specify attributes for, and therefore override, any identically-named tags in stylesheets above it in the list. Furthermore, that stylesheet could introduce "instance-specific" variations to existing tags without affecting other elements using the same tags on the same page (by using contextual constructions). And even then, the style applied to an element can be overridden by adding CSS attributes to the element itself, i.e. within the module code. The big problem, as I see it, is maintaining the "one click to change the whole site" capability. In my opinion this is a triviality anyway, but it could be kept if the module-level CSS confines itself to adding or re-specifying spacing/positioning attributes, i.e. the font/size/color attributes are specified higher up the tree. All of this will be addressed in a future release (I don't dare say which release!). If someone needs to introduce new solutions ahead of that, I'd be very pleased to discuss specific techniques. Jes1111 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Mark McFarlane Sent: 28 April 2003 14:01 To: rai...@li... Cc: Mark McFarlane Subject: [Rainbowportal-devel] How to support Module specific .css styles The IBS default.css included a couple of module-specific styles. In designing the discussion module I followed this lead and added 4 new styles. Bad choice ! The fundamental problem with this is that every time a new module introduces new styles they need to be added to ALL existing themes for on-the-fly 'theme switching' to work well. This is a big enough nuisance for Rainbow core developers, but an even bigger problem for external module writers. So what do we do? Option 1: Each Module ships with Module.css that is dynamically #included to the current theme's style sheet: - disadvantage is that there is only one Module.css so it might not look right under different themes, and there is a performance hit Option 2: Strongly discourage modules writers from using custom styles :), make them explain in their readme-help file how to use their styles. Option 3: Have the ModuleInstall routine copy-insert the module's custom styles into all existing themes. This breaks down when you add a new theme later. Your Option? I'm leaning toward option 2, discourage custom module styles, and then insisting that we add a few more base styles to all of our themes, at a minimum TR, and TD ! Mark Cory Isakson Online Status: <http://www.lifelesspeople.com:4000/message/msn/cis...@ya...> Online Status Indicator <aim:goim?screenname=cwisakson> _____ 3.9 Cents/min. No Fees or Minimums! http://www.dial4life.com <http://ld.net/?dial4life> _____ _____ Do you Yahoo!? The New <http://us.rd.yahoo.com/search/mailsig/*http:/search.yahoo.com> Yahoo! Search - Faster. Easier. Bingo. |