Removal of default css styles?

[st-h]

I would like to see... 🙋‍♀️🙋‍♂️

Removal of default css.

Why and how 💬

I noticed that the included default styles was causing issues when using this addon with my app. I tried to override the applied styles, but at least with safari (chrome was ok) this lead to different behaviour, than when the styles wouldn't be present at all. In order to solve this, I started to use a fork of this addon, which did not contain the css styles. I never had to accommodate for the removal of those styles. Do you think it would be possible to remove the styles at all?

[ijlee2]

Thanks for the suggestion. Since Node 10 support will be dropped soon, I think it is possible to make a major release, where we may also replace the resize modifier and remove the default stylesheet.

To clarify, I had added width: 100%; and height: 100% because I had thought this would allow the container to receive the correct available width and height from its parent element. I can imagine that this might not be what a developer always wants, and agree that it's easier to ask the developer to explicitly set width and height when needed, rather than to ask them to assume 100%.

Let me check what would happen if default stylesheet isn't present in the demo app and possibly a couple of other apps.

[ijlee2]

I took screenshots of what the demo app looks like with and without the default styles.

The album and dashboard pages don't turn out to be the same. The form page does, but likely because there isn't any other component rendered besides <Form>.

A. Album

With default styles

Without default styles:

B. Dashboard

With default styles

Without default styles

C. Form

With default styles

Without default styles

[ijlee2]

@st-h Can you provide me a demo app or a sample code, which replicates the issue that you had encountered with Safari? Could you also check if the issue is (still) happening on latest Safari?

If I understood you right, I think you might have tried overriding the default styles by writing,

.reset-default-styles {
  height: auto;
  width: auto;
}

<ContainerQuery class="reset-default-styles">
  ...
</ContainerQuery>

Is my assumption above correct?

[st-h]

@ijlee2 Yes, I am pretty sure that was what I was doing. It worked fine in Chrome and Firefox, but Safari was showing a different behaviour when setting it back to default values - quite weird behaviour. The only fix I could find, was to remove those styles, so I won't have to override them. It's been quite a while now since I added ember-container-query, so I don't have a demo app or sample code. The app I am working on is quite complex and at the moment not open source. I can give the current alpha version a try and see into what issues I'll run into, though.

[st-h]

Regarding the screen shots. Yes, where those styles are needed, they would need to be applied manually. My issue was that the default styles did not fit my use case, and I could not reset them by overriding because safari would show a different behaviour. This really sounds like a bug with Safari... but well.. what can we do about that? Those versions are already out there...

[st-h]

@ijlee2 sorry about the late reply. lots of work at the moment. I tried out the 2.0.0-alpha.0 and here is a screenshoot of the issues I am still observing with safari:

Here is the 2.0.0-alpha.0. I am overriding the container query styles as you recommended. However, this leads to a height that exceeds the parent container.

This is the exact same code, I only replaced container query with my fork that does not include the default styles.

This is my fork without the styles to override height and width (same result):

The only solution I could find to fix this, was to remove the default styles from container-query. I've also tried to use unset instead of auto for width and height, but the results are the same.

The parent element has display: flex btw. In a case like this it does not make any sense at all to try to set the width and the height to 100%, because a smaller height than the parent container is intended. Therefore I still think it would be better to remove the default styles and manually add them where appropriate instead of assuming a specific situation and provide styles that only support that specific case.

[ijlee2]

@st-h No worries, thank you for providing screenshots. I'll try to find time on Sunday/Monday to look at the issue closely.

[st-h]

Hi @ijlee2. Did you possibly find some time to look into removing the default css styles? I am still using a fork of this addon, because I run into unfixable layout issues when the default styles are applied that are shipped with ember-container-query.

[ijlee2]

Hi, @st-h. I'm much sorry for a late response. I wanted to take time to figure out a change that is non-breaking and doesn't expand the API unnecessarily (e.g. allow passing a Boolean as an argument to disable the default styles).

In v2.1.1, the addon exports a modifier called {{container-query}}. I believe, with the modifier approach, we can handle the case of not applying the default styles.

Here's a sample code, where the modifier is applied to an HTML element:

<div
  local-class="container"
  {{container-query
    features=(hash
      wide=(cq-width min=600)
    )
  }}
>
  Hello world!
</div>

.container {
  border: 1px solid orange;
}

.container[data-container-query-wide] {
  border: 1px solid steelblue;
}

One could also create a component to enable reusing code. What do you think?

[ijlee2]

To recap: Starting v2.1.1, end-developers can use the {{container-query}} modifier, to opt out of the <ContainerQuery> component. I'll mark the issue as fixed.

[st-h]

Thank you. Actually, I am currently working on a redesign. Surprisingly I could override all the styles when necessary without any issues. Today I finally checked if this might be related to a fix in Safari, however it turned out that the issue still exists. Seems to be a pretty weird edge case. Yet, I think the option to use a modifier when needed will work fine. I am glad I no longer need to maintain a fork 😊

[ijlee2]

@st-h Thank you for the update!