469,612 Members | 1,554 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,612 developers. It's quick & easy.

CSS style for Printing HTML select element

Hi,
I was wondering if anyone had a solution for printing HTML elements
(especially style elements). I do not wish to make any changes to the
page, other than in the <css media="print"block. I can use:

select {
border:1px solid #FFFFFF;
}

to get rid of the border, but dont know a way to get rid of the arrow
part of the element.

Essentially what I want is a set of styles which will allow printing of
the data contained in the HTML element, and not the interface part
itself.

Thanks for any input

Steve

Dec 13 '06 #1
8 17454
Scripsit Steve Macleod:
I can use:

select {
border:1px solid #FFFFFF;
}

to get rid of the border,
Can you? Doesn't work on IE 7, for example. Besides, to get rid of a border,
setting
border: none;
would be more natural.
but dont know a way to get rid of the arrow
part of the element.
You could try overflow: hide, on the grounds that the arrow might be a
consequence of implicit default overflow: scroll or overflo: auto, but this
doesn't seem to have an effect.

Form fields, especially select elements, are typically implemented in
browsers as widgets based on built-in routines that are relatively immune to
CSS, though to different degrees in different browsers.
Essentially what I want is a set of styles which will allow printing
of the data contained in the HTML element, and not the interface part
itself.
Why?

To let a user print a copy of his form data, it is better to have them
echoed to him by the server-side form handler. It can be echoed as a normal
HTML page, so that the data does not appear inside form fields. That way, it
can be printed or saved comfortably. You might then actually want to use CSS
to make the data look a bit like form data, or at least visually different
from normal content.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Dec 14 '06 #2
Building a page which is generated specifically as a print page is not
a problem, but this is what I am trying to get away from. I am working
on a healthcare system with over 600 database tables and the
maintenence of new/edit/view and print pages is getting time-consuming.
Id much rather have a solution where, when changes are required, I only
have to change one template, and for print, update the CSS accordingly.
Surely this is within the scope of CSS, no?
Jukka K. Korpela wrote:
Scripsit Steve Macleod:
I can use:

select {
border:1px solid #FFFFFF;
}

to get rid of the border,

Can you? Doesn't work on IE 7, for example. Besides, to get rid of a border,
setting
border: none;
would be more natural.
but dont know a way to get rid of the arrow
part of the element.

You could try overflow: hide, on the grounds that the arrow might be a
consequence of implicit default overflow: scroll or overflo: auto, but this
doesn't seem to have an effect.

Form fields, especially select elements, are typically implemented in
browsers as widgets based on built-in routines that are relatively immune to
CSS, though to different degrees in different browsers.
Essentially what I want is a set of styles which will allow printing
of the data contained in the HTML element, and not the interface part
itself.

Why?

To let a user print a copy of his form data, it is better to have them
echoed to him by the server-side form handler. It can be echoed as a normal
HTML page, so that the data does not appear inside form fields. That way, it
can be printed or saved comfortably. You might then actually want to use CSS
to make the data look a bit like form data, or at least visually different
from normal content.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/
Dec 14 '06 #3
Scripsit Steve Macleod:
Building a page which is generated specifically as a print page is not
a problem, but this is what I am trying to get away from.
Huh? What are you talking about? Upside-down fullquoting, the usual
indicator of lack of comprehensive reading, makes it impossible to guess
which parts of my message you understood. (Please google for "quoting on
usenet".) So I will try again; I'll type slower this time; hope it helps.
I am working
on a healthcare system with over 600 database tables and the
maintenence of new/edit/view and print pages is getting
time-consuming.
Then you should ask local IT support to give you some tools to work with.
You need some auxiliary software that lets you just fill in the content and
let a computer generate the various formats from a base file. I'm sure they
understand the problem if you explain what you need to achieve (in terms of
functionality for users) and how you work now. If they don't, complain to
your boss.
Id much rather have a solution where, when changes
are required, I only have to change one template, and for print,
update the CSS accordingly. Surely this is within the scope of CSS,
no?
No.

The template idea is great. Using CSS for the purpose is not great,
_especially_ if you'd need to change a form field to normal inline data,
effectively, in apperance.

Surely CSS helps you to tune the appearance on screen or paper, and
differently for screen and paper. But for selecting or reordering content,
CSS is very limited and cumbersome. For form fields, there's even less
success.

(I'm skipping the question why you would _want_ to print a form so that form
fields don't look like form fields. I'm sure the explanation might be
hilarious, but it's probably not essential.)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Dec 14 '06 #4

Steve Macleod wrote:
I was wondering if anyone had a solution for printing HTML elements
I stick them in a browser and press "print". What's your real problem
here? - it's hard to understand your post.

If you mean "How do I turn on and off great chunks of page when they're
printed" then this is easy with CSS.

Don't bother with print stylesheets and separate <linkelements with a
media attribute on them, just go with a single stylesheet and use the
@media rule within it.

Use classes of "no-print" and "print-only" in your HTML where needed.
Remember that you can have multiple classes on an element, just put
them all in the same attribute, whitespace separated.

Use "no-print" on a <formor a container <divrather than on the
<select>. Don't try and apply control to individual form elements, or
you make the design impossibly difficult to keep under control for both
presentations (you can do it, it's just hard)

CSS alone won't make a <selectprint as a list. If you need this, then
put the same content onto the page twice, once (maybe in a <ul>) with a
"print only" class on it.

Use appropriate length units for printing: dimensions of major design
elements in mm, maybe font-size in points. Remember that accessibility
still applies and someone might need a large-print copy. Remember that
it needs to work on other paper sizes too (legal vs. A4)

I often design fixed-width elements around text blocks with long lines.
These should be wider, or full-width when printed. Even though long
lines are still harder to read than short lines, it's not so critical
on paper compared to screen.

Changing the media selector temporarily from "print" to "screen" may
assist you during the coding and testing stage.
Try the following CSS snippet as a starting point

/* Print control */
..print-only{
display: none;
visibility: hidden;
}

@media print {

.print-only {
display: inherit;
visibility: display;
}

.no-print {
display: none;
visibility: hidden;
}
}

Dec 14 '06 #5
LOL well, aren't you a treat!

"let a computer generate the various formats from a base file"

Hmmm, sounds vague enough to be completely useless. When considering
that my original post related to a print style for (disabled) SELECT
elements, what exactly do you think I am trying to achieve.... could it
be generating the print format from a base file...? Our applications
are coded entirely in-house, if I want code to batch generate various
formats from a base HTML file I would have to write it myself. Given
the nature of the project I work with, a generic solution would not be
possible, furthermore, given the time constraints im working with,
in-practical. In reality I will probably use javascript to manually set
the display of each SELECT and INPUT element.

Incedently, after a little Goggling, I discovered that CSS 3 will
include the "CSS Paged Media" module, which is specifically designed to
render content on page-based media. Do you really think that CSS is
inappropriate for formatting a page for print? or are you just being
argumentative?


Jukka K. Korpela wrote:
Scripsit Steve Macleod:
Building a page which is generated specifically as a print page is not
a problem, but this is what I am trying to get away from.

Huh? What are you talking about? Upside-down fullquoting, the usual
indicator of lack of comprehensive reading, makes it impossible to guess
which parts of my message you understood. (Please google for "quoting on
usenet".) So I will try again; I'll type slower this time; hope it helps.
I am working
on a healthcare system with over 600 database tables and the
maintenence of new/edit/view and print pages is getting
time-consuming.

Then you should ask local IT support to give you some tools to work with.
You need some auxiliary software that lets you just fill in the content and
let a computer generate the various formats from a base file. I'm sure they
understand the problem if you explain what you need to achieve (in terms of
functionality for users) and how you work now. If they don't, complain to
your boss.
Id much rather have a solution where, when changes
are required, I only have to change one template, and for print,
update the CSS accordingly. Surely this is within the scope of CSS,
no?

No.

The template idea is great. Using CSS for the purpose is not great,
_especially_ if you'd need to change a form field to normal inline data,
effectively, in apperance.

Surely CSS helps you to tune the appearance on screen or paper, and
differently for screen and paper. But for selecting or reordering content,
CSS is very limited and cumbersome. For form fields, there's even less
success.

(I'm skipping the question why you would _want_ to print a form so that form
fields don't look like form fields. I'm sure the explanation might be
hilarious, but it's probably not essential.)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/
Dec 14 '06 #6
Why thank you for your constructive answer.
Im using some of these things already, but there are some good ideas in
there.I think the way to go at the moment is to use a seperate div with
print class to render the elements which present problems to standard
print CSS (select/option and input specifically)

Thanks again

Andy Dingley wrote:
Steve Macleod wrote:
I was wondering if anyone had a solution for printing HTML elements

I stick them in a browser and press "print". What's your real problem
here? - it's hard to understand your post.

If you mean "How do I turn on and off great chunks of page when they're
printed" then this is easy with CSS.

Don't bother with print stylesheets and separate <linkelements with a
media attribute on them, just go with a single stylesheet and use the
@media rule within it.

Use classes of "no-print" and "print-only" in your HTML where needed.
Remember that you can have multiple classes on an element, just put
them all in the same attribute, whitespace separated.

Use "no-print" on a <formor a container <divrather than on the
<select>. Don't try and apply control to individual form elements, or
you make the design impossibly difficult to keep under control for both
presentations (you can do it, it's just hard)

CSS alone won't make a <selectprint as a list. If you need this, then
put the same content onto the page twice, once (maybe in a <ul>) with a
"print only" class on it.

Use appropriate length units for printing: dimensions of major design
elements in mm, maybe font-size in points. Remember that accessibility
still applies and someone might need a large-print copy. Remember that
it needs to work on other paper sizes too (legal vs. A4)

I often design fixed-width elements around text blocks with long lines.
These should be wider, or full-width when printed. Even though long
lines are still harder to read than short lines, it's not so critical
on paper compared to screen.

Changing the media selector temporarily from "print" to "screen" may
assist you during the coding and testing stage.
Try the following CSS snippet as a starting point

/* Print control */
.print-only{
display: none;
visibility: hidden;
}

@media print {

.print-only {
display: inherit;
visibility: display;
}

.no-print {
display: none;
visibility: hidden;
}
}
Dec 14 '06 #7

Steve Macleod wrote:
Do you really think that CSS is
inappropriate for formatting a page for print?
CSS (typical implementations) is already great for formatting when
printing.

Page-flow control is in the CSS recommendation, but not usefully
implemented yet.

Control of pages (page size etc.) is an awful long way away.

HTML flow model (lack of newspaper columns etc) isn't going to be fixed
by any CSS alone. If you need that level of control, look at XSL:FO
instead.

Dec 14 '06 #8
Scripsit Andy Dingley:
CSS (typical implementations) is already great for formatting when
printing.
For some peculiar values of "great" maybe, but you seem to have forgotten,
for example, what the question was I about. Please consult the Subject line
if needed. (It's very well formulated Subject line. Too bad Steve Macleod
decided to behave destructively in other ways, even continuing upside-down
fullquoting, so he clearly wants to avoid expert help.)

The problem we were told about just arise from the fact that CSS is fairly
weaponless in front of <select>, if you want to do something fancy to it
(which of course normally means that you're spending your time creating
problems, not solving them, but that's a different issue).
Page-flow control is in the CSS recommendation, but not usefully
implemented yet.
It isn't even in either of the two CSS recommendations that exist, namely
CSS 1.0 and CSS 2.0. (It is inappropriate to cite the CSS 2.1 draft as other
than "work in progress", to quote the draft itself.)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Dec 14 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Henrik J?nsson | last post: by
16 posts views Thread by Geoff Cox | last post: by
5 posts views Thread by Jeremy | last post: by
9 posts views Thread by netclectic | last post: by
3 posts views Thread by Michele Locati | last post: by
reply views Thread by devrayhaan | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.