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

Server and Client Capabilities (Where Info. Should Be Located)

From: Orion Adrian <orion.adrian@gmail.com>
Date: Tue, 12 Jul 2005 22:58:37 -0400
Message-ID: <abd6c801050712195845aaf0dd@mail.gmail.com>
To: www-style@w3.org

I really wish it was feasible to have longer subject lines. Sometimes
I just feel I can't be as descriptive as I should be, but fear if I go
longer, I'll just make the subject useless (e.g. government titles).

Here I erred on the side of too much information.

I've mentioned this earlier and got no response to this specific point
other than no one would implement it, but here goes again.

It seems rather impractical for web authors to specify document layout
and expect their layout to work on many machines. For one, this at a
minimum limits the range of potential devices that understand certain
fundamental commands that they might not. Now to date there have
really only been two ends well defined that function moderately well:
the completely unstyled (e.g. lynxs) and the completely styled (e.g IE
and Firefox).

There doesn't seem to be a happy middleground. As a web author, I can
create a layout that works given certain assumptions. I can tune my
system by media queries, but that just seems a limited system that
puts the load on the web author (of which there maybe millions) and
not on the device (which there are also a lot of). However one web
author may write hundreds or thousands of pages or more. That means
every author is writing layouts trying to take into account every
device that could run it. Now it should be pretty clear this isn't
feasible unless you rely on the "hints" system that basically only
allows 4 properties (slight exageration).

It should be possible to get effective, attractive, efficient layouts
on every device for a given set of content. It should also be possible
to do this while maintaining author styling sheets for the big
browsers and still allow users to have control of layout.

But this only happens when we move the primary layout mechanism to the
device, make it semantic in nature and not content-based in nature and
finally make it content.

Each region of the layout would specify which types of content it
allows (e.g. class), not which content it contains (i.e. src). This is
where XFrames fails.

Then we can see about moving formatting too.

Orion Adrian


Orion Adrian
Received on Wednesday, 13 July 2005 02:58:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:19 UTC