[CSS3] Border width rounding clarification #2114
Comments
|
This sub-pixel problem is not restricted to border widths. Sadly there is no perfect way to solve it. |
|
I know not only border, but one way must be defined. I use definition of 1px for size of font of 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.) |
|
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. |
|
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. |
|
The Working Group just discussed 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. |
|
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
added
the
Closed as Question Answered
There is needed clarification in CSS specification due to rounding values in border-width.
Please test IE. FF and chrome for values:
Which browser has correct behaviour for pixel-ratio=1 and zoom=1.0?
shall antialiasing be or not?
The difference is pretty visible.
The text was updated successfully, but these errors were encountered: