I understand how to use variables in CSS. They have helped heaps with speeding up my work flow for my clients' sites.
I have noticed on more than a few occasions I would write down variables with a number next to it to assign to a particular color or look because there is no array system in place. I ended up creating a quasi-array so to speak.
Like this
--c1: color:#ddd; //link color
--c2: color:#aaa; //quote color
--c3: color:#444; //body text
Is it possible to do something like this in CSS?
--c new array (color:#ddd, color:#aaa, color:#444);
Then call array
arr(--c,3);
instead of
var(--c3);
I get that CSS is not a OOP, but it would be nice to be able to handle data like this, especially if I can extend it across two dimensions. I also understand this may be a pointless exercise in theory as typing --c3 is faster than doing --c,3 or even --c[3]. Food for thought.
Properties in CSS cannot be grouped in arrays in the way you describe. This includes custom properties. Preprocessors such as Sass and LESS have maps and lists, but the way custom properties work (see section 3 of the spec) means it's not possible to group them and index off of them using the same syntax found in preprocessors.
Related
I'm looking for a real solution to the problem of making a text flow inside a CSS-shape or inside an SVG-shape.
On the internet, you can find many partial solutions like:
https://www.html5rocks.com/en/tutorials/shapes/getting-started/
https://www.sarasoueidan.com/blog/css-shapes/index.html
All of them use "shape-outside" which is amazing for many purposes but in some cases it doesn't work well. That because these ways use two shapes with "shape-outside" and not a single CSS-shape with "shape-inside".
So I'm asking my self:
Does really exists "shape-inside"?
If not, is it going to be available soon?
Does something similar exist with SVGs?
I would like to create a web app that lets the user choose between different presets for floors and walls in an archilogic 3D scene.
https://spaces.archilogic.com/model/template/new?modelResourceId=f67ffde0-278e-11e4-9f8c-7dda0d61ae4a&mode=edit&view-menu=camera-bookmarks&main-menu=interior&logo=false
Just like in this editor, however, I need the materials menu to be simpler (user chooses from different preset textures which were uploaded earlier by the admin with the corresponding diffuse, spec, normal, and alpha maps).
I was browsing through all the repos of archilogic but couldn't find the source code of the 3D editor in order to make it simpler.
Does anyone know if it's available, if not, which direction should I be headed in order to develop such an app?
This is a feature that still is on the roadmap and not done yet, but there are ways to accomplish something similar.
So above all, the following description is due to all this not being ready and polished yet. It's an experimental way of getting to your goal.
Let's break this down.
Predefined materials
Archilogic has a long list of pre-defined materials right now that you can pick from. They're agnostic to the type of architectural element, so you can use any material on any element. Here is the list of available materials.
Floor & ceiling
Floors and ceilings are contained in a single element with an io3d-floor component.
So assuming you've got your floor and ceiling in the elem element, you can do the following to select a pre-defined material:
elem.components['io3d-floor'].data.material_top = 'wood_parquet_oak';
elem.components['io3d-floor'].update()
this will change the floor material to the given pre-defined material, in this case "wood_parquet_oak". For the ceiling material, change material_top to material_ceiling.
Walls
Walls work pretty much the same, but the properties are material_front and material_back instead of material_top and material_ceiling.
Other architectural elements
For other elements, you can probably work it out by looking what is available as properties in .data of the associated component (e.g. io3d-wall for walls).
Custom materials
This is a little harder to get right as there's a bunch of properties involved in making a custom material.
Assuming you have uploaded textures somewhere, you'd define the material like this:
elem.components['io3d-floor'].data.material_top = {
mapDiffuse: "https://example.org/texture.hi-res.gz.dds",
mapDiffusePreview: "https://example.org/texture.lo-res.jpg",
mapDiffuseSource: "https://example.org/texture.source.jpg"
}
You can also give it additional parameters, such as size: [3,3] scaling the texture to cover 3x3 meters in the model before repeating itself or passing normal maps or specular maps, but I exclude these for brevity.
Note: You can use this kind of material definition for anything that also accepts the pre-defined materials mentioned above. It's important to follow the naming convention and you need to have a gzipped DDS texture available as well as JPEG versions.
The 'Source' image is optional, but the other two have to be present or it won't work.
Summing it up: This functionality isn't fully ready yet (as you can tell by the quite contrived way of getting this to work) but this workaround will do until a better way is going to be available.
With the introduction of css vars, I would like to know the reasoning of of why -- would be chosen as a way of denoting a var.
Considering CSS has a semi capable calc function, I feel like the -- could easily be confused for a decrement operator in other languages.
I am curious if there is any historical significance or technical limitation that led to choosing --. The double in particular perplexes me, when CSS markers are generally singles (#, ., #, etc). Also using a symbol already being used by other things also is interesting (especially when its valid for a class name to begin with --).
Example:
#custom-media --lt-sm (width < 576px);
--grey300: #e0e0e0;
.navbarItem {
display: inline-block;
text-align: center;
border-top: 1px solid var(--grey300);
border-left: 1px solid var(--grey300);
#media (--lt-sm) {
flex-grow: 1;
}
&:last-child {
border-right: 1px solid var(--grey300);
}
}
Disclaimer
Some might argue the validity of this question, but understanding the why is a key technique to remembering a particular concept.
The only discussion I can find related to it:
In the telcon today, we resolved to use a "--" prefix to indicate
custom properties and other custom things.
We discussed whether the prefix is maintained or dropped when
referring to the custom property from a var() function, but didn't
actually resolve. Discussion in the call leaned toward dropping the
prefix, like I do currently with var-* properties, but some side
discussion with Simon and Sylvain argued for using the full name, as
there are confusing cases like "--0" or "----".
So, while I understand the potential confusion caused by authors
possibly thinking that var() can take any property name as an
argument, I think it's overruled by the confusion over what needs to
be escaped in various circumstances. Escaping rules are always very
confusing to authors, so I'm going to go with "use the custom property
name literally as the var() argument".
Reference:
http://lists.w3.org/Archives/Public/www-style/2014Mar/0467.html
https://www.w3.org/TR/css-variables/#defining-variables
On top of avoiding clashing with vendor prefixes that begin with a single dash as mentioned by the other answers, keep in mind that the grammar for a CSS ident doesn't allow anything other than letters, numbers, dashes and underscores (see section 4.1.3 of CSS2). Were a custom property to be denoted by any other symbol, every existing CSS implementation would need to update or even rewrite its parser just to accommodate whichever symbol was being used for custom property names.1
From the minutes of the telecon that's alluded to in the message, you can see that the hypothesis of avoiding clashing with vendor prefixes that begin with a single dash is true. The use of -- did require a minor parser change, because idents normally cannot start with double dashes (as klumme pointed out). I'm not sure exactly how existing implementations parse(d) declarations, but it's safe to assume that my reasoning still holds: since idents can start with one dash, consuming the first dash would not immediately result in a parse error, so a parser can determine if it's looking at a <property> or a <custom-property-name> (or then encounter a parse error if it doesn't support custom props) before deciding how it should proceed.
This change is also reflected in the css-variables spec, in section 2 (which I also cover here):
A custom property is any property whose name starts with two dashes (U+002D HYPHEN-MINUS), like --foo. The <custom-property-name>
production corresponds to this: it’s defined as any valid identifier that starts with two dashes.
So dashes are used because they fit into the existing grammar with only minor parser changes, and double in particular to prevent clashing with vendor prefixes (note that dashes and underscores are interchangeable for vendor prefixes, so a single underscore wouldn't cut it either).
1 As a matter of fact, I gave this very same reasoning in response to somebody else's question just a few weeks ago, although their question wasn't about the chosen prefix for custom prop names.
I think that it was potentially related in some way to how vendors have their own prefix in which hyphen denoted attributes are ignored if they're not understood by the browser/parser. I think. It's also one way that wouldn't clash with any other CSS function or object that already exists.
For example preprocessors like LESS use the # symbol whereas SASS uses the $ symbol. This was discussed over at the Software Engineering SE that has a pretty decent answer to go with it.
Essentially, it seems that it was for compatibility reasons above anything else. One could argue that it's also easy to denote what is a variable compared to other things like the & symbol and % symbol.
Here is some additional reading on the differences of CSS variables over on CSS Tricks which includes vanilla CSS, LESS and SASS etc.
My thinking is it has to do with backwards compatibility. When you add something to CSS, not only do you have to make sure the syntax can be parsed unambiguously, you have to make sure that the new feature will not affect how old browsers parse the parts of the stylesheet that they are actually able to understand.
As variables can be declared inside a rule set, one hyphen could cause confusion with vendor prefixes. And the class name in a class selector is actually not allowed to start with two hyphens, at least in the CSS 2.1 spec.
What I want to do is write a selector that matches an arbitrary value in one place, then later requires a different value be equal to it. If [attr="value"] parsed "value" as a regex, then this would solve my problem:
*[class="(.+)"] *[class="if_\1"] {/* styles */}
Obviously I could just list each possible class individually, but that takes a great deal of convenience out of it.
Is this possible?
No, it's not possible. Attribute selectors are almost completely static and provide almost no dynamic matching functionality (beyond that of substring matches, which are still static and not dynamic pattern-based). They do not support anything like what you see in everyday regular expressions.
A stylesheet preprocessor such as Sass or LESS will allow you to generate the static CSS rules needed, but all that does is automate the manual task of listing all possible values individually, which proves my first point.
So, I want to display some rules concatenated with AND or OR, and I want to add color to AND or OR like red, green etc.
Fruit = Apple AND Market = SuperMarket1
So how should I do this? I have following thoughts:
To control the css by adding the css properties in repository or service class which handles the data access, which works but violates MVC design pattern.
To manipulate the data in the View using something like the Helper class, but the problem is the helper class has to parse the string to find the AND and it is possible that if AND is part of the rule. Even it is in rare case but it is still possible that if any rule contains the keyword and displays it incorrectly.
Any idea? Thanks in advance!
Just conditionally set a span with appropriately styled class on the element you want to color in the View. You can set helpers to do this and that, but often times people get so out of hand with helpers that they needlessly complicate the app....which is the opposite of the aim of MVC. Yes, it might violate the "strict" rules that MVC is supposed to follow. But step back and think about it.....is your environment REALLY big enough that you have to 100% strictly separate a minute amount of code and the presentation layer? Really? I've worked for Fortune 500's who don't stress that much.
The thing about MVC is that you can analyze it to death. It's great help to those of us who are building complex apps. But, there's an exception to EVERTHING. If you stress about these exceptions, you're not going to get anything done. Loosen the tie, man.