In the monolith we inherit this property from a CSS reset, but we cannot
count on that being present in every application using this library, so
also setting this property explicitly.
The table loading styles require the paddings that are removed for the
general table case. That's okay: the table loading styles do not support
putting custom content in cells, and so the option of setting custom
paddings for content will not be missed.
The previous removal of default table cell padding makes the default
alignment in content look weird. Adding a vertical alignment property
fixes this.
We previously removed the default padding because it did not play nice
with designs requiring less padding. Does the addition of vertical
alignment create a similar problem? I'd argue now. Padding cannot be
easily countered. Vertical alignment can easily be countered by
embedding div's in the cells with custom styling.
We've run into a situation in CCS where the default padding added to
cells are to large. Considering it is much harder to remove a padding
from the outside then it is to add one, this commit removes the default
cell padding for tables.
This way you're not limited to creating tables with fixed-width columns.
This also makes the table take up the maximum available width space by
default.
The table styles are currently depending on some browser styles. If
those are disabled (for instance using a reset.css file), then tables do
not look correct. This makes explicit styles that are currently coming
from the browser.
We make a suite that checks the behavior of both versions.
Assuming they have the same API, this should work.
If we add another version and it changes the API,
we might want to rethink this approach.
There are places where we need the select to be as wide as possible.
Since it seems like a sensible default to have all the selects expand,
we take that approach.
If we find out that this is harder, we can release use the old version.