shaunc
widths
@BryanCrotaz In doc you have :
Note: When the width, min-width or max-width is specified in the column, this refers to the inner width of the column, not including padding and borders. A min-width specified in the css refers to the outer width and includes padding and borders.
It seems more natural to me that what you declare explicitly are the outer widths, as these are what the component needs to layout the grid. For instance rowHeight has to be the outer height of rows; once we get horizontal scrolling going we will also need to know the column widths. OTOH the user has complete control of what goes in the grid & how its styled.
Do we have a reliable method of reading widths and heights from css? If so we could write something like ("if you don't specify a width, ember-grid will use the width of an element styled in css as .ember-grid .cell; if you don't specify rowHeight ember grid will use height of element styled in css as .ember-grid .body .cell).
Do we have a reliable method of reading widths and heights from css
We can read the css as applied to an element (so the computed css in the chrome debugger) but can't read individual style definitions from the css file.
As I was writing that note I was having second thoughts about the design. My reason for going the way I did was that borders and padding are the "between columns" part.
Hmm. If you specify width in css then padding is inside that width and margin and border is outside it?
...and margin: 0 ? It seems like padding is ok but otherwise user should put something in the box that they can style rather than styling the box itself.
++ on box-sizing: border box.
It's becoming a standard to * { box-sizing: border-box; } when starting an app.
Paul Irish talks about it here.
The issue with that is then you would need to do extra calculation to work out the inner width, as the outer-width would come for free when setting style="width:{{width}}px" on the columns.
Is there any pros or cons either way? (With regards to inner or outer widths?)
@lcpriest -- thanks for the thought. After a successful test, we will probably be moving to use flexbox layout more extensively, which will hopefully eliminate the need for some of the calculations we currently make.
Although using box-sizing everywhere seems like a sound practice for an app, IMO as an addon project, we can't assume or require it of our users. A part of the vision of declarative components is to give the user as much control as possible over the various bits the declarative component wraps. So if the user wants to render header cells with content-box then we should be able live with that (though we could wrap that content in something that lays out using border-box, of course).