Constructing the layout for web-based applications

[Michael Schuerig]

In my experience most available books and web publication on CSS are
related to web page/site design. Little attention is payed to the
design and construction of web-based application for data management.
Yes, of course, every book on CSS and web design has a chapter on forms
and possibly lists, the same goes for sites such as A List Apart. But,
in general, coverage is disappointing -- if you're looking for help,
that is. Regarding design aspects, GUI design guidelines by Apple et
al. can be helpful.

However, there's little help when it comes to constructing the target
design out of HTML markup and CSS. My best attempt at it, as part of a
framework on top of Ruby on Rails, can be seen here

http://www.schuerig.de/michael/boilerplate/

I'm mostly pleased with the layout as it is presented by
standards-compliant browsers. Unfortunately, they are only a minority,
especially when it comes to corporate desktop computers. Thus, as it
is, the usefulness of my stuff is regrettably restricted. Of course, I
want to make it work on Internet Explorer, too, but I'm having a hard
time finding information or sample code (HTML/CSS) that helps me with
this task.

Michael

--
Michael Schuerig There is no matrix,
mailto:mi*****@schuerig.de only reality.
http://www.schuerig.de/michael/ --Lawrence Fishburn

[Jim Moe]

Michael Schuerig wrote:

http://www.schuerig.de/michael/boilerplate/

I'm mostly pleased with the layout as it is presented by
standards-compliant browsers. Unfortunately, they are only a minority,
especially when it comes to corporate desktop computers. [...]

Perhaps you could enlighten us what the differences in page rendering
are between IE and everyone else. I see no discernalbe difference.
If cross-browser compatibility is a concern, I suggest using HTML 4.01
Strict rather than XHTML loose. Presentation is the most consistent for
4.01 Strict.
If you insist on XHTML, delete the "<?xml ...>" line (it confuses IE),
and serve the page as "Content-type: application/xhtml+xml". There are
other issues as well and they are covered in Appendix C of the XHTML spec
<http://www.w3.org/TR/xhtml1/#guidelines>.

--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Michael Schuerig]

Jim Moe wrote:

Michael Schuerig wrote:

http://www.schuerig.de/michael/boilerplate/

I'm mostly pleased with the layout as it is presented by
standards-compliant browsers. Unfortunately, they are only a
minority, especially when it comes to corporate desktop computers.
[...]
Perhaps you could enlighten us what the differences in page
rendering
are between IE and everyone else. I see no discernalbe difference.

I take it you've only looked at the description page. Have a look at the
(almost) live demo pages.

http://www.schuerig.de/michael/boile...ist_tasks.html
http://www.schuerig.de/michael/boile...form_task.html
http://www.schuerig.de/michael/boile...employees.html
http://www.schuerig.de/michael/boile..._employee.html

If they render correctly -- i.e. roughly the same as the screenshots --
on your version of IE, I'm on cloud nine. Unfortunately, chances are
very slim.
If cross-browser compatibility is a concern, I suggest using HTML
4.01
Strict rather than XHTML loose. Presentation is the most consistent
for 4.01 Strict.

I haven't yet decided on the trade-offs. As XHTML 1.1 Strict my pages
pass the W3C validator (generated, not necessarily the demos). As HTML
4.01 Strict I get erros related to improper nesting.

Michael

--
Michael Schuerig The more it stays the same,
mailto:mi*****@schuerig.de The less it changes!
http://www.schuerig.de/michael/ --Spinal Tap, The Majesty of Rock

[Spartanicus]

Jim Moe <jm***************@sohnen-moe.com> wrote:

If you insist on XHTML, delete the "<?xml ...>" line (it confuses IE),
and serve the page as "Content-type: application/xhtml+xml".

The latter does a bit more than confuse IE.

--
Spartanicus

[Spartanicus]

Michael Schuerig <mi*****@schuerig.de> wrote:

As XHTML 1.1 Strict my pages
pass the W3C validator (generated, not necessarily the demos).
Serving XHTML 1.1 as text/html violates w3c guidelines.
As HTML 4.01 Strict I get erros related to improper nesting.

Then fix that.

--
Spartanicus

[Jim Moe]

Michael Schuerig wrote:

I take it you've only looked at the description page. Have a look at the
(almost) live demo pages.
http://www.schuerig.de/michael/boile...ist_tasks.html

You have a number of errors in boilerplate.css.
When boilerplate.css is prevented from loading, the page looks the same
in IE and Mozilla. So it is your CSS that is breaking IE.
You are using a number of elements of CSS that IE does not comprehend.
IE is mostly CSS1 compliant, and sprinkles in a few CSS2 elements it deems
worthy. Things like "#menu > ul" are a mystery to IE. Use no non-alpha
characters besides "." and "#".
There are a large number of Javascript warnings from the main page.

"scriptaculous"?

--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Michael Schuerig]

Jim Moe wrote:

Michael Schuerig wrote:

I take it you've only looked at the description page. Have a look at
the (almost) live demo pages.
http://www.schuerig.de/michael/boile...ist_tasks.html
You have a number of errors in boilerplate.css.
When boilerplate.css is prevented from loading, the page looks the
same
in IE and Mozilla. So it is your CSS that is breaking IE.
You are using a number of elements of CSS that IE does not
comprehend.
IE is mostly CSS1 compliant, and sprinkles in a few CSS2 elements it
deems worthy. Things like "#menu > ul" are a mystery to IE. Use no
non-alpha characters besides "." and "#".

Yes, there are errors. display:inline-block is not yet in any finalized
CSS recommendation. It is in the CSS2.1 working draft. I don't see how
to do without inline-block (or its Gecko-equivalent
display:-moz-inline-box).

Yes, I know that IE is mostly CSS1 compliant.

Knowing these things is part of the problem statement. It helps, of
course, to clearly articulate what the problem is. Currently, I'm
looking for solutions to get what I already have to work with IE.
There are a large number of Javascript warnings from the main page.
There is no JavaScript on the main page at all. The demo pages use
JavaScript copiously.
"scriptaculous"?

Excuse me? I'm not sure what you are trying to say. In order to achieve
successful communication you would have to be a little more explicit.

Scriptaculous is a set of JavaScripts: <http://script.aculo.us/>
Michael

--
Michael Schuerig Most people would rather die than think.
mailto:mi*****@schuerig.de In fact, they do.
http://www.schuerig.de/michael/ --Bertrand Russell

[Jim Moe]

Michael Schuerig wrote:

You have a number of errors in boilerplate.css.
Yes, there are errors. display:inline-block is not yet in any finalized
CSS recommendation. It is in the CSS2.1 working draft. I don't see how
to do without inline-block (or its Gecko-equivalent
display:-moz-inline-box).

You cannot have IE compatibility and use non-IE features. You must dumb
down your CSS to match IE.

There are a large number of Javascript warnings from the main page.

Oops. It is the list_tasks.html page.
--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Alan J. Flavell]

On Fri, 26 Aug 2005, Jim Moe wrote:

You cannot have IE compatibility and use non-IE features.
That depends on what you understand by "compatibility". If you design
for graceful fallback on lesser browsers, IE will happily reveal
itself as a lesser browser. Users aren't in the habit of viewing your
pages on several browsers and awarding marks for identity of
rendering: what they want is convenient access to your /content/
(although it has to be admitted that all too many pages are designed
solely on considerations set out by the sponsor and the designer, with
precious little thought for the end user. Quite what use that is,
is left as an exercise for the student...).
You must dumb down your CSS to match IE.

I can't agree. If you design for graceful fallback, you can get even
better results on WWW-conforming browsers, while still getting more
than adequate results on that lesser browser, as well as on a wide
range of other browsing situations.

Whereas those who design only for the lesser browser get - at best -
poor results on www-compatible browsers - all too often, web pages
that simply don't work at all on them. So unless you're being bribed
to reject anyone who cares about the browser that they use, I'd
recommend graceful fallback.

[Spartanicus]

Jim Moe <jm***************@sohnen-moe.com> wrote:

Yes, there are errors. display:inline-block is not yet in any finalized
CSS recommendation. It is in the CSS2.1 working draft. I don't see how
to do without inline-block (or its Gecko-equivalent
display:-moz-inline-box).

You cannot have IE compatibility and use non-IE features. You must dumb
down your CSS to match IE.

display:inline-block is supported by IE.

--
Spartanicus

[Christoph Päper]

Spartanicus:

display:inline-block is supported by IE.

Half-heartedly, though.

[Jim Moe]

Alan J. Flavell wrote:

You must dumb down your CSS to match IE.

I can't agree. If you design for graceful fallback, you can get even
better results on WWW-conforming browsers, while still getting more
than adequate results on that lesser browser, as well as on a wide
range of other browsing situations.

Okay, my own limitations are showing then.
Nevertheless, the OP's CSS is so over IE's head that IE does not even
bother to display some of the content; not a graceful fallback. The OP
will have to start stripping out features until he finds which parts IE
stumbles over.

--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Michael Schuerig]

Jim Moe wrote:

Michael Schuerig wrote:

You have a number of errors in boilerplate.css.

Yes, there are errors. display:inline-block is not yet in any
finalized CSS recommendation. It is in the CSS2.1 working draft. I
don't see how to do without inline-block (or its Gecko-equivalent
display:-moz-inline-box).

You cannot have IE compatibility and use non-IE features. You must
dumb down your CSS to match IE.

I know and I knew before, but that's not the interesting part. What I
didn't know, still don't know, and why I asked for advice in the first
place is: how?

Michael

--
Michael Schuerig You can twist perceptions
mailto:mi*****@schuerig.de Reality won't budge
http://www.schuerig.de/michael/ --Rush, Show Don't Tell

[Leonard Blaisdell]

In article <de**********@newsreader3.netcologne.de>,
Michael Schuerig <mi*****@schuerig.de> wrote:

I know and I knew before, but that's not the interesting part. What I
didn't know, still don't know, and why I asked for advice in the first
place is: how?

Search for "CSS IE Bugs" in google. Eric Meyer used to maintain a CSS
compatibility chart, but I can't find a recent version. It probably got
too unwieldy to maintain. The search may not answer your question, but
it'll give you an idea of your problem.

leo

--
<http://web0.greatbasin.net/~leo/

[Jim Moe]

Michael Schuerig wrote:

You cannot have IE compatibility and use non-IE features. You must
dumb down your CSS to match IE.

I know and I knew before, but that's not the interesting part. What I
didn't know, still don't know, and why I asked for advice in the first
place is: how?

I've mentioned at least 4 different areas for you to explore. Which of
these (IE bugs, Javascript errors/warnings, CSS validation errors, CSS
features IE does not support, use of non-standard features) is difficult
to understand?

--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Spartanicus]

Christoph Päper <ch**************@nurfuerspam.de> wrote:

display:inline-block is supported by IE.

Half-heartedly, though.

Meaning?

IE has a bug in applying it to elements that default to block, but
there's a hack to get around that:
http://homepage.ntlworld.com/spartan...block_hack.htm

--
Spartanicus

[Michael Schuerig]

Leonard Blaisdell wrote:

In article <de**********@newsreader3.netcologne.de>,
Michael Schuerig <mi*****@schuerig.de> wrote:

I know and I knew before, but that's not the interesting part. What I
didn't know, still don't know, and why I asked for advice in the
first place is: how?

Search for "CSS IE Bugs" in google. Eric Meyer used to maintain a CSS
compatibility chart, but I can't find a recent version. It probably
got too unwieldy to maintain. The search may not answer your question,
but it'll give you an idea of your problem.

Thanks, I'll have a look. So far, I've often been referring to
Peter-Paul Koch's helpful site

http://www.quirksmode.org/

Michael

--
Michael Schuerig I am the sum total of the parts
mailto:mi*****@schuerig.de I control directly.
http://www.schuerig.de/michael/ --Daniel C. Dennett, Elbow Room

[Alan J. Flavell]

On Fri, 26 Aug 2005, Jim Moe wrote:

Alan J. Flavell wrote:

You must dumb down your CSS to match IE.
I can't agree. If you design for graceful fallback, you can get
even better results on WWW-conforming browsers, while still
getting more than adequate results on that lesser browser, as well
as on a wide range of other browsing situations.

Okay, my own limitations are showing then.

I don't see any reason for you to be so modest! I reckon I have
learned from things that you have posted.

MSIE has the facility, unique AFAIK amongst browsers, of implementing
a switch that is harmless to web-compatible browsers: the so-called
"conditional comment" in the HTML. So, *theoretically and in the
final analysis*, if someone wants to fully exploit CSS in
web-compatible browsers, while nevertheless getting the best out of
MSIE, they could use these conditional comments to present quite
different CSS to the two classes of browser - by separating the CSS
into individual stylesheets and using these "conditional comments" in
the HTML to switch.

In practice, I'd say, it's hardly ever necessary to really go *that*
far. I'm using the theoretically extreme case purely as a
"gedankenexperiment" to demonstrate that the earlier claims "You
cannot have IE compatibility and use non-IE features" and "You must
dumb down your CSS to match IE" are over-stating the case.
*Usually*, IE will ignore CSS things that it doesn't understand. But
if necessary there are techniques (particularly, this MSIE conditional
comment) to modify what IE gets to see, relative to other browsers.
Nevertheless, the OP's CSS is so over IE's head that IE does not
even bother to display some of the content;
I fully agree with you that such a consequence is serious!
not a graceful fallback. The OP will have to start stripping out
features until he finds which parts IE stumbles over.

My comments to which you were following-up were meant to be comments
on matters of principle, rather than anything directly addressed to
the original web page which started this thread. If that hadn't been
clear from the way I posted them, then please accept my apology.
At this point in time, when I visit the original poster's cited URL, I
find an XHTML/1.0 document which fails XHTML validation, and the CSS
checker refuses to look at it for the same cause: so I'm not motivated
to look much further. I'm a firm believer that it's discourteous to
offer anything for general discussion here before such computer-
reportable errors have been ironed out (unless the poster needs
specific help with the errors reported by the validator or checker).

http://validator.w3.org/check?verbos...l/boilerplate/

http://jigsaw.w3.org/css-validator/v...l/boilerplate/
However, I do notice that the XHTML document begins with

<?xml version="1.0" encoding="iso-8859-1"?>

which, as we know, will throw IE into its "quirks" mode. I wouldn't
want to spend any effort on that mysef: I'd want at least to aim for
standards mode. There's a number of ways of achieving that, starting
from what's there now, but ideally the first option would be best
IMHO:

* find out how to get the server to put the iso-8859-1 on the real
HTTP Content-type header, instead of having to supply it on the <?xml
thingy. Ah! the server is Apache, so that's easy (assuming that the
O.P is enabled for using the .htaccess file).

* recode the page in utf-8, and let XML-based agents default to utf-8:
omit the <?xml thingy; HTML-based agents would be content with the
"meta http-equiv" way of setting charset=utf-8.

* some other fiddly options that I'm too lazy to describe in detail.

I'm not saying that these changes will be, in themseves, an answer to
reported difficulties, but I'd want to make them before starting on
anything more-detailed, since I rate it as wasted effort to mess with
IE in its quirks mode nowadays.

cheers

[Christoph Päper]

Spartanicus:

Christoph Päper <ch**************@nurfuerspam.de> wrote:

display:inline-block is supported by IE.
Half-heartedly, though.

IE has a bug in applying it to elements that default to block,

Exactly.
but there's a hack to get around that:
http://homepage.ntlworld.com/spartan...block_hack.htm

It's so strange and so wrong this works!

[Spartanicus]

Christoph Päper <ch**************@nurfuerspam.de> wrote:

IE has a bug in applying it to elements that default to block,

Exactly.

but there's a hack to get around that:
http://homepage.ntlworld.com/spartan...block_hack.htm

It's so strange and so wrong this works!

IE is known for stupid things like that, foo{display:inline;float:left}
is another hack that shouldn't work. But as hacks go, I'm happy with
these ones since they are harmless to proper browsers.

--
Spartanicus