This is so inspirationally horrible someone spent hours remaking it, like it should've been: http://studentweb.infotech.monash.edu/~wlay/FIT1012/muse-dem....
Original: 1496 lines, 77.9kB
Your version: 104 lines, 4.75kB
I'd thought we'd progressed beyond the state of a decade ago where Dreamweaver or what-have-you would build you a cumbersome and baroque html splooge to match whatever you had done in the designer, but I guess we haven't advanced that far. Just goes to show you that front-end devs are still as necessary as ever I suppose.
For many purposes, optimizing the HTML nerd out of the process is a much bigger win than a 20k download (don't forget gzip) is a loss.
I know this is going to get me downvotes, but I think the dogmatic "HTML shall be written by hand!!1" attitude all over this thread is just people clinging to the past.
And then there are the higher level issues. What happens when you get a bug report about how the page is rendered in a specific browser/OS? Do you want to wade through 1500 lines of html or 100 lines? Which do you think will be easier and faster to fix? Which do you think will be easier to inspect for correctness from the start? What happens when you need to figure out why your page is rendering too slowly? Which is easier to analyze, which is easier to speed up? What happens when you want to change the design? What happens when you want to take the design and use it as a UI for a web-app?
Using a tool that generates such crappy HTML may allow an inexperienced person to create a web page with a decent appearance, and it may even save an experienced designer a few minutes upfront. But over the lifecycle of a project it ends up being an enormous drain. If you're an enthusiastic teen putting up a web page for your mother's knitting circle, it's fantastic! But this is not in any sense a truly professional tool.
For example, there is no big difference in functionality if the Adobe web site takes a few extra milliseconds to load. Customers just want to buy a product and get out of the way. And Adobe is a big company... This is even more true for their customers, thousands of small websites that just want to publish content as quickly as possible.
We don't write HTML/JS/CSS by hand because it's fun, that's for sure. We focus on code-reuse and delayed loading plus AJAX (plus gzip, compress, CDN, cache, etc.) because the customer focuses on speed and the CEO focuses on the bottom line.
And, not to mention no business owner want to get locked into a solution, they want their "data" transferable and standardized to at least some extend.
The code this produces is so horrible you've lost all the time spent with it. Muse dies out, and your time spent in it dies with it.
And, not to mention no business owner want to get locked
into a solution, they want their "data" transferable and
standardized to at least some extend.
Still, it absolutely defies reason that a business would need to hire someone specifically to edit a bit of text or change a font on a web site. Once a credible product along these lines hits the market, the terms HTML and CSS will disappear from the overwhelming majority of job descriptions, forever.
That's only weird to those who think open standards to be
the only viable standard.
MS Office is the de facto standard
your data is not vendor-locked when using it
This is, however, mostly thanks to people reverse engineering Microsoft's original binary file formats, and MS was not really happy about this to begin with. If they could have prevented it, they would have done so (and they tried). Even the newer OOXML is not entirely documented and prevents free implementations due to patents (which, no matter what Microsoft may claim, is the exact opposite of an open standard).
Also, while this conversion might work fine for simple, small documents (or other files), the more complex and larger your filed become the more impossible it becomes to convert without a major hassle, which brings us back to your misunderstanding of 'vendor-lock'. The terms doesn't necessarily mean that it's impossible to switch to alternatives, but also applies when measures are taken to make it as hard as possible to switch without investing heavily in time and money.
As a side note, I am not attacking MS Office specifically. It's just the best example for showing all that is wrong with closed standards and proprietary file formats.
In the history you're clinging to you completely ignore that there was no real alternative. Open standards weren't in a viable state. Furthermore the competition from closed standards have forced open standards to shape up.
I definitely want and wish for tools that can allow me to design websites without having to know what IE developers were thinking the day they decided to have some fun.
The reason vim, emacs and the likes are still used a lot isn't because of nostalgia but because it works great for the user.
The issue with all the WYSIWYG editors is they take the "a web site can be anything and everyone can be a designer"-approach which is completely make believe. Till they make some form of WYSIWYM editor aimed at the web designer to use, all other approaches are worthless because they are basically just Word that's fancied up.
Most graphic designer classes have a field trip to see how typographers worked for newspapers 60 years go, and learn why their job was important - and such a day will come for designers some day too when it comes to writing code in hand.
But till then, design and code still matters.
Second, HTML is for telling the browser how to lay out content. When you use Muse or Dreamweaver or iWeb or whatever, you're essentially "scripting" your HTML in a proprietary GUI. When that GUI changes or disappears, how will you maintain that page? Yes, by hand.
All WYSIWYG GUIs should seek to output human-maintainable code, at the very least. It isn't a performance issue.
~ $ curl -s 'http://studentweb.infotech.monash.edu/~wlay/FIT1012/muse-demo/' | gzip | wc -c
1741
~ $ curl -s 'http://muse.adobe.com/index.html' | gzip | wc -c
11521
I thought to check this because of ridiculousfish's old article (note the FAQ at the bottom, "Isn't that a humungous flood of markup?"): http://ridiculousfish.com/blog/archives/2009/06/01/roundy/#f...
Even small changes in response times can have significant effects. Google found that moving from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20% (Linden 2006).
I really do not want to see that 1mb picture of your dog mascot, but i was actually interested in your 5kb product description... Oh well if you dont care about your site, you probably dont care about selling your product either.
As for the rest of us, we don't have to be concerned till Muse starts learning the quirks and features of CSS faster than ourselves.
They're using a hidden div full of <img> elements to load the hover images before they're requested by an actual hover. It's all the way at the bottom of their code code: <div class="preload_images"> [Removed for brevity] </div>
Sprite sheets are another option (using the sliding doors technique), but they're a bit more ungainly. They would save a couple HTTP requests, but that extent of optimization isn't necessary on most sites. Unless I've already combined all my stylesheets into one file, I certainly wouldn't start combining images.
What really matters is perceptible lag to a user, and either technique work just as well for that.
I find Adobe's technique kind of neat, and I'll probably use it in some of my future websites.