Ticket #537 (closed Enhancement: fixed)
dm4-box-renderer-dom: in chromium long topic labels are not wrapped correctly
Reported by: | Malte | Owned by: | |
---|---|---|---|
Priority: | Minor | Milestone: | |
Component: | DeepaMehta Standard Distribution | Version: | 4.1.2 |
Keywords: | Cc: | ||
Complexity: | 3 | Area: | GUI / Usability |
Module: |
Description
In firefox there is no such issue, the box wraps the label correctly.
Attachments
Change History
Changed 11 years ago by Malte
- Attachment dm_box_renderer_label.png added
comment:1 follow-up: ↓ 4 Changed 11 years ago by Malte
BTW: The scrollbar on the x-axis (which appears in the chromium rendering of the webclient for about just 2 pixels) as seen in the screenshot above seems to be a wicked issue and does not happen in firefox.
I just know we could prevent this to happen through changing the following style definition:
#page-content { margin-left: from currently "1.6em" to any value smaller or equal to "1.5em"; }
I suppose chromium interprets such paddings or margins super-slightly different than other browsers, I heard stuff like that but I actually don't know.
comment:3 in reply to: ↑ description ; follow-up: ↓ 5 Changed 11 years ago by jri
Replying to Malte:
dm4-box-renderer-dom: in chromium long topic labels are not wrapped correctly.
In firefox there is no such issue, the box wraps the label correctly.
From my perspective it looks like: long labels which contain no spaces do not line wrap, regardless of browser.
Yes, in this case the label exceeds the blue topic box.
With dm4-box-renderer-dom topic label line wrapping relies on the browser rendering engine. So, what should we do?
Should we consider overflow=hidden?
comment:4 in reply to: ↑ 1 Changed 11 years ago by jri
Replying to Malte:
BTW: The scrollbar on the x-axis (which appears in the chromium rendering of the webclient for about just 2 pixels) as seen in the screenshot above seems to be a wicked issue and does not happen in firefox.
This is solved in the course of #543, right?
I just know we could prevent this to happen through changing the following style definition:
#page-content { margin-left: from currently "1.6em" to any value smaller or equal to "1.5em"; }
Yes, this would work, but do not solve the underlying problem, which is, as you mention below, the different ways the browsers do geometry calculations. With 1.5em Safari in turn would not use the entire screen.
DM solved the problem by not involving hardcoded pixel constants in its JavaScript? geometry calculations but measure the actual DOM elements. This way the geometry is (nearly) perfect in all browsers automatically (see #543).
I suppose chromium interprets such paddings or margins super-slightly different than other browsers, I heard stuff like that but I actually don't know.
What I've experienced is Safari's size calculations are integer based while Firefox and Chrome's are float based. E.g. 1.6em = 25.6 pixel. In Safari it results in 25 pixel on-screen, while Firefox and Chrome take it as is, 25.6, resulting in 26 pixel on-screen.
comment:5 in reply to: ↑ 3 ; follow-up: ↓ 6 Changed 11 years ago by Malte
Thanks for the info on integer and float based calculations in the various browsers, good to know.
Replying to jri:
Replying to Malte:
dm4-box-renderer-dom: in chromium long topic labels are not wrapped correctly.
In firefox there is no such issue, the box wraps the label correctly.
From my perspective it looks like: long labels which contain no spaces do not line wrap, regardless of browser.
Yes, in this case the label exceeds the blue topic box.
With dm4-box-renderer-dom topic label line wrapping relies on the browser rendering engine. So, what should we do?
Should we consider overflow=hidden?
And, no, I do not think so. We should leave that up to the browser rendering engine for now since hidden is not really an option, I think.
comment:6 in reply to: ↑ 5 Changed 11 years ago by jri
Replying to Malte:
Replying to jri:
With dm4-box-renderer-dom topic label line wrapping relies on the browser rendering engine. So, what should we do?
Should we consider overflow=hidden?
And, no, I do not think so. We should leave that up to the browser rendering engine for now since hidden is not really an option, I think.
I agree!
comment:7 Changed 11 years ago by Jörg Richter
- Status changed from new to closed
- Resolution set to fixed
long label dm4-box-renderer-dom in chromium