You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wondering, if this wouldn't be a very convenient and nice solution to various issues regarding reusable patterns/components and atomic design principles, which many of us use when developing larger applications.
My motivation for bringing something like this up is, that the media features, that exist for the picture/source and img element are pretty useless in those cases. I would always have to add script-hacks to achieve what i want. Adding a custom element for each purpose and adding container-support to each of those is also a pain and does not feel right. In my opinion this issues needs to be solved generically.
Lets imagine you write a "card" component, that displays text besides an image. But on small screens the image should be above. This can be solved with media queries very easily. But when it comes to nested layouts, where you dont know how much of the viewport is available to you, you need to use another solution. So there are container queries, which can solve this on a css level. But it is not possible to solve the problem of the image-tag needing to specify the correct src-attribute for its currently valid variant. I could only solve this with redundant markup, which is obviously not nice.
Here is a thought experiment, which illustrates, what i mean.
The benefit in a solution like this would be huge and it would be independent from css while still be able to cooperate with additional container-queries. You could specify different html attribute values for each container size you want to support. Custom-Elements and Patterns you provide, would be extremely straight-forward by adding style-rules given on attributes. The distinctive syntax (@) would be an easy way to provide patches for browsers, that dont support the feature yet.
This might be complete nonsense in your eyes but in my opinion this could be worth thinking about.
The text was updated successfully, but these errors were encountered:
I was wondering, if this wouldn't be a very convenient and nice solution to various issues regarding reusable patterns/components and atomic design principles, which many of us use when developing larger applications.
My motivation for bringing something like this up is, that the media features, that exist for the picture/source and img element are pretty useless in those cases. I would always have to add script-hacks to achieve what i want. Adding a custom element for each purpose and adding container-support to each of those is also a pain and does not feel right. In my opinion this issues needs to be solved generically.
Lets imagine you write a "card" component, that displays text besides an image. But on small screens the image should be above. This can be solved with media queries very easily. But when it comes to nested layouts, where you dont know how much of the viewport is available to you, you need to use another solution. So there are container queries, which can solve this on a css level. But it is not possible to solve the problem of the image-tag needing to specify the correct src-attribute for its currently valid variant. I could only solve this with redundant markup, which is obviously not nice.
Here is a thought experiment, which illustrates, what i mean.
The benefit in a solution like this would be huge and it would be independent from css while still be able to cooperate with additional container-queries. You could specify different html attribute values for each container size you want to support. Custom-Elements and Patterns you provide, would be extremely straight-forward by adding style-rules given on attributes. The distinctive syntax (@) would be an easy way to provide patches for browsers, that dont support the feature yet.
This might be complete nonsense in your eyes but in my opinion this could be worth thinking about.
The text was updated successfully, but these errors were encountered: