If so, would it make sense to put them in the display struct?
I don't know, because I don't really know the style system very well, so I don't know what design hurts least. We can assume that the default values for the column properties will apply to 99.99% of frames.
A more relevant question is what fraction of frames we'll have to look up the column properties at all. If it's just blocks, it probably makes sense to have a separate struct. If it's for pretty much all frames, it's probably better to just use the display struct.
Sounds like we want a separate struct, if I understand the setup correctly.
Either. People could configure it out, and we could avoid affecting the trunk at all while the support is developed. Personally I'd rather not have #ifdefs but maybe not everyone wants to deal with it.
I think letting people configure it out once it's done is a rather bad idea (fragmentation of a "Gecko" layout engine means, etc). At best, we can provide pref hooks to disable it (though that could probably be done with ua.css anyway).
As for affecting the trunk, I think in alpha it's not unreasonable to do so. Also, I'd rather have bits landing as we end up with them instead of the whole thing getting turned on at once -- that way if there are problems of some sort they may show up earlier and be more debuggable...
-Boris _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
