Hi all!

While building a printable six month calendar I'm trying to solve a
difficult problem, namely printing background CSS colors. Let me first
tell you what I have tried:

Since "every" browser will remove background color, the route to
success will lie in something else that does get printed. Well, the
only thing I know for sure browsers will print, is images. Not the
ones you put in CSS but the real img tag. Ok, the images would have to
sit underneath some text, in this case the day of the month and if
applicable, the event that goes in the calendar. I tried with gifs,
that I put in the same div (did I say the calendar is table less?) as
the day. When I put them, there are off a bit but the text is still
visible. But when I reposition them to be directly above the text, the
text disappear - hidden by the gif. So I tried with transparent pngs
instead (I know the IE5.5-6 hack) and everything look nice, until I
hit print. In the print version there is no transparency, which blocks
the text yet again.

Now is there anyone that knows of a method to print transparent pngs,
which keep them transparent!?

My only other option, it would seem, is to use PDF. I have looked into
iText, which is what google calendar use, but I really didn't want to
recode all the logic again to build the PDF. So I looked at HTML to
PDF and found several components (I use ASP.NET 2.0 for back end) and
online services. The only one that passed my test (correctly generate
PDF from CSS and divs) is http://www.pdfonline.com/ . The problem
however with their service is how they implemented it. I'm guessing
here, but I think that they use the IE HTML engine from the server,
request the page and take a snapshot, then they stick it in a PDF file
and viola! You got yourself a PDF, exactly as seen in IE. My calendar
is build from JS and it takes about 1-2 seconds in an average browser
but the snapshot is taking immediately, so my calendar won't be build
yet and the PDF will be empty. I have written them to ask if they
could put parameter to their service where I could set the delay time,
but so far no response.

I really thougth I had it with the transparent pngs but it didn't
work. Any bright suggesting out there?!?

PS. I hope someone smarter than me reads this.... :-)
A link to the calendar: http://bookevent.dk/JSCalendar/calendar.htm
EXT in effect: http://bookevent.dk/JSCalendar/GenCalendar.htm

Jon wrote:
>
> While building a printable six month calendar I'm trying to solve a
> difficult problem, namely printing background CSS colors. Let me first
> tell you what I have tried:

[non-semantic markup hacks snipped]

>
> PS. I hope someone smarter than me reads this.... :-)
> A link to the calendar: http://bookevent.dk/JSCalendar/calendar.htm
> EXT in effect: http://bookevent.dk/JSCalendar/GenCalendar.htm

Your post begs the question: What is there about this calendar that
makes it useful for me to use up the ink in my printer's color cartridge?

The months have only 24 days, which is weird. There's no scroll bar, so
it can't be that I've just got my viewport smaller than you foresaw, right?

Without JS, there's only an empty page. If you want to require JS for
this, okay, but wouldn't you like to at least tell the non-JS-visitor
that JS is required to see/use the whatever-it-is?

Your texts are flexibly sized, or at least, I can resize them in FF. But
the grid lines remain fixed, so they conflict with the texts.
Actually, there seems to be a slight mismatch by default.

I don't know what you mean by EXT but that page merely provides a an
extra, empty column containing nothing more than the ability to get rid
of the column. Reminds me of the machine which, when you flick the
switch to turn it on, extends a mechanical arm to flick the switch back
and turn itself off. That's all it does. :-)

Is a string like 30-06-2007 really the date format used in Denmark? With
dashes, I would have expected the year first, as in 2007-06-30.

Regarding PDFs: I hate 'em (or maybe I just hate Adobe Reader...). I'd
have to be convinced of the usefulness of your bg coloring before I'd
support the PDF way.

--
John
Pondering the value of the UIP: http://improve-usenet.org/

On 9 Sep., 04:26, John Hosking <J...@DELETE.Hosking.name.INVALID>
wrote:
> Jon wrote:
>
> > While building a printable six month calendar I'm trying to solve a
> > difficult problem, namely printing background CSS colors. Let me first
> > tell you what I have tried:
>
> [non-semantic markup hacks snipped]
>
>
>
> > PS. I hope someone smarter than me reads this.... :-)
> > A link to the calendar:http://bookevent.dk/JSCalendar/calendar.htm
> > EXT in effect:http://bookevent.dk/JSCalendar/GenCalendar.htm
>
> Your post begs the question: What is there about this calendar that
> makes it useful for me to use up the ink in my printer's color cartridge?
>
> The months have only 24 days, which is weird. There's no scroll bar, so
> it can't be that I've just got my viewport smaller than you foresaw, right?
>
> Without JS, there's only an empty page. If you want to require JS for
> this, okay, but wouldn't you like to at least tell the non-JS-visitor
> that JS is required to see/use the whatever-it-is?
>
> Your texts are flexibly sized, or at least, I can resize them in FF. But
> the grid lines remain fixed, so they conflict with the texts.
> Actually, there seems to be a slight mismatch by default.
>
> I don't know what you mean by EXT but that page merely provides a an
> extra, empty column containing nothing more than the ability to get rid
> of the column. Reminds me of the machine which, when you flick the
> switch to turn it on, extends a mechanical arm to flick the switch back
> and turn itself off. That's all it does. :-)
>
> Is a string like 30-06-2007 really the date format used in Denmark? With
> dashes, I would have expected the year first, as in 2007-06-30.
>
> Regarding PDFs: I hate 'em (or maybe I just hate Adobe Reader...). I'd
> have to be convinced of the usefulness of your bg coloring before I'd
> support the PDF way.
>
> --
> John
> Pondering the value of the UIP:http://improve-usenet.org/

John, thanks for taking the time to comment everything and not
consider what could be an answer to my question (u gotta love usenet
forums lol). No, seriously. You make some very valid points so I will
answer them.
> Your post begs the question: What is there about this calendar that
> makes it useful for me to use up the ink in my printer's color cartridge?
The reason why I want printable background images is because my client
told me she want it! She already got a pc based application that gives
her the calendar as a PDF but she's getting tired of mailing (snail
mail) it to her customers. So now she wants a web based calendar where
her customers can print their specific calendar.

On a side note - I find it really annoying/stupid that browser
manufactures think they have to take those decisions. It's NOT up to
them but to the developers. We are the ones who knows when it's
important and when it's not. Please give me some power, so I don't
have to spend days for filling my clients visions. Like which way to
print a document, landscape or not! C'mon! Don't they thing I as a
application developer knows when it makes sense!? puh.. enough
ranting..

> The months have only 24 days, which is weird. There's no scroll bar, so
> it can't be that I've just got my viewport smaller than you foresaw, right?
Yes your are completely right. If I put overflow:auto I have
scrollbars all the time so obviously I have a box width/height issue
which I will work out (I think I wrote it was a work in progress?).
Anyway, if you know where my CSS error is please, tell me.

> Without JS, there's only an empty page. If you want to require JS for
> this, okay, but wouldn't you like to at least tell the non-JS-visitor
> that JS is required to see/use the whatever-it-is?
The users is my clients clients and they will have to login. On the
login page I have a noscript section. I don't make rich client
applications that can run without JS.

> Your texts are flexibly sized, or at least, I can resize them in FF. But
> the grid lines remain fixed, so they conflict with the texts.
> Actually, there seems to be a slight mismatch by default.
Good point.. I will try to see if I can figure out a cross browser
resize algorithms or else I'll remove the feature.

EXT is a set of client-side cross browser controls: extjs.com
The second link has a buggy resize algorithm that doesn't work on
widescreen resolutions (maybe I'll remove it).
John, what you have seen is a big part of my application but it's
nowhere near the hole part. I will keep that to myself and my clients
for now. What I have posted what an example to make it easier for you
to me. If you think you can me in any way, please write
again! Thanks!

Jon wrote:

> My only other option, it would seem, is to use PDF.

Since it appears that you are more interested in how the page prints
then how it looks on screen, this may be your best option. Is there
money in the budget to hire someone who knows how to do that? (hint, hint)

I have not done generated PDFs in color, so your blue banners would wind
up gray, which may not matter if the calendars are going to be printed
on a grayscale laser printer.

If your server supports Perl, and you have a budget to work with, we can
talk.

Jon wrote:
> On 9 Sep., 04:26, John Hosking <J...@DELETE.Hosking.name.INVALID>
> wrote:
>> Jon wrote:
>>
>>> While building a printable six month calendar I'm trying to solve a
>>> difficult problem, namely printing background CSS colors. Let me first
>>> tell you what I have tried:
>> [non-semantic markup hacks snipped]
>>
>>
>>
>>> PS. I hope someone smarter than me reads this.... :-)
>>> A link to the calendar:http://bookevent.dk/JSCalendar/calendar.htm
>>> EXT in effect:http://bookevent.dk/JSCalendar/GenCalendar.htm
>> Your post begs the question: What is there about this calendar that
>> makes it useful for me to use up the ink in my printer's color cartridge?
>>
>> The months have only 24 days, which is weird. There's no scroll bar, so
>> it can't be that I've just got my viewport smaller than you foresaw, right?
>>
>> Without JS, there's only an empty page. If you want to require JS for
>> this, okay, but wouldn't you like to at least tell the non-JS-visitor
>> that JS is required to see/use the whatever-it-is?
>>
>> Your texts are flexibly sized, or at least, I can resize them in FF. But
>> the grid lines remain fixed, so they conflict with the texts.
>> Actually, there seems to be a slight mismatch by default.
>>
>> I don't know what you mean by EXT but that page merely provides a an
>> extra, empty column containing nothing more than the ability to get rid
>> of the column. Reminds me of the machine which, when you flick the
>> switch to turn it on, extends a mechanical arm to flick the switch back
>> and turn itself off. That's all it does. :-)
>>
>> Is a string like 30-06-2007 really the date format used in Denmark? With
>> dashes, I would have expected the year first, as in 2007-06-30.
>>
>> Regarding PDFs: I hate 'em (or maybe I just hate Adobe Reader...). I'd
>> have to be convinced of the usefulness of your bg coloring before I'd
>> support the PDF way.
>>
>> --
>> John
>> Pondering the value of the UIP:http://improve-usenet.org/
>
> John, thanks for taking the time to comment everything and not
> consider what could be an answer to my question (u gotta love usenet
> forums lol). No, seriously. You make some very valid points so I will
> answer them.
>> Your post begs the question: What is there about this calendar that
>> makes it useful for me to use up the ink in my printer's color cartridge?
> The reason why I want printable background images is because my client
> told me she want it! She already got a pc based application that gives
> her the calendar as a PDF but she's getting tired of mailing (snail
> mail) it to her customers. So now she wants a web based calendar where
> her customers can print their specific calendar.
>

OK, a web-based calendar is fine. But DON'T WASTE MY EXPENSIVE INK
CARTRIDGES ON IRRELEVANT BACKGROUND COLORS!

> On a side note - I find it really annoying/stupid that browser
> manufactures think they have to take those decisions. It's NOT up to
> them but to the developers. We are the ones who knows when it's
> important and when it's not. Please give me some power, so I don't
> have to spend days for filling my clients visions. Like which way to
> print a document, landscape or not! C'mon! Don't they thing I as a
> application developer knows when it makes sense!? puh.. enough
> ranting..
>

I'm glad they did. They save my ink. I really don't need to use $10
worth of ink on irrelevant background colors!

If I want a different colored background, I'll put in different colored
paper.

>> The months have only 24 days, which is weird. There's no scroll bar, so
>> it can't be that I've just got my viewport smaller than you foresaw, right?
> Yes your are completely right. If I put overflow:auto I have
> scrollbars all the time so obviously I have a box width/height issue
> which I will work out (I think I wrote it was a work in progress?).
> Anyway, if you know where my CSS error is please, tell me.
>
>> Without JS, there's only an empty page. If you want to require JS for
>> this, okay, but wouldn't you like to at least tell the non-JS-visitor
>> that JS is required to see/use the whatever-it-is?
> The users is my clients clients and they will have to login. On the
> login page I have a noscript section. I don't make rich client
> applications that can run without JS.
>

Then you lose about 10% of your prospective clients. Javascript should
be used to enhance the experience - and not be required to have the
experience.

>> Your texts are flexibly sized, or at least, I can resize them in FF. But
>> the grid lines remain fixed, so they conflict with the texts.
>> Actually, there seems to be a slight mismatch by default.
> Good point.. I will try to see if I can figure out a cross browser
> resize algorithms or else I'll remove the feature.
>
> EXT is a set of client-side cross browser controls: extjs.com
> The second link has a buggy resize algorithm that doesn't work on
> widescreen resolutions (maybe I'll remove it).
> John, what you have seen is a big part of my application but it's
> nowhere near the hole part. I will keep that to myself and my clients
> for now. What I have posted what an example to make it easier for you
> to me. If you think you can me in any way, please write
> again! Thanks!
>

Proper CSS and you don't need the resize with js. Make your widths a
percentage of the screen width.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

And lo, Jon didst speak in alt.www.webmaster:

> Hi all!
>
> While building a printable six month calendar I'm trying to solve a
> difficult problem, namely printing background CSS colors. Let me first
> tell you what I have tried:
>
> Since "every" browser will remove background color, the route to
> success will lie in something else that does get printed.

I don't know if this has been mentioned already in this thread, but
"every" graphical browser I have used has had a selectable option to
enable printing of background images and colours. By default, all of them
have this feature disabled to save printer ink.


IE: Tools >> Internet Options >> Advanced >> Printing >> "Print background
colors and images"

Firefox: File >> Page Setup >> Format & Options >> Print Background
(colors & images)

Opera: File >> Print Options >> Print Page Background


Don't bother creating a different version which forces the issue. Just
tell your customers how to enable and disable the printing of background
colours and images in their respective browser, then let them make their
own choice when printing the calendar.

Also remember that you can enforce specific CSS styles for printing with a
print media stylesheet. Combine this with IE conditional comments and you
can make background images appear or disappear, or switch them from 8-bit
(PNG) to 1-bit (GIF) transparency depending on the browser being used to
print.

Grey

--
The technical axiom that nothing is impossible sinisterly implies the
pitfall corollary that nothing is ridiculous.
- http://www.greywyvern.com/orca#search - Orca Search: Full-featured
spider and site-search engine

Jerry Stuckle wrote:

>
> Proper CSS and you don't need the resize with js. Make your widths a
> percentage of the screen width.

And your (OP Jon) grid heights relative to font-size (em or %).


--
John
Pondering the value of the UIP: http://improve-usenet.org/

Jon wrote:

>
> John, thanks for taking the time to comment everything and not
> consider what could be an answer to my question (u gotta love usenet
> forums lol). No, seriously. You make some very valid points so I will
> answer them.

I'm glad you appreciate that I thought about your page. It was in fact
an attempt to address your question. I'm sorry if you think you didn't
get your money's worth. I'll give you double your money back. :-)

BTW, it's usually preferred if you place your responses to my points
(valid or otherwise ;-) ) immediately after my points, rather than
copying and pasting them *again* into your reply. Points you don't want
to reply to should be trimmed out of your reply. And please do feel free
to trim signatures.

> On 9 Sep., 04:26, John Hosking wrote:
>> Jon wrote:
>>
>>> While building a printable six month calendar I'm trying to solve a
>>> difficult problem, namely printing background CSS colors. Let me first
>>> tell you what I have tried:

>>> A link to the calendar:http://bookevent.dk/JSCalendar/calendar.htm
>>> EXT in effect:http://bookevent.dk/JSCalendar/GenCalendar.htm


>> The months have only 24 days, which is weird. There's no scroll bar, so
>> it can't be that I've just got my viewport smaller than you foresaw, right?

> Yes your are completely right. If I put overflow:auto I have
> scrollbars all the time so obviously I have a box width/height issue

So why use overflow:auto instead of overflow:visible? I'd leave the
declaration out completely.

> which I will work out (I think I wrote it was a work in progress?).
> Anyway, if you know where my CSS error is please, tell me.

Well, I have very little interest in checking through the JS that
produces all the resulting markup, but I can see the generated code, and
that lets me generate what will seem like a smart-aleck answer. Ready?

Your CSS error is putting it inline. For every day in the calendar, I
see stuff like style="left: 83.3333%; top: 87.0968%; width: 16.6667%;".
This stems from what I think is a much larger (and more general) error:
coding the page as a huge clump of absolutely positioned divs and spans.
A calendar is a classic example of tabular data. I recommend you use
<table>.

Probably not what you want to hear (and still doesn't provide any
direction about bg colors), but it's how I see it.

--
John
Pondering the value of the UIP: http://improve-usenet.org/

On 10 Sep., 19:30, Scott Bryce <sbr...@scottbryce.com> wrote:
> Jon wrote:
> > My only other option, it would seem, is to use PDF.
>
> Since it appears that you are more interested in how the page prints
> then how it looks on screen, this may be your best option. Is there
> money in the budget to hire someone who knows how to do that? (hint, hint)
Hi Scott.
My colleague made the original windows based program in Delphi which
generates the PDF I HAVE to mimic and we have seriously talk about
migrating it to .NET (I use ASP.NET as backend) but have deemed it to
expansive with the current budget.
But if you see me on usenet another time with a problem you think you
can solve, I'm sure we can figure out a price. :-)

> Proper CSS and you don't need the resize with js. Make your widths a
> percentage of the screen width.
Jerry, all width sizes are a percentage of the screen! Unfortunately
different browsers have different interpretation of 100%. I'm not sure
what's wrong yet.. :-(

Hi Grey.
> Don't bother creating a different version which forces the issue. Just
> tell your customers how to enable and disable theprintingof background
> colours andimagesin their respectivebrowser, then let them make their
> own choice whenprintingthe calendar.
Sorry, not an option.

> Also remember that you can enforce specific CSS styles forprintingwith a
> print media stylesheet. Combine this with IE conditional comments and you
> can make backgroundimagesappear or disappear, or switch them from 8-bit
> (PNG) to 1-bit (GIF) transparency depending on thebrowserbeing used to
> print.
As GIF is 1-bit (as you stated) there are no good. Either the color is
there and blocking the text or it's isn't there and there is no
background color.
I have solved it though with z-index.

On 10 Sep., 21:03, John Hosking <J...@DELETE.Hosking.name.INVALID>
wrote:
> And your (OP Jon) grid heights relative to font-size (em or %)
I have to put the height of the grid or IE6 won't show the grid at
all! I have decided to move away from relative sizing all together.
The height will be 600px (210mm for printing) and if the users screen
is too small a scrollbar will be presented.

Jon wrote:
>> Proper CSS and you don't need the resize with js. Make your widths a
>> percentage of the screen width.
> Jerry, all width sizes are a percentage of the screen! Unfortunately
> different browsers have different interpretation of 100%. I'm not sure
> what's wrong yet.. :-(
>

But since you're writing everything in javascript, it's impossible to tell.

Get it working with a static page (no JS) first. That will .

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

> Well, I have very little interest in checking through the JS that
> produces all the resulting markup, but I can see the generated code, and
> that lets me generate what will seem like a smart-aleck answer. Ready?
That's fine as I have the JS in order :-) My problem is CSS and
browser behavior.

> Your CSS error is putting it inline. For every day in the calendar, I
> see stuff like style="left: 83.3333%; top: 87.0968%; width: 16.6667%;".
> This stems from what I think is a much larger (and more general) error:
> coding the page as a huge clump of absolutely positioned divs and spans.
> A calendar is a classic example of tabular data. I recommend you use
> <table>.
I did make the calendar with tables before but I had all kinds of
problems + I hate tables! I think it will be easier to manipulate (the
DOM) with divs rather than trs and tds. Especially because the divs
are absolute positioned, I can remove a div with out worrying about
the layout. Also my solution (printing images) requires that the
elements are taken out of the page flow, so I can use z-index. As far
as I know that requires absolute positioning.

On 11 Sep., 16:58, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> But since you're writing everything in javascript, it's impossible to tell.
Jerry, you can use firebug and click on the HTML tab. That will show
you the generated HTML. For you sake I will create a page with the
generated HTML. I will post the URI shortly :-)

And lo, Jon didst speak in alt.www.webmaster:

> Hi Grey.
>
>> Don't bother creating a different version which forces the issue. Just
>> tell your customers how to enable and disable the printing of background
>> colours and images in their respective browser, then let them make their
>> own choice when printing the calendar.
>
> Sorry, not an option.

Please explain.

What if I don't *want* to print your calendar backgrounds. Then you
aren't giving me a choice.

Grey

--
The technical axiom that nothing is impossible sinisterly implies the
pitfall corollary that nothing is ridiculous.
- http://www.greywyvern.com/orca#search - Orca Search: Full-featured
spider and site-search engine

On 11 Sep., 17:07, GreyWyvern <s...@greywyvern.com> wrote:
> Please explain.
>
> What if I don't *want* to print your calendar backgrounds. Then you
> aren't giving me a choice.
That's correct! My client already has an application that produces her
calendars as PDF. She usually snail mails them out, after she prints
them. To free up time on her behave I'm creating a web based
application that does just that. The caveat (not sure if that's the
correct term) is that she is afraid that her clients will call her and
ask for the "real" calendar if the web based one doesn't look like the
existing or look worse (less graphic). Thus not achieving anything. To
put it short, the clients will continue to get the calendar as always
but they will have to print it out themselves.
*
The calendar is NOT public and the user WILL have JS turned on and
their browsers WILL support CSS. If the have anything worse than IE6
then it's too bad.
*
If any of your guys are CSS sharks I would very much appreciate your
with the scrollbar issue.
Regards, Jon.

Jon wrote:
> On 11 Sep., 16:58, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> But since you're writing everything in javascript, it's impossible to tell.
> Jerry, you can use firebug and click on the HTML tab. That will show
> you the generated HTML. For you sake I will create a page with the
> generated HTML. I will post the URI shortly :-)
>

Yes, you can, but it's a lot harder to read - and difficult to read and
save.

But I think you missed my point. Get a static page going first, then
get it to work with your JS.

And I agree with John. I think this would be better as a table. It is
a table, after all.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

And lo, Jon didst speak in alt.www.webmaster:

> GreyWyvern wrote:
>
>> Please explain.
>>
>> What if I don't *want* to print your calendar backgrounds. Then you
>> aren't giving me a choice.
>
> That's correct! My client already has an application that produces her
> calendars as PDF. She usually snail mails them out, after she prints
> them.

If she already has an application that produces her calendars as PDF, why
not just email the PDF? What is the benefit of moving away from that
application to reproduce the calendar in HTML?

Grey

--
The technical axiom that nothing is impossible sinisterly implies the
pitfall corollary that nothing is ridiculous.
- http://www.greywyvern.com/orca#search - Orca Search: Full-featured
spider and site-search engine

Jon wrote:

> My client already has an application that produces her
> calendars as PDF. She usually snail mails them out, after she prints
> them. To free up time on her behave I'm creating a web based
> application that does just that.

Except, not in PDF format.


> The caveat (not sure if that's the
> correct term) is that she is afraid that her clients will call her and
> ask for the "real" calendar if the web based one doesn't look like the
> existing

If you create a page intended to be printed in HTML, you are at the
mercy of the browser. Each browser will place the HTML on the printed
page slightly differently. Even the same browser with different settings
will give slightly different results. If everybody's printed copy must
look the same, you pretty much have to go with PDF.

For everyone who doesn't like JS generated pages:
http://www.bookevent.dk/JSCalendar/JustHTML.htm

Hmm.. So far all the time I have used on this topic on usenet has been
about answering questions that had little to do with my question. I'm
sorry but I didn't post a question to answer questions about design
decisions or whatever else people could come up with. My project is
set, I have the design goals, I have a contract with my client that
specifies everything. It's not up to debate and nothing will be
changed. I do think usenet groups can be awarding in that you can get
another pair of eyes on a subject. But this has been a complete waste
of time.. Not only did I come up with a solution to my problem alone,
I also wasted time answering question from people who didn't have an
answer. This is all very sad, because this could really be a great,
professional assistance in those hairy moments where you don't know
what to do. I don't know what to do about it, but it's probably the
last time I will post any questions here.

For all of you who read this, please think again before you reply to a
topic/question. A question about why my client don't use another
application is really really pointless. I wouldn't be creating an
application if there was no need or if my client wasn't paying. The
simple answer to THAT question is that there is more to my application
than just the calendar. Which IS really really beside the point. My
question is about browser behavior and CSS. Nothing more and nothing
else!

Thanks for your time. I hope you will think twice before asking
questions to a question. We are all professionals and we all loose
money on wasting time.
Regards, Jon.

PS. Please don't tell me it's easier to manipulate tables than divs -
I had to learn the hard way and there is no way I'm switching back to
tables if I can avoid it!

And lo, Jon didst speak in alt.www.webmaster:

> Hmm.. So far all the time I have used on this topic on usenet has been
> about answering questions that had little to do with my question. I'm
> sorry but I didn't post a question to answer questions about design
> decisions or whatever else people could come up with. My project is
> set, I have the design goals, I have a contract with my client that
> specifies everything. It's not up to debate and nothing will be
> changed. I do think usenet groups can be awarding in that you can get
> another pair of eyes on a subject. But this has been a complete waste
> of time.. Not only did I come up with a solution to my problem alone,
> I also wasted time answering question from people who didn't have an
> answer. This is all very sad, because this could really be a great,
> professional assistance in those hairy moments where you don't know
> what to do. I don't know what to do about it, but it's probably the
> last time I will post any questions here.

If your perception of Usenet is as nothing more than an information desk,
good riddance.

Usenet is a collaborative medium where everyone can voice their ideas. If
you have a problem with the discussion drifting to elements of your
problem you don't think are important, you should have phrased your
question in such a way as to provide the initial focus.

You had a "solution" to your problem decided upon from the beginning, you
only needed to know how to implement it. Yet instead you outlined your
entire situation then expected people to ignore all that context and just
give you the goods. Then when people began suggesting different (and
better) ways to resolve your situation, you got pissy about people wasting
your time. In case you haven't figured it out already, that makes you
pretty arrogant.

> For all of you who read this, please think again before you reply to a
> topic/question. A question about why my client don't use another
> application is really really pointless. I wouldn't be creating an
> application if there was no need or if my client wasn't paying. The
> simple answer to THAT question is that there is more to my application
> than just the calendar. Which IS really really beside the point. My
> question is about browser behavior and CSS. Nothing more and nothing
> else!

I'm sorry, but who are you? I ask because it sounds like you expected
your reputation and client history to have preceded you. I'm sorry to
dissappoint you, but it didn't. We have no clue at what point your
project is at, and what kind of urgency you require. How are we supposed
to know what still can or cannot be changed?

BTW, most of the suggestions offered you are indeed *better* solutions to
your problem. Don't blame us if what you really wanted was a quick hack
rather than valuable with the fundamental design.

> Thanks for your time. I hope you will think twice before asking
> questions to a question. We are all professionals and we all loose
> money on wasting time.
> Regards, Jon.

If it was a question of money, you should have gone to Experts-Exchange or
Yahoo! Answers. On Usenet, for a problem as general as you described it,
you're going to get a roundtable discussion as a response, and you're
being foolish to have expected anything else.

> PS. Please don't tell me it's easier to manipulate tables than divs -
> I had to learn the hard way and there is no way I'm switching back to
> tables if I can avoid it!

Oh yeah, that's exactly how I was going to end this post, with a comment
on how you should really be using tables. But it seems like you predicted
precisely what I was going to say. Now I am totally at a loss for words.
Looks like you win this one.

Grey

--
The technical axiom that nothing is impossible sinisterly implies the
pitfall corollary that nothing is ridiculous.
- http://www.greywyvern.com/orca#search - Orca Search: Full-featured
spider and site-search engine

Jon wrote:
> Hmm.. So far all the time I have used on this topic on usenet has been
> about answering questions that had little to do with my question. I'm
> sorry but I didn't post a question to answer questions about design
> decisions or whatever else people could come up with.

Your original post explored three different possible ways to solve your
problem. Exploring different ways to solve the problem was not out of line.

> My project is
> set, I have the design goals, I have a contract with my client that
> specifies everything. It's not up to debate and nothing will be
> changed.

Does the contract specify that a printable calendar must be created in
HTML with no tables?

> I do think usenet groups can be awarding in that you can get
> another pair of eyes on a subject. But this has been a complete waste
> of time.. Not only did I come up with a solution to my problem alone,
> I also wasted time answering question from people who didn't have an
> answer.

We did have answers. They weren't the answers you wanted, but they were
good answers.

> For all of you who read this, please think again before you reply to a
> topic/question. A question about why my client don't use another
> application is really really pointless. I wouldn't be creating an
> application if there was no need or if my client wasn't paying. The
> simple answer to THAT question is that there is more to my application
> than just the calendar. Which IS really really beside the point. My
> question is about browser behavior and CSS. Nothing more and nothing
> else!

Then why did your original question explore other options?

Your client has a calendar in PDF format. Your client wants other users
to obtain the same calendar. You mentioned that PDF was a possibility. I
suggested that it was the best option, and it could easily be done by
someone who knew how to do it.

And now you complain because it wasn't the answer you wanted.

Take it from someone who has been there. At some point someone will
email you and tell you that on X browser and Y operating system the page
won't print as expected.

> Thanks for your time. I hope you will think twice before asking
> questions to a question. We are all professionals and we all loose
> money on wasting time.

We are all professionals. Some of us have been there and done that. We
have learned the right way and the wrong way to do things. Exploring
better options is part of what we do here.