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

Updates limitations #420

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Updates limitations #420

wants to merge 1 commit into from

Conversation

BoDonkey
Copy link
Contributor

@BoDonkey BoDonkey commented Jan 9, 2025

Summary

Summarize the changes briefly, including which issue/ticket this resolves. If it closes an existing Github issue, include "Closes #[issue number]"
This PR updates the breakpoint preview section of the documentation to correct inaccuracies about the limitations. Updates the spike section of PRO-6932, opening it for plugin modification.

What are the specific steps to test this change?

For example:

  1. Run the website and log in as an admin
  2. Open a piece manager modal and select several pieces
  3. Click the "Archive" button on the top left of the manager and confirm that it should proceed
  4. Check that all pieces have been archived properly

What kind of change does this PR introduce?

(Check at least one)

  • Bug fix
  • New feature
  • Refactor
  • Documentation
  • Build-related changes
  • Other

Make sure the PR fulfills these requirements:

  • It includes a) the existing issue ID being resolved, b) a convincing reason for adding this feature, or c) a clear description of the bug it resolves
  • The changelog is updated
  • Related documentation has been updated
  • Related tests have been updated

If adding a new feature without an already open issue, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

@BoDonkey BoDonkey requested a review from haroun January 9, 2025 11:18
Copy link
Member

@boutell boutell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only change I am requesting is that we explicitly say why min-width: >= ... doesn't make sense and should not be used in any case.


- Example of problematic query:
```css
@media (min-width >= 600px) { ... }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is accurate documentation, I know.

In terms of the feature... is it just silly? I get it, min-width is already a ">=" situation, it's bizarre to add an explicit ">="...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it is just silly isn't it. I think it would be good for us to explicitly say "adding >= to min-width doesn't make sense because it is already a greater-than-or-equal comparison, so we don't support it."

| Complex logical conditions | ⚠️ Partial / Unreliable |
| Viewport-relative units | ⚠️ Not container-aware |
| User preference queries | ❌ Unsupported (e.g., dark mode) |
| `orientation` | ❌ Unsupported |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like orientation and aspect-ratio are still candidates to be supported at some point, per my ticket, but this is a good documentation update.

| User preference queries | ❌ Unsupported (e.g., dark mode) |
| `orientation` | ❌ Unsupported |
| `aspect-ratio` | ❌ Unsupported |
| Size descriptors with `>=` or `<=` | ⚠️ Not recommended |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| Size descriptors with `>=` or `<=` | ⚠️ Not recommended |
| Size descriptors with `>`, `<`, `>=` or `<=` | ⚠️ Not recommended |

#### 2. Operator and Descriptor Limitations
Some combinations of size-related descriptors and operators may not work reliably:

When `min-width`, `max-width`, `min-height`, or `max-height` are used with `>=` or `<=` operators.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When `min-width`, `max-width`, `min-height`, or `max-height` are used with `>=` or `<=` operators.
When `min-width`, `max-width`, `min-height`, or `max-height` are used with `>`, `<`, `>=` or `<=` operators.

| Complex logical conditions | ⚠️ Partial / Unreliable |
| Viewport-relative units | ⚠️ Not container-aware |
| User preference queries | ❌ Unsupported (e.g., dark mode) |
| `orientation` | ❌ Unsupported |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All unsupported query feature can be implemented using the transform method by the project owner.

transform will receive the media query and is supposed to return the new value for breakpoint preview.

In a nutshell, if this is not supported by the modules, you can still implement this yourself using the transform option.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You make a really good point. I totally forgot about transform. That should be documented (or at least mentioned).

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

Successfully merging this pull request may close these issues.

3 participants