{"action":"created","issue":{"url":"https://api.github.com/repos/eqcss/eqcss/issues/12","repository_url":"https://api.github.com/repos/eqcss/eqcss","labels_url":"https://api.github.com/repos/eqcss/eqcss/issues/12/labels{/name}","comments_url":"https://api.github.com/repos/eqcss/eqcss/issues/12/comments","events_url":"https://api.github.com/repos/eqcss/eqcss/issues/12/events","html_url":"https://github.com/eqcss/eqcss/issues/12","id":152904657,"number":12,"title":"Can you instantiate the keyword selectors?","user":{"login":"dropddesigns","id":2650467,"avatar_url":"https://avatars.githubusercontent.com/u/2650467?v=3","gravatar_id":"","url":"https://api.github.com/users/dropddesigns","html_url":"https://github.com/dropddesigns","followers_url":"https://api.github.com/users/dropddesigns/followers","following_url":"https://api.github.com/users/dropddesigns/following{/other_user}","gists_url":"https://api.github.com/users/dropddesigns/gists{/gist_id}","starred_url":"https://api.github.com/users/dropddesigns/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dropddesigns/subscriptions","organizations_url":"https://api.github.com/users/dropddesigns/orgs","repos_url":"https://api.github.com/users/dropddesigns/repos","events_url":"https://api.github.com/users/dropddesigns/events{/privacy}","received_events_url":"https://api.github.com/users/dropddesigns/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":13,"created_at":"2016-05-04T00:27:11Z","updated_at":"2016-06-16T23:08:34Z","closed_at":null,"body":"I'm using a modified version of the BEM syntax and was wondering if you can instantiate $this with a modifier\r\n\r\ne.g.\r\n\r\n@element '.block' and (min-width: 300px) {\r\n  $this {\r\n    background-color: #000;\r\n  }\r\n\r\n  $[this]--brighten {\r\n    background-color: #FFF;\r\n  }\r\n}"},"comment":{"url":"https://api.github.com/repos/eqcss/eqcss/issues/comments/226639431","html_url":"https://github.com/eqcss/eqcss/issues/12#issuecomment-226639431","issue_url":"https://api.github.com/repos/eqcss/eqcss/issues/12","id":226639431,"user":{"login":"tomhodgins","id":955601,"avatar_url":"https://avatars.githubusercontent.com/u/955601?v=3","gravatar_id":"","url":"https://api.github.com/users/tomhodgins","html_url":"https://github.com/tomhodgins","followers_url":"https://api.github.com/users/tomhodgins/followers","following_url":"https://api.github.com/users/tomhodgins/following{/other_user}","gists_url":"https://api.github.com/users/tomhodgins/gists{/gist_id}","starred_url":"https://api.github.com/users/tomhodgins/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tomhodgins/subscriptions","organizations_url":"https://api.github.com/users/tomhodgins/orgs","repos_url":"https://api.github.com/users/tomhodgins/repos","events_url":"https://api.github.com/users/tomhodgins/events{/privacy}","received_events_url":"https://api.github.com/users/tomhodgins/received_events","type":"User","site_admin":false},"created_at":"2016-06-16T23:08:34Z","updated_at":"2016-06-16T23:08:34Z","body":"> My premise is that we don’t control article widths (eg 33%, 50%, 100%) because we may not know where the article will exist or how wide it will be.\r\n>\r\n> The articles could be nested a couple of layers deep. The idea is that the article gets inserted anywhere and its child elements 'adapt' and are styled accordingly to the width of the article.\r\n\r\nYes, this is the idea behind EQCSS. I see this being based on the layout (or grid) that you are using for a page.\r\n\r\n> Maybe element queries are different to container queries and I’m mixing the two concepts?\r\n\r\nNo, you aren't mixing them up. There _can_ be a difference but in this case EQCSS is a container-style element query syntax, just like how `@media` queries are a container that wrap a block of styles. Some people support element queries just on individual elements themselves at the rule level, so you wouldn't be able to affect any element on the page other than the one meeting the condition. Our container-style approach lets you style any element on the page when a condition is met :)\r\n\r\nHere's a pseudo-code rule-level element query, it couldn't style anything other than itself\r\n\r\n```\r\n.widget[width<300px] {\r\n  color: red;\r\n}\r\n```\r\n\r\nVersus a container-style query, which can style itself, child elements, but also any element on the page:\r\n\r\n```\r\n@container '.widget' (width<300px) {\r\n\r\n  .widget {\r\n  \tcolor: red;\r\n  }\r\n  .widget a {\r\n  \tcolor: blue;\r\n  }\r\n  .widget-wrapper {\r\n\tborder: 1px solid black;\r\n  }\r\n\r\n}\r\n```\r\n\r\nBoth of the syntaxes in this are fictional, but should illustrate the difference. Container query isn't synonmous with element query, because isn't `@media` a container query already? I'm not sure if there's a convenient term for the attribute-style element query approach, the non-container-style element query plugins.\r\n\r\n\r\n> I've created an image to illustrate where I am coming from. The three areas surrounded by the dashed borders indicate three different components (could be portlets, different modules, different source APIs etc).\r\n> The articles represented in the three different components are the same article.\r\n> The idea is that the article content comes back with the exact same classes and basic HTML structure each time. We don't necessarily have the control to add more classes.\r\n> Therefore, we set element queries on the article to say if the article is under a certain width, stack the image and body copy (we can achieve this).\r\n\r\nYes, this is exactly the use case behind the development of Element Queries. I made some [nice responsive tables](http://staticresource.com/tables), but then when we started putting them in layouts with sidebars, and at different sizes, suddenly all my break-points were off. So instead of writing viewport-relative responsive queries I can just style on element from 200px up to 2000px and I never have to worry about where it gets displayed, I know it will adapt to look its best.\r\n\r\nHere's a video of me converting a `@media`-based navigation into `@element` queries that shows that once you have it in `@element` queries you can stick it in any size of container and it will adapt: https://www.youtube.com/watch?v=ybCrzsglqXM\r\n\r\n> However, if the article is inside a two, three, four column grid layout, we also want the columns to change their width (25%, 33%, 50%, 100%) depending on the width of the grid container.\r\n> \r\n> To make it more complex though, the grid may be nested so you probably can't rely solely on the browser viewport width. Ultimately, this is why we need element/container queries in the first place right?\r\n\r\nYou can't nest `@element` queries inside each other, but you can nest elements with `@element` queries applied inside each other just fine. Check out [this demo](http://staticresource.com/widget-demo.html) for a lightweight example, and [this demo](http://staticresource.com/squeezeCSS/) for probably the heaviest, most convoluted nested example of EQCSS that's been built so far.\r\n\r\n> What I've found is that when the article has an element query, placing it inside another component that also has an element query, you have to use pixels as the relative units don't seem to work.\r\n\r\nI'm curious why the desire to base nested multiple elements with em-based repsonsive queries, it seems harder to think in ems than pixels for stuff like this, no? What's the advantage to using `em`?\r\n\r\nWe did try to support every unit, even the weird ones. That's strange and I'll keep investigating this.\r\n\r\nI've built another demo from scratch in which I place `article` elements with a bunch of `@element` queries on them based on `em` units are placed within a larger layout still based on `@element` queries using `em` units ☛ http://codepen.io/tomhodgins/pen/beeQON\r\n\r\nDoes this solve the issue?"}}
{"actor":{"display_login":"tomhodgins"}}