

Something is wrong with this picture. - Nemmie
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0707.html

======
buff-a
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.

~~~
jeromeparadis
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
> I believe standard bodies should put their brains and efforts on defining
> API standards.

Have you seen SOAP?

~~~
DuncanIdaho
He said put brains into it.

Not in a sense: "Throw your brains in for zombies to have a party". But in a
sense that one should try and think and find protocols which are elegant in a
sense that it makes reasoning about and using them easy and simple.

I agree that coming up with SOAP and XML-RPC took quite some brains and
effort, too bad that some really good people had to be lobotomized for it.

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

~~~
haberman
The myth that the web would be better with strict XML parsing is convincingly
debunked here:
[http://web.archive.org/web/20110514122249/http://diveintomar...](http://web.archive.org/web/20110514122249/http://diveintomark.org/archives/2004/01/14/thought_experiment)

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.

~~~
stonemetal
That isn't really related to what he said at all. Sure web browsers should be
forgiving in what they except, but dev tools shouldn't be. How would you like
the C compiler that tried to interpret any old chicken scratch as a valid C
program? Never a compiler error again!

~~~
haberman
> How would you like the C compiler that tried to interpret any old chicken
> scratch as a valid C program? Never a compiler error again!

Oh fun, bad analogies time! How would _you_ like it if your word processor
refused to save a text document because it detected an incomplete sentence?

~~~
stonemetal
Nope no analogy. If I expect a machine to understand a language, then it had
better be able to determine weather or not a document written in that language
is valid. It doesn't matter if it is a programming language or a mark up
language. Permissive modes are great for accepting the work of others, but
when learning how to write that language in the first place a strict
interpretation is best. That way you can focus on getting it right.

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

------
politician
"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
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://jnd.org/dn.mss/human-
centered_design_considered_harmful.html)

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

~~~
politician
Thanks, those links were well worth the read.

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

------
zitterbewegung
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?

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

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

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

~~~
Fluxx
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
In this age of rich webapps, the markup is just there to launch javascript.
There's nothing particularly wrong with that IMHO.

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

