Version: 4.2.91 (KDE 4.2.91 (KDE 4.3 >= 20090609)) (using 4.3.69 (KDE 4.3.69 (KDE 4.4 >= 20090923)), compiled sources) Compiler: gcc OS: Linux (i686) release 2.6.27.13-tmb-desktop-1mdv Testcase: <div style="display:table; width: 500px; padding:6px; max-width: 10px; border: 5px solid red;"> a </div> (Reported on #khtml with actual use) RenderTable::calcMinMaxWidth simply doesn't care about these.
Created attachment 37960 [details] First try w/lots of debug info This works in simpler cases, but fails in one of the two on target page. The problem case there is that the maxWidth computed by the table layout algorithm is /smaller/ than the CSS maxWidth, and the RenderTable::calcWidth chunk doesn't ignore it.
The use in the wild: https://bugs.launchpad.net/moin-solenoid/+bug/464156
2 testcases from CSS 2.1 test suite: The 'max-width' property applies to elements with 'display' set to 'table'. http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/max-width-applies-to-013.htm and The 'min-width' property applies to elements with 'display' set to 'table'. http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/min-width-applies-to-013.htm Konqueror 4.4.2 fails both tests; Konqueror 4.4.2 shows a vertical thin black line and not a 1 inch wide by 1 inch tall filled black square. Firefox 3.5.8 passes both tests while Opera 10.10 passes only the min-width-applies-to-013.htm test. regards, Gérard
Issue 240 http://wiki.csswg.org/spec/css2.1#issue-240 Summary Behavior of min/max width on table elements. URL http://lists.w3.org/Archives/Public/www-style/2010Oct/0817.html Proposal Make undefined Resolution Proposal accepted to make effect of min/max-width/height undefined on table elements to which they apply. Status Closed. http://wiki.csswg.org/spec/css2.1#issue-240 So now, the final version of CSS 2.1, section 10.4 Minimum and maximum widths: 'min-width' and 'max-width', now states " In CSS 2.1, the effect of 'min-width' and 'max-width' on tables, inline tables, table cells, table columns, and column groups is undefined. " http://www.w3.org/TR/CSS21/visudet.html#min-max-widths So, this bug report should now be resolved as INVALID or as WORKSFORME. regards, Gérard
Resolving as WORKSFORME since the spec clearly indicate that the layout is undefined (meaning any rendered layout is conformant) in such cases.
Ok but in this case Konqueror is treating "width: 100%" differently from all the other browsers mentioned in the downstream bug of comment 2 which has originated this report: https://bugs.launchpad.net/moin-solenoid/+bug/464156. You can debug this with the following websites for example: http://moin.larpwiki.de https://www.cirrus-rs.de I think a new bug regarding this could be created if possible. When most popular, standard-following-famed browsers behave in a way and some specific in another, it's likely there's a bug. For example, in my project I specific CSS only for IE (worst: for specific versions), and I would sincerely to not add Konqueror in this salad, *if* there's a bug with it rather than with the CSS 2.1 specification. I mean, I'm not sure how this conclusion came up but it sounds odd, like browsers need a consensus or we web developers need to understand how to achieve what we want correctly, because relying on a standard-undefined property sounds just wrong, as well as having this property available for table elements in the spec at all.
> Ok but in this case Konqueror is treating "width: 100%" differently from all > the other browsers mentioned in the downstream bug of comment 2 which has > originated this report: https://bugs.launchpad.net/moin-solenoid/+bug/464156. Renato, This is the first time I read "treating 'width: 100%' differently" ... and I don't even know onto which element this declaration applies. Over at bugs.launchpad.net/moin-solenoid/+bug/464156, I read "Konqueror ignores the max-width setting for ul.gotobar, ul#pagetrail { display: table }" in comment #1. Then I see is a screenshot in comment #4. It's a start but it's far, very far from complete. > You can debug this with the following websites for example: > http://moin.larpwiki.de > https://www.cirrus-rs.de Yes. I see the layout issue at those sites. It would have been helpful to mention those sites in this bug report to begin with. > I think a new bug regarding this could be created if possible. It may be ok to *create* a new bug report but, in itself and of itself, it does not do much. Creating a bug report is only the beginning of a process. And a bug report needs to begin a lot of information which can be verified, confirmed. > When most > popular, standard-following-famed browsers behave in a way and some specific in > another, it's likely there's a bug. Often, yes. But not always and not necessarly. By itself, a difference of layout is only a motive to investigate the code to check if there is a spec violation or an incorrect implementation. > For example, in my project Renato, 1- Are you the author of those (moin.larpwiki.de , cirrus-rs.de ) websites? 2- Can you create a *_reduced_* testcase from moin.larpwiki.de or cirrus-rs.de demonstrating the layout issue? > I specific CSS only for IE (worst: for specific > versions), and I would sincerely to not add Konqueror in this salad, *if* > there's a bug with it rather than with the CSS 2.1 specification. I mean, I'm > not sure how this conclusion came up but it sounds odd, like browsers need a > consensus or we web developers need to understand how to achieve what we want > correctly, because relying on a standard-undefined property sounds just wrong, > as well as having this property available for table elements in the spec at > all. I read what you wrote and this is not useful or helpful right now but I understand what you mean. Renato, I can help up to a certain point; you must try to be helpful and patient. Read Investigating Konqueror Bugs http://www.konqueror.org/investigatebug/ Try to create a *_reduced_* testcase out of http://moin.larpwiki.de or out of https://www.cirrus-rs.de which would still show the layout issue in Konqueror. I recommend you do not create a bug report right now. We first need to create a *reduced*, *minimized* testcase out of moin.larpwiki.de or cirrus-rs.de . regards, Gérard
(In reply to comment #7) > This is the first time I read "treating 'width: 100%' differently" ... and I > don't even know onto which element this declaration applies. It's because max-width is used in the selectors mentioned in 1st comment from the downstream bug, for giving a limit to this very 100% width also used in them (as well as display: table, of course). I used firebug and I coudn't see which element 100% relates to in the elements affected by these selectors, it simply doesn't match any outer element's border/padding/margin/etc. Hence max-width works in most common browsers as kind of delimiter to this "crazy" behavior or width: 100%. > Often, yes. But not always and not necessarly. By itself, a difference of > layout is only a motive to investigate the code to check if there is a spec > violation or an incorrect implementation. Indeed, I wish Konqueror the best as well. > 1- Are you the author of those (moin.larpwiki.de , cirrus-rs.de ) websites? No, I'm the author of the theme used by the wiki engine they run. > I read what you wrote and this is not useful or helpful right now but I > understand what you mean. I mean it could be bad CSS code, but the fact that most browsers deal ok with it makes it less likely than something wrong with Konqueror. > Renato, I can help up to a certain point; you must try to be helpful and > patient. I'm sorry if I pass a wrong impression, I don't really care that much, I'm just trying to avoid an workaround which is already implemented: http://bazaar.launchpad.net/~renatosilva/moin-solenoid/konqueror-fixes/revision/152. About the testcase you're right, there were one but it doesn't serve anymore. I won't create a new bug report. I have no conditions at the moment to really dig into this and show you a reduced testcase so we could create or find a related report. As I said, I'm not trying to fix something mine, but rather based on the other browsers I'm just telling that it *seems* there's something wrong with Konqueror. Maybe someone in the wild gets interested in this and contribute with the testcase and even a patch, as Maksim Orlovich did.
Sorry for the duplicate comments, I was hanging on for too long so stopped and tried again. Thanks in advance if some admin can delete this and previous duplicated comment.
Sorry for my typos as well.
> About the testcase you're right, there were one but it doesn't serve anymore. I > won't create a new bug report. I have no conditions at the moment to really dig > into this and show you a reduced testcase so we could create or find a related > report. Renato, I'll try to create a reduced testcase and examine the issue later. I'll let you know if I create a bug report. regards, Gérard
Renato, Semi-reduced testcase out of cirrus-rs.de: http://www.gtalbot.org/BrowserBugsSection/Konqueror4Bugs/semi-reduced-testcase-cirrus.html If Konqueror 4.7.4 decides to ignore line 26: max-width: 320px; like the spec allows it to do [1], then the rendered layout by Konqueror 4.7.4 of such semi-reduced testcase out of cirrus-rs.de is compliant with the spec. What other browsers do (Firefox 9.0.1, Opera 11.60, Chrome 16.0.912.75) is (and would be and must be considered also) compliant. I need to examine more the issue and explore a few things when I'm rested. Max-width applied on table testcase [2] has been identified as an incorrect and wrong test submitted to the test suite[3] and also been identified as incorrect and wrong test in the CSS Test Suite Manager "Shepherd" system. [1] "In CSS 2.1, the effect of 'min-width' and 'max-width' on tables, inline tables, table cells, table columns, and column groups is undefined. " CSS 2.1, section 10.4 Minimum and maximum widths: 'min-width' and 'max-width' http://www.w3.org/TR/CSS21/visudet.html#min-max-widths [2] http://test.csswg.org/suites/css2.1/20110323/html4/max-width-applies-to-013.htm [3] http://wiki.csswg.org/test/css2.1/issues#incorrect-rc6-testcases and also into CSS Test Suite Manager "Shepherd" system. regards, Gérard
Hi Gérard and all, (In reply to comment #8) > I used firebug and I coudn't see which element 100% relates to in the > elements affected by these selectors, it simply doesn't match any outer > element's border/padding/margin/etc. Hence max-width works in most common > browsers as kind of delimiter to this "crazy" behavior *of width: 100%. Please disregard this comment, I just noticed another max-width which was causing this "crazy" 100% width. When removed, it looked just fine, aligned with the page box. (In reply to comment #13) I just find it odd how these properties are allowed by the spec for these table elements at all. Stating that the behavior is undefined just left browsers lost about what to do, leading to different behaviors even though all compliant! It just sounds like a bug in the spec to me (as well as in the official compliance tests).
Not sure if this helps but I just found out I have introduced max-width as sort of delimiter after having problems with pixel-fixed width in Chrome 4 and Safari 4: http://bazaar.launchpad.net/~renatosilva/moin-solenoid/trunk/revision/40.1.2 http://bazaar.launchpad.net/~renatosilva/moin-solenoid/trunk/revision/40.2.2
(In reply to comment #15) > Not sure if this helps but I just found out I have introduced max-width as sort > of delimiter after having problems with pixel-fixed width in Chrome 4 and > Safari 4: > > http://bazaar.launchpad.net/~renatosilva/moin-solenoid/trunk/revision/40.1.2 > http://bazaar.launchpad.net/~renatosilva/moin-solenoid/trunk/revision/40.2.2 Still needed in Safari 5.1.2.
And Chrome 16.0.912.75 m.
> (In reply to comment #13) > > I just find it odd how these properties are allowed by the spec for these table > elements at all. Stating that the behavior is undefined just left browsers lost > about what to do, leading to different behaviors even though all compliant! There are many constraints (2 border-collapse models, 2 table-layout models, 2 applicable semantic models) that apply on table elements and sub-table elements (rows, cells, columns, caption elements) for properties like width and height. So, the decision to make max-width (and min-width, max-height, min-height) undefined was more or less predictable, unavoidable. As for the stylesheets involved, I saw no necessary reasons to use 'max-width' and no reason to use 'display: table' either. The rules of the solenoid stylesheets are often over-excessively coded, with redundant declarations; many rules are over-defined, over-declared, even when they don't apply at all. They also over-declare containers, wrappers. Closing and marking as VERIFIED WORKSFORME Gérard
> As for the stylesheets involved, I saw no necessary reasons to use > 'max-width' and no reason to use 'display: table' either. The reason for max-width is what I have said in comments 15-17. It was a side effect crossbrowsing issue I faced while trying to fix the bugs below. Just checked and 'display: table' was straightforward code for them: https://bugs.launchpad.net/moin-solenoid/+bug/449933 https://bugs.launchpad.net/moin-solenoid/+bug/449938 > The rules of the solenoid stylesheets are often over-excessively coded, with > redundant declarations; many rules are over-defined, over-declared, even when > they don't apply at all. They also over-declare containers, wrappers. Much of the code was inherited from another project rather than being planned from scratch. Also, my CSS changes were extremely focused on the user experience being stable among browsers, even if I maybe had to somewhat "sacrifice" the code, rather than doing deep research in CSS and specs *and lots of different browser behaviors*. A clear example is IE, for which I doubt I could *ever* talk to developers for fixing their odd behaviors compared to other browsers, not to say it is known as a buggy browser at all. Therefore I ended up creating stylesheets focused for IE 7 and IE 8. I used to try a common solution for avoid workarounds the most, but didn't let it stop me making things work. I achieve it in the side effect problems I mentioned, creating fixes for Chrome and Safari without browser-specific CSS. I just tried to do the same for Konqueror, but ended up creating browser-specific code for it. It could be avoided by not fixing Chrome and Safari, but I'd have two browser communities to face. In sum, part of the code was inherited and I didn't feel like rewriting it. Also my focus is the user experience even making code look workaround-like. I'm not arguing in favor of the theme's code, just making a few points. I wish the code was clear but neither it's my focus nor I have time for that. Anyway, thanks for your attention, I don't really care that much as I said, because I have a fix for this in the project, I just tried to collaborate for less crossbrowsing trouble in the world :) Regards.