| Author |
 Topic  |
|
RDoGG™
Junior Member
USA
329 Posts |
 Posted - 18 August 2001 : 15:28:39
|
this is the weirdest thing:
it is under: <span class='category'>
and i want a regular category color (by default, mintcream) instead of the regular link color (by default, darkblue/navy)
RDoGG™ |
 |
|
|
Morpheus73
Average Member
Denmark
597 Posts |
Posted - 18 August 2001 : 15:37:10
|
TOP MOD, WM!
Is it being discussed with the DEV team to release as intergrated to the next version of snitz release? - when bugfixing and tweaking of this mod is done it might as well, then we´ll have a internationalized/CSS version ready soon (and then membershipsystem/usergroups) can be initialized 
Morpheus73 - morpheus73@hotmail.com |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 18 August 2001 : 16:06:10
|
RDoGG™
When you say you want a regular category color, are you referring to the links for the category name? What you may have to do is create a class for the category link and add that to the href code in whichever files that appears in. It'll probably only be a couple.
This <span class='category'> may enclose the href code, but it would be best to add the class directly to the href to ensure it's exactly what you want it to be.
Morpheus73
Thank you! To answer your question, no there hasn't been any discussions with the DEV team to release this.
I'm sure they would have their own preferences as to the names of the classes and all, but that can be changed in the data file and the external stylesheet. The script is merely a tool which will allow for a quick conversion of the asp files. It'll save a lot of time from having a programmer comb through all the files and manually convert font tags and table backgrounds to classes. The script could be run to do the bulk of it and then a programmer could go back in and fine-tune wherever needed. There's cases where there are <p><font> combinations which will be converted to <p><span class="xxxx">. There's nothing wrong with this, however the class could be moved to the <p> tag and the <span> tag removed.
|
|
|
|
Morpheus73
Average Member
Denmark
597 Posts |
Posted - 18 August 2001 : 16:32:15
|
Someone from DEV group of CSS - please share your views
Morpheus73 - morpheus73@hotmail.com |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 18 August 2001 : 17:13:24
|
Is there a DEV group for CSS?
Edited by - work mule on 18 August 2001 17:13:56 |
|
|
|
Morpheus73
Average Member
Denmark
597 Posts |
Posted - 18 August 2001 : 17:24:25
|
There should be by now ... else I think maybe you should be moderator of this DEV group if you want to, WM.
mph73
Morpheus73 - morpheus73@hotmail.com |
|
|
|
gor
Retired Admin
Netherlands
5511 Posts |
Posted - 18 August 2001 : 18:37:11
|
Work Mule,
Reading through this topic the MOD looks great! 
Is it really that easy ? so then this should work on Version 3.3.03 once it is released and even on the Version 4.0b1 that we have ?
This looks like the way to keep all happy and eliminate any discussion.
Because we could, i.e. release a Version 4.1 CSS and one without, put them both out there and then we have two choices:
Either keep using the current code and always also release a converted version, or drop the codeversion with the color tags and only use the CSS version.
BTW, you are right that this is not the place to discuss CSS, it is the place to discuss your mod.
Am looking forward to testing this once I get the time (after V3.3.03).
Pierre
Join a Snitz Mailinglist |
|
|
|
Morpheus73
Average Member
Denmark
597 Posts |
Posted - 18 August 2001 : 18:59:56
|
using the css is definately cool if you run subforums ... this way u could have a lot of forums completely different look but same DB - COOL!
Morpheus73 - morpheus73@hotmail.com |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 19 August 2001 : 01:18:29
|
gor, in answer to your question, yes it's that easy.
It'll work on any version, at any time. In the current download file, there's a copy of the v3.3sr2 code that's been converted to CSS.
However...there have to be some standards. So far, except with the v3.3 release, the code for building the font tag has been consistantly on one line. Now with v3.3 what I've found is cases where the code for the font tag is found on multiple lines.
Example:
response.write ("<font face=""" & strDefaultFontFace & """" &_
" size=""" & strFooterFontSize & """>")
The problem lies in that the script is looking for a string to match on. When it's all together there's no problem. When it's broken up, it's harder to identify. With Perl I can easily match the above line, even with a newline. However if someone used spaces for indenting the second line versus tabs, then the possible string variations start adding up.
If you look through the datafile, you'll see how many different combinations can be found for what should be the standard category text, default text, header text, etc. So far, I've accounted for the vast majority in that data file. I even updated the file for the most recent release. However there were some weird combinations and I interpreted them as one thing and maybe they were meant as something else. There were also cases of color spelled as colour, alignment tags inside font tags, duplicate attributes within the same tag and more.
To sum the past couple of paragraphs, consistancy in the use of font tags should be encouraged.
Getting back to your post, yes you could release a regular version and a CSS version. Like I said, I maintain my main development version with font tags. Once I'm ready to update the production version, I run the script, which only takes seconds, and then I have a CSS copy ready to push to the production server.
An argument for both versions is that there are still people who probably would be resistant to CSS or maybe there's some remote possibility that someone wants some weird color/font combination that doesn't work in CSS - I'm not sure if that would be true, but who knows?
One drawback with maintaining two versions is for people doing mods or changes. If someone downloads the CSS version and want's to integrate non-CSS mods, the mod code could be converted (with the script) prior to adding. But now you may have people discussing some of the markup code in either a CSS or non-CSS environment. Possibility for confusion?
There's also an opportunity for some optimization for a full CSS version. If CSS were to be truly adopted, then there may be no need for color/font info stored in the config.asp file. The only place it would be required is the external stylesheet. So then does the information need to be placed into application variables or if the stylesheet gets cached and only referenced once per session, then direct db access may be an option. These are just a few things to consider.
Also, I haven't accounted for the forum admin changing font sizes. In the stylesheet I have three variables at the beginning for sizes. I've hardcoded the sizes to the variables. For example the default size is 12. The entire stylesheet uses px. Now the admin side could allow the admin to select the number size and then the unit in a separate dropdown - px, pt, etc. These could be used when the external stylesheet is built.
|
|
|
|
bjlt
Senior Member
1144 Posts |
Posted - 19 August 2001 : 02:31:11
|
px looks good on the screen but would be farely small when printed.
|
|
|
|
gor
Retired Admin
Netherlands
5511 Posts |
Posted - 19 August 2001 : 04:32:08
|
quote:
However...there have to be some standards. So far, except with the v3.3 release, the code for building the font tag has been consistantly on one line. Now with v3.3 what I've found is cases where the code for the font tag is found on multiple lines.
Example:
response.write ("<font face=""" & strDefaultFontFace & """" &_
" size=""" & strFooterFontSize & """>")
hmm...here goes my remark about not supporting MODS....if you post a topic in the BUGS forum with files and line-numbers I'll change them.
quote:
The problem lies in that the script is looking for a string to match on. When it's all together there's no problem. When it's broken up, it's harder to identify. With Perl I can easily match the above line, even with a newline. However if someone used spaces for indenting the second line versus tabs, then the possible string variations start adding up.
The good news then is that you can support variations in case we don't get them all out. Don't think it is too much to ask as design standard.
quote:
To sum the past couple of paragraphs, consistancy in the use of font tags should be encouraged.
Agreed
quote:
One drawback with maintaining two versions is for people doing mods or changes. If someone downloads the CSS version and want's to integrate non-CSS mods, the mod code could be converted (with the script) prior to adding. But now you may have people discussing some of the markup code in either a CSS or non-CSS environment. Possibility for confusion?
Correct, that is not something we would want.
quote:
There's also an opportunity for some optimization for a full CSS version. If CSS were to be truly adopted, then there may be no need for color/font info stored in the config.asp file. The only place it would be required is the external stylesheet. So then does the information need to be placed into application variables or if the stylesheet gets cached and only referenced once per session, then direct db access may be an option. These are just a few things to consider.
Also, I haven't accounted for the forum admin changing font sizes. In the stylesheet I have three variables at the beginning for sizes. I've hardcoded the sizes to the variables. For example the default size is 12. The entire stylesheet uses px. Now the admin side could allow the admin to select the number size and then the unit in a separate dropdown - px, pt, etc. These could be used when the external stylesheet is built.
Without having looked at the code: isn't it possible to use an inline stylesheet which actually is nothing more than the surrounding style-code with an include (an asp page) in it.
The include than builds the stylesheet using the variables stored in the application variables, which get updated like they are now ?
Pierre
Join a Snitz Mailinglist |
|
|
|
SalmanKhana
Average Member
USA
961 Posts |
Posted - 19 August 2001 : 04:48:21
|
work mule, unfortunately i dont know what css is  i will read about it but a small input from you would also be helpful
|
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 19 August 2001 : 05:25:03
|
quote:
The good news then is that you can support variations in case we don't get them all out. Don't think it is too much to ask as design standard.
What I usually do is run the conversion script and after it's complete, I run a search against all of the converted files for any instances of font tags. I take the results and add them to the data file and rerun it. I do this until no more font tags are found. Same process with bgcolor.
quote:
Without having looked at the code: isn't it possible to use an inline stylesheet which actually is nothing more than the surrounding style-code with an include (an asp page) in it.
The include than builds the stylesheet using the variables stored in the application variables, which get updated like they are now ?
I'm not sure if you're referring to the external css file or including the stylesheet in inc_top.asp. But either way, either is possible.
I think we're referring to the same thing, but let me explain a little bit more just in case.
Right now, inc_top.asp has a section in the <head> section for css. What I've done is removed all css code out of the <head> section and replaced it with a link to an external css file.
<link rel="stylesheet" type="text/css" href="inc_sitespecific/site_css_stylesheet.asp" title="<%=strForumTitle%> Stylesheet" />
I wanted to use asp to dynamically build it and so this file is named using the .asp file extension instead of the .css extension. For this external css stylesheet, I now build the classes with asp:
".default {font-size: " & strCSS_DFsize & "px; color: " & strDefaultFontColor & "; font-family: " & strDefaultFontFace & ";}" & vbCrLf &_
I use the existing application variables to assemble this file with the proper colors, fonts, etc. Right now, I'm not using the application variables for the sizes (however that could be easily changed). The reason is because the font sizes stored in the database are html sizes - 1,2,3,4,5,6 - which would have to be converted to either the equivalent in px, pt, em, etc.
Since I couldn't use the size stored in the database, I chose to hardcode the sizes in like this:
strCSS_DFsize = 12
strCSS_HDsize = 12
strCSS_FTsize = 10
If someone wanted to use pt vs. px, then all they would have to do is a find/replace on "px;" for "pt;".
|
|
|
|
gor
Retired Admin
Netherlands
5511 Posts |
Posted - 19 August 2001 : 05:40:04
|
quote:
Right now, I'm not using the application variables for the sizes (however that could be easily changed). The reason is because the font sizes stored in the database are html sizes - 1,2,3,4,5,6 - which would have to be converted to either the equivalent in px, pt, em, etc.
Since I couldn't use the size stored in the database, I chose to hardcode the sizes in like this:
strCSS_DFsize = 12
strCSS_HDsize = 12
strCSS_FTsize = 10
If someone wanted to use pt vs. px, then all they would have to do is a find/replace on "px;" for "pt;".
With the CONFIG_NEW adding variables is easy.
In fact, just making sure they are being loaded in config.asp and adding them to the admin-screen is all you need.
Version 3.3.03 will have a function in inc_functions.asp that can do one out of three things:
1) if the config-variable isn't in CONFiG_NEW then it gets added
2a) if it is there it gets updated
2b) you can also decide to leave it unchanged if it allready is there (neat for install and upgrade work where you don't want the existing value to be overwritten with the default one, but you do want to add it if it didn't exist yet).
So you could easely store those in the database also (so including the choice for px and pt), just think of some nice variable names and you are set.
Pierre
Join a Snitz Mailinglist |
|
|
|
itsme_rick
Starting Member
USA
14 Posts |
Posted - 20 August 2001 : 23:21:12
|
Hey I would just love to se this work out guys.
I have all of our new website going online next month is all done with css. maybe some day, can use nothing but css instead of tables like we still do, even in layers. I think its more of old habits more than anything, besides standards so much. css is taking off reall well i think, more and more users are using it. I just love it with Dreamweaver and Ultradev. Topstyle for major tweaking.
I am new to asp, a few months now, so still in the learning mode for this asp and a great looking forum for our reps and users.
At present I am using the huw build 33.09 I think, went well, have trouble at times, keep loosing mods some how, so have to to figure out why, the PM is still giving me trouble. Trying to customize these forums to blend better with our websites is very hard, besides just the colors, which are the main thing.
On the idea of using db variables seems the way to go for hard coding, pretty much the way its done now, but css would be a lot easier and maybe could almost handle the entire forum at some point, so please go for it, need help, just yell, will beta to death.
back to fixing this huw build....egypt huh...
Best Regards,
Rick Parker
IT Manager |
|
|
|
Topic |
|
|
|
Topic Locked
