You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A “rule declaration” is the name given to a selector (or a group of selectors) with an accompanying group of properties. Here's an example:
31
+
Una “declaración de regla” es el nombre dado a un selector (o un grupo de selectores) acompañados de un grupo de propiedades. He aquí un ejemplo:
32
32
33
33
```css
34
34
.listing {
@@ -37,12 +37,12 @@ A “rule declaration” is the name given to a selector (or a group of selector
37
37
}
38
38
```
39
39
40
-
### Selectors
40
+
### Selectores
41
41
42
-
In a rule declaration, “selectors” are the bits that determine which elements in the DOM tree will be styled by the defined properties. Selectors can match HTML elements, as well as an element's class, ID, or any of its attributes. Here are some examples of selectors:
42
+
En una declaración de regla, los “selectores” son los bits que determinan qué elementos en el árbol DOM tendrán el estilo dado por las propiedades definidas. Los selectores pueden coincidir con los elementos HTML, así como clases de elementos, ID, o cualquiera de sus atributos. He aquí algunos ejemplos de selectores:
43
43
44
44
```css
45
-
.my-element-class {
45
+
.mi-clase-de-elemento {
46
46
/* ... */
47
47
}
48
48
@@ -51,32 +51,32 @@ In a rule declaration, “selectors” are the bits that determine which element
51
51
}
52
52
```
53
53
54
-
### Properties
54
+
### Propiedades
55
55
56
-
Finally, properties are what give the selected elements of a rule declaration their style. Properties are key-value pairs, and a rule declaration can contain one or more property declarations. Property declarations look like this:
56
+
Finalmente, las propiedades son las que dan el estilo a los elementos seleccionados de una declaración de regla. Las propiedades son pares *nombre-valor*, y una declaración de regla puede contener una o más declaraciones de propiedades. Así se ven las declaraciones de propiedades:
57
57
58
58
```css
59
-
/*some selector */ {
59
+
/*algún selector */ {
60
60
background: #f1f1f1;
61
61
color: #333;
62
62
}
63
63
```
64
64
65
65
## CSS
66
66
67
-
### Formatting
67
+
### Formato
68
68
69
-
*Use soft tabs (2 spaces) for indentation
70
-
*Prefer dashes over camelCasing in class names.
71
-
-Underscores and PascalCasing are okay if you are using BEM (see[OOCSS and BEM](#oocss-and-bem)below).
72
-
*Do not use ID selectors
73
-
*When using multiple selectors in a rule declaration, give each selector its own line.
74
-
*Put a space before the opening brace `{`in rule declarations
75
-
*In properties, put a space after, but not before, the `:`character.
76
-
*Put closing braces `}`of rule declarations on a new line
77
-
*Put blank lines between rule declarations
69
+
*Usar “soft tabs” (2 espacios) de indentación
70
+
*Preferentemente usar guiones medios (`-`) en lugar de [camelCase](https://es.wikipedia.org/wiki/CamelCase) en nombres de clases.
71
+
-Guiones bajos (`_`) y [PascalCasing](https://es.wikipedia.org/wiki/Pascal_Casing) son válidos si está utilizando BEM (ver[OOCSS y BEM](#oocss-y-bem)abajo)
72
+
*No utilizar selectores ID
73
+
*Cuando se utilizan varios selectores en una declaración de regla, poner cada selector en una línea
74
+
*Poner un espacio antes de la llave de apertura `{`en declaraciones de regla
75
+
*En las propiedades, poner un espacio después, y no antes, del caracter `:`(dos puntos)
76
+
*Poner las llaves de cierre `}`de las declaraciones de regla en una nueva línea
77
+
*Poner líneas en blanco entre las declaraciones de reglas
78
78
79
-
**Bad**
79
+
**Mal**
80
80
81
81
```css
82
82
.avatar{
@@ -90,51 +90,51 @@ Finally, properties are what give the selected elements of a rule declaration th
90
90
}
91
91
```
92
92
93
-
**Good**
93
+
**Bien**
94
94
95
95
```css
96
96
.avatar {
97
97
border-radius: 50%;
98
98
border: 2pxsolidwhite;
99
99
}
100
100
101
-
.one,
101
+
.un,
102
102
.selector,
103
-
.per-line {
103
+
.por-linea {
104
104
// ...
105
105
}
106
106
```
107
107
108
-
### Comments
108
+
### Comentarios
109
109
110
-
*Prefer line comments (`//`in Sass-land) to block comments.
111
-
*Prefer comments on their own line. Avoid end-of-line comments.
112
-
*Write detailed comments for code that isn't self-documenting:
113
-
-Uses of z-index
114
-
-Compatibility or browser-specific hacks
110
+
*Preferentemente usar `//`(en Sass) para bloques de comentarios.
111
+
*Preferentemente escribir comentarios en una única línea para ello. Evitar los comentarios al final de una línea.
112
+
*Escribir comentarios detallados de código que no es auto-documentado:
113
+
-Usos de z-index
114
+
-Compatibilidad o hacks para navegadores específicos
115
115
116
-
### OOCSS and BEM
116
+
### OOCSS y BEM
117
117
118
-
We encourage some combination of OOCSS and BEM for these reasons:
118
+
Incentivamos el uso de una combinación de OOCSS y BEM por las siguientes razones:
119
119
120
-
*It helps create clear, strict relationships between CSS and HTML
121
-
*It helps us create reusable, composable components
122
-
*It allows for less nesting and lower specificity
123
-
*It helps in building scalable stylesheets
120
+
*Ayuda a crear relaciones claras y estrictas entre CSS y HTML
121
+
*Ayuda a crear componentes reutilizables y que se pueden recomponer.
122
+
*Permite menos anidación y menor especificidad
123
+
*Ayuda a construir hojas de estilos escalables
124
124
125
-
**OOCSS**, or “Object Oriented CSS”, is an approach for writing CSS that encourages you to think about your stylesheets as a collection of “objects”: reusable, repeatable snippets that can be used independently throughout a website.
125
+
**OOCSS**, o “CSS Orientado a Objetos” por sus siglas en Inglés, es un enfoque para escribir CSS que le permite pensar en sus hojas de estilo como una colección de “objetos”: reutilizables, con snippets que pueden repetirse fácilmente y se pueden utilizar independientemente a través de un sitio web.
*Smashing Magazine's [Introduction to OOCSS](http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/)
127
+
*[OOCSS wiki](https://github.com/stubbornella/oocss/wiki) de Nicole Sullivan
128
+
*[Introduction to OOCSS](http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/) de Smashing Magazine
129
129
130
-
**BEM**, or “Block-Element-Modifier”, is a _naming convention_ for classes in HTML and CSS. It was originally developed by Yandex with large codebases and scalability in mind, and can serve as a solid set of guidelines for implementing OOCSS.
130
+
**BEM**, o “Bloque-Elemento-Modificador”, es una _convención de nomenclatura_ para clases en HTML y CSS. Fue originalmente desarrollado por Yandex con grandes bases de código y escalabilidad en mente, y puede servir como un conjunto sólido de directrices para la aplicación de OOCSS.
*Harry Roberts' [introduction to BEM](http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/)
132
+
*[BEM 101](https://css-tricks.com/bem-101/) de CSS Trick
133
+
*[Introduction to BEM](http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/) de Harry Roberts
134
134
135
-
We recommend a variant of BEM with PascalCased “blocks”, which works particularly well when combined with components (e.g. React). Underscores and dashes are still used for modifiers and children.
135
+
Se recomienda una variante de BEM con “bloques” en formato [PascalCase](https://es.wikipedia.org/wiki/Pascal_Casing), que funciona particularmente bien cuando se combina con componentes (ej. React). Guiones medios y bajos se utilizan para los modificadores e hijos.
136
136
137
-
**Example**
137
+
**Ejemplo**
138
138
139
139
```jsx
140
140
// ListingCard.jsx
@@ -161,39 +161,39 @@ function ListingCard() {
161
161
.ListingCard__content { }
162
162
```
163
163
164
-
*`.ListingCard`is the “block” and represents the higher-level component
165
-
*`.ListingCard__title`is an “element” and represents a descendant of`.ListingCard`that helps compose the block as a whole.
166
-
*`.ListingCard--featured`is a “modifier” and represents a different state or variation on the`.ListingCard` block.
164
+
*`.ListingCard`es el “bloque” y representa el componente de más alto nivel.
165
+
*`.ListingCard__title`es un “elemento” y representa un descendiente de`.ListingCard`que ayuda a componer el bloque en su conjunto.
166
+
*`.ListingCard--featured`es un “modificador” y representa un estado diferente o variación del bloque`.ListingCard`.
167
167
168
-
### ID selectors
168
+
### Selectores ID
169
169
170
-
While it is possible to select elements by ID in CSS, it should generally be considered an anti-pattern. ID selectors introduce an unnecessarily high level of [specificity](https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity)to your rule declarations, and they are not reusable.
170
+
Si bien es posible seleccionar elementos por ID en CSS, en general se debe considerar un anti-patrón. Los selectores ID introducen innecesariamente un alto nivel de [especificidad](https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity)a sus declaraciones de regla, y no son reutilizables.
171
171
172
-
For more on this subject, read [CSS Wizardry's article](http://csswizardry.com/2014/07/hacks-for-dealing-with-specificity/)on dealing with specificity.
172
+
Por más información sobre este tema, lea el siguiente [artículo de CSS Wizardry](http://csswizardry.com/2014/07/hacks-for-dealing-with-specificity/)sobre el control de la especificidad.
173
173
174
174
### JavaScript hooks
175
175
176
-
Avoid binding to the same class in both your CSS and JavaScript. Conflating the two often leads to, at a minimum, time wasted during refactoring when a developer must cross-reference each class they are changing, and at its worst, developers being afraid to make changes for fear of breaking functionality.
176
+
Evitar la vinculación de la misma clase en tu CSS y JavaScript. Combinar los dos a menudo tiene consecuencias negativas, como mínimo, tiempo perdido durante la refactorización cuando un desarrollador debe hacer una referencia cruzada de cada clase que está cambiando, y peor aún, los dessarrolladores temen hacer cambios por miedo a romper la funcionalidad.
177
177
178
-
We recommend creating JavaScript-specific classes to bind to, prefixed with`.js-`:
178
+
Recomendamos crear clases específicas para JavaScript para vincular con CSS, con el prefijo`.js-`:
179
179
180
180
```html
181
181
<buttonclass="btn btn-primary js-request-to-book">Request to Book</button>
182
182
```
183
183
184
184
### Border
185
185
186
-
Use`0`instead of `none`to specify that a style has no border.
186
+
Utilizar`0`en lugar de `none`para especificar que un estilo no tiene borde.
187
187
188
-
**Bad**
188
+
**Mal**
189
189
190
190
```css
191
191
.foo {
192
192
border: none;
193
193
}
194
194
```
195
195
196
-
**Good**
196
+
**Bien**
197
197
198
198
```css
199
199
.foo {
@@ -203,16 +203,16 @@ Use `0` instead of `none` to specify that a style has no border.
203
203
204
204
## Sass
205
205
206
-
### Syntax
206
+
### Sintaxis
207
207
208
-
*Use the `.scss` syntax, never the original`.sass`syntax
209
-
*Order your regular CSS and `@include`declarations logically (see below)
208
+
*Utilizar la sintaxis `.scss`, nunca la sintaxis`.sass`original
209
+
*Ordenar el CSS regular y las declaraciones `@include`lógicamente (ver a continuación)
210
210
211
-
### Ordering of property declarations
211
+
### Orden de las declaraciones de propiedades
212
212
213
-
1.Property declarations
213
+
1.Declaraciones de Propiedades
214
214
215
-
List all standard property declarations, anything that isn't an `@include`or a nested selector.
215
+
Listar todas las declaraciones de propiedades estándar, todo lo que no sea un `@include`o un selector anidado.
216
216
217
217
```scss
218
218
.btn-green {
@@ -222,9 +222,9 @@ Use `0` instead of `none` to specify that a style has no border.
222
222
}
223
223
```
224
224
225
-
2. `@include` declarations
225
+
2. Declaraciones `@include`
226
226
227
-
Grouping `@include`sat the end makes it easier to read the entire selector.
227
+
Agrupar `@include`sal final hace que sea más fácil de leer el selector entero.
228
228
229
229
```scss
230
230
.btn-green {
@@ -235,9 +235,9 @@ Use `0` instead of `none` to specify that a style has no border.
235
235
}
236
236
```
237
237
238
-
3. Nested selectors
238
+
3. Selectores anidados
239
239
240
-
Nested selectors, _if necessary_, go last, and nothing goes after them. Add whitespace between your rule declarations and nested selectors, as well as between adjacent nested selectors. Apply the same guidelines as above to your nested selectors.
240
+
Los selectores anidados, _si es necesario_, van al final, y nada va después de ellos. Añadir espacio en blanco entre las declaraciones y selectores de reglas anidadas, así como entre los selectores adyacentes anidados. Aplicar las mismas directrices anteriores a los selectores anidados.
241
241
242
242
```scss
243
243
.btn {
@@ -253,45 +253,45 @@ Use `0` instead of `none` to specify that a style has no border.
253
253
254
254
### Variables
255
255
256
-
Prefer dash-casedvariable names (e.g. `$my-variable`) over camelCased or snake_cased variable names. It is acceptable to prefix variable names that are intended to be used only within the same file with an underscore (e.g. `$_my-variable`).
256
+
Preferentemente utilizar nombres de variable con guiones medios (ej. `$mi-variable`) en lugar de escritura de camello (camelCase) o guiones bajos (snake_case). Es aceptable utilizar como prefijo para nombres de variables que están pensados para ser utilizados solo dentro del mismo archivo con guión bajo (ej., `$_mi-variable`).
257
257
258
258
### Mixins
259
259
260
-
Mixins should be used to DRY up your code, add clarity, or abstract complexity--in much the same way as well-named functions. Mixins that accept no arguments can be useful for this, but note that if you are not compressing your payload (e.g. gzip), this may contribute to unnecessary code duplication in the resulting styles.
260
+
Se deben utilizar Mixins para _secar_ el código, agregar claridad o abstraer de complejidad de la misma manera que las funciones. Los Mixins que no aceptan argumentos pueden ser útiles para ello, pero notar que si no está comprimiendo su carga (ej. gzip), esto puede contribuir a la duplicación innecesaria de código en los estilos resultantes.
261
261
262
-
### Extend directive
262
+
### Extend
263
263
264
-
`@extend` should be avoided because it has unintuitive and potentially dangerous behavior, especially when used with nested selectors. Even extending top-levelplaceholder selectors can cause problems if the order of selectors ends up changing later (e.g. if they are in other files and the order the files are loaded shifts). Gzipping should handle most of the savings you would have gained by using `@extend`, and you can DRY up your stylesheets nicely with mixins.
264
+
`@extend` debe evitarse ya que tiene un comportamiento poco intuitivo y potencialmente peligroso, específicamente cuando se utiliza con selectores anidados. Incluso extender los selectores placeholder de nivel superior puede causar problemas si el orden de los selectores termina cambiando más tarde (ej. si se encuentran en otros archivos y el orden de los archivos cambia). Gzipping debe manejar la mayor parte de los ahorros que se habría obtenido mediante el uso de `@extend`, y se pueden _secar_ las hojas de estilos muy bien con mixins.
265
265
266
-
### Nested selectors
266
+
### Anidación
267
267
268
-
**Do not nest selectors more than three levels deep!**
268
+
**¡No anidar selectores más de 3 niveles de profundidad!**
269
269
270
270
```scss
271
271
.page-container {
272
272
.content {
273
273
.profile {
274
-
//STOP!
274
+
//PARAR!
275
275
}
276
276
}
277
277
}
278
278
```
279
279
280
-
When selectors become this long, you're likely writing CSS that is:
280
+
Cuando los selectores se vuelven muy largos, probablemente se está escribiendo CSS que es:
281
281
282
-
* Strongly coupled to the HTML (fragile) *—OR—*
283
-
* Overly specific (powerful) *—OR—*
284
-
* Not reusable
282
+
*Fuertemente acoplado al HTML (frágil) *—O—*
283
+
*Excesivamente específico (poderoso) *—O—*
284
+
*No reutilizable
285
285
286
+
Nuevamente: **¡nunca anidar selectores ID!**
286
287
287
-
Again: **never nest ID selectors!**
288
+
Si tiene que usar un selector ID en primer lugar (debería intentar no hacerlo), nunca deberían anidarse. Si se encuentra haciendo esto, neceista revisar su marcado HTML, o averiguar por qué necesita tanta especificidad. Si está escribiendo HTMLy CSS bien formado, **nunca** debería hacer esto.
288
289
289
-
If you must use an ID selector in the first place (and you should really try not to), they should never be nested. If you find yourself doing this, you need to revisit your markup, or figure out why such strong specificity is needed. If you are writing well formed HTML and CSS, you should **never** need to do this.
290
+
## Traducción
290
291
291
-
## Translation
292
-
293
-
This style guide is also available in other languages:
292
+
Esta guía de estilo está disponible también en otros lenguajes:
0 commit comments