Re: Material that does no scroll in web page

GTalbot wrote:

So if a main browser manufacturer with all its huge financial, huge
technical resources still can not provide a browser version that can
support a 10 years old CSS specification,

To my knowledge, there is no web browser that supports the entire CSS2
specification. Obviously, CSS2 support is much better in Firefox/Opera,
but I'm sure if it was so easy to upgrade CSS support in IE, Microsoft
would have done so already. Don't forget that such descisions are not
ruled by technical considerations alone. Backward compatibility is a
huge issue.

then it's time to invite users/visitors to switch or to upgrade.

That's not your decision but that of the user.

In the web and in this web inter-connection logic, browser
manufacturers have a responsibility. Web authors (and content
providers at large) have a responsibility. Users have also a part, a
role, a responsibility as well.

Try to tell that last sentence to a user who's ready to spend money on
your business website. "Sorry, your web browser from 2001 is too old and
sucks. Our pages will look cra... uh, I mean degrade gracefully, but
that's not our fault -- it's yours, because you, dear customer, have
responsibilies as well. Please don't go to our competitor's website,
anyway. Thank you."

I can not agree with you on this: this is not what my experience leads
me to conclude. If the web author follows best coding practices

It's hard to tell which coding practices are best, isn't it? What
constitutes a good coding practice? That which is used on most
successful websites such as Amazon and eBay? Table layouts and ugly
inline styles abound on their pages. That tells you something about how
horrible the current situation of web authoring languages really is.

In fact, I've personally been studying and teaching how to use semantic
markup and tableless layouts for about 6 years, and yet I don't see any
progress at all. No professional website used by myself on a daily basis
has even remotely clean HTML code. It seems that if you want to play
safe, you just take a <table> and forget about semantic markup. It's
disappointing, but it's reality, and it frustrates me to a point where I
almost stop caring.

You have to choose between putting hacks into the markup (by abusing
tables for layout) and putting them into the stylesheet (by abusing
properties for something they were never intended for).


I can not agree with you. You give a general perspective, opinion. No
example, no concrete reference I can examine...

Fine, here's an example of a hack for creating a three-colum layout on a
web page:

<div id="content">
....
</div>
<div id="navigation">
....
</div>
<div id="related">
....
</div>

#content { margin-left:20em; margin-right:20em }
#navigation {position:absolute; left:0; top:0; width:20em }
#related {position:absolute; right:0; top:0; width:20em }

It's a hack because the stylesheet abuses the "position" and "margin"
properties for something they have not been intended for. Just take a
look and examine the semantics more closely: #content should have a left
margin of 20em, yet when you look at the page there will be no visible
left margin at all. Stating that you want a margin when you actually
want something else is not that much different from stating that
something is tabular data when it really is not.

But it's getting worse: the code introduces dependencies. The value of
the "margin-left"/"margin-right" properties in one declaration depend
entirely on the values of the "width" properties in other declarations.
If you would like to change the width of the navigation column, you
cannot just say "width:23em", you have to edit other parts of the code
as well.

Here's another example of a CSS hack:

<div id="navigation">
....
</div>
<div id="related">
....
</div>
<div id="content">
....
</div>

#navigation { float:left; width:20% }
#related { float:right; width:20% }
#content { width:50% }

This is a hack because it introduces dependencies between declarations
(see above) and even stronger dependencies between the HTML code and the
stylesheet (possible ways of ordering the columns depend on the order of
the elements in the markup), and because it abuses the "float" property.

Look what the specification says on "float" [1]. The property is clearly
designed to be used for giving designers a way to flow text around some
block, not to create multi-column layouts.


I stand by my opinion that it's impossible to write semantically correct
CSS 2.1 code for creating multi-column layouts. It *will* be possible in
CSS3's Advanced Layout module [2], provided it will ever be finished.
With the properties explained in that draft, it will be possible to
write a stylesheet that actually says "I want a three-column layout with
A on the left, B in the middle, C on the right, and D at the bottom"
without any indirections, clever tricks, or dependencies.

I presume the code would look like this:

body { display: "abc"
".d." }
#navigation { position:a }
#content { position:b }
#related { position:c }
#footer { position:d }

(Something may be wrong with this, I am not really that familiar with
the current draft!)


I trust that you handle CSS pretty well and know how to use it as
efficiently as possible. I'm just arguing that complex CSS layouts are
bound to remain hacks simply because they *cannot* be done otherwise.

If CSS 2.1 was perfectly suited for all design needs of today, there
would be no need for CSS3.

X-Post & Followup to comp.infosystems.www.authoring.stylesheets


[1] http://www.w3.org/TR/CSS21/visuren.html#floats
[2] http://www.w3.org/TR/css3-layout/


--
Christian Hackl

Christian Hackl wrote:

GTalbot wrote:

So if a main browser manufacturer with all its huge financial, huge
technical resources still can not provide a browser version that can
support a 10 years old CSS specification,

To my knowledge, there is no web browser that supports the entire CSS2
specification. Obviously, CSS2 support is much better in Firefox/Opera,
but I'm sure if it was so easy to upgrade CSS support in IE, Microsoft
would have done so already. Don't forget that such descisions are not
ruled by technical considerations alone. Backward compatibility is a
huge issue.

True, but it is a matter of disparity. IE misses on a much larger chunk
and what it does "support" is riddled with numerous bugs and sometimes
just plain incorrect implementation. If backward compatibility then you
would expect that their different versions would handle their
proprietary methods consistently, but they don't. One could argue that
marketshare drives them to resist, non-compliance keeps designers
perpetuating non-compliant designs thereby maintaining their
marketshare... Once their marketshare stated to slip to an alternate
browser, *only then* did MS decide to "embrace" standards, sort of...

then it's time to invite users/visitors to switch or to upgrade.

That's not your decision but that of the user.

In the web and in this web inter-connection logic, browser
manufacturers have a responsibility. Web authors (and content
providers at large) have a responsibility. Users have also a part, a
role, a responsibility as well.

Try to tell that last sentence to a user who's ready to spend money on
your business website. "Sorry, your web browser from 2001 is too old and
sucks. Our pages will look cra... uh, I mean degrade gracefully, but
that's not our fault -- it's yours, because you, dear customer, have
responsibilies as well. Please don't go to our competitor's website,
anyway. Thank you."

Well when it isn't tied to the OS, the browser can auto upgrade as
non-IE browsers do so it could be not a issue.

I can not agree with you on this: this is not what my experience leads
me to conclude. If the web author follows best coding practices

It's hard to tell which coding practices are best, isn't it? What
constitutes a good coding practice? That which is used on most
successful websites such as Amazon and eBay? Table layouts and ugly
inline styles abound on their pages. That tells you something about how
horrible the current situation of web authoring languages really is.

Yep, and you can choose to perpetuate it or change. There are benifits
to change.

In fact, I've personally been studying and teaching how to use semantic
markup and tableless layouts for about 6 years, and yet I don't see any
progress at all. No professional website used by myself on a daily basis
has even remotely clean HTML code. It seems that if you want to play
safe, you just take a <table> and forget about semantic markup. It's
disappointing, but it's reality, and it frustrates me to a point where I
almost stop caring.

Don't mean you have to create *your* sites that way, who is pointing the
gun to your head?

You have to choose between putting hacks into the markup (by abusing
tables for layout) and putting them into the stylesheet (by abusing
properties for something they were never intended for).


I can not agree with you. You give a general perspective, opinion. No
example, no concrete reference I can examine...

Fine, here's an example of a hack for creating a three-colum layout on a
web page:

div id="content"
...
/div
div id="navigation"
...
/div
div id="related"
...
/div

#content { margin-left:20em; margin-right:20em }
#navigation {position:absolute; left:0; top:0; width:20em }
#related {position:absolute; right:0; top:0; width:20em }

It's a hack because the stylesheet abuses the "position" and "margin"
properties for something they have not been intended for.

How's that?

Just take a
look and examine the semantics more closely: #content should have a left
margin of 20em, yet when you look at the page there will be no visible
left margin at all. Stating that you want a margin when you actually
want something else is not that much different from stating that
something is tabular data when it really is not.

The margin it to clear the "position:absolute" block that is not in the
page flow! This is correct behavior and proper method.

But it's getting worse: the code introduces dependencies. The value of
the "margin-left"/"margin-right" properties in one declaration depend
entirely on the values of the "width" properties in other declarations.
If you would like to change the width of the navigation column, you
cannot just say "width:23em", you have to edit other parts of the code
as well.

Here's another example of a CSS hack:

div id="navigation"
...
/div
div id="related"
...
/div
div id="content"
...
/div

#navigation { float:left; width:20% }
#related { float:right; width:20% }
#content { width:50% }

This is a hack because it introduces dependencies between declarations
(see above) and even stronger dependencies between the HTML code and the
stylesheet (possible ways of ordering the columns depend on the order of
the elements in the markup), and because it abuses the "float" property.

Where does it say one rule is not supposed to rely or depend on another?
What about cascade?

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

In article <fmgdc7$cqp$1 (AT) aioe (DOT) org>,
Christian Hackl <hacki (AT) sbox (DOT) tugraz.at> wrote:

It's hard to tell which coding practices are best, ....

In fact, I've personally been studying and teaching how to use semantic
markup and tableless layouts for about 6 years, and yet I don't see any
progress at all. No professional website used by myself on a daily basis
has even remotely clean HTML code. ...

You have to choose between putting hacks into the markup (by abusing
tables for layout) and putting them into the stylesheet (by abusing
properties for something they were never intended for).

....
#navigation { float:left; width:20% }
#related { float:right; width:20% }
#content { width:50% }

This is a hack because it introduces dependencies between declarations
(see above) and even stronger dependencies between the HTML code and the
stylesheet (possible ways of ordering the columns depend on the order of
the elements in the markup), and because it abuses the "float" property.

Look what the specification says on "float" [1]. The property is clearly
designed to be used for giving designers a way to flow text around some
block, not to create multi-column layouts.


I stand by my opinion that it's impossible to write semantically correct
CSS 2.1 code for creating multi-column layouts.

You are going to have a hard time getting folks to understand you
properly without a bit more work on your argument here. Perhaps I
can direct you to the parts you should be more clearly
articulating.

The justified frowning on use of tables for layouts is based on
something. First, you need to outline what it is based upon. It
is not based on the mere superficiality that tables were created
for tabular data. Anyone in this area worth his salt would have a
more substantial reason. It is well known that many things
created for one purpose can be intelligently used for another.

It is sometimes said in criticism of a newbie that they are using
the wrong tool. What is meant by the serious advisor is not the
silly thing that it is a tool that was not created for the
purpose but that it is an inefficient tool in this particular
context. Inefficiency is something that includes many things in
this area. It includes author website construction and update
time and effort, the ease of function and understandability
across browsers and platforms for users with differing abilities,
capacities and devices.

You appear to me to be basing your argument on the superficiality
mentioned above. It is no big deal that floats were created for
an express purpose but are being used for quite a different
purpose. The real question, the deeper one, is simply: is this a
bad thing? The people who argue against the unrestrained use of
tables for layout are arguing that this is a bad adaptation (for
reasons you will be familiar with). You need to show a similar
strong criticism of css float (to take an example) along the
lines that it is bad, it has bad consequences.

You appear to me not to be grasping the basic distinction even in
the ideal between semantic markup and styling, between content
and presentation. If the html is all good and true and people
have no trouble understanding the content without any css styling
turned on, then that is a not a bad achievement. Not possible
with the unrestrained use of tables. If a float is made to make a
margin, whether the margin looks like a margin in a kid's
schoolbook or not, so what? It is not a bad thing.

--
dorayme

On 14 jan, 14:32, Christian Hackl <ha... (AT) sbox (DOT) tugraz.at> wrote:

GTalbot wrote:
So if a main browser manufacturer with all its huge financial, huge
technical resources still can not provide a browser version that can
support a 10 years old CSS specification,

To my knowledge, there is no web browser that supports the entire CSS2
specification.
Obviously, CSS2 support is much better in Firefox/Opera,
but I'm sure if it was so easy to upgrade CSS support in IE, Microsoft
would have done so already.

After 10 years, the biggest software manufacturer on this planet with
all its technical, financial capabilities is not able to achieve more
than 56% of support of the entire CSS 2 spec. when 3 other smaller
browser manufacturer have around 90% and that for over 3 years or so?

Microsoft had everything in their hands:
- undisputed market dominance since 1999
- lots of time since 1998: 10 years
- commitment claims in lots of webpages that Microsoft would continue
to implement web standards
- huge financial capabilities
- human resources
- technical resources of all kinds

After 10 years, you're telling me that it's not so easy for Microsoft
to upgrade CSS support in IE??? And I'm not even mentioning the huge
numbers of bugs, CSS bugs, DOM bugs testcase-ed, demontrated in IE 6
on top of that.

Microsoft had all of the ingredients and opportunity to implement
correctly and completely HTML 4.01, CSS 2.x, DOM 1 & 2 and many other
W3C approved specs during those 10 years. No one can seriously argue
this.

Don't forget that such descisions are not
ruled by technical considerations alone. Backward compatibility is a
huge issue.

They slowed down implementing CSS and they stopped fixing the bugs and
instead decided to care, to cherish for backward-compatibility instead
of truly chosing the web standards way and manners. Remember the CSS1
box model and how it was implemented by Internet Explorer?
http://en.wikipedia.org/wiki/Interne..._box_model_bug

then it's time to invite users/visitors to switch or to upgrade.

That's not your decision but that of the user.

You visit a site with IE6. The web author can invite you (or suggest
you) to switch or to upgrade. There is no problem with that. As long
as some explanations and diplomacy is used. Rudeness and giving orders
is not what I suggested.

I have seen good examples of this in the past...

In the web and in this web inter-connection logic, browser
manufacturers have a responsibility. Web authors (and content
providers at large) have a responsibility. Users have also a part, a
role, a responsibility as well.

Try to tell that last sentence to a user who's ready to spend money on
your business website. "Sorry, your web browser from 2001 is too old and
sucks. Our pages will look cra... uh, I mean degrade gracefully, but
that's not our fault -- it's yours, because you, dear customer, have
responsibilies as well. Please don't go to our competitor's website,
anyway. Thank you."

Your words. Not mine. Your words are truly disrespectful, cynical and
arrogant.

Again: web visitors have a responsibility. No matter how you see it,
web users have responsibilities.
Beyond accessibility to content and navigation functionality, the
responsibility of the web author ends: the responsibility for a better
surfing should shift to the user. Downloading and installing a free
software like Firefox 2.0.0.11, Opera 9.25, Safari 3.0.4 (or even
Internet Explorer 7) takes a few minutes, will bring all kinds of
benefits (tab browsing, better security, more features, etc).
Addressing the intelligence of the user and explaining him the
benefits gained and the respective responsibility of the 3 parties
involved (browser vendor, web author, web visitor) toward a web
interoperability/accessibility has a lot more chance of being fruitful
than to address visitors with arrogance, insult, uncalled/unprovoked
cynism like your words do.

In mid 2004, US-Cert, a US government organization, recommended to web
users to stop using Internet Explorer. Remember that? In January 2007,
a Washington Post journalist established that IE users were exposed
during 284 days in 2006 while Firefox users were only for 9 days. And
you believe we shouldn't invite users to switch or at least to
upgrade?

I can not agree with you on this: this is not what my experience leads
me to conclude. If the web author follows best coding practices

It's hard to tell which coding practices are best, isn't it? What
constitutes a good coding practice?

Well, if you visit a few sites, read articles, buy a few books, attend
a few conferences, follow web authoring courses, do a few websites,
discuss/listen about coding issues or problems in web authoring/
programming newsgroups, etc... eventually, you will know more of or
develop better coding practices.

Some recommendable webpages on good coding practices:

Web standards checklist by Russ Weakley
http://www.maxdesign.com.au/presentation/checklist.htm

W3C Quality Assurance tips for webmasters (17 for now)
http://www.w3.org/QA/Tips/

Truth & Consequences of web site design by Chris Beal
http://pages.prodigy.net/chris_beall/TC/index.html
just excellent!

Opquast best practices
http://en.opquast.com/bonnes-pratiques/

Dive Into Accessibility: 30 days to a more accessible web site
http://diveintoaccessibility.org/table_of_contents.html

That which is used on most
successful websites such as Amazon and eBay?

No. A successful website like Amazon or eBay does not constitute
necessarly a source of good, recommendable coding practice per se.
Amazon and eBay are not necessarly a school for better coding
practices or improved/increased coding experience.

Table layouts and ugly
inline styles abound on their pages. That tells you something about how
horrible the current situation of web authoring languages really is.

In fact, I've personally been studying and teaching how to use semantic
markup and tableless layouts for about 6 years, and yet I don't see any
progress at all. No professional website used by myself on a daily basis
has even remotely clean HTML code. It seems that if you want to play
safe, you just take a <table> and forget about semantic markup.

Your decision. Not mine.

It's
disappointing, but it's reality, and it frustrates me to a point where I
almost stop caring.

You have to choose between putting hacks into the markup (by abusing
tables for layout) and putting them into the stylesheet (by abusing
properties for something they were never intended for).

I can not agree with you. You give a general perspective, opinion. No
example, no concrete reference I can examine...

Fine, here's an example of a hack for creating a three-colum layout on a
web page:

div id="content"
...
/div
div id="navigation"
...
/div
div id="related"
...
/div

#content { margin-left:20em; margin-right:20em }
#navigation {position:absolute; left:0; top:0; width:20em }
#related {position:absolute; right:0; top:0; width:20em }

No url. No webpage. It's difficult to follow you.

It's a hack because the stylesheet abuses the "position" and "margin"
properties for something they have not been intended for.

I don't understand you. You are saying we should not position page
division(s) in the margin area of another page division because margin
and position were not designed or intended to do that...

Just take a
look and examine the semantics more closely: #content should have a left
margin of 20em, yet when you look at the page there will be no visible
left margin at all.

There is a left margin. It may not be "visible" as you say. It's only
"covered" by an abs. pos. element. It's quite a stretch to call this a
code abuse.

Stating that you want a margin when you actually
want something else is not that much different from stating that
something is tabular data when it really is not.

The same layout could have been achieved with a few other different
CSS columnar layout design.

But it's getting worse: the code introduces dependencies. The value of
the "margin-left"/"margin-right" properties in one declaration depend
entirely on the values of the "width" properties in other declarations.
If you would like to change the width of the navigation column, you
cannot just say "width:23em", you have to edit other parts of the code
as well.

So? So what?

Lots of coding introduce dependencies, even in HTML 4 when using a
<table>.

Here's another example of a CSS hack:

div id="navigation"
...
/div
div id="related"
...
/div
div id="content"
...
/div

#navigation { float:left; width:20% }
#related { float:right; width:20% }
#content { width:50% }

This is a hack because it introduces dependencies between declarations
(see above) and even stronger dependencies between the HTML code and the
stylesheet (possible ways of ordering the columns depend on the order of
the elements in the markup), and because it abuses the "float" property.

You do say that the above code *abuses* the float property... It's
quite a stretch

Look what the specification says on "float" [1]. The property is clearly
designed to be used for giving designers a way to flow text around some
block, not to create multi-column layouts.

Float is not restricted to inline elements in the spec.


Look at position: fixed. It is designed/intended to be used for
creating fixed elements in page layouts. "Authors may use fixed
positioning to create frame-like presentations." And it's not
supported by MSIE 6.
And the example provided by CSS 2.x at section 9.6.1
http://www.w3.org/TR/CSS21/visuren.h...ed-positioning
is certainly looking like a CSS columnar layout to me. Now, are you
saying that such example abuses position: fixed?



Examine this example
http://www.w3.org/2002/03/csslayout-howto
and then explain to me how or where it's not correct.

I stand by my opinion that it's impossible to write semantically correct
CSS 2.1 code for creating multi-column layouts. It *will* be possible in
CSS3's Advanced Layout module [2], provided it will ever be finished.
With the properties explained in that draft, it will be possible to
write a stylesheet that actually says "I want a three-column layout with
A on the left, B in the middle, C on the right, and D at the bottom"
without any indirections, clever tricks, or dependencies.

Without dependencies as you explained them is impossible, unrealistic.
Indirections: I don't know what you're talking about.
Clever tricks: I don't know what you're talking about.

CSS column layout without CSS hacks: yes.
I'm against CSS hacks targeting bugs in the CSS parsers of browsers.

Gérard

On 2008-01-14, Christian Hackl <hacki (AT) sbox (DOT) tugraz.at> wrote:

GTalbot wrote:

So if a main browser manufacturer with all its huge financial, huge
technical resources still can not provide a browser version that can
support a 10 years old CSS specification,

To my knowledge, there is no web browser that supports the entire CSS2
specification. Obviously, CSS2 support is much better in Firefox/Opera,
but I'm sure if it was so easy to upgrade CSS support in IE, Microsoft
would have done so already. Don't forget that such descisions are not
ruled by technical considerations alone. Backward compatibility is a
huge issue.

Backwards compatibility is a technical consideration.

Microsoft easily has the resources to have by now provided something
that has a completely backwards-compatible "quirks mode" and a
completely standards-compliant "standards mode".

So why don't they? Who knows? It could be for cynical business reasons
or it could equally just be bad programmers and bad management. You can
have practically infinite resources and still suck.

[...]

Look what the specification says on "float" [1]. The property is clearly
designed to be used for giving designers a way to flow text around some
block, not to create multi-column layouts.

I do see your point here. CSS 2.1 often doesn't give the impression of
providing the things people actually want very directly.

Don't forget though that part of this is because CSS 2.1 is not
implemented completely in the main browsers. In particular inline-block
would be a more natural choice for a lot of the things people have to
use floats for.

With inline-block and display: table (-cell, -row, etc.) I reckon you
can do most things fairly easily.

Another point is that fashions in web design come and go. They probably
didn't know when they designed CSS that everyone would want to do
these column-style layouts.

I stand by my opinion that it's impossible to write semantically correct
CSS 2.1 code for creating multi-column layouts.

This business of "semantically correct" isn't a requirement of CSS
selectors. The HTML is supposed to be semantic, the CSS is just supposed
to work. You want it clear and readable, but no-one's bothered if you
use (for example) display: table on something that isn't tabular data,
or float for columns. They're just instructions about how to layout the
page.

It *will* be possible in
CSS3's Advanced Layout module [2], provided it will ever be finished.
With the properties explained in that draft, it will be possible to
write a stylesheet that actually says "I want a three-column layout with
A on the left, B in the middle, C on the right, and D at the bottom"
without any indirections, clever tricks, or dependencies.

I presume the code would look like this:

body { display: "abc"
".d." }
#navigation { position:a }
#content { position:b }
#related { position:c }
#footer { position:d }

(Something may be wrong with this, I am not really that familiar with
the current draft!)

Well it sounds like they are listening to what people want anyway.

I trust that you handle CSS pretty well and know how to use it as
efficiently as possible. I'm just arguing that complex CSS layouts are
bound to remain hacks simply because they *cannot* be done otherwise.

Still better than tables for most things. Never mind the semantic
worries, don't forget how unspecificied and quirky a lot of the details
of table layout are.

Ben C wrote:

On 2008-01-14, Christian Hackl <hacki (AT) sbox (DOT) tugraz.at> wrote:
GTalbot wrote:

So if a main browser manufacturer with all its huge financial, huge
technical resources still can not provide a browser version that can
support a 10 years old CSS specification,
To my knowledge, there is no web browser that supports the entire CSS2
specification. Obviously, CSS2 support is much better in Firefox/Opera,
but I'm sure if it was so easy to upgrade CSS support in IE, Microsoft
would have done so already. Don't forget that such descisions are not
ruled by technical considerations alone. Backward compatibility is a
huge issue.

Backwards compatibility is a technical consideration.

Microsoft easily has the resources to have by now provided something
that has a completely backwards-compatible "quirks mode" and a
completely standards-compliant "standards mode".

The question here is that there are different level of quirks. There's
the true "quirks mode" that dates back to the pre-HTML 4 era. Then
there's the IE 6 "standards mode" that isn't terribly
standards-compliant (left, for example, is broken). Now there's IE 7
which is more standards-compliant, but not as much as, say, FF or
Safari's standards compliance. IE 8 is also going to have a mess.

Now how am I supposed to specify that I want an IE 7-era standards
compliance? Don't say conditional comments, they are the pinnacle of
standards non-compliance.

Read the W3C CSS mailing list archives. You'll find that trying to
micromanage standards has been asked for a few times. A consensus
prevails around the idea that permitting usage implies abuse; support is
tepid for the reason that browsers will be inclined to lie if they are
asked to state what they support. It happened with UA strings, it'll
happen again with the some of the proposals.

Look what the specification says on "float" [1]. The property is clearly
designed to be used for giving designers a way to flow text around some
block, not to create multi-column layouts.

I do see your point here. CSS 2.1 often doesn't give the impression of
providing the things people actually want very directly.

The main goal of CSS these days tend to imply a typographic sense.
Ultimately, pixel-perfect designs are doomed to failure since there is
too wide a range of browser sizes to support, and the early drafts, to
me at least, tend to take the freer vein of thinking.

It *will* be possible in
CSS3's Advanced Layout module [2], provided it will ever be finished.
With the properties explained in that draft, it will be possible to
write a stylesheet that actually says "I want a three-column layout with
A on the left, B in the middle, C on the right, and D at the bottom"
without any indirections, clever tricks, or dependencies.

What about CSS 3 Multicolumns, likely to be supported well before
Advanced Layout? Mozilla browsers already experimentally support parts
of this spec.


--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Christian Hackl wrote:

#content { margin-left:20em; margin-right:20em }
#navigation {position:absolute; left:0; top:0; width:20em }
#related {position:absolute; right:0; top:0; width:20em }

It's a hack because the stylesheet abuses the "position" and "margin"
properties for something they have not been intended for.

So what was "position" intended for, if not to position elements some
place other than their static position? I don't see a hack here.

By your reasoning, it sounds like using display:table instead would be a
hack as well. So what would be acceptable in your eyes?

Just take a
look and examine the semantics more closely:

There aren't any semantics in this case. "margin" is strictly a
stylistic property and has nothing to do with semantics. div is
intentionally non-semantic.

Maybe there's a language barrier here and you really mean a word other
than "semantics", but I'm not sure what that would be.

Stating that you want a margin when you actually
want something else is not that much different from stating that
something is tabular data when it really is not.

That's a stretch, I think.

--
Berg

On 2008-01-14, Joshua Cranmer <Pidgeot18 (AT) verizon (DOT) invalid> wrote:

Ben C wrote:
[...]
Microsoft easily has the resources to have by now provided something
that has a completely backwards-compatible "quirks mode" and a
completely standards-compliant "standards mode".

The question here is that there are different level of quirks. There's
the true "quirks mode" that dates back to the pre-HTML 4 era. Then
there's the IE 6 "standards mode" that isn't terribly
standards-compliant (left, for example, is broken). Now there's IE 7
which is more standards-compliant, but not as much as, say, FF or
Safari's standards compliance. IE 8 is also going to have a mess.

Now how am I supposed to specify that I want an IE 7-era standards
compliance? Don't say conditional comments, they are the pinnacle of
standards non-compliance.

Read the W3C CSS mailing list archives. You'll find that trying to
micromanage standards has been asked for a few times. A consensus
prevails around the idea that permitting usage implies abuse; support is
tepid for the reason that browsers will be inclined to lie if they are
asked to state what they support. It happened with UA strings, it'll
happen again with the some of the proposals.

I agree. Besides it's stretching the idea of "backwards compatibility"
to use it an excuse for not fixing bugs. Compatibility with a previous
documented standard is one thing, just not working properly is another.

Jonathan N. Little wrote:

Christian Hackl wrote:

In fact, I've personally been studying and teaching how to use semantic
markup and tableless layouts for about 6 years, and yet I don't see any
progress at all. No professional website used by myself on a daily basis
has even remotely clean HTML code. It seems that if you want to play
safe, you just take a <table> and forget about semantic markup. It's
disappointing, but it's reality, and it frustrates me to a point where I
almost stop caring.

Don't mean you have to create *your* sites that way, who is pointing the
gun to your head?

It's not about me. *I* would like the entire web to adopt better
technologies (such as CSS3 and browsers that actually implement it) and
to use cleaner code, but I don't see it happening at all, hence my
frustration.

Just take a
look and examine the semantics more closely: #content should have a left
margin of 20em, yet when you look at the page there will be no visible
left margin at all. Stating that you want a margin when you actually
want something else is not that much different from stating that
something is tabular data when it really is not.

The margin it to clear the "position:absolute" block that is not in the
page flow! This is correct behavior and proper method.

It is correct behaviour, of course, but still semantically incorrect.
Browsers also "behave correctly" when they render tables used just for
layout purposes. The semantics are the problem, and this effectively
causes all the other, more concrete problems.

Taking one element out of the page flow, giving it a certain width, then
giving another element a margin that's about as big the previous
element... that's a hack, or a "workaround" if you think hack is too
harsh a description.

Using such a technique, you say: "I want this element to be able to
overlap with other elements, but I don't want it to overlap with other
elements." It's illogical. You use position:absolute for something else
and are then required to somehow undo or rather hide the effects of its
real purpose (taking an element of the page flow).

In other words: you do not tell the browser what you want, you tell it
what to do.

Naturally, the browser's rendering engine cannot be aware of your true
intention of creating a multi-column layout and thus won't help you in
the least. For example, it will not automatically make the central
column's left margin larger if the left column grows. How could it? Your
stylesheet does not say anything about columns. It says something about
overlapping elements and margins to the border of the body element. As
far as the semantics of your CSS are concernced, overlapping elements
are what you *want*.

This is a hack because it introduces dependencies between declarations
(see above) and even stronger dependencies between the HTML code and the
stylesheet (possible ways of ordering the columns depend on the order of
the elements in the markup), and because it abuses the "float" property.

Where does it say one rule is not supposed to rely or depend on another?

It's possible, but it's not very desirable. You don't want one thing in
the code to depend on some other, unrelated thing.

<h1>Heading<h1>
<p>Paragraph</p>

h1 { padding:0.5em }

You don't need to change anything about the "p" style just because you
give the upper element some padding. Even though the visible margin
between the elements (i.e. that seen on the screen by the user) is
determined by styles for both elements, you can safely change borders,
margins, and paddings for either without breaking the other. The
dependence is *internal*, not in your code. That's not the kind of
dependence I am criticising, see below.

What about cascade?

Cascading is a different story altogether. But I think in this case it
supports my point. Let's say the main stylesheet says:

#navigation
{
position:absolute;
left:0;
top:0;
width:20em
}
#content
{
margin-left:20em
}

And on some other page, an additionally included special stylesheet
specifies a thick border for the navigation element:

#navigation
{
border:20px solid green;
}

This border will now cause #navigation to overlap with #content, because
the browser cannot adapt the layout dynamically -- as it could do if it
knew it was supposed to render a two-column layout (for example by
implementing CSS3 and interpreting a stylesheet written as explained in
the current Complex Layout draft). As a consequence, you have to edit
the central column's style. Note how this kind of dependency differs
from the one in the h1/p example above.


--
Christian Hackl

In article <fmj6sa$chf$1 (AT) aioe (DOT) org>,
Christian Hackl <hacki (AT) sbox (DOT) tugraz.at> wrote:

Jonathan N. Little wrote:

Christian Hackl wrote:


look and examine the semantics more closely: #content should have a left
margin of 20em, yet when you look at the page there will be no visible
left margin at all.

You are not looking or examining semantics, you are looking at
something else. You are not necessarily making a semantic error
when you specify a background colour for an element which does
not show up (because of any number of reasons). CSS is about
styling. The webpage user does not see the style instructions.
There is no known reason for the effects of a style instruction
to be as literally obvious as you demand even to the expert
colleagues of a web author.

--
dorayme