Closed pzuraq closed 6 years ago
Hello @pzuraq, I'm migrating to ember-table's new api and have some styling-issues. Should we define @addepar/style-toolbox as dependency? I noticed, that some important style-defs are at _core.scss, but _core.scss is not available if ember-table is used as addon. Maybe you can clarify the things.
thank you
@addepar/style-toolbox
is our in-progress style framework. It’s tailored specifically to Addepar, and changing pretty frequently at the moment, so it may not be the best to rely on. If you like the look of the styles for the table, feel free to use them.
In general, Ember Table only includes the absolute minimum styles that are required for it to work. This allows you to add whatever styles you like. You can use our style framework as an example, but develop your own if you like. We cannot guarantee that our style framework will have the same semver guarantees as Ember Table, so this is probably the best approach.
@pzuraq thank you for the clarification :)
Beta 1 has been launched!
This issue is for tracking progress towards the first beta of 2.0.0
Goals
Feature parity with Ember Table 1 usage at Addepar
This includes many features not in Ember Table 1 that have been added internally such as tree data structure support, subcolumns, and sorting
Configurable and customizable at any level
Ember Table 1 encouraged users to extend its component/view classes to add simple features like class names, customized templates, event handlers, etc. Ember Table 2 should not require any extension to handle these things, it should be possible to customize them via the template and public APIs.
Accessible
Ember Table 1 was no accessible at all. We plan to have a base level of accesibility for the initial beta release, and to build on it in the future.
Features
<table>
tag, etc)~Tasks
position: sticky
for fixing headers/footers~The target API for beta.1 is outlined in #505: