[UPHPU] More CSS frustration

[Mac Newbold]

Today at 11:55am, John David Anderson said:

>> I don't feel like the browsers are up to par yet to allow for so-called 
>> "pure css" implementations on web pages in a robust cross-platform way. In 
>> fact, if people are going to keep advocating table-less design, then 
>> there'd need to be an acceptable replacement. In other words, something 
>> that can properly do auto-sizing rows and columns. (No, floating divs can't 
>> do that.) The way people try to float divs, abosolute position things, and 
>> fix absolute dimensions (height and/or width) on things to make them work 
>> is a much less robust and flexible solution (even though it might be "pure 
>> css") than the corresponding implementation that may include actual tables. 
>> CSS is supposed to make it easier to change and override things, but the 
>> absolutely-sized-and-positioned floating div thing that is so popular now 
>> is so incredibly fragile that I've seen it stop working properly with 
>> changes as simple as adding or removing content or doing a text-size 
>> increase or decrease in the browser, or a font replacement.
>
> Here's a single example:
> http://developer.yahoo.com/yui/examples/grids/index.html

Did you notice that while the HTML is quite clean on these examples, they 
don't even layout properly if you have javascript turned off? The ones I 
pulled up use javascript to make the height and width constraints on the 
divs match up from one to another. How is that any less of a hack? That is 
not my idea of a robust way to build a HTML/CSS page. Why should we need 
client-side scripting to make our pages look right when they load?

> Your "incredibly fragile" experiences with CSS are most likely a minority 
> experience, and in now way compare to the flexibility in design and the firm 
> control I can have over complex layouts. CSS is now integrating with 
> JavaScript effects, allowing you to define the looks of effects and behaviors 
> in your app. Its the direction the web is moving, and I'm convinced of that.

Javascript effects (aka bells and whistles) don't mean much to me in a 
discussion about making clean maintainable robust cross-platform HTML/CSS 
pages.

I could ask for a raise of hands of people who have had experiences with 
CSS fragility in "pure css" layouts, but I don't want to flood the mail 
server. Among people I've talked to, even the pure CSS advocates admit 
quickly that there are some tricks (aka hacks) you need to know before 
you'll have good results generally.

>> It is really easy to write clean html with a bit of CSS and have it work 
>> without any hacks or contortions across all major browsers. Where I have to 
>> make good maintainable code as quickly and efficiently as possible every 
>> day, I haven't found a good way to make a living trying to make them all 
>> "pure css". But everyone is in different situations, and the same answer 
>> isn't always right given that we all have different factors and priorities 
>> involved in our decisions.
>
> This might be due, in some degree, to inexperience in working with the 
> technology. A similar argument might be made for me not using object oriented 
> design principles, or programming patterns.

I absolutely agree that people can do better with tools their familiar 
with, even if those tools might be inferior by some standard to other 
tools with which they have no experience. I've got at least as much CSS 
experience as any Average Joe, I think, and if Average Joe can't do it 
yet, then maybe it's not ready for prime time yet.

> The idea with CSS is to keep your markup semantic, and move the presentation 
> layer off the the HTML. If you're using tables to make things pretty, you 
> might as well <em> to make things italic, and <strong> to bold things. Part 
> of the reason CSS is taking hold is because it represents a philosophy of 
> separating content, markup, and presentation.

I'm not sure I understand your example in the way you intended, but I 
think you might have a point. Saying you want something <EM>phasized is 
different than asking for italics, and saying something <STRONG>ly isn't 
the same as asking for bold. <EM> and <STRONG> are semantic tags, whereas 
asking for italics or boldface are specific presentation details, just 
like <h2> and "font-size: 24px; font-weight: bold;" are semantic and 
presentation detail respectively.

> Sure, you can use tables and other tags to pragmatically get the job done, 
> but in my view, maintainable, semantic, presentation free markup will play 
> dividends in the future. There is more to code than getting something done: 
> the object with CSS is to increase separation, and make things more organized 
> and meaningful.

Separation isn't always a good thing. If try to separate things along the 
wrong lines, there is so much interconnection and interdependence between 
them (i.e. a complex interface between the two) that you in practice don't 
really benefit from the modularity and reusability and replaceability that 
was intended. I'm not saying we shouldn't sepearate our semantics and 
presentation and logic and content in an appropriate fashion. But what is 
appropriate in each case depends on a whole lot of factors.

Ways to tell you might have separated things in a less-than-perfect way:

1. If making a change would require changing things on both sides of the 
boundary (i.e. you have to make a change to the presentation to compensate 
for a change made to the semantic markup)

2. If you rarely can make common changes by editing just one file.

3. If you don't find yourself (over months or years of maintaining 
projects) replacing one of the files without replacing or majorly 
overhauling the others, perhaps the separation was unnecessary?

I'm all for benefits. Separation offers benefits. If those benefits aren't 
something you ever end up using, then how much are they really worth to 
you in your situation?

You can't really argue that the code I write (myself, or as part of work 
with my coworkers) isn't at least as maintainable (to me/us at least) as 
any code you could write your way. When you write code for a living, or 
even as a hobby, isn't it really about getting the most done in the 
shortest amount of time over the long term? Quality of the code, including 
maintainablity, modularity, separation, and any other good things, is 
something that heavily contributes to time saved over the lifetime of the 
code. If I have to invest 10 extra hours to a project to do it "ideally", 
then I'd want to be pretty sure that it will save me 10 hours or more down 
the road. If I'm spending time making code reusable that I won't ever end 
up reusing, or making code more maintainable that I will never look at 
again, what good does it do me? You're buying something with your efforts 
that doesn't get you anything in return. If it gives you satisfaction do 
to it that way, and that satisfaction is worth the price you pay for it, 
that's great, but that varies from person to person.

Maybe other people have more time on their hands than I do, but until I've 
got lots of free time, I'm planning on being careful with how I invest my 
time, in my programming projects as well as everything else. I want every 
hour I spend doing anything to be "worth it" to me as I look back on it.

For example, what do I get by contributing time/effort to UPHPU? I get to 
learn new things and hear new ideas, I get satisfaction of helping people 
(or at least trying to), I get good coworkers, build friendships, build 
business associations, and I clarify my own thoughts and opinions by 
thinking about things I might not have taken enough time to think about, 
so I become a better person and hone my skills. Are those things worth the 
time I put into it? I feel like they are. Others may disagree, who knows.

I sincerely hope I don't offend anyone nor make anyone feel like I'm 
belittling their style of doing work or their opinions or point of view. 
I've found some things that have worked really well for me (in my opinion) 
so I'm trying to share them, and I enjoy hearing what other people have 
found (good and bad) in the things they've tried, so I know if I should or 
shouldn't try it myself or recommend it to others. So my humble (really) 
apologies to anyone who I have made feel bad, now or at any other time.

Mac

P.S. Apologies to dataw0lf for not keeping this to three (very long?) 
paragraphs...

--
Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/