Re: Transition (was Re: Capitalize across "span")

John Udall wrote:

>	From practically the beginning, some people just didn't get it.  They
>tried to force HTML to make a document "look" just right.  And it didn't
>work. If you resized your browser window, or viewed the document on a
>different platform, or in a different browser and the document just didn't
>"look" the same.  The information content was still there, but the "look"
>wasn't right.  Some people just felt they had to force it.  That's why we
>have all of these documents that use tables to control display which we're
>always complaining about.

Not to rehash the past, but rather than blaming users, I think the
widespread use of tables for layout (and I will be the first the admit that
they're a kludgy workaround that causes me no end of grief) shows that the
spec was insufficient for the needs of users. Presentation *can be* an
important aid to comprehension, as shown by numerous studies that are cited
in Karen Shriver's "Dynamics of Document Design."

>	I think that part of the problem is that separating document structure
>from document display is not a process that is intuitive for many people.
>It didn't help that early browsers did not offer a lot of control or
>customization over the final "look" of a document.

One reason the populace rebeled is that earlier HTML and browsers forced us
to abandon "user interface" techniques for content that have been developed
and beta tested over the past five centures (arguably I could go back
further, the advent of the printing press started the standardization of
these techniques). HTML in those days was better suited for being read by
machines than by people. (Incidently, the one legibility study of SGML that
I know of, found SGML documents to be difficult for people to understand
precisely because the documents lacked the those sort of presentation aids
I'm talking about.)

Yes, the Web is *not* print, and I do believe pages should be scalable to
multiple browsers, monitors and platforms. However, print has had a long
time to experiment and develop principles for how to present content
effectively. For example, the guideline that leading needs to be increased
as line length increases to maintain legibility is a principle that works
regardless of whether it's a book, a billboard, or a computer monitor.
While admittedly most users weren't aware of this at a conscious level
(since HTML was like the DTP revolution all over again), those of us who
did were found HTML to be painful to work with.

>A good XML markup tool will provide
>affordances for capturing the structure of a document.  Basic style sheets
>for common output devices, coupled with a good tool for customizing them
>will give people the control that they want over the look of the final
>product without alientating particular user populations.

I feel like we're now at the point where we really starting to get all
three legs of the tripod -- HTML for basic structural elements, CSS for
presentation and XML to handle the data about the content, which could
include the structural data if needed. Once we reach the point where these
are widely supported, I'm willing to hang up my mask and live within the
law. The biggest problem I have now if supporting legacy documents and that
means mixing in layout tables for the moment.

While I realize that many here find using tables for layout abhorrent, not
providing some sort of <NOCSS-P> capability to author a combined CSS-P/HTML
3.2 document makes it difficult for me to transition to CSS-P thus slowing
adoption of the standard. Clients simply aren't go to pay me double so that
I can do a CSS-P version and a HTML 3.2 tables version. And presentation is
important enough to them that they won't accept what happens when an older
browser tries intrepret a CSS-P page. So I kludge yet again and use CSS-1
and tables.

>	I don't think that the move to a "pure" separation between document
>structure and display is impossible.

I'm a bit more dubious. In my experience, presenting content most
effectively often entails intertwining
structure and display.  For example, take the widely-used two-column layout
of main content and secondary content. In print it's common "hang"
secondary content in the side column next to the main content it relates
to. Yes, it's possible to make it a footnote at put it at the bottom of the
page (which can be even more problematic on a Web page due to the length)
but that's not nearly as effective a presentation of the information. (It's
also near-impossible to do in HTML without gymnastics despite the fact that
this is an ideal way to handle links to related material, since you can
elaborate about the link, which contributes to better UI, without
disrupting flow of the main content.)  Now I realize you can argue back
that my footnote example proves that the structure is independent of the
presentation, which is true. My point is that it's less legible and poorer
UI, although I believe the "footnote option" certainly should be a fallback
for text-only or low-resolution browsers like PDAs. Admittedly, I'm still
wading through the details of entire CSS specs, but it doesn't seem like
there's an easy way for CSS-P to be changed on the fly to cover a situation
like this. (If I'm wrong, please tell me where to look.) Perhaps XML and
XSL are the answer here, but I won't comment since I haven't read the specs.

>The
>people who will be hard to bring around are those who don't even know what
>the standard is, and they don't subscribe to www-style.

Again I think one of the keys is making sure that standards meet the needs
of those using them, which makes it a lot easier to convince people to live
within the standards. I'd agree everyone is trying to be helpful here, I
just think the academic/programming backgrounds of many of those here have
sometimes left blindspots to important issues of how HTML/CSS/XML etc. will
likely be used by those outside the  academic/programming circles.



George Olsen
Web Architect/Designer
mailto:golsen@2lm.com
2-Lane Media
http://www.2lm.com
vox 310/473-3706 x2225                                         fax 310/473-6736

Received on Tuesday, 10 February 1998 17:48:05 UTC