Bug in the category/column HTML when 2 categories only on Home Page.

<DL><DT></DT><DD></DD></DL>
second category doesn't show unless mouse over and then disappears if mouse over any other hyperlinks.

Missing </DL> ?

It is OK with more than 2 categories.

grr, damn ie. Another css bug to add to my list :(

Adrian

with as few bugs as this, you've done remarkably well!

Another template problem- sorry!

when include_sidebar.html has more content than main content- ie: side bar is longer on screen; main 'shadow' box often displays wrongly.

example... bookmark template

Additionally there are issues wrt left shadow bar in IE when something is included in the sidebar.html ... the left shadow never displays on login screen. What u have mentioned is already an issue. It's a tough balancing act between the content area and the sidebar.

Thanks
HyTC
==================================
Mail Me If Contacting Privately Is That Necessary.
==================================

There's no doubt it is difficult- I completely messed up the custom.css and had to start again last night.

Yup, this is a known css issue that I need to work out :(

Adrian

copy core.css to custom.css
change one thing at a time and then preview the whole site to see if things are not awkwardly displayed.

wrt that left shadowbar disappearing on login screen when something is included in the sidenavigation, i just played with a commented out interesting remark in core.css. That got the shadowbar back in ie and nothing went wrong in firefox., though if seen with a maginufying glass one can see slight mismatch on the right top and bottm curve sections... but that's with a magnifying glass ...

I know nothing of css. When i know nothing then i follow the above rule :). Barring few limitations, luna looks neat.

Thanks
HyTC
==================================
Mail Me If Contacting Privately Is That Necessary.
==================================

Please don't do that. That defeats the whole purpose of having a custom.css file. You should only put the necessary overridden styles in custom.css so that you will get any changes made in future updates to core.css. If you edit core.css, don't leave your changes in there - you'll just lose the change the next upgrade.

Adrian

I've found the best way to work is my having a copy of the core.css & custom.css on my own computer & then take the source code off the dynamic home page.

Change the css links at the top of the page to match your computer & then you can work on the custom.css by editing both it and the home page source code off-line. Obviously this may then bring up some issues for other pages but it is a way to get the main work done.

Suggestion:
The custom.css file is renamed templateset.css . and called by
<link type="text/css" rel="stylesheet" media="screen" href="<%config.db_static_url%>/<%t%>.css" />

with the core.css being called by
<link type="text/css" rel="stylesheet" media="screen" href="<%config.db_static_url%>/core.css" />

This would make it less likely that the wrong custom style sheet would be edited for each template set. All style sheets could be stored in the one directory.

The reason for the core and custom to be in the template directory, is that each template set might be completely different.

To prevent accidental crashes, it might be a good idea to have a "default" css in the /static directory, but to then name the template CSS to

core_<%t%>.css and custom_<%t%>.css within those template directories.

Since they are only called in the common_head file, it's not a real issue, but it can prevent accidental corruption or overwriting the wrong css file, which could be disasterous.

So, there would be 3 css files. A "default" css, to prevent any real issues. Based on the luna/default set is ok, or even a new .css that presents it all in a simple clean interface.

Then, load the core (template default) css:

<link type="text/css" rel="stylesheet" media="screen" href="<%config.db_static_url%>/<%t%>/core_<%t%>.css" />

and then the custom template css:

<link type="text/css" rel="stylesheet" media="screen" href="<%config.db_static_url%>/<%t%>/custom_<%t%>.css" />

These files should also be part of any backup, since they can take a whole site down if they are missing or corrupt. That is the real problem with css.

And, mixing css with php could lead to disaster.... putting so much into a template. But that's another issue.



Time to do this is NOW... before the release is set in stone. This is only a change to 1 file, and the file names, and can prevent a lot of grief later.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

I can see what you are meaning here.

When I setup the paths/URLs I changed the db_static_url path & image path outside of the .cgi-bin. Presumably if I'd left the .css paths as they were, I would have been able to edit the style sheets through the template editor?

To explain what I'm trying to do-

I will have 5 installations (1 with 11 different template sets" with a unified design but the templates themselves will be different. My intention is to have all sites using the same core.css & then using the templateset.css.

My concern is that if I have all the custom.css labelled the same, and stored in different directories, I'll accidentally ftp the file into the wrong directory. If all templateset.css are stored in the one directory with different names, then I should not make this error.

I live in a remote area and depend on a slow connection ( what is broadband?) so editing on my own computer and then uploading the files is the only option open to me.

Perhaps this is too much of a change for the standard setup, and one I will have to implement myself. I'm not sure how many other people would find the change I suggested useful- particularly if the .css files can normally be edited through the template editor.

The problem with moving them out of static/luna is that there's luna specific paths in the css file. In your case, the best solution would be to leave core.css as is, and just change include_common_head.html to use <%config.db_static_url%>/<%t%>.css and <%config.db_static_url%>/luna/core.css. That way you'll get the changes in the core.css file on upgrades, and your custom changes won't be as confusing.

Adrian

Adrian,

Did you look at my suggestion, to plan for future upgrades/expansion, and to prevent major problems in dealing with multiple template sets.

the three level , NAMED .css files would prevent any problems in the future.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Yes, I think you are right here.

Thanks

Hi.

Question.
If there are too many places to override then:

Remove the core.css path altogether from the header and just operate with custom.css (copied and edited version of core.css). Yes on upgrades, one can compare and see the changes coming in (as i always have the pre-upgrade core.css in form of unedited variables in custom.css). With a copied core-->custom.css i also have the original core.css effectively to compare with the new core.css which comes with the upgrade. if it's a core+custom.css combination, then post upgrade, there is nothing available to see what was their in pre upgrade core.css I could be wrong, but just my opinion as when it's an online upgrade, i wouldn't bother downloading the tgz to local disk (unless it becomes mandatory to do so when versions are changing as i am not clear on what happens with update feature with version change)

Additionally from performance point of view if core+custom = 13+5 =18K
Wouldn't it be better just to have 13K of custom.css and remove core.css from the header altogether. Otherwise everytime one hits ctrl+f5 one would have 18 K of css there as compared to only 13K

Thanks
HyTC
==================================
Mail Me If Contacting Privately Is That Necessary.
==================================

I think you are missing the point of the cascading style sheets.

the idea is to have a "default" basis for the templates, but allow overridding of those styles locally.l

To do that, you need to *always* load your defaults, and most sites are now suggesting to put in *all* defaults for all tags, rather than assume any.

Once you load the defaults, you then override them with the custom .css.

You can also override them in any subdiredtory, or category template set, by simply requesting the load of the new custom css


You have to trade off a bit of download/bandwidth, for loading the custom .css, in order to get it all out of each and every template you download.

In the net long run, it's a lot less bandwidth.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Unless i am missing something (which apparently doesn't look like as i have the test install functional on all fronts with core.css commented out in the header and just taking only custom.css)

custom.css =core.css (with overriding in relevant sections) keeping the .css download to almost same as if there was no customization. I already have all the defaults from core.css (as custom.css is just a copied over version of core.css albiet with changes done in relevant portions), it's just that i don't have core.css + custom.css but just a custom.css (core.css with changes)

Just as i said, i could be wrong. I am still trying to pick up on this. Correct me if i am wrong.

Thanks
HyTC
==================================
Mail Me If Contacting Privately Is That Necessary.
==================================

The whole point of splitting them up is to reduce the amount of diffs needed to upgrade the templates. With both a custom.css and core.css file, you can get away with not having to do the diff at all, while keeping your templates up to date. Of course this comes at the expense of an extra file load, but remember that css files are cached, so it isn't such an expensive trade off.

diffs will be generated like the template diffs we have been providing with our recent releases.

Note that we're currently looking into the different possibilities in making different styles for each template easier, so there might be some changes in how the css is laid out in the RC.

Adrian

I didn't copy core.css into custom.css- I only put the changes in custom.css and I think that is the way it is meant to work? You don't need to comment out core.css because it takes the main code from there and only the customised styles from custom.css

It makes it much easier to work with because it is a much smaller amount of code.

I think i couldn't explain.
I have custom.css (core.css with modifications, so everything that core.css carries is also there in custom.css), mainting almost the same size. core+custom in my case would be 13+5~18K. With only custom.css (which is core.css with changes) it's about the same as original ~ 13K (or perhaps less if i remove the comments as i have unused core.css to fall back on for comments if needed). My question is why have a 2 hit to webserver (with more downloads) when it can be reduced to just one whenever there is a "New Visitor" or a ctrl+f5.

Thanks
HyTC
==================================
Mail Me If Contacting Privately Is That Necessary.
==================================

Please keep this option of just dealing with *one* css file (for a given template set) open or in other words not make it compulsory to load the packaged css file a necessity.

Thanks

Thanks
HyTC
==================================
Mail Me If Contacting Privately Is That Necessary.
==================================

Yes, this is the intended way of customising your css styles.

Adrian

Your savings by merging your changes into a single file are negligible - browsers heavily cache static files like javascript and css, so on a typical session browsing one's site, the css will only be downloaded once (the rest will be just head requests checking to see if the file has changed).

The advantages (well to you, not your end users), far outweigh the bandwidth savings from combining the two files. If you combine the two files, upgrades will require more work (something we're working on reducing), since now you have to go through the css diffs. One case of this being difficult and prone to error would be if we rearranged the contents of the css file (although we'll try not to do such a thing). If you only had your changes in the custom.css, then the change wouldn't affect you - you probably won't even have to worry about looking at the css diffs.

So the difference now is 2 downloads (size of core.css + custom.css) + 2 head requests + no work during upgrades vs 1 download + 1 head request + going through diffs making sure you haven't missed anything every upgrade.

Adrian

Upgrading has never really been a cakewalk :). (Not complaining)
There are other time taking testing ativities that require admin's time (Not complaining)

luna template set ---> finally someothertemplatename set (obviously with names corected in css) --> visible to users (unaffected by upgrades) ... not sure if this would not break anything. Shouldn't AFAIK

luna (original -- with local deleted) there in working installation so that upgrade's does not complain. Post upgrade Admins would always prefer to go thru each detail before applying it to working install. In fact this would only be made readable/writebale before upgrades for some reasons.

Now if core.css is made a compulsion, then perhaps yes, there would be no option but to have a core.css + custom.css

Thanks

Thanks
HyTC
==================================
Mail Me If Contacting Privately Is That Necessary.
==================================