How far do you guys go before you decide messing up the CSS too is not worth it or do you always figure out some way or the other to get it done through css the right way?
Most of the people posting here are css experts but for newbies or mid-levelers dealing with a complex css is pretty much a nightmare.
Who decides for you guys about keeping it semantic / using CSS 3 / validate the HTML etc. Do you decide it yourselves or is it your employers / clients.
For me as these are not required by my employers / clients, I prefer to do it the way it should be done but then again I like to keep things simple by whatever method as long as it works on major browsers & the piece of code is a accepted standard.
It won't make the learning curve too high for the person who'll look at after it next. Sure I don't like to use tricks/hacks that only a few people know / can figure out to make things work.
What are your thoughts on this?
It's a case of being pragmatic ... but at the same time looking at the bigger picture.
Yes, right now you've got a really complicated piece of design to do, and you're struggling to get it to work with semantic HTML and CSS best practice. So do you give up, or do you persevere? If you've got time, and you persevere, then hopefully you'll figure out how to do it properly, and then you'll have learned something useful that will help you when you come up against a similar problem next time. Whereas if you just give up and bodge it together any old how, you'll be in the same position next time round, without a solution. So then, do you bodge it, or do you try to do it properly? If you try to do things the right way from the start, you should find you save yourself time in the long run, even if it takes a bit longer that first time.
Other times, you might know how to do it properly, but it takes up masses of code and you can't see a way to streamline it, but the bodge approach is much leaner. In that case, you have to compromise, and to do that, you have to know the pros and cons of each method. If you bodge it, what are the side-effects going to be? How badly will anyone lose out as a result? If you do it the proper way, will the extra mass of code add more problems (eg, in terms of bandwidth) than it solves. And that will depend on the situation, and will vary from one case to another.
As a general rule, I always try to do things properly – the right way is the right way for a good reason, which means that you have to have a really good reason to deliberately choose the wrong way!
At some stage in any design there comes a point where what you need to achieve cannot be done without adding extra html to achieve it. Round corners in IE6 spring to mind as a good example and if your audience is IE6 - 8 and you really want round corners then you have no choice but to add the extra elements needed to achieve that design. I don't really see that as a big problem as long as the underlying code is well structured and a couple of well placed empty elements aren't really a cause for too much grief.
Of course there are good ways to make round corners and bad ways so you would still use the minimalist approach using sprites and as few extra elements as possible. The page can still be well structured and semantic and I never see a need for decoration images to be in the html.
I see very few examples where good code is going to be more time consuming to write than writing bad code and indeed I can't really think of an example apart from the round corner scenario I mentioned.
I think the problem may be that the authhor is perhaps doing it the wrong way to start with and making it harder than it needs to be. Most css layouts are staight foward and if you follow basic rules and practices a lot of things fall into place at the start. e.g. structural html, logical headings, clearing your floats, resetting your margins, making sure everything actually fits, allow breathing space for elements, don't account for every pixel on the page etc..
Of course it does take some experience to do the above but that would be true for any discipline that you need to learn. For beginners it is a steep learning curve and things must be done in the right way or they won't work or get very complicated very quickly.
I suppose it would have been helpful for you to provide a real scenario where you think bad code is easier and we could discuss the most semantic options or alternatives. There are times when a simple table is going to be less code than the alternative and as long as its only once in a blue moon then I don't think its something to worry about too much.:)
As a general rule, I always try to do things properly – the right way is the right way for a good reason, which means that you have to have a really good reason to deliberately choose the wrong way
Would never deliberately prefer the wrong way, unless the good way is complex / not known.
Paul, you are right I began learning things the wrong way. Most of my problems come from me being able to write code on my own (in the wrong way) that works, but I need to refer to some help/sample code doing it correctly & fixing a layout problem using best practices seems much harder than doing it some way or the other.
It’s got to do with working on Asp.net here where css best practices is given the least importance, in these few years never came across anyone who is even mid- level on css. My point here is trying to use best practices; it could be a maintenance problem in the future if people don’t really want to bother about css.
I suppose it would have been helpful for you to provide a real scenario where you think bad code is easier and we could discuss the most semantic options or alternatives.
Here is an example;
Ralph.M (3rd post) provides the simplest possible solution though it’s not the right way. I see you (Paul) have a solution as well & I can figure it out but not without checking out what each line in the piece of code means. I’m sure experienced people would not need to do that , but it does looks a lot of code to achieve something simple & so do many other solutions on that post.
Ralphs solution doesn't actually solve the problem that was answered:). The inline image will force the line-height to be taller and when text wraps it will leave a big gap which is what the Op wanted to avoid. There is actually no easy (or wrong) way to do what the OP wanted in that example. An image just behaves like an inline-block element and would be no different form having a span in the same place sized to fit a background-images and using inline-block. That results in less html than the image version so it's not really helping your cause
You probably should have offered the ubiquitous equal column examples that are so easy to do in tables but difficult in css for older browsers.
I get your point though but as I mentioned before it's mainly down to a lack of understanding on how things work that lead to solutions being more convoluted than they should be. I can't really help with making everyone understand css in one go but I can at least offer solutions that show the right way to do things (most of the time). It does come down to experience and learning and I remember doing things completely the wrong way at the start and tying myself in knots so it happens to us all.
Perhaps because I had been out of school for 20+ years before the GUI came along, I learned to write well structured/organized documents. Presentation, as we know it, was not considered. Today, how many people write documents using a typewriter? No, they use that stupid and inefficient application, the word processor, where they must conflate structure/semantic-values and presentation while composing what they want to say. The end result is the difficulty in separating structure, html, from presentation, css.
The difficulties are made worse by being a graphic designer. Essentially all graphic design is aimed at print. Unless a long painful process of retraining one's self has been undertaken, the graphic designer will always have trouble with translating print design to the web. His experience lies in fitting content to the design. Likewise the "old hand" at web coding whose experience has been in table based layouts. No non-trivial table layout can be either well structured or semantic. The table coder is caught up in the silliness epitomized by the word processor.
HTML is a dead simple markup language. Take the time to learn it well, and learn to write documents that would make sense coming out of a typewriter or viewed in Lynx. CSS is not so simple, but that's where you apply your design sensibilities. Yes, I learned LaΤΕΧ (a typesetting markup language) before html, which may color my attitude.
The more time spent now learning to get it right, will mean a lot less time on down the road in coding, revision, and maintenance.
This topic is now closed. New replies are no longer allowed.