xCSS: come up with your CSS specification. Part 1
My previous article, “What I Expected from HTML5 and CSS3” touched on a rather sensitive topic, but did not answer a perfectly reasonable question, but what do I offer in return. Therefore, I came up with the idea of creating a public CSS specification that would reflect current web technology development trends and requirements for future functionality. I invite everyone to participate in the development of our own version of the specification. If its popularity is high enough, it can be accepted by all browser developers, and both web developers and users will benefit from it.
The first mechanism that I bring to your attention is called "guides"
Guides
The purpose of this mechanism is to simplify the control of positioning of elements relative to each other. The tabular presentation of the data does not allow creating stream structures when the number of elements in a row is unknown, and elements need to be transferred to the next row when changing the width of the container. Line blocks (inline-block) do not allow the formation of automatically adjustable blocks in height or width. It is these problems that the guide mechanism will solve.
Guide definition
Guides are block elements of zero height or width, depending on the type: horizontal or vertical. Neither the width nor the height of the guides can be controlled, they always occupy 100% of the width or height of the element. Guides can have margin, padding, border, background, which will allow you to create certain stylistic techniques.
Guide Description
Guides have specific behavior even within the current CSS standard. Linking their description to a specific element will not allow flexible control of the display in complex cases. I suggest extending the CSS syntax a bit to free your hands and not repeat the mistakes of the current specification, and introduce local identifiers.
$rule1 { /* rule preferences */ }
$rule2 { ... }
Already existing identifier and class selectors cannot be used as a local variable, since the name of the guide is used only inside CSS, and should never be used directly in HTML. There is another problem that does not allow the use of identifiers and classes, but I will talk about it later.
rule-type
There are two types of guides: horizontal (horizontal) and vertical (vertical) . Guides are horizontal by default.
Property Values: horizontal || vertical
Default value: horizontal
rule-repeat
This property controls the repetition of guides. By default, the repeat mechanism is disabled for guides.
Property Values: none || repeat
Default value: none
The repetition mechanism is necessary in order to automatically form several guides with the same properties and identification. The repeat property is used only when margin-top or margin-bottom or padding-top or padding-bottom is specified for the horizontal type of guides , and margin-left or margin-right or padding-left or padding-right for vertical guides, respectively .
The number of horizontal guides is calculated using the formula
kh = containerHeight / (ruleMarginTop + rulePaddingTop + rulePaddingBottom + ruleMarginBottom)
The number of vertical guides is calculated using the formula
kv = containerWidth / (ruleMarginLeft + rulePaddingLeft + rulePaddingRight + ruleMarginRight)
Example of use
$myRule {
rule-type: vertical;
rule-repeat: repeat;
margin-right: 10px;
margin-left: 20px;
padding-right: 50px;
}
rule
To use guides in some block, the rule directive is used
Property Values: $ ruleID [$ ruleID]
Default: none
You can use one or two variables with guides of different types. When using two identical types of guides, this directive does not apply.
Using guides
After defining the guides, a block control mechanism is needed. To do this, you need another snap-to property , which will tell the elements inside the block with guides how they should interact with each other.
snap-to
Property Values: [top ($ ruleID)] [bottom ($ ruleID)] [left ($ ruleID)] [right ($ ruleID)] || [top] [bottom] [left] [right] || none
Default value: none
In difficult situations, when the block with guides contains another block with guides, it is better to indicate adhesion to a specific edge of a particular guide. In simpler cases, specifying a guide identifier is optional.
Sticking to the edge is similar to the behavior of an element with position: relative.
I specifically omit the more detailed behavior, since it will take more than one page of text, and I will turn to examples
. Usage examples
A typical task is a gallery. I know that you can use inline-block, but by adding another horizontal guide, you can make an analogue of the table, which cannot be done by conventional means.
$ rule1 {margin-top: 200px; rule-repeat: repeat; }
#gallery {rule: $ rule1; }
#gallery div {snap-to: bottom}
...
A form in which labels are aligned with the shapes along the guide
$ rule1 {margin-left; 150px; rule-type: vertical; }
#form {rule: $ rule1; }
#form label {snap-to: right}
#form span {snap-to: left}
A three-column layout can be done like this:
$ rule1 {margin-bottom; 100%; rule-repeat: repeat; }
#wrapper {rule: $ rule1; }
#wrapper> div {snap-to: top ($ rule1) bottom ($ rule1)}
Conclusion
Guides have many “white spots” in behavior that need to be investigated, modeled, and studied. This is especially true for the relationship between the adhered elements and the normal flow, adhered and floating elements, how the elements should behave if they adhere to the left and bottom edges of the guide grid, and so on. However, one thing is clear that this mechanism does not greatly modify the existing CSS2.1 rules, but only supplements them. The implementation of guides, in my opinion, is much simpler for browser developers than the implementation of the same display templates in CSS3, and there are more possibilities and dynamics in my way.
Waiting for your criticism, comments, additions.