Granted, my view would be steeped in the “I hand-code my CSS” school of thought, but even if we can’t have a WYSIWYG editor creating CSS and HTML for us could we at least get a CSS editor built into Fireworks? I’d recommend Photoshop for the job, but it seems that PS is doing quite enough already…arguably more than what most web designers even need. They’ve added so many new functions and “features” to PS over the years that it’s almost unrecognizable. I want something streamlined, not tacked on. Dreamweaver offers acceptable tools for round-trip image editing, but the thing’s a pig. It’s $400 US for a text-editor that takes half a minute to boot!

Seems that it wouldn’t be a stretch to offer this sort of functionality in an already object-oriented application like FW. It already has HTML-export functions built in although I rarely, if ever, use them. The hooks are still there and if we could define web functionality to library items in a Fireworks PNG (this is a element, this is an ), feels like good juju to me.

Of course, I might be slapping around those who love the idea of WSYIWG editing tools, I just haven’t found them to my liking in the efficiency department.

Niels Matthijs said on 5 July 2010 at 11:54 am: Most graphics (like icons) are better rendered as images. They could and should be copied as such, not as a html snippets with css attached to it.

Here’s a fantastic example of the Opera logo rendered purely using CSS. When I saw it, I immediately knew the potential here. As someone who’s created images purely in CSS before, there are two distinct advantages to this approach. The first is that the image is then dynamic. Written purely as code, this enables the author to add and change the ‘image’ at will. Want the Opera logo in green? Just change the code. Want it a different colour on every page to suit the backgrounds? Again, easy with the code at hand. I once made a demo that illustrates this approach. An ‘image’ made with CSS can be recoloured, inverted, brightened, enlarged and so on.

It would be a pain to create thousands of similar images with Photoshop or Illustrator. Plus all the web space you would need to store them. Whereas CSS allows us to create just one ‘image’ and re-use it any way we see fit.

Lastly, examples like the CSS Opera logo are zoomable, with no loss of quality! Enlarge a fixed-size icon or image and see how fuzzy it gets. Now try the Opera logo and zoom in. The logo, including the gradients and the shadows, remains perfectly smooth. Enough said.

Look what w3c has already done. Web design has moved way backwards in the last few years. The same boring assed cut and paste templates.

But you like that, don’t you? Lower the bar and even you and your chin stroking porn surfing programmer mates can make out they’re half decent designers. You’re not. Never will be. Get over yourself.

However! I would like to put out the idea that SVG (I’m becoming an SVG evangelist) might in fact be able to bring some interesting opportunities. Illustrator (as someone else pointed out) can export some nice graphics in SVG format and if you take a bit of a creative leap you can take what Illustrator has done and do some funky things to the code. The fact that SVG becomes an accessible part of the DOM means that you can manipulate it like any other elements. Duplication, manipulation and variations allow for using SVG graphics as libraries of UI elements and sort of bridging the gap between the work of designers and coders. Of course, interesting to note in all of this is that SVG can make use of its own CSS declarations and so there already is a graphics format that directly relies on CSS to change its presentation.

Anyone who has used CSS3 at all & SVG can see the similarities in some of the declarations and JS libraries like Raphael JS, Processing JS and of course the usage of the canvas element are all beginning to create a new way of describing visual elements of a page while also building on a solid standards based foundation. I don’t think (although some meta languages like SASS, etc might move there) that its all too likely in the near term that these techniques will result in a unified authoring environment but I think that at the very least there will be increasing numbers of developpers on the cutting edge who push their browsers to the limit and take advantage of them. The more these techniques are explored, I think there will be greater possibilities for semi-formalizing these processes into libraries (as has happened with JS) or authoring methodologies, which while not software, are in fact production tools. For example, versioning, modularity, oject oriented programming etc, are concepts that I use everyday (much the same way I use other tools such as PS), unbound to any specific piece of software or language. In other words, using cutting edge technologies for experimental purposes (eg. those CSS3 icons) will inevitably lead to better authoring practices, standards, and yes, perhaps some software. Bespoke coding will, by dint of the effort required to do it, will lead to optimization. Photoshopping a website together in as little time as possible won’t lead to greater efficiency.

Finally, the more we use these techniques and the more standard they become we’ll get to reap one of the best advantages to using code to replace/augment graphics which is that its much more scalable/flexible than raster graphics, working equally well on say Safari for the iPhone and in Chrome on the desktop. And this is where I think some of the real ‘art’ in hand-coding lies. The ability to intelligently scale and adapt your design/code to multiple platforms and multiple browser renderers really does require a human touch.

As Zeldman and others have pointed out, inDesign, PhotoShop et all were originally purposed for print based design, ie static design. While I love PS and obviously require it for my job, exporting for web doesn’t exactly have a lot of nuances or even much optimization for different platforms. This is where (along with other steps in the process) I have to step in and use my noggin and earn my pay. Furthermore, this discussion (and especially everyone on the machines can do it all bench) has mostly ignored the elephant in the room which is behaviour – ie JavaScript. HTML & CSS are only 2 parts of the modern equation and if automating valid HTML & CSS is hard, I can only imagine how hard it would be to use some sort of WYSIWYG to generate various behaviours, bind events, fire AJAX calls etc. Clean and semantic markup in HTML & CSS is essential if you’re going to be using say JQuery, ExtJS, or any other sophisticated JS library without going mad.

Anyway, thats my long-winded take on it all. Guess I had to get some things off my chest. Obviously a great article judging the response its gotten. Cheers Zeldman!

However, wouldn’t it be great if you could take your Photoshop comp and assign HTML elements and CSS properties directly to it and the tool spat out a basic framework that you could then build from in a text editor?

Also there are plenty of little web apps out there that let you play around with, say, border-radius or background-gradient values, and see the results instantly. Combine all of them and you’ve got a pretty handy little tool.

My point is that the current workflow requires a stepping backwards and forwards between at least two applications that can’t communicate with each other. Rather than thinking that one could or should replace or be superior to the other – surely there is scope for a tool that allows you to work with both image and code in the same workspace? Sort of a Fireworks/Coda hybrid?

To the point: no, unless assuming a near-human grade AI, no tool will be able to take a picture and create (correct) markup. At some point or other a decision MUST be made to create paragraphs, headers, lists, emphasis and similar – and that, within the foreseeable future, is something a computer cannot do.

It has nothing to do with generations, nothing to do with niche jobs, nothing what so ever to do with more than one way to Rome. At this point in time we’re faced with a very simple, if much misused, engineering fact: software ain’t smart enough to turn pictures into semantic markup.

Please remember: while a program can determine that a piece of text exist in an image, and that it is heavier font-wise than the text around it, it still cannot say whether the text is emphasised – or simply bold. It can neither understand the context of the text, nor read the author’s mind.

Advanced tools can be made. Tools which support developers, be they programmers, content authors, or designers, in doing their job. But doing the job for them?

Right now that’s impossible. But perhaps in a few decades or so. Or a century. Or two. Not a particularly practical thing to hope for.

Had a little play a while back (version 1) but a friend suggests that all it ends up is with everything using absolute positioning so maybe not so good. (maybe an over exageration but you get the idea) but I reckon no app can do it all.

I’ll take a day off to read all the comments, I think :) oh boy !!

And second to the “hardcore-coders”: I know perfectly the languages that I use but I also like to use Dreamweaver. Navigating through the code of a big form with thousand of lines just by clicking on an input in the visual editor is gold to me.

Remember: All roads lead to Rome…

Back to Adobe tools. Fireworks has been mention, and also by Jeffry himself. It really is a shame that more emphasis isn’t placed by Adobe on the tool. Besides mentioning what @michael did, (a fellow past FW beta member) Fireworks CS5, not before, does a decent job of producing standards-based CSS. It is lean, and while the naming isn’t what I’d like, it does a good job. Like someone else suggested, I place a rectangle around *div* areas of text, and use my Common Library HTML items like h1, etc., to designate a header. It makes a difference how the file is set up of course, but it makes an external style sheet and not a ton of extra CSS is created. I did this as a lesson for the fireworks video I did for total training this year.

As of CS4, I didn’t care for the way Photoshop, (sorry Mordy) or Illustrator exported HTML and CSS. Uck! Fireworks CS4 needed a replacement plug-in by either Matt Stow or David Hogue, can’t remember which made it. It was still better than anything ID, PS, or AI could export.

Now I am an Adobe Instructor, but my motto has always been the right tool for the job. I started web design back in CyberStudio days. Dreamweaver back at version 2. As a previous print designer, it didn’t take me long to move to hand coding. No other tool did it as easily. I’d like to think of myself as a true hybrid (just put on my first conference this year called D2W. Designer/developer Workflow conference url was d2wc.com) but I agree with David Blatner and Mordy when it comes to some designer will and don’t care about the code and will indeed use whatever tool will allow them to not look at the code. I have that trouble in my Dreamweaver class, where we (first day) jump into the code and I teach them to write HTML/CSS right away.

So, if there are some (i.e., random WordPress users) designers who won’t write code, why not create better exports of CSS (it obviously won’t compare to hand-written code)? The export PS and AI has now is crap. Why anyone would use Photoshop for web design is and has always been beyond me, and I’ve been using PS since version 1. Right tool for the right job.

Dreamweaver is just a tool. If used properly, it can help you create top-notch HTML/CSS, just as CODA or any other code editor out there. Dw has smart code hinting (which is also extensible), auto-complete, integrated ftp/sftp, related files feature, etc.

The fact that some people use Dw in the wrong way (use it only in DesignView) doesn’t mean the tool itself is not good. :)

That aside I completely agree with this article. Dreamweaver is as close as we’re gonna get to an illustrator and pagemaker for HTML5/CSS/JS. I am however one of those “hand coders who will knock dreamweaver” and will state for the record that Dreamweaver sucks.

“Hand Crafted” is the best way to describe how we code our html/css/js and photoshop compositions.

Jeffrey, thanks for your response, that’s exactly the kind of information I’d want to sink my teeth into…the first step is comprehensive ethnographic research; how web designers work, both in serving their unconscious intentions / cultural biases / unspoken assumptions, and then the practical day-to-day routines, tools, techniques, and heuristics that they use to make code – then to give them the tool that does what they didn’t even know they wanted.

Following what subsequent commenter Brian Warren said, I do see some level of assistance provided, hopefully not as annoying as Clippy, but that helps automate repetitive processes. I don’t think we can have the program make subjective calls about semantics, but we could provide tools for managing semantics (for instance, a palette to assign semantic priority to code sections, etc.)

Ultimately you still will benefit from having in-depth knowledge of HTML/CSS and JS; I would like to think that it would be the kind of tool that will help a newbie craft decent code, and an expert craft brilliant code.

but the practice of architecting and web designing is still in the mind of the artist – not in his tools.

mf, that’s what I’m saying.