- From: Patrick Dark <www-style.at.w3.org@patrick.dark.name>
- Date: Sun, 21 Feb 2016 12:10:45 -0600
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: darkdragon <darkdragon-001@web.de>, www-style list <www-style@w3.org>
On 2/16/2016 5:35 PM, Tab Atkins Jr. wrote: > On Wed, Feb 10, 2016 at 12:45 AM, darkdragon <darkdragon-001@web.de> wrote: >> Currently, you need at least 7(!) characters plus the actual name just to >> use one variable. This is quite much to encourage users to use it! >> >> Why do you need "--" AND "var()"? >> Wouldn't be one of it be enough? > We need the -- in var(--foo) so that the name matches exactly between > definition and use. Anything else is potentially confusing, and makes > searching in a document harder. > > We need a var() function for a few reasons. For one, there are a few > places in CSS where you can have arbitrary names already, like counter > styles or animation names, so allowing a bare custom property name > would be ambiguous there. Theoretically we could make it invalid to > name your @keyframes or @counter-style rule something that looks like > a custom property name, but that means more rules for authors to > learn. I think it would be good to go ahead and do this. I've used CSS variables and find that having to declare each variable reference twice—once with var() and again with the "--" prefix—is onerous. Being able to eliminate var() would continue to address your first concern (i.e., syntax consistency) while making the feature significantly easier to use. One reason it's onerous aside from the verbosity, is that if I create a custom property like --color, then try to copy and paste what I just typed to multiple locations, I can't do that without first typing "var(" at the beginning of what I pasted and ")" at the end of what I pasted, then copying that before continuing the paste process. In case it's not obvious, I arrive in this situation because it's typically the case that I'll write part of a style sheet before deciding that I need variable to ensure that certain parts of the style remain consistent. > For two, var() is required in some circumstances, like when you want > to provide a fallback. In general, a language shouldn't provide > multiple ways to do something unless there are good reasons for each, > and there isn't a strong reason to omit var() when you're not using > any other functionality, so I don't allow it. The name of this feature, var, provides no indication whatsoever that it permits fallback values. This is the first I've heard of that functionality and finding it in the spec isn't obvious either because the fallback feature's description doesn't have its own section. This seems inconsistent with your "readability and understandability" principle (quoted below). It also seems strange to have this feature, which is unrelated to variables, be part of the Variables module when there's already a Conditional Rules module that does the same thing. This seems inconsistent with your "a language shouldn't provide multiple ways to do something" principle. > >> Why not something like "v()" as a shortcut (people using jQuery and stuff >> are used to such shortcuts!)? > While I highly value terseness in CSS and promote it whenever > possible, it must be balanced against other concerns, like readability > and understandability. Single-letter names are generally a bad > tradeoff here - they only save a little bit, but they make it much > more difficult to tell what's being referred to. The name "var()" is > already abbreviated from "variable()", but it's a pretty unambiguous > cut, and anyone working in the web platform is already familiar with > "var" from JS. If this was seriously a concern, then the syntax would have been something more like -var-property so that custom property declarations are clearly variables. But it isn't. And, if authors can do without a var() equivalent when invoking variables in other languages, I think authors can do without it in CSS. "--" is the syntax CSS is using for declaring variables and "--" is required when using variables; that follows the paradigm of languages like PHP and is more than is required in languages like JavaScript, which doesn't use variable signifiers at all. For more perspective, imagine having to type var() or let() around every variable use in JavaScript; that would be absurd.
Received on Sunday, 21 February 2016 18:11:15 UTC