SitePoint Sponsor

User Tag List

Page 3 of 6 FirstFirst 123456 LastLast
Results 51 to 75 of 131
  1. #51
    SitePoint Member
    Join Date
    Jun 2004
    Location
    USA
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by redux
    i get by with pretty much no hacks at all. proper planning and a good understanding of css is essential. and yes, IE is happy with all the code i use as well. surprising, isn't it?
    No, not really. Certain layouts work great with a CSS layout. It's just that the layouts I like did not work without a lot of hacks to get things to act as they were expected. Mostly my problems came up when trying to get divs to float correctly, or inheritance problems.

    Worse, certain CSS experts were happy about taking advantage of CSS bugs in certain browsers, where some browsers read the screwed up CSS code, while others ignored it.

    I would love to do my layout with 100% CSS, but it simply doesn't work for me yet. Hopefully one day.

  2. #52
    SitePoint Enthusiast underzen's Avatar
    Join Date
    Apr 2004
    Location
    Ft. Lauderdale, FL
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by vgarcia
    CSS as a standard (CSS1 anyway) happened back in 1996. Think about the state of the Web eight years ago, if you were even on it back then. That's even before table layouts were big (this is around the time of frames), so how was it supposed to replace them? As for the 3-column thing, you don't need CSS3 for that; you can do it with CSS2 if you wanted a tableless layout, or even CSS1 if you don't mind a hybrid approach with a simple table for structure/layout and CSS for everything else like padding, etc (CSS2 came out in 1998 by the way; it's not the W3C's fault that browsers are slow to implement things).
    ahhhh yes, frames........... a walk down memory lane!

  3. #53
    SitePoint Wizard megamanXplosion's Avatar
    Join Date
    Jan 2004
    Location
    Kentucky, USA
    Posts
    1,099
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SniperX
    Sorry, which case are you arguing here? The case for cleaner code or the case for accessibility. The question was about cleaner code, not standards or accessibility. (Not to say that you can't meet both with tables too.)

    As for 56k users - that is becoming as little a valid argument as is designing for Netscape 4.x
    It's impossible to have clean code if you are not following standards or accessibility, they are inextricably linked. Asking people to talk about clean code but not standards and accessibility is like asking "Could you tell me what you know about cleaning a house which doesn't involve moving?". It simply cannot be answered, because standards and accessibility is a requirement for clean code, as movement is a requirement for house cleaning.

    As for 56k users, they are still a very large audience, no matter how much you wish to deny it. I know for a fact that there are more 56k users then there are broadband users because broadband isn't even offered where I live and it's one of the fastest growing cities in North America. Considering that North America is one of the most technologically advanced (for normal consumers), I wouldn't be suprised if 80% of the other places with internet access are dialup-only. Even in the areas where you can get broadband, I don't think many people are going to pay $20+ extra a month so they can check their email 5 seconds faster. While the others may be saying 50% for dialup, I'd say that it's actually a lot higher than that, probably around 60-70%. If you want to abandon that big of an audience, go for it.

    As for NN4, I do not design pages for NN4, or any Netscape browser for that matter. Netscape had it's chance to win approval and it failed miserably. The only netscape-related browsers that I'll design my pages for are Mozilla and Firefox (which are almost identitical in rendering). I also find it funny that, while you are promoting table-based designs you want to curse NN4 and browsers like it, isn't that the only valid reason to be using table-based designs? Judging by the fact that you think everything should be progressing and older technologies can burn in hell, I find it hilarious that table-based designs are your preference. That tells me one thing, you are not comfortable with CSS-based design yet.

    Just my 2 cents.

  4. #54
    SitePoint Addict
    Join Date
    Apr 2004
    Location
    UK
    Posts
    218
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sorry, as I get older I get increasingly forgetful. You'll have to remind me where I have been expatiating the virtues of tables. As you realise that I haven't, I hope you'll find time to explode in another fit of hilatity.

    Just because I don't chant the CSS mantra, it doesn't naturally follow that I don't support it or that I must support tables. Please, read posts before responding simply to try to poke fun. I'm too old to bite at such petty things.

    Quote Originally Posted by megamanXplosion
    I also find it funny that, while you are promoting table-based designs you want to curse NN4 and browsers like it, isn't that the only valid reason to be using table-based designs? Judging by the fact that you think everything should be progressing and older technologies can burn in hell, I find it hilarious that table-based designs are your preference. That tells me one thing, you are not comfortable with CSS-based design yet.

    Just my 2 cents.

  5. #55
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    CSS vs. tables shouldn't matter to the end user. This much is obvious, their page viewing experience should simply work.

    CSS vs. tables shouldn't matter to the designer either. A design environment shouldn't consist of strange codes and hacks, it should simply be highlighting, dragging and drop-down menus.

    When you use a visual environment for design, it doesn't matter so much how a page was coded as long as you can drag around the crucial nuggets of presentation code. For a long time, you could get the most consistent experience out of GoLive and Dreamweaver by using table-based designs. I believe that this is why tables are still strong, no other reason. Designing with tables by hand is a total convoluted mess, anyone who endorses it must be using an editor or enjoy convoluted messes.

    CSS vs. tables is a battle that should not even be fought at the designer level. Makers of web browsers should embrace it because it makes their products stronger. Makers of design environments (GoLive, Dreamweaver) should embrace it because it makes their products stronger. Until both these factions make their choice, their will be no definitive winner.

    If I am not mistaken, there was a time when people (in the print business) often had a hands-on familiarity with postscript. Nowadays that is useless, the tools are competent enough that interacting directly with postscript is unnecessary. I'll go on the record (and prepare to eat my words in 5 years) that it will eventually be pointless for designers to know either html or css or whatever technique supersedes them. Once the WYSIWYG tools reach a certain degree of competence, no one will need to have a hands-on understanding of the code used to compose pages.

    I've said this about coding in general before, but I am about twice as serious and 5 times as confident about this, as I believe there is a precedent in the print realm and because designers work best in visual environments.

    Now which menu has that end of rant icon?
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  6. #56
    gingham dress, army boots... silver trophy redux's Avatar
    Join Date
    Apr 2002
    Location
    Salford / Manchester / UK
    Posts
    4,838
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samsm
    Now which menu has that end of rant icon?
    it's that little box with a cross in it at the top right edge of your browser window
    re·dux (adj.): brought back; returned. used postpositively
    [latin : re-, re- + dux, leader; see duke.]
    WaSP Accessibility Task Force Member
    splintered.co.uk | photographia.co.uk | redux.deviantart.com

  7. #57
    SitePoint Addict xDev's Avatar
    Join Date
    Jul 2003
    Location
    Moncton, New Brunswick, Canada
    Posts
    247
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samsm
    I'll go on the record (and prepare to eat my words in 5 years) that it will eventually be pointless for designers to know either html or css or whatever technique supersedes them. Once the WYSIWYG tools reach a certain degree of competence, no one will need to have a hands-on understanding of the code used to compose pages.
    As long as the view-source option is still available on web documents it'll never happen. People are curious by nature and like to know how things work. The analogy to the print world doesn't hold up to the web at all. Text is the basis of documents on the web, design and style is an afterthought.

  8. #58
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by redux
    it's that little box with a cross in it at the top right edge of your browser window
    Oh no, too late! :-)

    Quote Originally Posted by xDev
    Text is the basis of documents on the web, design and style is an afterthought.
    Text is less the basis of print documents? Not sure I buy that.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  9. #59
    Huh? What now? tntcheats's Avatar
    Join Date
    Aug 2003
    Location
    BC, Canada
    Posts
    719
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I believe in hybrid design, unless I can use pure CSS.

    I'll use the basic <table><tr><td</td><td></td<td></td> for the main 3-column table, and have a header and footer div (just as the basic design) and then I'll style it all with CSS.

  10. #60
    SitePoint Member
    Join Date
    Jun 2004
    Location
    tempe
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i don't know, but i guess i can see both sides here

  11. #61
    gimme the uuuuuuuuuuu duuudie's Avatar
    Join Date
    Feb 2004
    Location
    Switzerland
    Posts
    2,253
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have been following this thread even if I haven't read every single post from the beginning so... it's time to speak I guess. I initiated a thread a few weeks ago in which I asked if it was posible to create adavanced layouts without using hacks. Let's say that the answer wasn't a loud YES. So I thought... well, I'll have to live with hacks.

    There was a thread going on here a few months ago, about hacks and new borwsers generations. The CSS forum regular members probably remember this discussion. I decided not to use hacks but honestly, for some stuff, it's handy. Really handy.

    Now using hacks (what an unprofessional word) is a non sense to me. It sounds like building something on a very fragile basis. Browsers have different behaviours, fine. That is a fact. Hacks can help unifying the way browsers will display your layouts, I can't go against that. But......... why using hacks when a bit of scripting can help you serve the right CSS to the right browser??? This article is a good start:
    http://www.sitepoint.com/article/bro...uck-php-rescue

    Honestly, I cannot understand how the use of hacks has even become part of authoritative articles. Learning a bit of PHP (or ASP, .NET, even javascript) is not the end of the world and will let you do what you want to do the clean way.

    The morale of my post is the following: knowing hacks is a good thing. It helps you understand how browsers react and what they don't understand. Using them, however, is a very bad idea because you don't know how browsers will behave in 5 years or so and that one shouldn't have to hack anything to make it work properly.

    When the strong voices of the CSS forum help other members by showing them how to use hacks, I always think that with the 'hack solution' provided another server side solution should be provided as well. Then it would be up to the member to choose his weapon. Learning these stuff is honestly not hard. If I made it, well... anyone can make it.

    just my $o.o2.


  12. #62
    there is no box baztorres's Avatar
    Join Date
    May 2004
    Location
    UK - London \ Surrey
    Posts
    372
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up good point ...

    Very good post. I agree.
    Resolving the issue at the source (in effect) by offering browser detection and then offering the correct CSS.

    This can then be ported to screen resolution and ending the debate of which is the best resolution to design for, maybe a bit of a headache, however it does make it possible to have the site displayed in the same way and as the designed \ developer intended it to be.
    Baz
    ---

  13. #63
    Huh? What now? tntcheats's Avatar
    Join Date
    Aug 2003
    Location
    BC, Canada
    Posts
    719
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I believe that as browsers evolve, and people move to better and faster and more-css-using browsers I'll evolve my design. I'll change it if these new browsers will choke on the code.

  14. #64
    Non-Member Egor's Avatar
    Join Date
    Jan 2004
    Location
    Melbourne, Australia
    Posts
    7,305
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by duuudie
    But......... why using hacks when a bit of scripting can help you serve the right CSS to the right browser???
    Thats exactly what hacks do. They feed different css to different browsers except its all kept in the one style sheet. I would not even name them hacks. Using scripting to serve the right CSS document sounds more like hacking to me.

    Using them, however, is a very bad idea because you don't know how browsers will behave in 5 years or so and that one shouldn't have to hack anything to make it work properly.
    I do not believe anyone will keep any site design the same for 5 years. And in 5 years the browsers that do need hacks will be almost obsolete.

    Just my opinion.

  15. #65
    gimme the uuuuuuuuuuu duuudie's Avatar
    Join Date
    Feb 2004
    Location
    Switzerland
    Posts
    2,253
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mstwntd
    Thats exactly what hacks do. They feed different css to different browsers except its all kept in the one style sheet.
    you can keep it all in one style sheet by renaming your style file .php instead of .css. Not that hard You're right, hacks feed different css to different browsers, going against that would be insanity. They just don't do it as it should be done as far as I'm concerned.

    Quote Originally Posted by mstwntd
    I would not even name them hacks.
    so how would you name this *coding practice*? I don't want to sound sarcastic but exploiting browsers flaws is a hack. You can obviously go against that but well...
    Code:
    {width:740px;w\idth:690px}
    that doesn't sound like a clean technic to me. Sorry but I doubt that someone will convince me of the contrary. Now, I definitly agree with the fact that knowing this trick is a good thing, knowing why you can achieve what you wanna achieve with this hack ('cause it sounds like a hack to me) is definitly a good knowledge. But using it is another story. A bit of PHP will allow you to achieve the exact same thing without using the avobe bit of code. It's just a matter of a few ifs.
    Code:
    if IE5 is watching {
    display css for the funky IE5
    }else{
    display this css
    }
    Honestly, calling this a hack is a mistake. Server side people spend a lot of time dealing with users input, forms ertc... Browsers are part of the 'user input' field. Feel free to discuss it, of course.
    I do not believe anyone will keep any site design the same for 5 years. And in 5 years the browsers that do need hacks will be almost obsolete
    I don't want to sound harsch but if your coding practice is based on the assumption that browsers needing hacks will be obsolete in 5 years, you're showing a very unprofessional attitude. I am learning all that so I definitly wouldn't call myself a pro or whatever, but doing stuff the right way is the best way to improve the users experience. You also have to take into account that in 5 years, people might still visit your site using funky browsers. Moreover, my point was that if new browsers have a weird interpretation of what *you don't call hacks*, your layout will no longer be displayed the proper way. This is obviously just a theoretical thought as I cannot predict how browsers will behave. But the most secure, the best.

  16. #66
    SitePoint Zealot Beeper's Avatar
    Join Date
    Sep 2003
    Location
    LONDON UK
    Posts
    199
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am a lowly web monkey, I work in a design agency dominated by designers who really really care about how things look.

    For years I spent time planning and creating tables to make their designs work. Now I am dipping my toe into the murky waters of CSS.

    The cross browser thing has been true since the dawn on time. I personally find I have similar issues which ever way I code, css or tables. So we work around it, learn some new ideas, take on some techniques etc.

    I am loving CSS, I still have loads to learn, absolutely loads, but there was a time when I had loads to learn about JavaScript, PHP, Flash/Actionscript, mySQL, PERL and a host of other stuff, (still do in most cases). But that's the beauty of our work, we get to expand our minds and learn things whilst getting paid. Better than pushing paper round a desk...

    If you want something to look the same on all browsers that can be delivered (apparently) to over 95% of users then go use flash. But no, we have other concerns, usability, SEO, text readers...

    It takes me longer to do it in CSS because I am still very much a beginner, but I can see how much more flexible it makes things, especially when you start using dynamic content. It won't be long until it's as quick, and then quicker than tables.

    Untill that time you'll see my around the forums asking stupid questions...
    Never argue with an idiot.
    They just drag you down to their level...
    and beat you with experience.

  17. #67
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,556
    Mentioned
    183 Post(s)
    Tagged
    6 Thread(s)
    When the strong voices of the CSS forum help other members by showing them how to use hacks, I always think that with the 'hack solution' provided another server side solution should be provided as well
    If thats a sly dig at me then you can fix your own pages in future.

    Code:
    Moreover, my point was that if new browsers have a weird interpretation of what *you don't call hacks*, your layout will no longer be displayed the proper way
    Consider the following (hack) code:
    Code:
    #test {width:400px;padding:10px}
    * htm #test {width:420px;w\idth:400px}
    Now as you recognise this is the box model hack for ie5 and 5.5.. What happens if new versions of IE don't parse the star selector hack anymore. Nothing happens the new ie gets the 400px width that it would have got anyway just like other browsers.

    Now what happens if ie5 doesn't support the star selector hack anymore? Don't be silly that browser isn't going to change it will always support the star selector hack.

    Therefore the above hack is fullproof (well nearly fullproof because a new browser could suddenly say "Hmmm... I think i'll render the star selector hack but if theres a y in the month then I won't) - even then the above code would still work.

    Armed with a proper understanding of hacks you can make your code as fullproof as possible. Armed with a proper understanding of css you don'e even need the box model hack anyway and can eliminate most other hacks by simple design changes.

    I think browser detection by scripting is a step backwards and the same logic of your argument can be applied to your scripting.
    Moreover, my point was that if new browsers have a weird interpretation of what *you don't call hacks*, your layout will no longer be displayed the proper way
    How are you going to recognise new browsers without changing your detection routines?

    Also I don't like the idea of having multiple css file to update for different browers when 2 or 3 well placed hacks can be placed next to the original code and if the need arises can be changed sitewide in a matter of seconds should something be awry.

    if you want scripting solutions then there are plenty od scripting forums on sitepoint. This is the css forum and I will offer css solutions if at all possible.

    Using hacks to support older browsers that are not going to change is fine. Using hacks that affect browsers currently in on-going development should be used with caution and should be understood.

    Anyway ,using hacks on newer browsers that adjust an element by 1 or 2 pixels isn't the end of the world if it doesn't get rendered at a later date. Using hacks for structural elements of a page should be avoided if the page doesn't function without them (albeit slightly differently).

  18. #68
    gimme the uuuuuuuuuuu duuudie's Avatar
    Join Date
    Feb 2004
    Location
    Switzerland
    Posts
    2,253
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Paul O'B
    If thats a sly dig at me then you can fix your own pages in future.
    ??? So you wouldn't help me because I have made the statement that a scripting solution could easily be provided in order to let the member chose what he wants to do? This is going personnal and this is not the point Paul. So please stay focused on the css discussion. You obvioulsy are a CSS god and I have learned most of the stuff I know from you (check your rep and this thread).
    Consider the following (hack) code:
    Code:
    #test {width:400px;padding:10px}
    * htm #test {width:420px;w\idth:400px}
    Now as you recognise this is the box model hack for ie5 and 5.5.. What happens if new versions of IE don't parse the star selector hack anymore. Nothing happens the new ie gets the 400px width that it would have got anyway just like other browsers.

    Now what happens if ie5 doesn't support the star selector hack anymore? Don't be silly that browser isn't going to change it will always support the star selector hack.

    Therefore the above hack is fullproof (well nearly fullproof because a new browser could suddenly say "Hmmm... I think i'll render the star selector hack but if theres a y in the month then I won't) - even then the above code would still work.

    Armed with a proper understanding of hacks you can make your code as fullproof as possible. Armed with a proper understanding of css you don'e even need the box model hack anyway and can eliminate most other hacks by simple design changes.
    my point was, and still is, that this is not a way that I like. Sorry but even if your explanations definitly make sense (and I don't critic them) I am still not convinced by the practice itself regarding that it takes advantage of a flaw. Can you go against this fact? I doubt it.
    I think browser detection by scripting is a step backwards and the same logic of your argument can be applied to your scripting.
    How are you going to recognise new browsers without changing your detection routines?
    I never said that this solution would be a 'coded once, coded forever' solution. Code changes will need to be made to detect new browsers. However, we can bet that new browsers will be better browsers, therefore I doubt that you would need to change your code for newer browsers if your IFs staments are designed to take care of known problems (such as IE5). Just recognize problematic browsers, not all browsers:
    Code:
    if (problematic browser is viewing) {
       display code for problematic browser
    }else{
       display code for all the good browsers
    }
    Also I don't like the idea of having multiple css file to update for different browers when 2 or 3 well placed hacks can be placed next to the original code and if the need arises can be changed sitewide in a matter of seconds should something be awry.
    multiple??? I reread my post and couldn't find the mention of multiple css files. You would need your exact same .css as before. You would just change style.css to style.php, use a few IF to fix problems and you're done.
    if you want scripting solutions then there are plenty od scripting forums on sitepoint. This is the css forum and I will offer css solutions if at all possible.
    I know, thanks. Let me quote myself:
    I always think that with the 'hack solution' provided another server side solution should be provided as well. Then it would be up to the member to choose his weapon.
    I am clearly referring to sensitive situations as I was talking about hacks (my posts were clear on this point). Now, to make it clearer: when it comes to hacks (-->sensitive situation), a little if/else should be mentionned. That was my point.
    Using hacks to support older browsers that are not going to change is fine. Using hacks that affect browsers currently in on-going development should be used with caution and should be understood.
    I would be hardly pressed not to agree with you Paul. The whole point of my first post is to mention that hacks can be avoided. Each time I have been teached a hack, I took the time to understand it, I asked more questions about it to make sure that I understood what it was doing and then I used a bit of scripting to have another solution than the original hack. This is also a personnal practice, but I keep a .css file with the hacks intact that I don't use but for discussions about them or as a reminder.

    I hope that my point will be better understood now.

  19. #69
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,556
    Mentioned
    183 Post(s)
    Tagged
    6 Thread(s)
    ??? So you wouldn't help me because I have made the statement
    Whoops - forgot the smilie - sorry

  20. #70
    gimme the uuuuuuuuuuu duuudie's Avatar
    Join Date
    Feb 2004
    Location
    Switzerland
    Posts
    2,253
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    lol.. I was suprised by your answer.

    I feel better as well

  21. #71
    Non-Member Egor's Avatar
    Join Date
    Jan 2004
    Location
    Melbourne, Australia
    Posts
    7,305
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    using server side coding to feed browsers alternative style sheets is just as bad as using so called hacks.

    What happens if a new browser that comes out says its ie5 to the browser detector script?

    THats not likely to happen though, but neither is browsers reading the hacks we use right now.

    If you look at the latest browsers - firefox, opera, safari, they ignore the hacks for older browsers, so why the hell would the makers allow them to interpret those hacks in the future?

    The people behing all the browesrs are well aware of the existing hacks, they are not complete dumbasses.

  22. #72
    Non-Member Egor's Avatar
    Join Date
    Jan 2004
    Location
    Melbourne, Australia
    Posts
    7,305
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by duuudie
    I don't want to sound harsch but if your coding practice is based on the assumption that browsers needing hacks will be obsolete in 5 years, you're showing a very unprofessional attitude. I am learning all that so I definitly wouldn't call myself a pro or whatever, but doing stuff the right way is the best way to improve the users experience. You also have to take into account that in 5 years, people might still visit your site using funky browsers. Moreover, my point was that if new browsers have a weird interpretation of what *you don't call hacks*, your layout will no longer be displayed the proper way. This is obviously just a theoretical thought as I cannot predict how browsers will behave. But the most secure, the best.
    No, actually my coding practice is based on the needs of browsers exsisting today, and the hacks are working for me, and my clients, and the end users. And in five years I will not care and ignore IE 5 and 6 as I, and most web designers ignore netscape 4 and IE 4 today.

    I am also a newbie and have only been doing web design since the end of last year, so my opinions and thoughts may not be right, but as I said above, they work for me, and I will speak my mind.

  23. #73
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,653
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Simple-you make it to default to the "new" way of doing things. Basically match for the bad rather than the good, as one can feed Opera/Gecko/KHTML the same CSS and they tend to render similarly.

    Note this is not the decision Microsoft made for .NET, which has embedded server-side browser detection. It presumes an unknown browser wants HTML 3.2 code. Of course, the company tha was supposed to be updating the <browsers> list is too busy selling browser hawk for ASP.OLD to update it, so the 7.0 series browsers get treated as if they were NS4. Ugh.

    WWB

  24. #74
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,556
    Mentioned
    183 Post(s)
    Tagged
    6 Thread(s)
    I feel better as well
    lol - you should know by now that most of my answers are tongue in cheek - and I very rarely get annoyed

    After all I can see both sides of the argument but it always seems as the argument works both ways in most situations so there doesn't seem that there can be a winner. Just a matter of personal choice

  25. #75
    there is no box baztorres's Avatar
    Join Date
    May 2004
    Location
    UK - London \ Surrey
    Posts
    372
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I can see the people do not like having seperate browser CSS file used with browser detection, why? But as a orginasational idea, is it not a valid concept? I'm only new at using CSS (since the last 2 months), is it possible to have a in style? A global one (if you will) that all pages use and then a browser specific one. This should produce cleaner CSS which should be easier to read and maintain.

    I just think that it would very much aide a more organised and easier way to build sites. Yes it may take an initial investment in time, but does this then not cancel out the ease of updating, alterating and mainting?
    Baz
    ---


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •