986098 - Wrong background url representation, url "-ing

Status: NEW

(Core :: DOM: CSS Object Model, defect, P5)

Description

[Sergey And]

User Agent: Mozilla/5.0 (iPad; CPU OS 7_1 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D167 Safari/9537.53

Steps to reproduce:

jQuery developers says that is firefox bug:
http://jsfiddle.net/shM68/2/
So, as you can see url in background style was "quoted".


Actual results:

http://jsfiddle.net/shM68/2/


Expected results:

No quotes like in other browsers.

Comment 1

[eisner2121]

I also am having an issue with line-height after the recent Firefox 28.0 browser update.  Not on all items however it seems to be affecting the <ul> <li> which have special properties assigned.  It also seems that the margin-top properties have been affected also.  This website worked perfectly until the recent update was applied.  It also seems to look perfectly fine in other browsers as well.  Please let me know if it's my mistake or if there is anything I can do on my end.  Thank you for your time!  

Page affected:  http:www.plumb-techplumbingandheating.com/index.html 

Towards the middle of the page the group of 8 list items are being shifted upwards into the text, and the line-height is no longer in effect.

Comment 2

[eisner2121]

Update -  After checking on an older version of Firefox (Version 19)  There seem to be no errors at all with line-height or margin spacing by pixels.

Comment 3

[Francesca Ciceri [:madamezou]]

Attachment: test_case_bug986098.html

Html testcase for bug 986098

Comment 4

[Francesca Ciceri [:madamezou]]

I can confirm the issue with line height at the page:

 http://www.plumb-techplumbingandheating.com/index.html 

with Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20140314220517. I don't think it's because of badly written CSS as the problem doesn't show with Chromium Version 32.0.1700.123 Debian jessie/sid (248368).

Attached is the minimal testcase I created: the style of the page is defined both in a style.css and inline, but I tried to strip it down to the essential. Also, I added a workaround on the comments of style.css (it's only about adding line-height:300% to ul, li).

Hope this helps!
Francesca

Comment 5

[Francesca Ciceri [:madamezou]]

Attachment: styles.css

css for 8397299: test_case_bug986098.html

Comment 6

[Manuela Muntean [Away]]

I can reproduce the issue mentioned in comment 1 with latest Nightly on Ubuntu 13.10 x86.

Comment 7

[Boris Zbarsky [:bzbarsky]]

The behavior shown in the original fiddle doesn't seem like a bug to me if it's talking about the url(foo) becoming url("foo"); it's just canonicalizing the value to an equivalent canonical one, which is what CSSOM generally expects to happen in this situation.  Note that in IE the canonicalization seems to happen even before you mess with the CSSOM, by the way.

The testcase from comment 3 shows content overlapping in both Gecko and Chrome, which is not surprising: the CSS explicitly sets a large negative top margin on that float, which pulls it up into the preceding text.

The page at http://www.plumb-techplumbingandheating.com/index.html shows the vertical spacing for the lists being very different in Gecko and Chrome; that's what causes the same negative margin to lead to different effects.  I assume that's what this bug report is really about.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase showing the vertical spacing difference clearly

The paddings are just there so you can see the whole image

Comment 9

[Boris Zbarsky [:bzbarsky]]

David, what's the right behavior per spec here, for an outside bullet?

Comment 10

[eisner2121]

Hey everyone, I'm sincerely appreciative for all of the help and suggestions.  I applied and tested the suggested CSS from comment #5 and inside of Firefox yes it works great, however a quick test over on IE 10 shows that the 2 groups do not line up as they did previously.  I guess this may be a slightly odd way to line up 2 groups of <li> however I'm simply trying to make this section of the site look like it was asked to look like.  If there is a better way to do this I'd be very grateful for any suggestions.  Again thank you very much for all of the help and support!

Respectfully,
   Eric

Comment 11

[Sergey And]

And what about a bug in https://bugzilla.mozilla.org/show_bug.cgi?id=986098#c0
All of you can reproduce it?

Comment 12

[Boris Zbarsky [:bzbarsky]]

> I guess this may be a slightly odd way to line up 2 groups of <li>

It's not just slightly odd, it's totally broken for users who are not using the default font size (e.g. because their vision is not great).  If what you want is a two-column layout, you probably just want to use a columnset, or a table if you need older browser support.

I also just realized that comment 1 hijacked the bug that was reported in comment 0 to talk about a totally unrelated issue, and then comments 3-5 ran with the hijacking.  :(

That bug as reported is invalid, though, so I guess we might as well stick with the comment 1 issue...

The behavior on that site changed back in December in this checkin range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=edac8cba9f78&tochange=0204febd3146 and is presumably due to us fixing bug 942017.

Mats, should we be treating text bullets differently from image bullets here?  It's not clear to me what the spec says in this situation...

Comment 13

[Boris Zbarsky [:bzbarsky]]

Oh, and the reason the issue reported in comment 0 is invalid is that http://dev.w3.org/csswg/cssom/#serialize-a-url explicitly says to do http://dev.w3.org/csswg/cssom/#serialize-a-string which adds the quotes.

Comment 14

[Sergey And]

Don't understand, why issue in comment 0 is invalid? O_o

Comment 15

[Boris Zbarsky [:bzbarsky]]

Sergey, because the spec explicitly says that url values are serialized as url("something"), with the quotes.

Comment 16

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

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

  # The size or contents of the marker box may affect the height of
  # the principal block box and/or the height of its first line box,
  # and in some cases may cause the creation of a new line box.
  # Note: This interaction may be more precisely defined in a
  # future level of CSS.

I think the marker should affect the line-height of the line with which the marker is aligned, just as it would if it were part of that line.  (Choosing that line is a bit tricky to define.)

Comment 17

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

I think we should just back out bug 942017.

Comment 18

[Sergey And]

Boris, where in http://dev.w3.org/csswg/cssom/#serialize-a-url or http://dev.w3.org/csswg/cssom/#serialize-a-string something about that url must be &quote;-ed? It's says that string must be escaped.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Uh... the second link explicitly says to start with a U+0022, then the string data, then another U+0022.

Comment 20

[eisner2121]

As advised above I attempted to use tables for current and older browser support, however the results were the same with unbalanced rows inside of IE.  I also attempted to use absolute positioning with the same unbalanced effect.

David thank you so very much for your input.  I've referenced bug 942017 and it seems like <li> and bullets are having numerous issues.  I've never used these forums so I'm unsure what it means as to back out on bug 942017.  Does this mean that this section of code applied to the current update will be reversed back to the previous patch which was unaffected?  If so, is there an estimated time that this would occur possibly?

Comment 21

[Sergey And]

I see, but why it's html &quoted;??? :)
For ex IE or Chrome - not "-ing. Chrome removes quotes (result: style="background: url(..)"), IE - changing style like this: style='background: url("..")'.

Comment 22

[Mats Palmgren (inactive)]

(In reply to Boris Zbarsky [:bz] from comment #12)
> Mats, should we be treating text bullets differently from image bullets
> here?

At first glance, that seems like the best option.

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-7) from comment #17)
> I think we should just back out bug 942017.

That would re-introduce the parity with IE and Chrome for the test in that bug.

Comment 23

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

This bug is a mess of confusion between two issues; I've moved the line-height issue to bug 989130.

Comment 24

[Boris Zbarsky [:bzbarsky]]

> I see, but why it's html &quoted;??? :)

Because it's inside an attribute value which is itself in double quotes.  Let's turn this around.  What output were you expecting and why?

Comment 25

[Sergey And]

(In reply to Boris Zbarsky [:bz] from comment #24)
> > I see, but why it's html &quoted;??? :)
> 
> Because it's inside an attribute value which is itself in double quotes. 
> Let's turn this around.  What output were you expecting and why?

style="background: url('...')" like in IE
or
style='background: url("...")' like in IE
or
style="background: url(...)" like in Chrome
or
style='background: url(...)' like in Chrome

Comment 26

[Boris Zbarsky [:bzbarsky]]

None of those follow the specs.  The specs are _very_ clear here.  When serializing a CSS url() value, it's serialized as url("foo") per the link above.  When serializing an HTML attribute value, it's serialized per http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#serializing-html-fragments which says:

  For each attribute that the element has, append a U+0020 SPACE character, the attribute's
  serialized name as described below, a U+003D EQUALS SIGN character (=), a U+0022
  QUOTATION MARK character ("), the attribute's value, escaped as described below in
  attribute mode, and a second U+0022 QUOTATION MARK character (").

Where "escaped as described below" links to http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#escapingString

Which is exactly what we're doing.

Also, you did not answer the key part of the question: _why_ were you expecting those 4 different output formats but not what the spec actually requires?

And a separate question: what practical problem is this causing?  The string produced per spec is one that, when parsed with an HTML parser, have url("foo") in the style attributes value, right?

Comment 27

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.