There are several more important issues there than the syntactic nitpicking
that HTML 4.01 Strict (vs. Transitional) is about. For example, setting a
large fixed width is a bad idea. And if you test the page with images
disabled (easy on Firefox when you have Web Developer Extensions installed,
as any web author should have), you'll understand _why_ alt attributes are
required and you know better than to use alt="" for an image containing
text.
> A validator check shows 12 errors.

And they are all described rather clearly. If you really want to work on
this, just read the explanations and fix the errors that you understand,
then re-validate. (Often fixing one simple error removes some other error
messages as well.) The only confusing thing here is that several errors are
caused by the use of text-level (inline) elements directly inside a <form>
element.
> BTW, INPUT elements are not allowed
> anymore in HTML 4?

Of course they are. In Strict, they must be wrapped inside block-level
containers (such as div or table).
> I'm not an HTML expert and I was wondering if perhaps some
> translators/converters exist, which convert transitional code into
> strict code. Any ideas?

It would be possible to create a converter, and most probably pointless. In
particular, some styling features that are possible in HTML 4.01
Transitional are not allowed in HTML 4.01 Strict and either very problematic
or impossible to do in CSS as currently defined and implemented. But of
course "conversion" can be defined in various ways, e.g. so that
presentational attributes and elements that are disallowed in HTML 4.01 are
simply omitted.

In general, you should use CSS rather than HTML for presentational (styling)
features, but it is usually pointless to do HTML to CSS conversion for
existing documents. What you might find useful is learning the CSS way of
doing things that you accustomed to doing in HTML, especially since CSS
usually gives more possibilities and often an easier way. So don't change
existing documents, change your mind and habits. See "Mapping presentational
HTML to CSS",http://www.cs.tut.fi/~jkorpela/html2css.html

Advertisements

On 16 mai, 09:47, "Jukka K. Korpela" <> wrote:
> Alfred Molon wrote:
> > I was trying to convert the pages from my site from transitional to
> > strict and ran into problems.
>
> It's usually pointless, and sometimes outright harmful, to convert existing
> pages from one HTML version to another.
>
> >http://www.molon.de/l/upsgn1.html
>
> There are several more important issues there than the syntactic nitpicking
> that HTML 4.01 Strict (vs. Transitional) is about.

There may be other more important issues: it's usually the case too.

But, in the process of making a webpage, if making sure that
presentation and style are done by CSS then it becomes normal to
declare a reference to a strict DTD. Fixing validation markup errors
does not fix everything but it's nevertheless a necessary minimum.

For example, setting a
> large fixed width is a bad idea. And if you test the page with images
> disabled (easy on Firefox when you have Web Developer Extensions installed,
> as any web author should have), you'll understand _why_ alt attributes are
> required and you know better than to use alt="" for an image containing
> text.

A missing alt attribute is going to be reported by a validator as a
validation markup error.

> It would be possible to create a converter, and most probably pointless.

I disagree. I've used HTML Tidy to convert several hundreds of
webpages to use a doctype declaration referencing a strict DTD at
mozilla.org and never thought it was pointless.

> In
> particular, some styling features that are possible in HTML 4.01
> Transitional are not allowed in HTML 4.01 Strict and either very problematic
> or impossible to do in CSS as currently defined and implemented.

I'm curious. Can you name a few of such styling features that are
possible in HTML 4.01
Transitional and that are not allowed in HTML 4.01 Strict and either
very problematic
or impossible to do in CSS as currently defined and implemented. ?
> In general, you should use CSS rather than HTML for presentational (styling)
> features, but it is usually pointless to do HTML to CSS conversion for
> existing documents. What you might find useful is learning the CSS way of
> doing things that you accustomed to doing in HTML, especially since CSS
> usually gives more possibilities and often an easier way. So don't change
> existing documents, change your mind and habits. See "Mapping presentational
> HTML to CSS",http://www.cs.tut.fi/~jkorpela/html2css.html

I see errors or questionable "CSS or HTML+CSS replacements" in that
"Mapping presentational HTML to CSS".

2-
<table bordercolor="color"> . First bordercolor is invalid.
<table style="border-color: color">
Second: without a border-style, the declaration border-color: color
will be ignored.

3- <center>content</center> <div style="text-align:center">content</
div>
It can be margin-left: auto; margin-right: auto; for block level
elements. It depends on what the author intended. <center> can be
converted in 2 manners; it depends on the context and what the author
intended.

4- <ol start="number"> no CSS counterpart
but there is counter-reset for this and list-style-type: decimal.

Advertisements

On Wed, 19 May 2010 22:03:17 -0700, GTalbot wrote:
> I'm curious. Can you name a few of such styling features that are
> possible in HTML 4.01
> Transitional and that are not allowed in HTML 4.01 Strict and either
> very problematic
> or impossible to do in CSS as currently defined and implemented. ?

Actually, I can ... but in the end I was finally able to abandon it.

One of my sites [the parts lookup] was used by a customer who used an old
cell phone that only had some HTML 3.2 browser on it. I used a table
structure and a center tag to get a layout that worked. When he upgraded
phones, I dropped all that.

(He would use his phone while he crawled around a bike, ordering parts
right off the parts list instead of trying to write things down an order
them later.)

GTalbot wrote:
> But, in the process of making a webpage, if making sure that
> presentation and style are done by CSS then it becomes normal to
> declare a reference to a strict DTD.

It depends. If you need, say, a working method (i.e. one that works at least
in most situations) for allowing (but not requiring) a line break in a
string, then you should use the <wbr> tag and just deal with the
consequences in validation. You might still declare the Strict DTD (to get
"standards" mode) but then you need to ignore certain errors, and finding
unintentional markup errors becomes more difficult. Of course, in this
context, Transitional would not help. My point is that document type
declarations are something to be chosen on very pragmatic grounds.
>> you'll understand _why_
>> alt attributes are required and you know better than to use alt=""
>> for an image containing text.
>
> A missing alt attribute is going to be reported by a validator as a
> validation markup error.

Yes, with any published HTML DOCTYPE since 3.2. But my point was that
validators do _not_ catch alt="" - it's not a syntax error, and it would be
quite wrong to report it as syntax error.
> I've used HTML Tidy to convert several hundreds of
> webpages to use a doctype declaration referencing a strict DTD at
> mozilla.org and never thought it was pointless.

Well, you didn't tell us what the point was.

Mechanical conversions like those performed by HTML Tidy when I last used it
(admittedly, years ago) tend to make the document more messy, not less. When
I see presentational attributes in a tag, I know what they relate to. If I
see some CSS code with an automatically generated non-mnemonic
non-suggestive class name, I need to search for that class name's
occurrences to see what is being done.
> Can you name a few of such styling features that are
> possible in HTML 4.01 Transitional and that are not allowed in
> HTML 4.01 Strict and either very problematic
> or impossible to do in CSS as currently defined and implemented. ?

1) <ol start="42"> and <ol value="10">
2) target attribute
3) <small> (no defined counterpart in CSS - operates with a special scale of
sizes)
4) <menu> (I know I'm stretching here, but a browser may render <menu> and
<ul> differently - that was originally the intent, and Lynx does that - and
since you cannot in general know what the difference might be, how could you
achieve it in CSS?)
> I see errors or questionable "CSS or HTML+CSS replacements" in that
> "Mapping presentational HTML to CSS".

Whether it is valid depends on the document type definition. Besides, it's
irrelevant, since the topic of my page is practical mapping from
presentational HTML to CSS, without taking a position on "standards" or the
question whether people should use presentational HTML or CSS.
> <table style="border-color: color">
> Second: without a border-style, the declaration border-color: color
> will be ignored.

So the effect is just the same as for bordercolor="color"
> 4- <ol start="number"> no CSS counterpart
> but there is counter-reset for this and list-style-type: decimal.

That does not correspond to the start attribute, which affects the number in
the numbering that browsers generate by default for <ol>. If you use
counters, you must specifically _suppress_ such numbering, otherwise you
will get two numbers for each item. This means that the rendering will be
different, except by accident.

Thank you for the usual bogosity signals, including forged sender
information and lack of any citation, in a context where you a replying to a
statement about lack of _defined_ counterpart. If you claim that there is a
defined correspondence, you should be able to cite a definition.

Besides, your statement is wrong even if taken just as an observation of how
browsers typically behave in the implementation of <small>. To see this,
just try

<small>W</small><span style="font-size:90%">W</span>

on some browsers. Using a large basic font size will help you make the
observations faster.

On 23 mai, 14:57, "Jukka K. Korpela" <> wrote:
> GTalbot wrote:
> > But, in the process of making a webpage, if making sure that
> > presentation and style are done by CSS then it becomes normal to
> > declare a reference to a strict DTD.
>
> It depends. If you need, say, a working method (i.e. one that works at least
> in most situations) for allowing (but not requiring) a line break in a
> string, then you should use the <wbr> tag and just deal with the
> consequences in validation. You might still declare the Strict DTD (to get
> "standards" mode) but then you need to ignore certain errors, and finding
> unintentional markup errors becomes more difficult. Of course, in this
> context, Transitional would not help. My point is that document type
> declarations are something to be chosen on very pragmatic grounds.

Instead of <wbr>, I believe there is a character entity for this...
but it's not well supported IIRC.

> > I've used HTML Tidy to convert several hundreds of
> > webpages to use a doctype declaration referencing a strict DTD at
> > mozilla.org and never thought it was pointless.
>
> Well, you didn't tell us what the point was.

The point was to achieve clearer separation of style and presentation
from content and structure. More consistent look, more consistent
coding manners, therefore easier to maintain, to do site-wide changes
if needed.
> Mechanical conversions like those performed by HTML Tidy when I last used it
> (admittedly, years ago) tend to make the document more messy, not less.

You need to test HTML Tidy, experiment, make adjustments. Tuning of
options to use is delicate in HTML Tidy when you're beginning with
HTML Tidy.
> When
> I see presentational attributes in a tag, I know what they relate to. If I
> see some CSS code with an automatically generated non-mnemonic
> non-suggestive class name, I need to search for that class name's
> occurrences to see what is being done.

You have a point here. I totally agree with you on this. I manually
have to rename "c" classes (generated by HTML Tidy) into better
descriptive class names, more mnemonic, intuitive class names.

Some options in HTML Tidy are not that useful; others are more useful,
I'd say.

> > Can you name a few of such styling features that are
> > possible in HTML 4.01 Transitional and that are not allowed in
> > HTML 4.01 Strict and either very problematic
> > or impossible to do in CSS as currently defined and implemented. ?
>
> 1) <ol start="42"> and <ol value="10">

I would suggest to use counter-reset.
> 2) target attribute

Frames are pretty much obsolete, definitely not recommendable. There
is the target property in a CSS 3 module. Anyway, I do not recommend
any of this. target as an HTML attribute is really something which
should not be used anymore
> 3) <small> (no defined counterpart in CSS - operates with a special scale of
> sizes)

I would suggest CSS declaration
{font-size: smaller;}
as a CSS replacement for <small>

bordercolor is not in any document type definition that I know of.
It's not in transitional DTD. bordercolor is not listed in HTML 3.2
and is not listed in HTML 4.01. bordercolor is an HTML extension from
Microsoft.
> Besides, it's
> irrelevant, since the topic of my page is practical mapping from
> presentational HTML to CSS, without taking a position on "standards" or the
> question whether people should use presentational HTML or CSS.

Okay. Fair enough.
>
> > <table style="border-color: color">
> > Second: without a border-style, the declaration border-color: color
> > will be ignored.
>
> So the effect is just the same as for bordercolor="color"

I am not sure. I would need to test this. I believe
bordercolor="color" will be honored in quirks mode in a number of
browsers with a default solid (or is it outset?) border and a default
2px width. When converting to HTML 4.01 strict, <table style="border-
color: color"> may not suffice.

> > 4- <ol start="number"> no CSS counterpart
> > but there is counter-reset for this and list-style-type: decimal.
>
> That does not correspond to the start attribute, which affects the number in
> the numbering that browsers generate by default for <ol>.
> If you use
> counters, you must specifically _suppress_ such numbering, otherwise you
> will get two numbers for each item. This means that the rendering will be
> different, except by accident.

I understand what you're saying. <ol> would have to be dropped then.
It could still work with a counter-reset set at, say, 42 and a counter-
increment.

Gazing into my crystal ball I observed dorayme <>
writing in news::
> In article
><
> m>,
> GTalbot <> wrote:
>
>> target as an HTML attribute is really something which
>> should not be used anymore
>
> I doubt there is a good argument for so sweeping a statement.
>

I have to agree with GTalbot. The user can right click and open in a
new window or tab. Authors should not decide what the user wants to do
for him.

I use mouse gestures, have for years, and the thing I really hate is
having the back button broken.

Of course, this is with the exception of frames, which also should not
be used anymore, unless it is in an intranet application.

In article <Xns9D84C6341514arbpenyahoocom@85.214.73.210>,
Adrienne Boswell <> wrote:
> Gazing into my crystal ball I observed dorayme <>
> writing in news::
>
> > In article
> ><
> > m>,
> > GTalbot <> wrote:
> >
> >> target as an HTML attribute is really something which
> >> should not be used anymore
> >
> > I doubt there is a good argument for so sweeping a statement.
> >
>
> I have to agree with GTalbot. The user can right click and open in a
> new window or tab. Authors should not decide what the user wants to do
> for him.
>
Authors decide all sorts of things for users. Users often have
not a clue what they really want to do. Right click and open in
another tab indeed! Do you really dream that the average person
on the Clapham bus would know such a thing? There is a super
idealised caricature of the user that is behind the idea that
target should *never* be used.
> I use mouse gestures, have for years, and the thing I really hate is
> having the back button broken.

Yes, and you mention this because there is something typical
about you? Mouse gestures!

I become uneasy when I hear that a film is going to be more than
90 or so minutes and I get a panic attack if it is over 120 or so
mins. But I will not be banning such films when I become ruler of
the world. This caution allows for various circumstances hard to
foresee.

On 23 mai, 14:57, "Jukka K. Korpela" <> wrote:
> GTalbot wrote:
> > 4- <ol start="number"> no CSS counterpart
> > but there is counter-reset for this and list-style-type: decimal.
>
> That does not correspond to the start attribute, which affects the number in
> the numbering that browsers generate by default for <ol>. If you use
> counters, you must specifically _suppress_ such numbering,

list-style-type: none suppress such numbering.
> otherwise you
> will get two numbers for each item. This means that the rendering will be
> different, except by accident.

Neil Gould wrote:
> There are some presentational situations (beyond intranet) that are best
> served by the use of frames, and there is no CSS equivalent that works with
> all browsers, as frames do. There are facilities within the existing frames
> model to address almost every concern that I've read from those who oppose
> their usage, and I haven't seen one legitimate concern for dropping them
> (no, I don't need to re-read the "frames are evil" drivel) so AFAICT, there
> isn't a good reason NOT to use frames if they're the best solution to a
> presentational requirement.
>

Ugh! Again...

Simple reason: because a much better implementation can be done via
server-side scripting. Frames was a Netscape invention to accommodate
document modular assembly at a time when server-side technologies were
very limited. That is not the case now, and even Netscape abandoned
using frames shortly after their introduction. Frames are a little like
White-Out, indispensable in the age of typewriters but obsolete in the
age of Word Processors.

It "works" in IE 8 as well, in the same sense as on other browsers you
mentioned: when style sheet support is enabled, it creates a numbered list
with numbering starting at 42.

But it does _not_ work as a replacement for <ol start="42"> in the sense of
creating the same appearance. The left indentation is different, and so is
the spacing between the number and the item text. You can add rules to
affect that, but the effect depends on the browser, as the spacing of the
numbers generated by browsers by default for <ol> may vary.

Now you might say that this is irrelevant and that CSS-generated spacing can
be more consistent and that pages should not rely on details of spacing. And
I might agree, mostly. But you still cannot replace the start="42" attribute
by CSS code that creates the _same_ effect. Similar, maybe essentially
similar, and maybe much better - but still not the same.

And there are lots of web pages that rely in details of formatting, so the
cleanup could actually do some harm.

On 26 mai, 23:52, dorayme <> wrote:
> Authors decide all sorts of things for users. Users often have
> not a clue what they really want to do. Right click and open in
> another tab indeed! Do you really dream that the average person
> on the Clapham bus would know such a thing? There is a super
> idealised caricature of the user that is behind the idea that
> target should *never* be used.

A very wide majority of graphical web browsers (IE7+, Firefox 1+,
Opera 7+, Safari 3+, Konqueror 3+, Chrome 3+) in use today are tab-
capable web browsers and they all have a setting which allow users to
divert a new window (or linked reference with a target attribute) into
a new tab or into the same window. So, for a lot of reasons, the
target attribute, as originally designed, fails (or can not be ensured
that it will succeed as originally designed/planned) for a majority of
people. The least successful one (with regards to opening a new
window) must be <a href="..." target="_blank">.

That's a theoretical benefit - no tangible effect on the functionality or
appearance on the page, _except_ that you may break a page in converting it
(after all, we make mistakes, and computers are great in assisting us there)
and that the page won't look as it used to when CSS is off. Very marginally,
you might achieve some reduction in page size and thereby in load time, if
you manage to replace lots of <font> etc. markup by some simple CSS.
> More consistent look, more consistent
> coding manners, therefore easier to maintain, to do site-wide changes
> if needed.

Maybe - but is there a proof thereof? And maintainability and modifiability
depends on much more than Strict vs. Transitional. To create a really
maintainable and easily modifiable _site_ you would need to redesign it, not
just modify the markup. You should probably then start from selecting or
creating tools and procedures for generating the pages etc., and then you
would basically reconstruct the markup, not just convert it.
> Tuning of options to use is delicate in HTML Tidy when you're beginning
> with
> HTML Tidy.

Thanks for the heads-up. I'll keep avoiding HTML Tidy if I can.
>> 1) <ol start="42"> and <ol value="10">
>
> I would suggest to use counter-reset.

As discussed in another sub-thread, it does not do exactly the same, and it
does not work widely enough to justify the approach in WWW authoring.
>> 2) target attribute
>
> Frames are pretty much obsolete, definitely not recommendable.

The issue was converting from Transitional to Strict by replacing non-Strict
constructs by CSS, not the desirability or usefulness of such constructs.
Millions of pages use the target attribute. Hint: It cannot be replaced by
CSS, but it can be replaced by JavaScript, though here, too, you cannot
achieve _exactly_ the same effect (except by cheating: by using JavaScript
that modifies the document by adding a target attribute!).
>> 3) <small> (no defined counterpart in CSS - operates with a special
>> scale of sizes)
>
> I would suggest CSS declaration
> {font-size: smaller;}
> as a CSS replacement for <small>

One might also say font-size: 10pt, and it _might_ (just as your suggestion
_might_) have the same effect on some browsers under some conditions. Or,
more sensibly, one might say font-size: 85%, and it might, by accident, have
the same effect. The point is that <small> is of its own kind.
>>> 2-
>>> <table bordercolor="color"> . First bordercolor is invalid.
>>
>> Whether it is valid depends on the document type definition.
>
> bordercolor is not in any document type definition that I know of.

Well, that can be arranged. Seehttp://www.cs.tut.fi/~jkorpela/html/own-dtd.html#tagsoup
> I am not sure. I would need to test this. I believe
> bordercolor="color" will be honored in quirks mode in a number of
> browsers with a default solid (or is it outset?) border and a default
> 2px width. When converting to HTML 4.01 strict, <table style="border-
> color: color"> may not suffice.

You're right, bordercolor also sets the border style to solid (as opposite
to outset, which is what most browsers use by default), but it's even more
complex. The effect does not depend on quirks vs. standards mode, but it
depends on browser. On Firefox, bordercolor sets only the color of the
border around the table; on IE, cell borders are affected too.

This is further evidence for my statement that it is not possible to convert
from Transitional to Strict, in a manner that preserves the original
formatting on all browsers, or even in a few major browsers. Moving from
Transitional to Strict thus involves a design change, not just mechanical
replacement.

Neil Gould wrote:
> I agree that server-side scripting provides a lot of capability, but that
> approach adds a lot of complexity to a relatively simple presentational task
> and isn't as universally functional as frames. Although your opinion is not
> uncommon among web programmers, you still haven't provided a good reason why
> frames should be abandoned.
>

For one, savvy folks disable them to prevent falling victim to iframe
injection....

On 27 mai, 11:53, "Jukka K. Korpela" <> wrote:
> GTalbot wrote:
> > CSS replacement for <ol start="42">
> >http://www.gtalbot.org/BrowserBugsSection/css21testsuite/css-replacem...
>
> > 2 rules and 4 declarations is all that is needed.
>
> > It works as expected in Firefox 3.6.3, Opera 10.10, Konqueror 4.4.3,
> > Chrome 5.0.375.55. It should work in IE8.
>
> It "works" in IE 8 as well, in the same sense as on other browsers you
> mentioned: when style sheet support is enabled, it creates a numbered list
> with numbering starting at 42.
>
> But it does _not_ work as a replacement for <ol start="42"> in the sense of
> creating the same appearance. The left indentation is different, and so is
> the spacing between the number and the item text. You can add rules to
> affect that, but the effect depends on the browser, as the spacing of the
> numbers generated by browsers by default for <ol> may vary.
>
> Now you might say that this is irrelevant and that CSS-generated spacing can
> be more consistent and that pages should not rely on details of spacing. And
> I might agree, mostly. But you still cannot replace the start="42" attribute
> by CSS code that creates the _same_ effect. Similar, maybe essentially
> similar, and maybe much better - but still not the same.

It still does not perfectly look the same; it still does not perfectly
appear the same. You may have to add a few more properties to adjust
indentation here, spacing there, etc.
> And there are lots of web pages that rely in details of formatting, so the
> cleanup could actually do some harm.

You have to test and verify before copying such code. And adjust
accordingly.

On 27 May 2010, "Jonathan N. Little" <> wrote:
> Neil Gould wrote:
>
>> I agree that server-side scripting provides a lot of capability, but
>> that approach adds a lot of complexity to a relatively simple
>> presentational task and isn't as universally functional as frames.
>> Although your opinion is not uncommon among web programmers, you
>> still haven't provided a good reason why frames should be abandoned.
>>
>
> For one, savvy folks disable them to prevent falling victim to iframe
> injection....

On 27 May 2010, "Jukka K. Korpela" <> wrote:
> The issue was converting from Transitional to Strict by replacing
> non-Strict constructs by CSS, not the desirability or usefulness of
> such constructs. Millions of pages use the target attribute. Hint: It
> cannot be replaced by CSS, but it can be replaced by JavaScript,
> though here, too, you cannot achieve _exactly_ the same effect
> (except by cheating: by using JavaScript that modifies the document
> by adding a target attribute!).

That isn't "cheating"; that's using the old noodle as God intended.

As for the target attribute, I earnestly believe that the w3c was
completely ill-advised in devalidating it as they did. A better
approach would have been to try to make it more useful for what it was
originally intended as in the first place.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!