Add WeightedContentTrackSize

[erickok]

It would be useful to have a WeightedContentTrackSize (or whatever we end up calling it), which would size a track based on the weight it's contents have over the total intrinsic size of all columns.

This is how an HTML table would size itself (given no other constraints). This would solve Sub6Resources/flutter_html#491.

[shyndman]

Hi @erickok,

I think that what I'm working on for #16 will help a lot here. It's basically a rework/debugging of the entire layout algorithm. I'll keep you posted.

[shyndman]

(and not like last time...work is super light for me right now, so I'm full speed ahead 😉 )

[shyndman]

I'm not quite done yet, but here's how it's looking with your user's example data:

There's no need for a new track size, because this is how IntrinsicTrackSize is supposed to work (like an auto track in the CSS Layout Grid spec).

Video of resizing (debug build, so it's a little jumpy):
https://user-images.githubusercontent.com/42326/104787235-0a38c600-575d-11eb-892f-afc54a248225.mov

[erickok]

That's fantastic! Looking forward to it.

[shyndman]

Hey, so qq about what your user is encountering.

What TrackSizes are being used by your <table>s?

[erickok]

At the moment it's FixedTrackSizes for columns with a fixed defined width and FlexibleTrackSizes for the other rows (with either a value [0..1] if a 'fixed' percetage is defined, otherwise always value 1).

[shyndman]

Gotcha. Are you considering moving to a default of intrinsic?

[erickok]

Yes, absolutely, for the columns that do not define a fixed width in pixels or percentage.

[shyndman]

Percentage is an interesting one too, because FlexibleTrackSize isn't really the same thing. Flexible tracks only ever grow after everything else has been laid out.

Not sure how accurate you're trying to be with compatibility.

[erickok]

Not 100% sure on how html tables respond to this. In the end a 100% accuracy isn't our direct goal, but that would be nice of course. There are a lot of edge cases that you potentially have to cover to get close to a browser's behaviour, given colgroups, css,, html width, inconsistent given sizes, etc. Let's take it one step at a time. 🙂

[shyndman]

👍

[shyndman]

OK, got it. New sizing algorithm is working awesome.

I'm going to clean it up and write some tests tomorrow, then we're off to the races!