1114454 - bizarre layout issue

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Glenn Linderman]

Attachment: svg-sample.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045

Steps to reproduce:

Load attached file into Firefox (34 or 36 dev, same results)


Actual results:

I'm trying to format music in a funny way, but the lines don't line up. No music in the attached files, just the lines, stripped out the unnecessary stuff.


Expected results:

So I'm using non-standard tag names, but <s-> should be a column of music, 3 staves. Between the 2nd and 3rd staff, a <t-> should contain the text... this has been stripped too, except for a Chinese "1" character, and some xxx's. But, with all the cruft stripped, the problem is still demonstrated. I made a copy of the left two columns, wondering if it was something special about the corner, but no, it repeated.

My thought was that each <s-> would be laid out from the top down, rather than leaving a gap at the top. So the 1st and 3rd <s-> tag have gaps.

Note the 1st are 3rd <s-> content is identical, but 3rd <s-> is slightly higher than the first. I see no obvious reason why they shouldn't all line up, at least at the top...

Curiously, if one deletes the Chinese 1 from the <t-> inside either the 1st or 3rd <s->  (just the character, not the enclosing <p> which has a fixed height), the 1st or 3rd <s-> rises to the top... but pushes down the 2nd & 4th <s->. I don't have a clue why changing the content of one <s-> should affect the other, except by pushing it to the right. Each <s-> should be fully self-contained, without impact on the vertical position of the others.

In attempting to debug this, I created bug 1113483, which laments the lack of position reporting... of course it would be even better if the reason for the position were available as well. I see no obvious reason for these vertical positions.

In attempting to debug this, I noticed that for the first <p> in the first <t-> in the first <s-> (where the Chinese "1" is), the Box Model reports the size as 27x20, but the lines overlaid on the browser viewport include a report of 28x20. Then in the <t-> in the last <s->, I noticed the first <p> has a Box Model size of 33x20, and an overlay report of 34x21, and the last <p> there has a Box Model size of 39x17 and an overlay report of 39x18.  I understand there can be floating point rounding in the scaled dimensions, but don't understand why the reports should be different. Once the rounding is done, the number of pixels should be well-known, and correctly reported. This discrepancy in both width and height reporting makes me wonder how I'll be able to debug my stacked boxes with any accuracy. I'm using explicit box heights for each of the items, so I would expect that they should all stack consistently, and that even my bottom row of staff segments should align... but so far I haven't gotten the top row to align.  I did get several now-deleted stacks to align, but without these stacks being consistent, I have uncertainty as to the reliability of the overall method.

The theory I started from was that the widths of the items would impact the widths of the stacks, and that would provide the vertical alignment desired, by centering all the content. And then the heights of each item of content would be fixed, providing horizontal consistency.

Workarounds would be helpful... I have thought of using position: absolute; and one experiment indicates that that would work. But I'm sure curious why this scheme doesn't work. Since I get a similar visible effect in Chrome, I do wonder if it is a markup problem, but even if it is, the development tools aren't helping me figure it out, and I'm seeing these inconsistent numbers in the debugger, so I thought it would be worth reporting the bug for that, even if my main problem is markup.

Comment 1

[Glenn Linderman]

OK, the top alignment problem can be fixed by adding

#gbd-words s- { vertical-align: top; }

but I'm not at all sure why the baselines were different in content with identically structured data.

And then the misalignment of the bottom staff lines becomes much smaller, but more apparently a different problem, likely related to precision and rounding, but again, with the same box heights given to all the boxes within each <s->, it is not at all clear why they don't have the exact same rounding. So even if a particular box would be (perhaps surprisingly) a pixel different in size from what might have been expected, since the exact same floating point numbers should be used for each <s-> stack, it is quite surprising to get different answers for the stack height. The exact same floating point numbers should be used, because the exact same heights and scale factors are being used.

The debug tools report all the heights the same, but get a different sum for the size of the <s-> tags in different stacks.

Comment 2

[Glenn Linderman]

So I found that the "computed" column reports the floating point sizes. In all the columns, the computed heights are the same, to the reported precision. So it is not at all clear why the sum for height of <t-> would be different in the various columns. The heights before are the same also, so they don't seem to give an excuse for different rounding, either.

Comment 3

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

Given that Chrome gives the same results, I'd presume that it isn't a bug unless you have a simpler and more concise testcase and explanation and a summary of what the bug actually is.  Feel free to reopen this bug report if you do, but we don't have the resources to help you debug things.

If you're looking for the relevant specs, start from http://dev.w3.org/csswg/css2/visudet.html#line-height .