Re: Browsers will never get it right [was Re:Blocked-base parsing?]

On 9/16/05, Larry Israel <lisrael@cruzio.com> wrote:
> 
> >> > possible (e.g. tracking what you've read or haven't, marking posts for
> >> > keywords). Since the structure of an HTML document is unknown on any
> >> > give site beyond the required html, head, title and body elements, you
> >> > end up not being able to determine what is content and what isn't.
> >>
> >> Making HTML simple was a deliberate part of the original design.  Whilst
> >> now you seem to need to take expensive web design courses to use it, the
> >> idea was that it was so simple that any secretary or librarian could
> >> mark up text.
> >
> > And while this was something the early adopters were willing to do, we
> > now must compare what a secretary or librarian could do against what
> > is out there in the wild. Most people just aren't satisfied with
> > producing something that looks many times worse than the standard.
> > What they will look for is something that eases the process while
> > giving them professional results. If everybody drew like me, I might
> > do it as a hobby, but since I do draw the way I do (poorly) and there
> > are pros out there who draw they way they do (very well), my ego can't
> > take the hit. And I firmly believe that's part of the problem. Again
> > I'm looking for practical solutions to the problems we're facing. We
> > must take into account the psychology of the audience we're targeting.
> 
> This points to one of the fundamental problems with the current styling
> system. In theory, it should be easy to style any standard XHTML documents
> with CSS.

<snip />

> The reason it doesn't work today is because the way documents are marked
> up with (X)HTML is not sufficiently standardized. When marking up a page,
> there are many choices and every web author does things differently. This
> is largely because we don't have <header>, <footer>, <content>, <section>,
> <nav-primary>, <nav-secondary>; or any other similar system that is
> actually known and used by most web authors; a system that describes the
> functions of all of the elements and their relations in detail. (The tags
> given here are just an example, and perhaps a poor one, but I'm sure you
> get my drift. Authors could just as well standardize on <div id="header">,
> or something else.)
> 
> A big problem with CSS is that a style sheet must be written for a
> specific group of documents. Unfortunately, the two are tied together by
> necessity. Generally, a CSS file is not transferable to other sites. You
> can't just take a style sheet from a CSS library and link it to ANY
> standard XHTML file. If you could, there would already be CSS libraries
> (both open-source and commercial) with CSS files and background graphics
> for download, and lots of people would be using them. (Maybe there are
> some already and I just haven't seen them?)

Well that's an issue with a generic system trying to markup hundreds
of different formats of data. Since things aren't effectively
described in HTML and CSS requires very specific markup authors are
left with no choice but to come up with their own markup through id
and class. These being non-standard effectively nullifies CSS's
transferability. And you've said as much, so it's nice that we're on
the same page.

The fundamental problem as I see it is that HTML tries to generalize
everything. Instead of talking about contacts, I'm talking about
paragraphs. Instead of products, I'm talking about tables. HTML
focuses too much on communicating through the same broken systems that
language uses and ignores what the underlying data is. HTML would be
better served two fold. One for describing snippets of text. Second as
a transport protocol for strongly-typed content.

-- 

Orion Adrian

Received on Friday, 16 September 2005 14:14:33 UTC