Open
Bug 597778
Opened 14 years ago
Updated 2 years ago
CSS2.1 rules for background-images and list-style-images without intrinsic size aren't followed, for SVG images
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
REOPENED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: dbaron, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-needed)
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
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Updated•14 years ago
|
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+
Comment 1•14 years ago
|
||
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.
Reporter | ||
Updated•14 years ago
|
Blocks: css2.1-tests
Comment 2•14 years ago
|
||
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.)
Updated•14 years ago
|
Keywords: dev-doc-needed
Reporter | ||
Comment 3•14 years ago
|
||
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.
Reporter | ||
Comment 4•14 years ago
|
||
(and -004 and -005 apparently still have a known bug in the test)
Comment 5•14 years ago
|
||
(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•14 years ago
|
||
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?)
blocking2.0: final+ → -
blocking2.0: - → final+
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
Closed: 14 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 8•14 years ago
|
||
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 → ---
Comment 9•14 years ago
|
||
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+ → -
Comment 11•14 years ago
|
||
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•10 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.
Comment 13•10 years ago
|
||
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•10 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•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Product: Core Graveyard → Core
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•