47  9060 
Neal <ne*****@yahoo.com> wrote: Patrick Griffiths weighs in on the CSS vs table layout debate in his blog
entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php . A
quite good article.
I disagree. A flimsy article, no mention of certain issues that make
table based layouts so author friendly:
Intuitive grid type visualization.
Shrink to fit and expand when needed behaviour/options.
Intuitive hor/ver centering of *all* elements (block/inline).
No mention of the fact that css itself contains a method to replace html
tables used for layout (css tables), but that they are not supported by
IE.
Note that I'm no apologist for table layouts (I plonked B. Pearson
months ago), I never advise their use for layout purposes, and I've
mastered the skill to use css exclusively for layout years ago. But the
fact remains that using css for layout in practice throws up mayor
obstacles for the average author.
Also, first thing I had to do to be able to read the article was to
disable his stylesheets (micro fonts).
--
Spartanicus
Spartanicus wrote: Neal <ne*****@yahoo.com> wrote:
Patrick Griffiths weighs in on the CSS vs table layout debate in his blog
entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php . A
quite good article.
I disagree. A flimsy article, no mention of certain issues that make
table based layouts so author friendly:
Intuitive grid type visualization.
Shrink to fit and expand when needed behaviour/options.
Intuitive hor/ver centering of *all* elements (block/inline).
No mention of the fact that css itself contains a method to replace html
tables used for layout (css tables), but that they are not supported by
IE.
That shows in my opinion how underdeveloped IE is, and overtaked by
other browsers. The sad thing is that because most people still use
this "stone age" browser, Microsoft is now responsible for preventing
the development of WWW.
Note that I'm no apologist for table layouts (I plonked B. Pearson
months ago), I never advise their use for layout purposes, and I've
mastered the skill to use css exclusively for layout years ago. But the
fact remains that using css for layout in practice throws up mayor
obstacles for the average author.
Also, first thing I had to do to be able to read the article was to
disable his stylesheets (micro fonts).
The layout is just his suggestion, as you have yours on your sites.
But why disable it, if the font-size is the only problem? At least he
use percent for font-size, easy to resize even in IE :-)
--
/Arne
"Spartanicus" <me@privacy.net> wrote in message
news:f2********************************@news.spart anicus.utvinternet.ie...
: Neal <ne*****@yahoo.com> wrote:
:
: >Patrick Griffiths weighs in on the CSS vs table layout debate in his blog
: >entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php . A
: >quite good article.
:
: I disagree. A flimsy article, no mention of certain issues that make
: table based layouts so author friendly:
:
: Intuitive grid type visualization.
: Shrink to fit and expand when needed behaviour/options.
: Intuitive hor/ver centering of *all* elements (block/inline).
: No mention of the fact that css itself contains a method to replace html
: tables used for layout (css tables), but that they are not supported by
: IE.
:
These are good points and my advice would be to use tables sparingly, where
CSS fails to deliver.
--
Long www.webcharm.ca - Integrated content management web hosting
Spartanicus wrote: Neal <ne*****@yahoo.com> wrote:
Patrick Griffiths weighs in on the CSS vs table layout debate in his blog
entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php . A
quite good article.
I disagree. A flimsy article, no mention of certain issues that make
table based layouts so author friendly:
Intuitive grid type visualization.
If you need to visualize elements as you're building your page, then it
means you're mostly building a site in a WYSIWYG interaction mode which
is not best for design to begin with.
Shrink to fit and expand when needed behaviour/options.
This suggests your layout is not scalable when not using table for
laying out your content. There are ways to make a site entirely scalable
and independent of the available workarea dimensions of the ua.
Obviously, there are other ways to shrink to fit and expand when needed
besides wrapping content with a
<table width="100%" ...>.
This need to table to make the content "fluid" is also at the source
of nested tables too.
Intuitive hor/ver centering of *all* elements (block/inline).
Don't know what you're talking about here. Are you saying that centering
a table within its parent element should also center its content? Are
you referring to
<table align="center" ...>
No mention of the fact that css itself contains a method to replace html
tables used for layout (css tables), but that they are not supported by
IE.
I don't understand what you're talking about here.
Note that I'm no apologist for table layouts (I plonked B. Pearson
months ago), I never advise their use for layout purposes, and I've
mastered the skill to use css exclusively for layout years ago. But the
fact remains that using css for layout in practice throws up mayor
obstacles for the average author.
But this is a different issue (ease of implementation versus best
practice for the avg author).
IMO, using table layout for rendering non-tabular data is wrong, bad,
nightmare to upgrade, makes parsing, rendering longer, make files
bigger, etc...
Also, first thing I had to do to be able to read the article was to
disable his stylesheets (micro fonts).
One disadvantage of using nested table in table design which is never
mentioned is that all DOM node fetching and manipulation (insert,
delete, replace, remove,etc) are more complex, longer since the dom tree
of nodes is deep. E.g. trying to print a selection in a nested table
will usually fail and make the application crash on most browsers.
DU
DU wrote: Spartanicus wrote:
no mention of certain issues that make table based layouts so
author friendly:
Intuitive grid type visualization.
If you need to visualize elements as you're building your page, then
it means you're mostly building a site in a WYSIWYG interaction mode
which is not best for design to begin with.
There's no reason why someone can't code proper html (4/strict, using
elements as they are intended). Then layout the presentation using a
grid. If you ask me, this is the best way forward for the layperson html
author. But it cannot go in this direction because MSIE/Win does not
support css table-like presentation.
Obviously, there are other ways to shrink to fit and expand when
needed besides wrapping content with a <table width="100%" ...>.
Of course:
display: table; width: 100%; /* etc */
That's sort of the point, I think.
Intuitive hor/ver centering of *all* elements (block/inline).
Don't know what you're talking about here. Are you saying that
centering a table within its parent element should also center its
content?
It's a trivial matter, using table cells, to center things horizontally
and vertically. The vertical thing is especially desirable, as a glance
through the archives shows. If css tables were implemented -- really, if
they were implemented some time ago -- it would be an alternative to
what we see today. I imagine that it would be *easier* to program a
wysiwyg application to code real content, put all blocks in display:
table-cell, and let the user push blocks around to their hearts' content.
But this is a different issue (ease of implementation versus best
practice for the avg author).
I think you missed Spartanicus' point: that css as currently implemented
is hard. I'd have to agree. Floats are tricky stuff. I used to use them
only occasionally, to flow text around a <p> text. Now I use them for
nav bars, div elements, all kinds of stuff. Browsers are buggy with
floats, it can unintended consequences, etc.
IMO, using table layout for rendering non-tabular data is wrong, bad,
nightmare to upgrade, makes parsing, rendering longer, make files
bigger, etc...
Who are you arguing with here? Spartanicus specifically stated that he
was opposed to table for layout.
One disadvantage of using nested table in table design which is never
mentioned is that all DOM node fetching and manipulation (insert,
delete, replace, remove,etc) are more complex, longer since the dom
tree of nodes is deep.
Indeed. Now suppose web authors -- not just (would be?) professionals
here, but your aunt who posts her favorite recipes on her site -- used
simple html, and used css tables to lay it out as they do now with real
tables? They get the layout they want, html file sizes shrink, surfers
have more flexibility. The more I think about it, the more I realize
that css tables could be quite a nice solution. Shame that MSIE/Win
doesn't support them.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Neal wrote: Patrick Griffiths weighs in on the CSS vs table layout debate in his
blog entry "Tables my ass" -
http://www.htmldog.com/ptg/archives/000049.php . A quite good article.
It is useful for exploring the matter, but misses a few points.
1. It ignores the fact that use of layout tables can be compliant. It says,
for example: "Despite the fact that pioneers have been talking about web
standards for a long time, the majority of web sites are still developed using
tables and non standards compliant code. Because of this, user agents will be
forced to handle table based layouts for many years to come. This effectively
negates one of the biggest selling points for web standards. That of forward
compatibility. It's highly unlikely that in the near future, any of the big
browser manufacturers (um, that'll be Microsoft then) will release a browser
that renders the majority of sites unusable".
It is possible to use layout tables in *valid* HTML 4.01 Strict, XHTML 1.0
Strict, and XHTML 1.1. According to current proposals, they will also be valid
in XHTML 2.0. How can it be otherwise? *Tables* have to be supported. And
there is no robust way of distinguishing between layout tables & other sorts.
They will be valid (in the W3C sense) for decades to come.
Use of layout tables is *not* about compliance or non-compliance. It is *not*
about HTML 3.2 or later. It is *not* about DTP-like design or other types of
design. It is *easy* to provide counter-examples! Search elsewhere for
arguments that will stand up to scrutiny.
2. It misses the point when it talks about browser-support, although it gets
close. "When the browser manufacturers finally get their act together,
developing sites using CSS will get a lot easier. Still, I think most people
would agree that CSS development has a much higher barrier to entry than table
based design. In an odd way, I think this is one reason why CSS based design
is becoming so "popular" amongst web professionals. It allows them to
differentiate themselves from the amateur "FrontPage Cowboys" and take back
the web for themselves. Perhaps this is why many people see web standards as
"Ivory Tower" and why many web standards advocates come across as having a
sense of superiority and a zealous attitude towards web design."
It isn't about browsers, it is about authoring tools! *That* is the key issue.
When authoring tools enable people to develop tableless-layouts that are
robust cross-browser, people will use them, and that will be the future. Until
then, it won't be. Authors will do what works, (which layout-tables
*certainly* do), within the project constraints of cost, risk, and time. I use
Dreamweaver MX2004. It is so good with CSS2 that I am able to make sensible
choices according requirements, skills, target-audience, etc. (I even suspect
that it would be possible to use it to develop a rather poor tableless-layout
*easier* than a good table-layout).
3. *Obviously*, this is not about tables versus CSS! Every experienced user of
layout-tables *also* uses CSS! It would be stupid not to. Indeed, many
experienced authors use a whole range of layout-techniques, (absolute
positioning, floats, tables, normal flow, others). They all play their part,
either separately or in combination.
But the article gets this right: "We need to be honest and up-front about the
benefits as well as the cost. Developing CSS sites can be hard and it can time
consuming. In certain circumstances using tables for layout can make much more
sense than CSS".
4. That is really the point. *Why* should an author use one method or another
for the next page? Hopefully, not just because someone a newsgroup said
"table-layout is bad". Only a gullible idiot would fall for that one! Proper
decisions need better analysis.
I believe anti-table arguments are futile. The web appears to be 99% dominated
by table-layout, so there is no obviously no credibility in a position that
they don't work! And, of course, you can't even use more esoteric arguments
such as "separate content from presentation". Because using tables still
allows massive presentational variations using CSS as well. (I can switch left
& right columns of a table-layout, just using CSS). Tables simply set the
default layout in the absence of CSS. But so does all other mark-up!
Arguments should instead say why tableless-layout is good. What are the
specific advantages, that will stand up to scrutiny? The "anti-layout-table"
argument is discredited. What is needed is a credible "pro-tableless-layout"
argument.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Spartanicus wrote: Neal <ne*****@yahoo.com> wrote:
Patrick Griffiths weighs in on the CSS vs table layout debate in his
blog entry "Tables my ass" -
http://www.htmldog.com/ptg/archives/000049.php . A quite good article.
I disagree. A flimsy article, no mention of certain issues that make
table based layouts so author friendly:
Intuitive grid type visualization.
Shrink to fit and expand when needed behaviour/options.
Intuitive hor/ver centering of *all* elements (block/inline).
No mention of the fact that css itself contains a method to replace
html tables used for layout (css tables), but that they are not
supported by IE.
IE doesn't really allow you to start with non-tables and turn them into
something like tables. But it does allow you to start with tables and turn
then into non-tables. Here are some examples of use of valid CSS2, supported
by IE 5 & 6, to transform table-layouts by using CSS. They all use exactly the
same simple layout table.
http://www.barry.pearson.name/articl.../exhibit04.htm
http://www.barry.pearson.name/articl.../exhibit05.htm
http://www.barry.pearson.name/articl.../exhibit07.htm
Note that I'm no apologist for table layouts (I plonked B. Pearson
months ago),
Chuckle! I don't believe that for a second. I believe you are reading this,
but now you can't respond! (Your problem, not mine).
I never advise their use for layout purposes, and I've
mastered the skill to use css exclusively for layout years ago. But
the fact remains that using css for layout in practice throws up mayor
obstacles for the average author.
[snip]
They throw up obstacles for lots of experienced, professional, authors. It
often comes down to "what is the most effective way of developing my next
page?" If you do this for a living, you can't afford to ignore practical
issues in favour of pedantic purist policies that don't matter to the target
audience.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson wrote: Spartanicus wrote:
Neal <ne*****@yahoo.com> wrote:
Patrick Griffiths weighs in on the CSS vs table layout debate in his
blog entry "Tables my ass" -
http://www.htmldog.com/ptg/archives/000049.php . A quite good article.
I disagree. A flimsy article, no mention of certain issues that make
table based layouts so author friendly:
Intuitive grid type visualization.
Shrink to fit and expand when needed behaviour/options.
Intuitive hor/ver centering of *all* elements (block/inline).
No mention of the fact that css itself contains a method to replace
html tables used for layout (css tables), but that they are not
supported by IE.
IE doesn't really allow you to start with non-tables and turn them into
something like tables. But it does allow you to start with tables and turn
then into non-tables. Here are some examples of use of valid CSS2, supported
by IE 5 & 6, to transform table-layouts by using CSS. They all use exactly the
same simple layout table.
http://www.barry.pearson.name/articl.../exhibit04.htm
http://www.barry.pearson.name/articl.../exhibit05.htm
http://www.barry.pearson.name/articl.../exhibit07.htm
Note that I'm no apologist for table layouts (I plonked B. Pearson
months ago),
Chuckle! I don't believe that for a second. I believe you are reading this,
but now you can't respond! (Your problem, not mine).
I just thought I'd reply here, now he can ;-) (only if he
wants to of course) I never advise their use for layout purposes, and I've
mastered the skill to use css exclusively for layout years ago. But
the fact remains that using css for layout in practice throws up mayor
obstacles for the average author.
[snip]
They throw up obstacles for lots of experienced, professional, authors. It
often comes down to "what is the most effective way of developing my next
page?" If you do this for a living, you can't afford to ignore practical
issues in favour of pedantic purist policies that don't matter to the target
audience.
Nah, I'll stay out of this thread now.
--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -
Barry Pearson wrote: IE doesn't really allow you to start with non-tables and turn them into
something like tables. But it does allow you to start with tables and turn
then into non-tables.
Exactly the opposite of what is desired, in this case, and it's hard to
imagine a practical use.
If you do this for a living, you can't afford to ignore practical
issues in favour of pedantic purist policies that don't matter
Anxious anchors alliterate when placed in powerful posts.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Barry Pearson wrote: It is possible to use layout tables in *valid* HTML 4.01 Strict,
XHTML 1.0 Strict, and XHTML 1.1.
You do know the meaning of "valid" in terms of HTML, right?
Use of layout tables is *not* about compliance or non-compliance.
And you know that a valid document may still violate the standard, right?
http://www.cs.tut.fi/~jkorpela/html/...tion.html#good
Search elsewhere for arguments that will stand up to scrutiny.
About table layouts, there are plenty that don't stand up to scrutiny.
Just seach Google Groups for "Barry Pearson table layout." You might
optionally want to include "inter alia" or "let the courts and
marketplace decide."
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
On Tue, 18 May 2004 08:26:45 +0100, Spartanicus <me@privacy.net> wrote: Neal <ne*****@yahoo.com> wrote:
Patrick Griffiths weighs in on the CSS vs table layout debate in his
blog
entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php
. A
quite good article.
I disagree. A flimsy article, no mention of certain issues that make
table based layouts so author friendly:
Well, it's the other side of the coin, and he has linked to his opponent's
arguments. I don't expect
anyone to spend a lot of time defending what they think isn't right.
By "quite good", look at the discussion it has raised. Indeed, that's the
sign of a good article.
Neal wrote: By "quite good", look at the discussion it has raised. Indeed, that's
the sign of a good article.
George W. Bush's argument for invading Iraq has raised quite a lot of
discussion, but even elite opinion does not regard it as a "good
argument." ;-)
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
On Tue, 18 May 2004 16:35:30 -0400, Brian
<us*****@julietremblay.com.invalid> wrote: Neal wrote:
By "quite good", look at the discussion it has raised. Indeed, that's
the sign of a good article.
George W. Bush's argument for invading Iraq has raised quite a lot of
discussion, but even elite opinion does not regard it as a "good
argument." ;-)
But it would have made a great article! Would've been less deadly too.
Arne wrote: Spartanicus wrote:
Also, first thing I had to do to be able to read the article was to
disable his stylesheets (micro fonts).
But why disable it, if the font-size is the only problem? At least he
use percent for font-size, easy to resize even in IE :-)
Um, did you actually change the text size? If you did, you would have
noticed that the side columns widened proportionately, leaving less and
less room for the content. For me, by the time the text size was
readable, there was only one word per line in the content column. :-(
Disabling stylesheets is indeed the best alternative at a site like this.
--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
kchayka wrote: Arne wrote:
Spartanicus wrote:
Also, first thing I had to do to be able to read the article was to
disable his stylesheets (micro fonts).
But why disable it, if the font-size is the only problem? At least he
use percent for font-size, easy to resize even in IE :-)
Um, did you actually change the text size? If you did, you would have
noticed that the side columns widened proportionately, leaving less and
less room for the content. For me, by the time the text size was
readable, there was only one word per line in the content column. :-(
Disabling stylesheets is indeed the best alternative at a site like this.
Well, if you have that big problem to read that text, I do understand
that disabling stylesheets is an alternative. The text is'nt big,
similar to 12px as original (100%) I guess? But I have no problem with
that on my 17 inch screen and 1024x768 resolution.
I resized the text to 200 percent, and certanly the columns widened.
But there was still more than one word per line! :-)
Since there is a very large number of sites out there with that text
size (and even smaller!) for content, you must have really big
problems when surfing?
--
/Arne
URL: http://www.pajala.tk
------------------------------------------
Get your personal ad free domain and email
account for free at http://www.dot.tk
------------------------------------------
On Tue, 18 May 2004 16:24:50 -0500, kchayka <us****@c-net.us> wrote: Um, did you actually change the text size? If you did, you would have
noticed that the side columns widened proportionately, leaving less and
less room for the content. For me, by the time the text size was
readable, there was only one word per line in the content column. :-(
Disabling stylesheets is indeed the best alternative at a site like this.
He apparently uses font-size: 77% which I think is absolutely stupid.
Well, I'm not touting this CSS as ideal, and it's a shame as he's rather
committed to standards otherwise.
Spartanicus wrote: Note that I'm no apologist for table layouts (I plonked B. Pearson
months ago), I never advise their use for layout purposes, and I've
mastered the skill to use css exclusively for layout years ago. But the
fact remains that using css for layout in practice throws up mayor
obstacles for the average author.
Maybe the average author that hasn't been keeping up to date and still views
each tag as a "command" the way browsers of years past have. Anyone who
doesn't know CSS by now and isn't learning it, should stick to just HTML
and have someone else handle CSS. That, I suspect, by the definition of
"designer" in CSS level 1, may well be what the members of the W3C who made
that standard had in mind to begin with.
Also, first thing I had to do to be able to read the article was to
disable his stylesheets (micro fonts).
Agreed, micro fonts suck. (I'm about to go back to making my minimum and
medium font sizes the same just to make sure the bulk of text on Web sites
is readable, but this plays havoc with testing my own content.)
--
Shawn K. Quinn
Barry Pearson wrote: They throw up obstacles for lots of experienced, professional, authors. It
often comes down to "what is the most effective way of developing my next
page?" If you do this for a living, you can't afford to ignore practical
issues in favour of pedantic purist policies that don't matter to the
target audience.
The only practical issue I see, is that structural markup with a clear
separation of presentation and content is how to make documents for the Web
with an eye on the future. Layout is, and always was, part of presentation,
not content, and as such belongs in CSS, not HTML.
If you really *need* pixel perfect layout, you should be using PDF, not HTML
and CSS. You can't expect <table> and similar elements to be a "layout box
command" forever, any more than you can realistically expect <blockquote>
to be an "indent command".
--
Shawn K. Quinn
On Tue, 18 May 2004 23:41:50 -0500, Shawn K. Quinn
<sk*****@xevious.kicks-ass.net> wrote: You can't expect <table> and similar elements to be a "layout box
command" forever, any more than you can realistically expect <blockquote>
to be an "indent command".
We might include <p> as a "blank space" command.
Well put. Damn well put. But there's one catch. All graphic browsers will
allow us to emulate the double-spacing of <p> and the indentation of
<blockquote> using CSS. But the most popular browser has no support for
CSS's inherent replacements for <table>.
Still, for me it comes down to the screwdriver analogy Patrick used in the
article. HTML as a presentational device is like using a hand screwdriver.
Sure, the electric screwdriver we have to work with right now cannot fully
replace the hand screwdriver, but it's not a fault of the tool, but of the
material we have to work with. Sooner than later, and mark my words, most
web users will be using a browser which supports CSS fully, and the idea
of using table for layout will be as queer as using your sleeve for wiping
your nose.
Neal wrote: Sooner than later,
and mark my words, most web users will be using a browser which supports
CSS fully, and the idea of using table for layout will be as queer as
using your sleeve for wiping your nose.
lol
You know how many actually do that? ;-)
--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -
On Wed, 19 May 2004 16:38:20 +0200, Els <el*********@tiscali.nl> wrote: Neal wrote: Sooner than later, and mark my words, most web users will be using a
browser which supports CSS fully, and the idea of using table for
layout will be as queer as using your sleeve for wiping your nose.
lol
You know how many actually do that? ;-)
*snif* Pardon?
Neal wrote: the most popular browser has no support for CSS's inherent
replacements for <table>.
That's the key. We needed css table presentation, in an easily usable
form, but we didn't get it.
Sooner than later, and mark my words, most web users will be using a
browser which supports CSS fully,
I don't see any reason to write off MS. They settled the lawsuit brought
by the U.S. government, on rather good terms for MS. They were not able
to settle the case in Europe, but I doubt that will be a significant
hindrance. Unless Linux/Unix starts making inroads into the home pc
market, we'll be stuck with Windows, which necessarily includes that OS
component that doesn't even pretend to be a web browser.
and the idea of using table for layout will be as queer as using your
sleeve for wiping your nose.
I understand the desire, but I don't think that's a realistic
prediction. We won't see a new version of MSIE until "Longhorn,"
promised in 2007. That means perhaps 2008, with users gradually moving
to the new version in 2010 or later. You'd do well to realize that there
will be no practical use for css table presenation until then at the
earliest.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
On Wed, 19 May 2004 11:33:53 -0400, Brian
<us*****@julietremblay.com.invalid> wrote: I don't see any reason to write off MS. They settled the lawsuit brought
by the U.S. government, on rather good terms for MS. They were not able
to settle the case in Europe, but I doubt that will be a significant
hindrance. Unless Linux/Unix starts making inroads into the home pc
market, we'll be stuck with Windows, which necessarily includes that OS
component that doesn't even pretend to be a web browser.
My gut instinct tells me that MS will lose its hold on the browser market
within 5 years. This will happen through word-of-mouth and organized
campaigns informing the public of better options available, coupled with
further delays in the readiness of Longhorn - I suspect it's closer to 10
years away. The way things are going, people are slowly trickling away
from IE toward alternative browsers. If each of us gets 3 people a year to
use Mozilla or Opera, and each of them does as well, hold on to your hat,
because that trickle will become a torrent.
IE will be the Netscape 4 of the WWW in 10 years, and Longhorn will have
to provide complete support for W3C standards to be at all competitive.
Neal wrote: My gut instinct tells me that MS will lose its hold on the browser
market within 5 years.
Well, I'm no business analyst. But when I listen to or read business
analysts, none seem to indicate that MS is in trouble. Maybe you know
something they don't, but just aren't sharing it with us.
This will happen through word-of-mouth and organized campaigns
informing the public of better options available,
Note that this is not how Netscape lost their dominance. It was through
illegal business practices committed by MS.
The way things are going, people are slowly trickling away from IE
toward alternative browsers.
I can only imagine this happening on alternative browsing devices, and
only because MS doesn't have anything for those devices. But that's not
to say that they won't announce some vaporware, or buy out a competitor,
or who knows what else?
If each of us gets 3 people a year to use Mozilla or Opera, and each
of them does as well, hold on to your hat, because that trickle will
become a torrent.
lol Neal, what are you smoking down there in Springfield? How many of
"us" do you think there are?
I've installed Mozilla or Firefox for several family members. They all
liked it at first, but each of them has gone back to MSIE 6/Win because
more sites work with it. You underestimate MSIE's hold on the market.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
On Wed, 19 May 2004 16:24:06 -0400, Brian
<us*****@julietremblay.com.invalid> wrote: lol Neal, what are you smoking down there in Springfield?
At the moment, a nice Dominican cigar. Yeah, maybe I overestimate the
possibilities for change and progress - I was so sure the Cuban embargo
would collapse too. Oh well. Dominicans are nice too.
I've installed Mozilla or Firefox for several family members. They all
liked it at first, but each of them has gone back to MSIE 6/Win because
more sites work with it. You underestimate MSIE's hold on the market.
That's just it. What will change the balance is more websites which work
BETTER in a conforming browser. If word gets out that sites are more
usable in alternative browsers, it can happen.
And, to reassure, no I do not have extra info. This is, as I said, just a
gut instinct and has no basis on anything but the possibilities I think
are down the road. As accessibility becomes more important, as security
becomes an even greater concern, and as website design development must
turn to areas of CSS that MS cannot handle properly, I can't imagine that
IE6 will maintain the status it currently holds among users and designers.
At least, not easily. But Gates is one savvy businessman, I wouldn't put
anything past him.
Neal wrote: Patrick Griffiths weighs in on the CSS vs table layout debate
in his blog entry
I just read the articles that prompted Griffiths' response. They might
have made a good point about the difficulties of css for those who just
aren't interested in computers as anything other than utilitarian. But
the authors of those pro-table layout articles decided to include points
that just don't bare the weight. One starts out by comparing those who
advocate web standards with "Communist radicals...[who] wanted to take
over the world and brainwash everybody." I'm not joking. http://www.apcmag.com/apc/v3.nsf/0/a...256e5f001a59c5
I guess that's the blog version of a shock jock, and clearly doesn't
warrant being taken seriously.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
"Brian" <us*****@julietremblay.com.invalid> wrote in message
news:10*************@corp.supernews.com... Neal wrote:
Patrick Griffiths weighs in on the CSS vs table layout debate
in his blog entry
I just read the articles that prompted Griffiths' response. They might
have made a good point about the difficulties of css for those who just
aren't interested in computers as anything other than utilitarian. But
the authors of those pro-table layout articles decided to include points
that just don't bare the weight. One starts out by comparing those who
advocate web standards with "Communist radicals...[who] wanted to take
over the world and brainwash everybody." I'm not joking.
Yeah, just like those crazies who think that each phone company should use
its own telephony protocol.
Shawn K. Quinn wrote: Barry Pearson wrote:
They throw up obstacles for lots of experienced, professional,
authors. It often comes down to "what is the most effective way of
developing my next page?" If you do this for a living, you can't
afford to ignore practical issues in favour of pedantic purist
policies that don't matter to the target audience.
The only practical issue I see, is that structural markup with a clear
separation of presentation and content is how to make documents for
the Web with an eye on the future. Layout is, and always was, part of
presentation, not content, and as such belongs in CSS, not HTML.
No it wasn't! Layout became within the scope of CSS (jointly with HTML),
rather than specifically HTML, in 1997/8. (Specifically, with HTML 4 in
December 1997, and CSS2 in May 1998). Up to that point, pretty well all the
key documents, published by the major players, starting in 1989, placed layout
within the scope of HTML. (The exceptions were some proposals to put "columns"
into stylesheets for layout purposes). I would be interested to see evidence
to the contrary, using documents published *before* April 1997. I haven't
managed to track any such evidence down for my page:
"A brief history of tables"
http://www.barry.pearson.name/articl...es/history.htm
Besides, who says that tables don't permit separation of presentation &
content? Here is a page that uses a simple layout table. I'm talking here
about the outer-level 1-row 2-column table, which puts the site navigation on
the right. I wanted "industrial strength", and a no-CSS default of 2 columns.
http://www.childsupportanalysis.co.uk/
Here is essentially the same page, certainly an identical <body>, but with 2
extra CSS rules. They put the site navigation (2nd table column) on the
left. I've embedded them for demonstration purposes, but they simply override
2 existing rules in the CSS, and I could have modified the external CSS
instead.
http://www.childsupportanalysis.co.uk/reversed.htm
Table mark-up sets the default layout in the absence of contrary CSS. But the
same is true of non-table mark-up. Then you can apply CSS to change things
considerably, for tables and non-tables.
If you really *need* pixel perfect layout, you should be using PDF,
not HTML and CSS. You can't expect <table> and similar elements to be
a "layout box command" forever, any more than you can realistically
expect <blockquote> to be an "indent command".
If you want pixel perfect layout, CSS is the way to go! It gets better at
pixel-perfection with each generation.
Tables have *never* been good at pixel perfection. They were & are intended to
adapt to the users' viewing conditions, such as text size & viewport width,
and optimise for that. In that sense, they conform to the "adapt to the user"
ethos of the web. Create a simple table with no attributes, put stuff in, and
view it under a large range of conditions, and what happens? The cells will
expand & contract according to the content & text size, and attempt to use as
much of the viewport as is useful to reduce vertical scrolling, while also
trying to avoid horizontal scrolling. Wonderful.
Experienced authors of tables all know this, and don't try to use them as a
"layout box command". They just use them to place complex material in rows &
columns. In fact, typically, such authors use very few, if any, controls on
the widths & heights of tables & cells, either via attributes or CSS. The only
remotely reliable way to control the sizes of table cells is to control the
*contents*, not the table elements themselves. Spacer-GIFs were the
last-century way of controlling the content. Now, if that degee of control of
the minimum width is needed, spacer-divs might be used. But, to achieve
maximum width, you had better wrap up the contents of table cells in (say)
<div>s, then use CSS to control the size of those <div>s. The table will adapt
to that:
<td>
<div class="width1">
Content goes here
</div>
</td>
div.width1 {
width: 300px;
overflow: auto;
}
As the CSS1 recomendation said: "We expect to see extensions of CSS in several
directions:
.....
fonts: more precise font specification systems are expected to complement
existing CSS1 font properties.
values, properties: we expect vendors to propose extensions to the CSS1 set of
values and properties. Extending in this direction is trivial for the
specification, but interoperability between different UAs is a concern.
layout language: support for two-dimensional layout in the tradition of
desktop publishing packages."
Tables are inherently flexible in size, and can only be controlled unreliably
& with difficulty. CSS offers "px" values for just about everything, and if
the user has CSS enabled, these rules typically work.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Neal wrote:
[snip] We might include <p> as a "blank space" command.
[snip]
Quite. And that is how key documents from all the major players wrote about
<p> right up to February 1997.
Tim Berners-Lee, Daniel Connolly, Dave Raggett, & probably others, all wrote
in those terms from 1993, (if not earlier), until February 1997. Paragraph
mark-up was intended to be used to achieve the typical rendering of a new
line. "Paragraph break" was pretty well synonymous with "line break" until
February 1997. You got a "paragraph break" between block-level elements up to
that time - even between (say) an <h1> and an <h2>.
The first significant published document, that I know of, to counter this, was
the HTML 4 recommendation in December 1997. That recommendation introduced
semantic mark-up rather than presentational mark-up, and used "line break"
instead of "paragraph break" between block-level elements. If there were key
published documents before this that did the same, I haven't found them. I
would welcome references.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Brian wrote: Barry Pearson wrote:
It is possible to use layout tables in *valid* HTML 4.01 Strict,
XHTML 1.0 Strict, and XHTML 1.1.
You do know the meaning of "valid" in terms of HTML, right?
I go by what W3C says. I've made pages using simple layout tables, put various
DOCTYPES in, made tactical adjustments such as " />" closures, and they
validate at W3C. Including XHTML1.1. (And why not? Why shouldn't table-layout
pages validate? They use bog-standard (X)HTML!) Use of layout tables is *not* about compliance or non-compliance.
And you know that a valid document may still violate the standard,
right?
http://www.cs.tut.fi/~jkorpela/html/...tion.html#good
[snip]
I've read that. I don't believe it applies here. Simple layout tables use a
subset of data-table mark-up. The differences are mainly in the minds of
humans, not something that technology can distinguish.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
On Thu, 20 May 2004, Barry Pearson wrote: We might include <p> as a "blank space" command.
Quite. And that is how key documents from all the major players
wrote about <p> right up to February 1997.
Hmmm? <p> , what had originally been a paragraph break - analogous to
<br> as a line break - was SGML-ified as a paragraph container in the
run-up to drafting the first formal specification of HTML as an
application of SGML, and that was finalised (as RFC1866) by November
1995. So the change in the specification can be traced to some time
before that.
Some of us already had documents marked-up according to the old style,
and didn't bother to change them, since they weren't actually invalid
according to RFC1866.
Tim Berners-Lee, Daniel Connolly, Dave Raggett, & probably others,
all wrote in those terms from 1993, (if not earlier), until February
1997.
We'll need a citation if you're to stand any chance of defending that.
Paragraph mark-up was intended to be used to achieve the typical
rendering of a new line.
No, of a new *paragraph* (not surprisingly).
"Paragraph break" was pretty well synonymous with "line break" until
February 1997.
No. It was typically rendered as a paragraph break, not surprisingly.
You got a "paragraph break" between block-level elements up to
that time - even between (say) an <h1> and an <h2>.
I disagree. There was, and still is, a natural vertical gap between
H1 and H2 elements. You only see the rendered result. Interpret it
as you will, there was nothing more to it than a gap.
The first significant published document, that I know of, to counter
^^^^^^^^^^^ this, was the HTML 4 recommendation in December 1997.
That's easily done: just apply your personal criterion of
insignificance to all the significant discussions and documents which
went before.
That recommendation introduced
semantic mark-up rather than presentational mark-up,
No, it didn't "introduce" it; it *reinforced* the earlier plan of
logical/structural markup. Which pre-dated the - finally unsuccessful
- attempt by the "big two" graphical browsers to turn HTML into a
WYSIWYG presentation language.
The Hypertext Markup Language (HTML) is a simple markup language used
to create hypertext documents that are platform independent. HTML
documents are SGML documents with generic semantics that are
appropriate for representing information from a wide range of
domains. HTML markup can represent hypertext news, mail,
documentation, and hypermedia; menus of options; database query
results; simple structured documents with in-lined graphics; and
hypertext views of existing bodies of information.
That's RFC1866 from 1995. Which goes on to several times mention the
use of style sheets to influence the details of the presentation.
If, as you claim, HTML had been meant to specify the presentation, at
that point in history, why would they have been talking about style
sheets, riddle me that?
Barry Pearson wrote: No it wasn't!
It was only a matter of time before you chimed in with your exclamatory
remarks. ("No it wasn't!" "Gosh!" "Chuckle!" etc.)
I would be interested to see evidence to the contrary
You've been give the links, over and over and over again. I'm sure you
know that most of the regulars have given up on you.
I haven't managed to track any such evidence down for my page:
"A brief history of tables"
Any excuse to plug that thing, eh?
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Barry Pearson wrote: I've made pages using simple layout tables, put various DOCTYPES in,
made tactical adjustments such as " />" closures, and they validate
at W3C. Including XHTML1.1. (And why not? Why shouldn't table-layout
pages validate?
There's no "should" about it. They *must* validate if they do not
violate the syntax of the language. (You apparently do not understand
what "valid" means in this context.)
Simple layout tables use a subset of data-table mark-up. The
differences are mainly in the minds of humans, not something that
technology can distinguish.
Exactly the point. Since a validator can only check the syntax of a
document, you can only guarantee that a valid document is correct in its
syntax. Whether the document is correct in any other sense cannot be
judged by validating it. So the fact that you've successfully validated
table layout documents says exactly nothing about the appropriateness of
tables used for layout.
Several other examples of incorrect html are on this page, which is
valid html 4.01/strict. http://www.julietremblay.com/test/valid
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Alan J. Flavell wrote: On Thu, 20 May 2004, Barry Pearson wrote:
> We might include <p> as a "blank space" command.
Quite. And that is how key documents from all the major players
wrote about <p> right up to February 1997.
Hmmm? <p> , what had originally been a paragraph break - analogous to
<br> as a line break - was SGML-ified as a paragraph container in the
run-up to drafting the first formal specification of HTML as an
application of SGML, and that was finalised (as RFC1866) by November
1995. So the change in the specification can be traced to some time
before that.
The last publication I can identify was HTML 3.2, in January 1997:
http://www.w3.org/TR/REC-html32#level
"Most elements that can appear in the document body fall into one of two
groups: block level elements which cause paragraph breaks, and text level
elements which don't. Common block level elements include H1 to H6 (headers),
P (paragraphs) LI (list items), and HR (horizontal rules)."
Pretty explicit! I'm not saying that things weren't changing before that. But
HTML 3.2 was a key publication by a major player, which is what I said. An
author can validate against HTML 3.2 - but can an author validate against
RFC1866? (Actually, I have seen pages with an HTML 2.0 DOCTYPE, so perhaps
they could. But that surely became irrelevant with HTML 3.2). My reading is
that all the major players were already thinking of the next stage of the web,
and CSS1 & HTML 3.2 were intended to draw a line under this "first era" so
that they could concentrate on the "second era".
Some of us already had documents marked-up according to the old style,
and didn't bother to change them, since they weren't actually invalid
according to RFC1866.
I suspect that although that document pointed directions to the future, it
wasn't as influential in the immediate development of the web (authors,
authoring tools, browsers, validation, etc) as the later HTML 3.2. And even
that document used terms such as "formatted paragraph style" when talking
about definition lists. This was a document that was laying a basis for later
influential recommendations. But how many people cite that document, rather
than (say) HTML 4, which is the recommendation that explicitly introduced
semantic mark-up to HTML? Do people write "SMGL applications", or "HTML"?
Tim Berners-Lee, Daniel Connolly, Dave Raggett, & probably others,
all wrote in those terms from 1993, (if not earlier), until February
1997.
We'll need a citation if you're to stand any chance of defending that.
These are all, of course, in my page:
"A brief history of tables"
http://www.barry.pearson.name/articl...es/history.htm
Here are some examples. (That pages has dozens of references, including dozens
to documents held at W3C). First, some quotes that illustrate the thinking of
the time:
1993: Tim Berners-Lee, Daniel Connolly, "A Representation of Textual
Information and MetaInformation for Retrieval and Interchange" ( version 1.2)
http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
"Typical rendering is described for many elements. This is not a mandatory
part of the standard but is given as guidance for designers and to help
explain the uses for which the elements were intended". (Hence- presentational
mark-up).
"The elements within the BODY element are in the order in which they should be
presented to the reader". (Hence - layout primarily determined by HTML).
"When writing documents, you should assume that whatever is done it is
designed to have the same sort of effect as the styles above".
Paragraph mark-up was intended to be used to achieve the typical
rendering of a new line.
No, of a new *paragraph* (not surprisingly).
Whether you use Berner-Lee (1993), or Raggett (1997), "paragraph break" was
pretty well synomymous with "line break".
"Paragraph break" was pretty well synonymous with "line break" until
February 1997.
No. It was typically rendered as a paragraph break, not surprisingly.
You got a "paragraph break" between block-level elements up to
that time - even between (say) an <h1> and an <h2>.
I disagree. There was, and still is, a natural vertical gap between
H1 and H2 elements. You only see the rendered result. Interpret it
as you will, there was nothing more to it than a gap.
HTML 3.2, January 1997, (Raggett):
http://www.w3.org/TR/REC-html32#level
"Most elements that can appear in the document body fall into one of two
groups: block level elements which cause paragraph breaks, and text level
elements which don't. Common block level elements include H1 to H6 (headers),
P (paragraphs) LI (list items), and HR (horizontal rules)."
I can't see how that can be interpreted other than to have "paragraph breaks"
between <h1> and <h2>, as I said. Which means "line breaks".
The first significant published document, that I know of, to counter
^^^^^^^^^^^ this, was the HTML 4 recommendation in December 1997.
That's easily done: just apply your personal criterion of
insignificance to all the significant discussions and documents which
went before.
And how would you judge HTML 3.2? See above. I am trying to reveal history,
not rewrite it.
RFC1866 is already in my history, as, HTML 2.0. But I thought that it was
superceded by HTML 3.2. This is common with the web. For example, we are all
familiar with the statement in HTML 4 about layout tables, saying that CSS
should be used for layout. But HTML 4 was December 1997, and CSS2 was May
1998. (And CSS1 wasn't a layout language, and said so). These are indications
of possible future directions, not imperatives to obey at that time. Are we
talking about the history of the web (from 1989), or later specifications (in
which case we should look for what supercedes what, such as HTML 3.2
superceding HTML 2.0).
That recommendation introduced
semantic mark-up rather than presentational mark-up,
No, it didn't "introduce" it; it *reinforced* the earlier plan of
logical/structural markup. Which pre-dated the - finally unsuccessful
- attempt by the "big two" graphical browsers to turn HTML into a
WYSIWYG presentation language.
HTML was proposed as a presentational language before those browser got in the
act! See the quotes from Berners-Lee, that preceded the browser wars.
(Table-layout had taken off by the time of RFC1866). Do you know of a clear
identification that HTML was for semantic mark-up, before the browser wars
started? The first solid indication I saw was the HTML 4 recommendation in
December 1997. Certainly, presentational mark-up was in HTML 3.2 at January
1997.
My history also records what appear to be minority opinions. I am not trying
to say that there was only one view. For example, from 1993 onwards there were
suggestions for "columns" in stylesheets for page layout purposes. In fact,
that appears to be the key page-layout departure from "HTML does layout"
during that time. And look what happened to it! Consigned to CSS3. I can't
discover whether the major players thought tables were sufficient, or whether
they simply didn't understand the importance of page layout. I have spoken to
people who believe that many experts working in these areas are in the latter
category. But until experts properly realise the importance of layout, and
seriously address the topic, they will obviously be bypassed.
The Hypertext Markup Language (HTML) is a simple markup language
used to create hypertext documents that are platform independent.
HTML documents are SGML documents with generic semantics that are
appropriate for representing information from a wide range of
domains. HTML markup can represent hypertext news, mail,
documentation, and hypermedia; menus of options; database query
results; simple structured documents with in-lined graphics; and
hypertext views of existing bodies of information.
That's RFC1866 from 1995. Which goes on to several times mention the
use of style sheets to influence the details of the presentation.
Did it? I've just searched it for various terms, and can't find that. "Layout"
is hardly there. Ditto "style", except to show what "link" can be used for.
Ditto "sheet". Am I looking at the wrong document? I am looking at:
http://www.ietf.org/rfc/rfc1866.txt
I believe that something changed in December 1997 / May 1998. "Layout" was
*not* presentation / style before then. When Tim Berners-Lee & Daniel Connolly
said in 1993: "The elements within the BODY element are in the order in which
they should be presented to the reader", I think this carried forward for
years. What changed before May 1998?
If, as you claim, HTML had been meant to specify the presentation, at
that point in history, why would they have been talking about style
sheets, riddle me that?
I never said that HTML was meant to specify the presentation! Where did you
get that from?
What I am saying is that, before HTML 4 & CSS2, "presentation" was *not*
normally seen to include "layout" ("positioning"). From a very early stage it
was known that we needed stylesheets to change to rendering of elements that
had been laid out ready to be displayed on a screen. That was not in doubt in
1993, and probably earlier. But, until later than Febuary 1997, the assumption
all throughout appears to have been that HTML was responsible for the overall
layout, and stylesheets then changes the details, especially for fonts,
colours, etc. (Except for a couple of far-sighted people who mentioned
"columns"!)
It is too easy to conflate "styles" & "presentation" & "layout", but the
relationship between these has been changing. Instead of just looking for
"presentation" or "styles", and assuming without evidence that they include
layout, try looking specifically for indications that they were talkng about
layout/positioning.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Brian wrote: Barry Pearson wrote:
I've made pages using simple layout tables, put various DOCTYPES in,
made tactical adjustments such as " />" closures, and they validate
at W3C. Including XHTML1.1. (And why not? Why shouldn't table-layout
pages validate?
There's no "should" about it. They *must* validate if they do not
violate the syntax of the language. (You apparently do not understand
what "valid" means in this context.)
[snip]
I'll try to spell it out in even simpler English.
Table-layout pages can validate at W3C with an XHTML 1.0 (Transitional or
Strict) DOCTYPE, or with an XHTML 1.1 DOCTYPE. I have tried those
combinations, and has the "valid" report from W3C.
Have you evidence to the contrary?
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Brian wrote: Barry Pearson wrote:
[snip] I would be interested to see evidence to the contrary
You've been give the links, over and over and over again. I'm sure you
know that most of the regulars have given up on you.
[snip]
I seek evidence to the contrary. Not just unwarranted assertions that it has
been supplied, when it hasn't.
Please supply facts, not spin. And if contrary facts don't exist, of course
people will stop arguing with me!
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
On Thu, 20 May 2004, Barry Pearson wrote: I suspect that although that document pointed directions to the future, it
wasn't as influential in the immediate development of the web (authors,
authoring tools, browsers, validation, etc) as the later HTML 3.2.
Now you're just being silly. If you have the least interest in the
history of HTML, I suggest you start to find something out about it
first. And if you're not interested in its history, it would be nice
if you'd refrain from continuously rewriting it.
Tim Berners-Lee, Daniel Connolly, Dave Raggett, & probably others,
all wrote in those terms from 1993, (if not earlier), until February
1997.
We'll need a citation if you're to stand any chance of defending that.
These are all, of course, in my page:
Very drole. Now how about some citations to authentic original
materials?
1993: Tim Berners-Lee, Daniel Connolly, "A Representation of Textual
Information and MetaInformation for Retrieval and Interchange" ( version 1.2)
http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
1993, yup. I found 1992-3 materials discussing the then-current HTML,
and the forthcoming SGML-ification, which, as we know, was codified in
RFC1866 by late 1995. So what's this nonsense about 1997?
"Typical rendering is described for many elements. This is not a mandatory
part of the standard but is given as guidance for designers and to help
explain the uses for which the elements were intended".
Just so.
(Hence- presentational mark-up).
Exactly wrong, since the only point of inventing HTML originally had
been to make the same information accessible to the then-current
diverse viewing situations. The point of stressing "typical"
rendering was that non-typical renderings could be equally valid.
And how would you judge HTML 3.2? See above.
"See above"? No, see the reactions of the participants when
HTML3.2(spit) was revealed at the time. Then you'd be in no doubt how
we judged HTML3.2(spit) at the time.
RFC1866 is already in my history, as, HTML 2.0. But I thought that it was
superceded by HTML 3.2.
That's factually correct: it was the W3C's unfortunate diversion into
would-be presentational HTML, from which we are now finally
recovering. I suppose one could only conclude that they felt they had
lost the upper ground - to the "big two" - and that their best move
was to simply document some best common factor of what the big two had
already deigned to implement. And they called that HTML3.2 (and we
all wailed about the fact that 3.2 had turned out to be so much less
than 3.0 had promised to be).
As you can read at http://www.w3.org/MarkUp/#previous (and this seems
an accurate verdict to me): HTML3.2 "represented the consensus on HTML
features for 1996": I.e it documented a common subset of the feechers
which the browser vendors had consented to implement at that time.
HTML3.2 "pointed the way"??? Don't be absurd. HTML3.2 rubber-stamped
the past, nothing more. It even did that badly, as your quotation
about block level elements "causing paragraph breaks" indicates. That's RFC1866 from 1995. Which goes on to several times mention the
use of style sheets to influence the details of the presentation.
Did it? I've just searched it for various terms, and can't find that.
Then you seem to have missed the three occurrences of "style sheet"
which I found, then. What do you suppose a style sheet would be for,
if not for influencing the presentation?
Barry Pearson wrote: I'll try to spell it out in even simpler English.
You need to spell it out to yourself. You failed to understand my point,
which can only be because you do not understand what validation means.
Table-layout pages can validate at W3C with an XHTML 1.0 (Transitional or
Strict) DOCTYPE, or with an XHTML 1.1 DOCTYPE. I have tried those
combinations, and has the "valid" report from W3C.
Read this very slowly, Mr. Pearson.
Of - course - it - validates - since - it - does - not - violate - the -
syntax - of - HTML.
Have you evidence to the contrary?
How could I have evidence of something which cannot be?
Your inference that a successfully validated document is correct HTML is
absurd, as the test case I posted shows.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Brian wrote: Barry Pearson wrote:
I haven't managed to track any such evidence down for my page:
"A brief history of tables"
Any excuse to plug that thing, eh?
I just wonder, why he thinks it is good publicity to his page to tell
that he has gotten facts incorrect, and claims that they doin't exist
when they contradict his page?
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
I'm looking for work | Etsin työtä
Alan J. Flavell wrote: On Thu, 20 May 2004, Barry Pearson wrote:
I suspect that although that document pointed directions to the
future, it wasn't as influential in the immediate development of the
web (authors, authoring tools, browsers, validation, etc) as the
later HTML 3.2.
Now you're just being silly. If you have the least interest in the
history of HTML, I suggest you start to find something out about it
first. And if you're not interested in its history, it would be nice
if you'd refrain from continuously rewriting it.
There are over 60 external links on my "history" page. Over 25 of them are to
documents on the W3C site, including the major proposals & recommendations,
plus various discussions/debates in forums. Others are to IETF, academic
organisations, and to histories written by others on various aspects. I think
most of the links discuss the period before February 1997. I have, at some
time or other, read at least most of the content of all of those pages.
Obviously I will have missed some things in the process, because some of it
was highly detailed. That is why I ask for help, and I gradually evolve the
page in the light of comments received. I update it about every week or two.
My style is to quote from the pages using copy & paste, rather than using
paraphrasing, to try to ensure that I am revealing the history as written by
others, and don't inadvertently rewrite it. I also assume that when someone
says something in one of those sources, they wrote what they meant. So I don't
try to retro-fit another interpretation on it. I think some people assume that
the views that have developed since February 1997 (WAI, HTML 4, CSS2, etc)
were the views prevalent before then. In fact, it is sometimes as though they
came from a parallel universe.
>> Tim Berners-Lee, Daniel Connolly, Dave Raggett, & probably others,
>> all wrote in those terms from 1993, (if not earlier), until
>> February 1997.
>
> We'll need a citation if you're to stand any chance of defending
> that.
These are all, of course, in my page:
Very drole. Now how about some citations to authentic original
materials?
The links are on my page, as noted above. That page is now 37 kilobytes, (most
of it the 36-row date-ordered table). The links themselves are really too big
to post here, and anyone with web access to follow up the links could do so
from that page, which sets the context for each of them.
1993: Tim Berners-Lee, Daniel Connolly, "A Representation of Textual
Information and MetaInformation for Retrieval and Interchange" (
version 1.2) http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
1993, yup. I found 1992-3 materials discussing the then-current HTML,
and the forthcoming SGML-ification, which, as we know, was codified in
RFC1866 by late 1995. So what's this nonsense about 1997?
SGML-ification appears not to have changed the intent of the mark-up. The fact
that it presumably provided a sounder basis for a clean separation of various
concerns doesn't mean that people exploited that basis in the proposals &
recommendations for what HTML was for. HTML continued to be defined in terms
of typically rendering, not in terms of the semantics of the elements.
Things changed as a result of events that became public in the 13 months from
May 1997 to May 1998. (We know that those events had a basis in earlier work,
but those are the key dates for things that people now often quote). They
include:
May 1997: WAI launched.
December 1997: HTML 4, with explicit semantics included for some elements, and
references to accessibility, other devices, etc.
May 1998: CSS2, with positioning & aural stylesheets.
"Typical rendering is described for many elements. This is not a
mandatory part of the standard but is given as guidance for
designers and to help explain the uses for which the elements were
intended".
Just so.
The details will obviously vary from one device to another, and from one
browser to another. But some aspects were more explicit. For example:
"The elements within the BODY element are in the order in which they should be
presented to the reader".
"When writing documents, you should assume that whatever is done it is
designed to have the same sort of effect as the styles above".
(Hence- presentational mark-up).
Exactly wrong, since the only point of inventing HTML originally had
been to make the same information accessible to the then-current
diverse viewing situations. The point of stressing "typical"
rendering was that non-typical renderings could be equally valid.
A key phrase there is "to help explain the uses ...". When HTML 4 (December
1997) wants to help explain the uses of "paragraph", it says "Authors
traditionally divide their thoughts and arguments into sequences of
paragraphs", which is surely a good way of introducing semantic mark-up. But
earlier proposals & recommendations (including HTML 2.0) describe it in terms
of the typical rendering, and tend to go into details about the line break (or
"paragraph break"). An example from HTML 2.0: "An HTML user agent should
present the body of an HTML document as a collection of typeset paragraphs and
preformatted text".
Those "diverse viewing situations" appeared, pretty consistently, to be
different types of screen, but on many different end-systems. Berners-Lee &
Raggett mentioned screens a number of times. I'm not criticising anyone for
this. (I was helping to design large-scale computing systems at about that
time, typically for display on screens!) I'm simply commenting that this was
how people appeared to think about the web at that time, at least from what
they *wrote*. (I don't know what their long-term vision for it was at that
time).
And how would you judge HTML 3.2? See above.
"See above"? No, see the reactions of the participants when
HTML3.2(spit) was revealed at the time. Then you'd be in no doubt how
we judged HTML3.2(spit) at the time.
Indeed. But I'm trying to record the facts, not the emotional reactions to
them!
RFC1866 is already in my history, as, HTML 2.0. But I thought that
it was superceded by HTML 3.2.
That's factually correct: it was the W3C's unfortunate diversion into
would-be presentational HTML, from which we are now finally
recovering. I suppose one could only conclude that they felt they had
lost the upper ground - to the "big two" - and that their best move
was to simply document some best common factor of what the big two had
already deigned to implement. And they called that HTML3.2 (and we
all wailed about the fact that 3.2 had turned out to be so much less
than 3.0 had promised to be).
As you can read at http://www.w3.org/MarkUp/#previous (and this seems
an accurate verdict to me): HTML3.2 "represented the consensus on HTML
features for 1996": I.e it documented a common subset of the feechers
which the browser vendors had consented to implement at that time.
Indeed. The period from about 1994 to February 1997 was one where IETF & W3C
were trying retrospectively to get control over a damaging situation. HTML 2.0
(November 1995) represented the situation at about June 1994, and hence was
way behind current thinking. HTML 3.2 was an attempt to draw a line under this
whole period, so that the world could move on. I doubt if HTML 2.0 had much
chance of being credible with browser developers & authors, if only because it
lacked tables, which started to appear in browsers late 1994. 5 months
*before* it formally became a recommendation, Bert Bos (an author of CSS1 & 2)
proposed HTML 2.1 to add tables to 2.0. Subsequent discussion suggested that
because of the progress on 3.0, 2.1 was not the way to go. (Who knows what
would have happened if they had realised that 3.0 was to be replaced by 3.2?)
HTML3.2 "pointed the way"??? Don't be absurd. HTML3.2 rubber-stamped
the past, nothing more. It even did that badly, as your quotation
about block level elements "causing paragraph breaks" indicates.
I didn't mean the whole of HTML 3.2 did that, and I have said somewhere that
it appeared to have been intended to draw a line under that era. (As with
CSS1). But HTML 3.2 includes the statement: "W3C is continuing to work with
vendors on extensions for accessibility features, multimedia objects,
scripting, style sheets, layout, forms, math and internationalization. W3C
plans on incorporating this work in further versions of HTML". That is the
pointer I was referring to. CSS1 Appendix E also has forward pointers. These
authors had no illusions that their documents represented the future. > That's RFC1866 from 1995. Which goes on to several times mention
> the use of style sheets to influence the details of the
> presentation.
Did it? I've just searched it for various terms, and can't find that.
Then you seem to have missed the three occurrences of "style sheet"
which I found, then. What do you suppose a style sheet would be for,
if not for influencing the presentation?
You snipped what I said! I said "I've just searched it for various terms, and
can't find that. "Layout" is hardly there. Ditto "style", except to show what
"link" can be used for".
I was obviously not saying that stylesheets were not mentioned. And obviously
they were for styling things! But there appear to be different views about
what styling means, before & after February 1997. (I'll call these "first era"
& "second era").
First era. HTML was intended for display on screens. HTML defined the overall
layout, and suggested some detailed styling, and provided some attributes to
control it. The realisation was that anything more needed stylesheets. I cite
several proposals for stylesheets from 1993 onwards. Discussion about
stylesheets during this time, except for the occasional mention of "columns",
was about such things as rendering of text, etc.
Second era: HTML was intended for rendering in many, and unlimited, ways,
including adaptive technologies. Elements therefore started to be described in
semantic terms. Stylesheets are now expected to be common, and there was the
intent to undo much of the damage of the extra presentation mark-up. Default
layout on screens was identified by HTML, but now stylesheets could change the
layout too. CSS2 is not a page layout language, (although it is "sort-of" a
viewport layout language if you wanted it), so even with CSS-positioning, it
typically needed some attention to the wrapping & nesting & sequencing of the
top-level of the document tree. (So, except for fairly simple pages, with
perhaps 3 or 4 key units, it hasn't yet separated layout from mark-up).
The topic about use of tables for layout is totally different from the topic
of whether or not to use CSS. At least, it was before February 1997. Now there
is some overlap, but most of the table-layout pages being put on the web each
day, (at least, from the on-line news services), uses CSS, often vast amounts
of it.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
On Fri, 21 May 2004, Barry Pearson wrote: 1993, yup. I found 1992-3 materials discussing the then-current HTML,
and the forthcoming SGML-ification, which, as we know, was codified in
RFC1866 by late 1995. So what's this nonsense about 1997?
SGML-ification appears not to have changed the intent of the mark-up.
Neat swerve :-}
The details will obviously vary from one device to another, and from
one browser to another. But some aspects were more explicit. For
example: "The elements within the BODY element are in the order in
which they should be presented to the reader".
Right, so they hadn't yet come up with the idea of a stylesheet which
can re-arrange the sequence of the content. But - to take an example
- an audio browser which reads-out the content in the sequence in
which it appears in the markup is still a perfectly valid "rendering"
in accordance with the spirit of the specification.
Those "diverse viewing situations" appeared, pretty consistently, to be
different types of screen,
Those *were* the practical rendering platforms at that time, so I
don't find it surprising that effort was concentrated on those,
although I recall attending a presentation at CERN where an early
speaking browser was presented. It particularly stuck in one's mind,
as it desperately tried to pronounce IBM as a word "ibbum", and its
best effort at pronouncing Pisa sounded like "pisser". Ho hum. And how would you judge HTML 3.2? See above.
"See above"? No, see the reactions of the participants when
HTML3.2(spit) was revealed at the time. Then you'd be in no doubt how
we judged HTML3.2(spit) at the time.
Indeed. But I'm trying to record the facts, not the emotional reactions to
them!
The facts were what they were: HTML3.2 effectively rubber-stamped what
the graphical browsers (chiefly the "big two") had deigned to
implement. Note that client-side imagemaps and tables had already
been introduced via RFCs, prior to HTML3.2 (and HTML3.2 only contained
cut-down versions of both, limited more-or-less to what the big two
had deigned to implement).
Indeed (and I presume you can find this in the historical record), if
Netscape hadn't at the last minute implemented the proposed Latin-1
character entities from RFC1866, they would not have been included in
HTML3.2.
(And history repeated itself when Netscape omitted to implement the
character entities which were introduced in HTML4).
Alan J. Flavell wrote: On Fri, 21 May 2004, Barry Pearson wrote:
> 1993, yup. I found 1992-3 materials discussing the then-current
> HTML, and the forthcoming SGML-ification, which, as we know, was
> codified in RFC1866 by late 1995. So what's this nonsense about
> 1997?
SGML-ification appears not to have changed the intent of the mark-up.
Neat swerve :-}
I'm playing it straight. In fact, my initial test now, when looking at an
older proposal, is to examine "paragraph". ("Table" comes later). I'm coming
to the conclusion that the way a mark-up proposal deals with "paragraph" is
telling. In the non-HTML world, "paragraph" was an early example of mark-up,
(it originally meant "a small mark indicating a change in sense"). It is
fundamental to HTML. If someone talks about "paragraph breaks", that is
indicative. People can be allowed a slip of the pen when discussing tables or
forms, but surely not "paragraph"?
The details will obviously vary from one device to another, and from
one browser to another. But some aspects were more explicit. For
example: "The elements within the BODY element are in the order in
which they should be presented to the reader".
Right, so they hadn't yet come up with the idea of a stylesheet which
can re-arrange the sequence of the content. But - to take an example
- an audio browser which reads-out the content in the sequence in
which it appears in the markup is still a perfectly valid "rendering"
in accordance with the spirit of the specification.
Yes, but I simply don't think that was in their minds at the time. They had
screen readers, (eg. IBM's Screen Reader/2 in 1992), and the statements in
HTML 4 in December 1997 about layout tables was half based on screen readers.
But speaking browsers are a vastly different concept, and so far I haven't
found a good reference before the announcement in 1998 of IBM's HPR. I think
the pre-February-1997 views were based on not resequencing on screens, hence
not resequencing with screen-readers either.
Those "diverse viewing situations" appeared, pretty consistently, to
be different types of screen,
Those *were* the practical rendering platforms at that time, so I
don't find it surprising that effort was concentrated on those,
although I recall attending a presentation at CERN where an early
speaking browser was presented. It particularly stuck in one's mind,
as it desperately tried to pronounce IBM as a word "ibbum", and its
best effort at pronouncing Pisa sounded like "pisser". Ho hum.
Was it a genuine browser rather than screen reader? Have you a date and/or
reference? (I don't really believe that IBM's HPR simply came into being in
1998!)
[snip] The facts were what they were: HTML3.2 effectively rubber-stamped what
the graphical browsers (chiefly the "big two") had deigned to
implement. Note that client-side imagemaps and tables had already
been introduced via RFCs, prior to HTML3.2 (and HTML3.2 only contained
cut-down versions of both, limited more-or-less to what the big two
had deigned to implement).
Indeed (and I presume you can find this in the historical record), if
Netscape hadn't at the last minute implemented the proposed Latin-1
character entities from RFC1866, they would not have been included in
HTML3.2.
No, I didn't know that. Have you a reference? (I may be able to find it).
(And history repeated itself when Netscape omitted to implement the
character entities which were introduced in HTML4).
Chuckle! Welcome to the real world. I spent many years helping to design &
develop a mainframe operating system in competition with IBM products. Virtual
storage, access levels, stacks, proper code v data segment properties instead
of the typical "flat-storage" model of Windows that enables the hackers to
trash or hijack your computer. Your tax records may go through a subsystem
that I once design responsibility for. (What is it worth .....? I once wrote a
proposal for IR that accidentally omitted the possibility that taxpayers could
have the initial letter "P"). But, the world doesn't behave like that. IBM
could thrash us even at greater price. VHS beat Betamax. We have coloured cars
instead of only black. The free market is the worst possible way of developing
products and standards. Except for all the other ways.
I believe the incredible expansion of the web from about 1994/5 onwards was
helped, not hindered, by those browser wars. They screwed up the standards,
but they made the web a much more exciting place for users. Your problem is
that you appear to be an engineer. (So am I). We always lose out to the
marketers & business managers, then have to pick up the pieces. But ... cast
your inhibitions aside, stop worrying about facts, stop worrying about the
long term effects on the users, and you too could learn to be a marketer or
business manager.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Lauri Raittila wrote: Brian wrote: Barry Pearson wrote: > I haven't managed to track any such evidence down for my page:
> "A brief history of tables"
Any excuse to plug that thing, eh?
I just wonder, why he thinks it is good publicity to his page to tell
that he has gotten facts incorrect, and claims that they doin't exist
when they contradict his page?
I am not currently aware of any errors in that page. But I recognise that
future evidence will reveal errors & omissions. I recognise that,
unfortunately, my knowledge is incomplete & that I sometimes make mistakes.
(If that doesn't apply to you, I envy you). When I become aware of them, I
correct them. Over time, that page will become more comprehensive &
authoritative. I update it perhaps every week or two. I created it on 1st
January, and it already has more than 60 external references, and is over 37
kilobytes, and sometimes appears in the top 10 results of Google searches,
depending on the particular search term.
When people cite sources that they believe contradict what appears on that
page, I read them. (Except when they are *already* referenced by that page,
which is quite common). Quite often the source doesn't support the
contradictory position! I sometimes wonder whether the responder has bothered
to read the document they believe contradicts what I am saying. (Or perhaps
they haven't understood what I am saying, and they may even agree with me if
they did).
Please treat this as an attempt to evolve a public, comprehensive,
authoritative, credible, source on this particular topic. It started out as "A
brief history of tables". It is becoming "A not so brief history of tables &
all the context & influences that support & led to tables"! It is here to
stay, and will be good as I can make it, with help from here & elsewhere.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
On Fri, 21 May 2004, Barry Pearson wrote: Alan J. Flavell wrote: On Fri, 21 May 2004, Barry Pearson wrote:
> 1993, yup. I found 1992-3 materials discussing the then-current
> HTML, and the forthcoming SGML-ification, which, as we know, was
> codified in RFC1866 by late 1995. So what's this nonsense about
> 1997?
SGML-ification appears not to have changed the intent of the mark-up.
Neat swerve :-}
I'm playing it straight.
I asked you about the nonsense reference to 1997, and you responded
with a nonsequitur about SGML-ification. By now of course you've
managed to shake-off the original context of the reference to 1997, so
there's nothing left to argue about. That's how "straight" you played
it, IMHO.
In fact, my initial test now, when looking at an
older proposal, is to examine "paragraph".
Look e.g for Google Groups' earliest reference to "speaking browser"
and see what you make of what you find. The *concept* clearly was not
new in 1994 when that posting was written, even if the commentator had
never "seen" one (maybe he should have "heard" one instead, but let's
not quibble over details).
In fact you might want to read some of the other postings in that 1994
thread, they include contributions for a certain Marc Andreessen as
well as Jamie Zawinski; and in the opposite corner, as it might be,
from Joe English and Peter Flynn. To name just a few of the familiar
names I see on that thread.
But speaking browsers are a vastly different concept, and so far I haven't
found a good reference before the announcement in 1998 of IBM's HPR.
I can't point you to a product, I'm afraid, and my memory for dates is
notoriously hazy without being able to find the original materials.
For sure the presentation that I was describing at CERN would be
categorised as an R&D project rather than a product, but I'm quite
definite that it rendered marked-up data (i.e it was a "speaking
browser"), rather than rendering the contents of a screen display a la
IBM Screen Reader.
Netscape hadn't at the last minute implemented the proposed Latin-1
character entities from RFC1866, they would not have been included in
HTML3.2.
No, I didn't know that. Have you a reference?
Not off-hand, no, sorry. In fact I have to admit I'm puzzled that I
now can't find anything to document the assertion, but I'm confident
that I didn't simply imagine it.
In hunting for relevant discussions, I'm reminded that the draft was
called Wilbur, and - I think this is significant - here's a comment
about it, from May 1996:
By the way, there's a new HTML 3.2 draft spec out. It basically says
that the Netscape and Microsoft extensions are now part of the spec
(except frames and JavaScript).
[...]
The presentation people will be happy with this new spec. The SGML
people will be less happy. (Style sheets didn't make it in.)
I didn't have to try hard to find that. It popped up in a search for
the draft which led to HTML3.2. I'd say the author of that remark had
recognised that there was an underlying ethos among the supporters of
SGML - that the markup was about marking logical structure, and that
it was opposed by the supporters of presentational-HTML. (The above
quote was from May 1996, and obviously refers to matters which were
common currency by that time).
Which kind-of opposes your blithe assertion that:
| SGML-ification appears not to have changed the intent of the mark-up.
I believe the incredible expansion of the web from about 1994/5 onwards was
helped, not hindered, by those browser wars. They screwed up the standards,
but they made the web a much more exciting place for users. Your problem is
that you appear to be an engineer. (So am I).
I notice that you chide me when, alongside my attempts to clarify the
historical record, I also express personal opinions; but you seem to
have no hangups about expressing yours.
Oh well.
Alan J. Flavell wrote: On Fri, 21 May 2004, Barry Pearson wrote: Alan J. Flavell wrote: > On Fri, 21 May 2004, Barry Pearson wrote:
>> Alan Flavell wrote ...
[snip] >> > 1993, yup. I found 1992-3 materials discussing the then-current
>> > HTML, and the forthcoming SGML-ification, which, as we know, was
>> > codified in RFC1866 by late 1995. So what's this nonsense about
>> > 1997?
>>
>> SGML-ification appears not to have changed the intent of the
>> mark-up.
>
> Neat swerve :-}
I'm playing it straight.
I asked you about the nonsense reference to 1997, and you responded
with a nonsequitur about SGML-ification. By now of course you've
managed to shake-off the original context of the reference to 1997, so
there's nothing left to argue about. That's how "straight" you played
it, IMHO.
[snip]
My reference to 1997 wasn't nonsense. The reponse about SGML-ification wasn't
a nonsequitur. So, I'll amplify. In summary:
- The perception of the nature of the web, stated publically by the major
players, changed dramatically as result of events in the 13 months from May
1997 to May 1998. There appear to be different views about what styling means,
and what other things mean, before & after February 1997. (I'll call these
"first era" & "second era" below). Just try comparing the way people talked
about things before & after this date. (I have done this comparison, and I am
exploring it further at the moment. Unfortunately, I will probably have to
re-read about 50 large web pages in the process! But I will publish the
results).
- What is important about the nature of the web is what authors should do to
achieve their ends, (communicating with the audience), and what browser
developers should do on behalf of users. Authors mark-up material as various
elements, and specify styles for these. So when should authors mark-up their
available material, and as which elements? It depends on what they are told.
Up to about February 1997 they were told what to do in terms of presentation,
not in terms of semantics. It is irrelevant whether HTML 2.0 SGML-ified
things. HTML 2.0 tells people what "paragraph" is for, which is for
typographical purposes, separated by new lines. So all concerned are entitled
to go ahead on that basis. HTML 4 in December 1997 changed all of that.
First era. HTML was intended for display on screens. HTML defined the overall
layout, and suggested some detailed styling, and provided some attributes to
control it. The realisation was that anything more needed stylesheets. I cite
several proposals for stylesheets from 1993 onwards. Discussion about
stylesheets during this time, except for the occasional mention of "columns",
was about such things as rendering of text, etc.
Second era: HTML was intended for rendering in many, and unlimited, ways,
including adaptive technologies. Elements therefore started to be described in
semantic terms. Stylesheets are now expected to be common, and there was the
intent to undo much of the damage of the extra presentation mark-up. Default
layout on screens was identified by HTML, but now stylesheets could change the
layout too. CSS2 is not a page layout language, (although it is "sort-of" a
viewport layout language if you wanted it), so even with CSS-positioning, it
typically needed some attention to the wrapping & nesting & sequencing of the
top-level of the document tree. (So, except for fairly simple pages, with
perhaps 3 or 4 key units, it hasn't yet separated layout from mark-up). http://www.barry.pearson.name/articl...es/history.htm
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson wrote: Alan J. Flavell wrote:
[snip] 1993: Tim Berners-Lee, Daniel Connolly, "A Representation of Textual
Information and MetaInformation for Retrieval and Interchange" ( version
1.2) http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
"Typical rendering is described for many elements. This is not a mandatory
part of the standard but is given as guidance for designers and to help
explain the uses for which the elements were intended". (Hence-
presentational mark-up).
That doesn't support your argument. Pay attention to "typical", "not a
mandatory part" and "given as guidance".
If I were writing a specification like that and wanted to give an
illustrative example, I'd pick a visual representation as well, as it's the
form most people are more familiar with. And the visual representation
_would_ help explain my intentions.
If I gave an example for an element type that blinked, was bold and italic,
and was very large, somebody reading the specification would say to
themselves "Hey, I think I'm supposed to call attention to this type of
element when I render it".
This doesn't mean that the specification is intended to be limited to a
particular presentation. It means that the specification authors chose a
sensible *example* that people were comfortable relating to. Using your
logic, they wouldn't have been able to give an example without you claiming
that it makes HTML presentational, even though they explicitly state "these
are just examples". Mere mention of presentation doesn't make HTML
presentational. It's not an evil word that sucks up specifications into
its possession.
"The elements within the BODY element are in the order in which they
should be presented to the reader". (Hence - layout primarily determined
by HTML).
I wouldn't describe the order of a document as a mere presentation detail.
You can't reorder arbitrary documents without running the risk of changing
their meanings. I believe that's one of the reasons CSS has avoided this
type of control, whereas XSLT (the 'T' standing for "Transformations") has
not.
Basically the specification is saying "don't reorder the document contents".
It's a constraint intended to preserve the document's meaning.
"When writing documents, you should assume that whatever is done it is
designed to have the same sort of effect as the styles above".
That doesn't support your argument unless you read "effect" as "visual
effect". If something is bold, italic, blinking and in big letters, the
effect is that attention is called to it. User-agents that have nothing to
do with presentation still find "attention should be called to this
element" useful information.
Paragraph mark-up was intended to be used to achieve the typical
rendering of a new line.
No, of a new *paragraph* (not surprisingly).
Whether you use Berner-Lee (1993), or Raggett (1997), "paragraph break"
was pretty well synomymous with "line break".
As far as my understanding goes, a line break is when text stops being
rendered on one line and continues on the next. A paragraph break is a
pause between bodies of text. Visually, a paragraph break is larger than a
line break. Non-visually, a line break doesn't make sense, and a paragraph
break is some kind of "gap".
[snip] The first significant published document, that I know of, to counter
^^^^^^^^^^^ this, was the HTML 4 recommendation in December 1997.
That's easily done: just apply your personal criterion of
insignificance to all the significant discussions and documents which
went before.
And how would you judge HTML 3.2? See above. I am trying to reveal
history, not rewrite it.
HTML 3.2 was a stopgap measure to stablise existing usage, as opposed to
HTML 4 which was actually designed. I have no problem with somebody
referring to HTML 4 as significant and HTML 3.2 as insignificant, regarding
design intentions. Nobody really designed HTML 3.2, they were just trying
to capture a snapshot of the tag soup everybody was writing at the time.
[snip] HTML was proposed as a presentational language before those browser got in
the act! See the quotes from Berners-Lee, that preceded the browser wars.
In "Weaving The Web"¹, on page 45 of my edition, when talking about the
origins of HTML, Tim Berners-Lee had this to say on the matter:
"A philosophical rule was that HTML should convey the structure of a
hypertext document, but not details of its presentation."
This is talked about before the release of the first web browser,
WorldWideWeb, in March 1991.
As far as what HTML was intended to be, right from the beginning, it appears
you are directly contradicting a very clear statement by Tim Berners-Lee,
the guy that invented HTML, in the book he wrote about the origins of the
WWW.
[snip] I never said that HTML was meant to specify the presentation! Where did
you get that from?
Huh? Straight from this very post I am replying to:
HTML was proposed as a presentational language before those browser got in
the act!
You're pretty clear in claiming that HTML was intended for presentation.
What I am saying is that, before HTML 4 & CSS2, "presentation" was *not*
normally seen to include "layout" ("positioning").
[snip] Instead of just looking for "presentation" or "styles", and assuming
without evidence that they include layout, try looking specifically for
indications that they were talkng about layout/positioning.
Can you provide any evidence that this is not the case? "Presentation" is a
pretty open term meaning "how something is presented" and there's no doubt
in my mind that it includes layout _by_definition_.
¹ Weaving The Web, Tim Berners-Lee, Orion Business Books. ISBN:
0-75282-090-7.
--
Jim Dabell
Jim Dabell wrote: Barry Pearson wrote: Alan J. Flavell wrote: [snip] 1993: Tim Berners-Lee, Daniel Connolly, "A Representation of Textual
Information and MetaInformation for Retrieval and Interchange" (
version
1.2) http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
"Typical rendering is described for many elements. This is not a
mandatory part of the standard but is given as guidance for
designers and to help explain the uses for which the elements were
intended". (Hence- presentational mark-up).
That doesn't support your argument. Pay attention to "typical", "not
a mandatory part" and "given as guidance".
If I were writing a specification like that and wanted to give an
illustrative example, I'd pick a visual representation as well, as
it's the form most people are more familiar with. And the visual
representation _would_ help explain my intentions.
This wasn't simply an illustrative example! There was no deeper model
described for which this was an illustration. *This* was the only model being
described.
That is the point I am making here. Since December 1997, we can identify a
semantic model for HTML that underpins various claims about the logical
purpose of mark-up. So, when we see a visual formatting model, we can assume
that it is a representation and/or illustration. We have a semantic model for
contrast.
But I can't find such a semantic underpinning before 1997. If you know of one,
please give me the reference. What I see, before 1997, is that the HTML model
of a page was based on its representation on a screen. I'm sure that some
people were thinking beyond this, especially getting on for 1997, but they
were (apparently) not expressing their views in places that were influencing
the development of the web at that time.
If I gave an example for an element type that blinked, was bold and
italic, and was very large, somebody reading the specification would
say to themselves "Hey, I think I'm supposed to call attention to
this type of element when I render it".
If you saw: "Typical rendering is described for many elements. This is not a
mandatory part of the standard but is given as guidance for designers and to
help explain the uses for which the elements were intended", perhaps you
would. Having seen that typical rendering for an element was blinking, you
would be entitled to assume that the use of mark-up in that way was to make it
blink.
Berners-Lee wrote that. It describes a causal link from mark-up to rendering.
It says nothing whatsoever about semantics. Do you know of anything about
HTML, written before 1997, that was really about semantics, rather than
presentation? I haven't found anything. I have been asking here for references
for some time. I'm sure it was being discussed. But it didn't appear to be
making an impact at the time.
This doesn't mean that the specification is intended to be limited to
a particular presentation. It means that the specification authors
chose a sensible *example* that people were comfortable relating to.
Using your logic, they wouldn't have been able to give an example
without you claiming that it makes HTML presentational, even though
they explicitly state "these are just examples". Mere mention of
presentation doesn't make HTML presentational. It's not an evil word
that sucks up specifications into its possession.
This is more than an example. Note: "to help explain the uses for which the
elements were intended". The description of paragraph didn't include the
semantics of "paragraph". It was about how it would be rendered. The semantics
of "paragraph" appeared in December 1997. Possibly for the fist time, in a
recommendation.
"The elements within the BODY element are in the order in which they
should be presented to the reader". (Hence - layout primarily
determined by HTML).
I wouldn't describe the order of a document as a mere presentation
detail. You can't reorder arbitrary documents without running the
risk of changing their meanings. I believe that's one of the reasons
CSS has avoided this type of control, whereas XSLT (the 'T' standing
for "Transformations") has not.
CSS2 (May 1998) enables elements to be presented in an order other than they
appear in the BODY element. CSS-positioning does this a lot. CSS1 (December
1996) appears to have gone to a lot of trouble to avoid this. Floats appear to
be defined so that they don't change the order. I believe the change in view
happened after February 1997.
Basically the specification is saying "don't reorder the document
contents". It's a constraint intended to preserve the document's
meaning.
I'll stick to what it says: "The elements within the BODY element are in the
order in which they should be presented to the reader". I'll leave you and
others to speculate about what the intention was.
"When writing documents, you should assume that whatever is done it
is designed to have the same sort of effect as the styles above".
That doesn't support your argument unless you read "effect" as "visual
effect". If something is bold, italic, blinking and in big letters,
the effect is that attention is called to it. User-agents that have
nothing to do with presentation still find "attention should be
called to this element" useful information.
Another point I make is that, before 1997, there was no evidence that the
recommendations were trying to include other than visual effects. If you know
of one, please give me the reference. As far as I can tell, non-visual effects
resulted from events in the period May 1997 to May 1998. I'm sure discussions
were going on before this, but the public statements that influence
discussions today appear to arise from that 13-month period.
Paragraph mark-up was intended to be used to achieve the typical
rendering of a new line.
No, of a new *paragraph* (not surprisingly).
Whether you use Berner-Lee (1993), or Raggett (1997), "paragraph
break" was pretty well synomymous with "line break".
As far as my understanding goes, a line break is when text stops being
rendered on one line and continues on the next. A paragraph break is
a pause between bodies of text. Visually, a paragraph break is
larger than a line break. Non-visually, a line break doesn't make
sense, and a paragraph break is some kind of "gap".
And your point is ...?
Until about February 1997, they appeared to be synonymous. Which, by your own
logic, would appear to mean that before that date, the key documents were
being considered in visual, not non-visual, terms. Before HTML 4 in December
1997, "paragraph break" appears to have been an acceptable term for what
happened between block-level elements, whether text-oriented or not. If you
can spot any indication that authors thought that it was different from "line
break", please show the evidence. As far as I can tell, they used it
interchangeably.
[snip] HTML was proposed as a presentational language before those browser
got in the act! See the quotes from Berners-Lee, that preceded the
browser wars.
In "Weaving The Web"¹, on page 45 of my edition, when talking about
the origins of HTML, Tim Berners-Lee had this to say on the matter:
"A philosophical rule was that HTML should convey the structure of a
hypertext document, but not details of its presentation."
This is talked about before the release of the first web browser,
WorldWideWeb, in March 1991.
Please provide evidence dated from those times. (I am not convinced by what
has been written since 1997/8. I believe some people are tending to re-write
the early history, in the post-1997/8 image. I am trying to find what was
*actually* written at that time, not the spin put upon it later).
I *do* believe that Berner-Lee was firmly convinced about stylesheets from the
early days. But browser-supplied stylesheets, not author-supplied stylesheets.
As far as what HTML was intended to be, right from the beginning, it
appears you are directly contradicting a very clear statement by Tim
Berners-Lee, the guy that invented HTML, in the book he wrote about
the origins of the WWW.
If I appear to be doing that, it is only because I quoting his own words from
key documents authored by him during the period before 1997. He is the one who
should be explaining the incompatiblities in his statements, not me!
[snip] What I am saying is that, before HTML 4 & CSS2, "presentation" was
*not* normally seen to include "layout" ("positioning").
[snip] Instead of just looking for "presentation" or "styles", and assuming
without evidence that they include layout, try looking specifically
for indications that they were talkng about layout/positioning.
Can you provide any evidence that this is not the case?
"Presentation" is a pretty open term meaning "how something is
presented" and there's no doubt in my mind that it includes layout
_by_definition_.
[snip]
As you say ... "in your mind". I believe that, before 1997, that would have
been an exceptional, minority, view. Have you evidence to the contrary?
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Toby Austin |
last post by:
I'm trying to replace <table>s with <div>s as much as possible.
However, I can't figure out how to do the following…
<table>
<tr>
<td valign="top" width="100%">some data that will...
|
by: mr_burns |
last post by:
hi,
is the table percent value for height used for displaying in browsers.
i have a table i want to run to the bottom of the screen so it seemed
best to set the height value to 100%.
when i...
|
by: Zak McGregor |
last post by:
Hi all
Are there any good solutions to aligning form field names and input boxes
without resorting to tables? I am struggling to do this nicely at the
moment.
Thanks
Ciao
Zak
|
by: Anthony Williams |
last post by:
Good morning,
I'm currently designing a site, using CSS, and wish to create a variable
width two-column layout, with header and footer, and one fixed-width column
on the left.
Previously, I...
|
by: Pete |
last post by:
Hello everybody --
Forgive my multi-posting my question. I posted first to ciwah, but I
learned that ciwas is the better group for this CSS question.
The problem has me stopped. The page:
...
|
by: phil-news-nospam |
last post by:
Is there really any advantage to using DIV elements with float style
properies, vs. the old method of TABLE and TR and TD?
I'm finding that by using DIV, it still involves the same number of...
|
by: ypjofficial |
last post by:
Hello All,
I am defining a class with one virtual function and storing its first 4
bytes ie. the address of the virtual function table to a file.I am
again rereading the file in the same program...
|
by: Tor Inge Rislaa |
last post by:
Table or Div
Is there a common rule or "best practice" concerning when to use TABLE and
when to use DIV tag's when designing a master page? I am designing a master
page with a header and...
|
by: Jeff User |
last post by:
Hi all
I am writing program/framework to server a web site dynamically based
on stored web page data with C#, .net1.1
What is the preferred means of controlling page layout, frames or...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
