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

REOPENED
Unassigned

Status

()

defect
REOPENED
9 years ago
9 months ago

People

(Reporter: dbaron, Unassigned)

Tracking

(Blocks 1 bug, {dev-doc-needed})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

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
blocking2.0: --- → ?
Summary: CSS2.1 rules for background-images and list-style-images without intrinsic size aren't followed → CSS2.1 rules for background-images and list-style-images without intrinsic size aren't followed, for SVG images
Assignee: nobody → dholbert
blocking2.0: ? → final+
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.
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.)
(and -004 and -005 apparently still have a known bug in the test)
(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
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?)
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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
Depends on: 609714
Apparently no other browsers get this right either. I don't think we should block on this.
blocking2.0: final+ → -
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

4 years ago
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.
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.]
Assignee: dholbert → nobody

Comment 14

4 years ago
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.

Updated

9 months ago
Product: Core → Core Graveyard

Updated

9 months ago
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.