Last Comment Bug 763349 - @media print rules are not followed when an SVG image is embeded through an img tag
: @media print rules are not followed when an SVG image is embeded through an i...
Status: REOPENED
:
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-10 14:17 PDT by Jeremie Patonnier :Jeremie
Modified: 2015-07-10 03:34 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
SVG image for the test case (1.56 KB, image/svg+xml)
2012-06-10 14:17 PDT, Jeremie Patonnier :Jeremie
no flags Details
HTML file for the test case (273 bytes, text/html)
2012-06-10 14:19 PDT, Jeremie Patonnier :Jeremie
no flags Details

Description Jeremie Patonnier :Jeremie 2012-06-10 14:17:30 PDT
Created attachment 631773 [details]
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 2012-06-10 14:19:21 PDT
Created attachment 631774 [details]
HTML file for the test case
Comment 2 Masatoshi Kimura [:emk] 2012-06-10 20:00:35 PDT
This is intentional. See bug 628747.
Comment 3 Masatoshi Kimura [:emk] 2012-06-10 20:03:37 PDT
Sorry, I misread @media as @import.
Comment 4 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-06-11 08:56:36 PDT
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 2012-06-11 09:25:07 PDT
(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 [:bz] (Out June 25-July 6) 2012-06-11 09:27:43 PDT
> 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] (largely AFK until June 28) 2012-06-11 09:37:56 PDT
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 [:bz] (Out June 25-July 6) 2012-06-11 09:42:29 PDT
> 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] (largely AFK until June 28) 2012-06-11 09:48:16 PDT
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 2012-06-11 09:57:32 PDT
(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 2012-06-11 10:05:34 PDT
(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] (largely AFK until June 28) 2012-06-11 10:19:27 PDT
(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 2012-07-06 12:26:35 PDT
(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) 2012-07-08 16:36:38 PDT
(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 Kruitbosch 2015-07-10 03:34:04 PDT
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. :-(

Note You need to log in before you can comment on or make changes to this bug.