validate HTML

S

shank

I'm on the W3 website and trying to validate my page. A BUNCH of problems
showed up. I'm using Dreamweaver MX and use it to create the code. This
should be a no brainer, but checking it for 4.01 transitional is dismal.

<body bgcolor="#FFFFFF" leftmargin="0" topmargin="0" marginwidth="0"
marginheight="0">

One of the red flags is that the above margins are invalid attributes of the
<body> tag.
OK... How do I set my page to have "0" margins?
And why would Dreamweaver stick them in there?

Can someone give me a clue to conforming to the validation process?
I'm using vbScript and ASP and I'm not sure I will ever be able to comply
100%.
Has anyone else run into this?

thanks!
 
B

brucie

I'm on the W3 website and trying to validate my page. A BUNCH of problems
showed up. I'm using Dreamweaver MX and use it to create the code. This
should be a no brainer, but checking it for 4.01 transitional is dismal.

new documents should use the strict DTD
<body bgcolor="#FFFFFF" leftmargin="0" topmargin="0" marginwidth="0"
marginheight="0">

One of the red flags is that the above margins are invalid attributes of the
<body> tag.
OK... How do I set my page to have "0" margins?
body{margin:0;padding:0;}

And why would Dreamweaver stick them in there?

its a poor quality editor. just because "everybody" uses it doesn't
necessarily mean its good. look at IE.
Can someone give me a clue to conforming to the validation process?

hand code. you'll know what every line does and why its there.
I'm using vbScript and ASP and I'm not sure I will ever be able to comply
100%.

any page can validate 100%
 
A

Adrienne

I'm on the W3 website and trying to validate my page. A BUNCH of
problems showed up. I'm using Dreamweaver MX and use it to create the
code. This should be a no brainer, but checking it for 4.01
transitional is dismal.

<body bgcolor="#FFFFFF" leftmargin="0" topmargin="0" marginwidth="0"
marginheight="0">

One of the red flags is that the above margins are invalid attributes
of the
<body> tag.
OK... How do I set my page to have "0" margins?
And why would Dreamweaver stick them in there?

Can someone give me a clue to conforming to the validation process?
I'm using vbScript and ASP and I'm not sure I will ever be able to
comply 100%.
Has anyone else run into this?

thanks!

You're familiar with includes, so start including a style sheet definition
for your pages.

<link rel="stylesheet" href="style.css" type="text/css">

*** style.css ***
body {margin:0}

You might want to think about using another editor. I think you would be
happy with http:///www.html-kit.com , has syntax coloring, plugins (spell
check, Thesaurus, ASP specific tools), scripting to define frequently used
code (like sql select statements), HTML-Tidy, integrates with TopStyle for
stylesheets. Best of all, it's free.

Trust me, even though you're writing ASP, you'll be able to validate if you
stick to keeping HTML for the markup, CSS for presentation, and ASP/SQL for
serverside.

One more little hint: escape &'s as &amp;

CSS Tutorial: http://www.w3schools.com/css/default.asp
 
B

brucie

body {margin:0}

margin on the <body> is actually incorrect. you cant have a margin
outside of the available canvas area. operas use of padding on the
<body> is correct.
 
A

Adrienne

Gazing into my crystal ball I observed brucie <[email protected]
html.org> writing in
margin on the <body> is actually incorrect. you cant have a margin
outside of the available canvas area. operas use of padding on the
<body> is correct.

Thanks, brucie. Another mystery of life solved.
 
D

DU

shank said:
I'm on the W3 website and trying to validate my page. A BUNCH of problems
showed up. I'm using Dreamweaver MX and use it to create the code. This
should be a no brainer, but checking it for 4.01 transitional is dismal.

At this point, you should use a strict DTD and validate your document.
<body bgcolor="#FFFFFF" leftmargin="0" topmargin="0" marginwidth="0"
marginheight="0">

One of the red flags is that the above margins are invalid attributes of the
<body> tag.
OK... How do I set my page to have "0" margins?
And why would Dreamweaver stick them in there?

Can someone give me a clue to conforming to the validation process?
I'm using vbScript and ASP and I'm not sure I will ever be able to comply
100%.
Has anyone else run into this?

thanks!

It's not recommendable to remove all padding and margin on the element
(body) rendering your content. Every known documents appearing on every
possible media use some kind of padding or margins. I personally use
this for all my pages.

<style type="text/css">
body {margin:16px; padding:0px; color:black; background-color:white;}
</style>

Browsers all have default margin (or padding like Opera 7) values for
the body element.

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunclear/Netscape7/Netscape7Section.html
 
D

DU

brucie said:
In post <[email protected]>
Adrienne said...




margin on the <body> is actually incorrect. you cant have a margin
outside of the available canvas area.

What are you saying exactly? Margin on the body element is rendered in
all W3C CSS1 compliant browsers. I don't understand why you said what
you said.

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunclear/Netscape7/Netscape7Section.html
 
W

Whitecrest

its a poor quality editor. just because "everybody" uses it doesn't
necessarily mean its good. look at IE.

Well personal opinion....
hand code. you'll know what every line does and why its there.

You do not need to hand code every line to know what it does.
any page can validate 100%

I will agree there. But validating the code does not mean that the page
looks good. You can have a mighty shitty looking validated page.
 
B

brucie

What are you saying exactly? Margin on the body element is rendered in
all W3C CSS1 compliant browsers. I don't understand why you said what
you said.

if you consider the <body> element to be the available canvas area and
not the <html> element then padding is the space between the <body>
element and its content. that makes sense. i don't think anyone would
disagree with that.

<html>
<head>
</head>
<body>
<padding>
content of site
<padding>
</body>
</html>

if you consider <html> to be the available canvas area then margin is
the space between the <html> element and the <body> and <head>
element.

<html>
<margin>
<head>
</head>
<body>
content of site
</body>
<margin>
</html>


that just doesn't look right. its more logical to use padding on the
<body> element and the suggested CSS2 style sheet has padding 8px, no
margin.
 
D

DU

brucie said:
In post <[email protected]>
DU said...




if you consider the <body> element to be the available canvas area and
not the <html> element then padding is the space between the <body>
element and its content. that makes sense. i don't think anyone would
disagree with that.

Are you saying that borders and padding on the root element (html)
should not be rendered? Are you saying that margins on the body element
shouldn't be rendered? Are you saying that the body element can not
render margins? Are you saying that the body element does not comply
with CSS1 box model?
<html>
<head>
</head>
<body>
<padding>
content of site

What if the author inserts here:
<padding>
</body>
</html>

if you consider <html> to be the available canvas area then margin is
the space between the <html> element and the <body> and <head>
element.

Is that so? margin on the body element should only be rendered if the
head has the rule {display:block}?
<html>
<margin>
<head>
</head>
<body>
content of site
</body>
<margin>
</html>

Regardless of the way you define what is the available canvas area, I
still don't see why margins on the body element should not (or can not
or are preferable not to) be used in a style sheet in any/all conditions.
that just doesn't look right. its more logical to use padding on the
<body> element and the suggested CSS2 style sheet has padding 8px, no
margin.

Margins are part of the CSS1 box model. Regardless of how you define the
available canvas area and why you need to define it, I don't see why
body {padding:<value>} is any better or superior to body
{margin:<value>}. IMO, these properties can both be used for the body
element and both should be rendered if used. FWIW, CSS2.1 uses margins
on the body element, not padding.

http://www.w3.org/TR/CSS21/sample.html

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunclear/Netscape7/Netscape7Section.html
 
B

brucie

Well personal opinion....

not really. if you purchase a program you want it to do what its
designed to do and do it properly. if you purchase a media player you
want it to be able to play media and do it properly. if you purchase a
graphics editor you want it to be able to edit graphics and do it
properly. why would or should a html editor be any different?

if browsers didn't have error correction there would be very few html
editors on the market or they would do what they were designed to do
properly.

DW/FP/etc etc users really need to ask themselves why they paid so
much for a program that doesn't do what it was designed to do properly
and for some reason think that its acceptable that it doesn't.

would anyone think it acceptable if their graphics editor didn't edit
graphics properly? media player not play media properly? i think not.
why then is it acceptable for a html editor?
 
D

DU

brucie said:
In post <[email protected]>
Whitecrest said...




not really. if you purchase a program you want it to do what its
designed to do and do it properly. if you purchase a media player you
want it to be able to play media and do it properly. if you purchase a
graphics editor you want it to be able to edit graphics and do it
properly. why would or should a html editor be any different?

if browsers didn't have error correction there would be very few html
editors on the market or they would do what they were designed to do
properly.

DW/FP/etc etc users really need to ask themselves why they paid so
much for a program that doesn't do what it was designed to do properly
and for some reason think that its acceptable that it doesn't.

would anyone think it acceptable if their graphics editor didn't edit
graphics properly? media player not play media properly? i think not.
why then is it acceptable for a html editor?

I agree entirely 100% with you on this. I agree that this Dream Weaver
MX html editor tool can be, should be, ought to be improved furthermore.
But I can't resist the temptation to say that some people obviously
think that Dream Weaver MX is good enough:

"The following authoring tools adhere to the W3 standards. (...)
Macromedia™ Dreamweaver™ MX"
http://devedge.netscape.com/toolbox/tools/2003/authoring/

"Macromedia Dreamweaver MX
W3C valid XHTML? Yes"
http://www.backupbrain.com/2002_11_17_archive.html#a003122

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunclear/Netscape7/Netscape7Section.html
 
B

brucie

Are you saying that borders and padding on the root element (html)
should not be rendered?

if you consider the <html> element the available canvas area and stick
a margin or border on it then where is the margin or border supposed
to go? the margin and border would be outside the available canvas
area.

<html> element as the available canvas area:

+<html>---available canvas area +---+
margin - border | padding <body></body> padding | border - margin
+----------------------------</html>+

<body> element as the available canvas area

+<body>---available canvas area +---+
margin - border | padding <site content> padding | border - margin
+----------------------------</body>+

some problem in each case. the border and margins are outside the
available canvas area.
Are you saying that margins on the body element
shouldn't be rendered?

it all comes down to what is the available canvas area of the browser.
is it the <html> element or the <body> element?

its logical to consider the <body> element the available canvas area,
not the <html> element. the <body> is the documents content, the bit
thats displayed in the available canvas area. applying a margin or
border would place the margin or border outside the available canvas
area.
Are you saying that the body element can not
render margins?

i'm saying that the <body> element is the available canvas area of the
browser, not the <html> element. applying a margin or border on the
Regardless of the way you define what is the available canvas area,

what the available canvas area is is the point of it all. it is either
the <html> element or the <body> element.

if the available canvas area is the <html> element margins and borders
should not apply but can be applied to the <body> element.

if the available canvas area is the <body> element then margins and
borders should not apply.

you cant place margins and borders outside the available canvas area.
 
D

DU

brucie said:
In post <[email protected]>
DU said...




if you consider the <html> element the available canvas area and stick
a margin or border on it then where is the margin or border supposed
to go? the margin and border would be outside the available canvas
area.

<html> element as the available canvas area:

+<html>---available canvas area +---+
margin - border | padding <body></body> padding | border - margin
+----------------------------</html>+

<body> element as the available canvas area

+<body>---available canvas area +---+
margin - border | padding <site content> padding | border - margin
+----------------------------</body>+

some problem in each case. the border and margins are outside the
available canvas area.

I see what you mean. But "available canvas area" is nowhere defined in
the specs. Neither are "visible canvas area" or "rendered canvas area".
"canvas" and "initial containing block" are though.

The diagram of the box model is clear to me and AFAICS, the body and the
html elements are block-level elements which should conform to the CSS1
box model.
it all comes down to what is the available canvas area of the browser.
is it the <html> element or the <body> element?


its logical to consider the <body> element the available canvas area,
not the <html> element. the <body> is the documents content, the bit
thats displayed in the available canvas area. applying a margin or
border would place the margin or border outside the available canvas
area.




i'm saying that the <body> element is the available canvas area of the
browser, not the <html> element. applying a margin or border on the



what the available canvas area is is the point of it all. it is either
the <html> element or the <body> element.

if the available canvas area is the <html> element margins and borders
should not apply but can be applied to the <body> element.

if the available canvas area is the <body> element then margins and
borders should not apply.

you cant place margins and borders outside the available canvas area.

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunclear/Netscape7/Netscape7Section.html
 
B

brucie

I see what you mean. But "available canvas area" is nowhere defined in
the specs. Neither are "visible canvas area" or "rendered canvas area".
"canvas" and "initial containing block" are though.

but what is the initial containing block? thats what i'm getting at.
is it the <body> element or the <html> element or something
mysterious?

if its the <html> element then

html{margin:10px;border:1px solid green;}

should not apply. IE6 gets the margin right (ignores it) but screws up
on the border. both opera and mozilla get it wrong, they apply both
the margin and border.

The diagram of the box model is clear to me and AFAICS, the body and the
html elements are block-level elements which should conform to the CSS1
box model.

as browsers apply borders and margins to the <html> and <body>
elements then the initial containing block at the moment can only be
defined as "something mysterious"
A <p> with the rule position:absolute; top:-200px; left:200px; (as given
in my previous post) should not be in your "available canvas area" then?

browsers don't display it, its removed from the normal document flow
and placed outside the initial containing block. if it was part of the
initial containing block the block is supposed to grow to hold its
content and browsers are supposed to supply scrollbars if the initial
containing block is smaller than the viewport.

but! the initial containing block grows to accommodate elements
absolutely or relatively positioned with positive values greater than
the viewport and scrollbars are supplied. so why doesn't the initial
containing block accommodate elements positioned with negative values
or change the negative value to the nearest supported value which
would be zero?

my head hurts
 
M

Mark Parnell

brucie said:
but what is the initial containing block? thats what i'm getting at.
is it the <body> element or the <html> element or something
mysterious?

The way I think about it is that since you can set styles on the html
if its the <html> element then

html{margin:10px;border:1px solid green;}

should not apply. IE6 gets the margin right (ignores it) but screws up
on the border. both opera and mozilla get it wrong, they apply both
the margin and border.

if the <body> element is the initial containing block then all three
browsers screw it up, they apply the margin and border.

Agreed.


as browsers apply borders and margins to the <html> and <body>
elements then the initial containing block at the moment can only be
defined as "something mysterious"

So it seems. :-S
browsers don't display it, its removed from the normal document flow
and placed outside the initial containing block. if it was part of the
initial containing block the block is supposed to grow to hold its
content and browsers are supposed to supply scrollbars if the initial
containing block is smaller than the viewport.

Yes...

but! the initial containing block grows to accommodate elements
absolutely or relatively positioned with positive values greater than
the viewport and scrollbars are supplied.
Yes...

so why doesn't the initial
containing block accommodate elements positioned with negative values
or change the negative value to the nearest supported value which
would be zero?

Because then where the paragraph has been moved to would become the
beginning of the canvas (i.e. top: 0;), so the paragraph would need to be
moved another 200px up, so the canvas would expand again, so where the
paragraph has been moved to would become the beginning of the canvas....
my head hurts

I'm not surprised. Mine too.
 
R

rf

Mark Parnell said:
The way I think about it is that since you can set styles on the html
element, but nothing bigger, <html> would be the initial containing block.
Though it could be something mysterious, of course. :)

The (CSS2) spec is quite clear on this. The initial containing block is
generated by the root of the document tree, the html element.

I'm not surprised. Mine too.

<aol>me too</aol>

Cheers
Richard.
 
D

DU

brucie said:
In post <[email protected]>
DU said...


Section 14.2 of both CSS2 and CSS2.1 contradict the above.


I think you should have defined this as "viewable canvas area" from the
beginning: it seems to me to be a better wording of what you were trying
to explain.
but what is the initial containing block? thats what i'm getting at.
is it the <body> element or the <html> element or something
mysterious?

if its the <html> element then

html{margin:10px;border:1px solid green;}

should not apply. IE6 gets the margin right (ignores it) but screws up
on the border. both opera and mozilla get it wrong, they apply both
the margin and border.

if the <body> element is the initial containing block then all three
browsers screw it up, they apply the margin and border.




as browsers apply borders and margins to the <html> and <body>
elements then the initial containing block at the moment can only be
defined as "something mysterious"




browsers don't display it, its removed from the normal document flow
and placed outside the initial containing block.

No. It is placed inside the initial containing block. That's per specs.

[If we position "div1":
#div1 { position: absolute; left: 50px; top: 50px }
its containing block is no longer "body"; it becomes the initial
containing block (since there are no other positioned ancestor boxes).]
http://www.w3.org/TR/CSS21/visudet.html#containing-block-details


if it was part of the
initial containing block the block is supposed to grow to hold its
content

The "initial containing block" is not the document root element, is not
the body element and is not an html element at all.

and browsers are supposed to supply scrollbars if the initial
containing block is smaller than the viewport.

but! the initial containing block grows to accommodate elements
absolutely or relatively positioned with positive values greater than
the viewport and scrollbars are supplied.

Where do you read this? Section 10.1 of CSS2.1 clarified and corrected
the previous CSS2 TR. So you must now refer to that section. The CSS2.1
Working Draft of September 15th 2003 still kept what was in the previous
CSS2.1 Working Draft.

http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

so why doesn't the initial
containing block accommodate elements positioned with negative values
or change the negative value to the nearest supported value which
would be zero?

my head hurts

"The containing block in which the root element lives is chosen by the
user agent. (It could be related to the viewport.) This containing block
is called the initial containing block."
http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

This is the best schema for I.C.B.:

+--------------------+
| I.C.B. |
| +--------------+ |
| | html | |
| |+------------+| |
| || body || |
| || || |
| || || |
| || || |
| || || |
| || || |
| |+------------+| |
| +--------------+ |
| |
+--------------------+


DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunclear/Netscape7/Netscape7Section.html
 
D

DU

rf said:
The (CSS2) spec is quite clear on this.

Quite clear but wrong. CSS2.1 corrected this.
This has been discussed before a lot.

The initial containing block is
generated by the root of the document tree, the html element.

As far as I understand things, root element and root of document tree
are different things. Document root element is of nodeType ELEMENT_NODE
(nodeName HTML): that is a certainty.
As far as I understand things (and here I might be wrong), root of
document tree is of nodeType DOCUMENT_NODE (nodeName #document).
<aol>me too</aol>

Cheers
Richard.

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunclear/Netscape7/Netscape7Section.html
 
B

brucie

Section 14.2 of both CSS2 and CSS2.1 contradict the above.

to cut a long debate short i do not agree with the CSS1/2
recommendations or browser behavior and CSS2.1 is a working draft yet
to be submitted for consideration. it is not a recommendation or
specification to be followed at the moment.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top