Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CSS3] Border width rounding clarification #2114

Closed
Nadya678 opened this issue Dec 17, 2017 · 6 comments
Closed

[CSS3] Border width rounding clarification #2114

Nadya678 opened this issue Dec 17, 2017 · 6 comments
Assignees
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. css-backgrounds-4 css-values-5

Comments

@Nadya678
Copy link

There is needed clarification in CSS specification due to rounding values in border-width.
Please test IE. FF and chrome for values:

border:0.3px solid #000;

border:0.7px solid #000;

border1.3px solid #000;

border1.5px solid #000;

border:1.7px solid #000;

border:1.999px solid #000;

Which browser has correct behaviour for pixel-ratio=1 and zoom=1.0?

shall antialiasing be or not?

The difference is pretty visible.

@Loirooriol
Copy link
Contributor

This sub-pixel problem is not restricted to border widths. Sadly there is no perfect way to solve it.

@Nadya678
Copy link
Author

Nadya678 commented Dec 18, 2017

I know not only border, but one way must be defined. I use definition of 1px for size of font of <html/> tag and other elements in rems (and %s) Using media query I switch <html/> font-size to 0.75px or 0.5px to make the site responsible on very small screens (emulation of zoom, the zoom is not needed in CSS) but... The border 2rem converted to 1.5px looks differently in Cr and FF.

What are possible solutions of the problem? The problem with rounding border-width, margin, padding shall be resolved to show sites properly in Cr, IE and FF and shall be described in spec.

IT IS BIGGER PROBLEM than rounding 254.5 in colours. I see difference between 1 ans 2px border but I don't see difference between 255 and 254 in colours.

BTW. Small screen means 200, 300 CSS pixels not 414px (Samsung, iPhone etc.)

@fantasai
Copy link
Collaborator

fantasai commented Feb 3, 2018

The CSS specifications define the computation of “used values” -- the theoretical goal of the rendering. We don't discuss how to rasterize, though -- that's historically been out of scope and left to the UA. I'm not sure we want to do so now, and if we do I'm not sure which spec it would go into. But I can ask the WG what it wants to do.

@dbaron
Copy link
Member

dbaron commented Feb 6, 2018

And note that I think we've discussed in the past in the working group that some things (e.g., borders, column rules, line-heights, line grid sizes) should probably be handled differently from the rest, as in the message of mine that John Resig quoted. In particular, those should be snapped to device pixels at used value time (breaking the constraint that 4 * 25% matches 100%), before their use in layout, whereas we should otherwise do layout using subpixel sizes and snap edges at the end (breaking the constraint that every 25% size is the same).

I think there may even have been some implementation convergence towards this model over the past few years, although I'm not sure how interoperable things are.

@css-meeting-bot
Copy link
Member

The Working Group just discussed [CSS3] Border width rounding clarification.

The full IRC log of that discussion <dael> Topic: [CSS3] Border width rounding clarification
<dael> github: https://github.com//issues/2114
<dael> fantasai: My question was do we want to work o n this or leave it undefined. In the past we have left this kind of thing undefined.
<dael> dbaron: Prob good to define better then we do, but not fully. That requires careful work to do. It's work figuring out what the range of behaviors is and figure out if there's willingness to converge and then spec around that range.
<dael> astearns: So we need testing to see if there's something we could spec that's interop
<dael> franremy: It also depends on screen DPI which makes testing hard. It's always been tricky to get this right. We get from time to time reports we render differently but I am not confident it's easy toe xplain the exact behavior because every drawing path may be differnt. We need more testing yes.
<dbaron> I think it's also more about the layout effects than the drawing paths.
<dael> fantasai: Do we want to spend time o n this and if so who?
<dael> franremy: Eventually i might be able to but it's not a priority. We've been asked to investigate if we can be better interop. It's a stretch goal we could look. I'm fine assigning to me.
<dael> astearns: And I suggest franremy you can ask the person that opened the issue if they have tests or evidence of convergence. We can put it on them what hte solution should be.
<dael> franremy: Sounds like an awesome idea.
<dael> astearns: Good on this issue?
<dael> fantasai: Yes.

@tabatkins
Copy link
Member

Border widths (and outlines, and column-rules) are now interoperable between browsers, and well-specified to reflect that. Closing the issue as it should be a consistent answer now.

@tabatkins tabatkins added the Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. label Feb 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. css-backgrounds-4 css-values-5
Projects
None yet
Development

No branches or pull requests

7 participants