No style for print and projection media types

Should this also work for a link like this to a printer version:

 <a rel="alternate" media="print" type="text/html"
  href="print.html"
  title="Printer formated version of this page.">Printer Friendly</a>

ie. a rel attribute on a <a> element in the body in addition to working for
<link> elements in the head?

> <a rel="alternate" media="print" type="text/html"
> href="print.html"
> title="Printer formated version of this page.">Printer Friendly</a>

Probably no.

However, it was hotly debated whether to recognize REL attributes on A elements
in bug 87428. I eventually disabled it because of performance reasons. With
some fixes to the link toolbar that should improve performance (bug 102992) this
reason may become moot.

I thought there was an enhancement to check REL attributes on A elements when
building the link toolbar, but I can't find it. One should be created if it
doesn't exist. Then we can debate the issue in that bug instead of here.
Whatever decision applies to the link toolbar should apply to this bug.

I think this is a dup. It's not related to the Links Bar; removing dependency.

Note that this behavior must be overridable, to guard against the case where
annoying authors specify <link rel="alternate" media="print"
href="you-cant-copy-this-page-so-nyah-nyah-nyah.txt" />.

> It's not related to the Links Bar; removing dependency.

It is related, because "printer friendly" alternates will need to be omitted
from the Links Bar, just as stylesheets are now. Restoring dependency.

> Note that this behavior must be overridable
...

Agreed.

if you go to http://gemal.dk/test/print.html and press Print or Print Preview
the page that should be printed/shown is http://gemal.dk/test/print.html?print=1

The pages are the same the print=1 is just added for testing.

is this really future? Also the preview stuff? Getting the URL specified in the
link media print url for print preview couldn't be soo hard ...?

to Rods to look at these issues

Note that printing prints the DOM, not a url. So this will require architecture
work and such (fetching data from a URL, parsing into a DOM, printing the DOM,
but only in some cases).

I would say this is lower-priority for 1.0 than, say, getting print preview to
be usable.

Removing "Dupeme" from status whiteboard.

This feature has been included in IE since version 4 (i think, it is definatly
in version 6). It is not supported in Netscape 4.

Relevant standards are at
http://www.w3.org/TR/html4/present/styles.html#adef-media (it is worth scrolling
up as well as down, but that is a good place to start).

Ian, stylesheet media have nothing to do with this bug. Mozilla supports
stylesheet media. This bug is a request to get the resource pointed to by a
<link rel="alternate" media="print"> tag and print it when a page is printed.
Nowhere do stylesheets enter that picture.

Sorry, I gave you the wrong url.

http://www.w3.org/TR/html4/types.html#type-media-descriptors
(my point was that this is in the standards, unlike a lot of LINK which is vague
in the standards).

But it does raise the question of what to do with a tag like:
<link rel="alternate stylesheet" media="print">

I couldn't see any reference to this in the standards, but it would seem
sensible to print the current document with this stylesheet if no suitable
printer friendly versions were found in other link tags.

It was suggested that this functionality could be overridden by the user. Good
point.

Where I work, we offer PDFs of many documents and it would be really nice to
have those PDFs automatically *suggested* as the preferred printable alternative
when available. However, they should not be forced on the user. There must be
a way for the user to easily refuse this because not everyone wants a PDF (or
whatever format a given web site wants to suggest). The auto-print function
would need a mechanism to degrade gracefully.

Perhaps some kind of confirm dialogue could be used to notify the user that we
are downloading a new page for printing? Or if the download is rapid, maybe
just a visible notification on the print preview that this is a document other
than teh original HTML page. On another level, maybe users can specify in
their preferences which file formats they accept and refuse as auto-printable,
to reduce the number of confirm dialogues.

Just some thoughts...

All/all.

Created an attachment (id=123120)
Dynamically changes the page actually printet using rel=alternate

Shows an example on changing the page actually printet.
Works in IE6 on XP, should work in Mozilla too, but does not

*** Bug 234869 has been marked as a duplicate of this bug. ***

I'd suggest adding a checkbox "Use alternate document for printing" to the print
dialog, which is disabled when no such <link> is present, and checked as default
when such a link is present.

If the alternate document is text/html or whatever other type mozilla can
handle, the user has the normal options like preview etc..

If mozilla does not know what to do with such a file, all options but save to
file or send to printer are disabled. The user can then save the file and print
it with the appropriate application (maybe mozilla could also suggest executing
this application for the user) or the user's print subsystem has to care about
the type of file.

dup of Bug 51848 ?

Suggest following changes to this bug:

- It is *not* related to: 103053 or 104586 (Link toolbar).

- Consider that the priority of this bug may have increased as the use of dynamic content (both on the server and on the client) has become much more widespread. Merely changing CSS for print media is often not enough and whole alternate versions of the pages or forms must be loaded instead when a user selects File=>Print. This capability has also been in the W3C standards for some time now.

I do not believe this bug should be fixed. When the user clicks "print", I believe they expect to print roughly the content that is currently in their browser, not some other content which could potentially be radically different. We (and all other modern browsers) already allow for different styling of print via @media CSS selectors.

Adding a checkbox to the print dialog is both difficult to do cross-platform and just asks the user to make a decision without the necessary context.

Recommend WONTFIX.

HTML4 says that the media attribute applies only to style sheets:
# This attribute specifies the intended destination medium for style information.
# It may be a single media descriptor or a comma-separated list. The default
# value for this attribute is "screen".
  --http://www.w3.org/TR/html4/present/styles.html#adef-media

Current HTML5 draft says:
# The media attribute says which media the resource applies to. The value
# must be a valid media query. [MQ]
#
# If the link is a hyperlink then the media attribute is purely advisory, and
# describes for which media the document in question was designed.
#
# However, if the link is an external resource link, then the media attribute is
# prescriptive. The user agent must apply the external resource to views while
# their state match the listed media and the other relevant conditions apply,
# and must not apply them otherwise.
  --http://www.w3.org/TR/html5/semantics.html#attr-link-media

So this feature request isn't even backed by any specifications.

From the spec

# Link Types
# Alternative
# Designates substitute versions for the document in which the link occurs.
# When used together with the lang attribute, it implies a translated version
# of the document. When used together with the media attribute, it implies
# a version designed for a different medium (or media).
http://www.w3.org/TR/html4/types.html#type-links

*** Bug 545944 has been marked as a duplicate of this bug. ***