Closed
Bug 206631
Opened 22 years ago
Closed 16 years ago
border-width based on text size should always be the same in pixelworth
Categories
(Core :: Layout: Block and Inline, defect, P3)
Core
Layout: Block and Inline
Tracking
()
RESOLVED
DUPLICATE
of bug 287624
People
(Reporter: hakon_, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(3 files, 1 obsolete file)
518 bytes,
text/html
|
Details | |
15.93 KB,
image/png
|
Details | |
1.70 KB,
patch
|
crazy-daniel
:
review+
crazy-daniel
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030509
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030509
When using relative units to set a border-width, like 'border-width: 0.1em' it
seems that the conversion from em to px is done more than once, resulting in
different border-widths sometimes. Have a look at the sample page.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Expected Results:
The converted pixel-value corresponding to a relative value should be locked so
that it's always the same no matter how many times or where it is used.
Comment 2•22 years ago
|
||
->layout B&I
Assignee: dbaron → block-and-inline
Component: Style System → Layout: Block & Inline
Keywords: testcase
Comment 3•21 years ago
|
||
> it seems that the conversion from em to px is done more than once
It's done once, but the result is a fractional number of pixels. We lay out
using those fractional numbers, but then your monitor is not capable of
displaying sub-pixel-width lines, and rounding occurs....
When rendering to a device capable of sub-pixel display (eg a printer), this is
a non-issue.
Blocks: 134942
Depends on: 287624
Comment 4•19 years ago
|
||
(In reply to comment #3)
> When rendering to a device capable of sub-pixel display (eg a printer), this is
> a non-issue.
I would generally agree. But would it be possible than to make such a screenshot?
I took on on a CRT and one on a TFT, although that doesn't matter. It might matters that these 2 were taken on different graphic cards.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060531 Minefield/3.0a1
Comment 5•17 years ago
|
||
This WFM on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2
The borders are equally sized starting with Firefox 3.0
The reference uses pixel values, is that reliable in this case?
Attachment #357402 -
Flags: superreview?(dbaron)
Attachment #357402 -
Flags: review?(dbaron)
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Comment on attachment 357402 [details] [diff] [review]
reftest
You should:
* specify the font-size on body, since the default can vary
* drop the test in 'ex', since that can vary depending on what the default font is
With those changes, r+sr=dbaron.
Attachment #357402 -
Flags: superreview?(dbaron)
Attachment #357402 -
Flags: superreview-
Attachment #357402 -
Flags: review?(dbaron)
Attachment #357402 -
Flags: review-
(In reply to comment #8)
> (From update of attachment 357402 [details] [diff] [review])
> You should:
> * specify the font-size on body, since the default can vary
Done. I used 16px as that's the browser default.
> * drop the test in 'ex', since that can vary depending on what the default
> font is
Done.
The "new" test still fails in Fx2 and passes in Fx3+.
> With those changes, r+sr=dbaron.
Attachment #357402 -
Attachment is obsolete: true
Attachment #357441 -
Flags: superreview+
Attachment #357441 -
Flags: review+
Flags: in-testsuite?
Keywords: checkin-needed
Pushed the test:
http://hg.mozilla.org/mozilla-central/rev/723ea3c0719f
You need to log in
before you can comment on or make changes to this bug.
Description
•