Something is wrong with this picture.

http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0707.html

by Nemmie • 15 years ago

192 81 15 years ago

lists.w3.org

politician2• 15 years ago

"I heard people speak of Web Authors and Web Developers and making various distinctions about them. I heard some folks of arguing that this audience of ours prefers markup over scripts, and when faced with concrete examples of the opposite, retort that those are just some script library folk, not the majority."

Get these people some personas, stat!

jasonrr• 15 years ago

I find that personas are nearly useless for this kind of design discussion. Personas are an attempt to homogenize some group of people into a single pseudo-person that has specific attributes. When the lines between personas are hard to draw or there are so many lines that you wind up with lots of personas, you can find yourself spending lots of time managing personas without a ton of direction or solving anyone's problems.

For a heterogenous audience like "web makers" of various types, an activity centered approach can be really helpful. Don Norman explains this idea better than I ever could:

http://jnd.org/dn.mss/human-centered_design_considered_harmf...

http://www.jnd.org/dn.mss/hcd_harmful_a_clarification.html

politician2• 15 years ago

Thanks, those links were well worth the read.

zitterbewegung• 15 years ago

I guess the real question is can you or how would you try to reform the culture that has surrounded the process? Or is the alternative branching out and creating your own like WHATWG?

sskates3• 15 years ago

HTML markup is a good example of premature design optimization. It may have been a good in theory to separate content from presentation, but if you look at the web today, the way pages are generated is a huge mess.

Even this site, which uses tables for layout when "you're not supposed to used tables for layout", is a good example of why HTML is so bad for creating web pages. There's no reason I should have to jump through all the hoops I do to display two div blocks side by side in a horizontal box. All other XML based layouts I've used (Android and Flex) are a piece of cake compared to messing with HTML, CSS, and JavaScript.

zdw• 15 years ago

HTML had the opportunity to get better with XHTML and strict enforcement of schemas and XML syntax (which I'm willing to bet Android and Flex require).

The problem was that doing so broke most of the web, or was not internalized by page creators. So we're stuck with the current situation (bad markup, crufty designs, etc.).

Imagine if the first HTML editors forced a schema check before save. I think we'd be in a much better place now if they did...

bermanoid• 15 years ago

But the problems sskates mentions would not be helped by better schema compliance; they start and end with the fact that CSS is a miserably poor layout engine that is not powerful enough to effectively separate content from presentation.

HTML itself has its warts, sure, but the fact that we end up constantly resorting to HTML and/or Javascript edits to do things that should be happening in CSS alone is, to me, a much worse problem.

nene• 15 years ago

I would argue the contrary, that the very reason why HTML took off so fast was that any fool was able to craft a site, and it would work even if it had a few bugs in it. Failure tolerance is a great feature. Especially if you consider it in the context of document authoring - for which HTML was originally designed for - it's better to read a document that has one unclosed <b> tag in it, than to be completely unable to read it because there's a syntax error in markup.

haberman2• 15 years ago

The myth that the web would be better with strict XML parsing is convincingly debunked here: http://web.archive.org/web/20110514122249/http://diveintomar...

Web pages (unlike Android layout files) are complicated composites of multiple data sources that are generated on-the-fly, and are combined in complicated (but sometimes low-tech) ways like string manipulation. Under such circumstances, it is simply too hard to create perfect XML every time.

jtwb• 15 years ago

This is a failing of CSS, specifically. CSS has extremely limited tools for building a page layout.

See http://www.w3.org/TR/css3-flexbox/ and http://dev.w3.org/csswg/css3-grid-align/

sskates3• 15 years ago

But it doesn't make sense to me- why does presentation need to be separated from content? On pretty much every single page on the internet, layout and presentation are so tightly coupled that it ends up being more of a hassle to maintain a separate style sheet than it is to declare stuff inline.

_delirium• 15 years ago

I'm not sure it was particularly premature for the original use case, which was writing hypertext documents. HTML inherited the idea of structure/style separation (though initially implemented in a sort of half-assed way) from previous document markup languages, like SGML and LaTeX, where it had gotten a decent numbers of years of exercise, and worked fairly well. I mean it still works pretty well in LaTeX, though not perfectly.

mbreese• 15 years ago

You're exactly right... for the original purpose - hypertext documents - HTML and CSS work just fine. The problems arise from the fact that we've hijacked these documents to produce web applications which use the barest stub of a document to get running. And then we try to shoehorn a dynamic site into what was originally designed to be a static document. Dynamic content was originally the exception, not the norm.

Frames were actually a good effort to solve the problem of web-site "chrome" (navigation bars, headers, etc), and were somewhat useful. But they proved to not be flexible enough for designers (rightly so), and thus we have the mess that we have now.

baby2• 15 years ago

Actualy is it so wrong to use table (like we're not supposed to) in a profesionnal css design? They do great in every browser from ie 6 to opera and they don't nead clear:both or other tricks.

I miss designing with tables... And I just don't do anymore because I was told not to, for maybe no good reasons.

ricardobeat6• 15 years ago

There are perfectly good reasons. Read my comment above and the many answers here: http://stackoverflow.com/questions/83073/why-not-use-tables-...

Fluxx3• 15 years ago

Ceasing to adopt standards, best practices and support users who are disabled because "the old way seems to work better" is a terrible way to advance technology.

nikatwork2• 15 years ago

I also like how CSS has less layout functionality than tables, specifically <td width="*" valign="middle">.

Sure, you can emulate this with "display: table;" but a) it's not backwards compatible and b) that's the same darn thing as just using a table!

ricardobeat6• 15 years ago

It's not "the same darn thing". The <table> tag is for tabular data, it implies relationships between it's elements that are of utter importance for screen readers and machines. It might be ok visually, but structurally it's a mess.

display:table is not an emulation, it's exactly the same behavior as a table, exposed for use at will. You can use the flexbox model for the same effect: http://jsbin.com/ejeraq

Be very glad that you have good vision and Google engineers spend millions and decades on making some sense of tag soup.

ricardobeat6• 15 years ago

Pages made by decent developers are not a mess. Certainly orders of magnitude less messy than handling all your presentation in code, mixed with business logic and controllers.

Separation of presentation and content allows for information to be accessible by everyone, indexed/readable by machines, adaptable to different displays. It's also easier to maintain (content editors can't mess with layouts) and makes many performance improvements possible.

The HN site has no special reason to use tables, it's perfectly possible to render this layout using semantic, clean markup. CSS has come a long way since 1999.

gnaritas2• 15 years ago

But nowhere near as easy or as cross browser compliant, especially at the time this code was written.

jheriko• 15 years ago

I like to think the whole problem with web development is that it is popular. Almost all of the exclusive web design/script people I have met are essentially terrible at what they do - I think this happened because the web is so popular and so new that the good engineers and designers are so few and far between that their direction is diluted by the masses. Hopefully it will right itself over time.

Ultimately the tools will mature to the point where what the data representation is beneath them will mean nothing to these kinds of consumers. (e.g. how you save your photos as .jpg, .tga or whatever and usually care less about the details).

Fluxx3• 15 years ago

Most sites use an HTML page to launch a JS-driven app because HTML as a presentation medium is not as responsive and lack the UX elegance that one can achieve with Javascript. It's simply a technology stack that works better at solving the job.

The main problem is that everyone is reinventing the wheel to deliver that kind of experience with custom JS code that augments the DOM in different ways. If browsers and the W3C worked out a way to deliver a similar UX over something standardized that browsers, crawlers and other consumers of the web could rely on, that would get used.

maximusprime• 15 years ago

In this age of rich webapps, the markup is just there to launch javascript. There's nothing particularly wrong with that IMHO.

lukev• 15 years ago

There's everything wrong with that. There are huge benefits to handling the internet as a linked graph of documents and resources. Try writing a site that loads all its content via Javascript and see how well you rank in Google.

I have nothing against the existence of web applications, as long as it's recognized that they have a fundamentally different nature and purpose than a web page. The W3C doesn't always make decisions that are right for everybody, but they've done a pretty decent job of preserving the ideal of a document/resource-centric web. And it's important that it stays that way.

jamesrom• 15 years ago

A markup language, by definition, cannot define behaviour. You can do design, layout and animations with markup, but you simply cannot do any kind of processing or behaviour (when I say behaviour, I mean things like authentication, processing, manipulating data, etc). So if your webapp needs to be behaviour-rich (which I don't know how you can call it a webapp if it isn't) then you're going to need a scripting language to define those behaviours.

HTML + CSS + JavaScript are complex tools, it would be great if we could unify them into a single language. I think that jQuery's success is in part due to this unification, but I certainly don't think jQuery is the answer.

repsilat• 15 years ago

Lispers have said a few times that HTML/Javascript would be well replaced by S-expresssions and (a) Lisp. There are more than a few reasons why it won't catch on, of course, but even to an old-school imperative programmer like me it sounds a damn sight better than what we have now.

buff-a• 15 years ago

Either you have separation of data and presentation or you don't. HTML didn't. HTML5 still doesn't. It is not possible to present an arbitrary block of data in a normalized, optimal form, and have CSS render it any way you want. For that you need script (or XSLT!), but even then, unless you go canvas, you have to deal with a markup language for presentation that is actively trying to not be presentation but be data instead. Its trying and failing. Life would be so much easier (and involve much less cognitive dissonance) if the DOM stuck to being presentation.

As it is, developing web apps is this giant joke, where you encrypt what you really want to happen in the form of pseudo-data (html) and magic rule-based transformation (css), and then the browser goes to a ton of effort to attempt to recreate what you really wanted. The effort the browser has to go through as soon as you introduce a div, or change its class, just to determine which, if any, of the CSS rules now apply to that node and any of its children, is just offensive. Worse: its something you, the programmer, must be able to model in your head to determine what the fuck is going on. Good luck with that! The result we get is "try it and see" "programming".

HTML1.0 was a local optimum. Somewhere there is another, better optimum. The W3C appears to be willing to travel the Himalayas of suboptimal to find it.

fooandbarify2• 15 years ago

While I certainly agree that there is tons of room for improvement with HTML/CSS/JS, I get confused when people start discussing it in such hyperbolic terms. It's not that bad. Most data on the internet fits really nicely into the document metaphor.

knieveltech• 15 years ago

Normally I immediately bridle when someone offers criticism without including proposals for improvement[1] but in this case it really is that bad. It really, really is.

And while I would be willing to agree provisionally that most data (by volume of unique URLS) on the web does fit the document metaphor, if page views is your metric I'm not at all convinced.

For example, is it logical to even attempt to reason about a Facebook wall containing recent updates from $n individuals in terms of authorship? Is this even relevant information given the entire contents of the page will have changed in 12 hours?

The document metaphor made perfect sense 15 years ago but it breaks down quickly in the face anything dynamic, as is evidenced by the need for any credible web developer to have a minimum of 7 largely unrelated technologies[2] committed to memory to do their job effectively.

Markup 15 layers deep? 2000+ lines of code to tell the browser how to render a website? Vendor-specific dynamic rendering engines to sidestep the limitations of native web languages? Surely this is not what success looks like?

[1] Unfortunately I have no idea how to fix this mess.

[2] HTML, CSS, JavaScript, a JS Framework (typically jQuery), at least one back-end language, SQL or similar and API stuff (SOAP, JSON, etc).

srl• 15 years ago

Amen.

More disturbing still: because those people who are learning to program /now/ - in this decadent era of webapps and mobile devices - learn the brain damage that is modern web development early on. And it turns out (sorry, no evidence here but my own observations) that when you're first learning something, it's easy to mistake a brain-damaged system for an elegant one. And so, yes, there are people learning to program today, holding up CSS as an example of elegance.

To be honest, I wouldn't complain about CSS so much - even if it lacked the much-seeked "separation of data and presentation" (isn't there a buzzword for that somewhere?) - if only accomplishing simple tasks didn't require obscure, unreliable hacks. As long as CSS was capable of formatting a reasonably-constructed document (titles before text, left-hand elements before right-hand elements) without hacks, I'd be happy. But it's not. And it doesn't look like it will be any time in the near future.

rimantas3• 15 years ago

  > As long as CSS was capable of formatting a 
  > reasonably-constructed document (titles before text,
  > left-hand elements before right-hand elements) without
  > hacks, I'd be happy.

What hacks do you need to do that?

alex_c• 15 years ago

>Either you have separation of data and presentation or you don't. HTML didn't. HTML5 still doesn't.

Is it really so desirable? I understand the appeal in theory, but in practice is it really worth it in most cases?

Or perhaps I'm so scarred by HTML and CSS that I can't even visualize a web with true separation of data and presentation that actually makes life better.

Edit: some of the other comments discuss this. Of course I see the advantage of abstraction and reusability. What I'm really asking about is the advantage, or even feasibility, of a pure, or strict, separation of data and presentation.

jeromeparadis2• 15 years ago

Totally agree.

In my opinion, the problem of separation of data and presentation won't be solved by markup or CSS.

If a Web page is to contain data and a service wants to act on this data, it has to scrape the Web page. Which is even harder with scripted pages. But scraping data isn't a solution. The semantic web may try to have web developers bring sense to data on a web page, but the problem remains. It's just a markup patch. It's doesn't define how to act on that data. Web Intents are just another patch to markup to bring verbs.

Direct access to the data sources with well define methods to act on that data and interact with it (instead of using form) is what works today through APIs. What doesn't work is that there aren't a lot of open standards APIs. Most well used APIs are proprietary and Facebook's a good example. I believe standard bodies should put their brains and efforts on defining API standards. Some standards APIs some clunky, are in use in B2B in the back ends but there's not much of it on the consumer facing Web. We must move forward to push separation of presentation, data and verbs for the whole Web, one small step at a time.

If most use cases on the Web used standard APIs, we would have true separation of content and presentation. We would even have the verbs to exchange/create understandable content. Then, you can use HTML/CSS to adapt a UI to any device with true separation.

That's the way we build apps and sites today and with standard, it would pave the way to a more exciting future.

So one day, if I want to have my own customized UI for that new holographic/gesture recognition device to shop with my preferred merchants, I just have to build an app and I'll be able to browse their merchandise, sort it like I want and finalize a transaction without even visiting their Web site.

epochwolf• 15 years ago

> I believe standard bodies should put their brains and efforts on defining API standards.

Have you seen SOAP?

danssig2• 15 years ago

>If a Web page is to contain data and a service wants to act on this data, it has to scrape the Web page.

This is completely the wrong approach and this isn't how people who know what they're doing work now.

A web page is just a presentation layer. If you have a service that wants data, it needs to work with a model or presenter/controller layer. On the web this can be a REST service, SOAP, something proprietary, etc. Ideally, the web site will be using this same source to get its data.

If the web application presents data via a web interface and doesn't offer a presentation/controller layer to allow you to access that same underlying API, then yes, you will have to scrape if you want that data for some reason. But I don't see this as wrong, you're doing something the owners of the data didn't intend for you to do. You'll have similar issues if you want to get data out of any application view (e.g. screen scraping a windows native app).

EDIT: Read the rest of your post and I see that you addressed much of this already. I still maintain that this is already how people are working who want others to use their data.

einhverfr4• 15 years ago

I think you are missing the fact that a good document really needs three things:

1) Data (RDF, NoSQL, RDBMS, etc)

2) Structural presentation (i.e. what HTML or LaTeX provides) and

3) Presentation to the user (i.e. what CSS or macro packages in LaTeX provide)

To get from 1 to 2, you have to have some logic. You could do it with Javascript acting against RDF and HTML, I suppose. Or you could do it with XSLT. However there's no inherent guarantee that inherent data structure will in any way match your document structure and so these are really separate concerns.

This is why HTML template systems are so important for web programming.

gambler• 15 years ago

"HTML1.0 was a local optimum. Somewhere there is another, better optimum. The W3C appears to be willing to travel the Himalayas of suboptimal to find it."

I don't think they're even going in the general direction of better optimum.

Here is what I think that optimum should include:

- Better document model (vs no document model at all, which seems to be where it's all headed right now).

- Separation of content, layout and styling. Yes, into three parts, rather than the two we have right now.

- Partial caching and user-side includes that aren't a blob of ugly, shortsighted hacks. Something that's works with the document model, not against it. It's absolutely ridiculous that I have to write custom code to prevent the browser from re-downloading (and the server from re-generating) page headers so on.

- Significant improvement of forms. New UI elements, support for pure-HTML put/delete requests, different format for sending data that has structure (vs only key-value pairs).

einhverfr4• 15 years ago

Generally agreed, but would suggest a slightly different set of concerns separated.

instead of separation of content, layout, and styling, I would suggest a separation of data, structure, and styling. Data + structure gives you content, structure plus styling gives you layout.

So in this idea you might have RDF as data, an HTML template as structure, and CSS as styling. The browser would generate the HTML from the template and the RDF, and the CSS would then be used to lay it out and style it.

halo• 15 years ago

HTML is a structured document format, with CSS for styling and presentation.

The web became so popular that developers want HTML to be an unstructured data format with a separate fully-fledged layout language.[1]

Neither idea is wrong, there's just an impedance mismatch between the two.

There are three options:

1. The status quo. Developers mangle technologies designed for something different so it does what they want, with an increasing use of libraries and abstractions. It's inefficient and messy, but it works and is backwards compatible.

2. Give up on the idea of structured data and try to mangle HTML/CSS to be closer to what developers want. You end up with a crap structured document language and a crap web application language, but the web application language will be slightly less crap than the status quo.

3. Create a new language actually designed for web applications with a proper layout engine and HIGs to go with it. Despite being the most sensible option, this isn't realistically going to happen. A lack of backwards compatibility kills adoption and browser makers will never agree. It took them a decade to agree on a font format.

None of the options are ideal. I suspect somewhere between 1 and 2 will happen in reality.

[1] Layout is also a really hard problem. I don't think it's been acceptably solved in the general case.

ricardobeat6• 15 years ago

For me this just demonstrates W3C's distancing from reality... There where pretty good data-driven and thought-out decisions on HTML5 from the beginning, but things were pretty grim for this year. Parts of the spec are being just pushed around (microdata…), meanwhile there is no public place for developers to be heard (and no, mailing lists and bug trackers are not ideal. this is 2011).

Despite that, the web as a platform is getting better and better. Yes, it's hard to build stuff with HTML/CSS/JS, but it gets easier by the month, and the current state of the technology is really amazing (except for a few legacy browsers still bogging things down).

danssig2• 15 years ago

Many of us are developers on here, so I propose the following: rather than be lead around by the nose on this, why don't we change it? We could define our own XML (or JSON? optional?) based data markup format and a separate presentation markup (XML/JSON based though!) format for displaying it on a graphical interface. Then we could create a browser plug-in that used it, or fork a browser to understand how to render it (or both).

We could set up our web servers to detect if the client has the plug-in/browser and serve this new standard if so, or redirect to "legacy" web pages if not (with a little "best experienced with" badge). If the day comes that we aren't getting anymore "legacy" requests we can just drop them (or even better, just program the servers to be able to auto-generate something passable if a legacy client did happen by). If done right, this really could get traction, since most web designers would prefer a nice format to fighting their way through as one has to today, and clients shouldn't be able to tell any difference.

The web is ours. If the "standards bodies" are making crap standards we don't have to stand for it.

yason• 15 years ago

The thing is, web was supposed to be about documents but it always wanted to be about programs. A basic markup language together with styling goes with the former but in the latter it becomes something you need to work around.

Something is wrong with this picture.

Related Stories