Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding CSS classes to thead, tfoot and tbody #492

Open
buschtoens opened this issue Oct 11, 2017 · 2 comments
Open

Adding CSS classes to thead, tfoot and tbody #492

buschtoens opened this issue Oct 11, 2017 · 2 comments

Comments

@buschtoens
Copy link
Collaborator

@fran-worley #99 (comment):

Sorry to bump an old issue but I believe this only partially resolves issues marrying up Bootstraps css styles with ember-light-table.

We need to be able to apply styles directly to the 'thead' too ('.thead-default' is just one style example from BS v4). Could the api be harmonized to allow you to add classes directly to table elements (table, thead, tbody etc.).

As a user, I would expect that setting class on {{t.head}}, {{t.body}} and {{t.foot}} set these classes on the rendered <thead>, <tbody> and <tfoot> elements.

I'm not sure, if we can use class as the attribute name here, since it's a magic Component keyword that automatically sets the class HTML attribute for the rendered component element.

@fran-worley
Copy link
Contributor

fran-worley commented Oct 11, 2017

@buschtoens provided we can come up with a consistent API for adding class names to table elements it wouldn't matter if the method name was different to class.

I think it would be better to choose a new property name as the hacks involved to use class are likely to be messy and some people might wish to apply a class to the ember element wrapper (e.g. to hide it or something similar).

tClass or tableElementClass might work as a name and could replace the tableClassNames property added for #99 as I believe the API should be harmonious across all table elements.

@kboucher
Copy link

tClass or tableElementClass might work as a name and could replace the tableClassNames property added for #99 as I believe the API should be harmonious across all table elements.

Is there any reason not to follow the naming convention adopted with the addition of the tableClassNames property and simply add support for theadClassNames, tbodyClassNames, and tfootClassNames?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants