Element Queries


#21

I have published a bunch more element query demos now, as well as some blog posts which help explain how the syntax I’m using works. It’s very versatile and coming in very handy for building responsive modules that can be deployed across multiple domains.

The modals adapt to the width of the modal in the browser, as well as the height of the cover image, and the width of the ‘Add to Cart’ button.

Modal Testing Screenshots

@MT: The reason I submitted a follow up comment was because Discourse wouldn’t allow me to post more than five links in one comment.


#22

Please refrain from posting many links in your comments as that would get you caught in the spam filters. You could instead create a page that contains all these resources elsewhere and link to that page from here.


#23

Hi! I am a UX designer at an enterprise software company. Our flagship products are browser-based, and I find that element/container queries would be the most reasonable way to implement the kinds of designs I’d like to produce for our users.

Has there been any movement on this? It appears that the dust has settled somewhat in the syntax thread on Github, though @ausi’s proposed making the syntax match Media Queries Level 4 more closely in his prolyfill implementation. @tomhodgins’s EQCSS supports container query functionality and a handful of other handy extensions to CSS. Some of his example use-cases are also very compelling (IMO), like this responsive calendar component.

So, what can I do to help further this discussion? Do we need more use cases? Is there a thread somewhere else that I’m not seeing?

Thanks!


#24

Yes on the EQCSS front!

We have been busy, and have recently added:

  • SCSS alternates for meta-selectors
  • Firefox speed enhancements
  • EQCSS now watches mousedown, mousemove, mouseup, and input
  • Performance improvements (introduction of EQCSS.throttle())

We’re also hosted in cdnJS as well if you want to use a hosted copy instead of mirroring it yourself.

I’ve also written an article (~6k words) that should be published sometime soon (any day now) that explains the history, research, syntax, and concepts related to EQCSS so watch for that to come out!

Oh, we also have a Gitter chat room now where I would love likeminded folks who want to talk about element queries, container queries, EQCSS, or even other element query plugins to come hang out and discuss. We’re breaking new ground here, so comparing notes will help all of us get this figured out :slight_smile: You’re all invited!

Lately I’ve been busy outputting a lot of Element Query related demos on Codepen too, so check that out: http://codepen.io/tomhodgins/pens/public/

EDIT: Oh, and the demos on the website now have touchscreen grab handles so you can resize the demos on mobile! Everybody gets to experience element queries :smiley:


#25

There has been movement on this!

Lately I’ve:

Hopefully that sparks some interest and keeps the ball rolling on element/container queries!


#26

Implementation seems to be a big question mark at the moment, particularly because of performance worries. Has there been any consideration to defining what’s queried, as far as width and height, in CSS - like context-width: 30%? It seems like that would avoid circular dependencies, although it does have major limitations - flexbox, grid - it could be a much more performant first step…


#27

@pmccloghrylaing There is already an implementation of the syntax I’ve been using available at http://elementqueries.com and performance is usable today. In the future there will be more direct ways to apply styles written in this syntax to the browser and page too, so performance will become even less of a concern in the future than it is today.

Circularity also doesn’t seem to be a problem at all in practice, only in theory. When writing element queries it’s so illogical to try to express something that would get stuck in a loop that you never seem to do it by accident when actually building things. Even sitting around trying to come up with example where you could introduce a circular dependency is hard to do. It’s possible to create infinite loops in JavaScript (and almost any other programming language), that means the language is powerful—not that it’s flawed. Here’s how we’ve handled circularity in our syntax: https://tomhodgins.github.io/element-queries-spec/element-queries.html#self-referential-element-queries

I’ve been using this syntax to build things for the past 2 years and it’s been a dream to use — try playing around with some of the demos and code samples on Codepen to see what you can do with it: http://codepen.io/search/pens?q=eqcss&limit=all&type=type-pens


#28

I had an idea yesterday for how we could achieve container-query-like features with CSS variables that may be easier for browsers to implement:


#29

with ResizeObserver will help get nearer to container query. CSS only would be much better but better something than nothing :slight_smile:

<my-component class="my-component"></my-component>

<style>
.my-component {
	--my-component-content-query-px: 200;
	color: red;
}

.my-component.is-content-query { /* this will always prevail over media query when is active */
	color: blue;
}

@media (min-width: 400px) {
  .my-component {
    color: green;
  }
}
</style>

<script>
class Component {
	constructor() {
		this.elm = document.querySelector('my-component');
		this.contentQueryWidth = null;
		this.RexObx = null;
		this.isContentBreakPoint = false;
	}
	
	init() {
		this.contentQueryWidth = this.getCSSCustomProperty("--my-component-content-query-px");
		this.RexObx = new ResizeObserver(this.resizeObserverHandler);
		this.RexObx.observe(this.elm);
	}
	
	resizeObserverHandler (entries) {
		let entry = entries[0].contentRect;
		this.isContentBreakPoint = this.contentQueryWidth <= entry.width;
		this.elm.classList.toogle('is-content-query', this.isContentBreakPoint);
	}
	
	getCSSCustomProperty(cssCustomProp) {
	    let value = window
	        .getComputedStyle(this.elm)
	        .getPropertyValue(cssCustomProp)
	        .trim();

	    return value - 0; // coercion to number
	}
}

let instance = new Component();
instance.init()
</script>

working example in chrome canary

repo: https://github.com/MatteoWebDesigner/css-container-query-with-resize-observer demo: https://css-container-query.herokuapp.com/


#30

I am planning to use EQCSS in one of the projects. However the project uses polymer library. I faced some problems including EQCSS in a polymer component. With web components gaining importance is there a plan to include support for shadow dom and web components?. It would really fantastic if this could be used in a web component as we would like the styling also to be within the component and not depend on the screen width etc.


#31

Hi @satyanath! Do you have a live example of the sort of components you’re using? I’d love to see if I can find a way to style them. I was doing experiments styling the shadowDOM with regular CSS last week so I’m wondering if EQCSS can get in there :slight_smile:

Are there Polymer component demos online configured how you’ll be using them somewhere that I could experiment with?


#32

Thanks for the quick response. Unfortunately the code I have is way too complex and the component is having lot of our product logic. I will try to generate a simple component and provide. I have a release next week - may be I can do that after that.

Thanks for willing to help.


#33

Here is a simple polymer component using EQCSS.

https://1drv.ms/u/s!AkIVd37AT9QPlKgaObHzdMlm1uYiuw

The code works in google chrome. However it is using the “shady” dom (a simulation of shadow dom by polymer). In the index.html if you change the “shady” to “shadow” in line number 13, the element query does not work.

Shady dom allows all the elements within a component to be visible and hence global queries on selectors will be able to access elements within a component, however that is not possible in shadow dom. If the code runs with the component context (i.e. this is set to the component - all the elements inside would be visible).May be this will give a clue of what can be done to make it work with shadow dom.

Now the code (both with shady and shadow dom) does not work in firefox. In firefox as there is no shadow dom support it would use shady dom only. In my other (actual product code which I cannot share) I could get EQCSS working in firefox also by putting the EQCSS script tag outside the template and dom-module tags. But here in this example I am unable to get it working. Not sure what is the issue.


#34

I was able to get the Firefox version working. I included the code in the attached function of the component which caused EQCSS to be part of the component.

Wit this it is working in both Chrome and Firefox - but only with Shady DOM. It still does not work with Shadow DOM.

https://1drv.ms/u/s!AkIVd37AT9QPlKgbJq5Vig-ogQ7R2Q