tomhodgins / element-queries-spec

A spec for a Container-Style Element Query Syntax

CSS Element Queries

A spec for a container-style element query syntax in CSS

Read online: element-queries.html

What is this about?

This spec aims to define a syntax for scoped styles and element queries in a container query style, as well as the related selectors, functions, and units that make scoped styles and element queries versatile and powerful way to write layout-independent responsive conditions for elements in CSS.

Proposed Syntax

/* Scoped Style */
@element div {
  :self {
    background: lime;
  }
}

/* Element Query */
@element div and (min-width: 500px) {
  :self {
    background: lime;
  }
}

/* Container Query */
@element div and (min-width: 500px) {
  :self {
    background: lime;
  }
  html {
    background: red;
  }
}

/* Multiple Selectors */
@element #example-1, #example-2 {
  :self {
    background: lime;
  }
}

/* Multiple Conditions */
@element div and (min-width: 500px) and (min-characters: 5) {
  :self {
    background: lime;
  }
}

View Syntax Example: styles.css

Plugin & Demo

As a reference for the syntax described in the spec, I have included a JavaScript plugin that reads the proposed syntax and displays the desired behaviour of the proposed functionality.

View Plugin: element-queries.js

View Demo: demo.html

Related Projects

There are a few projects currently working with the syntax described in this spec:

• EQCSS Element Query CSS browser plugin
• eqcss-compiler an EQCSS to JavaScript compiler

Further Examples

More examples of this syntax can be found on Codepen by searching for "EQCSS".

Search Codepen for EQCSS: Codepen Search

Who am I?

I'm an independent web developer, not affiliated with any major companies. The research & development contained in this spec is my own.

How you can help

At this stage the work on this spec is focused on taking the existing EQCSS syntax for element queries as implemented by the EQCSS project and defining them in a more formal way so that other plugin builders could design plugins or tools that work with the EQCSS syntax as implemented by EQCSS.js

In the future once the first version of this document is complete, there will be an opportunity to extend the features described.

For now, the most productive way to provide input would be by contributing to the conversation in the Gitter chat room for the EQCSS project

Further Reading

• How Style Scoping Works with Element Queries
• What the Heck are Element Queries & Container Queries?
• Writing Element Queries Today Using EQCSS
• The Search For The Holy Grail: How I Ended Up With Element Queries, And How You Can Use Them Today

element-queries-spec's Issues

Enable SASS/SCSS support?

Hi Tommy,
I am planning to use your awesome project, but I am wondering if it would be feasible to use SASS language, to take advantage of variables and mixins. In my oppinion, pre-processors like SASS are wide used on any size projects. The main compatibility problem between SASS and your project is the $ char in the meta-selectors. I made a test using underscore instead, and works perfectly. What's your oppinion?

wrong-input.eqcss.scss

$brand-color: #ff0000;
@element ".this-selector input" and (min-characters: 5) {
  $this { border-color: $brand-color; }
}

right-input.eqcss.scss

$brand-color: #ff0000;
@element ".this-selector input" and (min-characters: 5) {
  _this { border-color: $brand-color; }
}

output.eqcss

@element ".this-selector input" and (min-characters: 5) {
  _this { border-color: #ff0000; }
}

Combining multiple @element-querries

Hi guys,

is it possible to combine multiple @element-querries. What I'm thinking of is something like

@element ".button__container" and (min-children:3){ 
  @element ".button" and (min-width:276px) {
    :self {
      width: 100%; 
    }
     
    :parent {      
      flex-basis: 476px;
    }
  }
}

I would like to apply the style to the buttons, but only if the button__container has more than 2 buttons.
However, this doesn't seem to work.

Regards
Slawa

Moving eval into separate proposal level?

I really like the proposal, it's incredible! But maybe it would be good to move the eval stuff into a separate proposal? I can imagine evaluating js inside css might be a bit controversial.

I don't understand how scoping works (I read the spec).

I read the spec, but I can't understand what "scoping" means, or at least I don't understand what it is useful for.

For example, I would think that in the following example only the p inside of .two is styled:

https://codepen.io/anon/pen/MrmqeX

But instead what I see is something like "Because there exists an element with class .two anywhere on the page, then apply this style in global scope which applies to all elements on the page even if they are outside of the element with class .two".

I was hoping that styles inside of the @element query would apply only to elements that are found inside of the element(s) targeted with @element. This would be similar to nesting in SASS/LESS/Stylus.

Is this not the case? Do you mean to rather do something like "If there is a <video> element anywhere on the page, then style the whole page in some way"?

Slow performance on Firefox when using scrollbar

Hello there again! Hope you are well.

I've been having some performance issues lately on our app and managed to pinpoint it to the EQCSS code and more specifically to the part when there is an event listener for mousemove.

The issue occurs only when using the mouse to scroll with the scrollbar, and doesn't happen when scrolling with the wheel. This is due to the code:

    window.addEventListener("mousemove", function(){
      if(EQCSS_mouse_down){
        EQCSS.throttle();
      }
    });

I am trying to figure out what is the purpose of re-running the EQCSS code in the mousemove and input listeners. I mean, it's self-explanatory to use it on resize, click, even mouse up (in browser resize, and/or tabs use) but what about mousemove and input? What am I missing here?

Once again thanks for your time!

Element queries on ember

please delete me! sorry :(

positioned elements provide the context

Element queries (and other element logic) should only be relative to the nearest positioned element. This gives authors more control over what the context is. It also slightly reduces, but not eliminates, issues of shifting contexts causing styling thrashing.

This is particularly useful for a few different scenarios:

• It allows you to style inline and inline-block elements that might not return a reliable width to be queried.
• It allows you to create a component and style the internal layout based on that component’s sizing properties. Especially helpful if the internal layout is split into two or more columns but you still want to style based on the component width.

Unitless values eg for "ew" values

I had a case where I wanted to use an "ew" value as a multiplier, but that resulted in an invalid calc() expression:

https://bugs.chromium.org/p/chromium/issues/detail?id=813325

Is it possible to ask EQCSS for a unit-less value? (eg like "ew" but without a unit, or just any value based on element width without a unit, for use as a multiplier)

Production

Hello,
I want to know whether this project is ready to be used in production or not.

:parent, :next and :prev specificity and necessity?

First of all: I love the proposal!

One thing that I couldn't figure out is what specificity :parent, :next and :prev have.

I am also wondering wether they are needed. :parent is by far the most useful of them, but the only one you'd really need is :self.

Overall it feels like these selectors should be in a separate proposal.

I am only commenting this because I love the proposal and hope it will be accepted. Additional complexity could prevent that.

add a nested syntax

Hello,

in LESS I'm able to write media query inside of declaration blocks.

div {  
 color: green;
 @media (min-width: 500px) {  
    color: red;  
  }  
}  

compiles to

div { color: green;}
@media (min-width: 500px) {  
  div { color: red; }  
}

In element queries this could be a nice shortcut because if removes the doubled selector declaration.

  ul { 
    padding: 5px;  
    @element (min-width: 500px) {  
       padding: 10px;  

      li { padding: 1px;}  
    }  
  }  

What do you think of it?

script on CDN (via jsdeliver)

Can you please do a git release. (just click on releases).

If you release, then we can get the .js script via cdn. tia

Will Element/container query would work inside nested feature query?

Multi line Condition error on click

Hello,
I have used eqcss for the product display. Here is the fiddle https://jsfiddle.net/sohilpx/6af77wcm/ .

It renders fine initially but when i click anywhere the height of the div increases automatically. This is not the expected behavior.

Can you look into this?

Specificity

I am right in understanding that EQCSS will always create a real CSS Rule with just a single [data-attribute] selector (irrespective of the selector used as the EQCSS selector)?
e.g.
(at)element '#specific.ew' {
$this {
font-size: 2ew;
}
}
will always give
[data-eqcss-0-0] {font-size: 2ew;};
and NEVER:
#specific.ew.[data-eqcss-0-0] {font-size: 2ew;};

Do I understand that correctly?

Is there any way to 'pass through' the selector to make it more SPECIFIC?

At the moment we have potential issues where greater Specificity exists for some elements within existing CSS stylesheets, or if we wanted to provide a standard CSS fallback just in case.

At the moment the only solution I can find is to include !important for all the EQCSS rules.

Please advise.