Apps

How good is your HTML?

Most developers will tell you that they write HTML according to the specification, yet not all of those developers have read the specification. So, do you write high-quality HTML, or does your HTML simply work?

One of the interesting things that keep coming up on the HTML 5 mailing list is how few Web pages properly validate against the HTML standard. Ask any developer though, and they will usually tell you that they write HTML according to the specification. Ask those same developers if they have actually read the HTML specification, and most of them will say they have not. I think that part of the confusion is because many programmers assume that their HTML is well written if it displays as intended in a browser that "adheres to the HTML specification." So, time for some honesty... do you actually write high-quality HTML, or does it simply work (or not work)?

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides. --------------------------------------------------------------------------------------------------------------- Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

143 comments
mikifinaz1
mikifinaz1

And if you are a professional, it pays to validate all your code, even HTML script, everyone is not using IE.

dementeddwarf
dementeddwarf

I work for a state entity that demands (and laws insist) that I code for accessibility. Though my pages don't always look the way I would like, they are accessible to all. My major problem is having code that works in all browsers EXCEPT Internet Explorer. I know they are improving but there are still too many users out there using 6 or under.

Slayer_
Slayer_

Is that what you mean't to say? I am not sure of the coding differences between IE6 and IE7. I still use IE 5.5SP2 on some of my systems. Loads most webpages just fine.

chris
chris

I never guessed you poeple would be THIS into web coding. Anyone miss the good ol days of tables and those cute little ants running around? hahahah just kidding.

Sterling chip Camden
Sterling chip Camden

... were for sissies. Use FRAMES. just kidding.

Geek3001
Geek3001

Some people may not see the 'just kidding' comment. While I have used FRAMES, I prefer to avoid them nowadays. They definitely had a steep learning curve when they first came out.

Geek3001
Geek3001

I recently took a look at some of the stuff I did over a decade ago, when everything was in the HTML and tables were the way to do formatting. It wasn't pretty, both from a maintenance standpoint and a 'code' clarity standpoint. I'm VERY glad things have improved over the years. More recent content is trying to take advantage of newer technologies that should allow me to leverage things. I love the fact that you can change the entire look and feel of a well designed web site simply by changing the CSS, as opposed to the old style technique of scan and replace HTML 'code.'

techrepublic
techrepublic

My first web page was in 2000 written with notepad learning html by viewing source code. It was so much fun I studied html and upgraded to CuteHTML for my editor. I used that until a month ago when I accepted the fact that it was time for a new editor that had an up to date code base for auto-completion. I have never made a web page with a wysiwyg editor. I tested a few, at times when I thought about how nice it would be to make pages a little quicker, but I didn't like the code they produced. Now my coding is a decent speed, so I have no need for wysiwyg. I use PSP to throw together a look for a page, then when I have the look I want, I write the code to make it. My coding isn't perfect though. Until about a year ago, I never really understood the importance of the doctype tag. I always thought basic html didn't need it, so I have many websites full of pages with no doctype line, and since html didn't require closing tags at one time, most of my past work wouldn't pass a validation. I've been doing sites since 2000, so I have many that need to be updated someday, but now I don't have the free time to do that. Every page I do is tested in Firefox, IE and Opera, and important sites are tested in a few others as well. All work now uses the doctype line and all closing tags and most would pass the validation test. The fun part will be going back and fixing/updating all my older pages and sites.

urmiparikh08
urmiparikh08

i am new with webpages. i have started with HTML coding and all. i read you use PSP to see different looks and then dicide on which looks the best, i think that helps because you dont have to keep coding for different looks to decide which looks the best, it saves good amount of coding time. so tell me what is PSP & its use in detail

techrepublic
techrepublic

Paint Shop Pro is a less expensive, but just about as good, alternative to Photo Shop. With PSP I start with a blank image and add graphics by adding other images or creating them as layers. I can just drag them around so it's easy to play around a little. When I create images, like menu buttons, I create them as vectors so they can be resized easily without losing quality. I put together the graphics, then add text, again as vectors so they can be adjusted easily. Once I have what I want, I save the different layers as individual images, then write the code to make the page.

apotheon
apotheon

There was a time when I hadn't heard of standards compliant code or doctype declarations. Thankfully, those dark days are long gone. edit: I just wish doctype declarations were simpler and cleaner.

Justin James
Justin James

The DOCTYPE for HTML 5 is one of the most hotly debate items out there that does not involve accessibility. I am not making this up. They *are* trying to make it simpler and cleaner (something like 90% of pages have invalid DOCTYPEs!) though. The problem seems to be (from what I can tell, my eyes glaze over at some of this stuff)how XML or XSLT parsers seem to handle it, I get the impression that making a really simple DOCTYPE would significantly "break the Web" for some reason. J.Ja

Geek3001
Geek3001

When I first started playing with validated HTML/XHTML, I had problems with DOCTYPEs. For something that basically says 'Use this set of rules for validation,' the DOCTYPE code is awfully wordy. You would think that W3.ORG would make things shorter, perhaps even establishing a separate URL to handle such. A doc type like the following: could be replaced by: and the only thing that would change would be the "HTML 4.01 Transitional" part of the DOCTYPE. And even that could be simplified by using standardized codes like HTML401T. (Of course, there are probably issues that I don't know about that would make this type of solution unreasonable.)

chris
chris

You either write good HTML/XHTML code or you don't. And an excuse of just to make it work isn't good enough in my books.

mauco
mauco

With all the fancy tools out there now, I wouldn't be surprised if most of us aren't as good as we used to be - myself inclusive. But this is a wake up call. But what I know is that its best to rely on your HTML skills than all these WYSIWYG tools. Hand coding always takes you farther and lets you know what's happening under the hood.

wsargent
wsargent

I like to write 100% compliant HTML for two reasons: #1 it's faster - noticeably faster when the browser is in standards-mode, versus quirks mode. #2 it helps me find bugs more quickly. My pet peeves are Flash and those darn query strings. They ruin everything. ;-) I know there are tweaks for the Flash code, but Adobe should fix it, not me. I bought Dreamweaver 2.0 in 1998. Used it for about a week and decided that hand-coding was for me. Then I learned Perl to eliminate the tedious parts with templates and been doing that ever since. :-) Web designers who don't like HTML are like surgeons who don't like the sight of blood. Who wants an appendectomy from an organ designer using HospitalWeaver 3.4?

ptc4free
ptc4free

People who use editors like dream weaver to generate PHP/ASP along with the HTML. There is where the most risk is... If your page doesnt display correctly on every single client, oh well, but if someone finds a whole into your server, oh crap. You just had client information stolen and your server set up as a spam relay. Honestly I see where wysig-asdfsaf (why the hell is the name so long......), should not be around. But Casual content should be easy to put up. Period. Ease of use and acceptability are #1 and #2 of rules for any userbase. Whether your a blogging site or a forum. Anyone in webdesign should either create their own "quick click" tools, or share and carefully scrutinize and understand other coders tools. I'm self taught in HTML, CSS, PHP, SQL, and many other programming languages over around four years. I'd say I'm on an intermediate level at least. It is far faster to create my own code, in a base text editor, maybe one with syntax highlighting at most. I like my documents blank and fresh so I know what is in it, from the very beginning. I use a doc type I feel is appropriate (usually xhtml strict)and check its validation. In addition to css validation, you still need to do cross computer and browser checks to see how things display. Even with "perfect" code your site will not always display the same in every browser, resolution, and other configurations. Moral of this all... if you are the one creating a web page, and its not something simple like a blog post, code the damn thing yourself. No matter you skill level, if its hard GOOD, you'll learn from it.

wsargent
wsargent

Oh. Does Dreamweaver give you boilerplate PHP/ASP to pop in? hehe... Sure. It's a security risk, but I am not sure it is necessarily worse than half the stuff that's out there.

CharlieSpencer
CharlieSpencer

I use a WYSIWYG tool called SiteSpinner. I've run the results past W3C a couple of times and failed miserably. On the other had, I'm not developing web sites for a living. I have a single site with less than a dozen pages. I have a target audience of less than thirty people, all known by name and who have no problems viewing the site. For my purposes, it isn't worth learning to hand-code.

Oz_Media
Oz_Media

I used to write all my own HTML code but now since I've been focused more on learning search engine algorhythms and positioning, I use Dreamweaver for my code and simply tweak the output to the browser it is focused at. DW used to write a lot of redundant code but is prettt good now. As far as validation, DW allows me to test various browsers and edit markup to make it compliant. More important to me now is the perfect balance between number of keywords to body copy so as not to have a browser disqualify or penalize my positions due to over tagging(weighting). I also focus on hidden tags such as Alt tags which make a heap of difference with positioning and lets yuo get in extra keyword qualifiers without over tagging your header and losing position. HTML is just the ground roots that I don't need to focus my time on anymore as there are tools to simplfy and automate that process.

Grayson Peddie
Grayson Peddie

Even if I use ASP.net 3.5/C#, I tend to focus entirely on HTML/CSS. I did not use tables, except for data. I'm developing a home automation website for controlling lights and security (I will implememnt a log-in system, which is no big deal as only I will access it). EDIT: Not meant as a reply to post above me. I need to get used to TechRepublic's website... The layout in Talkback is different from ZDNet's. :(

santeewelding
santeewelding

I actually understand a lot of this. You guys have been very good teachers all my while here.

boxfiddler
boxfiddler

Works in each of the major browsers in which I've tested it. I don't use an editor, just write the code in Notepad and run it through my browsers. Don't mess with CSS, either.

chris
chris

try Komodo or Quanta+ (linux). the tag completion and CSS integration makes it worth it. PS both are legal freeware and you are still writing all the code manually.

Sterling chip Camden
Sterling chip Camden

Do you use tables for layout then?

PhilippeV
PhilippeV

There are still lots of progress to do in HTML to better support the various presentation layouts. Notably HTML is still too much structured with a very basic 1D layout only structured between unconstrained horizontal inline contents and block contents aligned in a vertical stack of blocks. Even for tables, the grid model is still not very good at specifying the grid constraints properly: for example there's no easy way to align two tables or grids, unless you merge those grids in a single one (this breaks the data structure, and the document/layout separation). What site builders want is more control on the layout and a smarter control of the layout constraints (for example when adapting to various screen sizes or device capabilities, or paper formats when printing). One of the mot wanted support would be to stop using tables to use columns in a way that can adapt to various screen sizes (the number of columns needed to render a part shuold be automatic, and their content should be spread equally without having to decide, in the document code itself, where a column break should occur). The same is true for graphics as users want more interaction with them: this is where Flash has proven to be useful. There's a key emerging standard that is maturing there: SVG. It is fully XML conforming, it adopts the CSS standard for styling it, it can work with dynamic scripts, and it supports the embedding of texts and even bitmaps to which it can also apply rendering filters (or "shading" streams) and that can be combined together to produce other streams. The natural evolution of SVG will be to integrate the 3D modeling (and for browsers implementing it, it support 3D navigation as well), and audio and video support plus the synchronisation of streams in time (integrate the SMIL standard). May be some day, SVG (which already has a DOM and supports active scripts and internationalization) will have enough capabilities to replace HTML completely (it already supports links), and there's no reason why SVG would not be as good as Flash (or silverLight) for making any kind of applications or web services. The key advantageof SVG is that it is developed as an open standard instead of the proprietary Flash or SilverLight solutions... And in fact, if you look closely in Flash or Silverlight, they have been created using the same concept as SVG, and have also integrated the extensions and facilities proposed in SVG itself... Now let's require that all browsers implement SVG natively.

Oz_Media
Oz_Media

I had used css mainly for sitewide text formatting, headers etc. Since Fireworks offered an dimproved export to css option for page design, I started using more and mroe css in conjuction with it. Seemed to be the easiest way for me to learn anyway. I avoid nested tables as search engines don't dig enough when indexing and positioning your site. But I have found that simple, single layer tables are engine friendly enough, for most search engines, and don't detract from positioning.

boxfiddler
boxfiddler

I misunderstand CSS. And use it without having realized it, until your question. Thanks for asking it. I only barely work with HTML, for my own purpose. Opened a book, got to work, have been playing in it since. Barely geeky, too, I often have to read tech things multiple times for meaning to set in. Sheesh. :D

Justin James
Justin James

... is miserable, because browsers love to implement the CSS standards a bit differently, from my experience. 90% (if not more) of my "HTML" difficulties are really CSS issues, and almost all of them are regarding positioning/aligment/sizing/etc. J.Ja

Geek3001
Geek3001

That is a very good point. I have heard what JAWS does with a web site and cringe when some sites are 'displayed.' (JAWS is a program that allows the visually impaired to run programs, including browsers.)

chris
chris

if you ever work on a project that might actually be used by someone who can't see, your table use makes their time on your site maddening. now, how often does that happen to the average hobbyist? don't know, but if you weren't aware of that fact, there are reasons for doing away with tables other than just loving CSS.

rebeccaaward
rebeccaaward

I will admit, this was later on my list as well. When I started using CSS, I only used it for colors, headings, styles, that type of thing. It was only a year and a half or two ago that I started using it for placement on the page. Now I prefer to use it for placement compared to tables, nbsp or sized invisible graphics. The only time I used tables now is when I have tabular data to display.

skyemacm
skyemacm

I use CSS for controlling fonts, color on the page, etc. Have not been successful using it for placement. So I stick with tables. This works well for me.

apotheon
apotheon

I'm better at using the English language properly than most English teachers -- but I still have to think about it (and sometimes even look it up) to remember whether something is a "preposition" or a "participle". When I see a sentence with a dangling participle, though, I know it's wrong.

Geek3001
Geek3001

It is often a matter of understanding the jargon involved with different aspects of technology. I suspect that there are a lot of people out there that know how to do things but don't know the 'proper' jargon for what they are doing. This is especially true if you learn things informally through websites and books.

boxfiddler
boxfiddler

I do a double-check on what CSS is. I look at an example, and lo and behold that's what I've coded in Notepad. Ah... this brain. :D

jck
jck

I don't do intricate web design. If I need spacing, the ampersand-nbsp works still. I mostly edit and modify. I will occassionally steal someones style definitions and reuse them in another page, section, whatever. But, I just don't do lots of web... yet that is. lol.

Jaqui
Jaqui

I test script even generated html pages against the w3c validator. I keep tweaking until it passes. and I only use the STRICT DTD. then I go further and test the css against the w3c validator, it has to pass as well.

chris
chris

what a lot people don't know is that with correct doc type and being valid many of them pesky browser issues go away....even if you just add xhtml transitional. strict is even better of course. PS what do you do for offsite links? targe="_blank" is apparently evil. do you just throw the user there (no new window)?

Beauregard T. Shagnasty
Beauregard T. Shagnasty

Using XHTML is mostly pointless. Transitional is for, well, transitioning legacy pages when you don't have time to completely rewrite the 1990s code. Further, a proper XHTML doctype with XML prolog will throw Internet Explorer into Quirks Mode. Properly served XHTML - as application/xhtml+xml - causes Internet Explorer to just offer to "download the file." Serving XHTML as text/html is also pointless. http://tekrider.net/html/doctype.php Bottom line? Use HTML 4.01 Strict. Oh, about target-"blank"? See this: http://tekrider.net/pages/faq.php?q=osl

Justin James
Justin James

But we wouldn't have you any other way. :) J.Ja

Jaqui
Jaqui

I'm consistent in my oddity. :D I have always said that meeting standards is a good thing. :D

apotheon
apotheon

I've been reading your comments in this thread and, thus far, I'm pretty sure I'd hire you if you showed up on my doorstep looking for a job. edit: . . . assuming I had a job to give, that is.

rebeccaaward
rebeccaaward

I use validators on the code that I am allowed to validate. Some of the code I write is for intranet/privileged use only, so I am not allowed to use an external validator in any fashion. But like some have said, I continue to check my code and test it until I am satisfied that it is compliant not only with these standards but with the standards created by my employer (content standards). Does this take longer? You bet. But I have explained to my employer that if they want a page to go out before I am completely satisfied, that I won't back it up. I am not here to make friends. I am here to do a job, and to do it properly. I can make friends elsewhere.

apotheon
apotheon

Sometimes -- when one has that luxury -- code generated by a framework that doesn't validate is a sign you should be using a different framework. Other times, it may be easier to write your own than to make the framework in question work, and there may not be a separate preëxisting framework that fills your needs.

Sterling chip Camden
Sterling chip Camden

I'll validate my own creations, but stuff that gets generated by frameworks can be massive and take a long time to figure out how to tweak it to be correct.

Geek3001
Geek3001

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.

alaniane
alaniane

I generally try to avoid having to write HTML. Of course, I'm not a web developer and the only time I use html is when I need to take data from my application or the database and display in a browser. Most of the time I write functions that generate the html on the fly to plug into the existing corporate Intranet site. Basically, I only write HTML when I have no other choice. I'm probably also committing every unpardonable sin out there when it comes to HTML by using tables for my data, but then again I'm not writing publicly accessible websites and I'm not overly concerned about being standards compliant outside of being compliant with the corporate site's standards and the HTML being generated is pretty basic stuff.

montanasman
montanasman

I develop to IE and FireFox. I always validate with W3C validators for HTML and CSS. With todays available editors there is no reason not to use good form and identify the doctype. I use Dreamweaver and InterDev, but my favorite it EditPlus. It is cheap and has references for most all extensions. I was shocked at the number of people just don't care about form. I guess thats why they have trouble getting "ranked".

sgrebenyuk
sgrebenyuk

Interesting, CSS started way before the end of last century, and the total approach has changed since that. Same is with HTML. Almost nobody uses naked HTML anymore. it either xhtml, or similar. W3 is a good site to look at... for your own education, but if you are wondering why is your site not so popular, as others, it has almost nothing to do with HTML codding. What was your questions? I don't see it listed Thanks, Sasha http://www.oco-inc.com

TechRepublic
TechRepublic

My biggest frustration with the new 'standards' is the LOSS of functionality and flexibility while yet adding to the complexity of a system overall. For instance, under strict HTML you can't specify a width on an inline element?!?! How silly is that! Sure it is inline and you want to behave as inline but what is wrong with being able to set its width if you need to. Bye bye the nice form layout using labels with width. Sure you can make it work but NOW it takes twice as much coding or tricks! Standards, HAH!

Justin James
Justin James

It's not that the functionality is gone, it's just been moved to CSS... ;) J.Ja

apotheon
apotheon

Some of that functionality is either missing or gone, now. There are times I just want to center something, and nothing I do in CSS seems to work. Until the W3C gets its head screwed on straight, thank goodness for Transitional.

chris
chris

[span style="width:blah;"]stuff[/span]??? or using a class or something? PS I have not looked up that "rule" so I am actually asking.

kgunnIT
kgunnIT

When it comes to programming in general, be it winforms, html, linux apps, whatever, I am a perfectionist. My desk can be a clutter, but my code, I want the code to be clean, organized, and I want my code to be 100% error free and compliant to the standards. Every web page I have created so far I work on it until it passes W3C standards, including my CSS validating, the whole works. I don't consider the page to be complete until it passes. I also test my webpage on multiple platforms using multiple browsers to make sure that it renders the way I(!) want it to render. I do all of my own coding, not these fancy, code-for-me programs. I want to see my own code, makes troubleshooting a lot easier. I use just a basic text-editor to get the job done.

Beauregard T. Shagnasty
Beauregard T. Shagnasty

Geek301 said: "I've been using the W3Schools validator..." Hopefully, you are not confusing w3schools.com with the W3C. Those two entities are not related or connected in any way. If you ask in Usenet, say in comp.infosystems.www.authoring.html, about the value of w3schools.com, you will learn that the site is fraught with errors. The validators live at: [http://validator.w3.org/] and [http://jigsaw.w3.org/css-validator/]

Justin James
Justin James

The validator at validator.nu is excellent as well. The author/maintainer is insanely active on the HTML 5 list, and he is constantly spotting descrepencies in the specs due to his work on the validator. J.Ja

Geek3001
Geek3001

I am aware of the difference between w3schools.com and the W3C. And I have discovered some errors myself, when comparing the information they have to reference books I have available. I'll definitely keep in mind the Usenet evaluation though. My use of the site is mainly as a review for those topics I've studied before and a Beginner's Tutorial for topics I've only heard about. It gives me a start at the jargon being used so I have a chance of asking the right questions when I want to do something a bit more complex. They do have links to the validators you mentioned though.

rbresten
rbresten

Well, I'm pretty good at HTML as of now, although i've been lax as or recently cause I haven't bothered to update my site at all.

Slayer_
Slayer_

My website is over a year since it was updated. Copyright hasn't been updated since 2006 :)

Slayer_
Slayer_

I do know how to code HTML and the tags etc. I understand how they all work, and I know how to use google to figure out the CSS I want. But the frustration of, oh this only works for this browser, or this only works if you have all this in place, or if it's used here, is really anouying me. So I mostly just use Dreamweaver, set it to try and adhear to standards, and go at it. Occasionally fixing the botched code it occasionally makes. I frankly don't even bother testing in alternate browsers anymore, if you avoid aslignment CSS it seems you can pretty much always make cross compatible code. It will be nice when IE8 actually conforms to a standard, should make testing a bit easier. If all the different browsers conformed to a standard (any standard would do), this would be epicly easier.... FYI to any critisizers, I don't make corporate webpages or anything, they are all personal pages for various reasons.

chris
chris

Anyone who is designing pages for someone else (can I say professionals) vs those who do it for themselves (hobbyists). The thing I hate, as a professional is code that was created poorly by whoever went before. Sure it displayed fine, but now I have to fix things in 40 places instead of just once in a Style Sheet of maybe a PHP include file.

irene
irene

For years I used Homesite and swore by it. WYSIWYN (What you see is what you need) was their motto. I resisted Dreamweaver, but finally bit the bullet and bought the Adobe CS3 web suite. I love it and it has made me much more efficient. I'm still in the code most of the time, but it has a feature that allows a "split" so you can find where you need to be in the WYSIWYG part and then fix it in the code. Furthermore, it has autocomplete, which sometimes completes by typing one letter, saving a mess of time. Its template features are also great time savers. Make a change in your basic template and it changes in all the pages based on it. There are things that WYSIWYG is better for, like making minor text changes or changing information in a table. But as far as constructing a page, the bare code is the way to go. Nothing wrong with using good tools, though. Still swear by TopStyle for CSS.

Justin James
Justin James

I loved HomeSite too. When it died, I ended up using basic text editors for a while. The last time I used Dreamweaver was 2001 or so (the MX years) and I hated it. I haven't used it since, so I can't say. A few years ago, I started using W3C's Amaya, but it is a really buggy app, so I went back to plain text editors. I have been *slowly* easing into Microsoft Expression Web, which reminds me a lot of HomeSite, and works the way you describe Dreamweaver working. I agree that TopStyle is excellent. J.Ja

apotheon
apotheon

It doesn't sound like the WYSIWYG features of Dreamweaver are really the features of it you like.

Geek3001
Geek3001

I use an older version of Dreamweaver (MX?) and can get reasonable results with it. My biggest problem is that I haven't figured out how to keep it from undoing my content indentation, especially when I use DIV tags. I tend to be picky about indentation because, for me, it tends to make things easier to read.

Geek3001
Geek3001

I'll give the preferences another try in MX. I seem to recall looking in that area, but sometimes a second or third or even fourth look is needed.

Oz_Media
Oz_Media

A guy that was helpng me with some Fireworks to CSS conversion a year ago wrote a script for Fireworks that Adobe has added to CS4. It allows for you to create a full graphic page in Fireworks, and it makes a seamless css page from it. Obviously you have to work out your content DIVS but the alignment/overlap issue is instantly resolved and it really makes page design and changes extremely fast. Simply opening the page in Dreamweaver allows to to cross edit individual graphics, colours etc straigh through fireworks and then it applies it and updates the css for you too. Really haven't found a better set of tools than the Macromedia/AAdobe suites. I now use CS4 master edition, more than I need but extra tools are always nice even though I prefer Fireworks and rarely use Photoshop. I'm not sure about MX, that was a few years back for me now, but I think it, or later versions, allow you to control what code is and what isn't indented and how far the indent is through the 'preferences'. Worth looking to the Exchange for, I couldn't tell you how to get to it off the top of my head.

Slayer_
Slayer_

And have similar problems, however I tend to just use table formatting, of which dreamweaver does a really nice job of. But when i use such things, I tend to need to drop down into code and do it manually. But considering how much effort the tool saves, I'd say its worth it.

Justin James
Justin James

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

apotheon
apotheon

One part of the reason for that problem is that some browser developers just won't properly implement the standard, and it annoys the crap out of me. Another part of the reason is that the standard itself is kind of full of crap. The basic ideas are excellent, but I think the standards committees must be far too hung up on visions of a "pure" Semantic Web in all its glory to realize that what Web designers really need out of a presentation language is the ability to specify presentation details quickly, easily, and in a maintainable manner, without interfering with the ability to create what is actually envisioned for the Website.

apotheon
apotheon

I'm pretty sure Firefox does "take away" from width for padding. The point where different browsers sometimes differ is on whether margins should go inside or outside the width specification.

apotheon
apotheon

As I've pointed out elsewhere in this discussion, libraries and frameworks can be a real boon for the standards-compliant developer, assuming you have the right library or framework. One can even code up such a thing oneself, for very domain-specific purposes, pretty easily sometimes.

apotheon
apotheon

HTMLKit was excellent, the last time I used it. I much prefer a highly functional keyboard driven text processor like Vim over any clicky mouse-driven GUI text editor, but if I had to use the clicky style editor on MS Windows, I'd definitely investigate whether HTMLKit was up to its previous standards of awesomeness.

chris
chris

quanta +, komodo do a good job making sure you get your tags closed (and I think it even warns you if you have them interlaced, but I cannot remember) HTML Kit does a good job create anchor tags to other pages and img inserts.

chris
chris

it's not gonna happen, but it would be great if the big boys would just do an end run. that way you start with the real world issue and go backwards. like, as you mentioned div width, padding, borders, and margins, etc. EG: to me (and I think a lot of actual logical humans), 'width' should be absolute and padding would take away from the inside dimension (like a box in the real world with foam put into it). Can someone tell FF that for me?

chris
chris

hahahaha, sorry. It's just a bunch of crud-ola and gonna stay that way for a while :-(

chris
chris

to the hurt of everyone. they are trying to rectify what they see as the wrongs of html4 (presentation code intermixing, etc), but they end up with half this and that, never getting their and just making everyone else suffer. they should just start over instead of trying to fix it (if that's what they want)

angdis-bb
angdis-bb

When I first tried to put together jsp's, I bent over backwards trying to be standard and validate-able. I did everything I could to understand the intent and usage of XHTML and CSS. I have to conclude that it was a waste of time. As long as browsers differ over the interpretation of XHTML and CSS, we are wasting brain cells working on stupid compatibility problems that should never exist in the first place. The only solid solution I see to to use a toolkit like GWT and stay away from writing html, css and javascript. Let other people worry about compatibility problems and use the fruit of their labor (which is prodigious).

alan.jackson
alan.jackson

"Most browser developers, most standards working group members, and most markup coders -- all of them, together -- are to blame...." Most browser developers want to be standards compliant. Historically, it's the lead supplier that has'nt. We have the standards working group members to thank for the high quality of standards in existence, despite the huge pressures they are put under from a commercial front. In "Coders" I assume you mean those web developers who have to meet some overpaid executives "bright vision" of a new corporate web presence. True, HTML was originally a developed for distributing information, but with presentation a key factor. Thankfully, thanks to CSS (another standard), separation of data and presentation can be achieved. Today, XML means many things to many people. As it has found it's way into Network security, the control of Standards become all the more important.

PhilippeV
PhilippeV

It's true that HTML was a subset of SGML and it was the case up to HTML4. It's also true that HTML5 preserves a good (but imperfect) compatibility with HTML4 and lower, however it derives from XHTML and not HTML4. It's also true than XHTML is an application (i.e. a subset) of XML that has more restrictive syntaxic and logical constraints than what SGML permitted. However, it's still false to say that XHTML ou HTML5 do not derive from SGML: in fact even XML is an application (i.e. a subset) of SGML. The main differences is that the constraints of validity in XML (and then in XHTML) are part of the mandatory rules where SGML does not enforce these rules, that are optional. XML did not invent a new syntax: all of its syntax is perfectly conforming to SGML syntax. XML also specified some mandatory interpretations of some keywords (making for example distinctions for namespaces, or for pseudo-attributes that it does not consider as regular attributes, notably those using the pseudo-namespace "xml:") SGML did not have the concept of namespaces, but namespaces in XML (and then in XHTML) appear just as part of the regular SGML identifiers for element names and attribute names, and a specific pseudo-attribute "ns=" has a special meaning. SGML did not enforce the closure of tags if this was not required explicitly by the DTD schema. However, such behavior (with implicit closure) is no longer permitted in XML, and there's no need to indicate it in the DTDs for XML as it is implicit and enforced by XML parsers. SGML did no require the strict recursive inclusion of tags and permitted tags to be opened in the content of an element and closed in another one, possibly spanning several ones: this was posible in HTML, with severe caveats due to the ambiguities, but is no longer tolerated in XML (and XHTML). Still HTML5 does not enforce the strict XML rules, so even if it derives formally from XHTML, it is NOT a conforming application of XHTML, but it behaves as a conforming application of HTML4. So HTML5 clearly derives from SGML (tags closure is not required but implicit with tags like , , , that cannot have any content; but you can still close them explicitly using the short form like or but you should NOT close them with a separate close tag, something permitted in XML and XHTML; for this reason you should really close your tags explicitly, using only the short form if elements have no contents, so that conforming XHTML will be also conforming HTML). One of the bad thing in XML is the fact that it still does not enforce the schema validation (which is optional) and there's still no clear way to specify this schema (the only syntax recognized for schemas is the one from DTDs, but the DTDs, inherited from sGML and fully compatible with it, are notoriously insufficient). The same is true in XHTML where there's no clear and mandatory way to specify how to process the content or how to transform it (XSLT is not enforced, and in fact there are competing technologies); only CSS has gained approval and standardization (in HTML4, HTML5 or XHTML), but CSS is not XML- or SGML- based and defines its own language. There is also no strict enforcement for the syntax of scripts (that are not XML- or SGML-based) and how to specify which language is used: there are still ambiguities notably for active attributes (and still no real standard for these "dynamic HTML" attributes). And even if you think that browsers are supportnig and conforming to XHTML, many of them will not process arbitrary XML as they should because they don't implement a full XML processor (so they won't recognize custom namespaces, despite of the efforts made by W3C to define XHTML within "modules"). In fact, for now, there still does not exist any conforming XHTML browser: they all implement a subset of XHTML but not enough to respect the standard for parsing it completely (and validate it too!). This is unrelated to the fact that these browsers still don't exhibit the same rendering behavior, even if they parse the content the same way. Tthe battle for now is within the standardization of CSS, but other battles are lagging since too long, notably the standardization of DOM and its implementation/binding support in script languages like javascript, ECMAscript, or VBscript. There are also too many incompatible dynamic behavior of the data collections generated and accessible through DOM: the collections, when they have mutual dependencies, are not updated collectively the same way across browsers (so this still creates big difficulties to make scripts work as they should: to enforce a compatible behavior, you need to suffer severe performance problems in script engines, another battle that is just starting and is really difficult because it also exposes numerous security issues, where the wanted protection level can create incompatibilities across browsers; the encapsulation level is also very different across browsers, so they don't expose th same dynamic behavior). All these reasons have allowed other proprietary formats to emerge and succeed (like Flash, which is a proprietary-constrained format based more or less of DOM, javascript, and its own collections of behavior and methods, but a successful work that could be ported on many environments, without having to suffer compatibility problems with other standards). The good question remains: when will it be possible to create conforming sites with the same interaction capabilities and performance as Flash, but using true interoperable standards instead of patent-encumbered proprietary formats like Flash)? It should not happen very soon, notably because of the numerous patents hold by Macromedia (now Adobe), unless the key elements of these patents are liberalized by Adobe to allow their reimplementation within the HTML/XML/CSS/ECMAScript standards suite, and a real effort is made by all browser writers to adopt this standard (Microsoft is always far behind, and has much more resistance since too long). One way to solve this interoperability problem would be to really say to all users to stop using Internet Explorer (even if it's preinstaleld and needed for a few legacy applications). Unfortunately, IE resists within all Microsoft products that are intimately bound to it and do not cooperate well (or not at all) with other browsers: this is the case for example with Windows Update that refuses to work if IE is not the default browser, and refusing to make IE the default means that you'll also not patch your system correctly in time to avoid severe security issues and exploits. So the key elment that makes IE still be used, despite it is too far away behind the standard, is Windows and the need to constantly maintain it functional and protected. There's a solution: convince all users to stop using windows, or only as a lower layer hypervizor running other OSes on top of it. May be users will be more happy when Microsoft will start delivering and isntalling Windows as a huge monolithic OS, but in two parts: a thin but very secure and reliable hypervizor, and a virtualized OS running on top of it or on top of other hypervizors, and in a more modular way; this virtualized OS shouls also work as a service from a remote network (such as computing grid farms). Patching the system should no longer depend on the browser's user interface, and so any browser could run in the virtualized OS, independantly of the OS or hypervizor behind it. Such browsers could then really support the interoperable standards, and could even collaborate to offer common services with a common, stable, and secure layer of implementation libraries that could be shared across applications, and tuned specifically and locally for more performance, depending on the supporting platform (virtualized or not). In this schema, the OS as well as the browser would become an utility (only the GUI and its aspect would be specific, but it could be implemented as well as an application of the HTML/CSS/DOM/scripts standard layer, just like a "skin"). And all applications for this environment would become services (that could be deployed locally or remotely, or rented online with a service subscription). (Note that even Microsoft starts admitting that IE is not the best tool for all its products, see its recent development in Silverlight that should become a competitor to Adobe Flash; this is just the start of the battle for the creation and adoption of an interoperable standard for dynamic web standards extending HTML/CSS/DOM/scripts, but something that will become highly required in the context of virtualization of computing resources, and the development of web services and virtual domains for appliances at home or even in mobile contexts within your pocket).

apotheon
apotheon

I didn't take it amiss. Thanks for the information about HTML5. I wonder if it is for better or worse, now that I know.

Justin James
Justin James

"HTML is a subset of SGML. XHTML is an XML schema." For better or worse, HTML 5 is actually no longer an SGML derivitive (about HTML being a subset of SGML, XHTML is still an XML schema). From the HTML 5 spec (http://www.whatwg.org/specs/web-apps/current-work/): "For compatibility with existing content and prior specifications, this specification describes two authoring formats: one based on XML (referred to as XHTML5), and one using a custom format inspired by SGML (referred to as HTML5). Implementations may support only one of these two formats, although supporting both is encouraged." There is also some interesting verbiage on explaning the reasoning behind this (as well as some details of some ways that various browsers ignored the specs) are here: http://www.whatwg.org/specs/web-apps/current-work/#parsing Not busting your chops of course (not likely you'd know some obscure piece of information about a spec that's still a draft and is a zillion pages long to boot), just thought it was interesting since you mentioned it, got me thinking about it. :) J.Ja

Justin James
Justin James

Nope, I work (whenever possible) with the Windows Forms stuff in .Net. I'm being transitioned into working on our main product, which is a plugin to Word. That's actually the reason why I have to "reheat" my VB.Net knowledge... out of the languages which can be used to manipulate the Word object model, VB.Net supports optional and named parameters, without which, you are stuck passing 18 null values and 3 real values to the method calls, and having to get the parameter order precise... what I *am* hoping for, is to be able to "divide the work" in a way that lets me use VB.Net for the Word interaction, and see if either IronPython or F# is usable for the main processing code. This was one of my motivators for learning Ruby, until I discovered that IronRuby wasn't ready for production use. J.Ja

apotheon
apotheon

Hopefully, you aren't doing rich-client-as-HTML-replacement work. That kind of crap annoys the hell out of me. I tend to prefer accessibility over "consistent presentation", when the answer to the problem of consistency is something like Flash or Silverlight -- because interfaces designed with those technologies are widely inaccessible, fat, frustrating even when they do work, and generally a bad idea. They're also, of course, not open standards in any meaningful sense, which just adds to the annoyance.

apotheon
apotheon

HTML is a subset of SGML. XHTML is an XML schema.

Tony Hopkinson
Tony Hopkinson

and the other regular, no closing tag at all. HTML is not XML. If it was, I couldn't mention improper closure. To be XML a document must be correct. Any application that processes an incorrect document is violating the XML specification.

Justin James
Justin James

"Most browser developers, most standards working group members, and most markup coders -- all of them, together -- are to blame for different parts of the huge, festering problem that is the Web's current dismal state of design." Yup, I agree. This is why, for myself, I try to only use HTML for its original purpose... distribution of written content, supplemented by the occassional picture and some links to other stuff. I have little desire to work on Web apps above and beyond "fill in the form" style stuff (and those projects tend to be boring anyways). I much prefer working with rich clients, where wrangling with issues caused by an inadequete presentation and networking technology do not consume 75% of my time. Alas, my employers do not always see it that way. :) J.Ja

Slayer_
Slayer_

Are you refering too something like [font][center][/font][/center] or people that do this [img src="Blah"][/img] Cause I always noticed that Iframe, only works if you do it the second way. [iframe src="blah"][/iframe] Works but I can never get [iframe src="blah" /] to work. You guys try, see if you can get it to work, perhaps I'm ruining the code somehow? I had always wondered.... HTML is just XML with a specific doctype. CSS is for styling XML. Doctypes are suposed to be old and ancient, and we are supposed to use XML schemas now. Why can you not in HTML just make your own schema or your own tags, and format them appropriatly in CSS. That would fit in the XML standard, but not into the HTML DTD. Why use div and span tags when you can make your own tags? FYI HTML was a hobby of mine long ago, I have never actually tried this.

Tony Hopkinson
Tony Hopkinson

improper closure of tags. To write code that deals with that is harder and therefore more expensive than just throwing an exception when the input is garbage. Coping with that ambiguity, then introduces a mass of cruft to cope with the different probable interpretations downstream of the first screw up. Now improper closure of tags is the standard, an ongoing and ever expanding increase in costs.... The only explanation is right at the start, the jobs was being done by complete idiots.

apotheon
apotheon

But what you'll find, if you dig really deep into the HTML and CSS standards, is that this stuff is insanely vaguely defined, when it is defined at all. I wasn't talking about that kind of thing, though. I was talking about stuff like whether the width of a div includes the measure of the margin property, and whether position: absolute works. This is not the same as the abbr/acronym tag behavior specification. Hell, when it comes right down to it, the only thing an XHTML tag is really required to do on its own is identify itself as either a block or inline tag, and conform to certain criteria about where it's allowed to appear in relation to other tags, as far as I can tell; the rest is styling and "expected" behavior. These standards monkeys expect it all to be "semantic", where the actual markup is concerned, and damn anyone who wants it to mean something for practical design purposes. Of course, HTML itself is basically just XHTML with all the logic removed, and a bunch of tumors growing where the logic used to be, and I don't speak of HTML 5 at all here since I've never worked with it. In the above, assume I'm talking about HTML 4 and XHTML. Thank goodness for XHTML 1.0 Transitional -- because of the way browser developers can't get their acts together and, y'know, do something reasonable with CSS. It doesn't help that W3C is (as I hinted earlier) full of crap with its insistence on abstractions that don't map to real-world use worth a damn. Argh. I guess the way I really feel about it is simple: Most browser developers, most standards working group members, and most markup coders -- all of them, together -- are to blame for different parts of the huge, festering problem that is the Web's current dismal state of design.

Justin James
Justin James

"One part of the reason for that problem is that some browser developers just won't properly implement the standard, and it annoys the crap out of me." Yes, and no. Yes, there are some differences in how various browsers parse and display the HTML. Ditto for CSS. But what you'll find, if you dig really deep into the HTML and CSS standards, is that this stuff is insanely vaguely defined, when it is defined at all. For example, remember a while back a discussion we had around abbr (or was it acronym?)? Looking at the HTML spec, nowhere does it define if that tag should have (or not have) a tooltip on it... it is completely up to the browser implementer. Same thing for error handling. The HTML 4 spec basically doesn't define error handling at all, and its definitions of so many things is so vague, that what one browser calls an error, another browser will consider valid, and both answers could be considered correct. Indeed, one of the unknown things about HTML... is that it is *not machine verifiable*! That's right! Here's a good example, the alt attribute on the img tag. Always required, right? In HTML 4, yes (I think, at least). But in HTML 5, the current version (that I remember) says (more or less), "alt is required but it can be just the empty string, but in certain circumstances it can be omitted" and those "certain circumstances" are basically things only a human can determine. It may have changed since this was a big "to do" in the HTML 5 group, so don't quote me on this. But you see this kind of stuff in the HTML spec. HTML 4 didn't define stuff well at all. HTML 5 is much more precise, error handling (and what is considered an error) is much more clear, but it is still impossible to valdiate parts of it with a machine. The alternative, of course, is to us XHTML, which is very clear regarding parsing, error handling, etc. since tha tis all clearly (and strictly) defined by the XML spec. But even then, you are left with a lot of problems. Keep in mind, HTML is designed to be an implementation and device independent spec. Which means that virtually zero presentational details (including a "default CSS styling" for elements) is defined in it. As an unfortunate result, any approach to HTML which assumes a particular presentation logic is potentially going to not work in one browser or another. Until the HTML and CSS specs gets 100% cleaned and clarified, and browser vendors agree on a default stylesheet, this will continue to be an issue, regardless of how "standard compliant" the browser itself may be. :( J.Ja

Geek3001
Geek3001

I've been playing around with what might be called 'themes and variations' using CSS in order to compare how different style configurations affect things. The results have been interesting, even without browser differences. It is kind of fun seeing how two or more different styles affect something individually and how combining those styles via nesting can create a whole new style. (Cascading rules, if you know how to use it.)

Sterling chip Camden
Sterling chip Camden

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.

jck
jck

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...

Justin James
Justin James

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

jarzola
jarzola

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.

Justin James
Justin James

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

apotheon
apotheon

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.

Justin James
Justin James

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

apotheon
apotheon

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.

apotheon
apotheon

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?

Justin James
Justin James

... 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

Justin James
Justin James

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

SnoopDougEDoug
SnoopDougEDoug

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

SnoopDougEDoug
SnoopDougEDoug

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

SnoopDougEDoug
SnoopDougEDoug

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

apotheon
apotheon

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.

tgerhard
tgerhard

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? ;-)

Justin James
Justin James

... 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

Tony Hopkinson
Tony Hopkinson

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.

apotheon
apotheon

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.

Sterling chip Camden
Sterling chip Camden

... 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.

Geek3001
Geek3001

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.

Geek3001
Geek3001

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.

chris
chris

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.

chris
chris

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?

chris
chris

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).

chris
chris

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.

Tony Hopkinson
Tony Hopkinson

They are the ones you are definitley going to get rid of next version or may be the one after... :D 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.

jarzola
jarzola

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...

jk2001
jk2001

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.

scott
scott

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

rebeccaaward
rebeccaaward

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.

alex.kashko
alex.kashko

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.

alex.kashko
alex.kashko

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.

apotheon
apotheon

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 discourtesy 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.

Justin James
Justin James

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

Slayer_
Slayer_

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.

apotheon
apotheon

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%.

Slayer_
Slayer_

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.

Tony Hopkinson
Tony Hopkinson

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.....

Sterling chip Camden
Sterling chip Camden

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

apotheon
apotheon

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.

Geek3001
Geek3001

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

pkshere
pkshere

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.

bboyd
bboyd

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.

Justin James
Justin James

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

apotheon
apotheon

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.

Jaqui
Jaqui

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.

Editor's Picks