Jeff Croft

I’m a product designer in Seattle, WA. I lead Design at a stealthy startup. I recently worked at Simply Measured, and previously co-founded Lendle.

Some of my past clients include Facebook, Microsoft, Yahoo!, and the University of Washington.

I’ve authored two books on web and interactive design and spoken at dozens of conferences around the world.

But seriously, who gives a shit?

Blog entry // 09.26.2007 // 2:06 AM // 75 Comments

The new layers of web development

Consider this post a feeler of sorts. There’s a topic I find interesting, but I can’t say I’ve yet fully fleshed out my thoughts on the matter. I’m hoping to generate some discussion here. If other people are also interested, and if a discussion leads me to the train of thought I think it will, then I may put these thoughts together and present them at Refresh Seattle on October 30th.

With that out of the way: Let’s talk about the so-called “layers” of web development. Web Standards types generally talk about three layers: structure or content, presentation, and behavior. Loosely, these three layers translate to (X)HTML markup, CSS, and Javascript, respectively. I’m concerned that this view is short-sighted, and leaves out key pieces of modern web development.

Web Standards advocates tend to only talk about the front end of web sites and app. They tend to completely ignore the back-end. This bothers me. So I want to reevaluate best practices with regard to these “layers,” viewing things more holistically — sort of combining the MVC-ish model back-end web development is heading towards and the front-end oriented layers Web Standards folks talk about. I will quickly outline what I believe to be the real way cutting edge web sites are put together, and then I hope you’ll discuss and tell me where I’m wrong.

Structured content layer (Database/Model)

In the traditional view of things, this means (X)HTML markup. However, real websites don’t store their content in (X)HTML. They usually store their content in relational database. Or sometimes they don’t store their content at all, and rather they gather it via REST APIs in structured, database-like formats such as XML and JSON. Ideally, these databases are semantically designed with fields that properly define the data stored within. Also ideally, the data in these databases contain little to no (X)HTML markup, as this would serve to inhibit the data’s ability to be used in other contexts (our web is not simply X(H)TML anymore. We may want to use this data in plain text for e-mails, in PDFs, in SWF files, and so forth.).

Business logic layer (Controller)

Real websites have some sort of business logic layer. This is generally server-side processing, which can be done in just about any programming language under the sun (Python, Ruby, PHP, Java, and .net are some common ones). Generally, this layer will interact with the data in the structured content layer, perhaps performing tasks like user authentication, validation, and data parsing and processing. Ideally, this layer is fully separated from both the structured content layer and the rendered output layer (next).

Rendered output layer (View/Template)

After the business logic layer has done it’s thing, real websites will want to display a rendered view. Often, this means (X)HTML markup. However, it could also mean PDFs, SWFs, plain text, and even RSS, XML or JSON. In most modern systems, this layer is handed by some kind of templating. Whether it’s a dedicated template language (a la Django Templates, MoveableType templates, or Smarty), a full fledged programming language (a la Ruby in Rails or PHP in Wordpress templates), or something else entirely (XSLTm for example), the goal here should be that only presentational logic is used. Business logic should never be mixed with (X)HTML (or the presentational format of your choice). All programatic elements should be used simply to present the data in the appropriate manner — not to process or otherwise modify the data, and certainly not to validate it, save it, or retrieve it from a database.

Style layer

Generally handled by CSS, the style layer adds visual design to the rendered output. This is generally well-understood by the Web Standards folks that tend to read this blog, so I won’t go too deep into it. It’s important to note, however, that CSS is not the only technology at play here. In Flash applications, the style layer will be part of the same SWF that contains the rendered output layer. In this circumstance, it’s important to keep the two layers as separate as possible within the Flash (FLA) environment — the fact that they’re ultimately rendered as a package is a non-issue.

Behavior layer

Generally handled by Javascript and/or Actionscript, the behavior layer runs client-side, and handles user interactions, sometimes passing data back and forth to the business logic layer, and sometimes not. In short, things that are clicked on, dragged, typed, and pressed are handed by this layer.

Here comes the rub

So the piece of this that I expect to be most contentious (if The myth of content and presentation separation is any indication) is the idea that the content layer is fully separate from the rendered output (i.e. markup) layer. In short, I’m suggesting that the (X)HTML templates used for a website in today’s modern world are much more closely related to presentation than they are to content. Why? Because (X)HTML templates are only one of many ways the content of a modern website is presented. It may also be presented as RSS. Or as a PDF. Or within a Flash context. Or sent as an e-mail. Or exposed as JSON in a REST API.

But, you say: (X)HTML markup gives it structure! I say: Not really. The structured content layer (i.e. database) layer gives it structure. That structure may be replicated in your (X)HTML templates or RSS feed, but the database is the place where the structure begins.

What’s different about the content as it appears in the database and as it appears in (X)HTML? Well, mostly a bunch of div elements and id andclass` attributes. What are these for? If you’re being honest with yourself, you’ll admit they’re mostly for hanging styles and behaviors on. In other words, (X)HTML templates are pretty much part of the presentation layer.

It’s okay. Just accept it. You’ll feel better in the morning. :)

Please do discuss.

Comments

  1. 001 // Joshua // 09.26.2007 // 3:12 AM

    All sounds good, I’d certainly come hear the presentation if you do it. BTW, turn on channel 5… Nick tells me there’s sharks on right now.

  2. 002 // Gabe da Silveira // 09.26.2007 // 3:42 AM

    This makes sense for the most part, and I think it’s pretty intuitive to developers. A document is one thing, but when you’re talking about an application, XHTML is woefully inadequate at providing semantic structure. Even a custom XML dialect is difficult to manipulate and extract information from compared to a relational database.

    Another thought I have (and this comes from my Rails experience) is that the controller and view can not be easily separated. The model stands alone because it can be used completely independently of the web. However the controller is specifically there to set up the environment for the view. The controller and view are nothing without each other, so some level of dependency is natural.

    At the same time, the controller should be minimal. I would characterize it as the navigation layer more so than “business logic layer”. A lot of business logic is inherent to the data itself, and the controller should not be concerned with that. Rather the controller is only in charge of the actual web interaction, which tends to be minimal (logging in, posting a comment, viewing a document, etc). It decides what data is needed from the model and provides it to the view of its choice. It’s essentially just glue between HTTP, the data model, and the view. In a way its fundamental task is the most complex, therefore it should be kept as simple as possible.

    On another tangent, the project I’m currently working on involves user-customized interfaces, which raises serious issues of maintainability around how the templates are structured. When you’re building things on the server, a lot of page-based structure goes away, and you have a lot more freedom in how to structure the final output. In this case sometimes keeping markup, presentation and behavior separate actually hinders maintainability because you are dealing with small chunks that have components of all three. With large page-oriented files the trifecta is the only reasonable way to split up the project, but if you have 30 small components on the server that go into a single page, maintainability has more dimensions to consider. Putting javascript inline may be far more maintainable than a huge, slow file that ends up with unnecessary code for many situations, or a thousand tiny files that are conditionally included. The same is true with CSS to a lesser degree.

  3. 003 // Stefan // 09.26.2007 // 3:44 AM

    Hm, I can agree partly. Part of the structure begins in the database, but in my point of view the real strucure comes in Structur Layer (may this be XHTML, PDF, RSS, …). I think „structure” is the templates and markup.

    This article on Particletree (4 Layers of Separation) may be of interest.

  4. 004 // Guillaume // 09.26.2007 // 4:06 AM

    It is presentation, but not looks. HTML presents, or rather “serves” content : both to humans and applications.

  5. 005 // Ludwig Wendzich // 09.26.2007 // 5:14 AM

    Amen.

    Everything you said is completely correct in my opinion, standardistas are taking things too far these days, yes we want clean code, yes we want semantic code but we also need to earn our bread, we need to be pragmatic and if we need to add in some “span-14”s to maximize profits then so be it.

    Content is stored in the database, presented in HTML (or PDF or Flash) and styled with CSS (if it’s presented with HTML.)

    It’s as simple as that.

  6. 006 // Matt Wilcox // 09.26.2007 // 6:10 AM

    I mostly agree with your assessment. At work we use a work-flow involving XML to store all of the data, XSLT running on a .net engine to transform the data in the XML into XHTML, and from there it’s the usual CSS/JS stuff.

    Practically, we need to insert HTML into the XML fields in places where those fields are user controlled through our custom CMS - which is a pain in terms of theoretical separation, but the only other approach would be to create an XSLT CMS engine that re-factored (potentially complex) user input into meaningful XML and then another engine that converted that XML into XHTML all on its own. No doubt that’s do-able, but it’d be prohibitively expensive to develop, and when the end output of that data is 99.99% of the time HTML - there’s not a valid cost/benefit ratio that allows us to do ‘the nice/right thing’.

    XML (or your database of choice) is the content layer, XHTML should perhaps be termed the ‘context’ layer - because that is really what it is and what it does. It provides semantic context for the information it contains - but the content itself could, as you say, be leveraged in any number of ways and any number of different contexts. I don’t agree that XHTML is part of the presentation layer - I think it straddles the content and presentation functions. It’s only when you’ve given your content good semantic definition that you can give it meaningful presentation. XHTML is the glue that performs that task, it’s the semantic ‘dictionary’ that contextualises the data within in order to give proper meaning and allow good understanding. Styling has to be done after the contextualisation, no matter whether that’s via XHTML, flash, PDF, or some other contextualisation process. That is a consequence of the information stack, not a designed role of it. It’s just not possible to style raw data because if it would remain raw data and thus meaningless - there has to be the context layer first.

  7. 007 // Kevin Teague // 09.26.2007 // 6:15 AM

    I wrote a response to your post, but I kinda went on for rather a bit and your system said, “Errors: ensure your text is less than 3,000 characters.” So I posted my comments as my own blog posting, Oh No, it’s MVC!.

  8. 008 // Nate Klaiber // 09.26.2007 // 7:48 AM

    I think they both provide structure. I agree with you that the real structure starts with the database schema. There are many designers that simply don’t get that, and some of they don’t really need to. Having a clean, normalized, and secure database is key to the content on the front end. The other problem is everyone tries to force things to be something they aren’t (I am currently guilty of this…for about another monty). Trying to use Wordpress as a CMS or a shopping cart - to me, your data model is flawed at the core.

    HTML still gives structure because it provides you with the proper placeholders to present your data. Headers, List Items, Paragraphs, etc. So I still consider it more structural than presentational in that regard. No matter what you spit out, XML, JSON, etc - that is all coming from the database layer at the core, and each of those still provides you with the proper placeholders for your data.

    Even though they provide the placeholders for your data - that doesn’t mean they know anything (or need to know anything) about the presentation.

    I like this thought process….

  9. 009 // pauldwaite // 09.26.2007 // 8:27 AM

    the database is the place where the structure begins

    Not necessarily. When you wrote this blog post, did you create 13 records in the paragraph table of your database? Or did you create one record in the blog entry table, containing 13 paragraphs described HTML, Markdown or similar?

    You’re quite right that, for lots of web sites, humans define the meaning of data when designing a database schema, or picking what data to ask for from an API.

    But as you say, that meaning is, for decent web sites, then replicated in HTML as far as HTML allows (and, one would hope, likewise in PDF, Flash, e-mail and all other outputs). And as far as users are concerned (be they human or machine), that replication of the meaning is the only one they ever get to see. So it had better be good.

    ideally, the data in these databases contain little to no (X)HTML markup, as this would serve to inhibit the data’s ability to be used in other contexts

    Also, not necessarily. If all the meaning in your data is expressible in HTML, I’d say it’s a pretty decent storage format. Given its fame, there are more likely to be tools to convert it to other formats. Failing that, you can give your raw HTML data to someone else, and they can look up what all the tags mean, rather than guessing about your custom XML format or database schema.

  10. 010 // Baxter // 09.26.2007 // 8:45 AM

    But Jeff, the structure of the data and the structure of the page will probably be wholly different. The homebuilding analogy I’d use is that the database is your warehouse or lumberyard. It’s got everything you need, stored away neatly, organized and counted. Your controller would be the job order: “Lets get 200 2x4s, precut to X length, along with the associated brackets we’re going to need.” And the page template is the framework of the house, where you put it all together. While both the database and the job site are definitely structured and organized, they’re probably not the using the same organization.

  11. 011 // Fredrik // 09.26.2007 // 8:49 AM

    I wrote a response to your post, but I kinda went on for rather a bit

    And I started writing a similar response (along the “web folks just don’t get MVC” line) but luckily went back to see if someone else had already done that before I got very far. Thanks for writing it for me ;-)

  12. 012 // Jason Porritt // 09.26.2007 // 8:57 AM

    Excellent post, but I still would call (X)HTML content. The only difference between the content as HTML and the content in a database is the format. Both formats provide structures that add meaning to the raw data, and both can be displayed using the proper browser application (Firefox vs. SQLDeveloper, perhaps?).

    Additionally, the data source (structured content layer, as you called it) for a mashup website is often HTML, RSS, or some other published API. Each of those is a form of structured content which can be parsed and passed through business logic or controller and rendered in another format. If you don’t have access to the original data, the HTML is the origin of the data’s structure for your purposes.

    I agree the style layer (CSS in most cases) is not content, and I think most everyone would agree with that. So why is that? Because the style layer is not typically useful when using the HTML layer as your data source. It tells the browser what colors, fonts, and position elements should have, not what the data is.

  13. 013 // Brad Siegfreid // 09.26.2007 // 9:19 AM

    This is definitely something I’ve been trying to resolve for my own projects but I’ll save the long, rambling response and give you the simple mental model that I’ve been using lately.

    A web application can deliver either a document representation of a model or it can deliver a client application that can then turn around and use that model in a more dynamic fashion.

    When I’m working on something static the standard thinking of structure and styling work well. The markup should have some semantic value, even if the only purpose is to keep things clear for the designer. I have yet to use semantic markup as a consumer but I still want to provide well structured documents just in case. It certainly doesn’t slow me down to provide it.

    When the application is delivering a client application or a document that includes a mini-client then I begin to view the HTML as a user interface framework. The markup begins to lose its semantic value as it provides structure for the application code. The more it becomes a client the less I feel the need to keep the old document concept in mind.

    To align this to your thoughts a bit more I do look at applications from the server-side more than from the web interface side. The only part of the MVC that changes is whether the view is document or client. If the view is a client then it follows its own MVC pattern if the client complicated enough. If not then I keep things as simple as possible and just add enough behavior to the document view.

    That’s the direction I’ve been going recently. It can still get messy.

  14. 014 // Eddie Welker // 09.26.2007 // 9:56 AM

    I agree with the layers that you have presented. The backend is often neglected (though, it’s the other way around at my job), but I believe that has more to do with the nature of web jobs and the training of employees… large projects often have people working on either the backend or the frontend. Rarely does one person work on both sides.

    The problem with your argument that (X)HTML is more closely associated with the presentation layer than the structural layer, is that the answer simply isn’t black and white, it’s a perfect shade of gray. Without a doubt, HTML both provides the fine-grained structure that databases don’t handle. That HTML is then interpreted by two audiences: humans, where the presentational aspect of HTML is of primary importance, or computers, where the structural aspect of the HTML is most important.

    [My personal feeling at this point is that because computers can only use the structure, while humans can make use of both the structural and presentational aspects, that makes it 2 votes for structure to one to presentation. Others may feel differently.]

    Stating that just because HTML is only one of a variety of ways to present the data, doesn’t give a relative weight to the importance of it’s presentational side, it just affirms that HTML has a presentational aspect. I would state that HTML, RSS, PDF, and other forms also contain a structure to them, and again, that doesn’t give more weight to the structural side, it just affirms that there is one.

    Unless the web’s evolution results in a shift, I think that it’s clear that HTML straddles both structure and presentation. To what degree depends on whether the glass is half empty or half full.

  15. 015 // Joe Dolson // 09.26.2007 // 10 AM

    It seems to me that the standard (X)HTML/CSS/JS division of the model is more a model of the user interface alone than of the entire web application. The idea is that those three facets (structure, presentation, and behavior) are essentially universal across sites (everything has a user interface), whereas business logic and foundational data structure really only apply to some projects.

    I’m also inclined to agree with some of the commenters above that the (X)HTML output is still structure, though at a different level than that data. Data is the foundation, business logic the frame, XHTML is the walls and ceiling. It may not be the ONLY structure presented, but it’s still structural in that it defines a particular format to the data.

    I do think that it’s a mistake to attempt to divide too strictly between structure and presentation. Although design choices in CSS should be kept thoroughly separate from the XHTML structure of the page, it’s naive to believe that the separated XHTML has no presentational value on its own.

  16. 016 // David Hemphill // 09.26.2007 // 10:14 AM

    There you go, rocking the boat with your dang logic.

    Jokes aside, your right on that Web Standard types tend to forget about the back-end stuff when talking about separation. I don’t know why, maybe it’s because they’re not as involved with the back-end development as they are with the front-end. It seems to me that if you’re just talking about front-end development then their definition of those terms fit well, but in the whole scope of a modern website, yours fits better.

  17. 017 // Stephen Van Dahm // 09.26.2007 // 10:45 AM

    HTML is different from JSON and Flash because it gets cached by Google and the Wayback Machine. Since we don’t know how long those resources are going to be around or how people are going to try to read it ten or twenty years from now, I think it’s still worthwhile to have as much structure and semantic correctness as possible. I recognize that this isn’t always practical; we all have deadlines, and the W3C standards kind of suck. It’s an ideal worth working for, though, even if it’s not always attainable.

    With JSON and RSS, it’s a bit different because that stuff just gets parsed by a machine and discarded.

  18. 018 // Jeff Croft // 09.26.2007 // 11:04 AM

    XML (or your database of choice) is the content layer, XHTML should perhaps be termed the ‘context’ layer - because that is really what it is and what it does.

    Ohhh, context layer — I like that!

    @Baxter: Interesting take and good analogy!

    The problem with your argument that (X)HTML is more closely associated with the presentation layer than the structural layer, is that the answer simply isn’t black and white, it’s a perfect shade of gray…Unless the web’s evolution results in a shift, I think that it’s clear that HTML straddles both structure and presentation. To what degree depends on whether the glass is half empty or half full.

    I do agree with this completely. I struggled with a way to describe it in the post, because you’re right — it’s just not an absolutely clear-cut thing.

    It seems to me that the standard (X)HTML/CSS/JS division of the model is more a model of the user interface alone than of the entire web application.

    It is, and I understand that. But my point is that ignoring the rest of the web application is shortsighted, and leads to confusion (like people thinking that (X)HTML is where structure begins).

    …whereas business logic and foundational data structure really only apply to some projects.

    I guess there are still a handful of static sites out there that have no business logic or foundational data structure, but they’re very rare these days — and they’re not the ones I’m talking about. :)

    I definitely generally agree with your thoughts, Joe.

    I think it’s still worthwhile to have as much structure and semantic correctness as possible.

    I think so, too. In the ideal situation, you (X)HTML does accurately describe the structure of your data. But, usually the (X)HTML layer is not the One True Source™ for that structure — your model (database) is. (X)HTML basically replicates that structure, or perhaps transforms it slightly from the database structure for appropriateness in the (X)HTML context.

    With JSON and RSS, it’s a bit different because that stuff just gets parsed by a machine and discarded.

    I see your point, but just for the record: RSS is cached by Google. And, I parse and cache JSON data in my database every day. So, these formats are not necessarily discarded.

    This is a really great discussion, guys. Nothing like the feeling of waking up in the morning and seeing I’ve helped get people thinking about this stuff. I’m already seeing ways I can tweak what I wrote to be more accurate and useful. This is exciting — thanks, guys! :)

  19. 019 // John B // 09.26.2007 // 12:28 PM

    Great article, and discussion! It took a while to get through the comments - they’re not the skimming variety.

    I believe you’ve pointed out something very true - that the whole process is rarely looked at, and we need to think of more than the traditional 3 layers, (whether they’re 3 front-end layers or 3 back-end layers).

    I think, though, that pauldwaite and Eddie Welker are right. While a lot of (X)HTML has to do with presentation the minute, but still important, elements of structure are contained in (X)HTML, (although XML or something else could probably be used for this as well). Pauldwaite said it well when he asked:

    When you wrote this blog post, did you create 13 records in the paragraph table of your database? Or did you create one record in the blog entry table, containing 13 paragraphs described HTML, Markdown or similar?

    But it goes deeper than paragraphs. It includes minor headers and pretty much anything inline in the paragraph. This is something I have tried to deal with in some of my own projects, and at times I have simply ended up storing HTML in a database. How else do you indicate that a word in the middle of a paragraph is written in another language? In print you would print that word in italics. In HTML you can use a span with a lang attribute. In a database, which stores plain text - a lot of information can be lost.

    The need to store inline information, (languages, inline links, and the like), almost adds another layer at the beginning: Call it Content Structure, (different from Structured Content - confusing I know), or something. I know that technically it’s still content, but we need some sort markup or syntax to retain that valuable information.

  20. 020 // Wilson Miner // 09.26.2007 // 12:34 PM

    The thing I like conceptually about extending the web development “stack” all the way back to the database layer is that it takes the pressure off of the markup to be the foundation of structure.

    HTML is an extremely weak carrier of structure. The pieces just aren’t there. And the few elements that smell like structure get overused and overextended beyond reason (remember when everything looked like it should be marked up with a definition list?). Microformats are a great hack for injecting some structure, but the fact that they exist and we’re so hungry for them just exposes the weakness of the underlying structure. HTML5 is a nice gesture towards structure, but it’s more like a gasoline hybrid than hydrogen - and Priuses still gets shitty gas mileage on the highway.

    Placed in the context of the rest of the stack as you described it gives the markup a role a little better suited to the tools at hand. Once the structure is defined, HTML provides a decent shorthand to describe structure for the purpose of presentation. That’s where the markup is inextricably tied to the presentation layer. Practically, you don’t use HTML to mark up content that isn’t going to be presented. Obviously, it’s good practice to apply as much consistent and media-agnostic structure as possible so the same content can be delivered through different devices - whether it’s mobile browsers, scrapers or assistive devices - but if you’re marking up content that won’t have a presentation layer at all, you’re not likely to be using HTML.

    As has been made so painfully clear over the years, HTML isn’t built for purity. So we might as well stop saddling it with those expectations. When the “pure” structure is stored somewhere else, the markup is just a translation. Use the best-available language to capture the essence of the structure in a medium-appropriate presentation. And if some of the subtler semantic nuances get lost in translation, well that just comes with the territory.

  21. 021 // Gabe da Silveira // 09.26.2007 // 2:14 PM

    Wilson hit the nail on the head here. HTML is structure for presentational purposes. The defined elements are all basic building blocks of generic documents. Sure headings and paragraphs and lists have some abstract meaning, but primarily they exist as presentational aids.

    The reason for the web’s success is the simplicity of HTML—it does just enough to present documents well in a variety of contexts. But it’s woefully inadequate as a data model. If you are a front-end person and you are trying to squeeze maximum semantic load into your HTML, step back a minute and realize that data modeling is a 50-year-old endeavour which HTML was in no way ever meant to address.

    By all means, get your documents set up for easy presentation across different platforms and aggregators such as search engines. But if you want real semantics there’s no substitute for a real data model.

  22. 022 // Jeff Croft // 09.26.2007 // 3:08 PM

    Once again, Wilson has up come up in here and show everyone else up (myself included) with his crazy, sense-making explanations of things.

    I couldnt agree more, man. Well-said.

  23. 023 // Kev Mears // 09.27.2007 // 8:07 AM

    Maybe a facile way of deciding whether something is the context layer or the content layer, is to ask whether you’d be happy for the marketing department to write it.

    If yes, then it’s probably content.

    If you have a hairy fit at what they’ve written, then it’s probably context!

  24. 024 // Peter Quinsey // 09.27.2007 // 10:17 AM

    Jeff, it’s true that XHTML looks pretty pathetic as a structural platform when compared against the rest of your server-side process. But that server-side process produces a web page—and as far as the web is concerned, that page has nothing to do with your server-side process. It’s independent, and needs its own structural platform.

    The complete response got a little long for the text box.

  25. 025 // Peter Quinsey // 09.27.2007 // 10:21 AM

    I mean, the complete response. So much for reading instructions.

  26. 026 // pauldwaite // 09.27.2007 // 10:33 AM

    Web Standard types tend to forget about the back-end stuff when talking about separation. I don’t know why, maybe it’s because they’re not as involved with the back-end development as they are with the front-end.

    I think it’s because the Web Standards movement is focused on client-side languages, as that’s the stuff that needed standardising. At the risk of being an offhand historian, the Web Standards movement got going because browsers weren’t interpreting HTML, CSS and JavaScript in the same way. So it focused on making browser support of those languages consistent, and then on good practice in writing those languages. It wasn’t fussed about the back end, except in so far as it affects the front end.

    headings and paragraphs and lists have some abstract meaning, but primarily they exist as presentational aids

    I disagree here. Look at Jeff’s “About the author” section below. It consists of three paragraphs. That’s not a presentation decision. As per Mac OS X’s Dictionary, a paragraph is “a distinct section of a piece of writing, usually dealing with a single theme”. That’s abstract meaning. The presentation part would be “indicated by a new line, indentation, or numbering”, and the HTML spec doesn’t say anything about that.

    I entirely agree with the general point (if I understand it right): most data modeling, and thus most of the meaning in your web app, will probably go on at the database level. But I still think there’s a valuable distinction between communicating the meaning of data (HTML’s job), and deciding what the data looks/sounds like (CSS’s job). Having commonly understood standards for the former genuinely makes development easier.

  27. 027 // Andrew // 09.27.2007 // 2:52 PM

    I would say that the HTML, in combination with the CSS and the client side script is the interaction layer.

    Part of interaction means presentation; therefore, it is possible to divide up the interaction layer into structure, presentation, and behaviour, but on their own they don’t form a layer in their own right.

  28. 028 // John K. // 09.29.2007 // 8:05 PM

    Move the business logic into the database as much as possible, and you’ll be happier (once you know SQL).

    Don’t store it as XML unless it’s a “document”. Store it plain old relational database style.

    Render the data in two phaes. First, transform from the database into objects (and sub-objects). Second, emit the objects via a template. This way, you can debug the objects with generic tools (aka, the print statement).

    Also, if you’re really into separating logic… well, there’s now three layers between the display and the business logic. SQL and HTML shall never share space in a file again.

    If you want to be a real code-thug about it, just limit your templating code to “? :” “print” “foo.bar()” and “while”. That removes the possibility of introducing any logic at all into the display layer.

    Also, we should really get over the whole MVC fad. Look up the Morphic design. Our clients are powerful enough (and the network is slow enough) that we’re producing things more like Morphs than views.

  29. 029 // Jeff Croft // 09.29.2007 // 8:40 PM

    Move the business logic into the database as much as possible, and you’ll be happier (once you know SQL).

    I’m not a SQL expert by any means, but I don’t believe SQL is capable of much of the business logic a typical web app includes. For example, can SQL:

    • Send e-mails?
    • Validate user input (for example, ensure an e-mail address is valid)?
    • Return an HTTP response to the browser?

    Also, we should really get over the whole MVC fad.

    I am not enough of a programmer to know whether we should “get over” MVC or not, but I do know it’s a horrible inaccuracy to call it a “fad.” Fads don’t last 30 years.

  30. 030 // Raina Gustafson // 10.03.2007 // 8:35 PM

    I’m pretty wet behind the ears with everything web, but have become a big fan of Textpattern over the last 6 months. I recently purchased Textpattern Solutions, a book on how to maximize its capabilites, and on page 152, the authors make a similar argument for how Textpattern improves on the structural, behavioral and presentational layers by adding what they call a “fourth dimension”. They go on to describe it as “the melding of content and structure on a very granular, tightly controlled, and completely customizable level… Textpattern adheres to its own semantic architecture… everything revolves around the explicit management of content and structure and then weaving them back together for the visitor’s browser.”

    It’s worth a look for anyone requiring a CMS or blogging platform.

  31. 031 // Jeff Croft // 10.03.2007 // 8:45 PM

    Hey Raina: That book (which I have as well, as it’s co-authored by my buddy Nathan Smith) makes a good point — but I’m not sure the point is exclusive to TextPattern. I’d say any quality CMS does exactly that. TextPattern certainly does, but you can get the sme benefit from other good CMSes, as well. :)

  32. 032 // James Asher // 10.04.2007 // 11:42 PM

    For example, can SQL: Validate user input (for example, ensure an e-mail address is valid)?

    Theoretically, at least with MySQL, it could. MySQL can do reg-ex‘s, so it could do any kind of data validation - at least as far as regular expressions are concerned.

  33. 033 // Jeff Croft // 10.05.2007 // 1:29 AM

    Theoretically, at least with MySQL, it could. MySQL can do reg-ex’s, so it could do any kind of data validation - at least as far as regular expressions are concerned.

    That’s a good point, but I still think it’s too limited for real-world use as the primary means of validation in most web apps. For example, say you have a URL field on an object and you want to verify that the URL exists (by hitting it via http) before saving it — SQL couldn’t do that, right?

  34. 034 // James Asher // 10.05.2007 // 9:22 AM

    It’s certainly not the method you’d want to use for validating email addresses, but I just wanted to note that it could be done.

    As far as I know there is no way to do anything via http directly with SQL, it’s simply not designed for that.

  35. 035 // Joey Tyson // 10.09.2007 // 11:51 PM

    I like the “context layer” idea… I kept feeling as I read the article that there were two concepts of “presentation” running around. (X)HTML is ideally not about presentation in the sense of how the rendered data ultimately appears to the user - that is, the colors and layout defined by the style layer. But (X)HTML is very much about presentation the sense that it presents the content to the user agent in a meaningful way. If an application sends content via XML to a web service, there’s no presentation in the sense of color going on - but the data is being “presented” in a structure that makes sense to the remote service, and XML enables that presentation. Like Wilson said, structure for the purpose of presentation. I don’t know, just thinking out loud…

  36. 036 // Pieter-Jan // 11.22.2007 // 11:11 AM

    @James: there IS a way mate. But it is hard and the server has need some modification. If you want some help dont hesitate to mail me at info [attttt] 2players.nl.

  37. 037 // appliances // 12.31.2007 // 2:07 PM

    Excellent post, well said.

    It’s certainly not the method you’d want to use for validating email addresses, but I just wanted to note that it could be done.”

    I would love to hear more on this as well…

  38. 038 // Manuel Zarate // 12.31.2007 // 3:35 PM

    I agree with most of the information here, but one of the things that we need to always think about is the layer we present to our visitors. Most website today focus too much on selling their idea to the visitor and not to present helpful and useful information that anyone will be able to use right away.

    Most ecommerce stores lack the easy navigational system that is necessary to make their clients be able to find their products fast, usability sometimes is not their main focus, all they want to do is make a sale.

    I am not a web designer expert, but I run a successful toronto seo company and we do deal alot of sites that do not follow the ideas on this post, I wish more and more clients would pay more attention the the different layers you have to build on an ecommerce system in order to make things work as best as possible.

    Thank you for letting me share this information, great post by the way

    Manuel Zarate

  39. 039 // Matt de Wit // 01.14.2008 // 6:27 PM

    how can i get the book Textpattern. Is it also published within the Netherlands? Should I get it to improve my web2.0 mediawiki? Or are there manuals on the internet about this subject (structure/design etc.)

  40. 040 // gowner // 02.23.2008 // 4:28 AM

    I would say that the HTML, in combination with the CSS and the client side script is the interaction layer.

    Part of interaction means presentation; therefore, it is possible to divide up the interaction layer into structure, presentation, and behaviour, but on their own they don’t form a layer in their own right.

  41. 041 // alex de souza // 03.21.2008 // 8:06 AM

    there is 2 site for webmasters. 1) w3.org/ 2) google.com

  42. 042 // css design // 07.15.2008 // 6:23 AM

    css layer examples / properties and layer attributes http://css-lessons.ucoz.com/css-…

  43. 043 // mercedes benz auto // 07.18.2008 // 5:30 PM

    @manuel Zarate: on your comment [I agree with most of the information here, but one of the things that we need to always think about is the layer we present to our visitors. Most website today focus too much on selling their idea to the visitor and not to present helpful and useful information that anyone will be able to use right away.] I fully agree. In our website we don’t sell anything. Our volunteers and visitors create content and share knowledge. For feee. We use wiki-software to make sure that everyone can make a contribution. In this case about a hobby: classic cars.

  44. 044 // Atv // 07.24.2008 // 12:28 PM

    This is definitely something I’ve been trying to resolve for my own projects but I’ll save the long, rambling response and give you the simple mental model that I’ve been using lately.

  45. 045 // Carnapple // 08.05.2008 // 9:19 AM

    Most ecommerce stores lack the easy navigational system that is necessary to make their clients be able to find their products fast, usability sometimes is not their main focus, all they want to do is make a sale.

  46. 046 // Internet Marketing // 09.10.2008 // 7:26 AM

    You have shared a good knowledge of web designing/development, thanks for posting this blog. I was in search of a good web development company then I found Rupizmedia, a very reputed web designing company. It is really trustworthy and recommended.

  47. 047 // AmaliaMendos // 09.18.2008 // 7:25 PM

    Hey. I’m sorry for offtopic. Where you download this theme for site? I realy love it. Amalia

  48. 048 // pay per click management // 09.25.2008 // 5:28 AM

    I usually work on Rendered Output Layer and think the best model of web development as per latest trends. It offers to user a diverse type of interaction and randomly presentation of web page. But I was unaware with Business logic layer, now i will implement this in my new development project. Thanks for this post :)

  49. 049 // Jason Gorman // 11.15.2008 // 3:28 AM

    DATA, LOGIC, FORM, STYLE and BEHAVIOR arranged as a PENTANGLE.

  50. 050 // Lingerie Wholesale // 12.02.2008 // 7:56 PM

    You have shared a good knowledge of web designing/development, thanks for posting this blog. I was in search of a good web development company then I found Rupizmedia, a very reputed web designing company. It is really trustworthy and recommended

  51. 051 // Jan met de Pet // 01.26.2009 // 1:47 PM

    I do agree that […the database is the place where the structure begins. ] It is difficult for me to see how […(X)HTML templates are pretty much part of the presentation layer. ] Regards Jan

  52. 052 // Sohbet Odalar? // 04.21.2009 // 11:29 AM

    hi,,,! avril congrat’z i hope u have more composed songs, to make has, ur fans happy…! cause ur songs make my world rock and happy…! hey..! my friends tell me were the same voice but not really…! luv yah..! muah..!

  53. 053 //  Website Design                // 05.25.2009 // 12:26 AM

    Another important factor for a well designed and programmed website is the quality search engine optimization service. Search engine optimization is the basis of search engine marketing success, because website optimization process spice-up the website with relevant keywords, facilitate one-way link, enhance link-popularity and place website at top or near the top of search engine result page that ultimately help in attracting motivated buyers and more traffic to website.

  54. 054 // Seo Company // 05.25.2009 // 2:49 AM

    As a serious online business person, what is important for your business is, to prepare a website that is well designed, attractive, easy to navigate, highly usable, good content, full of relevant information, enough functionalities and are capable of retaining visitors for long and make them come back again.

  55. 055 // Sohbet // 05.31.2009 // 1:40 AM

    I do agree that […the database is the place where the structure begins. ] It is difficult for me to see how […(X)HTML templates are pretty much part of the presentation layer. ] Regards Jan

  56. 056 // Chat // 05.31.2009 // 1:41 AM

    Thanksss… wonderful by admin.. thanks thanks..

  57. 057 // Sohbet // 05.31.2009 // 1:42 AM

    very gooodddd..

  58. 058 // siki? // 06.24.2009 // 12:27 AM

    thank you admin

  59. 059 // sohbet // 07.24.2009 // 3:18 PM

    Thank you very muCh admin

  60. 060 // sohbet // 07.24.2009 // 3:19 PM

    I usually work on Rendered Output Layer and think the best model of web development as per latest trends. It offers to user a diverse type of interaction and randomly presentation of web page. But I was unaware with Business logic layer, now i will implement this in my new development project. Thanks for this post :)

  61. 061 // Web Action Design // 08.09.2009 // 11:29 AM

    Sometimes we can’t help to over complicate things with extravagant design concepts and strategies. Just keep it simple.

  62. 062 // kameral? sohbet // 08.10.2009 // 2:21 PM

    I do agree that […the database is the place where the structure begins. ] It is difficult for me to see how […(X)HTML templates are pretty much part of the presentation layer. ] Regards Jan…

  63. 063 // Web Site Design Companies // 08.27.2009 // 2:24 AM

    I agree with you…. good job.

  64. 064 // chat // 09.09.2009 // 1:33 AM

    thanks you admin very good

  65. 065 // Quick House Sale // 09.14.2009 // 8:10 AM

    This blog is really is realy great.
    quick house sale

  66. 066 // green laser pointers // 11.19.2009 // 7:13 AM

    Yesh this blog really great. Very interesting one.

  67. 067 // Sohbet // 11.21.2009 // 9:21 AM

    I do agree that […the database is the place where the structure begins. ] It is difficult for me to see how […(X)HTML templates are pretty much part of the presentation layer. ] Regards Jan

  68. 068 // Chat // 11.21.2009 // 9:21 AM

    This blog is really is realy great. quick house sale

  69. 069 // website seo company // 11.26.2009 // 5:56 AM

    Great response I shall be researching this topic further.. website marketing company

  70. 070 // canl? tv // 12.04.2009 // 4:55 AM

    I would love to hear more on this as well…

  71. 071 // turk porn // 12.13.2009 // 5:46 AM

    thanks all good article and comments

  72. 072 // buy laptop // 12.17.2009 // 10:25 PM

    The importance of building a web presence in today’s times is immense, triggering rush by people and organizations to own websites to make themselves visible on the internet.

  73. 073 // Adult izle // 01.08.2010 // 3:16 PM

    Thanks you admin

  74. 074 // Double Glazing Windows // 01.12.2010 // 6:02 AM

    Very interesting topic, can you post some further information on this subject.

  75. 075 // sohbet // 01.30.2010 // 5:38 PM

    ilginç bilgiler te?ekkürler

Tags for this entry