[mediaqueries] [css-variables] [css-device-adapt] Scope in CSS

Hi everybody. (Happy Easter to those who believe)
I don't know if someone has proposed such a thing, nor if it is possible on
a technical POV, so I'll throw it out and let's see what happens.
As I can see, Media Queries define blocks which don't contain CSS
properties, but nested selectors along with their instructions.
I also see that media conditions can rely upon a variable aspect, which is
@viewport, and I also saw that someone proposed using variables in media
queries. This is "risky" because it introduces the problem of solving
possible circular dependencies (e.g. @viewport being rewritten in a
viewport-based MQ, or antagonist MQs) and it would be the same with
variables, which would otherwise be quite useful.
In scripting languages (e.g. Javascript) there is the concept of scope and
scoped variables: nested instances, e.g. functions, inherit variable values
from outer level (scope), but var instances defined inside functions that
do not affect their homonyms in outer scopes or in sibling scopes.
I'd say it could be the same for CSS, at least for variable aspects such as
@viewport and maybe proper variables.
"A variable defined in a block of instructions, or a property for a
@viewport instruction, only affects other blocks at the same level of
variable selector or @viewport instruction itself." Thus:

@viewport {
  width: 397px;
}

:root {
  --page-width: 768px;
}

@media (min-width: var(--page-width)) {
  :root {
    --page-width: 120px;
  }

  #header {

    width: var(--page-width);

  }

}

@media (max-width: var(--page-width)) {
  ...
}

#footer {

  width: var(--page-width);

}

#header > nav {

  width: 50%;

}


@media screen and (width: 397px) {
  @viewport {
    width: 500px;
  }
}

@media screen and (width: 397px) {
  #title { color: green; }
}


Every variable or viewport value defined inside a media query block only
affects properties in blocks defined in the same MQ blocks. Only ormal
inheritance allows values to exit their scope. In the example (design
inconsistencies are not relevant, it's just to show out) we have

 * a variable (--page-width) with is defined outside with a value of 768px;
this is used to evalueate a MQ (min-width: var(--page-width)). In case the
MQ applies, the nested scope is executed: the variable is rewritten to a
value of 120px for root descendants, and then this value is used for
#header element. The nested scope is exited, going back to global scope. A
new MQ is evaluated, and then we have an instruction (relying upon the
usual variable) applied to #footer. Both the MQ and the #footer width use
the "global" value of --page-width, 768px, because nested scope does not
affect variable call outside. But #header > nav width relies upon the
parent's width, and so, if the first MQ actually had applied, then <nav>
width inside #header is 60px (120px * 50%).

 * for the same reason, viewport width is globally set to 397px. This value
is used for evaluating the first viewport-related MQ (to true). It contains
a new viewport instruction setting it to 500px width. Viewport is a
"concept", not a real selector, so there is no element this property
applies to. It is just used for the following instructions inside the block
itself. When the MQ block is exited, viewport width is "reverted" (though
this term is not correct) to its initial value of 397px and as such used to
evaluate the second MQ (this is also in line with example introduction,
which says that color:green applies to the element despite viewport
redefinition).

Would this be somehow possible? The part about variables is still under
construction, so there should be no real backward-compatibility issues, and
the one about viewport would be aligned with example description (though
that introduction seems a bit conflictual). The problem is, scopes define a
brand-new concept of memory usage as every MQ (and therefore every nested
scope) potentially defines a new, volatile value for variables and viewport
properties which do not interfere with global (and are discarded on closing
scope).
Sorry for verboseness.

Received on Sunday, 5 April 2015 14:02:56 UTC