Version: (using KDE KDE 3.4.0) Installed from: I Don't Know Testcase URL: http://www.dougweb.org/wp/?page_id=121 Basically if I specify a width of 99.999%, Konquerer treats it as 99.00000%. This bug is also present in Safari (xref: http://bugzilla.opendarwin.org/show_bug.cgi?id=5164)
Dupe of this http://bugs.kde.org/show_bug.cgi?id=89738 ?
That bug was very specific - absolute widths, between 0% and 1%. I've found issues with numbers > 1%, and the bug seems to manifest itself whenever percentages are involved - widths/heights, font sizes, floated boxes, not just absolute boxes with 0% < width <1% etc. I would say bug 89738 is a specific manifestion of this much more general problem within the code. Related yes. Dupe no.
*** Bug 89738 has been marked as a duplicate of this bug. ***
*** Bug 76465 has been marked as a duplicate of this bug. ***
Another illustration of the existence of this bug: http://www.ualberta.ca/~sjm11/khtmlbug.html
*** Bug 121710 has been marked as a duplicate of this bug. ***
Confirmed for KDE 3.5.4.
Confirmed in KDE 3.5.9
Confirmed on trunk r800081.
Created attachment 24489 [details] testcase I attached the external testcase so it doesn't get lost.
Can anybody comment on the technical aspects of what has prevented a fix for this bug for over 2.5 years?
I loaded attachment 24489 [details] in Konqueror 4.4.3 and the <div style="width: 50.9%;float: left;clear:both;height: 60px;background-color: cyan;">I am 50.9% wide in a box 1000px wide, so I should be 509px wide. (...)</div> is actually 508px as reported by Konqueror DOM treeviewer's computed style for that element. That may/could be in fact the result of a smart strategy (to play it safe) when confronted with fractional percentage. The 8 colored "12.5% Menu Item" left-floated blocks are each and all exactly 125px. "At the very least, they should play it ’safe’, and draw 8×125px boxes.": this is what is being done too in Konqueror 4.4.3, Qt 4.6.2, Linux 2.6.31-19-generic i686 (32bits) here. regards, Gérard
> Can anybody comment on the technical aspects I can comment on the technical aspects of fractional percentages and fractional pixels from a CSS 2.1 point of view. There is NO rule, NO guideline and NO procedure to follow and to apply provided by CSS 2.1 specification when confronted with fractional percentages and fractional pixels. User agents are free to truncate, round up or round down fractional values, and this, at the beginning, during (intermediary values) and at the end of computing rendered values. Over at CSS 2.1 test suite ( http://lists.w3.org/Archives/Public/public-css-testsuite/ ), we have encountered this situation very often (in at least in 250 testcases) and I can assure you with a 100% certainty that a testcase with values like 'width: 50.9%;' would make the testcase rejected->need-rework. CSS 3 is supposed to deal with, tackle with this issue. I submit that this bug report should be resolved as INVALID regards, Gérard
Hi Gérard, > There is NO rule, NO guideline and NO procedure to > follow and to apply provided by CSS 2.1 specification > I submit that this bug report should be resolved as INVALID Just because the spec doesn't say what should happen, that doesn't mean that nothing should be done. It's a matter of "quality of implementation". You might also take into account things like how other browsers perform, what behaviour seems to be expected by websites, etc. (BTW, I submitted the bug that was duped to this over five years ago. I obviously gave up waiting for a fix a long long time ago! So if you aren't going to fix it I won't complain if it's closed as "WONTFIX". Just please don't tell me my report was wrong, which is what "INVALID" seems to imply.)
> Just because the spec doesn't say what should happen, I clearly and explicitly referred to the CSS 2.1 spec in my comment. Again, this issue is supposed to be addressed by CSS 3. > that doesn't mean that > nothing should be done. As a web developer, I would stay far away - from fractional pixels - from fractional percentages - from pixel-perfect webpage rigid design for many reasons. Web authors should avoid fractional pixels and fractional percentages: why a web author would need a level of layout accuracy of 1 tenth of a pixel or 1 per thousand of a containing block used dimension(s) is beyond my understanding. On top of the reasons already mentioned, there is NO consensus among browser manufacturers on how to deal with fractional pixels and fractional percentages. > It's a matter of "quality of implementation". You do not understand. There is no normative information, no guideline, no recommendation in current CSS 2.1 specification for fractional pixels and fractional percentages. So, anything is ok and good: truncation, rounding up and rounding down can be arbitrarily applied to any property with fractional pixels or fractional percentages, *_even with and including intermediary computations_*. And this is what happens too: it varies greatly from property name to property name and from browser, even browser version. > You > might also take into account things like how other browsers perform, what > behaviour seems to be expected by websites, etc. Browser software and algorithms should never be expected to guess what the web author or websites originally wanted, intended. > (BTW, I submitted the bug that was duped to this over five years ago. I > obviously gave up waiting for a fix a long long time ago! So if you aren't > going to fix it I won't complain if it's closed as "WONTFIX". Just please > don't tell me my report was wrong, which is what "INVALID" seems to imply.) INVALID is the correct resolution here. The CSS 2.1 spec gives no normative information, no guideline, no recommendation, no specifics on how to render/deal with fractional pixels, fractional percentages: so the current behavior is compliant with the spec and so the testcase and bug report originally make invalid assumptions about expected results. Once a CSS 3 units module covers, addresses and specifies this issue, then it may make this bug a valid one... assuming that the actual results in comment #12 are specified/compliant. Gérard Talbot
> why a web author would need a level of layout > accuracy of ... 1 per thousand of a containing block ... > is beyond my understanding Consider dividing something into three equal columns. If they are rounded to 33% the total width would be 99%, which could cause an edge to be mis-positioned by a few pixels relative to adjacent content, leaving an unsightly "jag". In the case that I reported 5 years ago, I was laying out elements on a family tree diagram that was potentially much larger than the screen, and elements that were supposed to line up didn't. > there is NO consensus among browser manufacturers on how to deal with > fractional pixels and fractional percentages. My observation 5 years ago was that Mozilla and IE did what I expected. >> It's a matter of "quality of implementation". > You do not understand. There is no normative information, no guideline, > no recommendation in current CSS 2.1 specification for fractional pixels > and fractional percentages. So, anything is ok and good I believe I do understand what you are saying, but perhaps you don't understand what I mean by "quality of implementation". QoI means that, precisely in this case where "anything is OK and good" by the specification, you go beyond what the spec requires to provide something that is "good" by some other useful measure (like making your users happy). For example, specs rarely say anything much about speed, yet we strive to make code perform reasonably well.
On Monday 03 January 2011 14:00:36 Gérard Talbot wrote: > https://bugs.kde.org/show_bug.cgi?id=113630 > > > > > > --- Comment #15 from Gérard Talbot <browserbugs gtalbot org> 2011-01-03 > 21:00:17 --- > > > Just because the spec doesn't say what should happen, > > I clearly and explicitly referred to the CSS 2.1 spec in my comment. Again, > this issue is supposed to be addressed by CSS 3. > > > that doesn't mean that > > nothing should be done. > > As a web developer, I would stay far away > - from fractional pixels > - from fractional percentages > - from pixel-perfect webpage rigid design > for many reasons. Web authors should avoid fractional pixels and fractional > percentages: why a web author would need a level of layout accuracy of 1 > tenth of a pixel or 1 per thousand of a containing block used dimension(s) > is beyond my understanding. I have an operation in a business where x/y steps for a particular process are complete. This is a manual operation where an employee will log each item, and there are y items. I also have a web page that shows the progress of these various logged operations. The progress also has a nice little bar graph so a general status can be ascertained quickly without looking at the individual numbers. The web page is made to be functional on various devices, such as smart phones, so I don't have a set width for the nice little bar graph. As such, there are almost always going to be fractions (x/y of the operation that is being logged, and bar width vs width of web page). Is it very important to have the exact width of the graph? No. Do I depend on fractional widths? No. I agree that is not wise from a web- dev point of view. Do I want khtml to be CSS compliant? Absolutely Yes. If fractional widths are not explicitly referred to by CSS 2.x, but other reputable browsers handle them, then do I want khtml to offer feature parity? Absolutely Yes. If nothing is lost by working with fractional widths, and it is worthwhile, then why call it INVALID? INVALID is NOT the correct resolution here, exactly b/c the CSS2.1 spect gives no normative information, no guideline, no recommendation, no specifics on how to render/deal with fractional pixels, fractional percentages. Rendering fractional widths as some other reputable browsers do would not leave khtml any less CSS 2.1 compliant, b/c the spec does not indicate that any particular course of action is right or wrong. A spec shall say what compliance entails. If a spec does not cover some topic, then no implementation surrounding that topic can be said to be in compliance *or* in violation of the spec. > On top of the reasons already mentioned, there > is NO consensus among browser manufacturers on how to deal with fractional > pixels and fractional percentages. > > > It's a matter of "quality of implementation". > > You do not understand. There is no normative information, no guideline, no > recommendation in current CSS 2.1 specification for fractional pixels and > fractional percentages. So, anything is ok and good: truncation, rounding > up and rounding down can be arbitrarily applied to any property with > fractional pixels or fractional percentages, *_even with and including > intermediary computations_*. And this is what happens too: it varies > greatly from property name to property name and from browser, even browser > version. > > > You > > might also take into account things like how other browsers perform, what > > behaviour seems to be expected by websites, etc. > > Browser software and algorithms should never be expected to guess what the > web author or websites originally wanted, intended. > > > (BTW, I submitted the bug that was duped to this over five years ago. I > > obviously gave up waiting for a fix a long long time ago! So if you > > aren't going to fix it I won't complain if it's closed as "WONTFIX". > > Just please don't tell me my report was wrong, which is what "INVALID" > > seems to imply.) > > INVALID is the correct resolution here. The CSS 2.1 spec gives no normative > information, no guideline, no recommendation, no specifics on how to > render/deal with fractional pixels, fractional percentages: so the current > behavior is compliant with the spec and so the testcase and bug report > originally make invalid assumptions about expected results. Once a CSS 3 > units module covers, addresses and specifies this issue, then it may make > this bug a valid one... assuming that the actual results in comment #12 > are > specified/compliant. > > Gérard Talbot
> Consider dividing something into three equal columns. How about considering *all* of the issue here. Not just width as a property but font-size, height, line-height, border-spacing, margin, padding, border, word-spacing, letter-spacing, vertical-align, etc. What is supposed to happen when the specified length is a real number or a real percentage? What is supposed to happen when the *used* length is a fractional pixel? a fractional percentage? Round up? Round down? Truncate? When? When specified or when computed or with used value? For intermediary computations too (eg. width: 6ex;)? > If they are rounded to > 33% This bug report subject description states that "Non-integer percentages are incorrectly rounded down". So, it is suggesting that 33.3% should be rounded up to 34%. This bug report has no formal steps to reproduce, no accurate description, no complete description, no quote of the spec, only 1 testcase (attachment 24489 [details]). > the total width would be 99%, which could cause an edge to be > mis-positioned by a few pixels relative to adjacent content, leaving an > unsightly "jag". In which situation? You do not specify this. In automatic table layout? In fixed table layout? Width when applied to table column defines the *minimum* width, not the used width: this in what the CSS 2.1 spec says today and 5 years ago http://www.w3.org/TR/CSS21/tables.html#columns How big, detrimental is such gap and jag? Does it break page layout and, if so, why? Are you over-constraining the table dimensions and, with it, your page layout (a very frequent issue on the web)? Are you using valid (markup and CSS) code? Your attachment 7566 [details] resorts to absolute positioning (and has nothing to do with table and columns) and it triggers in backward-compatible "quirks" rendering mode in which we know that anything you do is outside the spec. Your attachment 7566 [details] does not trigger web standards compliant rendering mode. If you really want this issue to be tackled seriously, then you would have to create a complete proposal at W3C-style mailing list with *_formal thorough normative specifications_* on all this so that Microsoft, Mozilla, Apple, Google, Opera and KDE would follow and comply with such specifications. { CSS does not define an "optimal" layout for tables since, in many cases, what is optimal is a matter of taste. CSS does define constraints that user agents must respect when laying out a table. User agents may use any algorithm they wish to do so (...) If the table is wider than the columns, the extra space should be distributed over the columns. } http://www.w3.org/TR/CSS21/tables.html#columns http://www.w3.org/TR/2005/WD-CSS21-20050613/tables.html#width-layout (5 years ago) but, as you can read, it does not define how and where the extra space should be distributed: it could be in the first column or the last column and in any other column. So, right here, it's not even possible to create a testcase. > In the case that I reported 5 years ago, I was laying out elements on a family > tree diagram that was potentially much larger than the screen, and elements > that were supposed to line up didn't. > > > there is NO consensus among browser manufacturers on how to deal with > > fractional pixels and fractional percentages. > > My observation 5 years ago was that Mozilla and IE did what I expected. No given url, no formal spec, no testable situation, no comparable layout, no given browser versions (build number), etc... 5 years ago, Internet Explorer 6 was the official stable and latest web navigator of Microsoft and there is now a very wide consensus that such browser had tons of bugs and flaws, even including its table model and had a bugward mode ('hasLayout', MS-Front-Page-incestual-compliance, etc). > > >> It's a matter of "quality of implementation". > > > You do not understand. There is no normative information, no guideline, > > no recommendation in current CSS 2.1 specification for fractional pixels > > and fractional percentages. So, anything is ok and good > > I believe I do understand what you are saying, but perhaps you don't understand > what I mean by "quality of implementation". QoI means that, precisely in this > case where "anything is OK and good" by the specification, you go beyond what > the spec requires to provide something that is "good" by some other useful > measure (like making your users happy). When a webpage situation has not been specified by normative information in the specification, then there is no "good" or "bad" layout, no "reasonable". It's undefined. And anything is "good". And it's even a "matter of taste". You refer to "quality", "good", "reasonable", "well" words but you have no idea how difficult underlying back-end code redesign can be on top of everything else. > For example, specs rarely say anything > much about speed CSS 2.1 is about presentation, layout, style. >, yet we strive to make code perform reasonably well. What you evaluate as reasonable may turn to be unreasonable, wrong, incorrect to anyone else, especially if the spec provides no guideline, no recommendation, no normative information, no formal rules when dealing with fractional pixels|percentages. As I said before, every single testcase (over 250 testcases) at CSS 2.1 test suite which involved fractional pixels or fractional percentages has been rejected->need-rework, redesign. Gérard Talbot
I'll just say that generally width: 50.999% isn't handled as width: 50%. Heck, you can see it in the testcase in comment #10 --- as was pointed out before, you get 508px and not 509px. Heck, I'll be precise: it's stored as 50 and 115/128 percents; and reasonably recent KHTML handles fractional width specifications, but box widths and positions are always integrals (which they should be if you don't want a slow blurry mess, though having intermediate values be non-integral makes some sense and is likely what Gecko is doing).
On Monday 03 January 2011 16:47:53 Gérard Talbot wrote: > https://bugs.kde.org/show_bug.cgi?id=113630 > > > > > > --- Comment #18 from Gérard Talbot <browserbugs gtalbot org> 2011-01-03 > 23:47:51 --- > > > Consider dividing something into three equal columns. > > How about considering *all* of the issue here. Not just width as a property > but font-size, height, line-height, border-spacing, margin, padding, > border, word-spacing, letter-spacing, vertical-align, etc. What is > supposed to happen when the specified length is a real number or a real > percentage? What is supposed to happen when the *used* length is a > fractional pixel? a fractional percentage? Round up? Round down? Truncate? > When? When specified or when computed or with used value? For intermediary > computations too (eg. width: 6ex;)? Yes, formidable challenges indeed. To write the spec to cover those details is surely complex. In spite of those challenges, a number of reputable (and current) browsers will handle 50.9% width just fine (and not simply round it to 50 or 51). The point being made here is not to define what the spec should say. Rather that in the vacuum created by no spec covering this detail we'd like to see the fractional case handled like the other browsers. In this case there is no right or wrong (spec doesn't say what to do), so INVALID is not appropriate.
(In reply to comment #17) > Do I want khtml to be CSS compliant? Absolutely Yes. Right now, I estimate that KHTML (Konqueror 4.5.4) fails about 12% to 15% of all 9633 testcases at CSS 2.1 test suite (RC4). And again, I am repeating in this bug report that every single testcase involving fractional pixel and fractional percentage (even including full integer ex unit) have been rejected and then recoded/redesigned by testcase submitters of/from browser manufacturers. Konqueror 4.5.4 crashes in some testcases (involving dynamic javascript :first-letter). Konqueror 4.5.4 hangs (infinite reflow: causing %tage CPU activity to remain high) in 6 testcases. I even list them in my website. > If fractional widths are not explicitly referred to by CSS 2.x, but other > reputable browsers handle them Firefox 4.0 beta 8, Firefox 3.6.x, IE 8, IE 9 Platform Preview 5 (beta 1), IE 9 Platform Preview 7, Chrome 8.0.552.224, Safari 5.0.x, Opera 11.0 and Konqueror 4.5.4 all handle fractional pixels and fractional percentages. But they do not handle these the same way, under the same circumstances, consistently. But they do not handle these the same way for all properties. But they do not handle these the same way for all properties and for specified values, computed values, intermediary computations, and used values. When replying to me, in your own quoted message, I already said that: { > > On top of the reasons already mentioned, there > > is NO consensus among browser manufacturers on how to deal with fractional > > pixels and fractional percentages. > > it varies > > greatly from property name to property name and from browser, even browser > > version. } >, then do I want khtml to offer feature parity? > Absolutely Yes. You are suggesting that there is a de facto browser manufacturer consensus and standard in dealing with fractional pixel and fractional percentages. I am telling you that there is NO browser manufacturer consensus and NO standard in dealing with fractional pixel and fractional percentages. It varies a lot! > If nothing is lost by working with fractional widths, and it is worthwhile, > then why call it INVALID? I already explained this. > INVALID is NOT the correct resolution here, exactly b/c the CSS2.1 spect gives > no normative information, no guideline, no recommendation, no specifics on how > to render/deal with fractional pixels, fractional percentages. Rendering > fractional widths as some other reputable browsers Please explicit what are those other reputable browsers: versions, build numbers and, of course, a precise thorough description of what they do with a list of precise testcases. > do would not leave khtml > any less CSS 2.1 compliant, b/c the spec does not indicate that any particular > course of action is right or wrong. > A spec shall say what compliance entails. If a spec does not cover some > topic, then no implementation surrounding that topic can be said to be in > compliance *or* in violation of the spec. Please read this: "Non-integer percentages are incorrectly rounded down." Where does it say in the CSS 2.1 spec that non-integer percentages should be rounded up? Where does it say in the CSS 2.1 spec that non-integer percentages can NOT and should NOT be rounded down? If the CSS 2.1 spec does not cover how non-integer percentages are to be rounded - if they are rounded (up or down) or not -, then why do you think this bug is a valid CSS 2.1 bug? This bug report makes the assumption that "Non-integer percentages are incorrectly rounded down" but the spec does not in any way support or make such assumption. When non-integer percentages are rounded down, then such handling is not in violation of the spec because the spec does not define how to deal with non-integer percentages. Again, some browsers do round up for some properties in some situations: it's not a violation of the spec. It is undefined in the spec: so, whatever a browser does is fine, ok, reasonable, good, whatever here. But stating or claiming that such handling (or any truncation|round up|round down handling) is incorrect, is making an invalid assumption. Gérard Talbot > > On top of the reasons already mentioned, there > > is NO consensus among browser manufacturers on how to deal with fractional > > pixels and fractional percentages. > > > > > It's a matter of "quality of implementation". > > > > You do not understand. There is no normative information, no guideline, no > > recommendation in current CSS 2.1 specification for fractional pixels and > > fractional percentages. So, anything is ok and good: truncation, rounding > > up and rounding down can be arbitrarily applied to any property with > > fractional pixels or fractional percentages, *_even with and including > > intermediary computations_*. And this is what happens too: it varies > > greatly from property name to property name and from browser, even browser > > version. > > > > > You > > > might also take into account things like how other browsers perform, what > > > behaviour seems to be expected by websites, etc. > > > > Browser software and algorithms should never be expected to guess what the > > web author or websites originally wanted, intended. > > > > > (BTW, I submitted the bug that was duped to this over five years ago. I > > > obviously gave up waiting for a fix a long long time ago! So if you > > > aren't going to fix it I won't complain if it's closed as "WONTFIX". > > > Just please don't tell me my report was wrong, which is what "INVALID" > > > seems to imply.) > > > > INVALID is the correct resolution here. The CSS 2.1 spec gives no normative > > information, no guideline, no recommendation, no specifics on how to > > render/deal with fractional pixels, fractional percentages: so the current > > behavior is compliant with the spec and so the testcase and bug report > > originally make invalid assumptions about expected results. Once a CSS 3 > > units module covers, addresses and specifies this issue, then it may make > > this bug a valid one... assuming that the actual results in comment #12 > > are > > specified/compliant. > > > > Gérard Talbot
FWIW, by "incorrectly rounded down" I didn't mean that they should be rounded up, I meant that in the specific testcase I created, that they're rounded *at all* - 50.9% of 1000 is an integer. I don't really have a problem with output being rounded to the nearest pixel if the browser can't handle sub-pixel positioning - but basic rules of accuracy taught to all schoolchildren say that you should round your output, not your inputs. The "early rounding" behaviour might be allowed per spec, but it doesn't match simple user expectation.
(In reply to comment #20) > we'd like to see the > fractional case handled like the other browsers. There is no de facto industry consensus among other browsers like IE8, Firefox 3.6.x, Chrome 7+, Opera 10+. Regardless of properties. Regardless of specified values, computed values, used values or intermediary computations (eg 6ex). > In this case there is no right or wrong (spec doesn't say what to do), so > INVALID is not appropriate. Read again this bug report summary: "Non-integer percentages are incorrectly rounded down" Therefore, according to you, rounding down of non-integer percentages is neither right and is neither wrong. But the summary of this bug report states loud and clear that it is wrong. Gérard Talbot
(In reply to comment #19) > I'll just say that generally width: 50.999% isn't handled as width: 50%. Heck, > you can see it in the testcase in comment #10 --- as was pointed out before, > you get 508px and not 509px. Heck, I'll be precise: it's stored as 50 and > 115/128 percents; and reasonably recent KHTML handles fractional width > specifications, but box widths and positions are always integrals (which they > should be if you don't want a slow blurry mess, though having intermediate > values be non-integral makes some sense and is likely what Gecko is doing). I believe at the time I filed this 5 years ago, 50% is exactly what it was handled as - i.e. my 8 boxes of 12.5% were drawn 12% wide - i.e. the difference was a lot more than a single pixel. It would appear then, that the behaviour has changed in the last 5 years from truncation to "best effort". So it's definitely improved.
On Monday 03 January 2011 17:29:27 Gérard Talbot wrote: > https://bugs.kde.org/show_bug.cgi?id=113630 > > > > > > --- Comment #21 from Gérard Talbot <browserbugs gtalbot org> 2011-01-04 > 00:29:26 --- (In reply to comment #17) > Firefox 4.0 beta 8, Firefox 3.6.x, IE 8, IE 9 Platform Preview 5 (beta 1), > IE 9 Platform Preview 7, Chrome 8.0.552.224, Safari 5.0.x, Opera 11.0 and > Konqueror 4.5.4 all handle fractional pixels and fractional percentages. Ah, I'm using KDE SC 4.4.x. I'm really only commenting here on matter of principle, anyway... > But they do not handle these the same way, under the same circumstances, > consistently. But they do not handle these the same way for all > properties. But they do not handle these the same way for all properties > and for specified values, computed values, intermediary computations, and > used values. Of course, I would expect there to be variances, especially in the absence of a defined spec. > >, then do I want khtml to offer feature parity? > > > > Absolutely Yes. > > You are suggesting that there is a de facto browser manufacturer consensus > and standard in dealing with fractional pixel and fractional percentages. > I am telling you that there is NO browser manufacturer consensus and NO > standard in dealing with fractional pixel and fractional percentages. It > varies a lot! You are right, I should not have used the word parity for the reasons you mentioned. You are obviously very knowledgeable in the area of browser workings, implementation of CSS specs, etc. If it is not clear, I am no more than a consumer of web browsers. I am not trying to have an in depth conversation about how khtml should handle these things on detailed level. Doug Wright said it very well in Comment #22, and that is my point of view as well. [snip] > Please read this: "Non-integer percentages are incorrectly rounded down." > Where does it say in the CSS 2.1 spec that non-integer percentages should > be rounded up? > Where does it say in the CSS 2.1 spec that non-integer percentages can NOT > and should NOT be rounded down? > > If the CSS 2.1 spec does not cover how non-integer percentages are to be > rounded - if they are rounded (up or down) or not -, then why do you think > this bug is a valid CSS 2.1 bug? This bug report makes the assumption that > "Non-integer percentages are incorrectly rounded down" but the spec does > not in any way support or make such assumption. > > When non-integer percentages are rounded down, then such handling is not in > violation of the spec because the spec does not define how to deal with > non-integer percentages. > > Again, some browsers do round up for some properties in some situations: > it's not a violation of the spec. It is undefined in the spec: so, > whatever a browser does is fine, ok, reasonable, good, whatever here. But > stating or > claiming that such handling (or any truncation|round up|round > down handling) is incorrect, is making an invalid assumption. okay. fine. so calling the behavior "incorrect" is "invalid" in the absence of a "valid." So it is not precisely correct to say "...incorrectly rounded down" b/c there is no "correct" from the point of view of the CSS 2.x spec. To say the bug report is INVALID for this lack of precision is to miss the point of the bug report, in my opinion. I think the point of this bug report is to give a little more effort to handle the "50.9% of 1000" type cases. To accomplish this there are a number of choices that could be made (I'm not suggesting any particular number, or any particular method, only that more than one exists, if I understand correctly). Many, if not all of which are valid and fine, as you stated above. Perhaps this is accomplished in KDE SC 4.5.x, I don't know. But a point here is that to call this report invalid is to say that khtml thinks that treating 99.9 as simply 99 is a perfectly reasonable thing to do (not arguing right or wrong here). The people who are voting for this bug are suggesting that khtml can do better in this area, as we have generally seen through the behavior of other browsers. > > Gérard Talbot By the way, I can tell you care a lot about getting it right, and I appreciate that. thanks...
Hi Gérard, I could write a rebuttal to your comment #18, but I'm not certain that it would be useful to do so; you don't seem to be on the same planet as me! Can I just suggest that you remember the saying, "don't shoot the messenger"? I filed the bug that was duped to this as a service to your project to help you make your software better, and the project's response has been to ignore it for 5 years, and then to basically tell me that I'm an idiot. This is not the right way to make friends. I'm going to unsubscribe from this bug now; it's clear nothing productive is going to come of it. Regards, Phil.
What is the state of this bug now with Konqueror 4.8.4?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!