Great roundup, but you’re missing a key element query plugin: EQCSS

EQCSS looks like the most feature-complete of the Element Query plugins available right now, it currently supports:

- @min/max width@
- @min/max height@
- @min/max child elements@
- @min/max characters@
- @min/max lines of text@
- @min/max Y scroll position@
- @min/max X scroll position@

As well as introducing some other crucial features that make working with element queries manageable, like:

- scoped styles (using @$this@)
- a parent selector for CSS (using @$parent@)
- using values returned from JavaScript inside styles
- and more!

You can read more about how to use the EQCSS plugin here

The biggest change for me in the past year has been shifting my thinking from the BEM and Bootstrappy ‘classy HTML’ toward a cleaner more ‘element-first’ approach. Here are some examples of things built in the past year using element queries thanks to the EQCSS plugin:

- Blockquote Style
- Calendar
- Content Demo
- Counting Children Demo
- Date Demo
- Zastrow-style Element Query Demo Demo
- Flyout Demo
- Headline Demo
- Media Player Demo
- Message Style Demo
- Modal Demo
- Nav Demo
- Parent Selector Demo
- Pricing Chart Demo
- Responsive Tables Demo
- Scroll-triggered Blocker Demo
- Signup Form Demo
- Testimonials Block Demo
- Tweet-Counter Demo
- JS Variables Demo
- Responsive Scaling Demo

…I think it’s safe to say EQCSS is a working, viable answer to the question of Element Queries!

FYI, EQ.js doesn’t require defining breakpoints in the HTML. You can also define them in your CSS using :before, just like Elementary. When you use the included Sass mixins, though, EQ.js will add a list of selectors to a :before element on the body tag, which the script uses to initialize. This way there’s no parsing the CSS file using JS and no breakpoints in the markup.

There is no real solution for HTML unless you redesign the entire resize functionality using Javascript and fixed sizes. You know where this problem has been very elegantly solved? Windows Presentation Foundation. There is a two pass resize mechanism: first the children request the size they want, bubbling up, then a second pass comes top-down where containers tell children what their size is. In the end, the child cannot force a container size. Also, the logic of how children are arranged is defined in the container, so a stackpanel would be working differently than a grid or a listview.

While it wouldn’t work in the same way in a web medium, I think it is worth considering that a one pass mechanism is not sufficient and rather than adding weird conditions in CSS, we should maybe think of revamping the rendering mechanism and adding new events.

Late last year I dived into responsive web design while working on a major website upgrade. I quickly came to the conclusion that there must be an easier way to do RWD than using media queries. Sorry Ethan, there is an easier way.

I solved the problem with 12 lines of pure JavaScript (no jQuery!) and a couple of small JavaScript helper functions. Using JavaScript, CSS tables and a simple grid layout I now have a versatile solution that avoids code bloat.

I call the solution jRWD. It is available on GitHub (https://github.com/BlackMagic/jRWD). It works on all modern browsers and mobile devices. To see jRWD in action please visit ieee-qld.org or ieee-qld.org/TISP and check out the source code. You might be surprised at jRWD’s simplicity!