Brainstorming: What do we "need" template-wise?

[Don Chambers]

OK - kill the home and login link concept. Too much effort/confusion with too little return on that investment.

Moving font size to style.css is good.

What I meant by additive is this: Lets say we set size at 100.01% in the body, then 75% in the sidebar, then state 1.5em in the sidebar title (this is actually what exists in the purple - perhaps all - colorset. That 1.5em setting in the sidebar title is very different with the sidebar set at 75% than the same 1.5em setting would be WITHOUT the sidebar set at 75%. So, by additive, I mean that the final setting in ems for a font size is influenced by all the parent font-sizes that have been set.

[yellowled]

OK - kill the home and login link concept. Too much effort/confusion with too little return on that investment.

Exactly my point

Moving font size to style.css is good.

Actually, I'm thinking about moving them to the colorset stylesheets.

I've stumbled upon a - in my humble opinion - great concept for font-sizes which I'm using more and more. It's setting a font-size for the body using a keyword (like "small") and using percentages for everything else. I'd like to use that for bulletproof also, but of course Dave's colorsets have been constructed using a combination of percentages and em. This is also fine, but personally I prefer the other approach.

So we could use the old technique for the colorsets only and the new one for base.css/style.css.

So, by additive, I mean that the final setting in ems for a font size is influenced by all the parent font-sizes that have been set.

Yes, of course, but that's true with any technique using relative font-sizes (i.e. != pt or px). Problem is, we need the 100.01% for some weird IE reason, then the 75% for the structural elements because that makes it much easier to calculate the em values - or something like that. As I said, Dave requested this - I've never paid that much attention to font sizes

I'll see if I can work out what I've described above tonight after work. It's too hot over here right now to do anything productive during daylight time

Erm, hate to bug you, but where is that friggin' quicksearch image you wanted to shoot me?

YL

[yellowled]

So we could use the old technique for the colorsets only and the new one for base.css/style.css.

Done. I have uploaded a new zipfile. This one has only one font-size (body) in base.css and some in style.css, everything else has been moved to the colorsets stylesheets to keep Dave's colorsets intact. Check it out, maybe this will be easier. We could probably even lose the stuff I moved to the colorset stylesheets, but I didn't want to do that without checking with Dave.

Bottom line: If we have a body { font-size: small; } in base.css and lose the 100.01% and the 75% for #wrapper etc., the colorsets still look good to me. However, I don't want to remove them without a second opinion by Dave.

Erm, hate to bug you, but where is that friggin' quicksearch image you wanted to shoot me?

I only quoted that to remind you of it

YL

[d_cee]

Hi guys

you seem to have been busy busy whilst I've been on holiday!

The discussion YL and I had early on in this project about font sizes was important both from aesthetic and accessability points of view. Em sizes are great as they are scaleable for users who want larger text sizes on screen than the site designer intended to be there. But for a designer it is desirable for 1em to equal 12px. However most browsers have the text size set at 16pt as the default value. So in order to set 1em = 12px we need to reduce the font size to 75% in the body. Some designers use 76% - might be an IE6 thing but I'm not sure - and others 62.5% which sets 1em to 10px. All browsers (whether compliant or not) should then have scaleable fonts

So, I don't think this value should be set in the individual coloursets as we want the template to perform consistantly no matter what colourset is used, however, how it's set is unimportant so long as we are achieving the right result. I'm used to % and em sizing and rarely use the relatively meaningless 'small, medium, large' etc font sizing and I suspect the same is true of most designers.

Hope that all helps

cheers

Dave

[Don Chambers]

I have never been a fan of the relative "small, medium, large" etc, although "smaller" or "larger" is a little more evident that the font size is being set relative to the parent element. My original post on this font size stuff was to merely point out that em's appear to be "relative" to whatever has been set by the parent elements (ie, the percentage values). I do, however, see value in using ems from the accessibility perspective Dave mentioned. Here is a better explanation than I could ever come up with: http://www.w3.org/TR/REC-CSS2/syndata.html#length-units

Anyway, I don't personally care if these things are set in the colorsheets, base, or style.css. I think some of this was initially set in style.css so the blank style was somewhat useable. I'm going to defer to whatever you 2 decide.

HOWEVER, as long as we are talking about sizes of things, I think there is something that can be cleaned up a bit in the banner. Unless YL changed anything recently, this is what we have in style.css:

Code: Select all

#serendipity_banner {
   margin: 0;
   padding: 0.25em;
   border-bottom: 1px solid #ddd;
   clear: both;}

/*** Header styles ***/
#serendipity_banner h1,
#serendipity_banner h2 { margin-left: 10px; }

and this is what exists in purple.css:

Code: Select all

#serendipity_banner {
   height: 126px;
   margin: 0;
   padding: 0.25em;
   border: 0px;
   background: #823995 url('img/purple_header.jpg') no-repeat;}

#serendipity_banner h1 {
   font-weight: bold;
   font-size: 1.4em;
   text-transform: uppercase;
   letter-spacing: .3em;
   padding: 0;}

#serendipity_banner h2 {
   Font-weight: normal;
   font-size: 1em;
   text-transform: uppercase;
   letter-spacing: .3em;
   padding: 0;}

We are getting some positioning slightly by accident due to the margin-left on style.css. I think this should be a bit more specific as margin: 0 0 0 10px. Next, the purple colorset defines the header as 126px tall. The actual background image is 136px tall. With my defauly FF font sizes, the banner actually expands to 133px tall. This is due to the fact that the CONTAINER has padding when it really should be applied to the h1 & h2.

When padding is zero on #serendipity_banner, set to 0.25em on the h1 & h2 (with the above mentioned change in margins) the container will be exactly as tall as specified (change to 136px?). All of this (except the height - which is specific to purple) can be set in style.css and removed completely from the colorsets. However, for esthetic reasons, Dave may want to change the margin or padding settings on the h1 & h2 as they will be positioned a bit differently than they currently exist.

So, my main points are 1) plug the missing margin settings on h1 & h2 and do NOT pad #serendipity_banner as this makes that container larger than specified.

I would probably not have noticed this except for my efforts on the admin stylesheet. I now have one that nearly perfectly emulates the frontend purple stylesheet.

Finally, did anyone ever go back through the colorsheets and make sure everything is in the same order as style/base?

[d_cee]

Hi

I'll have a look at making these changes you've suggested Don as it makes perfect sense to do it that way I'll download YL's zip later and install it on s9y-bp.

I'll also check the order of ids and classes in the coloursets, comment the style sheets and upload the latest versions to s9y-bp.

cheers

Dave

[yellowled]

Em sizes are great as they are scaleable for users who want larger text sizes on screen than the site designer intended to be there. But for a designer it is desirable for 1em to equal 12px. However most browsers have the text size set at 16pt as the default value. So in order to set 1em = 12px we need to reduce the font size to 75% in the body. Some designers use 76% - might be an IE6 thing but I'm not sure - and others 62.5% which sets 1em to 10px. All browsers (whether compliant or not) should then have scaleable fonts

Hm - maybe I'm too bad in math, but this looks like 62.5%/1em = 10px makes much more sense. In this scenario - if I got it right this time - 2em would equal 20px, 1.5em = 15px etc., right?

So, I don't think this value should be set in the individual coloursets as we want the template to perform consistantly no matter what colourset is used, however, how it's set is unimportant so long as we are achieving the right result. I'm used to % and em sizing and rarely use the relatively meaningless 'small, medium, large' etc font sizing and I suspect the same is true of most designers.

i see the point, and I also see that most people using bp would not be familiar with the new approach. So I guess this means setting it back to the %/em combination would be better. I'll get to that tomorrow.

YL

[Don Chambers]

Hang on a minute....... before YL's idea is dismissed completely, have a read here and see if it makes any difference to this decision:

http://diveintoaccessibility.org/day_26 ... sizes.html

I'm not referring to their hacks, but they do mention that this method does NOT compound as does the method we are currently using.

I'm also wondering something about accessiblity and font sizes..... is it OK to isolate SOME text as absolute, such as links? Graphically, some things become either challenging, or impossible, if the graphic has to take into consideration the possibility of the element becoming larger due to a browser text size increase.

[yellowled]

I'm not referring to their hacks, but they do mention that this method does NOT compound as does the method we are currently using.

I have to admit I have only skimmed it, but apart from that Netscape 4 hack (You're not suggesting to keep that, are you? bp does hardly care for anything below IE6 ...), it looks just like what I had in mind: Setting a font-size: small; for body and doing everything else in percentages.

I do, however, think Dave has a point: a lot of designers will probably be used to the percentage/em technique. However, if they want to use that for templates based on bp, they will know how to switch it.

The important question is: Can we get the colorsets to look decent using the keyword/percentages technique? That's Dave's call. We also have the option to use that for base/style.css and go with percentage/em for the colorsets.

I'm also wondering something about accessiblity and font sizes..... is it OK to isolate SOME text as absolute, such as links?

From an accessibility point of view: no. Accessibility doesn't care whether it looks good as long as it is scalable. Imagine a navbar with fixed font-sizes holding a login button which can not be resized. Now picture somebody extremely nearsighted trying to login ... see?

YL

[yellowled]

So, my main points are 1) plug the missing margin settings on h1 & h2 and do NOT pad #serendipity_banner as this makes that container larger than specified.

Done and included in yet another updated zipfile, which also includes the revised quicksearch.png.

I have handled the font-size stuff this way in this zipfile:
a) no font-sizes at all in base.css
b) font-size: small; for body in style.css
c) all other font-sizes in style.css still in em
d) all font-sizes in the colorsets as provided by Dave

I'd really like to keep it this way, but of course that would imply to agree on using either em or percentages for anything in c) and d) consistently. But I think this should be the version Dave should use for his revisions.

Finally, did anyone ever go back through the colorsheets and make sure everything is in the same order as style/base?

Who? Me? No

YL

[Don Chambers]

Well, percentages do, in fact, "compound" too. Sounds like the only thing that does not is the keyword method (small, x-small, etc). I've unfortunately never paid that much attention to accessibility, and therefore always used absolute pixels. Time to teach this old dog some new tricks!!! )

OK - another question. While it still needs a tiny bit of cleanup, the admin stylesheet emulating the purple colorset is done. I will change a few things once Dave finishes up his revisions to all colorsets for the padding/margin issue, but it is substantially complete.

So, you guys have a preference whether a) go with purple or b) have me create a more color neutral (mostly grey) version?

[yellowled]

So, you guys have a preference whether a) go with purple or b) have me create a more color neutral (mostly grey) version?

Why don't you give us a sneak preview on the purple version first?

YL

[Don Chambers]

So, you guys have a preference whether a) go with purple or b) have me create a more color neutral (mostly grey) version?

Why don't you give us a sneak preview on the purple version first?

YL

Let me get a few other things cleaned up, then I will send you the css file and related images..... unless you only want a screenshot. Right now, my attention is on the modification of about 2 dozen plugin files so they can support a bunch of new id's & classes I already added to the admin core files. These are not specific to BP - Garvin is committing them to 1.2.

[yellowled]

Let me get a few other things cleaned up, then I will send you the css file and related images..... unless you only want a screenshot.

I think a screenshot would suffice, especially since you should really take your time doing the admin template. It shouldn't be "release critical" anyway.

YL

[Don Chambers]

Styling the admin area is both a bit more complicated, and a bit easier, than styling the frontend. You will see that when you see the completed stylesheet.

The bigger problem is the scope of affected files. I introduced a lot of new classes to make styling certain aspects of both the front and back ends easier. Problem is that the plugins need these new id's and classes too. I did all the core files last week, and those were included in the beta4 release (problem with that release though, which will hopefully be corrected any moment by Garvin).

Earlier today, I added everything to the plugin files that hook into the admin sidebars. That was about 2 dozen file modifications. I have now identified approximately 220 files that need to be studied for potential modification (that is out of 3,800 total plugin files), and will do those next.

The final piece is identifying a half dozen or so classes that have been carried from one admin stylesheet to the next, but might have, in fact, been retired sometime in the past and no longer need to be included in any admin stylesheet. I have positively eliminated 3-4, but have about that many to still verify.... which will happen AFTER I get done with the 220 other files!!!

Wonder if the s9y developers will fly me to Germany for a few beers after this??!! hehehehe

Anyway, I'll get to a screenshot when I can, but it might be just as easy to send you guys the admin stylesheet. I'm commenting the heck out of it for all of our benefit.