RESOLVED CONFIGURATION CHANGED 145937
Vertical-aligned of RenderText should not contribute to a layout.
https://bugs.webkit.org/show_bug.cgi?id=145937
Summary Vertical-aligned of RenderText should not contribute to a layout.
ChangSeok Oh
Reported 2015-06-12 14:00:03 PDT
Attachments
Patch (5.57 KB, patch)
2015-06-12 15:46 PDT, ChangSeok Oh
no flags
Patch (5.57 KB, patch)
2015-06-12 15:51 PDT, ChangSeok Oh
hyatt: review-
All browsers match each other (959.81 KB, image/png)
2023-08-26 15:19 PDT, Ahmad Saleem
no flags
ChangSeok Oh
Comment 1 2015-06-12 15:46:17 PDT
ChangSeok Oh
Comment 2 2015-06-12 15:51:09 PDT
ChangSeok Oh
Comment 3 2015-06-16 11:07:21 PDT
Hrm.. Does this also need to be reviewed by Hyatt?
Darin Adler
Comment 4 2015-06-16 12:07:12 PDT
I think it does. I understand the problem but I am not sure this is the best solution and would like his view on that. And maybe Simon’s as well.
Dave Hyatt
Comment 5 2015-06-16 12:34:50 PDT
Comment on attachment 254830 [details] Patch This does not seem right to me. Vertical alignment was supposed to be computed for line boxes independently, so if there's a mis-positioning occurring, I think the mistake is in the calling code and has nothing to do with the value returned by the RenderText.
ChangSeok Oh
Comment 6 2015-06-17 22:21:14 PDT
(In reply to comment #5) > Comment on attachment 254830 [details] > Patch > > This does not seem right to me. Vertical alignment was supposed to be > computed for line boxes independently, so if there's a mis-positioning > occurring, I think the mistake is in the calling code and has nothing to do > with the value returned by the RenderText. Thanks for your comment, dhyatt! However I can't follow your comment, especially 'computed independently'. As my understanding the spec, verticalAlign is not something computed, it's a just given thing by content since it is not inheritable. In that context, raw text nodes, i.e RenderText, can't have verticalAlign style, but it does in WebKit. Because it reuses the shared container block's style even though it's not inheritable. I think that's the root cause. (Maybe why webkit does like that is for saving memory consumption?). InlineBox returns its renderer's verticalAlign, so it already seems not that 'independent' from renderer. In other words, it already does something with the value of RenderText. we can't allocate own styles for text nodes with any reason and the verticalAlign is a given style, not inherited one, so that we can't solve the issue by fixing its render style. If that's the case, the next possible approach would be fixing it through a commonly used interface. That's the InlineBox::verticalAlign() in my humble opinion. As you said, if we try to fix the issue by adding a workaround to near caller's place, then we might need to add the extra condition, is<RenderText>, everywhere calling verticalAlign() in InlineFlowBox.cpp. I think that's not a neat way since it sounds that potential verticalAlign issues still remain, because which can lead someone to make easily a mistake. It would be appreciated if you can correct me if any. =)
Koji Ishii
Comment 7 2016-04-13 04:45:07 PDT
Blink took the similar fix, which regressed and fixed differently. Please refer to http://crrev.com/1178473003#msg19 and http://crbug.com/496850#c7.
Ahmad Saleem
Comment 8 2023-08-26 15:19:04 PDT
Created attachment 467452 [details] All browsers match each other I think Safari Technology Preview 177 matches with other and even Safari 16.6 is same as STP177. Do we need to do anything else?
Note You need to log in before you can comment on or make changes to this bug.