597778 - CSS2.1 rules for background-images and list-style-images without intrinsic size aren't followed, for SVG images

Status: REOPENED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

CSS 2.1 has rules for how to handle background images and list-style image that don't have an intrinsic size/ratio.  Our implementation of SVG-as-image doesn't seem to be following these rules (at least based on the tests below).

In particular, http://www.w3.org/TR/CSS21/colors.html#propdef-background-image says:

# If the image has one of either an intrinsic width or an intrinsic height
# and an intrinsic aspect ratio, then the missing dimension is calculated
# from the given dimension and the ratio.
#·
# If the image has one of either an intrinsic width or an intrinsic height
# and no intrinsic aspect ratio, then the missing dimension is assumed to
# be the size of the rectangle that establishes the coordinate system for
# the 'background-position' property.
#·
# If the image has no intrinsic dimensions and has an intrinsic ratio the
# dimensions must be assumed to be the largest dimensions at that ratio
# such that neither dimension exceeds the dimensions of the rectangle that
# establishes the coordinate system for the 'background-position'
# property.
#·
# If the image has no intrinsic ratio either, then the dimensions must be
# assumed to be the rectangle that establishes the coordinate system for
# the 'background-position' property.·

http://www.w3.org/TR/CSS21/generate.html#propdef-list-style-image says:

# The size of the image is calculated from the following rules:
#·
#  1. If the image has an intrinsic width or height, then that intrinsic
#     width/height becomes the image's used width/height.
#  2. If the image's intrinsic width or height is given as a percentage, then
#     that percentage is resolved against 1em.
#  3. If the image has no intrinsic ratio and a ratio cannot be calculated from
#     its width and height, then its intrinsic ratio is assumed to be 1:1.
#  4. If the image has a width but no height, its height is calculated from the
#     intrinsic ratio.
#  5. If the image's height cannot be resolved from the rules above, then the
#     image's height is assumed to be 1em.
#  6. If the image has no intrinsic width, then its width is calculated from the
#     resolved height and the intrinsic ratio.·


There are some tests on this in the CSS 2.1 test suite, at least for backgrounds:

http://test.csswg.org/suites/css2.1/20100917/xhtml1/background-intrinsic-001.xht
http://test.csswg.org/suites/css2.1/20100917/xhtml1/background-intrinsic-002.xht
http://test.csswg.org/suites/css2.1/20100917/xhtml1/background-intrinsic-003.xht
http://test.csswg.org/suites/css2.1/20100917/xhtml1/background-intrinsic-004.xht
http://test.csswg.org/suites/css2.1/20100917/xhtml1/background-intrinsic-005.xht
http://test.csswg.org/suites/css2.1/20100917/xhtml1/background-intrinsic-006.xht
http://test.csswg.org/suites/css2.1/20100917/xhtml1/background-intrinsic-007.xht
http://test.csswg.org/suites/css2.1/20100917/xhtml1/background-intrinsic-008.xht
http://test.csswg.org/suites/css2.1/20100917/xhtml1/background-intrinsic-009.xht

Comment 1

[Jeff Walden [:Waldo]]

This possibly may be why layout/reftests/backgrounds/background-size-no-intrinsic-{height,width}-image{,-ref}.html are still fails ==, rather than ==, despite SVG now being supported in CSS -- worth looking at that whenever a patch is being written/tested to see whether it's fixed or needs another bug.

Comment 2

[Daniel Holbert [:dholbert]]

Filed Bug 609714 on the tests from Comment 1.  (We match Opera & Chromium on those tests, so I think the tests might just be broken.)

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There have been some corrections to these tests; current versions are:
http://test.csswg.org/source/contributors/fantasai/submitted/css2.1/backgrounds/background-intrinsic-001.htm
etc.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(and -004 and -005 apparently still have a known bug in the test)

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to comment #4)
> (and -004 and -005 apparently still have a known bug in the test)

FWIW, those are the only tests that fail now -- all the rest of the tests (in -001 thru -009) pass in my nightly.
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20101215 Firefox/4.0b9pre

So maybe this was just due to test-bugs?

For reference, the URLs for those still-broken tests are:
http://test.csswg.org/source/contributors/fantasai/submitted/css2.1/backgrounds/background-intrinsic-004.htm
http://test.csswg.org/source/contributors/fantasai/submitted/css2.1/backgrounds/background-intrinsic-005.htm

Comment 6

[Daniel Holbert [:dholbert]]

FWIW, I think we follow the rules outlined in comment 0, except for this one that I don't think we actually want:
#  2. If the image's intrinsic width or height is given as a percentage, then
#     that percentage is resolved against 1em.

(Instead of that, we treat percent widths (the default) as "no intrinsic width", which I think is more sensible.  A SVG image with no explicit height/width attribute probably doesn't want to be cropped to 1em-by-1em.)

dbaron: is there still something broken here?  Perhaps this should be resolved WORKSFORME (or INVALID since it turned out the tests were broken?)

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you send feedback to the CSS WG about that rule? You should probably include tests for various browsers to show if they follow the rule or not.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I don't see where we implement this part of the background-image rule:

# If the image has no intrinsic dimensions and has an intrinsic ratio the
# dimensions must be assumed to be the largest dimensions at that ratio
# such that neither dimension exceeds the dimensions of the rectangle that
# establishes the coordinate system for the 'background-position'
# property.

I'm looking at ImageRenderer::ComputeSize and nsLayoutUtils::ComputeSizeForDrawing and I don't see any code that would do this.

Failing to do this (and instead following the rule for "no intrinsic ratio") would explain why we fail background-intrinsic-004 and background-intrinsic-005.

Comment 9

[Daniel Holbert [:dholbert]]

I believe that's part of what Waldo is working on fixing in Bug 609714.

Correct me if I'm wrong, but I think the rule you quoted in Comment 8 is equivalent to this chunk from Bug 609714 comment 3 (which I expand on in the subsequent comment there):
> If both values are ‘auto’
[...and...]
> the image has neither an intrinsic width nor an
> intrinsic height, its size is determined as for ‘contain’.
[contain rules:]
> Scale the image, while preserving its intrinsic aspect ratio (if any), to
> the largest size such that both its width and its height can fit inside the
> background positioning area.

Setting bug 609714 as blocking this bug.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Apparently no other browsers get this right either. I don't think we should block on this.

Comment 11

[Jeff Walden [:Waldo]]

The list-style-image part of this is probably some easy changes to nsBulletFrame -- much easier than background-size, because does rather intricate negotiation with the specified sizing information while list-style-image's rendering size is controllable to a much lesser extent.  Maybe when I finish the background-size stuff I'll jump over and do that (although I admit my drive to fix something I didn't only-incompletely-implement, outside the typical bugs I fix, is somewhat low :-) ).

Note that there's also some fugliness where tree frames custom-draw their own list-style-images, rather than sharing code with bullets or whatever.  Probably those two algorithms should both be abstracted into one, if they both use the same CSS property, although I didn't stare at the tree frame algorithm quite enough to determine whether this is really possible (and it might not be desirable, if l-s-i for trees is just that much different).

Comment 12

[Avol]

My experience in this bug.
I just want to set line as my unordered lists bullet without using hack with background or pseudo-element. The bullet must be vertically aligned on the center of text line and with size, related to text size.

HTML code:
<!DOCTYPE html>
<html>
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<style>
		ul
		{
			font-size: 20px;
			list-style-image: url("list_marker.svg");
		}
	</style>
</head>
<body>
<ul>
	<li>One</li>
	<li>Two</li>
	<li>Three</li>
</ul>
</body>
</html>

SVG code:
<svg xmlns="http://www.w3.org/2000/svg" viewPort="0 0 10 10"><line stroke="#000" y1="50%" x2="100%" y2="50%" stroke-width="10%"/></svg>

It works perfect in Chromium, but don't work in Geko.
When I press Ctrl+F5 in Firefox, I can see markers, but with wrong size. After any redraw operation (for example, changing of window size or refreshing with F5), they disappear. And this behavior is certainly a bug.

Comment 13

[Daniel Holbert [:dholbert]]

Avol: I can confirm that your sample-code doesn't render any list markers in Firefox Nightly. (even after a refresh, on my machine)

If you're just looking for a way to make this work, you should be able to do so by giving your SVG an intrinsic width and height -- e.g. add width="10" height="10" to your <svg> element. (Also, I think you want "viewBox" instead of "viewPort" -- there is no "viewPort" attribute on the <svg> element.)

[I'm unassigning myself from this bug, to reflect reality, since I'm not actively working on it at the moment, & so someone else can take a crack at it if they like.]

Comment 14

[Avol]

Thanks, Daniel.
"viewPort" -- yes, it's my fault, but it's had no effect -- all dimensions are in percentages.
I understand, that I can use fixed dimensions, but I want to make them relative to text size.