From: Christian Hackl on
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
From: Jonathan N. Little on
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
From: dorayme on
In article <fmgdc7$cqp$1(a)aioe.org>,
Christian Hackl <hacki(a)sbox.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
From: GTalbot on
On 14 jan, 14:32, Christian Hackl <ha...(a)sbox.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/Internet_Explorer_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.html#fixed-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
From: Ben C on
On 2008-01-14, Christian Hackl <hacki(a)sbox.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.