Limited styling options

[raphaelbernhart]

Hi,

I am thinking about using this module in production but for this to work for me IMO the options for styling are very limited.

Please correct me if I'm wrong but aren't the only options to change the styling:

1. The colors in the nuxt config
2. classes in the component directly (f.e. via deep modifier)

But then the questions comes to me, why don't all the children in the component have a class. ATM it is really difficult to style certain elements in the component tree. image.
Would probably also be nice to be able to add custom classes. This would be useful f.e. when using tailwindcss.

FYI: I am open to create a PR, I just want to make sure that I am on the same page as everyone else :)

• Maybe a feature to collapse the Cookie groups? When there are a lot of cookies IMO it gets really hard for the user to keep track. This probably only makes sense once the feature in this issue is implemented? As now, for a workaround you can just "group" the cookies inside of the functional and optional cookies groups. image

[dargmuesli]

Yes, I definitely long for a tailwindcss implementation as well, just haven't found the time for that. Also, subcomponents seem to make sense to me too! It might help with feature requests like this one too: #196

[raphaelbernhart]

Sorry what do you mean with subcomponents? The collapse feature?

[dargmuesli]

Right now there is mainly only the CookieControl component, e.g.

That component's template could be more modularized, e.g. to have a CookieControlElement subcomponent for more flexible layout options:

:

[raphaelbernhart]

Right now there is mainly only the CookieControl component, e.g.

That component's template could be more modularized, e.g. to have a CookieControlElement subcomponent for more flexible layout options: :

Ah ok yeah. Tho IMO those are two separat features. I'll have a look in the upcoming days :)

[dargmuesli]

why don't all the children in the component have a class

I just want to mention that you should of course be able to access DOM children of components with classes via the usual CSS syntax like .cookieControl__ModalContent input:checked+button

[raphaelbernhart]

@dargmuesli As there are probably more things, can we continue the discussion here instead of the issue (#229)?

So there are probably these things:

1. Re-structure the component (using sub-components)
2. Config to be capable to add custom styling (preferably also tailwindcss)
3. add disable-scroll feature (maybe with use of headlessui)

Reg. "1." - I think we could change the structure (which we prob. will have to if we choose to use a component library) or we try to get "closest to original". This would definitely help with compatibility issues.

Reg. "2." - I think the easiest way would be to add a "styles" (?) config prop where you can update the styles of the elements of the cookie control? Do you agree/have other ideas?

Reg. "3." - If we decide to not use a third-party I think we only have to keep in mind that iOS has some caveats + we should not use body-scroll-lock as it seems to be abandoned (maybe use https://ishadeed.com/article/prevent-scroll-chaining-overscroll-behavior/?)

[dargmuesli]

I think the easiest way would be to add a "styles" (?) config prop where you can update the styles of the elements of the cookie control? Do you agree/have other ideas?

I'd just want the styles to not end up inline (except if Nuxt is configured to do that by downstream users), everything else is fine for me. Maybe also check how https://ui.nuxt.com/ offers configuration. I think they make use of the appconfig, which we could or should do too maybe?

add disable-scroll feature (maybe with use of headlessui)

The point of headlessui is more the headless part instead of the ui as I understand it. So it helps with all the accessibility stuff and maybe also the usual stuff like scroll locking that doesn't need to be reinvented for each project or library, which could very much help here.

[raphaelbernhart]

The point of headlessui is more the headless part instead of the ui as I understand it.

True but tho when exchanging, even if only the modal, we would inevitably have a different structure.
Anyways, I'll give it a shot and see how it turns out.