Discussion on:

How good is your HTML?

In recent months, in an effort to improve my HTML work, I've been using the W3Schools validator and trying to pin down how various browsers handle CSS.

When I first started playing with HTML, I mostly coded to the 'It works in IE' psuedo-standard. At the time CSS was just starting out.

Not great, but I can hand-code without the use of a auto-fill-in editor.

On occassion, I have to go back and looks something up...

I've been hand coding it forever, but I really wish I could be using a WYSIWYG editor. To me, editing HTML by hand is one of those mundane tasks that computers should be well suited for. Sadly, it turns out that HTML is significantly more difficult to edit (particularly in a WYSIWYG manner) that it is to render.

A few days ago, on the HTML 5 mailing list, it was explained *why*, and it made perfect sense. The problem is CSS. There is no longer a 1:1 ratio of desired effects and code to produce it. As a result, it is algorithmicly impossible to write a WYSIWYG editor that is going to work 100%, or even near 100%. It's now a problem at the same level as, say, voice recognition, or translating between Japanese and English. Without a 1:1 ratio of symbols or concepts on each side, you can't always get it right in a way that is both technically accurate, and conveys the desired meaning.

For example, the user hits "Enter". Do they want a new "paragraph" (generate a p tag), or do they want to have some space between the current element and the next one (generate a div tag)? The user selects "emphasize" for text; do they want to use the cite tag for a citation, use a span with a "this is important" CSS class, wrap it in the em tag, or wrap it in a span tag with an inline style to italicize?

J.Ja

since wysiwyg is never going to be useful as is, a new ... model ... for it:

stage 1 ) layout, set the divs.
in this, I mean the app only codes for the divs and placement.

stage 2 ) content, put it in place.
add the images and text, [ENTER] here is a p tag.

stage 3 ) styling.
here, selecting the block of text and adding things like emphasis, block quote, italics ...

not really a wysiwyg app, but as close as possible to get good code.

edit to add:

KWord already does do the layout and content separately. adding the styling as a separate stage and the html + css support would be easier than starting from scratch.

WYSIWYG has never been a good way to write markup for the Web. Even when all that we used was HTML, and there was no outside styling via CSS, WYSIWYG produced tangled masses of poorly formatted code that was very brittle and added metric tons of weight to a Webpage. We tended to get images sized by HTML, spaghetti tag nesting problems, and effectively unreadable code. The problem isn't that now it's effectively impossible to do it right: it's that anyone who thought we could really get it right with a WYSIWYG editor in the past had an insufficiently strict definition of "right". There's a lot more under the hood of good Web design than ensuring the code validates.

The right way to do it is with force-multiplier effects that still require the person writing the code to actually look at what (s)he is creating. I'm talking about simple and clean frameworks, themes and templates, code generation libraries, and other dynamic design generation tools. Even simplified markup languages (e.g., Markdown) can provide significantly improved ease of (good) design without breaking the ability to generate clean, well-formed, standards compliant code, or to render properly across browsers. In short, what's needed is syntactic sugar -- not drag-and-drop design tools that pretend they can solve all your problems in one swell foop.

If I was hiring for a Web designer, and a candidate's qualifications all centered around WYSIWYG editors -- even if not for the problem of the complex system that arises in the interaction of markup with stylesheets -- I'd just round-file that resume and move on.

I sympathize with this viewpoint, and agree with it 100% as far as development work goes. Unfortunately, the reality is, most people generate a significant portion of (if not the majority of) their typed bytes in HTML now. Blog software, email clients, various Web forum applications... more and more, HTML is the format of choice (well, not *by* the user's choice, but the application developers' choice) for rich text. The average person just is not up to the task of learning HTML, even in a simplified format. They don't care about the technical quality of the code that is produced, they care abot moving on with their day. I can't blame them, either. This is why a lot of the "semantic Web" (and anything else relying on massive taxonomy efforts by users) is never going to go very far too... users don't care if something is a "header" or not, they just want it big, bold, and centered, because to them, the display is synonymous with the meaning (which makes sense, this is how things were up until the last 10 - 20 years for most people).

So I think WYSIWYG is here to stay. The question then becomes, "how do we generate quality HTML from WYSIWYG authoring tools without needing telepathy?" and I don't think (as you argue quite well) that it is happening any time soon. Rock, meet hard place.

J.Ja

my appraisal of most WYSIWYG is very poor.

make a simple signature file with word and save as .html
or
notepad a simple pre-html file that displays correctly on any system.

Size 7:1, time to create about equal.

The MS generated one doesn't display correctly inside a lotus email system neither does it validate to any of the HTML standards.

Seems like Microsoft wants to drag the performance of the internet lower for some reason. of course I would prefer that my text not be dragged through a poorly performing java engine or silver light app unless it really needs some special functionality.

Displaying "Hello World" shouldn't require 70k of overhead.

I don't believe WYSIWYG HTML authoring tools are a "necessity" at all.

" Blog software, email clients, various Web forum applications "

The needs of Weblog software can be covered by what I already described in the preceding comment.

Email should almost never be HTML formatted anyway. Watch for my next IT Security article, tomorrow, providing an example of the kind of security issues HTML email can create.

Web forum software has even less need for drag-and-drop WYSIWYG requirements than Weblog software.

" The average person just is not up to the task of learning HTML, even in a simplified format. "

The average person seems to be able to handle BBCode just fine -- sometimes with the aid of a button to insert the code into the message so the average user doesn't have to remember how to use the tags. That's simplified HTML, y'know.

Anybody who doesn't have the wherewithal to understand how to use simplified markup like BBCode and Markdown has no business designing "rich content" anyway, because it will end up creating problems for viewers a lot of the time. In terms of their actual needs to convey the content they want to create, all they really require is line breaks and images, generally -- which sure as hell doesn't require a real WYSIWYG editor.

I'm rather annoyed by statements that normal users are too stupid or lazy to do things right as though that's justification for doing them wrong , and using a WYSIWYG editor is the wrong way to do it.

Frankly, I don't think an end user should be encouraged to inflict bad page design on others without at least understanding what they're really doing. WYSIWYG HTML editors are just tools for hiding from the understanding of what you're creating. When you have even a minimal understanding of the problems you can cause with bad design, simple HTML authoring without a WYSIWYG tool is at least as easy as with one -- and when you really understand it, the WYSIWYG tool just gets in the way. The only time it "helps", that it really makes things easier, is when you're doing things you shouldn't be doing, in my experience.

Having to think about what you're doing when you create a Webpage ensures you're going to think about how it will affect viewers beyond just how it's going to look under ideal circumstances.

" The question then becomes, "how do we generate quality HTML from WYSIWYG authoring tools without needing telepathy?" and I don't think (as you argue quite well) that it is happening any time soon."

Yeah, that's the problem: you can't get good code at current levels of technology (short of AI, basically) without having to see the code. Thus, my above statements about the inadvisability of using WYSIWYG tools.

. . . which is pretty much the problem with "modern" word processors, too.

... you'd probably disagree with it anyway, given the debates we humans have with one another over what's essential and correct.

What if you do know the code, and you know what your doing and the terriable code its writing behind the scenes.

Is it still wrong?

I always figured anything that saves time and saves money, is definitly worth looking into.

Like things like styling CSS, can be done so much easier in a WYSIWYG editor, over notepad. Even if you know the code, does it not make sense to just use the couple of clicks the WYSIWYG editor requires to generate the code for you?
And as long as the WYSIWYG mistakes are kept to a minimum, the manual fixing "should" take a lot less time then writing all the code yourself.

The problem is not that people don't know the damage they're doing with WYSIWYG editors -- it's that they're doing the damage. Someone who does know better shouldn't do the damage!

Yes, you can create the page faster in FrontPage than with a plain text editor a lot of the time, but then the page loads more slowly, and sometimes crashes browsers, and looks broken in some people's browsers. Those problems all lead to lost users. The rule of thumb for Web design used to be that every second of load time past the first two seconds lost you half your audience -- and, with a site that has broad appeal and generates revenue, that's a lot of lost money.

So you save a few hundred dollars you would otherwise have spent on a Web developer that actually knows what (s)he's doing, spending a little extra time crafting your Web presence correctly. So what? That's better than the millions of dollars you might lose over the coming year, and it's better than the increased complexity of a page that might make it easier for security crackers to use cross-site scripting against your site.

Besides, there's no reason to have to click on anything to speed up your Web design tasks. As I discussed further up the thread, you can use force-multiplying tools that provide powerful syntactic sugar abstractions so that the amount of typing you have to do to generate the majority of your code is reduced by 90%.

try this website.

http://rakion.softnyx.net

I think on opera once it told me each page view was a 2meg download. but you try.

I like to consider that the cream of the crap, everything can be done better than $oftnyx has done.

There are three categories of users here that we are discussing, and I think that it is important to differentiate them.

Group 1 are developers or some variety, who have applications that generate HTML. There developer *must* know HTML and *should* hand code it (or carefully review the output of their authoring tools and correct it where need be) to make it as correct as possible. As you point out elsewhere, good HTML is in everyone's best interest, and it provides a better user experience. If it takes a developer an extra hour to produce better HTML that will be consumed thousands or millions of times, that is a good bargain.

Group 2 are professional content producers. They are not developers per se, but they create content which appears on the Web all day long. People in marketing departments, technical writers, bloggers, etc. come to mind. I think that these people would benefit greatly from a simplified markup language like you describe. Since generating content is their job, it behooves them to spend a few minutes (or hours) to learn such a simplified system, and use it; it will make their content that much better, and their readers' lives much better too.

The third group of people are casual content producers. When I write an email, I am a casual content producer. When I post to a Web forum, I am a casual content producer. The large majority of users fall into this category most of the time, and most of those poeple fall into this category all of the time. For these users, while there may be some advantage to *others* if they generate correct HTML (even with a simplified markup language like you describe), there is no benefit *to them*. They have zero incentive to learn to do it "right", unless they are someone who derives satisfaction from doing things "right" whenever possible. Go to one of these users, try convincing them to spend some time learning to do it right, they will say, "why, the way I am doing it works just fine?" And from their standpoint (not ours), they are correct. It's not that I think that they are too stupid or too dumb to learn to do things "right", there is simply no motivation for them.

I think that what you are saying makes sense at a technical level, but I don't think that it is accomplishable at a cultural level. The genie is out of the bottle, as it were. "Group 3" users have an expectation that they can select text and click a button (or issue a keystroke command) to make text bold or italic or whatever; it would be hard (if not impossible) to convince them that learning even a simplified markup language. I think that there is hope for "Group 2" and "Group 1" users, for sure. Unfortunately. "Group 1" people are under increasing pressure more and more to get more done in the same amount of time... so they turn to frameworks and tools which are poorly written, and the mentality becomes "as long as I finish this project on time, I don't care". Again, it's an issue of motivation. I think many (if not most) users of these frameworks, tools, libraries, etc. care about doing things right, but it takes a backseat compared to "getting things done". It's not even a secondary requirement a lot of the time, it's a "nice to have". If they have a choice between two otherwise equal or nearly equal systems, they'll take the one that makes better code, but if there are significant functional differences, they'll take the one that meets their needs nearly every time.

And, of course, browser implementors haven't done anything to force or even encourage people to write good code anyways. It's like they all take the Perl approach of "do what you mean, not what you say."

J.Ja

The third group of people are casual content producers. When I write an email, I am a casual content producer.

Why are you writing HTML emails ?


When I post to a Web forum, I am a casual content producer.

The majority of Web forum apps I've seen offer simplified markup (e.g., BBCode), and people don't seem to have a problem with that.


For these users, while there may be some advantage to *others* if they generate correct HTML (even with a simplified markup language like you describe), there is no benefit *to them*.

I don't give a hot damn if they get some benefit out of screwing up other people's lives. I do not favor enabling their bad behavior.


They have zero incentive to learn to do it "right", unless they are someone who derives satisfaction from doing things "right" whenever possible.

The answer then, in my opinion, is to let them be ignorant and not get to add any "rich" formatting to their forum posts and emails. If they can't be arsed to act with courtesy toward others, I don't see any particular reason to coddle them with the tools they need to happily show dis courtesy toward others.


Go to one of these users, try convincing them to spend some time learning to do it right, they will say, "why, the way I am doing it works just fine?"

I'd rather just not provide them with the tools to do it wrong.


"Group 3" users have an expectation that they can select text and click a button (or issue a keystroke command) to make text bold or italic or whatever; it would be hard (if not impossible) to convince them that learning even a simplified markup language.

There's a big difference between italicizing text and inserting audio files into a forum post. I don't really care if you implement a clicky-button italic and bold formatting interface for your forum software, but please -- for the love of doG and all that's full of holes -- don't go beyond that level of brainless, minimal formatting when giving people the tools to make others' lives more difficult. Don't give people clicky buttons for inserting Flash objects or drop-down lists for arbitrary font size increases. It's bad enough their keyboards come with Caps Lock keys.

In the end, it looks like you're arguing against my statement about what should be done by talking about what you think is likely. I wasn't talking about likelihood; I was talking about what should be done. The two are orthogonal, or at least tangential, concepts. One is not a refutation of the other.

The same thing happens with c#. Visual Studio and SharpDevelop both use partial classes and decompose a project in ways that are counterintuitive and hard to navigate, when a simple MVC model would have been enough.

I reluctantly reverted to using a text editor for developing c# GUIs and found it a lot easier than I remembered. But I still miss autocompletion and the other benefitss of an IDE.


Getting back on topic. I hardly ever use an HTML editor and I do feel that with care one can get very good results this way. Generally I found benefits generating HTML in PHP and using the include directive for reusability.

A user entering a blog/forum entry is not creating web pages per se, but simply content that will go inside a web page.

The choices are simplified (bold, underline, etc).

The average user could not and would not understand the need for say, alt tags or properly declared doc types.

background on me:

Now I never use wysis, even for quick pages. I just can bring myself to do it. I once tried to "just do it from Word to html" to just get something up, but then I started doing finds and replace to get rid of all the bloat....etc. It's just faster to create it from scratch.

alex.kashko:

Maybe you just need to shop around for a text editor that better serves your needs. It sounds like using a text editor instead of the standard IDE suits you, and you just need a couple of features that something like Notepad doesn't provide.

While you may not be able to get exactly the same features as you get from VS.NET, you might be able to get alternate features that solve the same problems. For a more GUI-oriented mouse-driven approach, you might look into something like SciTE, which was specifically designed for programmers. If you want a more keyboard-driven option, you might give something along the lines of Vim a look.

I know it isn't going away, but that doesn't mean I have to lean on it myself. Where I work, the tool of choice is Dreamweaver and yes, I use it, but not for the WYSIWYG portion. I code in the code window, and use the "design" window to preview what I *might* see in a browser.

I spend way too much of my time removing "code" that was inserted by MS Word or some other program when someone else edited a file.

I have mentioned to many prospective employers during interviews that while, yes, I can work in Dreamweaver, ColdFusion, GoLive, FrontPage (shudder), I am primarily a flat code coder, and that I urge them to make sure that whomever they hire be able to code in flat code in case their CEO ever gets "wowed" by some new product and the old one gets tossed.

I even had a conversation with my recruiter just last week (I am on this job as a temp-to-hire) and she was bemoaning the fact that she can't find anyone with SharePoint experience. I asked her to describe what the clients are asking for. What she described was not a need for SharePoint administrators, but people who are familiar enough with Visual Studio that they can use the SharePoint Plug-in to design web-parts. That is a completely different animal. But it leads to the same WYSIWYG html type "developers". If they go in claiming to be SharePoint administrators, and all they really know is how to move web-parts around the page and give people permissions, or maybe play a bit in SharePoint Designer to make a new theme, they will not be able to fulfill the needs of the position.

Unfortunately, where I work isn't seeing the difference there either. All they care about is whether or not I can move the web-parts around and grant permissions. They aren't seeing down the road to the eventual need for customized parts, customized workflows. By the time they realize they need those, I may have moved on to something else.

so much code is just temporary anyway.

the thing I've run into is whenever someone decides to cut corners just to get something up, that project ends up lasting forever and then we end up dealing with the mistakes (crap) for a long long time.

that's what visual studio and other things help to create (the mess that is).

Sometimes I wonder if HR departments truly know what they are requesting when they say that they want people who are experienced with different WYSIWYG applications when it comes to web site development.

If they actually need things like version tracking, check in/out, workflow control and other non-code oriented processes available in a WYSIWYG application, I could see using a specific application. I can also see a certain amount of logic in specifying a specific application if they are trying to get people to support a site that has a lot of legacy content being served by ColdFusion or related products.

Overall, it would be much better if the HR departments looked for people who know the nuts and bolts of website development and aren't limited to what WYSIWYG tools have available.

It sounds like we need two different things to handle user input:

1. A filter for pasted rich text from Word that strips out the extraneous tags and attributes, leaving us with clean code that looks somewhat similar to the original.

2. A web-based rich text editor with restricted formatting features. This code is easy to analyze and fix so it will be good code.

Programmers, can generally hand code or use a tool like Dreamweaver that lets you fix the code manually.

As someone who has been handcoding (X)HTML and CSS in text editors for years, I have to say, "Right on!"

I've had to maintain sites that used WYSIWYG editors, and those memories are spiked with anguish and loathing. For one, I waded through the bloated view source panel to get things done. The other I just wound up totally rewriting -- saving the company bandwidth and removing lag.

By the way, can I send you my resume?

By the way, can I send you my resume?

Sure, if you want to -- but I don't have any jobs to offer at this point in my life. Sorry.

I sympathize with your pain, dealing with WYSIWYGed code, though.

WYSIWYG does not necessarily have to produce a tangled mess of poorly formattted code. I've used FrontPage without the extras for years and it does not produce poorly formatted code, unless you, the designer, decide you just must explictly position elements, set colors, etc.

The issue is that you can skin that cat in multiple ways. Want to indent a paragraph? You can do so with attributes or wrap the paragraph with a tag. Both are equally valid and both have their place.

Currently the heavy lifting is creating a CSS that both suits the designer as well as the writer. I'm using one now at work that was designed to ease a transition from one tool to another. It's great for supporting the old tool, but sucks for new projects. Our team is now trying to figure out the best approach to amending the CSS to support both types of projects. I'm leaning toward a script to point at the old HTML files, convert the styles to the new ones, and use a clean CSS. It's not a simple job.

doug

I once had to convert a few hundred pages from a table-based layout to a CSS layout, and in the process, completely re-design them. And the static pages had a ton of differences in the HTML, even though they looked the same to the viewer. I ended up using a monstrous regex to strip them down as much as possible. It wasn't perfect, but it did probably 80% - 90% of the heavy lifting for me, which made a multiple week job become a few day job.

J.Ja

You just helped to make my argument for me. Can you imagine how long it would have taken to do all that using nothing but a WYSIWYG editor?

Yeah, doing it in WYSIWYG would have taken a while, but to be frank, if I hadn't been working in Perl for the previous 2 or 3 years, I probably would have done just that. Perl really changed the way I think, it put me in a frame of mind where any task that appears repetitive, I immediately started wondering "how can I write a simple app or script to make my life easier?" And since then, it spread. If I have to generate a lot of text with only minor variation, I use Excel and its auto-fill functionality. I started working with PowerShell lately. I have a Visual Studio solution slowly filling up with little utility apps (I'd love to start using IronPython or IronRuby for those). And so on.

But it all comes back to Perl. What Perl gave me that no other system before it did, was a way of getting done what I needed to do, without having to worry about "correctness" or even doing things nicely. It made it a snap to just kludge together a basic processing engine and take care of the problem in 15 minutes. Most systems I deal with take 15 minutes just to get to the point where I can start addressing the problem. 15 minutes to deal with 30 minutes of work is a good investment, 30 minutes to handle 30 minutes of drudgery is not.

That's one reason why I recommend that folks spend some time with Perl, Ruby, Python or a similar system, it will help show them when, where, and how to pick the "low hanging fruit".

J.Ja

Yeah, doing it in WYSIWYG would have taken a while, but to be frank, if I hadn't been working in Perl for the previous 2 or 3 years, I probably would have done just that. Perl really changed the way I think, it put me in a frame of mind where any task that appears repetitive, I immediately started wondering "how can I write a simple app or script to make my life easier?"

In the general case, it's not really important where you learned the knack of thinking in terms of automating away the drudgery in your life. What's important is that you did so. As such, it's probably worth considering the idea that what's needed is not better WYSIWYG tools, but better distribution of the simple idea that we should abstract away drudgery with automation.

By trying to automate the wrong things (things that can't be effectively and correctly automated at this time), WYSIWYG tools often create drudgery.


If I have to generate a lot of text with only minor variation, I use Excel and its auto-fill functionality.

I usually use Vim, Perl, or Ruby, depending on the context.


What Perl gave me that no other system before it did, was a way of getting done what I needed to do, without having to worry about "correctness" or even doing things nicely.

I think you'd probably find a lot to think about in Untitled Document Syndrome, written by the guy who created Markdown. It has something to say about Perl's facility for just getting things done.

Thanks for the link, it was indeed a good read. I keep meaning to subscribe to the Daring Fireball blog. Beleive it or not, the white text on grey background is a large part of why I don't, it is so hard on my eyes to read that site.

You bring up an interesting thought for me, which is, "how do we get more people to have the 'aha moment' when it comes to drudgery?" This goes beyond WYSIWYG, but deep into the heart of why we use PCs to begin with. Most of the time, I see PCs being used as paper replacements, where there are some efficiency gains to be sure, but not too much. Using a $500 piece of equipment to type up grocery lists and play solitaire doesn't make much sense to me, but it is exactly what a lot of people do with a PC.

It took me about 10 years of heavy (4 - 8 hours per day) computer use, including learning a good number of computer languages (by the time I got to Perl, I had already worked in BASIC, Scheme, COBOL, and Pascal) to have this epiphany. I know I'm not everyone else, but I'd like to think of myself of at least "average" in intelligence, common sense, critical thinking skills, etc. If it took that long of a journey to "get it", I wonder what it would take for, say, my mother or my wife to "get it" too? I cringe whenever I see them using a computer, it's like watching my grandmother's molasses drive to the store while the paint dries and the pot boils.

If the average user has a hard time "getting" keyboard commands, I wonder what we can do to make automation more popular. Personally, I crank out little Excel and Word macros as needed to make my life easier, but I never did it before I had a job programming in Excel on a daily basis (which, incidentally, is where my isage of Excel comes from, creatures of habit and all of that).

Is it a matter of choice? In other words, when presented with a GUI and a more powerful but less obvious way of doing things, people choose the GUI? Is it a matter of education? Lack of intellectual curiosity, or maybe even "it's not my job to learn how to use this, unless my boss pays for training?" I'm really not sure.

But this is the kind of stuff that goes straight to the heart of the conception of a computer as being a truly "personal computer" like Alan Kay and others have envisioned, this idea that it does more than replace paper for basic accounting or data procssing jobs, but truly allows each person to leverage their time and personal talents.

Apple speaks a lot about this in their marketing, but the more I see of their products, the more I feel that they really don't get it. What I see coming out of Apple are ways to make it easier for people to perform tasks that Apple thinks they should be performing... easy video editing, easy photo editing, easy purchasing of music, etc. And I applaud that. But Apple is actually extraordinarily closed off if I want to do something with their tools that they have not approved. I hate to say it, but Windows Mobile is incredibly open compared to iPhone development. The reason you see a lot more activity in iPhone development, is because Apple made it easier for developers to monetize their work, and even that has quickly fallen apart as the App Store pricing flies out of control.

Way off topic here, of course.

J.Ja

I find it bulky and a pain to use. I learned HTML by sourcing pages and then tearing the coding apart to see what worked, what didn't and learned a lot of bad habits. I didn't encounter a WYSIWYG editor till I moved from webTV to a laptop. In the meantime I'd taken an online, webTV group, course in writing HTML properly and using W3C to validate my HTML.

I am sorely out of practice but there was a time when I wrote coding in my sleep and awoke to try it out!

I know most of the people here are IT techies and have a vast knowledge base, but I am a habitual student and am constantly learning.

If you are not constantly learning, you better check your vital signs because you might be dead and not know it.

tech, not management, never ever ever stops learning.

A techs approach to WYSIWYG is as a tool to take some of the humdrum crap out of the job.
A business's approach is you no longer need that expensive tech, and just humdrum crap is good enough.....

If it's a product with a definite short lifetime why waste effort.

If it's likely to be around for a decade or so then put money in to minimise maintenance costs.

Then there's the budget issue. If making it great would overrun the budget stop at good enough.

I like to produce quality. Sometimes time and budget make this impossible.

They are the ones you are definitley going to get rid of next version or may be the one after...

Quality isn't a bolt on optional extra, it's either there all the time, all the way through, implemented by everybody, or it isn't there any of it, broken by previous or next processes, and not done only by the poor tw@t who got the blame.

Been a part of those decisions before.

"just get it up"

"ok"

....6 months later

"so, we gonna redo that or replace it?"

"nope, no budget and well, it's still working"


anyone else relate?

On one of my jobs I had to write an SQL query using a two million record database to display payroll numbers for three different time periods. The person wanting it, the CEO, just wanted something quick and dirty, a one shot program. Because of the limits of the query program and the database, I had to do some fairly fancy data extraction to get the results.

The next month he wanted the same report, but for a different time period. I suggested that a program be written, but that suggestion was rejected because it would take too much time.

The 'one shot' program became a manually tweaked production run. It was not going away.

Several months later, when I changed jobs and moved out of state, I showed my replacement what I was doing and how it could be done better with a simple set of programs. Hopefully he wrote something to do the work.

From the one off batch program, to the we'll just do this in access once, to the quick bodge, we'll refactor in the next version.

There's temporarily permanent and permanently temporary, all else is BS, until it won't work anymore and our wands run out of sparkles.

... it is hard to not write good HTML. My experience has been that it is no more difficult to write good HTML than bad, *once you've learned it.* When I get slowed down, it's because I am doing something I don't know off the top of my head, and I go look it up instead of just winging it. Overall, I don't generate enough HTML in any given day (heck, week or month for that matter) for a few minutes worth of looking up to make a big difference. On that note, I have become a fan of Microsoft Expression Web. I do all of my edits in the source code window and use the "design" window strictly as a preview, but I really like its instant validation, and that it treats invald HTML the same way Visual Studio treats code that won't compile. Really hammers it into my head to make some changes. A good example, for a long time, I would camel case my event handlers, like: onChange="javascript...". Now I don't, since it was getting on my back about how all attributes must be lowercase.

J.Ja

Don't forget that just because something validates according to W3C, it is going to render well in all browsers. At minimum you should test your code against:

* IE 6 & 7
* Firefox (3 & ???)
* Chrome
* Safari

And I'm just talking about Windoze here, let alone Apple or Linux. I doubt most projects have the testing capabilities to do more than IE 6 or 7 and Firefox.

doug

... for even a cheap, used Mac mini in the office for testing. Never. I nevr quite understood why not. You're working on a million dollar budget, and you can't get $300 for a Mac mini to test with. Even when you get the budget, the IT department revolts, because it means that you have a device on the network that they can't patch/monitor/control via Active Directory and other tools. Ditto for Linux. At least with that, I can easy do it in a VM without approval.

J.Ja

That's what you get when you let "paper experts" -- people whose qualifications are based more on pieces of paper (like MCSEs) than on skills, aptitudes, and attitudes toward technology -- run the network.

Quite honestly that is why I hand code. I use xhtml, css and php 5.x. I hand code to make sure I get what I want. It is these choices that make it interesting. I try to find the best and most compliant way to accomplish what the page and client want. I also always check my code against w3c validators. They are not perfect, but it's the best I have found.

Best,
Scott

I think that HTML is perfectly fine, the problem is that we use CSS to style it. I remember the days that all I had to do was slap a table on the screen and give it a few properties and there was not earthly god that would move my table from its place. Now I have to worry about margins and padding and positioning. This sticks. I think that css should be build to cater to the developer not the other way around. But since this a client based world the design comes first then the functionality.
Look and feel then work and sweat...

I agree with all the pain points of CSS (like how FF and IE treat padding and div size differently).

But, if you've ever needed to change all h1s (you use h1s, right?) or how about changing all UL list-styles to some image, etc, CSS saves tons-o-time.

... the ability to apply different stylesheets for different presentations: screen, print, mobile, or even user-defined preferences.

Besides, moving the styling to a stylesheet separates semantic content from presentation, which gives the HTML more meaning.

I understand that CSS saves tons of time and yes I do use H1. But there is just something about the way css deals with it. If they are worried about dominance of the browser world then do not worry about how the page displays, make the page style standard and just worry about the features that you develop around it to work with these standards. Countless times I have switch from FF to IE just to use a feature or to make sure that it looks right on boths sides, but now I just hire a designer and let him worry about that for me. I'm tired of dealing with the way something looks I rather deal with the way something works.

In your example, I would have the tool create a new element that has exactly the same attributes as the previous. If it was a straight , use that. If it has attributes, such as a class setting, use the same class setting.

Personally I use Xemacs with HTML mode and FrontPage with no extensions when I cannot recall the tag parameters, then look at it again in Xemacs as I like my HTML to look good as well as render well.

doug

I know exactly what you mean. One thing I sort of miss from the pre-CSS days, was that browser differences were fairly limited, and in pretty easy to fix ways. Now, most of the differences are in CSS interpretation, not HTML interpretation, and CSS is much, much harder to troubleshoot and debug, in my opinion! You can't exactly query the Web browser "why is that image flush against that paragraph, and not 3 pixels away from it like I asked?"

J.Ja

And its not so much that something in CSS doesn't work in one browser (although there are a few of those), but that it works differently.