As we’ve worked on Easel, an in-browser web design tool, we’ve spent a great deal of time thinking about HTML and CSS to understand exactly what people mean when they talk about good markup.
The Ideal Markup
When you ask a web developer what makes good markup, you’ll probably get some mix of the following: readable code, separation of content and style, semantically meaningful markup, cross-browser/device support, graceful degradation, standards compliance, and performance.
Each of these aspects of a markup are important, however, they can’t all be the highest priority. Projects come with their own unique set of requirements, and developers have personal preferences (we can’t even agree on ids or classes). The best developers understand these constraints and deliver markup that balances these factors in an ideal manner.
That’s the craft behind web development.
The myth is that there is a tool which can achieve this balance for all projects. It’s why so many developers are unsatisfied by the markup generated by their tools.
Developers want a tool that is both general and specific. General in that it works for all projects, but specific in that it will understand each project’s context and deliver ideally suited markup. However, ideal markup is a product of the project context and personal preference, which simply can’t be fully replicated by a tool.
The Way Forward
If we accept that our tools can’t create the perfect markup, we should expect our tools to export in ways that we can apply context to. They should help us with the parts that they know best but still allow us the space to apply our judgement.
We’ve built Easel to be that kind of tool by using selective export. It eliminates mundane tasks like: determining the markup of a component, the syntax of a drop shadow, or the exact font size of a specific heading. But it won’t make judgement calls on tradeoffs for the developer (it can’t). By helping where it can and getting out of the way when it can’t, Easel allows you to focus on your craft rather than the mechanics.
Easel’s strength is that it gives teams the freedom to visually explore natively with the web, allowing non-technical members to prototype without knowing how to code. When the time comes to implement, the design choices are preserved as HTML and CSS, instead of being held hostage in an image.
Developers still need to use their judgement about the general structure of their markup and how it fits within their project, but that’s what we signed up to do.
We use Easel to build Easel. Every feature we make starts off as as an Easel document, and after several rounds of iteration and collaboration either Ben or I will implement it.
We start by opening the design document and mentally breaking it down into individual components. Inevitably, some of these components have already been built, and we can just reference them. Others are entirely new, which means we can highlight, copy the Easel generated markup, and use it as the starting point in our editors. We still have to decide which template to place it in and what style selectors to use, but we don’t have to worry about specifying all of the visual properties and much of the HTML, as we’ve taken those from Easel.
Neither Ben nor I miss the days when we had to use a color dropper to make things. That’s what makes us so excited to be working on Easel to streamline how web development happens. If you haven’t tried Easel already, sign up today.