css - parrafos - meta tags seo
Desarrollo y mantenimiento efectivo de CSS a gran escala para sitios web multilingües (7)
Creo que si quieres esto, tienes que usar algo como lesscss .
Hay un estándar en los trabajos para abordar esto, pero no conozco ningún navegador que lo admita. Incluso cuando lo hacen, es probable que se vea frenado por el soporte del navegador heredado (¿pero cuándo no ha sido esto un problema?).
Dejando de lado todos los desafíos técnicos, una vez hecho esto, me imagino que para implementarlo bien, aún tendría que asegurarse de externalizar cada referencia a izquierda / derecha y luego usar algo similar a la forma en que se utilizan las consultas de los medios en el diseño responsivo para navegadores móviles
Considere este escenario: está desarrollando una aplicación web multilingüe. Si todos los idiomas a los que te diriges son LTR o RTL , no tienes necesidad de reglas CSS específicas del idioma. Sin embargo, si sus idiomas de destino son una mezcla de idiomas LTR y RTL , debe especificar la dirección de lectura de la página para cada idioma.
Si agrega dir=''ltr'' o dir=''rtl'' al elemento <body> , lógicamente debe esperar que haga las magias necesarias.
Sin embargo, realmente necesita cambiar todas las configuraciones de right e left en reglas como text-direction y el margin . También necesita cambiar las reglas como el margin: 0 10px 0 20px; al margin: 0 20px 0 10px;
El estándar W3C podría evitar este problema al permitir dos valores más para las reglas relacionadas con la dirección. En otras palabras, en lugar de -right y -left (como en margin-right y margin-left ), podrían permitir algo como lo siguiente:
div.foo { margin-near: 100px; }
/* This would be equivalent to margin-left in LTR, and margin-right in RTL */
div.bar { margin-far: 100px; }
/* This would be equivalent to margin-right in LTR, and margin-left in RTL */
En esencia, en todas las reglas / valores en los que actualmente puede ingresar una palabra basada en la dirección hacia la left o hacia la right , en su lugar, podría escribir una letra near o far .
Dadas las debilidades actuales en la versión actual de CSS, estoy buscando algunas sugerencias para simplificar la creación y el mantenimiento de las grandes aplicaciones web bidireccionales.
Desafortunadamente, CSS funciona con la noción de izquierda y derecha, y este es el comportamiento correcto. Existen herramientas que lo ayudarán a migrar CSS de LTR a RTL; una que conozco es CSS Janus , que cambiará las propiedades -left / -right, y más.
Desde que cambiaste la pregunta a una de previsión en lugar de una reflexión tardía.
No es tan lógico
Dice: "Si agrega dir=''ltr'' atributo dir=''rtl'' o dir=''ltr'' al elemento <body> , lógicamente espera que haga la magia". La magia aparentemente es convertir, "todo a la left y todo a la right en reglas como text-direction y el margin ".
Sin embargo, no estoy de acuerdo en que, en todos los casos, lo que usted desea es necesariamente un resultado lógico. Existen instancias de uso text-direction del text-direction y del margin que no están necesariamente relacionadas con la text-direction del text-direction del sitio principal. Para el margin , esto parece evidente, ya que muchas veces se puede usar el margin para alguna forma de posicionamiento de elementos que no tienen relación alguna con el texto. Esa text-direction no se volteará automáticamente puede ser menos obvia, pero aún así válida. Supongamos que uno tiene un sitio en inglés (LTR) con una cita de árabe (RTL) en él. Ahora, uno convierte el idioma principal al hebreo (RTL), pero todavía tiene la cita en árabe, que no debería cambiar automáticamente a LTR ya que sería incorrecto.
Cosas como elementos flotados, elementos absolutamente posicionados, etc. (que usan valores a la right y a la left ) pueden o no estar posicionados como están debido a la text-direction del text-direction .
Básicamente, se reduce al hecho de que cuando uno diseña un sitio que pretende ser multilingüe de manera que cambie text-direction , se debe pensar en cada etapa qué debe hacer el elemento basado en un LTR o RTL. configuración.
Lo que esto significa es, en mi opinión, CSS no tiene una debilidad. Cualquier debilidad está en la implementación del diseño.
Pura previsión humana en el diseño
Entonces, el buen método sería elegir su dirección estándar (por ejemplo, LTR) y que ese sea su plan "base" con CSS directo.
Luego, para los elementos que desea voltear debido a un cambio en RTL, codifique CSS adicional para tenerlo en cuenta, ya sea aplicando una clase al <body> para apuntar con o utilizando un selector de atributo como body[dir=rtl] . Luego, piensa en cada elemento que haces, si ese cambio lo debería afectar, y si es así, agregas css (con el selector de dirección adicional agregando especificidad a la anulación):
.someClass {
color: red;
margin: 0 10px 0 20px;
float: right;
}
body[dir=rtl] .someClass {
margin: 0 20px 0 10px;
/* kept float as right */
}
.someOtherClass {
border: 1px 10px 1px 1px;
margin: 0 30px 0 50px;
float: left;
}
body[dir=rtl] .someOtherClass {
border: 1px 1px 1px 10px; /* changed border for text */
margin: 0 50px 0 30px;
float: right;
}
Aquí es donde un preprocesador como LESS o SASS (SCSS) (Dave mencionó LESS en su respuesta) podría ser útil (vea mi actualización a continuación), pero esa es una solución que requiere previsión.
Si no quieres que el código esté lleno de exceso de CSS
Podría tener una hoja de estilo separada para el css RTL que se carga en el momento en que se determina que el sitio es esa dirección en particular. La posible desventaja de esto es que separa el código de "cambio" del código original, por lo que el mantenimiento podría ser más difícil (la buena documentación de comentarios sobre los elementos que se ven afectados por la conversión de RTL en el código principal podría compensar esto).
(ACTUALIZACIÓN) ¿Usando MENOS para ayudar?
Aquí hay un pensamiento para hacer que el proceso sea más conciso a través de un preprocesador como LESS. Este ejemplo utiliza la funcionalidad de LESS 1.4 (actualmente en versión beta).
Idea 1
- Ventaja: mantiene todos los valores cambiados a un cambio de selector.
- Desventaja: más trabajo para codificar valores en argumentos.
Construye una mezcla para aplicar el selector deseado a
.rtl(...) {
//getting the number of arguments
//(weeding out nested commas in parenthesis to do it)
//they are expected to be grouped in pairs of TWO,
//as (property, value, property, value, etc.)
@mainArgs: @arguments;
@numArgs: unit(`"@{mainArgs}".replace(//([^)]*/)/g,"").split('','').length`);
//keep everything in one selector
body[dir=rtl] & {
//start the loop at 1
.rtlPropLoop(@numArgs);
}
//loop to change all properties
.rtlPropLoop(@total; @index: 1; @prop: extract(@mainArgs, @index); @value: extract(@mainArgs, (@index + 1))) when (@index =< @total) {
//need to define all properties that could be switched
//I''ve done just four here
.setProp(ML) { //margin left
margin-left: @value;
}
.setProp(MR) { //margin right
margin-right: @value;
}
.setProp(FL) { //float
float: @value;
}
.setProp(TD) { //text direction
text-direction: @value;
}
//... define more possible values to switch
//call setProp
.setProp(@prop);
//continue loop
.rtlPropLoop(@total, (@index + 2));
}
//end loop
.rtlPropLoop(@total, @index) when (@index > @total) {}
}
Luego úselo como sea necesario en otros selectores.
.test {
margin: 0 20px 0 10px;
float: right;
.rtl(ML, 20px, MR, 10px, FL, left);
}
.test2 a span {
float: left;
text-direction: rtl;
.rtl(TD, ltr, FL, right);
}
Produciendo este código terminado
.test {
margin: 0 20px 0 10px;
float: right;
}
body[dir=rtl] .test {
margin-left: 20px;
margin-right: 10px;
float: left;
}
.test2 a span {
float: left;
text-direction: rtl;
}
body[dir=rtl] .test2 a span {
text-direction: ltr;
float: right;
}
Idea 2
- Ventaja: le permite usar una sintaxis similar a la que desea; Se podría modificar fácilmente para trabajar con MENOS 1.3.3.
- Desventaja: produce un exceso de salida css si se cambian varios valores en un selector.
Construye algunos mixins de ayuda con la sintaxis como lo que esperas en CSS
//define global variable for opposite direction
@oppDir: rtl;
//generic helper mixins used inside other helpers
//to auto flip right/left values
.flipSides(left) {
@newSide: right;
}
.flipSides(right) {
@newSide: left;
}
//specific property helper mixins
.padding-near(@top, @right, @bottom, @left) {
padding: @top @right @bottom @left;
body[dir=@{oppDir}] & {
padding: @top @left @bottom @right;
}
}
.margin-near(@top, @right, @bottom, @left) {
margin: @top @right @bottom @left;
body[dir=@{oppDir}] & {
margin: @top @left @bottom @right;
}
}
.float-near(@side) {
float: @side;
.flipSides(@side);
body[dir=@{oppDir}] & {
float: @newSide;
}
}
Úsalos para definir cerca y lejos para cada dirección a la vez
.test1 {
.padding-near(10px, 30px, 2px, 40px);
.margin-near(0, 10px, 0, 20px);
.float-near(right);
}
.test2 {
.float-near(left);
}
Produciendo este código terminado (observe la repetición de .test1 para la dirección opuesta)
.test1 {
padding: 10px 30px 2px 40px;
margin: 0 10px 0 20px;
float: right;
}
body[dir=rtl] .test1 {
padding: 10px 40px 2px 30px;
}
body[dir=rtl] .test1 {
margin: 0 20px 0 10px;
}
body[dir=rtl] .test1 {
float: left;
}
.test2 {
float: left;
}
body[dir=rtl] .test2 {
float: right;
}
Después de alrededor de cuatro años después de publicar esta pregunta, esta necesidad será resuelta por w3. https://drafts.csswg.org/css-logical/
Las propiedades que aceptan valores de palabras clave direccionales físicas (arriba, abajo, izquierda o derecha) se redefinen para aceptar también las palabras clave direccionales relativas al flujo apropiadas. En tales casos, los valores relativos al flujo se pueden utilizar en lugar de los valores físicos correspondientes. Para las propiedades que toman varias palabras clave, no se permiten combinaciones de valores relativos al flujo y valores físicos (a menos que se especifique lo contrario en una especificación futura).
Después de tres años de hacer esta pregunta, sé que veo una tendencia en el uso de vocabulario de dirección lógica en lugar de palabras de 4 direcciones.
Las propiedades lógicas de CSS ahora solucionan este problema. Palabras clave de start / end uso del modelo Flex Blink ahora admite palabras clave de start/end/before/after . ei
ul, menu, dir {
-webkit-margin-before: 1em;
-webkit-margin-after: 1em;
-webkit-margin-start: 0px;
-webkit-margin-end: 0px;
-webkit-padding-start: 40px;
}
Para obtener información adicional sobre una solución que intentó superar la debilidad usando SASS / LESS, visite anasnakawa.github.io/bi-app-sass
Yo uso las hojas de estilo de cierre, y esto es tan simple como un indicador de línea de comando.
Defino todo como LTR (usando direction:ltr donde sea necesario), luego, utilizando --output-orientation=RTL durante la compilación, obtengo el CSS invertido generado para mí. Finalmente, al determinar la configuración regional (en el servidor), también determino el CSS para inyectar en mi plantilla.
Más información sobre el cierre de LR en el cierre está en https://code.google.com/p/closure-stylesheets/#RTL_Flipping