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

Feature request: re-com sans class #51

Open
timgilbert opened this issue Aug 5, 2015 · 4 comments
Open

Feature request: re-com sans class #51

timgilbert opened this issue Aug 5, 2015 · 4 comments

Comments

@timgilbert
Copy link

Hi, thanks for re-com, it is really useful and it's a great ready-made component library for re-frame.

I have a feature request: it would be nice to be able to pass in a property to the various re-com components which would cause them not to emit any style or class tags, so that they'd be a little easier to plug into a site which already had an existing CSS framework. I'm specifically thinking of the text-input component - I'd like to use some of its behavioral properties without having to untangle the intersection of the re-com CSS and the CSS library I've already got on the site I'm working on (to wit, materializecss, which you'd think would be a good match but for some reason getting the spacing and whatnot correct is a little painful).

I think re-com's default should still be to include class tags in its emitted hiccup which correspond to its bundled CSS, I just want an escape hatch available (if I'm reading the docs and code correctly, currently I can add CSS classes but I can't remove them), at least in components where it makes sense. I wouldn't necessarily expect more complex components like the date-picker to have this, but it would be nice for stuff like the input-text and input-textarea components.

@mike-thompson-day8
Copy link
Contributor

Hmm. So I can see what you are after.

So the goal here would be:

  • to be able to supply a :style or :class AND
  • indicate that this style/class should not be merged with the standard styles/classes and, instead, should be taken as the complete style/class in its own right?

In fact, sometimes, just supply a :class and NOT even supply a :style but have the standard :style ignored. And visa versa.

@timgilbert
Copy link
Author

Yes, that's precisely it. Maybe the parameter could be named :override-style or :override-class? As a degenerate case, supplying an empty string as the parameter should cause no :style or :class attribute (respectively) to be emitted at all.

I recognize I'm working in kind of an edge case here, so I don't have any problem specifying both :override-class "" and :override-style "" if I need to drop the style and class stuff altogether (as opposed to needing some funky logic where an empty :override-style implies an empty :override-class or the other way around).

@vvvvalvalval
Copy link

Maybe a better design would have been to name the initial parameter :add-classes, not :class; same thing for styles. But of course this would be a breaking change.

@Gregg8 Gregg8 added the styling label Nov 24, 2016
@cmal
Copy link

cmal commented Dec 2, 2016

Has this feature been implemented?
Also, is it possible to specify an :id to element?

@superstructor superstructor added this to the 2.12.0 milestone Jan 19, 2021
@superstructor superstructor removed this from the 2.12.0 milestone Apr 8, 2021
@BnMcGn BnMcGn mentioned this issue Dec 13, 2022
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

7 participants