W3C home > Mailing lists > Public > www-style@w3.org > September 2005

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

From: Orion Adrian <orion.adrian@gmail.com>
Date: Thu, 15 Sep 2005 17:47:56 -0400
Message-ID: <abd6c80105091514472790b764@mail.gmail.com>
To: www-style@w3.org

On 9/15/05, David Woolley <david@djwhome.demon.co.uk> wrote:
> 
> Orion wrote:
> > On 9/15/05, Emrah BASKAYA <emrahbaskaya@hesido.com> wrote:
> > > On Thu, 15 Sep 2005 05:43:37 +0300, Orion Adrian <orion.adrian@gmail.com>
> > > wrote:
> > >
> > > > So I say that a new model is already upon us. I say that it's time we
> 
> That's basically just describing the normal lifecycle of standards.  Start
> with bloat; new lean and mean targetted; industry committees; new bloat.

At some point, hopefully, a lesson is learned. Don't bloat. Stick with
targetted specs. Not every company is making these mistakes.
Ironically Google has learned to keep it's products lean and keep them
lean. Ben Goodger of Firefox seemed to learn the lesson as well and
understood that extensions were key.

> > > > took a look and see why so many people are starting to prefer RSS over
> > > > standard HTML feeds and in that view I find we'll see that client side
> 
> I would say that RSS was closer to a re-invention of gopher than to
> a re-invention of HTML.  I would say the Wikipedia language was rather
> closer to the original concept of HTML, although, potentially unfortunately,
> it has escape mechanism for including raw HTML/CSS.

Wiki has the same intention as the original HTML and many of the same
problems, though it includes it's own CMS system which doesn't require
users to learn HTML, but rather stays closer to natural formatting and
language.

I think the code system for the more pervasive forums online is a good
example of scaling back to what's necessary. BB Code I think it's
called. It's at least scoped and avoids divs and spans and other forms
of styling that really aren't necessary within the content at least.

> > > > CSS and Javascript isn't a good solution.
> 
> > 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.

> There are other SGML (and XML) applications, like DocBook and various
> electronic data interchange formats that are aimed for more sophisticated
> users or specific document structures.

I agree that there are formats out there that are more sophisticated,
but what I'm looking for is something inbetween the ontology effort,
the microformats effort and native platform efforts. What I want is
microformats that describe things. I also want a fallback category for
the undescribed. But until we all decide on a computer format for
describing names then I'll still have to deal with stuff like:

<firstname>X</firstname>
<firstName>
<first-name>
<name>X Y</name>
<given>
<givenname>
<givenName>
<given-name>

well you get the idea, but it gets really insane even from there and I
didn't even include last names. Standarizing on the little pieces
makes creating big pieces much easier, but every format still goes and
redefines something slightly differently. Microsoft even has a product
who's primary purpose is to take data in one form and put it into
another: BizTalk.

Now for this to happen, XML has to be fixed just slightly because
namespaces which are necessary for this kind of thing are just too
onerous to work. Also attributes can't be marked up for extension
properties.

Unfortunately we're much farther than I'd like to be and I'm afraid
I'm going to be an old man before I start seeing stuff like this come
to fruition, but I still hope and pray that people will come around
and stop worrying about things like how to add new types of event
logic and how to create multiple, layered backgrounds and get around
to figuring out how to make new behaviors possible. I feel CSS is way
too focused on what the graphical designer wants and not what users
need. I know it seems backwards to some, but it's how I feel.

-- 

Orion Adrian
Received on Thursday, 15 September 2005 21:47:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:40 GMT