763349 - @media print rules are not followed when an SVG image is embeded through an img tag

Status: REOPENED

(Core :: SVG, defect)

Description

[Jeremie Patonnier :Jeremie]

Attachment: SVG image for the test case

When an SVG image has a internal style sheet, if this image is embeded in a web page using an img tag, when you print the html page, the CSS @media rules inside the SVG image are not followed.

In the provide test case, the SVG image have a following CSS @media rule to print it B&W.

If you print the image while it's embeded in an HTML document through an img tag, the image remain colored when printed. 

If you print the image while it's embeded in an HTML document through an object tag the image is printed B&W as expected.


So in the test case :

Actual result : The image is printed in color

Expected result : The image should be printed in B&W

Comment 1

[Jeremie Patonnier :Jeremie]

Attachment: HTML file for the test case

Comment 2

[Masatoshi Kimura [:emk]]

This is intentional. See bug 628747.

Comment 3

[Masatoshi Kimura [:emk]]

Sorry, I misread @media as @import.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So one problem here is that the presentation is part of the image, right?  And we're sharing the image between the print and screen media here....

Comment 5

[Jeremie Patonnier :Jeremie]

(In reply to Boris Zbarsky (:bz) from comment #4)
> So one problem here is that the presentation is part of the image, right? 

As an SVG image with CSS inside it, yes.

> And we're sharing the image between the print and screen media here...

Not sure to understand what you mean. Yes, the image is used in both media. 

For what I can see, when gecko send the data to the printer, if the image is embeded with an <object> tag, it recomputes the pixels of the image to scale it properly and eventually applies the @media rules ; if the image is embeded with an <img> tag, it directly sends the pixels to the printer without recomputing the SVG image.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Not sure to understand what you mean.

Sorry, the comment was mostly directed at Daniel, and was about implementation details of the media code.  I'm happy to explain over e-mail if you're interested; just drop me a line.

Comment 7

[Daniel Holbert [:dholbert]]

Two possible strategies:
* The host document can get access to the image's presentation via imgIContainer::GetRootLayoutFrame()->PresContext() -- perhaps we could use that to temporarily toggle it to print mode, just while we paint? (If print-mode is dynamically configurable on the presentation -- I'm not sure whether it is.)

* Alternately, we could do some sort of "imgIRequest* imgIRequest::ForkForPrinting" sort of thing, to get a dedicated copy of the image which is in print mode from the start...

Comment 8

[Boris Zbarsky [:bzbarsky]]

> If print-mode is dynamically configurable on the presentation

There's no way to do it right now, and I would not assume that things would work if it were hacked in.  You'd certainly have to build a new frame tree, in any case....  Might as well just recreate the prescontext.

> to get a dedicated copy of the image which is in print mode from the start

This makes more sense to me, honestly.  We can use our existing document-cloning infrastructure there, I think.

Comment 9

[Daniel Holbert [:dholbert]]

I'm also not entirely convinced this is a use-case we want to support for SVG-as-an-image...

I don't think we can generally support CSS media queries in SVG-in-an-image (e.g. projection vs. screen, window-size checks, etc.) without giving each client of the image its own dedicated SVG document, and that's probably out of the question.

Maybe printing is special enough that we want to special-case it though?

Comment 10

[Jeremie Patonnier :Jeremie]

(In reply to Daniel Holbert [:dholbert] from comment #9)
> I'm also not entirely convinced this is a use-case we want to support for
> SVG-as-an-image...
Why that?

> I don't think we can generally support CSS media queries in SVG-in-an-image
> (e.g. projection vs. screen, window-size checks, etc.) 
I ran some tests with media queries and except for direct SVG document or SVG-in-HTML they never apply if the SVG image is embeded in an <object> or, obviously an <img>.

> without giving each
> client of the image its own dedicated SVG document, and that's probably out
> of the question.
I don't understand the implication here but author could expect to have the internal steelsheet of embeded image reacting to the state of the main document they are embeded in... actually I did.

> Maybe printing is special enough that we want to special-case it though?
I think so, that's why I special cased this bug

Comment 11

[Jeremie Patonnier :Jeremie]

(In reply to Jeremie Patonnier from comment #10)
> > I don't think we can generally support CSS media queries in SVG-in-an-image
> > (e.g. projection vs. screen, window-size checks, etc.) 
> I ran some tests with media queries and except for direct SVG document or
> SVG-in-HTML they never apply if the SVG image is embeded in an <object> or,
> obviously an <img>.
Ah sorry, I was a bit to fast here. An SVG image embeded through an <object> tag react pretty well to media queries. However, window-size media queries behave unintuitively, they do not react on change happening to the main document. I think I understand why but many author could be confused by that behavior.

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Jeremie Patonnier from comment #11)
> Ah sorry, I was a bit to fast here. An SVG image embeded through an <object>
> tag react pretty well to media queries. However, window-size media queries
> behave unintuitively, they do not react on change happening to the main
> document. I think I understand why but many author could be confused by that
> behavior.

Technically it's the "viewport size" that's queryable, so I'd expect it to react to the size of the <object> element (the viewport into which the SVG is being rendered).

(In reply to Jeremie Patonnier from comment #10)
> I don't understand the implication here but author could expect to have the
> internal steelsheet of embeded image reacting to the state of the main
> document they are embeded in... actually I did.

That's precisely the problem.  If we wanted to do that in general (have the internal stylesheet of the image react to the state of the main document, the image viewport-size, etc.), then each instance of an SVG image would need its own dedicated copy of the SVG document.  That'd be pretty inefficient, and it's not how imagelib works right now -- it's optimized to share images between clients.

It's technically possible, but it'd require some significant rearchitecting.

Does this work in other browsers, out of curiosity?

If/when an SVG spec ends up explicitly specifying how it behaves in an image (scripting, click interactions, animation, etc. -- probably via Doug Schepers' "Referencing Modes"[1]), it should probably specify how media queries behave, as well...

[1] http://dev.w3.org/SVG/modules/integration/SVGIntegration.html#referencing_modes

Comment 13

[Jeremie Patonnier :Jeremie]

(In reply to Daniel Holbert [:dholbert] from comment #9)
> Maybe printing is special enough that we want to special-case it though?

I ran a few test recently about this use case :
http://jeremie.patonnier.net/experiences/svg/media-queries/test.html

I will push them to the CSS WG and the SVG WG for further discussion about media queries.

However, about the @media print, I'm still convince that it should be handled for SVG-as-img. I understand that media queries that relay on the viewport states are a very problematic case that should be discuss elsewhere but in the case of media type, it really make sens to have the image rerender for the given media.

For what is worth, the @media print type in SVG-as-img is not handled in any browser. 
 - Firefox, Chrome and Safari only print the pixels image and never rerender it to follow the @media print rule :( 
 - Opera does not print the SVG-as-img at all! 
 - I wasn't able to test IE9+

Comment 14

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to Daniel Holbert [:dholbert] from comment #9)
> I don't think we can generally support CSS media queries in SVG-in-an-image
> (e.g. projection vs. screen, window-size checks, etc.) without giving each
> client of the image its own dedicated SVG document, and that's probably out
> of the question.

I think the demand for SVG-in-an-image to adapt to its viewport is only going to grow (at last week's Firefox DevCon in Osaka, all anyone wanted to talk about was responsive design, and there was a lot of interest in a demo I showed with responsive SVG).

For now, I guess the answer is "use <object> for that", but if we find a way to support this for <img> (e.g. special casing all SVG images with @media rules) that would be ideal. That is to say, I'm not entirely sure that special-casing print only is the right approach.

Comment 15

[:Gijs (he/him)]

The general version of this (@media rules (for min/max-resolution, in our case) not applying, also when using list-style-image or background-image) is biting us in bug 1173725. :-(

Comment 16

[Robert Longson [:longsonr]]

Attachment: HTML file for the test case

Comment 17

[Daniel Holbert [:dholbert]]

Comment 16 prompted me to retest in other browsers, and it seems like things haven't changed since comment 13 here. Firefox/Chrome/Safari all show the image in color when I print-preview the html testcase, as well as when I click through to print-to-PDF.