Re: [css-d] request: a thorough going over
Felix, Sorry it took so long to reply. I had mail client problems yesterday. On 8/26/2009 10:54 AM, Felix Miata wrote: Ah, yes -- Linux... I have to admit, I cheated here, and this was a good reminder. I've got a Linux box, and I do a lot of work on it. Unfortunately, font support on Linux is pretty bad. So my solution was to install the same set of fonts I run on my Windows machines -- at which point everything looked really nice, and I forgot how much I hated it before. Installing the Windows fonts isn't much help. You don't see what Linux users without them see. True, but the standard suggestion for the better part of a decade (at least) was to install the Windows web font pack. And it's still something that comes up in Google searches, so who knows how many people are still following that advice. Now that I think about it, I don't really know what the font situation on Mac OS is, either. Should probably do a bit of looking into that. Linux font support has gotten much better in recent years. Most recent distros install DejaVu by default, and many also include Liberation. Their equivalents are: DejaVu Sans = Lucida Console = Bitstream Vera Sans DejaVu Sans = Verdana = Bitstream Vera Sans DejaVu Serif = nothing really close; larger than Georgia; size close to Verdana; (same as Bitstream Vera Serif) Liberation Mono = Lucida Console Liberation Sans = Arial/Helvetica Liberation Serif = Times New (Roman) This is great info. Thanks! You also have the option of just accepting their choice of default, or just specifying generic monospace, sans-serif, or serif. I know about specifying the generics, but how do you leverage the user choice of default? I tried bumping up the line height like you suggested, but it just created really obnoxious rivers on my system. I'm guessing this is all related to the font choice(s). If you do a lot of nesting and font size adjustment, pure number line-heights are less likely to cause trouble: http://fm.no-ip.com/auth/line-height-inherit.html That little article was fascinating. Your 252px limited links column is rather confusing at high resolution: http://fm.no-ip.com/SS/SC/sc-michve03.png How interesting. I haven't seen the site do that before (except under IE6). What tool are you using for the analysis? OTOH, the content paragraph lines are little on the long side, more like a term paper (usually double-spaced) than a book (normally single spaced with normal leading). I completely agree. I've been thinking that I probably need to go back and cut the line length down (probably 25% at least). Your comment was good incentive to go back and do that. Best, michael __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] request: a thorough going over
On 8/28/2009 3:26 PM, Felix Miata wrote: Now that I think about it, I don't really know what the font situation on Mac OS is, either. Should probably do a bit of looking into that. I did a fresh Tiger install last week, and immediately updated to 10.4.11. I installed no other software except for SeaMonkey 1.1.7 Firefox 3.5.2. This left me with 100% of the M$ web fonts installed. Was that a tyop, or are you saying that either Apple or Mozilla are including the M$ web fonts? With browsers other than IE, specifying only a generic will allow the visitor to see used whatever his defaults are set to. With IE, specifying only generics will allow the visitor to see the defaults M$ hard-coded into the browser: Courier new for monospace, Times New Roman for serif, and Arial for sans-serif. Safari (v4.0.3 at least) will use its user-selectable monospace default if the requested font(s) are not available, same as the Geckos, but when the requested serif or sans-serif fonts are not available, it will supply the user-selectable default proportional, regardless whether that default is a serif or a sans-serif, and regardless whether the requested type of font is a serif or a sans-serif. http://fm.no-ip.com/auth/Font/fonts-face-samples-cdef.html might be useful in confirming for yourself. Note too that anytime Helvetica is requested on Windows, it is treated as if the request had been for Arial, which means all the following on Windows render identically: font-family: arial, helvetica, sans-serif font-family: helvetica, arial, sans-serif font-family: helvetica, sans-serif font-family: helvetica, 'lucida sans unicode', 'trebuchet ms', sans-serif font-family: sans-serif Some of that I knew, but the rest of it was informative. What tool are you using for the analysis? My eyes? What analysis? Whatever produced that interesting looking screen-cap you posted, overlaid on my page. =] Best, michael __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] request: a thorough going over
On 8/26/2009 1:30 AM, david wrote: Nice, cool color selection. Almost made me wish for a bright color somewhere! I know what you mean about the absence of bright colors. I wrestle with that issue, but never really seem to come up with a solution that I like. Since I'm not a graphic designer, I can't create fun little bugs with which to litter the pages, but acres of raw text can get tedious no matter how well the rest of the color scheme works. If you have any suggestions... Looked at it in FF3 on Linux. The serif font against the background had me squinting until I kicked the font size up a couple of steps (the strokes of the letters are thin, the color contrast between the thin letter strokes and background is low). Increasing the line spacing to 1.3 helped quite a bit. Getting rid of the dotty (to me) background helped more. Since text is your main content, I think increasing readability of the text would be a good idea. Ah, yes -- Linux... I have to admit, I cheated here, and this was a good reminder. I've got a Linux box, and I do a lot of work on it. Unfortunately, font support on Linux is pretty bad. So my solution was to install the same set of fonts I run on my Windows machines -- at which point everything looked really nice, and I forgot how much I hated it before. I tried bumping up the line height like you suggested, but it just created really obnoxious rivers on my system. I'm guessing this is all related to the font choice(s). Re. the background... I've been looking for a suitable replacement -- something that gives a subtle texture instead of being a solid color, or something that stands out -- unfortunately, I have yet to find anything that really works. I think your comment is the first negative one I've ever gotten about it. If anything, it's so light that the problem people have is that they can't see it. I'll keep the dotty-ness in mind. Maybe this would be a contact to get some work on the ice? ;-) http://www.usap.gov/ LOL -- that's great! I'll have to keep that in mind, if I ever get back into the business. Thanks for all your comments, michael __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] request: a thorough going over
1/ I think you'll want to use an xhtml 1.0 strict, or an html 4.01 strict doctype. Someone else can tell why xhtml 1.1 is not such a good idea. If it has to do with the issue of serving the correct MIME type (i.e. application/xhtml+xml vs. text/html), I think I've got that covered. There's a bit about it on my colophon page: http://ronin-group.org/TRG_colophon#mime And if that's NOT it, or I've missed something, I'd love to be better informed. 404 Sorry. Serves me right for not cutting and pasting. http://www.ronin-group.org/TRG_colophon.html#mime __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] request: a thorough going over
On 8/26/2009 9:22 AM, David Laakso wrote: My comments below have little if anything to do with CSS. They are personal opinion... take them as such, and do with them as will... Understood. Please don't feel like I don't appreciate them. I'm purely self-taught, and there's a lot that I can learn, especially from people who do this professionally. If it has to do with the issue of serving the correct MIME type (i.e. application/xhtml+xml vs. text/html), I think I've got that covered. There's a bit about it on my colophon page: And if that's NOT it, or I've missed something, I'd love to be better informed. 404 http://www.ronin-group.org/TRG_colophon.html#mime 2/ Check your site in a 640 x 480, 800 x 600, 1024 x 768 window. Note the clipping of the stuff at the bottom of the left column in a short window. This is one of those things that I wonder about every so often. I don't really track my visitor metrics, but my conclusion wound up being that I haven't seen anyone run something as small as 800 x 600 in so long that it's just not an issue. Granted. Nevertheless, as a simple example, on a 1680/116.5dpi MacBook Pro @1024 with a full-sidebar will yield a 640 content window... I never even thought of that. Good point! 6/ Gray on gray is sometimes difficult for some users to read. Have you checked your site with a color contrast analyzer? No, I haven't. This is the first I've heard of such a creature. I'll look into them. FWIW, here's one... http://juicystudio.com/article/colour-contrast-analyser-firefox-extension.php That looks very cool. I'll have to give it a whirl. I didn't realize that the color contrast issue played into accessibility, which I have to admit, I'm vaguely aware of, but haven't paid much attention to in the site development. It's good to have a reminder. Best, michael __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] request: a thorough going over
On 8/25/2009 9:20 PM, David Laakso wrote: Generally you're doing alright. She's relatively consistent cross-browser. IE 6/7 on a cursory glance go along with your program. Same for IE/8. Opera, Safari, SeaMonkey, and FF. On a more specific level, just some random thoughts that you may, /or may not/, wish to consider... 1/ I think you'll want to use an xhtml 1.0 strict, or an html 4.01 strict doctype. Someone else can tell why xhtml 1.1 is not such a good idea. If it has to do with the issue of serving the correct MIME type (i.e. application/xhtml+xml vs. text/html), I think I've got that covered. There's a bit about it on my colophon page: http://ronin-group.org/TRG_colophon#mime And if that's NOT it, or I've missed something, I'd love to be better informed. 2/ Check your site in a 640 x 480, 800 x 600, 1024 x 768 window. Note the clipping of the stuff at the bottom of the left column in a short window. This is one of those things that I wonder about every so often. I don't really track my visitor metrics, but my conclusion wound up being that I haven't seen anyone run something as small as 800 x 600 in so long that it's just not an issue. On the other hand, if you're seeing clipping at 1024 x 768, that worries me. Was there a particular page giving you problems, or was that a general resolution comment? 3/ Should the navigation links in the left column be larger, the same size, or smaller than the primary content in the right column? Obviously, I thought they should be larger. =] This was done for a couple of reasons: 1) to increase visibility, 2) to give them a certain scale in the sidebar and not have them surrounded by white space. I don't know if these are *good* reasons, but they were the ones that drove my decision. What are the operational or aesthetic theories behind the other schools of thought? 4/ If, for whatever reason, a user might scale the fonts, do you want the navigation links to horizontally cross-over and overlap the primary content? That doesn't happen on any browser I've tested. IE6 -- though essentially irrelevant -- wraps the text as it grows bigger. IE7 and Firefox 3 both scale the width of the sidebar along with the fonts. (I tried to make sure that widths are specified in ems so that this contingency is covered.) 5/ Is it possible to code the site with fewer ids, classes, and span thingies? I'm sure it probably is. =] 6/ Gray on gray is sometimes difficult for some users to read. Have you checked your site with a color contrast analyzer? No, I haven't. This is the first I've heard of such a creature. I'll look into them. Thanks for all your suggestions and comments. I really appreciate you taking the time. michael __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] request: a thorough going over
On 8/25/2009 9:20 PM, David Laakso wrote: Generally you're doing alright. She's relatively consistent cross-browser. IE 6/7 on a cursory glance go along with your program. Same for IE/8. Opera, Safari, SeaMonkey, and FF. On a more specific level, just some random thoughts that you may, /or may not/, wish to consider... 1/ I think you'll want to use an xhtml 1.0 strict, or an html 4.01 strict doctype. Someone else can tell why xhtml 1.1 is not such a good idea. If it has to do with the issue of serving the correct MIME type (i.e. application/xhtml+xml vs. text/html), I think I've got that covered. There's a bit about it on my colophon page: http://ronin-group.org/TRG_colophon#mime And if that's NOT it, or I've missed something, I'd love to be better informed. 2/ Check your site in a 640 x 480, 800 x 600, 1024 x 768 window. Note the clipping of the stuff at the bottom of the left column in a short window. This is one of those things that I wonder about every so often. I don't really track my visitor metrics, but my conclusion wound up being that I haven't seen anyone run something as small as 800 x 600 in so long that it's just not an issue. On the other hand, if you're seeing clipping at 1024 x 768, that worries me. Was there a particular page giving you problems, or was that a general resolution comment? 3/ Should the navigation links in the left column be larger, the same size, or smaller than the primary content in the right column? Obviously, I thought they should be larger. =] This was done for a couple of reasons: 1) to increase visibility, 2) to give them a certain scale in the sidebar and not have them surrounded by white space. I don't know if these are *good* reasons, but they were the ones that drove my decision. What are the operational or aesthetic theories behind the other schools of thought? 4/ If, for whatever reason, a user might scale the fonts, do you want the navigation links to horizontally cross-over and overlap the primary content? That doesn't happen on any browser I've tested. IE6 -- though essentially irrelevant -- wraps the text as it grows bigger. IE7 and Firefox 3 both scale the width of the sidebar along with the fonts. (I tried to make sure that widths are specified in ems so that this contingency is covered.) 5/ Is it possible to code the site with fewer ids, classes, and span thingies? I'm sure it probably is. =] 6/ Gray on gray is sometimes difficult for some users to read. Have you checked your site with a color contrast analyzer? No, I haven't. This is the first I've heard of such a creature. I'll look into them. Thanks for all your suggestions and comments. I really appreciate you taking the time. michael __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] request: a thorough going over
I've been working on a CSS3 / XHTML 1.1 Strict redesign of my site for awhile. Due to circumstances at my host, I had to push it over to the new server sooner than I'd intended. I was hoping to get some feedback if anyone has time to kick the tires on the site. At this point, I think I've lost all objectivity, so any bug or glitch reports, and suggestions -- on anything -- would be most welcome. The design is pretty sparse, focusing mostly on textual content. The CSS and all the pages validate. I've tested it on = Firefox 3.5, IE 8, and have seen it in action briefly on whatever the current shipping version of Safari is. Don't have access to Chrome, IE8, or Opera. http://www.ronin-group.org It would be most appreciated! michael __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] Suckerfish menu test (and a question)
Thanks to a suggestion by David G, I think I managed to get my
Suckerfish menu hybrid sorted in both IE6 and Firefox 2. If anyone
could check it out in other browsers and give me some feedback, I'd
appreciate it.
http://ronin-group.org/v2/bd/menu/menutest.html
Turns out that this previously suggested fix--
* html #nav4 li:hover ul, #nav4 li.sfhover ul {
display:inline-block;
position: static;
}
--didn't work for my implementation. However, doing this--
* html #nav li ul { width: 11.3em; margin: 0 0 0 -67px; }
--DID correct the drop down offset. If anyone else is experiencing
similar issues.
One thing that the original SF menu does, that I desperately would
like to replicate is the ability to ignore graphics in list elements.
I've been through the code--
http://www.htmldog.com/articles/suckerfish/example/
--back and forth and cannot for the life of me figure out how it's
done. It just seems to happen, but I doubt the answer is it's magic. =]
If anyone could tell me how to achieve that, it would absolutely make my day.
michael
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] Man vs. Suckerfish
The jury's still out on which one of us is winning. I've been playing with the original listapart Suckerfish menu for awhile, and recently became aware of the existence of the vastly improved Son of Suckerfish. Liking the styling of the original, I've been trying to adapt it to the new markup (by tracing through both sets of CSS and trying to figure out how to seam them together). Mostly, I think I've gotten it, but there are a couple of things that I just can't seem to get. 1) The offset of the drop down menu in contrast to the element above it. It shouldn't be there (and it's markedly worse in IE6), but nothing I try seems to have any effect on adjusting it. 2) In the original Suckerfish, there are embedded decorative images that do not get highlighted when they're moused over. It's totally cool, but I can't figure out how it's done. 3) The multi-level drop downs just don't work. (I plan on using this mostly as a single level menu, but since it's supposed to actually BE multi-level it would be nice if it worked. I haven't had time to see if I've done something stupid in the code.) If anybody has a couple minutes to give it a look, I'd sure appreciate it. Test file and graphics at: http://www.ronin-group.org/v2/bd/menu/menutest.html michael __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7 information -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] changes in W3C validator?
Has anyone noticed that the W3C's CSS validator is now parsing style rules embedded in HTML comments? I used to be able to sneak (correct but invalid) things into includes, and just discovered that that's no longer working. I haven't seen any mention of it, so I'm wondering if they just kind of snuck a new version in, or if I missed something obvious. I know they were working on a new XHTML parsing engine, but it didn't sound like Jigsaw was included in that... michael __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7 information -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] can't figure out why this won't validate
At 12:13 AM 3/19/2007, david typed out this missive:
This does not validate in CSS3:
.colset01 { column-width: 15em }
Unless you have a typo in your email, you're missing a closing ;.
The w3.org page didn't include them, but I though that, too. It
doesn't validate even with the semicolon.
michael
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] can't figure out why this won't validate
Ran into an interesting something. Not sure if it's a problem,
really, but it's confusing.
This does not validate in CSS3:
.colset01 { column-width: 15em }
It certainly should work, in fact it's an example used on this page:
http://www.w3.org/TR/css3-multicol/
But it spits this error: 15em is not a column-width value : 15em
Is this just a glitch in the validator or am I missing something
[really obvious]?
While I'm on the topic of CSS3 columns, is there a roadmap anywhere
that would indicate when the column module might move from a working
draft to a candidate recommendation? Assumably, that's the point when
the vendor specific style tags (like -moz- and -webkit-) will get
dropped in favor of the real deal.
Thanks,
michael
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] help! -- frameless css conflict with pure css popups
Hi all, I've got a small site that uses CSS frames to create a fixed navigation sidebar, similar to the techniques discussed here: http://jessey.net/simon/articles/007.html http://underscorebleach.net/jotsheet/2004/12/frames-with-css-layout http://css-discuss.incutio.com/?page=FixedLayouts This works perfectly in Firefox and IE 5-7 in quirks mode. The CSS and XHTML validate and all is right in the world. I recently got a wild hair to implement a sort of tooltip functionality and I used Eric's pure css popups as a model. It works great in Firefox, but IE has all kinds of problems positioning the info box. I'm pretty sure that there's some kind of conflict between the fixed positioning code and the css popups, but I don't have the skills to sort it out. The best I could come up with was a totally different implementation for IE, but there are problems and I'd prefer the rendering to be the same. I've been beating my head into this for so long now that I can't see straight, so I thought that I'd run it by the list -- since you all know infinitely more about CSS than I ever will. A description, with examples: http://ronin-group.org/TRG_colophon.shtml#notes My style sheets: http://ronin-group.org/css-rgo-main.css http://ronin-group.org/css-msiefix.css If anyone has any thoughts, I'd certainly appreciate hearing them. Best, michael __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7 information -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
