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

Re: Primer for layout/formatting split.

From: Orion Adrian <orion.adrian@gmail.com>
Date: Wed, 6 Jul 2005 12:44:21 -0400
Message-ID: <abd6c801050706094442d27ca9@mail.gmail.com>
To: www-style@w3.org

On 7/6/05, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> Orion Adrian wrote:
> 
> >Some of these points might be disputted and some have been, but for me
> >the form the core of my belief structure as to why there needs to be a
> >split. The layout language is forthcoming shortly.
> >
> >
> This post makes a lot of sense.
> 
> However whether this warrants a split in the actual language used to
> express that remains to be seen (I have not read your 'New layout
> language' post yet at this time :)). Why couldn't both be specified
> using the same syntax?

Formatting is semantic classification based with ideally no
classification needed id's. If you find yourself formatting something
based on an id, then you're probably in the realm of layout.

So formatting is based on semantic classifications and layout is
content, providing its own regions and then assigning content roles to
each region like title, navigation, content, tasks, etc. Each region
can then pull associated content from wherever.

> It also mentions author-based layout as not desirable, however giving
> the control of that to the user is just not acceptable to many, and too
> big a leap from what we have right now. Authors *want* to design their
> own layout, just look at the web and many desktop applications as well
> (although I have to agree I usually dislike those - Winamp excluded).

Say I had a layout for my file explorer/manager. I could have the same
basic layout for all file types with specific regions being populated
based on media type.

If the file is an audio file, it would have audio tasks on the left
region, the file name and detailed descriptions in the center and
maybe a list of associated artists/songs on the right.

When navigating to another audio file those would simply be changed
without the need for anything. The beauty of this is that each section
could be pulling from different areas. Some would be pulling from the
local system (i.e. tasks), others could be pulling from the content
website, while another could be pulling from an internet database like
AMG. The idea behind it is to create ad-hoc content that just isn't
possible now. We currently see RSS as a syndicated version of the
webpage, but really the webpage is a view of the syndicated content.
Each format would be served in an optimized format and not as HTML.

It really brings HTML, web services, the file system and applications
together in a way that hasn't been accomplished to date merely for the
fact that layout is intergrated with content. There's no way for the
UA to bring all these things together intelligently in a way that
adheres to usability guidelines.

We talk about what the world would be like if Microsoft has just kept
developing IE. I say, it would be the same place because we keep
looking at the current model and say, it's good enough. It's not and
it never will be. That's why we keep striving forward. That's why we
keep changing things; to improve them.

And it's all for a simple change in how we do it.

-- 

Orion Adrian
Received on Wednesday, 6 July 2005 16:44:25 GMT

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