Re: [css-d] The CSS Overlords
At 10:24 PM 1/17/2009 -0800, Dan Gayle wrote: Part of it is a generational gap between younger web designers and older. I never knew that table based designs were ever ok. The books always talk about table based layouts as if the Civil War were still raging, and the victory of the good North (CSS) was almost complete over the evil South (table-based layouts). Hey, we might be old, but we're not *that* old (and we're certainly still quite a way from the grave). ;) But another part of why tables hurt my brain is the lack of semantic structure. I can look at, analyze, and improve the code of a div and CSS based layout any day. Just to play Devil's Advocate... And I can create a site with tables, and -- assuming that I'm happy with my design -- I *don't* have to subsequently look at, analyze and improve on the code, having to come up with all sorts of hacks and fixes to make it work right (and always worrying, still, if I did actually get it right), and constantly worrying about what the next versions of browsers are going to do, all the testing and fixing that I'll have to go through, over and over again, forever re-doing and re-learning everything that I've already done/learning, forever having to fix things that were previously fixed (often with great time, effort and exasperation). On the contrary, the sites that I created 10+ years ago have lived through numerous browsers and browser versions, not once ever breaking in any of them, not once ever needing any change (indeed, the *only* major change that I've had to make on *any* of my older sites was when I first implemented CSS in them). The sites that you're making today with CSS layouts will quite possibly be completely obsolete within 5 years, but the sites that I've made with tables will in all likelihood still be around -- and working/looking perfectly fine -- in 100 years (unless, of course, the CSS Police decide to abolish and impound the entire concept of tables, forever and anon). ;) What is there to guess about this structure? It's easy, it makes sense, and is really easy to modify. div id=header/div ul id=nav/ul div id=content/div div id=sidebar/div div id=footer/div But when I look at the structure of even a simple table based layout, I have to blink my eyes a few times to even guess at what I'm looking at. Seriously? Messy/disastrous coding practices aside (which can apply to CSS layouts just as much as table layouts), but do you mean you can make sense of your code, above, but you can't make sense of this code, below? tr td id=header colspan=3/td /tr tr td id=nav/td td id=content/td td id=sidebar/td /tr tr td id=footer colspan=3/td /tr My code might *look* like there's more work involved in creating it, but what you're not showing in your code is all the countless hacks and fixes that you have to implement behind the scenes -- whereas my code requires *none*, *zero*, and in all likelihood never will. Ron ;) __ 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] The CSS Overlords
At 10:51 AM 1/18/2009 +, Christian Heilmann wrote: Cool, then show the sidebar on the left. Doesn't require a hack with CSS :) What do you mean -- on top of, and obscuring, the nav bar? Don't know what you mean (exactly), but I'm sure I'd have no problem pulling it off with ease (if you can explain what you mean better). Ron :) __ 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] The CSS Overlords
On Jan 18, 2009, at 8:20 PM, Ron Koster wrote: What do you mean -- on top of, and obscuring, the nav bar? Don't know what you mean (exactly), but I'm sure I'd have no problem pulling it off with ease (if you can explain what you mean better). Christian means: move that sidebar (right column in your code) to the left of the page, without modifying your html code. That is very easy to do with a (decently) stylesheet. Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ 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] The CSS Overlords
At 08:31 PM 1/18/2009 +0900, Philippe Wittenbergh wrote: Christian means: move that sidebar (right column in your code) to the left of the page, without modifying your html code. That is very easy to do with a (decently) stylesheet. Ah, okay. Well, sure, I see what you mean, and how that would be easier with CSS, but I do have to sit here and wonder... geez, when you folks create a web site, and you've finished/finalized the design, aren't you happy with it? Or do you just continually change the layout, just for the sake of changing the layout (because you can)? This has me thinking that perhaps my perspective comes from the fact that I came to web design after being into desktop publishing -- which, of course, is stagnant (i.e. in the sense that once one has created something, and put it into print, one doesn't have the option of going back and re-doing it, at least not without coming out with a second edition or whatever). On the other hand, perhaps for those of you who began your careers (whether professionally or non-professionally) in web design, the whole medium is just so conducive to change that that is your inclination -- to constantly change things around (and probably confuse any regular visitors!), simply because you can. I don't know. Any time I create a new site, I try to create something that -- in my mind, at least -- is perfect (so-to-speak), which is visually exactly what I'm trying to convey. Now, if that means having a nav bar on the left and a side bar on the right, well, if that's what looks right to me, then I can't see why I would then go and change it, making it visibly imperfect (at least, to anyone with any sort of design sense). Of course, I am using the term perfection loosely -- there isn't any such thing (when it comes to art) -- and it is all subjective, but if I've gotten it right, well, then I've gotten it right. Sure, there is the possibility that I might change my mind down the road and want to change the layout (or whatever), but even if that happens, we're only talking about, what, once every 5, 10 years or something? In the meantime, I can create a site and essentially forget about it -- and when Internet Explorer version 1042 (beta) comes out, and for all the decades in-between, I can rest with comfort, reasonably and justifiably assured that my site has worked and looked just fine, all along, I won't have to go off into a panic *each* time that *any* browser comes out with a new version, endlessly testing and revising my code. Hey, don't get me wrong, I really *do* embrace CSS, and really *would* like to learn more and then transform my sites into CSS layouts, because I know that that's exactly what it was meant for -- but, quite frankly, a lot of these responses to this thread are actually having the reverse effect that is intended, and are actually providing me with additional reasons that tables do, in fact, work much better (at least, at this point in the development of where CSS is at, and most certainly in the long run, as evidenced by the longevity, and lack of need for revisions, of my own sites). Yea, O Faithful Ones! I want to believe! I want to believe! But, pray, I ask thee: what about the dinosaurs? The CSS scriptures predict that the 8th Coming of the Browser is nigh, at which point all the coding will be washed away and a new world will begin -- but in my philosophy all is well, and there is, and has forever been, Eternity. Ron ;) Woof?... http://www.Psymon.com Ach, du Leni!... http://www.Riefenstahl.org Hmm... http://www.Imaginary-Friend.ca __ 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] The CSS Overlords
As a guy who grokked HTML in the days of table-based layouts, I loved, and still love, tables -- especially for tabular data or simple columns. As a guy who these days writes a ton of dynamic apps for delivery to multiple clients, I have love for CSS. And yes, CSS pwns font styling, no question. Crazily enough, you can use CSS styles within a table-based layout, and get the best of both worlds. As someone who despises the cross-browser cross-platform crap that's forced on us, table-based layouts are easier, but far less capable of being truly stunning looking/feeling/behaving, and less flexible of adapting one intricate layout to another for a new or seasonal or specific campaign look without massive rewrites. One's history, target platform(s) and audience(s) certainly dictate your perspective on this. Thanks- - Andy Badera - and...@badera.us - (518) 641-1280 - Google me: http://www.google.com/search?q=andrew+badera On Sun, Jan 18, 2009 at 6:59 AM, Ron Koster r...@psymon.com wrote: At 08:31 PM 1/18/2009 +0900, Philippe Wittenbergh wrote: Christian means: move that sidebar (right column in your code) to the left of the page, without modifying your html code. That is very easy to do with a (decently) stylesheet. Ah, okay. Well, sure, I see what you mean, and how that would be easier with CSS, but I do have to sit here and wonder... geez, when you folks create a web site, and you've finished/finalized the design, aren't you happy with it? Or do you just continually change the layout, just for the sake of changing the layout (because you can)? This has me thinking that perhaps my perspective comes from the fact that I came to web design after being into desktop publishing -- which, of course, is stagnant (i.e. in the sense that once one has created something, and put it into print, one doesn't have the option of going back and re-doing it, at least not without coming out with a second edition or whatever). On the other hand, perhaps for those of you who began your careers (whether professionally or non-professionally) in web design, the whole medium is just so conducive to change that that is your inclination -- to constantly change things around (and probably confuse any regular visitors!), simply because you can. I don't know. Any time I create a new site, I try to create something that -- in my mind, at least -- is perfect (so-to-speak), which is visually exactly what I'm trying to convey. Now, if that means having a nav bar on the left and a side bar on the right, well, if that's what looks right to me, then I can't see why I would then go and change it, making it visibly imperfect (at least, to anyone with any sort of design sense). Of course, I am using the term perfection loosely -- there isn't any such thing (when it comes to art) -- and it is all subjective, but if I've gotten it right, well, then I've gotten it right. Sure, there is the possibility that I might change my mind down the road and want to change the layout (or whatever), but even if that happens, we're only talking about, what, once every 5, 10 years or something? In the meantime, I can create a site and essentially forget about it -- and when Internet Explorer version 1042 (beta) comes out, and for all the decades in-between, I can rest with comfort, reasonably and justifiably assured that my site has worked and looked just fine, all along, I won't have to go off into a panic *each* time that *any* browser comes out with a new version, endlessly testing and revising my code. Hey, don't get me wrong, I really *do* embrace CSS, and really *would* like to learn more and then transform my sites into CSS layouts, because I know that that's exactly what it was meant for -- but, quite frankly, a lot of these responses to this thread are actually having the reverse effect that is intended, and are actually providing me with additional reasons that tables do, in fact, work much better (at least, at this point in the development of where CSS is at, and most certainly in the long run, as evidenced by the longevity, and lack of need for revisions, of my own sites). Yea, O Faithful Ones! I want to believe! I want to believe! But, pray, I ask thee: what about the dinosaurs? The CSS scriptures predict that the 8th Coming of the Browser is nigh, at which point all the coding will be washed away and a new world will begin -- but in my philosophy all is well, and there is, and has forever been, Eternity. Ron ;) Woof?... http://www.Psymon.com Ach, du Leni!... http://www.Riefenstahl.org Hmm... http://www.Imaginary-Friend.ca __ 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] Scrollbar styles (etc.) validation
I know this topic has come up here before (because I've searched the list archives), but I couldn't find what any ultimate recommendation is over what to do. I've got the CSS for one of my sites validating with no errors, except for the styling of the scrollbars (for IE only, of course), i.e. scrollbar-track-color, scrollbar-face-color, etc. -- this/these alone are causing the CSS file to not validate. In searching the list archives, it would seem that there's nothing that one can do about that, that using that feature simply will prevent the CSS file from validating. But what's the recommendation, then? If that -- and that alone -- is all that's making the style sheet not validate, then is it really important that it does (validate)? Or is the recommendation to just never, ever use that scrollbar stuff (and, if so... well, what really is the harm)? Also, for a variety of different things (like link colors, etc.) I get a bunch of these warnings (not errors)... You have no background-color set (or background-color is set to transparent) but you have set a color. Make sure that cascading of colors keeps the text reasonably legible. How on earth is that a warning? If I set a background color for my links or whatever else, well, then there goes my background graphic out the window. On the other hands, are warnings like the above safe to just totally ignore completely? Pardon my stupidity (if that, in fact, is the correct observation and answer for all of the above!). Ron %} Woof?... http://www.Psymon.com Ach, du Leni!... http://www.Riefenstahl.org Hmm... http://www.Imaginary-Friend.ca __ 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] The CSS Overlords
Ron Koster wrote: And I can create a site with tables, and -- assuming that I'm happy with my design -- I *don't* have to subsequently look at, analyze and improve on the code, having to come up with all sorts of hacks and fixes to make it work right (and always worrying, still, if I did actually get it right), and constantly worrying about what the next versions of browsers are going to do, all the testing and fixing that I'll have to go through, over and over again, forever re-doing and re-learning everything that I've already done/learning, forever having to fix things that were previously fixed (often with great time, effort and exasperation). [...] My code might *look* like there's more work involved in creating it, but what you're not showing in your code is all the countless hacks and fixes that you have to implement behind the scenes -- whereas my code requires *none*, *zero*, and in all likelihood never will. Ron: Frankly, I think your e-mails reflect the old way of thinking about the web. Yet in your own work from your signature you do not reflect the old way of development except in that you use tables for the outer layout. 1. You use a valid document type. Essential to modern development. 2. Your HTML validates (except for maybe some JS you haven't wrapped in !-- //--). 3. You use fairly semantic HTML instead of DIV for everything. 4. You do the bulk of your styling with CSS. So I guess my question is what exactly is it that you're doing that you need a zillion fixes and hacks to make it work? I haven't had to do that kind of development in years. Don't let this list confuse you. People have innumerable CSS problems because we are all learning and growing in CSS, not because CSS is critically flawed in the ways you have come to believe. It is not only possible to develop 100% hack free CSS based web pages, but it is possible to do so quickly and efficiently. The browser wars are over and the good side won. Now 99% of non vision-impaired web users have browsers that are IE 6 or newer (80% are much newer than IE 6) and this means the days of hacking and witching our HTML into cross browser compatible pages are over. Trust me when I say that if I had to do the things you outline above to make money in CSS development then I would run far, far away from all of this. I challenge you to throw away the tables. If you have an issue between browsers you can't clear up then bring it to the list and we'll all talk about it. Developing for the web without tables should not be the stressful situation you outline above. If it is then you're doing it wrong. -Adam Ducker (http://adamducker.com) __ 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] The CSS Overlords
At 08:55 AM 1/18/2009 -0500, Adam Ducker wrote: So I guess my question is what exactly is it that you're doing that you need a zillion fixes and hacks to make it work? I haven't had to do that kind of development in years. Well, that's what I meant -- *I* don't need all sorts of fixes/hacks in order to do what I want, but since I've been on this list (since last July) that seems to be all I see amongst those who do choose to create layouts (etc.) purely with CSS. I see one post after another go by with one problem or another, and quite often the answer will be that Yeah, IE is funny that way, and you have to do this and this and this and this in order to get it to work (or whatever similar solution might be for the question at hand). And yet, there's often been times when I looked at the person's problem and thought, gee, I could resolve that issue EASILY, if only I *wasn't* trying to do it exclusively with CSS. Don't let this list confuse you. People have innumerable CSS problems because we are all learning and growing in CSS, not because CSS is critically flawed in the ways you have come to believe. Well, perhaps flawed is the wrong word (although I don't believe I used that word, specifically). I guess what I mean, though, is that CSS is still very, very young (it's hardly hit puberty, let alone young adulthood!), and surely, surely everyone here can see and acknowledge that there's still all sorts of things that need to be worked out and really, genuinely standardized. In a way, how all the various browsers seem to be going off on their own, each creating their own standards, reminds me of the competition between HD and BluRay -- sooner or later someone is going to come out on top, and all the other browsers will follow. I mean, geez, if they don't then the need for all these ridiculous hacks and fixes will never, ever end! And that would be stupid, utterly ridulous and ultimately self-defeating, for *all* browser manufacturers and *all* web designers. But that's basically where things are at now -- a world of hacks and fixes. I'd like to think, though, that hopefully within the next decade things will indeed become better in that regard. In the meantime, I can't understand why anyone would take issue with something that *does* work (i.e. table layouts), that works in the long, long, long term, without any problems at all. It is not only possible to develop 100% hack free CSS based web pages, but it is possible to do so quickly and efficiently. The browser wars are over and the good side won. Now 99% of non vision-impaired web users have browsers that are IE 6 or newer (80% are much newer than IE 6) and this means the days of hacking and witching our HTML into cross browser compatible pages are over. Interesting. So the thousands of posts that I've seen go by on this list, all of which require a solution that involves hacking and witching, are just my imagination? I challenge you to throw away the tables. If you have an issue between browsers you can't clear up then bring it to the list and we'll all talk about it. Developing for the web without tables should not be the stressful situation you outline above. If it is then you're doing it wrong. And I challenge you to not condescend, and not tell me how to create my web sites. :) Look, what you're expressing in that last paragraph is *exactly* the sentiment that I was referring to in my first, initial post in this thread: that those out there who advocate CSS layouts can be very intimidating for those of us who continue to use tables, and can leave us feeling extremely apprehensive in posting a question, any question, to the list (for fear that we be admonished for using tables for layout). I don't know about anyone else here, but I think the conclusion that I've come to through this whole thread is that, hey, it's up to you! I absolutely, truly and whole-heartedly applaud all of you out there that are making sincere efforts at designing web pages purely with CSS layouts (etc.), if only because it's because of *YOU* people that things will, indeed get better and better over time. But with things still being as buggy as they are -- and with only hope for the future that things will get better -- until things do get better then I see no reason why people should be condescended to for choosing to stick with tables for layouts, for what's tried-and-true, for what *works*, long-term and quite possibly forever. Hey, if I walk out my door tomorrow and get hit by a bus and die, at least I'll be able to rest in peace, knowing that my web sites will live on after me -- even if the manner in which they're made is archaic, at least they won't completely fall apart and then eventually disappear from the web forever, the next time the next version of browsers hits the airwaves. In the end, I think Andrew said it best, and most succinctly... At 07:11 AM 1/18/2009 -0500, Andrew Badera wrote: One's
Re: [css-d] Scrollbar styles (etc.) validation
Ron Koster wrote: I've got the CSS for one of my sites validating with no errors, except for the styling of the scrollbars (for IE only, of course), i.e. scrollbar-track-color, scrollbar-face-color, etc. -- this/these alone are causing the CSS file to not validate. In searching the list archives, it would seem that there's nothing that one can do about that, that using that feature simply will prevent the CSS file from validating. 1: scrollbar styles affect a few non-IE browsers too. I never use IE for surfing, but I see your colored scrollbars in my non-IE browser because I've allowed it to act on those styles. 2: that proprietary stuff doesn't validate is as expected, and does not invalidate the regular styles. So if you're sure the styles are ok and work as intended, then there no real harm done. If total validity matters and you want to keep the proprietary styles, Conditionally Commented stylesheets for IE only stuff is an option. This approach doesn't make the styles valid, but for most hidden is good enough. Besides: the stuff will not show up in non-IE browsers when CCs are used, which I personally think is more important. You have no background-color set (or background-color is set to transparent) but you have set a color. Make sure that cascading of colors keeps the text reasonably legible. How on earth is that a warning? If I set a background color for my links or whatever else, well, then there goes my background graphic out the window. Background-color is layered behind background-image, so normally setting a background-color as fallback shouldn't be a problem. The shape / transparency of the background-images you're using may force you to declare an actual background-color further back, and since the validator can't see your visual design it can't clear you on that point - hence the warning. On the other hands, are warnings like the above safe to just totally ignore completely? Warnings should not be ignored, as what they're usually pointing at is something that may conditionally fail at the visitors' end. The validator can't check all what happens if, so it simply tells _you_ to perform such checking. Only when you have manually checked and are sure failures can not occur, can you safely ignore these warnings. regards Georg -- http://www.gunlaug.no __ 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] Scrollbar styles (etc.) validation
At 04:00 PM 1/18/2009 +0100, Gunlaug Sørtun wrote:
If total validity matters and you want to keep the proprietary styles,
Conditionally Commented stylesheets for IE only stuff is an option.
This approach doesn't make the styles valid, but for most hidden is
good enough. Besides: the stuff will not show up in non-IE browsers when
CCs are used, which I personally think is more important.
Hmm... I haven't got a clue what you're talking
about -- never heard of conditionally commented
style sheets before. I'll have to look into that and see what I can learn.
How on earth is that a warning? If I set a background color for my
links or whatever else, well, then there goes my background graphic
out the window.
Background-color is layered behind background-image, so normally setting
a background-color as fallback shouldn't be a problem.
Well, that's odd, because when I got that warning
I did just try giving the offending items (p, a,
etc.) a background color, but what happened was
that entire paragraphs lost the background
graphic behind them and had that color (only) instead. And that's no good.
In my style sheet, for body I have both a
background color and a background graphic, as
well as color (#5a584e) specified. And then for
p (for example) I have this...
p {
font-size: 14px;
color: #5a584e;
margin-top: 11px;
margin-bottom: 11px;
line-height: 138%;
background-color: transparent;
}
...and that's what gives me that warning, the
fact that I'm specifying a color (with that color
being, as you can see, the same color that's also
specified in the body styles), but not
specifying a specific background color.
This seems like such a simple, stupid and basic
thing -- my apologies for not knowing/understanding this.
Ron :/
Woof?... http://www.Psymon.com
Ach, du Leni!... http://www.Riefenstahl.org
Hmm... http://www.Imaginary-Friend.ca
__
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] The CSS Overlords
Ron Koster wrote: But that's basically where things are at now -- a world of hacks and fixes. I'd like to think, though, that hopefully within the next decade things will indeed become better in that regard. In the meantime, I can't understand why anyone would take issue with something that *does* work (i.e. table layouts), that works in the long, long, long term, without any problems at all. You've alluded to this in your other posts, but I'll respond to it here. I absolutely understand your drive to create the best, most perfect web site the first time around, for the requirements you're working with. But you must work in much more static environments than anything I've ever seen. Don't your clients ever send new requirements your way that require major redesigns, and much sooner than 5 years? That's absolutely amazing to me. It is not only possible to develop 100% hack free CSS based web pages, but it is possible to do so quickly and efficiently. The browser wars are over and the good side won. Now 99% of non vision-impaired web users have browsers that are IE 6 or newer (80% are much newer than IE 6) and this means the days of hacking and witching our HTML into cross browser compatible pages are over. Interesting. So the thousands of posts that I've seen go by on this list, all of which require a solution that involves hacking and witching, are just my imagination? Well, sort of, yeah. All those thousands of designers who don't need to do any hacking and witching aren't the ones who are posting questions. I rarely post, because I so rarely have any problems in CSS that I'd need to tap the list for help. In the meantime, I can get the benefit of hearing other people's issues and seeing the solutions. Isn't that what this list is for? If I want to peruse examples of interesting, working, CSS, there are other venues to visit. A few years ago, I undertook to switch all of the websites I was maintaining from the old table-based layouts to pure CSS. It has been so freeing, I could only wish the technology had arrived sooner. But oh well, that's what we all deal with in computer science, right? Laurie m...@winternet.com http://www.winternet.com/~milo __ 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] Scrollbar styles (etc.) validation
Ron Koster wrote: Hmm... I haven't got a clue what you're talking about -- never heard of conditionally commented style sheets before. http://reference.sitepoint.com/css/conditionalcomments -- http://www.gunlaug.no __ 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] The CSS Overlords
At 04:53 PM 1/18/2009 +0100, Gunlaug Sørtun wrote: If we all fell back to layout tables and minimal use of CSS, there would be very little incentive for growth. snip Layout tables will stay at 1998 level for a long time - probably for as long as HTML is in regular use. Thus, they're stable enough by now and those who wish can still use them. No progress in doing so though. Oh, I totally agree -- and that's basically what I was saying in my last/previous post in this thread. I absolutely, wholeheartedly do encourage anyone/everyone who does use purely CSS layouts, but... well, take my A Letter to an Imaginary Friend site, which is a literary piece of mine. At *this* point, I just wouldn't trust myself, nor CSS standards, to transform it into a CSS layout, simply because I just don't see any guarantee that it would then last forever (which, only naturally, is important to me). On the other hand, if I keep the table layout, then at least I have some semblance of assurance that it will last a long, long time. But perhaps I digress, and perhaps am becoming repetitive -- and having just been admonished off-list for being totally off-topic (along with various other admonishments), my apologies if this has, indeed, been the case. I am truly grateful for this thread, though. Believe it or not, but it really did help allay some confusion for me. I think I'll keep my table layouts for the time being, if only because I do know that they *work*, and I also just don't feel that I know enough about CSS (yet) to do anything otherwise. I suppose my only wish would be that others see that there's nothing wrong in my choosing to do that (for myself), if that's what works for me -- I mean, it's not like my doing so puts a rope around the rest of you, holding you all back. Ron ;) Woof?... http://www.Psymon.com Ach, du Leni!... http://www.Riefenstahl.org Hmm... http://www.Imaginary-Friend.ca __ 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] The CSS Overlords
At 09:38 AM 1/18/2009 -0600, m...@winternet.com wrote: I absolutely understand your drive to create the best, most perfect web site the first time around, for the requirements you're working with. But you must work in much more static environments than anything I've ever seen. Don't your clients ever send new requirements your way that require major redesigns, and much sooner than 5 years? That's absolutely amazing to me. Actually, in all honesty, the answer is no. If I've ever had a client want any sort of big change in any site that I've done for them, it's basically only been a complete, total overhaul -- i.e. re-building the entire site from scratch, which a CSS layout probably wouldn't have helped much at all. And even that has only happened, oh, maybe once or twice. With that said, I should probably point out that I'm not really doing web design in a professional way any more. I used to years ago, but my main interest now is for my own sites, plus the occasional volunteer work that I do for non-profit orgs, etc. In that regard, and as I said in my last post, if I'm going to stick with tables for layout (and for the time being), then that's simply what I feel is best and most appropriate for *my* sites -- but I do totally understand if others feel that their needs require CSS layouts, etc. And I guess that was my point: I'm not trying to change anyone here, and get anyone to revert backwards and use tables for layout, but for those of us who do choose to use them, the reasons for doing so are (or can be) perfectly valid, just as valid as choosing to use CSS. It's just a matter of what one's needs/goals are -- but it's not fair for anyone to be condescending (like an off-list message that I just got, admonishing me for my sites, as well as my thoughts here) if I feel that tables are *currently* what works best for me. I rarely post, because I so rarely have any problems in CSS that I'd need to tap the list for help. In the meantime, I can get the benefit of hearing other people's issues and seeing the solutions. Isn't that what this list is for? Oh, I totally agree. I don't always understand the more nitty-gritty technical things that people might be talking about, but even just checking out peoples' sites and seeing what others are doing with CSS has been fascinating, and certainly educational -- indeed, it can be quite inspiring! A few years ago, I undertook to switch all of the websites I was maintaining from the old table-based layouts to pure CSS. It has been so freeing, I could only wish the technology had arrived sooner. But oh well, that's what we all deal with in computer science, right? Well, I'll get there, too, some day. Maybe I'm really just chicken -- you people are scary. Ron ;) Woof?... http://www.Psymon.com Ach, du Leni!... http://www.Riefenstahl.org Hmm... http://www.Imaginary-Friend.ca __ 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] The CSS Overlords
Ron Koster wrote: [...] there's often been times when I looked at the person's problem and thought, gee, I could resolve that issue EASILY, if only I *wasn't* trying to do it exclusively with CSS. Sure, but we handle/serve such non-CSS solutions on other lists/forums, since [CSS-D] is mainly about making things work with CSS. Interesting. So the thousands of posts that I've seen go by on this list, all of which require a solution that involves hacking and witching, are just my imagination? That we're sometimes hacking old IE to pieces is not just your imagination. Not much else we can do for that and other old buggers that won't fade away, as long as clients insist not only on supporting them but also that they should look fresh and pixel-perfect. Most of what we serve better browsers are pure standard stuff though, that we sometimes split up and organize in certain ways so they can pick up what their level of standards-support allows them to. It's known as progressive enhancement. You see: we're all depending on those browsers, and their ability to deliver is growing somewhat slowly and unevenly. They do however grow because they're constantly being challenged. If we all fell back to layout tables and minimal use of CSS, there would be very little incentive for growth. The problem is that wishes for stability and progress tend to clash. If stability is ones only goal then progress will suffer. Microsoft have already tried that - freezing development at IE6 level, and despite all their attempts to catch up they'll be behind for years and versions to come. IE7 ended up as a minor stop-gap solution, and IE8 will be 3 to 5 years behind where other browsers are now when it's finally released. Layout tables will stay at 1998 level for a long time - probably for as long as HTML is in regular use. Thus, they're stable enough by now and those who wish can still use them. No progress in doing so though. regards Georg -- http://www.gunlaug.no __ 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] Scrollbar styles (etc.) validation
At 04:58 PM 1/18/2009 +0100, Gunlaug Sørtun wrote: Hmm... I haven't got a clue what you're talking about -- never heard of conditionally commented style sheets before. http://reference.sitepoint.com/css/conditionalcomments Oh! Thank you! I was going to just go search it out myself (just hadn't gotten around to it yet), but that certainly helps. Thanks! Rest assured I'll let you know if/when I run into any problems... Ron ;) __ 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] RE; The CSS Overlords
On Sun, Jan 18, 2009 at 1:09 AM, Ron Koster r...@psymon.com wrote: - Message: 2 Date: Sat, 17 Jan 2009 11:06:01 -0500 From: Ron Koster r...@psymon.com Subject: [css-d] The CSS Overlords To: css-d@lists.css-discuss.org Message-ID: mailman.1296.1232258960.8701.cs...@lists.css-discuss.org Content-Type: text/plain; charset=us-ascii; format=flowed At 02:20 PM 1/14/2009 -0500, Bill Brown wrote: Well, tables and CSS are not mutually exclusive. That is, they can be used together, though using them for layout is generally frowned upon by the CSS Overlords. [SNIP] I'm curious: why is this approach frowned upon? Please don't get me wrong, because I do fully understand that the *goal* of CSS is for the purpose of layout, etc., and tables were never really meant for that, but at the same time I can *easily* create a site using tables and have *no* cross-browser/platform problems at all -- on the other hand, I've attempted to create sites with CSS layouts, and have only ended up with a thoroughly buggy site. Perhaps I just don't know CSS well enough to know what I'm doing, but having now been on this list for a few months now (since last July), it seems like practically everyone has innumerable, sometimes insurmountable, problems in attempting to do so -- when quite often many of these problems would simply disappear if a table had been used for layout instead of CSS. I'm coming in to this discussion a bit late, so my apologies if required. That said I can think of more than a few reasons why CSS based layouts are far superior to Table based approaches. Most of them have already been discussed, but one of more important reasons is speed . CSS pages render about 1/3rd less time than table based layouts, Doug Boude, and Joe Gautreau tested this a while back, for the details see http://www.twoninemedia.com/blog/index.cfm/2007/4/19/TabledLayoutsvsCSSLayouts. Using the Web Page Analyzer at websiteoptimization.com the authors found that the CSS-based layout was 33% FASTER than the table-based layout on a T1 connection. I found that rather difficult to believe, so I tried a more rigorous test using JMeter and 100 simultaneous connections. The load test confirmed their findings, on average the CSS pages rendered much faster than table based layouts when under a significant load. This speed difference was maintained going from 5 through 100 simultaneous users. One of these days I'm going to have to blog about this. regards, larry -- The real problem is not whether machines think but whether men do. - B. F. Skinner - __ 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] RE; The CSS Overlords
At 11:31 AM 1/18/2009 -0500, Larry C. Lyons wrote: one of more important reasons is speed . CSS pages render about 1/3rd less time than table based layouts So instead of rendering in, say, 3 to 6 seconds (which, off the top of my head, seems about average, for any average page on the 'net -- at least on my computer), it'll only take a mere 2 to 4 seconds? Sorry, but I'm not sure how important a reason that is. Ron ;) Woof?... http://www.Psymon.com Ach, du Leni!... http://www.Riefenstahl.org Hmm... http://www.Imaginary-Friend.ca __ 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] The CSS Overlords (Ron Koster)
Hey Ron, You said: I'm curious: why is this approach frowned upon? Please don't get me wrong, because I do fully understand that the *goal* of CSS is for the purpose of layout, etc., and tables were never really meant for that, but at the same time I can *easily* create a site using tables and have *no* cross-browser/platform problems at all -- on the other hand, I've attempted to create sites with CSS layouts, and have only ended up with a thoroughly buggy site. Perhaps I just don't know CSS well enough to know what I'm doing, but having now been on this lis for a few months now (since last July), it seems like practically everyone has innumerable, sometimes insurmountable, problems in attempting to do so -- when quite often many of these problems would simply disappear if a table had been used for layout instead of CSS I taught a workshop recently in CSS design. These people were all still using hybrid designing because they couldn't get the knack of tableless design. In my intro, I asked them to each give their names and tell me which browser they used for testing their layouts during their workflow. Without a single exception, they all said IE. I made them develop for Firefox during the class, and then we fixed for IE, which only took MINOR adjustments. By the end of the one day workshop they had all completed two simple tableless layouts using the layouts at the layoutgala site. All their layouts worked in all browsers. I suspect you are just complacent and don't wish to make the effort to learn. And I suspect you might be making the same mistake my workshop students did. It never takes me more than 20 minutes to hack a layout for IE, and it already works in all the other browsers. And many times it takes me much less than that. I've been using tableless layouts for years. All the problems have already been solved for you. What are you waiting for? -- Ciao for now, bj mailto:b...@bitchslappin.net http://bitchslappin.net - Taking a Hard Look at the Business of Politics http://greenspeak.org - Small scale local environmental action http://kickasswebdesign.com NOTICE: Due to Presidential Executive Orders, the National Security Agency may have read this email without warning, warrant or notice and also without any judicial or legislative oversight. __ 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] The CSS Overlords (Ron Koster)
At 11:44 AM 1/18/2009 -0500, bj wrote: I suspect you are just complacent and don't wish to make the effort to learn. snip What are you waiting for? Thanks for your comments, BJ -- in response, please see my previous posts. In the meantime, back to this never-ending learning stuff for me (about CSS, about Photoshop, about video editing/DVD production, about typography and font design, about film studies/film history, not to mention updating my web sites, creating new artwork, and maybe even learning a new song on guitar). Ron ;) __ 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] The CSS Overlords
My code might *look* like there's more work involved in creating it, but what you're not showing in your code is all the countless hacks and fixes that you have to implement 'behind the scenes' Let me just say that I have made perfectly functioning CSS sites without any hacks or fixes whatsoever. but it's just as fantastic that some of us out there choose to stick with what does, in fact, really and truly work in the long haul, bug-free and quite possibly lasting 'forever.' You think your enthusiasm for table-based layout means it's just as good. That's great. But there may be finer points here that you are not clear on. For instance, people always talk about how CSS has only been recently supported but many people (even professional web developers) don't seem to know that it's had quite a bit of support for quite some time. I have pages that I created in 1999 and 2000 where I haven't had to touch the CSS since then (or the layout) and they still work perfectly fine. I was making pages with changeable style sheets in 2000 and using (thanks to the Intermediate CSS course I took from the HTML Writer's Guild taught by Eric Meyer) sibling and child and pseudo-selectors in 2002. Those things actually worked in Netscape (gasp, Netscape!) in 2002 before Firefox came along and enhanced the pages I used them on while those who used IE still had a perfectly good page. When I check those pages now in 2009 they still work just fine and there is now greater browser support. I'd go into greater detail if I weren't rushing out the door right now. There are some things I like about tabled layouts over CSS layouts but I never do tabled layouts anymore. __ 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] The CSS Overlords
The interests and motivations are different. If I am asked to do a pretty newsletter for Word's rendering engine behind Outlook, I would like to tell them to ask an HTML table guy. It took me a few years to learn CSS, but I won't spend time with learning tables. Some don't like CSS because of the workarounds to be found and new methods to be invented every day, but that's the fun part of CSS, at least to me. Frankly, I find tables boring, the last new idea how to use them was born a decade ago, a solved and glued puzzle. Maybe the fun part of tables is the control you gain over them, I just don't know. However, the day the CSS-framework-guys win and produce something endlessly boring that does not require an understanding of CSS anymore approaches, so maybe it's time to move on. How about a discussion like: how do we use CSS 3 with an IE6-userbase of greater than x% in years to come? Can we re-think degradation, this time without grace, and convince clients and co-workers that a page does not have to look the same across browsers, as long as a basic functionality is preserved? But how to design with and without border-radius, with and without multi-columns, with and without multiple backgrounds? I don't know how to find a pragmatic balance between CSS 2 and 3. Ingo __ 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] Gallery padding problems between IE Mozilla
Hi all, I have thus far successfully coded my css without any hacks apart from this set where I have to use !important to adjust bottom padding on some thumbnails. This is my codeL http://paste-it.net/public/v1ad1e9/ http://paste-it.net/public/v1ad1e9/ Am I doing something wrong? Many thanks -- Regards Karl __ 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] css3
Is PC Safari and Chrome rendering (unable to view this end for a lot of boring reasons): 1/ border-radius 2/ box-shadow 3/ text-shadow Known issues: there are many-- thanks for not reminding me... http://chelseacreekstudio.com/ca/cssd/index.php -- A thin red line and a salmon-color ampersand forthcoming. http://chelseacreekstudio.com/ __ 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] Gallery padding problems between IE Mozilla
Karl Bedingfield wrote: This is my code: http://paste-it.net/public/v1ad1e9/ Am I doing something wrong? Line 15 is certainly a troublesome piece of code which should be avoided. Can you show us the code in use on a page? That will make it easier for us to see what's wrong. -Adam Ducker (http://adamducker.com) __ 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] Gallery padding problems between IE Mozilla
Karl Bedingfield wrote: Hi all, I have thus far successfully coded my css without any hacks apart from this set where I have to use !important to adjust bottom padding on some thumbnails. This is my codeL http://paste-it.net/public/v1ad1e9/ http://paste-it.net/public/v1ad1e9/ Am I doing something wrong? Other than the CSS is not valid ;-) , dunno. A clickable link to the page in your post to the list could help... -- A thin red line and a salmon-color ampersand forthcoming. http://chelseacreekstudio.com/ __ 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] RE; The CSS Overlords
Ron Koster wrote: one of more important reasons is speed . CSS pages render about 1/3rd less time than table based layouts So instead of rendering in, say, 3 to 6 seconds (which, off the top of my head, seems about average, for any average page on the 'net -- at least on my computer), it'll only take a mere 2 to 4 seconds? Sorry, but I'm not sure how important a reason that is. Ron ;) Good grief. Give it up. Use tables. And be done with it. Please give me some good advice in your next letter. I promise not to follow it. -- Edna St. Vincent Millay, Letters US poet (1892 - 1950) -- A thin red line and a salmon-color ampersand forthcoming. http://chelseacreekstudio.com/ __ 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] RE; The CSS Overlords
On 19/01/2009, at 5:40 AM, Ron Koster wrote: At 11:31 AM 1/18/2009 -0500, Larry C. Lyons wrote: one of more important reasons is speed . CSS pages render about 1/3rd less time than table based layouts So instead of rendering in, say, 3 to 6 seconds (which, off the top of my head, seems about average, for any average page on the 'net -- at least on my computer), it'll only take a mere 2 to 4 seconds? Sorry, but I'm not sure how important a reason that is. Ron ;) Woof?... http://www.Psymon.com Ach, du Leni!... http://www.Riefenstahl.org Hmm... http://www.Imaginary-Friend.ca Ask anyone not on a fast internet connection. Not everyone has the luxury (utility?) of high speed internet connections such as those most of us on this list enjoy. k...@mothership.co.nz +64 21 999 990 Mothership | mothership.co.nz __ 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] css3
David Laakso wrote: Is PC Safari and Chrome rendering (unable to view this end for a lot of boring reasons): 1/ border-radius 2/ box-shadow 3/ text-shadow http://chelseacreekstudio.com/ca/cssd/index.php Tested in XP/VirtualBox on Ubuntu Ibex: Safari and Chrome both appear to recognize your border-radius, box-shadow and text-shadow settings as they stand now. Hope it helps. Would have responded earlier, but there was some static on the list that I had to filter out first. ;-) -- !-- ! Bill Brown macnim...@gmail.com ! Web Developologist, WebDevelopedia.com -- __ 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] css3
Bill Brown wrote: David Laakso wrote: http://chelseacreekstudio.com/ca/cssd/index.php Tested in XP/VirtualBox on Ubuntu Ibex: Safari and Chrome both appear to recognize your border-radius, box-shadow and text-shadow settings as they stand now. Hope it helps. Would have responded earlier, but there was some static on the list that I had to filter out first. Thanks. ~d Take no prisoners. -- A thin red line and a salmon-color ampersand forthcoming. http://chelseacreekstudio.com/ __ 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] RE; The CSS Overlords
This thread teeters precariously on the sharp edge of troll bait. (gravity pulling toward trolling) Time to stop. - CC On Sun, Jan 18, 2009 at 9:40 AM, Ron Koster r...@psymon.com wrote: At 11:31 AM 1/18/2009 -0500, Larry C. Lyons wrote: one of more important reasons is speed . CSS pages render about 1/3rd less time than table based layouts So instead of rendering in, say, 3 to 6 seconds (which, off the top of my head, seems about average, for any average page on the 'net -- at least on my computer), it'll only take a mere 2 to 4 seconds? Sorry, but I'm not sure how important a reason that is. Ron ;) Woof?... http://www.Psymon.com Ach, du Leni!... http://www.Riefenstahl.org Hmm... http://www.Imaginary-Friend.ca __ 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-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] RE; The CSS Overlords
At 02:38 PM 1/18/2009 -0700, Cyber Cog wrote: This thread teeters precariously on the sharp edge of troll bait. (gravity pulling toward trolling) Sorry, folks -- didn't mean to beat a dead fish, er, horse. :/ I do appreciate/have appreciated this thread, though, and it has been genuinely helpful for me (and, from some off-list responses I've received, it seems to have been helpful for some others here, too), and thus I do thank everyone who shared their own thoughts on this subject -- but, as the saying goes, 'nuff said. Ron :) Woof?... http://www.Psymon.com Ach, du Leni!... http://www.Riefenstahl.org Hmm... http://www.Imaginary-Friend.ca __ 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] css3
David Laakso da...@chelseacreekstudio.com wrote: Is PC Safari and Chrome rendering (unable to view this end for a lot of boring reasons): 1/ border-radius 2/ box-shadow 3/ text-shadow Known issues: there are many-- thanks for not reminding me... http://chelseacreekstudio.com/ca/cssd/index.php In Chrome 1.0.154.43 on Win Vista SP2, see screen shot here... http://www.fatpawdesign.com/laaksoscreenshot.png You're looking okay in IE7. Best, Peter www.fatpawdesign.com GO CARDS!!! __ 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] css3
David Laakso wrote: Is PC Safari and Chrome rendering (unable to view this end for a lot of boring reasons): 1/ border-radius 2/ box-shadow 1/2 combination: Safari - OK, Chrome - FAULTY (looks terrible) 3/ text-shadow 2: Safari - YES, Chrome - NO. Known issues: there are many-- thanks for not reminding me... You're welcome :-) http://chelseacreekstudio.com/ca/cssd/index.php regards Georg -- http://www.gunlaug.no __ 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] css3
David Laakso wrote: Farewell. Time to break-out the coil of rope and take it to the woods... ~d Hey ... that's *my* line! G -- http://www.gunlaug.no __ 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] css3
Gunlaug Sørtun wrote: David Laakso wrote: Is PC Safari and Chrome rendering (unable to view this end for a lot of boring reasons): 1/ border-radius 2/ box-shadow 1/2 combination: Safari - OK, Chrome - FAULTY (looks terrible) 3/ text-shadow 2: Safari - YES, Chrome - NO. Known issues: there are many-- thanks for not reminding me... You're welcome :-) http://chelseacreekstudio.com/ca/cssd/index.php regards Georg Farewell. Time to break-out the coil of rope and take it to the woods... ~d -- A thin red line and a salmon-color ampersand forthcoming. http://chelseacreekstudio.com/ __ 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] css3
On Sun, 18 Jan 2009 14:22:05 -0500, David Laakso wrote: Is PC Safari and Chrome rendering (unable to view this end for a lot of boring reasons): 1/ border-radius 2/ box-shadow 3/ text-shadow Known issues: there are many-- thanks for not reminding me... http://chelseacreekstudio.com/ca/cssd/index.php PC Safari 3.2.1 renders all three. The box-shadow on the center column boxes looks odd - the shadow is on the bottom only, and appears to be offset from the left, but there is no corresponding shadow to the right. PC Chrome 1.0.154.43 has no text-shadow, while box-shadow is much larger than on Safari, extending to all sides of the top row boxes, and top and bottom only of the main content's boxes. The border-radius creates a sharp right-angle black corner instead of a rounded corner. Viewed on a Mac running Windows xp under VMware Fusion Unity. Cordially, David -- __ 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] css3
peter hyde-smith wrote: In Chrome 1.0.154.43 on Win Vista SP2, see screen shot here... http://www.fatpawdesign.com/laaksoscreenshot.png www.fatpawdesign.com Oh, my... Twinkle, Twinkle, Little Star -- A thin red line and a salmon-color ampersand forthcoming. http://chelseacreekstudio.com/ __ 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] Pragmatic look at our CSS future - ripped from: The CSS Overlords
Ingo Chao wrote: How about a discussion like: how do we use CSS 3 with an IE6-userbase of greater than x% in years to come? I suggest we use this method... http://www.gunlaug.no/contents/wd_additions_12.html ...and this... http://www.gunlaug.no/contents/wd_additions_16.html ...and bog those old versions down with IE-expressions and scripts so the outcome at least looks like something. Can we re-think degradation, this time without grace, and convince clients and co-workers that a page does not have to look the same across browsers, as long as a basic functionality is preserved? Disgraceful degradation is fun and quite efficient, but I think we'll have a hard time convincing clients and co-workers that this is the way to go until IE7 and all its predecessors are below the 10% mark. The way it looks now we may also have to wait until IE8 has dropped back to well below that mark too, and that thing isn't even out yet... http://www.gunlaug.no/contents/molly_1_24.html So, it may take a while. But how to design with and without border-radius, with and without multi-columns, with and without multiple backgrounds? I don't know how to find a pragmatic balance between CSS 2 and 3. I suggest not using the browser-specific variants for real - only the standardized ones, and wait till browsers catches up with and stabilizes on the relevant standards - and us. If we use browser-specific extensions outside our sandboxes, we may create unnecessary splits between browsers that are otherwise more or less on the same level, and may in some cases promote inferior browsers over superior ones on some pretty unstable grounds. We may also create the need to go back and fix things once the standard versions kicks in, as test-versions and standard-versions may not give the same results. My pragmatic approach in this respect seems to lead to well-balanced results now and then... http://www.gunlaug.no/contents/wd_additions_43.html http://www.gunlaug.no/contents/wd_additions_45.html ...so I'm either quite good at predicting the future, or extremely lucky. Probably the latter, but I like to think it's the former. I'm also constantly keeping track of what browsers can and cannot do for me, without having to fear my layouts getting seriously broken... http://www.gunlaug.no/contents/wd_additions_42.html Not a valid approach, I'm afraid, but it works. It also alleviates the sense of boredom caused by slow progress across browser-land and elsewhere :-) regards Georg -- http://www.gunlaug.no __ 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] Pragmatic look at our CSS future - ripped from: The CSS Overlords
On 18/1/09 23:32, Gunlaug Sørtun wrote: I suggest not using the browser-specific variants for real - only the standardized ones, and wait till browsers catches up with and stabilizes on the relevant standards - and us. If we use browser-specific extensions outside our sandboxes, we may create unnecessary splits between browsers that are otherwise more or less on the same level, and may in some cases promote inferior browsers over superior ones on some pretty unstable grounds. We may also create the need to go back and fix things once the standard versions kicks in, as test-versions and standard-versions may not give the same results. Neither using experimental vendor-specific CSS properties or using unprefixed proposed CSS3 properties (they're not standardized!) is safe. But I'd have thought the former is safer, since vendors try not to implement two experimental versions and the proposed property is subject to change based on the experience of those implementations. -- Benjamin Hawkes-Lewis __ 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] Drop Caps
One of the issues that I've been having is with drop caps, and in
looking for a solution I found this page...
http://css-discuss.incutio.com/?page=DropCaps
...which recommends this code...
p:first-letter {
font: 2.5em/80% serif;
float: left;
padding: 0.2ex 0 0 0.2ex;
margin: 0;
overflow: visible;
}
It seems to work great (although I have yet to test in different
browsers/platforms) and I'm hoping that will resolve the issue I was
having (which had to do with the line height screwing up), but I
don't know the history behind how this recommendation was arrived at,
and so I'm just wondering if there's a particular reason why...
a) 2.5em/80% is specified (ideally, for my own purposes, I'd like to
change that to 2.6em/38%); and
b) if there's a specific reason for the padding: 0.2ex 0 0 0.2ex;
i.e. is there some reason why those couldn't just be all set to 0,
or, alternatively, why I couldn't indent the first letter (and, in
effect, the first line) a certain number of *px* (not ex)?
Thanks in advance!
Ron :)
Woof?... http://www.Psymon.com
Ach, du Leni!... http://www.Riefenstahl.org
Hmm... http://www.Imaginary-Friend.ca
__
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] css3
David Hucklesby wrote: On Sun, 18 Jan 2009 14:22:05 -0500, David Laakso wrote: Is PC Safari and Chrome rendering (unable to view this end for a lot of boring reasons): 1/ border-radius 2/ box-shadow 3/ text-shadow Known issues: there are many-- thanks for not reminding me... http://chelseacreekstudio.com/ca/cssd/index.php PC Safari 3.2.1 renders all three. The box-shadow on the center column boxes looks odd - the shadow is on the bottom only, and appears to be offset from the left, but there is no corresponding shadow to the right. Ah, so. See that now (blind as a bat on this end) on Mac/Safari. It's fixable. Thanks. -- A thin red line and a salmon-color ampersand forthcoming. http://chelseacreekstudio.com/ __ 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] Drop Caps
Ron Koster wrote:
http://css-discuss.incutio.com/?page=DropCaps
p:first-letter {
font: 2.5em/80% serif;
float: left;
padding: 0.2ex 0 0 0.2ex;
margin: 0;
overflow: visible;
}
and so I'm just wondering if there's a particular reason why...
a) 2.5em/80% is specified (ideally, for my own purposes, I'd like to
change that to 2.6em/38%); and
2.5em is the size of the font in relation to the parent element. In your
example, the first letter of every paragraph on the page would be 2.5
times the height of the font of the paragraph.
80% is the line-height, which does not require a unit, so I usually
write it in decimal form (.8 in this case).
b) if there's a specific reason for the padding: 0.2ex 0 0 0.2ex;
i.e. is there some reason why those couldn't just be all set to 0,
or, alternatively, why I couldn't indent the first letter (and, in
effect, the first line) a certain number of *px* (not ex)?
Try it:
http://www.w3schools.com/css/tryit.asp?filename=trycss_font
--
!--
! Bill Brown macnim...@gmail.com
! Web Developologist, WebDevelopedia.com
--
__
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] Drop Caps
At 08:09 PM 1/18/2009 -0500, Bill Brown wrote: 2.5em is the size of the font in relation to the parent element. In your example, the first letter of every paragraph on the page would be 2.5 times the height of the font of the paragraph. 80% is the line-height, which does not require a unit, so I usually write it in decimal form (.8 in this case). b) if there's a specific reason for the padding: 0.2ex 0 0 0.2ex; i.e. is there some reason why those couldn't just be all set to 0, or, alternatively, why I couldn't indent the first letter (and, in effect, the first line) a certain number of *px* (not ex)? Try it: http://www.w3schools.com/css/tryit.asp?filename=trycss_font Oh, I realize that it *works* and that one can change the various values (I've already tried it) but since that specific bunch of styling was recommended, I just don't know what the reasons for that recommendation were -- like, if I change it from what's recommended at that page... http://css-discuss.incutio.com/?page=DropCaps ...will it break in some browser or other? For one thing, for example, I'm not sure why extra padding is needed (or suggested) on two sides of the drop cap. Ron :? __ 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] Pragmatic look at our CSS future - ripped from: The CSS Overlords
Benjamin Hawkes-Lewis wrote: Neither using experimental vendor-specific CSS properties or using unprefixed proposed CSS3 properties (they're not standardized!) is safe. But I'd have thought the former is safer, since vendors try not to implement two experimental versions and the proposed property is subject to change based on the experience of those implementations. Vendor-specific CSS properties are for the most part safe to use in that they don't end up disturbing other browsers - although I have seen that happen too. Used on client-projects vendor-specific CSS properties may backfire on the one responsible for putting them in. Partly because each one will only affect one browser, and partly because the standardized version may deviate quite a bit from the experimental ones. Better explain how they work and don't work before they're put in, as explaining may become more difficult when a site has been up a while. - Note that *nothing in CSS gets standardized* until there are at least two interoperable implementations - at least two browsers must have pretty identical and flawless support for what's only a suggestion. This means we have to use the proposed properties/values if we want them to become recommended parts of standards. We must test to see what browsers make out of experimental and proposed CSS properties, as otherwise we can't catch implementation flaws. Our testing-ground should also be as real world as possible - not just some minimal test-pages, since only real world tests will reveal all weaknesses in a flawed implementation. - So, what I'm saying is that we need pretty wide and challenging sandboxes for testing - I use my entire site, and we need lots of them. Personal sites, blogs etc. are excellent testing-grounds, if we dare see things break/change slightly once in a while. Just do not sell experimental and/or proposed solutions to clients without having cleared it with them beforehand. They may not be quite so relaxed/happy if something changes or starts breaking when a new browser-version with upgraded standards-support arrives on the scene. regards Georg -- http://www.gunlaug.no __ 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] Pragmatic look at our CSS future - ripped from: The CSS Overlords
On 19/1/09 02:10, Gunlaug Sørtun wrote: Vendor-specific CSS properties are for the most part safe to use in that they don't end up disturbing other browsers - although I have seen that happen too. I can imagine implementations of vendor-specific CSS properties changing between versions (but then this also happens with standardized properties). I'd be surprised to find a vendor-specific CSS property (that is, a prefixed vendor-specific CSS property) affecting another web engine and interested as to how that would even happen - it sounds like a parsing bug. Do you have an example of this? Note that *nothing in CSS gets standardized* until there are at least two interoperable implementations - at least two browsers must have pretty identical and flawless support for what's only a suggestion. This means we have to use the proposed properties/values if we want them to become recommended parts of standards. Why do you think the two interoperable implementations rule means we need to author mainstream CSS based on guesses about how future implementations will work? That could be bad for the development of CSS, because improving the spec for those features could break web content that relied on those assumptions. Readers may wish to review the introductions to - http://www.w3.org/TR/CSS21/ and http://www.w3.org/TR/css3-mediaqueries/ - for example statements of the two interoperable implementations rule. -- Benjamin Hawkes-Lewis __ 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] Drop Caps
Ron Koster wrote: ...will it break in some browser or other? For one thing, for example, I'm not sure why extra padding is needed (or suggested) on two sides of the drop cap. Ron, I'm just leading horses to the Kool-Aid...I can't make 'em drink it. -- !-- ! Bill Brown macnim...@gmail.com ! Web Developologist, WebDevelopedia.com -- __ 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] Pragmatic look at our CSS future - ripped from: The CSS Overlords
Browser's support is still improving. My opinion is: if we are using CSS for professional purposes, we should take into account also obsolete versions. otherwise, we should drop our support to these browsers. see http://transcendingcss.com ^.^ http://www.css-zibaldone.com http://www.css-zibaldone.com/test/ (English) http://www.css-zibaldone.com/articles/ (English) http://mimicry.css-zibaldone.com/ (Blog) http://www.flickr.com/photos/gabrieleromanato/ (Flickr) __ 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] Pragmatic look at our CSS future - ripped from: The CSS Overlords
Benjamin Hawkes-Lewis wrote: Why do you think the two interoperable implementations rule means we need to author mainstream CSS based on guesses about how future implementations will work? The amount of guesswork can be kept at a minimum by checking up on proposals, experimental implementations and other people's work once in a while, but experience tells me two things: 1: features tend to get implemented based on plans, ease of implementation and that there's a wish to see them implemented. We can't always appreciate plans or how easy/hard it is, but we can back up our wishes by testing what little there is and present the results. 2: the W3C test cases used to test implementations are accurate for a property/value - in most cases, but exclude everything beyond that. Unless properties/values are also tested in more challenging environments - real world scenarios/designs - even pretty large implementation-flaws may not get caught. Having interoperable but more or less useless implementations hanging around for a few years does not help on progress, so we may as well test and report on various bug-lists, forums etc. to help speed up the process towards true interoperability ever so slightly, whenever we see the need for it. Different people automatically create different real world scenarios/designs, so the more the better. In short: I don't believe in sitting on the fence while waiting for others to drive progress. regards Georg -- http://www.gunlaug.no __ 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/
