18:10 <@hyatt> suddenly it won't.
18:11 <@bz> hyatt: | | |
18:11 <@bz> | |
18:11 <@hyatt> now you're getting into overconstrained tables
18:12 <@bz> | |
18:12 <@hyatt> tables suck
18:12 <@bz> hyatt: yeah, true
18:12 <@hyatt> what sucks about them is that you have to match WinIE or you're "buggy"
18:12 <@bz> hyatt: but in 90% of the cases I've seen out there tables are in fact overconstrained, and incorrectly
18:12 <@bz> yep
18:12 <@hyatt> even though nearly every table on the web is ambiguous
18:12 * bz agrees with hyatt
18:13 <@bz> let's not start on heights of table cells that have colspans...
18:13 < sicking> hyatt: btw, how much effort would it take to map between kthmls element-names (which are just an int iirc) and mozillas atom+namespaceid?
18:13 * sicking ponders what he is actually asking
18:13 <@hyatt> why does that matter, sicking?
18:14 < sicking> hyatt: well.. i've been somewhat looking at porting transformiix to khtml, and the biggest obstacle is (soon) that transformiix uses atoms
18:14 < jkeiser> hyatt: this sounds very much like the css rule for auto width rather than a max element width problem ... basically it says that if you have a percentage width child and the parent is auto, your width becomes auto too
18:15 <@hyatt> only that isn't what happens.
18:15 <@hyatt> there are two types of maxwidths
18:15 < jkeiser> when I just tried it (maybe my browser is bad) then | 's suddenly shrunk to auto size
18:15 <@hyatt> there's maxwidths where percentage cells affect the maxwidth (scaled via a multiplier of their intrinsic max width by the percent)
18:15 < jkeiser> when I wrapped the thing in a table
18:15 <@hyatt> and maxwidths where they don't.
18:16 < jkeiser> hmm
18:16 <@hyatt> ok, maybe that is right
18:16 <@hyatt> to call it "auto"
18:16 <@hyatt> hmmm.
18:16 <@hyatt> explain that rule to me again.
18:16 <@hyatt> maybe i can simplify my code.
18:16 < sicking> heh
18:17 < jkeiser> let me find the rule, 1s
18:17 <@hyatt> it's sitll not auto though
18:17 <@hyatt> the percents still affect teh widths of cells
18:18 <@hyatt> take the example i gave above
18:18 <@hyatt> and change the 50s to 100s
18:18 <@hyatt> and you'll see what i mean
18:18 <@hyatt> the overal lwidth of the nested table is the intrinsic max width of the three cells
18:18 <@hyatt> but the first cell gets all teh space!
18:18 <@hyatt> because of its 100%
18:18 <@hyatt> so even though you computed the width of the table as though the percents weren't there
18:18 <@hyatt> the actual layout had to lay out as though they were
18:19 < jkeiser> hyatt: they're the same in Mozilla (/me tests IE)
18:19 <@bz> Phear
18:19 <@bz> Phear the tables
18:19 < jkeiser> hyatt: 50%'s and 100%'s are the same in Mozilla and IE--they are "auto" (shrink to fit)
18:19 < jkeiser> hyatt: at least when we wrap the whole thing in another table
18:20 < sicking> the question is, who do we blame for this mess? Microsoft or netscape?
18:20 < jhermans> and the users still expect the output to be exactly the same in all browsers ...
18:20 < sicking> who copied who?
18:20 <@hyatt> jkeiser:
18:20 <@hyatt> http://www.mozillazine.org/weblogs/hyatt/archives/tables.html/test.html
18:20 <@hyatt> check that out
18:21 <@bz> sicking: msft copied NS4
18:21 <@hyatt> in the second table.
18:21 <@hyatt> the small one.
18:21 <@hyatt> note how cell a is wider than cell c.
18:21 <@bz> sicking: but then we have pages on which ns4 crashes and msft does "something"
18:21 <@bz> sicking: fun? ;)
18:21 < sicking> bz: it must have been before that
18:21 <@bz> sicking: s/4/3/, maybe
18:21 <@bz> sicking: but table layout did not change much from 3 to 4
18:21 < sicking> bz: yeah, that sounds better
18:21 < sicking> bz: right, and havn't since :)
18:22 <@bz> um
18:22 <@bz> so..............
18:22 * bz looks at cvs blame for this crap
18:23 * jkeiser tries to figure out why hyatt's does that and his doesn't
18:23 <@hyatt> jkeiser: what versio nof mozilla you using?
18:23 <@hyatt> jkeiser: what do you see?
18:24 < jkeiser> hyatt: 1.4 ... yours has extra space in the first cell of the second table, but my testcase doesn't, and I haven't figured out the difference between them yet
18:25 <@bz> hmm
18:25 <@bz> does -moz-user-input inherit?
18:26 <@hyatt> jkeiser: you probably have width=100% on your outer table
18:26 <@hyatt> jkeiser: that would be a guess
18:27 < jkeiser> hyatt: nope. The problem was the space in yours. It only does this (in Mozilla) when the second cell takes up two lines.
18:28 <@hyatt> jkeiser: the width of that table is the intrinsic max width of the cells
18:28 <@hyatt> jkeiser: but the first cell will still get all the space
18:28 <@hyatt> jkeiser: try putting a bunch of text inside the second cell. it's pretty funny.
18:30 <@bz> s/nsAString/nsACString/
18:31 < jkeiser> hyatt: oh, I see. That is so freaking messed up.
18:31 <@hyatt> jkeiser: yup.
18:32 < jkeiser> hyatt: but why don't a and c get equal share in this again?
18:32 <@hyatt> jkeiser: you only have 100% of space as far as tables are concerned
18:32 <@hyatt> you go from left to right, and once you run out of percents, you're done
18:32 <@hyatt> so the first cell gets 100/100
18:32 < jkeiser> hyatt: oh, I grok. It doesn't redistribute percentages evenly
18:32 <@hyatt> now you have 0/100 percent remaining
18:33 * hyatt thinks it would have made more sense to normalize
18:33 <@hyatt> but oh well
18:33 <@hyatt> GO NETSCAPE 1.1
18:33 <@hyatt> rofl
18:37 < jkeiser> hyatt: ok, max element width of the | 's (and even of the ) appears to be calculated the same in all these cases though. It's just that the reflow isn't asking for 100% width--it's asking for desired size given the body's width. It's the that is asking for the max element width and using it, which is what it's supposed to do.
18:48 < jkeiser> hyatt: it's just that for , desired size can be bigger than max element size :) Maybe the desired size is the right place for the quirk:
18:48 < jkeiser> (1) take the max element width of all non-percent-width td's;
18:49 < jkeiser> (2) assign percentage width td's the proper widths to make them that percentage width in the finished table;
18:49 < jkeiser> (3) shrink everything properly to make the table fit into the desired size (this is where the first-person-gets-the-space rule occurs);
18:49 < jkeiser> (4) give all td's that desired size
18:49 * jkeiser suspects he just described the algorithm that css prescribes
19:01 * jkeiser wonders how a xul-based layout deals with inline frames
19:02 < jkeiser> no, display: inline
19:02 <@hyatt> jkeiser: inlines in KHTML have no min/max width
19:02 <@hyatt> jkeiser: inline flow elements don't.
19:02 < jkeiser> hyatt: what happens to get them to create multiple boxes? You ask them for desired size and they do what they need?
19:03 <@hyatt> jkeiser: those boxes are created during layout
19:03 * glazou_sickHome wants hyatt to finally implement the element
19:03 <@hyatt> computing the max width for a block with inline kids is pretty insanely complicated
19:03 <@hyatt> heh
19:04 <@hyatt> because of whitespace
19:04 <@hyatt> pre, nowrap, etc. and possible mixtures
19:04 < glazou_sickHome> hyatt: nice 1st of april blog entry btw
19:04 <@hyatt> thx
19:05 < jkeiser> hyatt: ohhh, the size calculations and layout steps are separate. I totally had overlooked that.
19:05 <@hyatt> yes.
19:05 < jkeiser> I still wonder how desired size gets calculated without at least a virtual layout step.
19:05 <@hyatt> not sure what you mean.
19:06 <@hyatt> text gets measured sure.
19:06 <@hyatt> it's like a vastly simplified layout
19:06 < jkeiser> yeah, you basically have to do the same measurement twice in cases where the final size turns out to be the same as desired size
19:06 <@hyatt> yes.
19:06 <@hyatt> you do more measuring
19:07 <@hyatt> note that KHTML doesn't compute min/max intrinsic heights
19:07 <@hyatt> just doest his for widths
19:07 <@hyatt> height is all done during layout
19:07 <@hyatt> since margin collapsing has to be done
19:07 <@hyatt> and that involves having to lay out because of floats
19:08 < jkeiser> hmm. I can see how you could optimize the multiple-measurement if you wanted though.
19:08 <@hyatt> yes.
19:08 < jkeiser> And it is quite simple.
19:08 * jkeiser is more converted
19:08 <@hyatt> it makes the table code especially eas yto understand
19:08 <@hyatt> since you can then cache min/max intrinsic widths for clumns
19:08 <@hyatt> columns
19:09 <@hyatt> some layout operations become very fast
19:09 <@hyatt> e.g., you just lay out columns at their max widths if possible
19:09 <@hyatt> well, it isn't so much faster as jus teasier to read i guess
19:09 < jkeiser> which is a huge plus :)
19:10 * hyatt remembers when evaughan kept arguing passionately with troy about this and getting nowhere
19:10 <@hyatt> and troy kept responding and removing me from the cc list
19:10 <@hyatt> because he wanted to complain at evaughan in private
19:10 <@hyatt> or something
19:10 <@hyatt> it was funny
19:10 < jkeiser> hahaha
19:10 <@hyatt> evaufghan kept putting me back on the ccc list
19:10 <@hyatt> lol
19:11 < jkeiser> hyatt: I don't think there's anyone left who would really passionately defend the current reflow system on its technical merits :)
19:12 <@hyatt> jkeiser: :)
19:12 <@hyatt> safari's layout is much less optimized and easily twice as fast as gecko's
19:12 <@hyatt> i still don't understand that
19:12 <@hyatt> (safari's style system is much slower though)
19:12 <@smfr> no xpcom overhead?
19:12 <@hyatt> (which i do understand)
19:12 <@hyatt> i can't believe it would just be xpcom
19:13 <@hyatt> no, i think it's just thet the layout system in gecko sucks
19:13 < sicking> speed though good arch is infinetly better then speed through optimization
19:13 <@hyatt> the actual Reflow stuff in Gecko and actual layout of objects is just not very well done i think
19:13 <@hyatt> (mostly because of early bad architectural decisions)
19:14 <@hyatt> it's like the only part of gecko that didn't get a rewrite of some kind. :)
19:14 <@hyatt> so the poor thing is old.
19:14 < jkeiser> and it's the part in the most need of one now :)
19:14 <@hyatt> and creaky.
19:14 < sicking> when code gets so complicated that you can't keep track of the whole thing you always end up wasting tons of cycles, which spirals to more complicated code
|
|