Yes, I know some feel tables are evil. Nevertheless, at the time I
coded my site, it was easiest to control where stuff went on the page
for the widest range of browsers. I'm currently deciding about CSS,
which apparently still isn't consistent across many browsers. But
that's another discussion.

One of the coding things I did was to specify width in the <TABLE> and
<TD> tags. I used the O'Reilley HTML & XHTML book as a guide and they
say it's OK to specify width="50%" as well as a fixed width. Some HTML
syntax checkers complain on this syntax. It seems to work just fine in
all the browsers I test under. Is there anything in the HTML 4.01 spec
or later that prohibits this syntax? Why would some syntax checkers
flag this?

TIA,

/MeV/

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Michael Vilain <vilain@spamcop.net> wrote:
[color=blue]
>One of the coding things I did was to specify width in the <TABLE> and
><TD> tags. I used the O'Reilley HTML & XHTML book as a guide and they
>say it's OK to specify width="50%" as well as a fixed width. Some HTML
>syntax checkers complain on this syntax. It seems to work just fine in
>all the browsers I test under. Is there anything in the HTML 4.01 spec
>or later that prohibits this syntax?[/color]

The width attribute is deprecated in Strict DTDs on table cells, it's
allowed on the table element.

--
Spartanicus

"Spartanicus" <me@privacy.net> wrote in message
news:4pu541h9c9vsl5d6f7lt3qeaandk6upbqn@news.spart anicus.utvinternet.ie...[color=blue]
> Michael Vilain <vilain@spamcop.net> wrote:
>[color=green]
> >One of the coding things I did was to specify width in the <TABLE> and
> ><TD> tags. I used the O'Reilley HTML & XHTML book as a guide and they
> >say it's OK to specify width="50%" as well as a fixed width. Some HTML
> >syntax checkers complain on this syntax. It seems to work just fine in
> >all the browsers I test under. Is there anything in the HTML 4.01 spec
> >or later that prohibits this syntax?[/color]
>
> The width attribute is deprecated in Strict DTDs on table cells, it's
> allowed on the table element.
>
> --
> Spartanicus[/color]

Go figure. I'm not clear on this business of deprecated so I'll open myself
to attack and ask why deprecate anything?
Signed,
me

me wrote:
[color=blue]
> Go figure. I'm not clear on this business of deprecated so I'll open
> myself to attack and ask why deprecate anything?[/color]

Usually because a better replacement has come along.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

On Thu, 24 Mar 2005, David Dorward wrote:
[color=blue]
> me wrote:
>[color=green]
> > Go figure. I'm not clear on this business of deprecated so I'll open
> > myself to attack and ask why deprecate anything?[/color]
>
> Usually because a better replacement has come along.[/color]

Funnily enough, some of the quite early plans for the web involved
structure-based HTML with presentation controlled by a stylesheet.
There are some valuable lessons to be learned from the Viola browser,
by those who are prepared to assess the lessons in their appropriate
context.

It wasn't so very long before ideas started to develop for CSS,
although at that time there were several other ideas for stylesheet
implementations. Meantime, it seemed from its offerings at each
breathless new release that the then-popular wowser was trying to turn
HTML into a visual formatting language. Somewhere along the line, MS
decided to jump on that bandwagon with a wowser that was "bugwards
compatible" (if I recall the phrase right, and google says I do) with
the then-popular wowser.

There are some who claim that these earlier ideas for the web could
never have become popular, because they were too theoretical and took
too little account of eye candy; and that the web only became
successful because of the diversionary tactics of the then-popular
wowser in implementing direct visual styling in (quasi)HTML (which I
must admit in my own NSH opinion set back the course of web
development by several years, and we're only now seeing the benefits
of a recovery). I won't claim that all the failures ought to have
been successes: the proposed HTML3.0(RIP) contained some valuable
ideas, that appeared to have been buried without trace when
HTML.3.2(spit) was published; but which re-surfaced in improved form
in HTML4; but it also contained some items that would be rated as
hopeless hacks nowadays.

I think at least some of us now understand that HTML+stylesheets (or
HTML+CSS if you want to be specific) is a much more effective solution
for the eye-candy supporters - while causing less harm to
non-mainstream client agents.

It's easy to argue over the lessons of history, and I suppose we'll
never really know what would have happened in an alternative universe
where a stylesheet-supporting browser captured the market, and an
attempt to turn HTML into a visual formatting language got laughed off
the 'net.

Meantime, curiously enough, MS Word has had structural markup (they
call it "Styles") for many years, with an associated stylesheet (they
call it a style template). It can be used to make a remarkably
effective base, not only for printed documents, but also for
conversion to strict HTML with CSS formatting suggestions. *But* the
users of MS Word that I come into contact with 'most every day, still
insist on using it as if it were an electric typewriter - hit RETURN
for a linebreak, hit RETURN twice for a new paragraph, and everything
directly formatted with font sizes and bold and stuff, no matter what
it says in the "style" area (which they simply ignore). The
conversion to HTML is appalling.

In short, give them a precision tool and they use it as a hammer.

On Thu, 24 Mar 2005 20:24:14 +0000, "Alan J. Flavell"
<flavell@ph.gla.ac.uk> wrote:
[color=blue]
>On Thu, 24 Mar 2005, David Dorward wrote:[/color]
[color=blue][color=green]
>> me wrote:[color=darkred]
>> > Go figure. I'm not clear on this business of deprecated so I'll open
>> > myself to attack and ask why deprecate anything?[/color][/color][/color]
[color=blue][color=green]
>> Usually because a better replacement has come along.[/color][/color]
[color=blue]
>Funnily enough, some of the quite early plans for the web involved
>structure-based HTML with presentation controlled by a stylesheet.[/color]

As we both know, but some of the youngsters around here do not, the very
first browser that TBL used for demonstrations and request for funds to
develop HTML, had a separate style sheet mechanism for presentation.
(ran on a "NeXT Step" platform of that time IMMIC?)
[color=blue]
>There are some valuable lessons to be learned from the Viola browser,
>by those who are prepared to assess the lessons in their appropriate
>context.[/color]

Sure; here goes for the historically curious...

<http://www.xcf.berkeley.edu/~wei/viola/violaHome.html>

(it's a mirror since the true viola site is under reconstruction)

Pei Wei is nothing short of a genius when it comes to WWW applications.
I would personally claim that he should be regarded as the one who truly
invented client side scripting, and became the first one to realize the
true shortcomings of that mechanism when applied to the WWW too.

(still, have we seen a real interactive game of chess written in
Javascript yet? :-)

--
Rex

"David Dorward" <dorward@yahoo.com> wrote in message
news:d1v11u$8a2$1$8300dec7@news.demon.co.uk...[color=blue]
> me wrote:
>[color=green]
> > Go figure. I'm not clear on this business of deprecated so I'll open
> > myself to attack and ask why deprecate anything?[/color]
>
> Usually because a better replacement has come along.[/color]

Possibly, but I was hoping to get some insight into the how and why of
deprecated elements. If I were to make a guess based on my scant knowledge
of w3c processes I would assume that deprecated elements are no longer
appropriate for use with documents containing certain DTD's. I further
assume that even though an item is deprecated this doesn't mean that there
is a blanket prohibition against it's use and it can still be used with an
appropriate DTD (or possibly without a DTD?). Please feel free to enlighten
me as I am quite ignorant in these matters.
Signed,
me

On Fri, 25 Mar 2005 10:21:14 -0600, "me" <anonymous@_.com> wrote:
[color=blue]
>"David Dorward" <dorward@yahoo.com> wrote in message
>news:d1v11u$8a2$1$8300dec7@news.demon.co.uk...[color=green]
>> me wrote:
>>[color=darkred]
>> > Go figure. I'm not clear on this business of deprecated so I'll open
>> > myself to attack and ask why deprecate anything?[/color]
>>
>> Usually because a better replacement has come along.[/color]
>
>Possibly, but I was hoping to get some insight into the how and why of
>deprecated elements. If I were to make a guess based on my scant knowledge
>of w3c processes I would assume that deprecated elements are no longer
>appropriate for use with documents containing certain DTD's. I further
>assume that even though an item is deprecated this doesn't mean that there
>is a blanket prohibition against it's use and it can still be used with an
>appropriate DTD (or possibly without a DTD?). Please feel free to enlighten
>me as I am quite ignorant in these matters.[/color]

As a quick approximation:

- the original intention of HTML was to describe the *structure* of a
document (headings, paragraphs, lists etc) and leave the manner of
presentation of the information to the browser.

- the elements which are maintained in the Strict version of HTML are
structural elements.

- the elements which are deprecated are those which specify a particular
presentation (font size, colour etc). These are more appropriately
specified by means of stylesheets for reasons of speed, maintainability
and accessibility.

The deprecated elements occur in the Transitional version of HTML, which
was created with the idea that older web pages can be knocked into shape
with relatively few changes, not a complete rewrite. For new pages it is
recommended to use Strict, and thus not use the deprecated elements.

HTH

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

On Fri, 25 Mar 2005 10:21:14 -0600, "me" <anonymous@_.com> wrote:
[color=blue]
> I would assume that deprecated elements are no longer
>appropriate for use with documents containing certain DTD's[/color]

Define "appropriate for use".

The notion of a deprecated element is one that's still present and
supported (for legacy reasons), but a feature that should not be
encouraged further. If they're no longer in the DTD, then that's more
than merely deprecating an element.

--
Smert' spamionam

"Stephen Poley" <sbpoleySpicedHamTrap@xs4all.nl> wrote in message
news:t8i8419gt5vcdiboa28iq4cnaea7rd6jt6@4ax.com...[color=blue]
> On Fri, 25 Mar 2005 10:21:14 -0600, "me" <anonymous@_.com> wrote:
>[color=green]
> >"David Dorward" <dorward@yahoo.com> wrote in message
> >news:d1v11u$8a2$1$8300dec7@news.demon.co.uk...[color=darkred]
> >> me wrote:
> >>
> >> > Go figure. I'm not clear on this business of deprecated so I'll open
> >> > myself to attack and ask why deprecate anything?
> >>
> >> Usually because a better replacement has come along.[/color]
> >
> >Possibly, but I was hoping to get some insight into the how and why of
> >deprecated elements. If I were to make a guess based on my scant[/color][/color]
knowledge[color=blue][color=green]
> >of w3c processes I would assume that deprecated elements are no longer
> >appropriate for use with documents containing certain DTD's. I further
> >assume that even though an item is deprecated this doesn't mean that[/color][/color]
there[color=blue][color=green]
> >is a blanket prohibition against it's use and it can still be used with[/color][/color]
an[color=blue][color=green]
> >appropriate DTD (or possibly without a DTD?). Please feel free to[/color][/color]
enlighten[color=blue][color=green]
> >me as I am quite ignorant in these matters.[/color]
>
> As a quick approximation:
>
> - the original intention of HTML was to describe the *structure* of a
> document (headings, paragraphs, lists etc) and leave the manner of
> presentation of the information to the browser.
>
> - the elements which are maintained in the Strict version of HTML are
> structural elements.
>
> - the elements which are deprecated are those which specify a particular
> presentation (font size, colour etc). These are more appropriately
> specified by means of stylesheets for reasons of speed, maintainability
> and accessibility.
>
> The deprecated elements occur in the Transitional version of HTML, which
> was created with the idea that older web pages can be knocked into shape
> with relatively few changes, not a complete rewrite. For new pages it is
> recommended to use Strict, and thus not use the deprecated elements.
>
> HTH
>
> --
> Stephen Poley
>
> http://www.xs4all.nl/~sbpoley/webmatters/[/color]

Thank you for your answer. When you say strict I assume the DTD tells the
browser the page is strict?

As for completely separating structure from presentation I would adopt this
method if it allowed me the same freedom of design in IE that I currently
enjoy. If you said other browsers support CSS positioning better than IE I
would be hard pressed to argue against that point.
Signed,
me

me wrote:
[color=blue]
> Possibly, but I was hoping to get some insight into the how and why of
> deprecated elements.[/color]

"Deprecated" serves as a warning to browser makers and web site authors. An
element that's marked as deprecated is in a transitional state. It is
supported in the current version of the specification, but support for it
will be removed in a future version.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

"Sherm Pendley" <spamtrap@dot-app.org> wrote in message
news:CvudnQtpGbMZFdnfRVn-hA@adelphia.com...[color=blue]
> me wrote:
>[color=green]
>> Possibly, but I was hoping to get some insight into the how and why of
>> deprecated elements.[/color]
>
> "Deprecated" serves as a warning to browser makers and web site authors.
> An
> element that's marked as deprecated is in a transitional state. It is
> supported in the current version of the specification, but support for it
> will be removed in a future version.
>
> sherm--
>
> --
> Cocoa programming in Perl: http://camelbones.sourceforge.net
> Hire me! My resume: http://www.dot-app.org[/color]

But, it will always work, right? I mean, the browsers will always be able to
display deprecated code. What do you mean by, "...but support for it will be
removed in a future version"?

Carla

me wrote:[color=blue]
> "David Dorward" <dorward@yahoo.com> wrote in message
> news:d1v11u$8a2$1$8300dec7@news.demon.co.uk...
>[color=green]
>>me wrote:
>>
>>[color=darkred]
>>>Go figure. I'm not clear on this business of deprecated so I'll open
>>>myself to attack and ask why deprecate anything?[/color]
>>
>>Usually because a better replacement has come along.[/color]
>
>
> Possibly, but I was hoping to get some insight into the how and why of
> deprecated elements. If I were to make a guess based on my scant knowledge
> of w3c processes I would assume that deprecated elements are no longer
> appropriate for use with documents containing certain DTD's. I further
> assume that even though an item is deprecated this doesn't mean that there
> is a blanket prohibition against it's use and it can still be used with an
> appropriate DTD (or possibly without a DTD?). Please feel free to enlighten
> me as I am quite ignorant in these matters.
> Signed,
> me
>[/color]

My understanding of it is that they're deprecated because they're
presentational, for the most part, and therefore would be better
suggested via CSS.

There's no "blanket prohibition" against them, no.

c.thornquist wrote:
[color=blue]
> But, it will always work, right? I mean, the browsers will always be able
> to display deprecated code.[/color]

The theory is that eventually authors will get to the stage where they stop
using deprecated code (Its been a decade since HTML 4 was published, but
still... <sigh>) and then browsers can drop support for it.


--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

On Sat, 26 Mar 2005 10:00:27 GMT, "c.thornquist"
<c.thornquist@insightbb.com> wrote:
[color=blue]
>But, it will always work, right? I mean, the browsers will always be able to
>display deprecated code.[/color]

Current browsers will probably be able to. New browsers may well
choose not to.

Use <center> and your desktop browser in a few years might still be
making use of it. But your mobile phone never used it from the start.

c.thornquist wrote:
[color=blue]
> But, it will always work, right?[/color]

No, and that's precisely the point. Deprecation is a warning that, while a
given element works right now, support for it will be removed at some
future point in time.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

"c.thornquist" <c.thornquist@insightbb.com> wrote in message
news:%oa1e.106331$Ze3.5715@attbi_s51...[color=blue]
>
> "Sherm Pendley" <spamtrap@dot-app.org> wrote in message
> news:CvudnQtpGbMZFdnfRVn-hA@adelphia.com...[color=green]
> > me wrote:
> >[color=darkred]
> >> Possibly, but I was hoping to get some insight into the how and why of
> >> deprecated elements.[/color]
> >
> > "Deprecated" serves as a warning to browser makers and web site authors.
> > An
> > element that's marked as deprecated is in a transitional state. It is
> > supported in the current version of the specification, but support for[/color][/color]
it[color=blue][color=green]
> > will be removed in a future version.
> >
> > sherm--
> >
> > --
> > Cocoa programming in Perl: http://camelbones.sourceforge.net
> > Hire me! My resume: http://www.dot-app.org[/color]
>
> But, it will always work, right? I mean, the browsers will always be able[/color]
to[color=blue]
> display deprecated code.[/color]

I think the past can give us some idea of what may happen in future. To the
best of my knowledge IE6 supports all items that have been deprecated by the
w3c. I think the best indicator of how "future proof" our sites will be is
whether browsers stay backwards compatiable. I think IE has done a
reasonably good job in this respect. As an aside I rarely use the term
future proof when speaking of things made by man. The pyramids my well be
the best example of future proof, software (and websites?) might be the
worst
[color=blue]
> What do you mean by, "...but support for it will be
> removed in a future version"?[/color]

Based on my limited knowledge of their processes, (someone please correct me
if I'm wrong) a future version of the w3c standards may (will?) remove
support for deprecated items.
Signed,
me

"me" <anonymous@_.com> wrote in message
news:114b63t3o4qro90@corp.supernews.com...[color=blue]
> "c.thornquist" <c.thornquist@insightbb.com> wrote in message
> news:%oa1e.106331$Ze3.5715@attbi_s51...[color=green]
>>
>> "Sherm Pendley" <spamtrap@dot-app.org> wrote in message
>> news:CvudnQtpGbMZFdnfRVn-hA@adelphia.com...[color=darkred]
>> > me wrote:
>> >
>> >> Possibly, but I was hoping to get some insight into the how and why of
>> >> deprecated elements.
>> >
>> > "Deprecated" serves as a warning to browser makers and web site
>> > authors.
>> > An
>> > element that's marked as deprecated is in a transitional state. It is
>> > supported in the current version of the specification, but support for[/color][/color]
> it[color=green][color=darkred]
>> > will be removed in a future version.
>> >
>> > sherm--
>> >
>> > --
>> > Cocoa programming in Perl: http://camelbones.sourceforge.net
>> > Hire me! My resume: http://www.dot-app.org[/color]
>>
>> But, it will always work, right? I mean, the browsers will always be able[/color]
> to[color=green]
>> display deprecated code.[/color]
>
> I think the past can give us some idea of what may happen in future. To
> the
> best of my knowledge IE6 supports all items that have been deprecated by
> the
> w3c. I think the best indicator of how "future proof" our sites will be is
> whether browsers stay backwards compatiable.[/color]

This is what I've always heard. That browsers will remain backward
compatible. Otherwise, too many won't use the newer browsers (since the www
is filled with deprecated code).

I think IE has done a[color=blue]
> reasonably good job in this respect. As an aside I rarely use the term
> future proof when speaking of things made by man. The pyramids my well be
> the best example of future proof, software (and websites?) might be the
> worst
>[color=green]
>> What do you mean by, "...but support for it will be
>> removed in a future version"?[/color]
>
> Based on my limited knowledge of their processes, (someone please correct
> me
> if I'm wrong) a future version of the w3c standards may (will?) remove
> support for deprecated items.[/color]

When the w3c says code is deprecated, doesn't that mean that it's frowned
upon, but will still work? The w3c can't cause a browser to not display
deprecated code, right? Do they have much input into what will be backward
compatible in new versions of browsers?

Carla

c.thornquist wrote:[color=blue]
>
> When the w3c says code is deprecated, doesn't that mean that it's frowned
> upon, but will still work?[/color]

No, it means that they intend to remove it from a future version of the
standard. Once it's removed, browsers need not support it in order to
be standards compliant. In practice, even once that future version is
approved it will clearly continue to work in existing browsers, at least
for a while.
[color=blue]
> The w3c can't cause a browser to not display
> deprecated code, right? Do they have much input into what will be backward
> compatible in new versions of browsers?[/color]

It's entirely up to the browser vendors. Implementing and/or
maintaining deprecated features costs them time and money; at some point
each of them will decide that this cost isn't worth it for a feature
which people have been told for years that they shouldn't use -- and the
next version of an existing browser, or the first version of a new
browser, won't support those features.

Assuming backward compatibility forever is a really bad idea. The most
famous counter-example I can think of offhand is many years back when
Netscape (the dominant browser at that time) fixed a long-standing bug.
They had wrongly terminated an element when a '>' was seen, even if it
was inside a quoted string, and the usual cargo-cult mentality had
gotten into the habit of not bothering to type the closing quote in this
case. There was a great deal of wailing and gnashing of teeth when many
pages displayed as trash in the new version of Netscape.

Dave

"c.thornquist" <c.thornquist@insightbb.com> wrote in message
news:woh1e.104922$r55.104044@attbi_s52...[color=blue]
> "me" <anonymous@_.com> wrote in message
> news:114b63t3o4qro90@corp.supernews.com...[color=green]
> > "c.thornquist" <c.thornquist@insightbb.com> wrote in message
> > news:%oa1e.106331$Ze3.5715@attbi_s51...[/color][/color]

[snip]
[color=blue][color=green][color=darkred]
> >> But, it will always work, right? I mean, the browsers will always be[/color][/color][/color]
able[color=blue][color=green]
> > to[color=darkred]
> >> display deprecated code.[/color]
> >
> > I think the past can give us some idea of what may happen in future. To
> > the
> > best of my knowledge IE6 supports all items that have been deprecated by
> > the
> > w3c. I think the best indicator of how "future proof" our sites will be[/color][/color]
is[color=blue][color=green]
> > whether browsers stay backwards compatiable.[/color]
>
> This is what I've always heard. That browsers will remain backward
> compatible. Otherwise, too many won't use the newer browsers (since the[/color]
www[color=blue]
> is filled with deprecated code).
>
> I think IE has done a[color=green]
> > reasonably good job in this respect. As an aside I rarely use the term
> > future proof when speaking of things made by man. The pyramids my well[/color][/color]
be[color=blue][color=green]
> > the best example of future proof, software (and websites?) might be the
> > worst
> >[color=darkred]
> >> What do you mean by, "...but support for it will be
> >> removed in a future version"?[/color]
> >
> > Based on my limited knowledge of their processes, (someone please[/color][/color]
correct[color=blue][color=green]
> > me
> > if I'm wrong) a future version of the w3c standards may (will?) remove
> > support for deprecated items.[/color]
>
> When the w3c says code is deprecated, doesn't that mean that it's frowned
> upon, but will still work?[/color]

Yes it will still work. I have to chuckle at the phrase "frowned upon",
makes me wonder if the w3c thinks using deprecated code is a mortal sin or
just a venial sin. ;-)
[color=blue]
> The w3c can't cause a browser to not display
> deprecated code, right?[/color]

They wish they could. Thankfully though that will never happen.
[color=blue]
> Do they have much input into what will be backward
> compatible in new versions of browsers?
> Carla[/color]

They may make recommendations but they have no power to enforce them.

As I have long said, what you can or can't do with your computer on the web
is determined entirely by which browser you use. I think it highly unlikely
that future versions of IE will stop supporting what the w3c disparagingly
refers to as deprecated code, at least not anytime soon. People like bells,
whistles and eye candy. Why should MS remove popular features from IE, it
costs them little or nothing to retain support for depracated code. After
all, how many people do you know who like software that does less?
Signed,
me