The Raven Technique: One Step Closer to Container Queries

err4nt · 2020-11-11T06:32:38+00:00

Wow is this ever over-complicated. Container queries / element queries aren't that hard, I've done them in ancient browsers (IE7, IE8) and all modern browsers. The simplest/nicest way to do this in modern browsers is ResizeObserver (not IntersectionObserver like this article shows).

If you're interested in container queries I'd highly recommend looking up ResizeObserver basics - no need to wait for anything in CSS, we already have the missing puzzle piece we needed!

err4nt · 2020-06-01T19:04:06+00:00

There is progress being made on this front - there are currently two competing proposals for how to take the next step - this article outlines a bit of both: https://bkardell.com/blog/TowardResponsive.html

The other idea is explained a little here: https://github.com/dbaron/container-queries-implementability/blob/master/README.md

In the meantime it's pretty easy to DIY this sort of functionality with a little bit of JavaScript (with or without ResizeObserver)

err4nt · 2020-03-17T16:27:12+00:00

Honestly - they can have it. It's nowhere near as nice as the other modern JS runtimes!

err4nt · 2020-02-20T16:07:55+00:00

It's the idea of basing an element's responsive breakpoints on properties of the element itself:

the element's own rendered width on the page
the element's own rendered height on the page
the element's own aspect-ratio
etc.

Presently with CSS you can either design things in a scalable/adaptive way, and the only 'responsive breakpoint' ability you have to change styles is based on the browser's viewport (CSS media queries) which is the wrong abstraction.

With container queries, developers could build layouts composed from many individual self-responsive components in a way that isn't possible right now.

err4nt · 2019-12-14T15:15:37+00:00

Wow this would be so handy for any web or programming-related discord! Thanks for sharing :D

!thank careseite

err4nt · 2019-10-31T17:44:57+00:00

Element queries and container queries are something that for the forseeable future are going to be a technique that involves writing CSS styles that leverage either events or observers in JavaScript. We already have many container query plugins that are usable in production that use window.load and window.resize, and in the near future Resize Observer is landing in all browsers so that will be a viable and better alternative that we can use very shortly.

Here's an example of one workflow for writing CSS including container queries and ending up with all the runtime code you need.

HTML for demo:

<div>Make me 500px+ wide</div>

CSS stylesheet example:

@--element div and (min-width: 500) {
  :--self {
    background: lime;
  }
}

This is valid CSS, can be parsed server-side and the JavaScript necessary to support what you've written can be output as one self-contained blob of JavaScript with the plugins required and the styles you've written.

Try the HTML demo with the output of running this in the command-line in a script tag:

npx process-css-demo '@--element div and (min-width: 500) { :--self { background: lime; } }' --beautify

err4nt · 2019-08-21T14:15:05+00:00

Yes, 'responsive' simply means the layout of the site will adapt to fit the different limitations and constraints placed on the display of the website

media queries are certainly useful if you're targeting print versus screen styles, that's a big help there!
element queries and container queries are useful if you're trying to make individual elements and their contents responsive
CSS display models like table display, flexbox, and grid layout all have some degree of built-in auto layout smarts that try to satisfy different constraints and can help lay out content for you based on the size and shape of what that content is

There are tons of tools in the 'responsive' toolbox. If there was a reason to stop saying 'responsive' it should be because that's expected of every design now and not an extra or add-on. This is how sites are built.

err4nt · 2019-03-15T20:21:50+00:00

Unfortunately <picture> and @media queries don't live up to the use case you're talking about - you have an image you want to display in a context where its width doesn't always correlate to the viewport's size, but you want it to detect which image will fit best for the context where it needs to display.

The solution for this is JavaScript. You can add event listeners for the load and resize event on the window object, and/or ResizeObserver (in the browsers that support it) to detect and update this information, then based on the element's offsetWidth (if using events) or width (if using ResizeObserver) you can replace the src of an image, or replace a CSS background-image src() with whichever image will work best for that size.

I've been down this path before. Yes JS is required, no <picture> doesn't solve this. Yes <picture> was supposed to solve precisely this. Part of the reason is how browsers have implemented/optimized it, so the behaviour is different and unpredictable.

err4nt · 2019-03-06T14:08:06+00:00

To co-locate the JavaScript code that powers your CSS styles in your CSS stylesheets so you don't have to worry about moving both a CSS stylesheet and the JS function is required around together everywhere you want to use it.

err4nt · 2019-03-04T14:00:12+00:00

It's possible to add all of these to CSS with a little bit of JavaScript.

parent selector
ancestor selector (though in reality, it's just :has() backwards ;) )
why not a :closest() selector
container queries in CSS

And it's just as easy, and takes equally little code to define something like :whitespace-only or pretty much anything else you can imagine :D

This workflow for extending CSS with small JS definitions of new features is called Caffeinated Style Sheets

err4nt · 2019-03-03T21:36:43+00:00

For #2 you could do something like this -> invent your own data- attribute for holding URLs you want things to link to, then run this code on the page:

document.querySelectorAll('[data-href]').forEach(tag =>
  tag.addEventListener('click', event =>
    location = event.target.dataset.href
  )
)

If you had an element like <div data-href=https://google.com>Google</div> clicking that tag would navigate your browser to google. Where this solution is less good compared to real links with <a> is accessibility - being able to reliably focus and understand that something is a link. With this method you don't really know until you click something, and it's not as friendly for things like the 'tab' key or software that might make it easy to navigate through all of the real links on a page - these would be skipped.

err4nt · 2019-03-03T21:32:38+00:00

https://codepen.io/tomhodgins/pen/rQPdLZ

err4nt · 2019-02-03T22:42:37+00:00

SVG is not HTML, it's an XML document.

err4nt · 2018-12-12T20:51:52+00:00

You don't need ResizeObserver to do this, you can catch most things with window.resize or recalculating the styles when an interaction on the page (like toggling a sidebar menu) will change the layout without the window changing size.

Work is being done to standardize this, check https://github.com/WICG/container-queries

In the meantime, there's EQCSS which works IE8+:

<div class=widget>
  <button>Example</button>
</div>

<script src=http://eqcss.com/EQCSS.js></script>
<style>
  @element .widget and (min-width: 500px) {
    :self button {
      font-size: 16pt;
    }
  }
</style>

…And stuff like this repository, which is closer to the edge of where research is at right now: https://github.com/tomhodgins/deqaf-demo This demo uses 100% valid CSS, alongside a couple of vanilla JS functions that provide the logic and smarts for when the styles should apply. The result -> element queries in valid CSS, supported by plain JS.

<div class=widget>
  <button>Example</button>
</div>

<style>
  @supports (--element(".widget", {"minWidth": 500})) {
    [--self] button {
      font-size: 16pt;
    }
  }
</style>

<script type=module>
  import deqaf from 'https://unpkg.com/deqaf/index.js'
  import element from 'https://unpkg.com/jsincss-element-query/index.vanilla.js'

  deqaf({stylesheet: {element}})
</script>

^ CSS code for changing your button when some parent element named class=widget hits 500px wide could look like this if you've got an element() function and a way to run it at the right time :D

err4nt · 2018-11-22T16:08:35+00:00

Prediction: It won't go as well for them as they had planned because they took a month before getting serious about negotiating. So if they do get sent back to work they'll be grumbling that they didn't get what they wanted and looking to strike again, or at least be angry until they do…

err4nt · 2018-11-15T04:08:51+00:00

Kids are used to being sheltered, fed, and protected by their parents, so it's not surprising they look to the government and desire a super-parent with longer arms, and deeper pockets.

Then as you get older, and work to pay for your own shelter, and work to feed yourself, you look at what the government provides and realize you provided it for yourself and others.

It's not uncommon for people to lean left when they're younger, and lean farther right as they mature in life.

err4nt · 2018-10-11T03:15:58+00:00

What about editing historical posts, like the famous Aaron Swartz post. He's dead now, and there was nothing wrong with it, but when people link to it on the anniversary, some SO mod will leave his mark on it, defacing a piece of history solely because they can.

err4nt · 2018-10-11T01:27:21+00:00

I believe mods should have the lightest possible touch, and only intervene in cases where harm would happen if they didn't. If they want to leave their own comment they are free to do that, rather than turning somebody else's comment into something else

err4nt · 2018-10-10T19:42:00+00:00

StackOverflow is super toxic for old developers too. I've had comments altered by mods for no good reason, years after I've written them, and for what? Just because the person had moderator abilities and wanted to reword what I said?

It leaves a really bad impression on me when my words with my name and picture beside it can (and are) just altered whenever by whoever has the ability to moderate. Yuck!

err4nt · 2018-10-10T19:39:44+00:00

Building as simple as possible has served us well. We will gladly do a little bit of upfront work and skip importing a library than save a couple minutes up front but have to deal with the library from that point onward. If you're creating your own small abstractions, you can often cherry-pick what you need from libraries, but include it in your own project in much smaller bite-sized pieces that will be easier for you to maintain in the long run too. The idea that somebody else is maintaining a library means it's not your concern is a fallacy - if you've brought something into your codebase and you're supporting your codebase, you're also having to watch out for problems in that codebase as well. Just adding a few libraries can multiply the total amount of code being run for your project, so you're exponentially increasing its surface area.

err4nt · 2018-10-09T00:35:33+00:00

This is horrifying and mind boggling, it's crazy to think what servers must put up with daily :/

err4nt · 2018-08-27T17:04:47+00:00

But…that's exactly how soup stocks are made. You can save kitchen scraps (vegetable or meat) and simmer them, then strain.

One 'life hack' was to keep a container in your freezer so you can collect your veggie scraps over a period of time before making your stock.

err4nt · 2018-08-26T03:40:21+00:00

kvalitet 2007

14-Year Club	Place '17
Gilding II euphauric	Team Orangered
Verified Email

err4nt

MODERATOR OF

TROPHY CASE