An InDesign for HTML and CSS?

In “CSS is the new Photoshop” (?), Adobe’s John Nack correctly observes, as have many of us, that “Cascading Style Sheets can create a great deal of artwork now, without reliance on bitmap graphics.” Nack quotes Shawn Blanc, one of several concurrent authors of the phrase “CSS is the new Photoshop,” who cites as evidence Louis Harboe’s iOS icons and Jeff Batterton’s iPhone, both designed entirely in CSS and both only viewable in the latest Webkit browsers, Safari 5 and Google Chrome 5.

He’s not alone: Håkon Wium Lie from Opera predicts that CSS3 could eliminate half the images used on the Web. You can use various graphical tools to generate things like CSS gradients and rounded corners. As people can do more and more in code, it makes sense to ask whether even to use Photoshop in designing Web content.

I think Adobe should be freaking out a bit, but in a constructive way.

So far, so good. But Nack’s “constructive” suggestion for Adobe, quoting Michael Slade, is to create “the modern day equivalent of Illustrator and PageMaker for CSS, HTML5 and JavaScript.”

Nack acknowledges that this will be difficult. I propose that it will be impossible. Says Nack:

As I noted the other day, “Almost no one would look inside, say, an EPS file and harrumph, ‘Well, that’s not how I’d write PostScript’–but they absolutely do that with HTML.”

Well, there is a reason they absolutely do that with HTML. PostScript is a programming language designed to describe page layouts and text shapes in a world of known, fixed dimensions (the world of print), with no underlying semantics. PostScript doesn’t care whether an element is a paragraph, a headline, or a list item. It doesn’t care if a bit of content on one page cites another bit of content on a different page. PostScript is a visual plotting language. And HTML is anything but.

HTML is a language with roots in library science. It doesn’t know or care what content looks like. (Even HTML5 doesn’t care what content looks like.) Neither a tool like Photoshop, which is all about pixels, nor a tool like Illustrator, which is all about vectors, can generate semantic HTML, because the visual and the semantic are two different things.

Moreover, authoring good HTML and CSS is an art, just as authoring good poetry or designing beautiful comps in Photoshop is an art. Expecting Photoshop to write the kind of markup and CSS you and I write at our best is like challenging TextMate to convert semantic HTML into a visually appropriate and aesthetically pleasing layout. Certain kinds of human creativity and expertise cannot be reproduced by machines. Yes, there are machines that create music, and a composer like Brian Eno can program such systems to create somewhat interesting aural landscapes, but such music can never be the Eroica or “This Land is Your Land,” because there is no algorithm with the creative and life experience of Beethoven or Woody Guthrie.

Adobe already has a fine product in the code arena. Some hand coders knock Dreamweaver, but it does about as good a job as is possible of converting groupings of meaningless pixels into chunks of valid code. It is unreasonable to expect more than that from a tool that begins by importing a multi-layered Photoshop comp. Of course you can do much more with Dreamweaver if you use its code merely as a starting point, or if you use it simply as a hand-coding environment. But that’s the point. Some things, to be done right, must be done by the human mind.

There’s something to what Nack says. Photoshop could be made friendlier to serious web designers. Adobe could also stop ignoring Fireworks, as Fireworks is a better starting place for web design. They might even interview serious, standards-oriented web designers and start from scratch, as a new tool will suffer from fewer political constraints and user expectations than a beloved existing product with deep features and multiple audiences.

But while our current tools can certainly stand improvement, no company will ever create “the modern day equivalent of Illustrator and PageMaker for CSS, HTML5 and JavaScript.” The very assumption that a such thing is possible suggests a lack of understanding of the professionalism, wisdom, and experience required to create good HTML, CSS, and JavaScript. Fortunately, a better understanding is easy to come by.

111 thoughts on “An InDesign for HTML and CSS?

  1. It would make for a a great Big Web Show interview to have John Nack on to chat about this. Not sure how easy that is to make happen though.

  2. Totally agree; images will be around a long long time yet as will fiddly tools that dont necessary do everything some would like. What I would say is that SVG provides a ‘GZIP’able solution to some graphics on a page in the future that will in somecases be a better solution and you can already export it direct from illustrator. But as always the caveat of ‘One size never fits all’ remains.

    At least they didn’t suggest making Quark more of a web tool; I’ve seen some horrible sites appear complete with MOTW stating it was made in QUARK.

  3. i am no expert in HTML coding by a long shot, but I’m taken by Coding HTML is an art form statement. I’m not going to say that what you do isn’t creative. But isn’t there “good enough”? AND doesn’t adobe have other visual tools that at least take up the most compelling pieces of pixel to code elements juxtaposed with more robust programming entry? you mention Dreamweaver in a weak way. I would add that Fireworks does a pretty amazing job of this with even less access to code. I would also suggest that Flash Catalyst’s import of Ps and AI files and coverter to FXG is an even more compelling example.

    Now I understand the separation of style and structure, but for most this separation is a Style Sheet at best and if you are talking about converting Ps to CSS/HTML then it is really about “pixel perfect” conversion into an object that can be used in combination with your creative code where it matters more, no?

    But on the flip side of this. Your “code is an art form” and no tool can ever code as good as me implication in one fail swoop justifies Apple’s anti Flash Export tool. A tool I think is a shame that Adobe stopped supporting b/c it would have been great for folks like me who are ObjC shy as designers but who want to prototype for iPhone. We could have used this stuff on our phones through manual installs and provisioning and sent them to developers who could see richer prototypes. Bummer! yes, they’d have to recode it, but at least they’d have a great model to recode from. Oh well!

    — dave

  4. I’m not a big fan of this css-for-design trend.

    For one, 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.

    On top of that, I think designers should worry about design, not about how to fix things in css and how different browsers handle it. Keeping both aspects in mind you’ll get conflicts of interest, ultimately diminishing the quality of the final product.

  5. Long before I started my own business, I worked for the computing service in a university. One of my colleagues was an postscript guru. He wouldn’t use anything like Illustrator to make his files: he claimed it wasn’t nearly efficient enough. I suspect that few of us–very few–would seriously agree with his eccentricity.

    I wonder how much of this debate reflects his attitude: the belief/desire that much of what we do cannot be replicated mechanically. It’s undeniable that we’ll still craft things by hand: a hammer, for instance is a tool, and not (usually) a decision-making device: it’s how it’s used by skilled hands that matters.

    The continued success of handcrafted HTML & CSS may well be more a reflection of the state of the toolset than anything intrinsic.

  6. Nicely written. There are many improvements that can be made with tools like Photoshop, if they are improved, that remains to be seen. Nice article, Jeffrey.

  7. I have to disagree with the idea that a tool could not do this effectively. It would just be a matter of creating a tool that did it correctly. If I were building it (and I have to say that this article has inspired me to consider it), I would develop a tool that would take valid HTML markup and then give you a pallet from that markup which you could visually manipulate, applying CSS using a standard adobe toolset.

    The HTML would remain handcoded, or could be imported from Dreamweaver, and the CSS would replace postscript and would be as readable as the machine could make it.

    Finally, there is a lot of value in incorporating Canvas (or SVG, I guess) support into a tool like this.

  8. I just started drafting a similar blog post this morning. I agree that in the foreseeable future we will not get a tool that generates valid, semantic markup or clean CSS. However, with the advent of the canvas tag, such a tool is possible, and in some advanced cases, required to generate Javascript. I’m not talking about simple animations or effects, but a complete replacement for sites that need Flash (like So I agree with your main points Jeffrey, but I think lumping in Javascript is being shortsighted.

  9. As a side note, I think part of the issue here is that all the WYSIWYG HTML/CSS tools we’ve seen thus far (and continue to envision) have indeed been stuck in the cognitive rut of using visual editors like Photoshop and Illustrator as their model. The task requires a fundamentally different form of GUI that we haven’t seen thus far if we’re to start with the task of defining semantic meaning and working our way out to design.

  10. A few months ago I worked with a company who designed websites in InDesign. Each INDD file was a site, and good luck if you wanted pages of varying length. They swore by their process, claimed a thorough knowledge of SEO, but had no interest in code. Using page styles as CSS stand-ins didn’t interest them, and no one had heard of web standards.

    People stick with what they know. Whether InD, Dreamweaver, Photoshop, Fireworks, or whatever—the longer one dedicates to learning a tool, the more they’ll find a way to use that tool to any purpose. (Me, I favor pencil and paper.)

  11. is it just me, or am I wrong in thinking, that like life, there are many ways to enjoy a job or journey? and that any one person telling you only doing something one way is “the future” sounds like a bowler hatted snake oil salesman? Besides… do we all honestly want to pump out mac-esque rounded corner, blobby, shadowed generic design for the web? I think the chrome / iPod example is amazing… but I think I’d soon give up the web if every page looked like a that.

    You are all individuals….We are all individuals…..I’m not

  12. I think the position “we need to do everything by hand” is short sighted and doesn’t help anybody.

    What is the point of writing HTML + CSS by hand? So far it’s been done to help search engines do a better job at indexing our content. That’s it, no other reason.

    The fact that there’s a lot of people enjoying breaking their heads and spending hours to figure out clever ways to bend the markup to their will, most of us in the wild worry about being productive, and making a living.

    The current state of the art is simply untenable, and makes good design unviable for all but a small sub-set of sites.

    Nobody expects cars made by hand from scratch, nobody writes their own PDF files with a text editor, why do we insist in wanting to do everything by hand?

  13. These CSS3 based illustration have the merit to explore and demonstrate new possibilities, but don’t they more and more look like dick size contests ?

  14. @Luca: Because web design is an art – both visual and coding aspect of it is an art and that’s what makes it beautiful.

    I imagine you have also been questioning yourself as to why Monalisa had to be painted by hand by Leonardo da Vinci and not by robot?

  15. @Luca: and I would like to add that taking your “cars not built by hand for example”. Can you imagine what would happen if these engineers did not understand the process of how this car was built and cared nothing except for the way cars looked physically? We would all have died by now.

  16. Nicely put.

    I think a lot of these code-as-images experiments really are just that: explorations of a cool new shiny. Waiting for adoption of these new tools by browser-makers is one thing, but I don’t think we’ll get to the point of these feasibly replacing images until their rendering performance improves.

  17. These CSS3 illustration might be a good way to explore and demonstrate new possibilities, but they more and more look like scaled down versions of the Vatican made with matches. Next up, Machu Picchu !

  18. @Guilty Carnivore: We insist because ultimately it’s more efficient and gives you more power, understanding, and control of the process.

    This is, in some way, a repetition of the old (circa 1974) argument of whether to program everything in assembly language (more efficient and gives you more power/control) or to use one of those new-fangled “compilers.” At one conference, I heard this exchange: The assembly guy said, “Compilers produce code that is only 80% as efficient as the best human coders.” The compiler guy responded, “Yes, but how many ‘best human coders’ do you have working for you?” I realize this is not an exact analogy; a tool-generated page only 80% as elegant as one crafted by hand is going to look extremely ugly. But how many “best human designers” are making web pages? [Side issue: “looking good” is not an issue for some sites, e.g.,]

    I tend to agree with @David Sleight: “The task requires a fundamentally different form of GUI that we haven’t seen thus far”

  19. The task requires a fundamentally different form of GUI that we haven’t seen thus far

    We have. It’s called Microsoft Word. If you have a basic understanding of HTML semantics, and a good understanding of the language in which the content is written, you could use a tool like Word to mark up the content as headline level 1, headline level 2, paragraph, definition list (and items pertaining thereto), ordered list (and items), and so on.

    Creating the underlying HTML is easy, leaving aside the new and nested elements in HTML5 and accounting for differences in style (my definition title and definition item could be your H4 and paragraph).

    That’s easy, with or without a UI.

    What’s hard is incorporating only the needed hooks for a visual layout, and then writing well-formed CSS to deliver your (fixed or responsive) “page” design(s). Doing that requires an almost poetic ability to straddle the abstract and the concrete.

    Good CSS is strategic, like chess. Yes, computers can be programmed to play chess and win. But there are infinitely more variables—more “moves,” good and bad—in a web layout than there are in a chess game.

  20. @Tom: Paintings in that particular age were more often the expression of a pictorial need than works of art. While some of those are incredible works of art, some of them were just filling the need of a world that didn’t know photographic reproduction. After photography became popular, painting became much less popular and reserved to the “pure art” circle.

    @Tom: an engineer designing a car has no idea whatsoever about how a screw is forged, or how a tire is vulcanized. They just read the spec sheet and use whatever they need to make it work.

    @Guilty Carnivore: this is not sustainable, that’s the point. When you say better results, you mean better for yourself. Who is that better for? How is hand-coding making things better? Can you put a dollar value on that?

  21. Adobe has currently multiple products in the bitmap space – the product teams of which would be opposed to a new product in this space. So it will have to be something politically compatible. Repurpose the Freehand tool and brand?

    That said, despite their recent douchery, they are absolutely best placed to take advantage of the whole HTML5/CSS hype wagon and should be working hard to become the defacto choice for this new flavour of the web in the future – because I know others will be taking advantage of their Flash-based-and-iPhone-baiting distraction to attempt to carve their own niche.

    Hopefully they’ll wake up.

  22. But while our current tools can certainly stand improvement, no company will ever create “the modern day equivalent of Illustrator and PageMaker for CSS, HTML5 and JavaScript.” The very assumption that a such thing is possible suggests a lack of understanding of the professionalism, wisdom, and experience required to create good HTML, CSS, and JavaScript.

    True, though I’m sure people said comparable things about movable type or the assembly line. I agree though, it’s unlikely for someone to make this application. Certainly not Adobe. They’ve long since fallen out of favor as the corporation that understands and inspires their customers. Now they seem to languish in blissful ignorance of modern production processes.

    I think, at least in the shorter term, the answer lies not in an application that can do all of these things for someone, but in an application that can assist them better. An application that acknowledges the ways that CSS works with type, or the way a browser and its variant window sizes render a shape (allowing it to grow and shrink, or remain fixed), and all of the other properties unique to interactive media. I’m not a very big proponent of designing in the browser; I think tuning in the browser is a better flow, but that leaves us with little else to use than tools we sorta hack around to make them work for comping.

  23. Artful design and development requires a certain intimacy and until a generative program can match that intimacy the best method falls to the process with the greatest intimacy: manually.

    The current tools available do not meet the same potential one can reach with their own knowledge and skill, therefor the employment of programs that perform work that can be done manually is donated by the hands of two kinds of people: 1) People who know how to do what the program does and use it for convenience and 2) People who do not know how to do what the program does and use it for necessity.

    In an industry where manual results dominate – both in reverence among peers and by success in the market – one is at professional risk if they rely more on a program than on their own knowledge and skill. What is one to do when neither they nor their program can produce what is expected of the them? The distance to resolve in this scenario is proportional to how much has been left unlearned by the person and the effort required to cross this distance is increased by the magnitude of what has been left unlearned.

    While building tools helps us grow, using them when it halts our own understanding does not. The lesson is that in order to progress as an industry, the direction must still take it’s heading from craftsmanship.

  24. @Luca Candela. Yes I can. I can create websites, with lean chunks of code, that backend developers can easily hook into in order integrate rich application functionality. I can progressively enhance my semantic markup by using the DOM to attach javascript behaviors quite readily. I can return to any project, years later, and instantly understand the underlying structure and easily make updates, swap out content, or bootstrap. If anything seems vague, there are usually comments in markup or javascript that clue me into what was the original intent of any particular chunk of code.

    Also, the page is lighter that what would normally otherwise generated from any automated process, allowing for quicker load times, less bandwidth, and thus a better user experience (not to mention lower server bandwidth overages).

    All of this is quantifiable from a monetary perspective, as it saves my client money and myself a lot of headaches.

    @J David Eisenberg. I don’t disagree with your assertions or analogy, in some respect it’s valid. But currently, there’s nothing for me personally that substitutes my process: take a layered Photoshop document, create semantic markup and structure, then apply CSS and integrating the necessary sliced images (which is becoming less cumbersome process due to CSS3 gaining acceptance). Even with the smallest of projects this is largely a process filled with snap judgement calls at every stage, which at the end of the day no program export or macro currently replicates at any acceptable level. Sometimes you don’t need a jackhammer when a plain ole’ hammer will do the trick just fine.

  25. I don’t know when I hear InDesign. My first thought is not HTML/CSS but XSL-FO… but for… print. Not really for the Web. It seems that many people still think that HTTP is a magazine stand for displaying the last brochure.

  26. @Luca: take Dreamweaver’s design view as an example. Say I built a site from there without understanding code. Then I check my output in a browser and notice some elements are misaligned. Since I don’t understand code and all th dragging and moving things around in Dreamweaver doesn’t seem to help either, what should I do now?

    This is the problem in this industry. Anyone who has built a site for their school project believe that they all have what it takes.

  27. Luca Candela said on 5 July 2010 at 1:56 pm:

    @Tom: Paintings in that particular age were more often the expression of a pictorial need than works of art. While some of those are incredible works of art, some of them were just filling the need of a world that didn’t know photographic reproduction. After photography became popular, painting became much less popular and reserved to the “pure art” circle.
    I believe you are slightly minimizing Renaissance for the sake of the argument. While naturalism was certainly a part of the art at that time and they studied light and perspective in design, the themes were most certainly not limited to reproductions of nature or portraits. Classical themes(religious or mythical) were a very big part of it. Hence one cannot say that the painters of the time lacked imagination, nor that a camera can reproduce all that the human eye sees or the mind believes to see. Few people are interested in the person that Da Vinci painted as La Gioconda. But most are interested to see how Da Vinci saw her. There’s emotion and a piece of the author left in every masterpiece. And while us Front-end developers are no Da Vinci(or if any of you are, I want to meet you), there’s a piece of us in every bit of code we write. And I’d like things to stay that way. Good things do come from the heart.

  28. CSS can never be the new Photoshop, because there made for different things. And how should an “Illustrator or PageMaker” for CSS or HTML “know” which content is going to be included. I wanna use semantic ID’s or classes for HTML-Elements! A tool like this, isn’t able to structure code like the way I do.

  29. @Ray Drainsville

    The continued success of handcrafted HTML & CSS may well be more a reflection of the state of the toolset than anything intrinsic

    I completed agree with this statement. Long live handcrafted HTML & CSS.

  30. Spot on, and loved the connection to library science. I’d never realized that, but it makes a ton of sense. Thanks for getting the ‘ol noggin churning ;)

    @jasonsantamaria, and @zeldman,
    Regarding new tools, I’ve been starting to collect notes and interest to create a better spec for a new web design layout tool that would be comparable to photoshop or Fireworks, but mimic or honor practices like the box model so that the transition from comp to code is more fluid. I’m currently browsing for the right tool to begin creating that spec from a community of contributors.

  31. Well, I was one of those people who looked into PostScript files and complained. I loved working in PostScript code in the late 80s and early 90s, and there’s no doubt that a hand-crafted PostScript file can run rings around anything these programs can knock out. I can do in 1K what it takes a megabyte or two for Illustrator or InDesign to create.

    But you know what? It stopped mattering. Hand-crafted HTML and CSS matters less today than it did a few years ago, and in another few years it’ll mean even less. There will always be a place for human who can tweak code and get it “just so,” just as there are still people who can make a PostScript or PDF file do magic. But the vast majority of people who create pages (any kind of pages) should never, ever have to see or touch code. That’s what computers are for.

    We’re not there yet, but the most HTML/CSS “artists” work with the tool developers to create these tools, the better the result will be for everyone. Obviously, Adobe needs to pay attention and bring more of you on board.

  32. Isn’t this just a generational resistance by craftspeople, to tools that have the potential to make part of what they do obsolete? Haven’t we seen this all through the history of the Industrial Revolution, printing, typography, television, photography….?

    As someone with a nominal arts background — I wish people wouldn’t throw the word ‘art’ around and conflate it with their work. Just because it’s hand-made doesn’t make it art: it’s craft. Like old-school masonry, woodworking, and cheesemaking. Art (to quote Scott McCloud) has no purpose except to be art!

    Let’s face it — we’re writing code in order to make software-machines (browsers) produce desired results in a repeatable, that is to say reproducible manner. Certainly, working backwards, those processes can be turned into heuristics and algorithms, and given form with a visual interface.

    Will a new generation of GUI design tools replace bespoke hand-tuned code? Maybe…but as with phototypesetting or InDesign, the quality of the final output will still depend greatly on everything that happens before – ideation, graphic design, understanding the medium, understanding the context, and (with interaction) creating a great user experience.

  33. I think Photoshop (or Fireworks, whatever) could benefit from a better understanding of HTML/CSS, but I agree that no software will replace the ability of a designer to write good, semantic code. If Photoshop could do things like export CSS for type, or shapes, etc, then we’d come a long way.

    Personally though, I think it will have to be a new player that creates the ultimate web designer’s image app. We’re just now seeing decent competition for products like Dreamweaver. (Dreamweaver’s a fine app, for hand editing code, though it’s overpriced and bloated.) Products like Coda and Espresso have changed the game for people who write HTML/CSS. I think it’s just a matter of time before someone creates a Photoshop/Fireworks-esque app that understands CSS, and is easy to use/accessible.

    Adobe is the new Microsoft, within our industry. It’s what people grow up using, and once you get over the learning curve for an Adobe product, you don’t want to try anything else. There are other fine image editing programs out there, but none of them compare to the power and ease of use (relatively speaking) of Photoshop. Once some designers commit to using and learning some new tools, we’ll be able to let computers do the things computers are good at, so that humans can stick to doing the things humans are good at.

  34. Hand-crafted HTML and CSS matters less today than it did a few years ago, and in another few years it’ll mean even less.

    David Blatner, on what evidence do you base this rather startling assertion?

    Lean markup and CSS (the kind a human being can write but a piece of software can’t) matters less when people are accessing the web via mobile, and mobile use is expanding eight times faster than desktop browser use did? Bloated, nonsemantic code that takes five times longer to download is just fine when 3G network users will leave your site never to return if it takes more than a few seconds to appear in their smart phone?

    Lean markup and CSS (the kind a human being can write but a piece of software can’t) matters less when there are more and more sites online, making your site’s content that much more of a needle in an ever-larger haystack? The growth of the web is a tide washing your site’s relevance away. Companies spend millions on SEO to fight their irrelevance; yet good, semantic markup has a profound effect on findability and is part of any coherent SEO strategy.

    With the advent of mobile and the ever-increasing importance of findability, good, hand-authored markup matters more than it ever did. Your espousal of the contrary makes me very, very curious to learn what websites you’re talking about, and what evidence you’ve examined.

  35. A timely observation.
    The industry must take a fresh look at web authoring tools. CSS has become very, very capable, but also quite complex. We can’t count on CSS gurus (or those who simply plagiarize) to create the next wave of pages for the web.
    Check out the Skybound Stylizer CSS editor for a peek at where the next wave of design tools need to go. (Not affiliated, just impressed.)
    The tools of the future need to get the CSS rules out of the author’s way and generate them automatically as code in response to design decisions made on elements within the canvas of the browser window itself.
    Sure, we’re still far from the point where hand-coding is obsolete, but you can see that day in the offing, for sure.

  36. Tools like SASS and Compass make it much easier to hand-craft stylesheets. Designers can learn these tools very quickly, and they have the potential to make managing hand-crafted CSS so much less painful. I can develop 10 stylesheets, one for resets, one for colors, one for layout, however I want to slice things, and generate ONE minified stylesheet for production. I can also reuse code. My article in February’s PragPub magazine goes into more detail.

    Better CSS with Sass

    Hand-crafted HTML and CSS aren’t going away, but that doesn’t mean we shouldn’t get smarter about creating that hand-crafted code. No need to type -moz-border-radius when we can type !boder_radius(10px) and get all four generated for us :)

  37. “No?” Ok then, why?

    I disagree with you that “authoring good HTML and CSS is an art, just as authoring good poetry or designing beautiful comps in Photoshop is an art.”

    Authoring good HTML and CSS is a craft. It’s skilled knowledge, but it’s not art. It’s knowing the machine, and knowing how to punch the cards just so to get the machine to give you the results you want.

    I don’t deny that there is aesthetics and intuition and creativity involved in craft, but to equate it with poetry is a bit of a stretch. And yes, there’s craft in art but no-one mistakes a Chippendale dresser for a Henry Moore sculpture.

    Again, no-one’s expecting software to create great sites at the push of a button, but there is enough cumulative knowledge of best practices, and also solid, empirical knowledge of what browsers do, to be able to create a tool that, at the very least, outputs code that isn’t full of span tags…

  38. Jeffrey Zeldman, on what evidence do you base this rather startling bitch-slap of David Blatner?

    Right now it appears that you’re both lacking in the citation department.

  39. completely agree with you. Loved your comparisons with music as well as the library example. Perfect ways to describe HTML.

  40. I deeply respect your abilities, Mr. Zeldman, and it was a pleasure to meet you in person, but I think you’re missing my point. Nor do I feel “slapped” in any way, as much as you might enjoy the thought of doing so.

    You and I are both correct in our own ways, I believe. There is no doubt that your art is important today and in the next few years, especially for mobile. But where it would do even more good for even more people is in helping tool-developers (like Adobe and many others) create better tools.

    Do you really see the majority of publishers/designers hand-coding HTML5/CSS icons and such 5 years from now? That’s a ridiculous idea.

    The evidence is history: No hand-crafted work used for mass consumption has remained hand-crafted, other than art for the sake of art. As others have earlier pointed to: typesetting, layout, photography “darkroom” techniques… In your own web world: Dreamweaver and other environments have enabled hundreds of thousands of people to create/design/deploy in way that they never would have been able to had they had to rely on hand coding. Granted, those sites are best viewed on the desktop, but someday will evolve to better handle mobile with ease.

    Yes, you will always be able to do it better than a machine, just like I am able to write PostScript better than a machine. But you are blind if you think that the “good enough” world of computer-generated code will not eventually overtake you, especially in the areas that these blog posts are talking about (icons, frames, background, etc.).

  41. The minute a tool starts doing the markup for me is the moment I quit web development/design, move to Tibet, & become a monk.

    David Blatner, I assume, makes sites which such solid craftsmanship, that you have to have IE 5.5, Firefox 2 Safari 2 & at a “optimized” resolution of 800×600. Saying hand-crafted HTML/CSS matters little now and less in the future is like saying my kids matter little now and will matter less when they grow up and move out of the home. That statement is infinitely ludicrous.

    I guess though, I could be wrong. Time to bust out and dust off my copy of Adobe GoLive and get crack-a-lackin’, don’t want to disappoint Adobe, right David? I mean, why bother when we have computers to do it?! Drag & drop, the hobbyist method. Intuit let’s business owners create websites for themselves, so they can spend less money. Drag & drop, create a site with so much bloat it takes forever to load on slow connections or mobile devices. Yeah, that’s the kind of web we want!

    Puckering up to kiss Adobe’s ass-end is not my idea of a hand-crafted site. Creating it by hand, thus the “hand-crafted” is what I’d rather do, where I have control over markup, layout, & presentation.

  42. Isn’t this just a generational resistance by craftspeople, to tools that have the potential to make part of what they do obsolete?


    You could at least say why?

  43. I don’t care how many Web Developers you have involved in the creation of software, nothing can ever replace what a human does when it comes to handcrafting XHTML and CSS. Software doesn’t assess code and decide what the best avenue is for the project at hand, and no software will troubleshoot. Sure, software will better assist with what we’re handwriting (i.e. Panic Coda’s Clips panel, auto-complete in multiple applications) but that’s where it should end.

    Would you let a robot build your house? Like

  44. I think the responses to this post actually prove my point. Those with a big time investment in hand-coding “mastery” are the ones who are the most vehemently against the idea of an ‘indesign for css/html’, who sneer at mere ‘hobbyists’ who ‘drag and drop’ (still using DOS, then?) and who seem…well…threatened.

    Why shouldn’t I be able to draw a rectangle (in one efficient gesture) and have the program understand that I want to place a div there, and style it with a few clicks inside a palette or two, instead of tediously typing a lot of markup and having to jump between code and stylesheets?

    The question is not “should or shouldn’t we have GUI tools for web authoring,” but more, can we encode rules into a system to avoid precisely the kind of bloated output that the detractors rightly decry? The conversation has been poisoned by the failings of previous tools (Dreamweaver, GoLive, etc.) but it does not logically follow that a good tool cannot be created.

    If we want a system that outputs lean, economical code, that hews to standards, follows good practices of re-use and proper nested relationships etc, then what we’re really talking about is creating a sort of ‘html / css compiler,’ isn’t it?

  45. Every now and then they reappear: the people who think that machines, computers and software can replace humans in just about everything.
    For many things it is true, but not for creating software and that is what websites are. It’s a collection of statements that define a product. Creating that is a creative process with decisions all the way.

    Sure, tools can and will make that task easier, but even then a human still has to be in the driving seat and make decisions on how to solve problems and how to implement certain functionality.

    A tool or machine does not understand semantics so us mere humans must help them out. There will come more and more tools that will help us write semantic webpages and style those using clever CSS, but which tag is used and which options to layout the page are decisions made by humans. No machine can replace them in the coming decades.

    Keep it coming to us, Jeffrey! And be gently when you slap someone.

  46. This article ignores theory and recent history in progress toward Artificial Intelligence. If the concept of the technological singularity is not just possible, but rapidly approaching, creating a program that will write the kind of markup and CSS that experts create now is not even one of the larger hurdles. Consider the recent unveiling of Watson, IBM’s supercomputer that can determine the nuances of Jeopardy questions and regularly beat champion contestants. It seems like a stretch to propose that it will be impossible to create semantic HTML and CSS automatically when progress like this is considered. Will Adobe do it? Now that does seem unlikely.

  47. i love the analogy of the automated construction of a car that gets thrown around. it’s actually quite apt, but not in the way most people use it. we are not going to be replaced by the robots that assemble thousands or millions of copies of the car. that robot is already here, and it’s called the browser. we are the designers and engineers that make the model, evaluate the parts needed, adjust the design based on performance, tastes of consumers, the marketplace, price constraints, etc. then we finalize the the plans, some of which get converted into instructions that tell the robots and metals stamping tools and, yes, even some humans, how to put that car together, over and over again.

    html and css are our tools for telling the browser how to recreate that site, over and over again with consistent results. and we can even customize some things based on context, and if we’re working with dynamic code we can modify the page based on user input and changes in the data. our toolset (html5 & css3) is evolving, and the tools we use to create this layer of meaning and these browser instructions are also evolving. we’re getting more options that allow us to generate our markup and styles with less friction, with more customization for how we want to work, and with a better understanding of what we do baked in.

    i wonder why we haven’t seen mass adoption of wysiwyg tools by the leaders in our industry? why have we been going the other direction in recent history? i started by hand-coding everything. then i used dreamweaver for a while. then i switched back. why is that? i think it’s because we realized that the layer of abstraction wasn’t good for our craft. to return to the car analogy, the vehicle which came out at the end didn’t run very well, and wasn’t quite how we wanted it to look, and it was hard to fix. we realized that we were losing something in the translation, so we started going back to creating things in the way that offered the most direct translation of our ideas and concepts into specific rules, and finally into the finished output we wanted. we were talking to the software that talked to the browser, when we can just talk to the browser.

    as several folks have pointed out in the comments, this prediction of a photoshop/illustrator/indesign is based on a fundamental misunderstanding of what web design is. in print design, that magazine or book or brochure is *the thing*. the web is a different beast. the line between my design and the visitor using my site is much shorter. my markup and styles are *the thing*. they don’t just offer a visual layout to the site visitor, but they need to contain the meaning within the structure, and have the flexibility to respond to context. photoshop is great for creating a static visual and then getting it printed several million times. web sites (good ones, useful ones) are not static, so why act like we’re doing the same thing we used to do before the web came along?

    personally, i think there is further evolution for our tools. but i don’t think “photoshop and illustrator for web design” is the direction. i think the direction is in further reducing the friction we experience. for me, that’s all about the frameworks that are really coming into their own. where i work, we build sites using rails, so sass and compass have replaced a lot of the grunt work we used to complain about. i don’t have to write the same rules five times for five different elements, or declare my rounded corner radius using every vendor prefix variant, because my framework does it for me. i just write what i want, with a lot of shorthand available for the things i use most often. the software compiles it for me and off i go. i think our future tools will make frameworks like this even more user-friendly and build the compiling steps into the applications we use, and maybe css will even evolve in this direction. but i think we’ll still write the instructions, and we’ll still care about the meaning of our content and the quality of our rules.

  48. Sean:

    I’m not ignoring AI on principle; I just don’t think there’s an AI that can write markup and CSS like Aaron Gustafson, Eric Meyer, Ethan Marcotte, Dan Cederholm, Nicole Sullivan, Andy Clarke, or Tim Murtaugh.

  49. David:

    Of course I don’t expect most people to hand-craft their HTML and CSS.

    Most people don’t hand-craft their HTML and CSS now.

    Instead, they use blogging tools and content management systems (programmed by experts) filled with templates designed and programmed by experts (including experts in HTML and CSS).

    The owner of Local Restaurant X doesn’t need to be expert in HTML and CSS; she just needs to use a well-put-together WordPress or ExpressionEngine template (put together by a team that includes CSS/HTML experts) or a website designed by an agency or freelancer (with expert HTML/CSS as part of the package).

    Will there continue to be websites that don’t use good HTML/CSS, don’t hire agencies or freelancers, don’t use excellent free templates in systems like WordPress and ExpressionEngine, and don’t benefit from good HTML and CSS as a consequence? Of course there will be. Will some websites always be generated by tools like iWeb, which create bad HTML and CSS? Of course some websites will be, and they will be “good enough” (as you put it) in the sense that simply publishing a website (however well or poorly crafted) allows the site owner to accomplish some personal or business goals.

    Will there always be some agencies and designers who don’t understand the value of good markup and CSS, and who use tools to generate merely adequate code? Probably so. And, by your definition, it will be “good enough” if the website is out there being seen and used by customers. There is certainly value to publishing, and any tool that helps you publish is “good enough” in the sense that it accomplishes its mission.

    But if a site weighs three times what it should (because its markup and CSS are not optimal), and this causes it to perform poorly over 3G networks, then that site will lose customers, and that isn’t good enough. And if a site costs a fortune to update because it is founded on slipshod markup and CSS instead of portable markup, so that the site owner either spends too much on a redesign, or can’t afford to redesign or add new features at all, then the HTML and CSS that came out of a piece of software may not be “good enough” after all.

    Everyone does what they have to. If you don’t know how to author good HTML and CSS, don’t have time to learn, and have no budget for HTML consulting, but you own a tool that can produce HTML and CSS, then you should use that tool.

    Many people are in this kind of situation, and many companies can’t afford the best web designers and developers, but creating a site that is “good enough” in the code department is nothing to celebrate. (Just like creating a site that is “good enough”—good but not great—in its design and content is nothing to celebrate.)

    I’m in favor of improving our tools—The Web Standards Project worked with Dreamweaver in the late 1990s and early 2000s precisely to attain this end. But just as a thesaurus is no substitute for a writer, a tool (however capable) is no substitute for a developer.

  50. I wrote some of my thoughts about this topic on my own blog, but a few points made here had me thinking.
    I don’t think anyone can argue that we’d like full control over our presentation (CSS offers some hope there), and I don’t think think anyone can argue that there’s no substitute to great code either.
    It’s obvious to me that the argument here is less about the tools and more about the people who create the content. Those who already write code do a really good job, and while apps like Dreamweaver can help streamline production, Jeffrey’s comment about Microsoft Word as a capable tool still stands.
    So it’s really all about the other side, the design side, that struggles the most. Of course developers don’t need an equivalent of Illustrator for HTML and CSS. But designers do. Because designers won’t write code, or to Jeffrey’s excellent point — they will never learn to write anything more than “good enough” code.
    Rather, I believe a company needs to develop a tool that allows designers and developers to both work in hand (instead of against eachother). Not to start a whole flame war on Flash vs. HTML, but on some level, Adobe has been able to do this very well with Flash Catalyst and Flash Builder. Consider the pure concepts: One app is for the developer and one for the designer. They are built on the same code base, use the same file format, open each other’s files seamlessly, and offer each side the tools they need most.
    The problem with Photoshop, and all other Adobe design tools for that matter (I personally favor Illustrator for a variety of reasons — not sure why no one has mentioned it here), is that it’s pretty much a one-way street. And no code coming from there will meet every task. Only a truly collaborative workflow where design and code can be tweaked simultaneously and independently (which is where Flash Catalyst and Flash Builder are headed) can “solve” this “problem”.
    So to better modify the statement, what Adobe (or some other company) needs to do is to create a Flash Catalyst and Flash Builder for HTML/CSS.

  51. @Mordy Golding

    you say “Because designers won’t write code, or to Jeffrey’s excellent point — they will never learn to write anything more than “good enough” code.”

    i’m a designer that learned to write markup and css (i won’t call it code). and not just “good enough”. i care a lot about what i create, and strive to keep up on the latest advances in my craft. lots of designers have learned this, and lots of people who started by writing code, or markup, have learned to be designers. perhaps people like me are in the minority, but i think a lot of designers can learn html and css, and if current trends continue more and more will, because they’ve become more valuable in the talent market.

    i’m all for tools that make it possible for more visual designers to work on the web while maintaining quality. that said, html and css aren’t that hard to learn, and the value in learning them is great, if one is a designer that wants to make web sites. it takes time and effort to master them, but no more than mastering complex software such as indesign or illustrator.

  52. @River Brandon
    …but i think a lot of designers can learn html and css, and if current trends continue more and more will, because they’ve become more valuable in the talent market.
    My point was that designers shouldn’t be writing code at all. I agree that they should know basics about code, and they should understand how things work (just as an architect would benefit from knowing how materials are made and how they are assembled), but shouldn’t a designer be spending his/her talents on better design?
    It’s not that designers can’t write code — we’re pretty smart and we can learn whatever is necessary for our jobs. It’s more of what we want to do — design better experiences and better sites. To Zeldman’s point about bandwidth, would I rather a lean awesomely-coded site that forces to me to click 30 times to load different pages to find what I need, or that same site that is designed in a way that I find my way to the content I need in 1 or 2 clicks?
    I just feel that designers should be focused on what they do best, and developers should focus on what they do best. And I’d like to see a set of tools that lets us work in harmony.

  53. But the vast majority of people who create pages (any kind of pages) should never, ever have to see or touch code.

    That’s true, which is why they should never have to see something like postscript (a programming language, and a pretty ugly one at that). There should be no problem whatsoever with the average content producer seeing HTML, which is more akin to a system of punctuation. I think it’s quite patronising to suggest that someone with an average level of education can’t be taught to surround paragraphs with <p></p> tags.

    CSS, on the other hand, is a whole other issue …

  54. I have a feeling that many people are not ready to give up on pretenses. Just as a point-and-shoot wouldn’t make you a photographer, a WYSIWYG could never make you a Front-end developer. If you say you studied CSS and HTML, you know it well and are still finding it too annoying to work with, then most likely it’s not for you. Just because the market has a demand for it, it doesn’t mean that you have to do it if your heart is not in it. Some seem to be under the assumption that with the proper tool they should be able to do anything. Probably, in an ideal world, yes. But this is what we have and some of us are content with spending hours writing code that works and looks as it should. And we also have the right to complain and look with contempt at the wannabe tools on the market. Because CSS and html are not only about layout(as if that wasn’t hard enough for software to achieve). There’s a logic behind that code and it is based greatly on content as well. And however great our faith in AI might be, it is not ready for that yet. Of course, it’s probably in that direction that software is going. But it will take time and proper guarding/improvement of standards. And do keep in mind that if such software was to be created, one would be created for achieving design as well.
    At the same time I doubt that Front-end developers will disappear – I still enjoy a fine tailor instead of the mass produced clothes and I still love the feeling of a leather bound book despite e-books.

  55. Creating a machine to do a human’s job will ultimately end in disaster. Ask John Connor or Morpheus, they’ll tell ya.

  56. @David Blatner
    I would welcome tools that meant there were more quality websites and less ‘junk’, but they will never replace a skilled coder. The idea that clean code and professionally written xHTML & CSS is going to become less relevant is bizarre.

    To expand on Emma’s analogy of the Camera (which I think is a simpler concept than the Car ones).

    Even with the most expensive, top of the range DSLR you still need to understand some basic principles of Photography to take a good photo.
    Without understanding basic concepts, such as lighting, framing, perspective, depth of field – or in some cases which direction to point the camera ;) – you will never take ‘great’ photographs.
    Sure, automatic White Balance, Exposure, Flash and ‘smile detection’ can help you take a better picture – and that might be enough for some people – but it’s not enough when you are paid to get a ‘result’ or specific shot.

    Back to Web Design, the more the software can help you the better, of course, but without the understanding and skills in the first place the designer / developer will never know if it’s better (or not).

    Even when software becomes flexible enough to offer alternate ways of presenting items on the page – you still need a skilled decision maker to choose the most effective one.

    @Jeffrey – good article and nice to see you stirred up some debate.

  57. Whenever I use Indesign I always wish I could write HTML/CSS instead of using the indesign tools.

    Copy/paste, move everything up 5mm, it’s horrible. Just do it in one place and your done.

  58. This argument has been made so many times before I can’t believe people are still making it. It was a cliche probably before you were born. (The same way the major Content industries claiming that each new technology will ruin the experience for everyone is a cliche.)

    For a good example look at computer programming. (You tried to claim that PostScript wasn’t a good example, but I don’t think you played fair)

    Initially (well, after binary) all code was written by hand, in assembler. The code produced is fundamentally an art form when you are writing in assembler. Programmers said you would never automate assembler creation because it would create bulky inefficient inelligant, wasteful design.

    They were right. But only on the second count. Windows requires how many gigabytes for a full install?

    If you can’t see a time when CSS and HTML creation will be automated, it’s only because of your short-sightedness. (it might be CSS 6 and HTML12 but it will definitely happen.)

    Will we all lose out in some way when CSS and HTML automated generation comes into its own? Certainly. But we will gain so much more in return.

    Will there still be the esthetes who hand code everything from scratch? Probably, for a generation or two anyways. Will their arcane abilities produce tremendously fabulous creations? Almost certainly, but it won’t change the reality that 99% of CSS and HTML generation will be automated. eventually.

    I’m only 32 years old and I’ve got a lot more to learn about life, but this is such a certainty, I was sure you were kidding and read the whole article waiting for a punchline.

  59. @Tom You can atleast say why

    Back around 2002, 2003, I felt that tools were replacing HTML at the time, as most people could use dream weaver to build a web page. That was during a period for me where I thought table layouts was the way, and I didnt know much about server side and backend processes. I actually stepped away from the web briefly then, as I wasn’t sure if there was a future for people who liked to do the code. Because of the way things went in my life, I went to college for computer programming in 2006. I there learned to embrace XHTML standards, proper CSS. Separating the content, layout and the behaviour. When I started to do that, I realized my assumptions back in highschool were wrong. That while tools like Dreamweaver WYSIWYG are able to emulate a page very well, they only have one or two ways of doing it. How a page is to be structured and built using HTML and CSS depends on the design and the requirements. I firmly believe that it is important to have a human mind put this part together.

    In terms of photoshop being used to generate HTML, a designer at my work uses it occasionally for email blasts. For the most part, it has worked quite well for him. Recently he ran into issues building one. After slicing the images, and having the html export from photoshop, he ran into many issues trying to get the page working how he wanted. Afterwards, we also noticed some issues in different browsers when testing the page, and I had to go fix it. Since the code was all in tables, and I haven’t coded like that in 7 or 8 years, it was tricky for me to fix as well. Doing a design in photoshop is fine, so long as you keep in mind that it has to work in HTML and CSS. However, using the exported HTML I think can cause more grief.

  60. The comment about “generational resistance,” really got my goat. The only way, to my mind, a person could have that opinion is by having a rather thorough misunderstanding of the factors at play in the field of web design/development. It is distinctly not a matter of generational resistance, but rather a matter of more-complete understanding of the technology, the limitations, benefits, and idiosyncrasies thereof. Most professional application and system programmers do not use code-generators either, particularly for projects that require precise results. The variables are too numerous and complex for any programmatic algorithm to make the “correct” decision every time. A lack of understanding and a profusion of laziness do not equal an argument for a CSS/HTML markup generator. I’ve never seen a code-generator that created acceptable, much less optimal, markup. Show me a tool that does that, and I might reconsider. That said, the truth remains, whether in post-script or in HTML/CSS, humans are able write better code than any piece of software ever has. It may change in the future, but I’m proudly skeptical!
    Someday my loony bun will be a fine benny lava.

  61. One short, final thought: I find it fascinating how many people refer to hand-authoring html/css markup as tedious and/or inefficient. I became fluent in XHTML and CSS and it seems as easy as composing a friendly email, now. A lack of fluency or experience doesn’t mean a task is inherently inefficient, but gaining that fluency may require a shift of mind-set.

  62. Extremely interesting article, i personally feel the closest we have to this idea so far is CSSedit especially with its live view and excellent toolbox UI. With this software i have skipped the ‘photoshop design’ stage and just started coding.

  63. @David Blatner : these CSS3 icons are just illustrations of what has become possible to do with CSS, and I don’t think any hand coders here would enjoy spending half a day coding what you could draw in 15 minutes with graphic tools like Illustrator.
    But knowing how to design these icons will give you much more freedom and options when you’ll be making choices for a website design. Just as knowing how to draw with a pen and paper will help you have a better understanding of how to design an icon with a 3D software.

    @readers who don’t understand why hand coding is important : have you had the chance to debug/change a site’s layout ? Have a go without a text editor and come back here to give us your feedback.

  64. @ Jeremy Anderson: that was my comment and I stand by it, because no-one has yet provided any decent argument to the contrary.

    I don’t mean to say that to disparage Mr. Zeldman’s formidable skillset (nor those of the colleagues that he mentions), but I do not agree with the ease with which people shout WYSIWYG Is Bad and Only Humans Can Do This Work. It comes across to me as Oh No Please Don’t Make My Niche Employment Obsolete. It reminds me strongly of the arguments hand-type composers made against phototypesetting (and then later, desktop publishing) and I lived and worked through those eras and, well, people adapted.

    And it’s easy to decry poor HTML but – having looked extensively – it seems that there’s very little out there in the way of teaching people good HTML practice. So they fumble along (sometimes aided by the relatively poor wysiwyg tools we have) doing ‘good enough’ sites with the knowledge they have. Surely knowing what to avoid (pitfalls, traps, dead ends) is valuable, but who’s going to write that O’Reilly book?

    The Super Experts Mr. Zeldman mentions have a set of internalized (occasionally written in books) rules about how to code things effectively / more efficiently, and it’s certainly possible to code those rules into a piece of software, maybe if they got together and pooled their knowledge…surely it can be turned into heuristics and algorithms?

    Sure, today in 2010, a piece of software can’t code HTML / CSS as well as the Super Experts, because the tools to date are either too nerdy/techy, or too literal and simplistic. I used iWeb to do a really simple site and I loved the ease of use and direct-manipulation, but yeah, it outputs horrible code and structures the sites in a non-standard way. I love Coda, and I’ve done a lot of template-editing and css-tweaking in it, but I long for direct manipulation. Surely, along with intelligent defaults / AI rules and some sort of compiler mechanism, we can find the middle ground here.

  65. @Morty Golding You said, “To Zeldman’s point about bandwidth, would I rather a lean awesomely-coded site that forces to me to click 30 times to load different pages to find what I need, or that same site that is designed in a way that I find my way to the content I need in 1 or 2 clicks?”

    Why would coding a website by hand force you to build a site that is not user friendly? Are you referring to building the site (and having to click around) or using the site?

  66. Yes, we need an indesign to HTML and CSS application. I’m sure adobe will buy out some company with the right people for the job.

    Jeff, please, please… Move the comment form to the top of the comment list. I had to scroll and scroll and scroll on my iPhone.

  67. @art

    Why would coding a website by hand force you to build a site that is not user friendly? Are you referring to building the site (and having to click around) or using the site?

    I’m assuming that a designer’s time is valuable, and we all have to manage our time. If I were designing a site and could spend my time focused purely on design and user experience, and not also have to spend my time getting the code right as well, I’d ultimately produce a site with a better user experience. More importantly, I’d have more time to iterate on a design to get it right. As a designer, once I spent time coding something, I’d be less likely to try to iterate as it would potentially mean recoding.

    Of course, I agree with the overall sentiment of this article — as a designer, I don’t want a computer to code for me. I want a person doing that. But I don’t want that person to have to be me.

    Taken a step further, if you truly appreciate a great developer (and I do), then you have a healthy relationship that lets you question the status quo, and ultimately move the web further. I would imagine that designers are really good at pushing the limits of their designs. And I would imagine that developers are really good and pushing the limits of every technology framework. If there were a true collaborative environment, designers could better challenge developers, and developers could better challenge designers. Now though, it just seems that everyone is too afraid that the other is going to make the other obsolete, and no one wins.

  68. Of course, I agree with the overall sentiment of this article — as a designer, I don’t want a computer to code for me. I want a person doing that. But I don’t want that person to have to be me.

    It doesn’t have to be you. That’s what agencies (and freelance partnerships) are for.

  69. Jeff, please, please… Move the comment form to the top of the comment list. I had to scroll and scroll and scroll on my iPhone.

    The comment form is at the bottom so you’ll read other people’s comments before leaving your own. Doing so is not only a courtesy to other posters, it also reduces the likelihood that you’ll post the same thing someone else (or multiple someone elses) have already said.

    Of course, if you scroll down without reading the other comments, you can defeat the purpose of my design choice, as you have done. But you won’t be contributing meaningfully to the conversation if you’re only talking, not listening. God gave us two ears but only one mouth. We should listen twice as much as we talk.

  70. I do not agree with the ease with which people shout WYSIWYG Is Bad and Only Humans Can Do This Work. It comes across to me as Oh No Please Don’t Make My Niche Employment Obsolete.

    Why should I hire a writer to help with the content on my website? I own Microsoft Word. It includes a spell checker and a grammar checker.

    I have an autofocus camera, why should I hire a photographer to shoot my site’s photographs? (Because a photographer brings skill, passion, and vision to the shoot that a non-photographer with an autofocus camera cannot replicate, perhaps.)

    Why do serious photographers do their own developing, spend hours fine-tuning the print, and so on? Aren’t autofocus cameras and iPhoto good enough? Isn’t photography a niche employment, anyway, what with cameras being so advanced and all?

    Blah, blah, blah.

    AJ, I can’t tell if you’re a troll, or you just generally have no clue whatever that web development is not the same as transcribing a comp into code.

  71. @mordy golding

    My point was that designers shouldn’t be writing code at all. I agree that they should know basics about code, and they should understand how things work (just as an architect would benefit from knowing how materials are made and how they are assembled), but shouldn’t a designer be spending his/her talents on better design?

    designers shouldn’t be writing code? really? i don’t see why they shouldn’t. if a designer doesn’t want to write code (markup and styles, really), that’s fine. but what if they want to? what if it’s *part of the design process*?

    perhaps we have a fundamental difference of philosophy. for me, better code *is* better design. separating the two, by too much, leads to bad things. that is not to say every designer must build their own pages, but those who don’t should be working closely with front-end developers, if they want great results. and i think we’re both talking about great results.

    you don’t want to write the code, but you want great results? fine, then work with someone who is just as committed to spending their time on great markup and styles, because they go hand-in-hand.

  72. @jeremy anderson

    One short, final thought: I find it fascinating how many people refer to hand-authoring html/css markup as tedious and/or inefficient. I became fluent in XHTML and CSS and it seems as easy as composing a friendly email, now. A lack of fluency or experience doesn’t mean a task is inherently inefficient, but gaining that fluency may require a shift of mind-set.

    well said. you made the point more clearly than i did earlier. html and css are actually pretty easy to learn. and for me, it’s really about learning to think in the way that web pages work. it’s like going to italy and having a pocket dictionary or an electronic translator. or even a human translator. you can communicate well enough, but something is always lost. if you really want the full experience of the place, if you want to not just visit, but actually live there, you need to learn the language. and the language of *web design* is html/css. web pages don’t just look a certain way, they work a certain way, and the way they work is because of html and css.

    so to web designers, i say learn the native language, even if you work with others who will do the heavy lifting. you’ll be a better web designer for it, and someday you may even want to make your own web pages without someone else to help you.

  73. Well, Jeffrey, come on. I didn’t say anywhere that software could replace a trained, experienced professional; in fact I went out of my way to say quite the opposite.

    I know quite well that web development isn’t about simply turning comps into code. And a tool, no matter how sophisticated, can’t replace people (yet, anyway).

    The thing is, people keep reacting to the very idea of a good WYSIWYG tool without explaining why, beyond invoking the dead horse of FrontPage. I’d rather people say “If there were to be such a tool, it should do A and B and C properly while avoiding X and Y and Z,” but people seem hung up on the idea that it’s a complete impossibility. We thought iPhones were a far-off reality too.

    Mr Z, your arguments appear to boil down to “This is Art and computers can’t make Art,” and later, “A computer can’t code as well as (list of elite web professionals).”

    I argued that yes, while there are elements of art in the craft of web design and development, capital-A Art is something else altogether and we shouldn’t conflate the terminology (unless we’re talking about pure-art interactive pieces). I agree with you completely on the second point, but with the caveat that what those people know is something that can become an expert system.

    If that definition of web-dev as craft is reasonable, and I think it is, then techniques and best practice, can (albeit with great effort, I admit) can be turned into algorithms; these could further be modularized into functions; common structures turned into reusable ‘stencils,’ and so on.

    I believe it is possible to do all this and still output decent code, better than current tools; and at the very least ,as a starting point for a human programmer to take over and work with without gnashing their teeth and rending their garments.

    I want something like this because I code, albeit very slowly, much slower than I can come up with visual prototypes in other tools, because I’m a visual thinker who comes from a design background. I’d still like to avoid that step of Photoshop or OmniGraffle-to-code.

    What would be cool, from my POV, would be something like Coda + CSSEdit combined with InterfaceBuilder (on the front) and MaxMSP’s drag-input-to-output programming UI or Logic Pro’s Environment for basic back-end programming…. A literal flowchart that connects chunks of code to each other, or pipes outputs to inputs, event listeners to triggers, etc.

    Of course this doesn’t stop anyone from using TextEdit if they want to.

  74. AJ:

    I misjudged you. My apologies.

    If there were to be such a tool, it should do A and B and C properly while avoiding X and Y and Z

    If there were such a tool, I’d probably use it.

    Further, if there were a single tool that could intelligently see designers through the entire design process, from sketches to dynamic wireframes to live code and living pages, I’d certainly check it out.

    I’d be happy to test and provide feedback to anyone working on tools that can do this with rules-based intelligence at least approaching that of a competent web designer.

    Even if it only covered the part we’re discussing here—comping and coding—I’d check it out.

    Here are some of the things such a tool would have to do.

    For instance, currently, if I create a paragraph and style it, a tool gives it a unique class. If I create a second paragraph and style it the same way, the tool gives the second paragraph a different unique class with the same rules. Wouldn’t it be swell if, when I finish styling the second paragraph, the tool says, “You seem to be creating a general paragraph style. Shall I create a single style for paragraphs, and style all paragraphs this way?”

    It would then ask if I wanted to style *all* paragraphs this way or all paragraphs in this section or what.

    This is a trivial example of the kind of abstraction good web designers perform. It isn’t rocket surgery; a tool could help. I haven’t seen a tool that can work with existing layouts, analyze them this way, and provide the designer with intelligent choices to extend what’s in that single comp in ways the designer intended.

    The tool have to work both ways, too: it would need to extend that logic back into the comp.

    One of the dullest parts of doing web design work in Photoshop is painstakingly simulating styles you’ve already created as you develop new page types and new sections. Wow, what a joy it would be if Photoshop 2000 could ask me, “Would you like to fill the content in this section with the same paragraph and headline styles you used in ‘Home Page Comp’?”

    If software developers familiar with the web design process spent several years consulting with leading web and experience designers, I suppose anything is possible. It would still take a great designer to make a great design, and the output of any tool, even the brilliant hypothetical one I’ve just sketched, would need to be tweakable by those whose craft exceeded what the tool could deliver (and those tweaks would need to work their way back into the comp, which might be the most magical and least attainable part of this whole fantasy product).

    Is it possible? Beats me. Am I saying it would be exceedingly difficult if not impossible because I want to protect people’s jobs? No, although if I were trying to protect jobs, I sure wouldn’t be ashamed of that, either.

  75. I can’t wait for Photoshop 2000!

    But seriously, I’ve long wondered why Photoshop doesn’t have any form of style sheet functionality. That would be darn helpful for designers and developers alike.

  76. I saw some of the nice examples of such CSS rendered icons. A nice set is available here to view:

    The only thing is that such icons required so much of hand written CSS code which i thought would be very time consuming, nothing to take away from the creative aspect of CSS coding but then in real world scenarios we have less time to create those STUNNING interfaces designers hardly get time to for such creative renditions in their deadline driven projects.

    Secondly if so much amount of CSS is required it does add to some file size of CSS too then why not use light weight graphics instead.

    I am not totally sold to this idea. I think CSS geniuses will end up creating such icon libraries and people will simply buy these sets or download and use them in a fizz.

  77. Jeffrey, most of what you describe isn’t all that far-fetched for a program to do (though it does remind me of some of the MS Office era clippy interactions “Looks like you’re trying to make a list, let’s make a list! Please please, can we make a list!”

    The fuzzier part that seems really really hard for an app to do would be some of the tricky decisions we front-end people make when marking up a site. I have a hard time imagining (and I have a pretty good imagination) an application saying something like the following:

    “You know, it seems that this is the most important content on the page, I’m going to go ahead and put this a little higher in the source order.”

    or “I know you are styling this section header like all of the secondary headings, so normally I’d use an H2 here. However, there’s an extra level of headings here, making the document outline a bit more complex. Since we care about accessibility and SEO we’re going to preserve that outline, and I’m going to make this an h3 with an extra semantically-named class to hook in for styling it using the same CSS code for all of the h2’s.”

    or “This button text will need to be editable wont it? That means we’ll have to use @font-face or would you prefer another font? And of course either way that means it will be vulnerable text-resizing and variable line lengths, so I’m going to make sure we dont use a single static image in the background of that button.”

    Can computer programs do this sort of thinking? Sure, in the future, they will. But it just goes to show that this is going to be a very complex application.

  78. Designers shouldn’t code? That doesn’t make any sense to me. I went to art school, I have a BFA *and* I really enjoy the coding part of my work. In fact, code is my current media of choice to create visual designs.

    To my mind, HTML and CSS are tools, just like paints and brushes or litho stones and presses or markers and paper. If I paint, then I learn about how to best manipulate the paint itself, I learn how to choose the right canvas, I learn which brushes are the best for what I want to accomplish visually.

    Since my chosen ‘canvas’ is the web, I learn the tools necessary to create on that ‘canvas': HTML and CSS. It’s just like learning about brushes or inks or whatever.

    That’s not to say that there couldn’t be some shortcuts in that learning, in the form of better tools to help me code more efficiently. For example, I find it completely frustrating that none of the more current tools like Coda and Espresso actually show the cascade (like long-forgotten Xyle scope does). And yes, I do think there’s a lot of room for improvement in better ‘hinting’ and/or shortcuts for coders like Jeffrey describes above.

    But none of that should relegate designers to Illustrator and Photoshop alone. I can create visual work with whatever tool I choose – even code. It’s just a matter of learning the tools necessary.

  79. There’s something to what Nack says. Photoshop could be made friendlier to serious web designers. Adobe could also stop ignoring Fireworks, as Fireworks is a better starting place for web design.

    — Also a good point, Jeffrey! Fireworks is a great start for web design, indeed.

    Fireworks can also save you a lot of time, like the Photoshop 2000 that you dream of — because with the smart implementation of Pages, Layers and States (and Symbols), you can work in a much faster and efficient way! You can also have a Master page in your PNG document, and you could share your #header, #nav and #footer elements for all the pages in your design; this would allow you to instantly change parts of the design “site-wide” (“design-wide”, in this case)… almost as if you were using CSS to control some aspects of the graphic design! :)

    But even with the best tools (Fireworks or Illustrator or Photoshop), after the graphic design concept is ready, you need a top-notch Web designer (coder) to implement the design. And up to now, people were unable to invent a tool that could replace a great designer/developer/coder.

    …I remember myself starting my Web design career years ago, by trying to work in FrontPage (oh the horror!) and Dreamweaver. I was working in Design View, of course. But soon I discovered that once I have made a design in WYSIWYG style, it is very hard for me to change it… Then I also noticed that some webpages had much shorter and understandable source code, while others were bloated with FONT tags and were taking ages to load on a 33.6K modem connection. So I started to read and to learn. And to experiment. And to hand-code my HTML/CSS. And to “fight” with Netscape 4.79, IE5, the wrong box model of IE and the terrible CSS support (or, more exactly, un-support) of the old browsers…

    It was a hard beginning, but soon I discovered that writing code, thinking in code, actually gave me much more creative freedom! (I do not know why some designers think that to know and understand code is actually a limitation?)

    Not only this. My code was more robust than the code that Dreamweaver/FrontPage produced. It was lighter/shorter. It was much better readable by humans. It was easier to edit/change things at any moment. The code was also simpler and easier to troubleshoot.

    I “dropped tables out of the window”, as well as any thought for using any kind of “WYSIWYG mode” and never looked back. I am now happy to say that with great teachers such as Jeffrey Z, Dan C, Doug B and Eric M, whose blogs I was reading daily, I am now able to handcode HTML/CSS much better than any machine! :-)

    I still hear from time to time predictions that handcrafted HTML/CSS will soon be not needed anymore and that computers will start producing web designs (and html/css) much better and faster than we humans can. Perhaps this will happen one day.

    But today, great designers/coders are still as needed as great writers or photographers. Design is both craftsmanship and art, IMHO. Web design is mostly code, and to create/implement a great design, you usually need a great designer (coder).

    Tools help us (Dreamweaver, Coda, etc.), but we invent, edit and test the code, line by line. That’s how a great web design is born. There’s no shortcut, for now.

    Finally, one more remark: I am impressed what is done today with CSS3 — take the iPhone CSS3 implementation, for example. But I think that these are just “pushing the edge” experiments. Yes, you can re-create Mona Lisa with Microsoft Paint, but that’s not exactly the right tool for the job. With CSS3, you can now create icons or even more complext illustrations, but again, perhaps this is not the right tool for the job. It’s interesting to experiment in this direction, but great tools such as Fireworks/Photoshop will be still needed, years from now… CSS3 won’t replace them, at least for now…

    Jeffrey, a great post and even better discussion! I have read every single comment on this page and I’d like to say that you have one of the best audiences I came across lately in a designer’s blog! :)))

  80. Of course, there can be no design program with the intelligence to output semantic code – for now. We sound like typesetters when we speak in absolutes like this, though. Future intelligent systems could ostensibly interpret visual language, much the way that cameras interpret the visual language of a face and adjust focus accordingly.

    How long is it before our design programs can suggest semantic systems that we adjust? (human still at the helm)

    How long is it before reading systems (our devices) interpret the visual structure of anything – semantic or rasterized – and can output that structure in whatever manifestation is most useful to the user?

    Think big!

  81. I learned typesetting in the late 1970s and early 80s on dedicated phototypesetting devices like the Mergenthaler Linoterm and CRTronic, machines which predated personal computers, but whose formatting syntax bore a strong resemblance to what eventually became HTML.

    As good as I got at using these machines’ coordinate systems to format entire pages — and I got pretty good at it — I couldn’t wait to get away from them. Yes, some of these dedicated systems featured a good number of clever macros which would automate repetitive processes. But describing a page mathematically felt like a nerd’s parlor trick. It was not an interesting or fulfilling way for me to design anything. I wanted to paint the picture, not grind my own pigments or weave canvas.

    Adobe Illustrator on the Mac was a revelation. Then I saw a demo of QuarkXpress. Some time later, InDesign came along. The tools I’d been unknowingly waiting for were finally made available to me, and over time grew more stable and capable. Engineers had finally figured out a way to automate the process of writing PostScript code to place objects on a page without too much inefficiency. Over time, they added features which made the job of designing easier. I no longer needed to know how to assemble the engine in order to drive the car.

    I’m in the process of making the transition from print to web design. HTML and CSS are still obstacles for me to overcome, possibly because I haven’t yet found good teaching metaphors to internalize them better. But I know how I’d rather design a web page — or any page — than by describing it mathematically. I find it interesting that CSS constitutes — metaphorically — a good number of clever macros which automate what would otherwise be repetitive processes.

    Pardon my ignorant simplification, but history does occasionally repeat itself. Software grows more intelligent over time. It will very likely incorporate not just the automation of styling, but more of what you folks describe as the semantics of coding.

    I don’t want Photoshop 2000. I want InDesign CS7 or 8. Am I being unreasonable?

  82. even the brilliant hypothetical one I’ve just sketched, would need to be tweakable by those whose craft exceeded what the tool could deliver (and those tweaks would need to work their way back into the comp, which might be the most magical and least attainable part of this whole fantasy product).

    This is why I originally mentioned the Flash Catalyst / Flash Builder workflow because that’s exactly the concept, and it works. If Adobe could do the same for HTML/CSS then your fantasy would be a reality.

    I think the ironic thing here though, is that what you seem to crave is probably something that InDesign is most suited for. It already has the structure. It already has the logic. It’s completely extensible. You already basically have the box model, intelligent styles (nested styles, next style, etc), and probably the most powerful formatting tools that fit so perfectly into web workflows in the form of GREP styles, conditional text, and variables. Teach InDesign to do fluid layouts and understand a cascade and you pretty much have it all. You already have support for native PSD, so it would be easy for designers to make the transition.

    If Adobe would build a developer tool that would, as you say, allow one to modify the comp from the other direction, you’d be set.

    @Laura All the power to you. Most of the designers I know aren’t able to use code as a paintbrush. They prefer to experiment with visual tools.

  83. Jeffrey, as some have alluded in the comments (both here and elsewhere), I wonder if you’re conflating art and technique a bit too much. You lost me in the end when you say, “the very assumption that a such thing is possible suggests a lack of understanding of the professionalism, wisdom, and experience required to create good HTML, CSS, and JavaScript.” This sounds too much like someone too much in love of his place in life. The “creation” of HTML, CSS, and JS is really no different than the “creation” of the construction elements of a Gehry building. The way these elements are built, arranged, and manipulated will change and improve over time, but the practice of architecting and web designing is still in the mind of the artist – not in his tools.

  84. Photoshop is not a “native” tool for web designers. jQuery + HTML5 + CSS3 may replace or create something more useful. I am working on something like this at
    There are really few tools for web design out there, we should build something new suitable for our work. We do have the tools now.

  85. Moreover, authoring good HTML and CSS is an art, just as authoring good poetry or designing beautiful comps in Photoshop is an art. Expecting Photoshop to write the kind of markup and CSS you and I write at our best is like challenging TextMate to convert semantic HTML into a visually appropriate and aesthetically pleasing layout. Certain kinds of human creativity and expertise cannot be reproduced by machines.

    This argument is specious. Is it not tantamount to stating that expecting photoshop to create good creative images will never replace the paintbrush on canvas?

    Creativity and expertise cannot be reproduced by machines. This is not to say that human creativity cannot be rendered by a machine. Like any tool, there will be limitations in scope and in application. Working against such limitations is the business of the creative artist.

  86. This argument is specious. Is it not tantamount to stating that expecting photoshop to create good creative images will never replace the paintbrush on canvas?

    No, it’s saying Photoshop won’t create a beautiful composition for you—creating a beautiful composition requires talent, skill, and expertise. It’s saying a paint and canvas won’t paint for you. It’s saying any HTML/CSS tool created in the next decade can’t code like a good coder can code.

  87. This really is the thread that wouldn’t die!

    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.

  88. Drat I was hoping that iPhone CSS3 experiment would display properly in FF4b1 oh well.

    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.

  89. @Nathan:

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

  90. Like Michael said, DW is just a tool, and if you haven’t used CS5, then you *may* think it sucks, but you’d be wrong. I can write CSS in that tool faster than I can write it by hand thanks to code-hints that help me write it without my typing getting in the way. I don’t let Design view get in my way other than use split view so I can see what I am typing is doing.

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

  91. First, according to Wikipedia: “Art is the process or product of deliberately arranging elements in a way to affect the senses or emotions”. So if you want to cry after looking at your HTML, that has nothing to do with arts: there’s something wrong about you…

    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…

  92. WYSIWYG apps did their share of evil. But nowadays there’s a better understanding of semantics and web standards, so maybe it wouldn’t be that hard to imagine some kind of “What You Design Is What You Mean” type of application. There’s is no tool like that in the market as of yet. But would it be that hard to create? I mean, some kind of Fireworks where I can decide “this rectangle is a div called etc etc” The text within that div has a 10 px margin all around, and rounded corners. The main text size in this document should be 13 px etc etc. Apply all the rules we already know about floats etc. Would that be so hard in 2010? Get my point?

  93. I use Espresso and CSS Edit, however I have seen flux

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

  94. I find myself, surprisingly enough, in agreement with Jeffrey Zeldman. That has not happened for years …

    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.

  95. I agree wholeheartedly with the point that a tool could never replicate the decisions made by a human when converting a layout to semantic HTML markup because of the intricacies of decisions that need to be made by said human.

    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?

  96. Yeah, I totally agree with what Zeldman is sayin in this post. The main problem with such thinking (as far as I’m concerned) is how it effects client’s conceptions of how the web works. Flash has done a lot of damage in this perceptual area in that it does provide such an authoring environment but outside of standards based systems and techniques. That of course is an ole battle in the web design world so I won’t get too into it here, except to say that as professionals everyone really needs to make sure they push the idea of the ‘craft’. In other words, make sure that clients (and others, say managment) get the idea that what we do is indeed a craft, and that there isn’t going to be (anytime soon) a simple one-size fits all tool out there that is the killer-app equivalent of say Photoshop.

    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!

  97. This is just programmers versus designers rearing its ugly head again. You’re jealous because we designers can make nice pages and want to bog us down in code all over again.

    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.

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

  99. Sorry I’m late to this conversation, but was just checking out your post here after JSM launched a similar write-up this morning.

    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.

Comments are closed.