iWeb's HTML markup. Not so good.

And considering folks like Dunstan, Eris and Paul Nixon are all there...

I won't say I'm disappointed to hear this, but not really that surprised.

Remember a while ago when Jeffrey Zeldman worked with Apple to help redesign their site? I hope they haven't lost his number. Time to call him again. Or you. Or me. Or SOMEONE.

On the upside, the page validates as XHTML Transitional. :)

It shows just how little validation can mean. Well-formed markup doesn't always mean semantic code.

Yeah, when I was watching Jobs drag elements all over the screen and rotate them willy-nilly, my first thought was "There's no way that's going to look good in code." There's just a simplicity to the way you have to *design* in the first place in order for the code to work out right. Oh well... it'll improve.

There are also a lot of styles inline, which isn't great, but tolerable considering how easy is to generate a website with iWeb.

When I published my first site as a test, I was actually fairly pleased with what I saw. I thought it would be worse (tables and deprecated markup).

So, while you're right, it's not perfect, I don't think it's realistic to expect perfect. Not with 1.0, and not with the feature set and ease of use they offer the users.

The good news is that it is bound to improve...just like the Texans are bound to have a better season next year.

Ryan, the real problem is that people see using webstandards as a post developent step, alot of developers still just code some html, don't bothering about the semantics or validity of the markup. And when they reach the final stage of development the code is either too big a mess to start cleaning up or there isn't enough time left to clean it up. That's the whole problem, it would be alot easier if people would just THINK webstandards during development instead of seeing it as a required step of development. Just my few cents.

I wouldn't expect much meaningful code from any WYSIWG tool for many years to come.

"Ryan, the real problem is that people see using webstandards as a post developent step...."

Well, YEAH. First rule of any meaningful development beyond hobbyist is _always_ just "get it to work". It's only afterwards that those other things follow.

Look, I understand that doing it right the first time - wellformed/efficient code, stable/clean UI, full documentation - and doing it right _while_ developing is worth it's weight in gold.

That said, let's get real and deal with realities. That will always mean get it working first and foremost.

so what are the odds of uploading it to something like Wordpress? please let me know. you are the only one i know of who as covered this.. thanks agin.

And how may apps have you written that create websites? Um, none? Who cares who cares if theres "Zero inheritance or semantic structure for document elements..." blah blah blah. Johnny makes a nice looking page, mom see it in her browser, whether it Firefox Safari, IE, whatever. You should be thanking Apple because you still have a job. The world still needs narcissistic, self exhalting web designers.

Well, iWeb was built so that you didn't have to write any code at all, so why care?

So what if there is some unecessary code? It is a brand new application, and it gets the job done without the user having to write a line of code.

Well, iWeb was built so that you didn't have to write any code at all, so why care?

So what if there is some unnecessary code? It is a brand new application, and it gets the job done without the user having to write a line of code.

I have to agree with Joey. While I detest having to do maintenance on such code where I work, I think if hte viewable result works well, and the GUI is easy to use, and you can get things positioned right on the GUI, and it looks the same in multiple browsers, then I am all the more for it. I don't know how long I sit and fight trying to use webstandards and make it work in multiple browsers. It just doesn't do it since one follow standards.

Anyways, a little search-and-replace can fix many of your complaints. Go back to your text editor, and quit complaining about a product that you wouldn't use even if it worked as you wanted.

Hilarious - this post is more in depth, but very similar to an email I sent to Apple when I took a look at their own .Mac blog located here.

Here's the text of the email:

Man, I saw the huge horizontal scroll bar on the blog page and (since it's what I do for a living) took a look at the source. If that's an example of the code that's output from iWeb I guess I won't be recommending anyone use it. I understand that you're making an app for "anyone" to be able to publish, but when it outputs such horrible code it doesn't come off very Apple-like. It kinda reminds me of the junk that MS Word or Frontpage would produce. Where's the spit and polish?

Looking forward to 2.0,
Jeff Kenny

And putting that XML declaration before the doctype sends IE6 into quirks-mode. I'm guessing they did it on purpose, but strikes me as sort of, well, two years ago...

If it validates to XHTML Transitional, is there some other web-standard it should adhere to in order to be considered "more efficient"?

You said it ... at least there's 2.0.

I think in terms of a 1.0 this is a welcome addition to the WYSIWYG empire of apps; and quite honestly, I'm happy with the generated code. While these sites won't be read by anyone's screenreader anytime soon, at least they're not gumming up the web with yet more table-based layouts.

Think FrontPage, Freeway, GoLive or Dreamweaver (in WYSIWYG mode) does better?

I tested that iWeb page at two markup validation sites and it validated properly. Your own website does not. How do you account for that?

Just as an observation, Karelia's "Sandvox" application -- very similar to iWeb in concept -- seems to generate considerably better markup. And it validates as XHTML 1.0 Strict. I doubt it allows quite as much woo-woo stuff like the image cropping and rotation, but it still looks like it's pretty easy, and much less brain-dead than its competitors.

And I'm having trouble seeing that the woo-woo stuff Apple allows justifies the incredible excess of the inline CSS it's generating, anyway. It may be stuff that only "web geeks" truly care about, but there are going to be Apple Consultants out there recommending this program to their clients (I had dinner tonight with three ACN members all enthusing about this), and you know some of those clients will want things added to their iWeb-generated sites that iWeb can't do. As a web geek, if I'm going to deal with generated markup, I'd rather it not be stuff that I'm going to spend hours trying to clean up.

Ok...so its not clean and rich.

For Self-gen'd files its not too bad. Much (much) better than anything from Microsoft...

an it's a 1.0 consumer product.

I write this not to be snarky about the markup specifically, but to point out that Apple, of all people, should have been able to develop an application that spits out better markup than this.

Have you ever seen Apple's .plist format, used for meta information about applications in OS X? If you had, you wouldn't trust Apple to create any markup. Ever.

I don't know which is worse: The code iWeb is producing or statements like 'Who cares who cares if theres "Zero inheritance or semantic structure for document elements..."'

I wouldn't expect much meaningful code from any WYSIWG tool for many years to come.

http://jigsaw.w3.org/css-validator/validator?profile=css2&warning=2&uri=http%3A//richardathome.wordpress.com/

http://validator.w3.org/check?verbose=1&uri=http%3A//whatdoiknow.org/archives/002582.shtml

Is iWeb better than Claris Homepage? ;-)

To quote Appleologist:
Well, iWeb was built so that you didn't have to write any code at all, so why care?

Well, not only humans read the web: search engines do too. I think that given the flat (logical) structure of the file, many search engines will have trouble identifying interesting information easily and reliably.

Apple probably did it on purpose so that bozos like the blog author feel repulsed and decide not to fuck around with the template too much.

When watching the keynote presentation of iWeb, we all knew that this was going to be the case.

And hey, the example you gave us Todd is a pretty simple one column web page, I'd hate to see what the code is like on something more complex.

The div class="paragraph Body" part is just crazy.

This is a free app, bundled in a suite of consumer level products.

Its for folk who want to put up their photos or a blog for their school friends/grandma/dog, etc.

It is not a Pro App. It is not created for use by professional level web developers.

Who really cares if its not semantic markup - the user demographic it is targeting certainly doesn't.

Anyone who does care simply wouldn't be using it in the first place.

Done. Move on.

I think 'WhatDoYouKnowLOL' actually makes a good point. When I first saw some iWeb-generated code my initial thought was "I bet apple did that on purpose".

You see, I don't want a website that looks identical to a hundred other sites, and I also like to design my sites by hand, line by line ensuing that they are written well.

But as an amateur web designer I do like to 'borrow' ideas and the odd line of code when i see something nice. I looked at iWeb and figured I could just export an iWeb slideshow page, then pull out the nice slideshow stuff and chuck the rest away. This is still feasible of course, but with such disgusting code it becomes a lot less fun.

What's more of a concern for me is the ridiculously long and cryptic URL that iWeb publishes too. Seriously - this wacky URL will do more to hinder generic search engine rankings than the underlying code will anyday. Most engines these days rely on good content to create it's rankings, not tidy markup.

"""Have you ever seen Apple's .plist format, used for meta information about applications in OS X? If you had, you wouldn't trust Apple to create any markup. Ever."""

This is a dumb comment. Plists are straight serialization of Cocoa objects, and as such are quite useful and efficient. The code to parse them is always loaded in memory, and OS X is incredibly efficient at dealing with them. If you want "simpler" looking versions, you can use the ASCII plist format which looks sort of like C code and is much more readable with a simple text editor, but the XML version supports unicode, and generally works just fine, especially if you use Property List Editor or similar to view it.

I haven't read all the comments, but it seems that many commenters either don't understand, or don't remember why semantic markup is important.
Want to use a search engine to find this content? iWeb just made it more difficult. Have a disability and use a screen reader? Looks like you're out of luck with this code. Does it do aural stylesheets to attempt to overcome the semantic shortfalls? 2.0 I guess... maybe.

This really isn't much better than frontpage in my opinion. However, if it were to enforce semantic code, it surely would be much harder to use, and Apple is looking for ease of use. They want to put the power of online publishing in the hands of their customers. I'll grant you that the customer base probably won't have a huge impact on the web, but we are all better off if the content out there is semanticly marked up.

Thanks for the review, Todd. I've been wondering about this code.

On the bright side, perhaps Apple will be the first to support XHTML2 in a browser and a content generator.

Just a pointer to a Ruby scripting tool that generates valid HTML & a bit more: http://deplate.sf.net ! (Two further Ruby-based web page toosl are webgen.rubyforge.org and amrita.sourceforge.jp ; Unix-savvy users may want to look into nanoblogger.sf.net) !

> 3) overflow:visible set to all, and I mean all divs. Huh?

That's a technique to account for Windows IE bugs. Anything that pushes out the width of floated column (box model difference, wide image, or even italic text) can destroy a solid layout in Win IE. It's certainly redundant, but as a generator, I think it's more of a safety technique and certainly excusable to ensure a decent visual layout.

To clarify, I am in complete agreement that most of the markup and CSS—though probably more-easily scripted—is much in need of improvement. ;-)

God, you guys are harsh. This is a consumer app, folks! I start mentioning semantic markup to regular people and their eyes gloss over. And shitty markup doesn't stop search engines cold, so stop worrying. You want better code, turn your family and friends onto BBEDit and the O'Reilly books, not iWeb. Horses for courses.

For me, as a Web designer, the big issue is expectations -- I expect more from Apple given the level of quality of their other applications and given that they have people on the inside who know better.

There are plenty of times I've had to deal with legacy code generated by wysiwyg Web apps (FrontPage, etc) and it's usually a bleeding-eye nightmare. I expected Apple would take care of both the needs of the designer as well as the needs of the end user.

And, I suppose, beyond that, the needs of the Web in moving towards making it more semantically rich and useful. Ultimately there are reasons (many mentioned above) that we as Web designers are slowly, as a group, trying to push standards and semantic structure, and it's not just to make our jobs easier.

I had the same fears when I saw Steve doing that demo. "My God...this is going to be messy." And yeah, it is. Why did they even bother coming out with a WYSIWYG web editor?

This may be the geek battle of the century;

Apple Fanatics vs. Web Standardistas

Who will come out on top? I for one would pay a high price for a Zeldman vs. Jobs no-holds barred cage match.

Oh yeah, and just to throw my two cents in there, I agree that this is a bit of a disappointment. Apple has a reputation for designing things well from the inside out; this is why people are willing to pay more for a PowerBook when a Dell will get your email just as well. Sure iWeb "just works", but it could be designed a whole lot better and with a more forward-thinking attitude.

I'm writing up a review of iWeb, and I think you may have missed something--while you can see the text inside of a bunch of DIVs, the stuff that actually (at least, on the template that I used) gets displayed is all images. The text that you can see when you view source is in the longdesc attribute of the img tags.

I don't think these pages aren't going to work well with anything: no alternative browsers, and few search engines.

Jerry

I was using RapidWeaver, which I always felt could have been much better, and have better documentation. So i was excited to hear about iWeb. I have my copy now, and I have been playing with it all day. The code is not only ugly, but WTF is with the URL's it spits out. I add a simple photos page and the URL looks like a Amazon product page.

And what's up with trying to force us to use .Mac. Just let us upload the thing to our own domains, without the crazy URL's. Great tool, but Apple is thinking too Microsoft in business area.

You guys saying "who cares you wont use it anyway", claiming "it validates it must be ok" and linking to failed validation results for this site obviously have no idea WHY coding in web standards is important and why validation isn't what's important.

Validation is an indicator. It's purpose is to help encourage people to use appropriate, symantic markup.

The reason that's important has nothing to do with young joey looking at sites. You can create beautiful usable webpages, as far as standard non impared humans are concerned, with the most abhorrent markup.

The reason web standards are important is for accessability and machine readability. The ability for the site to work correctly on all browsers, on all devices, whether the user is using IE6 or Links, a Mac or a mobile phone, a standard visual brower or a blind reader. Non symantic markup decreases the meaning of a site in all but the standard non impared human case.

So stop being beligerant little prats and arguing about things that you obviously don't understand.

iWeb is no doubt a great thing for mum and dad, but that gives Apple a responsibililty to make it output the best code possible. Using a instead of a paragraph or a heading is inexcusable and lazy. It has nothing to do with being WYSIWYG.

Last littel bit lost the <dive> tag

Using a <dive> instead of a paragraph or a heading is inexcusable and lazy. It has nothing to do with being WYSIWYG.

Oh for crying out loud.

Google Fight:
Steve Jobs vs. Jeffrey Zeldman
99,900,000 - 1,370,000

Apple Fanatics vs. Web Standardists
1,920,000 - 41

How about the brand new WYSIWYG HTML editor Goldfish ( http://www.fishbeam.com/en/ )!

Eh, it's not as bad as I figured it would be. Slightly better than the mess that DW puts out. :)

Just another point of view:

with available bandwith and technology "well html" becomes less important. look at the print business: does anyone care what postscript looks like. NO, it simply has to "work well"

... but there are online resources that help you write pretty readable HTML code ( http://www.htmlbyexample.com ). (... although I agree that the HTML tag soup is pretty meaningless to the average user).

Just a little note to people validating this page and finding errors:

Those errors are being caused by commenters using (illegal) unencoded characters such as &. You’ve just proved you have no place in this discussion.

Read Fred’s post above. Understand it. Wake the hell up.

To the author, I checked the source code of this website and ...lol.. you better stfu. iWeb is a tool for people who are NOT webdesigner. Its for Joe Doe who wants to make a little website with pictures of this latest party