Lo que sigue es una discusión de solicitudes de comentarios (RfC) sobre si el legado de Vector debería restaurarse como la máscara predeterminada en el sitio de Wikipedia en inglés para computadoras de escritorio.
El 18 de enero de 2023, a las 15:17 UTC, el equipo web de la Fundación Wikimedia implementó Vector 2022 como la nueva interfaz predeterminada para todos los usuarios del sitio de escritorio de Wikipedia en inglés, después de implementar un conjunto de cambios especificados por los editores que cerraron esta RfC . Esto reemplazó a Vector legacy, que ha sido la predeterminada desde 2010. Desde la implementación de Vector 2022, ha habido reacciones negativas tanto de los usuarios que expresaron inquietudes con la nueva interfaz de usuario, con quejas en Wikipedia talk:Vector 2022 como en mw:Talk:Reading/Web/Desktop Improvements. Muchos editores tampoco estaban al tanto de este cambio hasta el lanzamiento y/o no participaron en la RfC anterior. Esto planteó dudas sobre si hubo consenso para implementar Vector 2022, aunque el equipo web participó en un proceso de varios años para investigar, diseñar, recopilar comentarios e iterar sobre el rediseño.
Tenga en cuenta que los usuarios registrados pueden cambiar su apariencia yendo a la pestaña Apariencia en Especial:Preferencias . Los usuarios anónimos no tienen la posibilidad de cambiar su apariencia. Para obtener una lista de preguntas frecuentes, consulte Wikipedia talk:Vector 2022/FAQ y mw:Reading/Web/Desktop Improvements/Frequently asked questions.
Si bien la mayoría de los editores experimentados ya están familiarizados con lo que constituye un argumento sólido, esta RfC vio una gran afluencia de nuevos editores, la mayoría de los cuales son lectores que querían hacer oír su voz. Muchos de estos lectores no están familiarizados con la política de consenso de Wikipedia. Los argumentos más sólidos son aquellos basados en nuestras políticas y pautas , mientras que los más débiles son aquellos basados en opiniones subjetivas , y aquí es donde deberíamos comenzar nuestra discusión. Esta solicitud de comentarios se produjo poco después del cambio de la apariencia predeterminada, y muchos !votes se basaron en opiniones personales sobre cómo Vector 2022 era mejor o peor que Vector 2010. Si bien estos suelen considerarse argumentos más débiles, no se descartaron por completo, pero no se les dio tanto peso como a otros puntos.
Hubo un debate extenso sobre las encuestas e investigaciones presentadas por la Fundación Wikimedia (WMF) para apoyar los cambios propuestos. Si bien algunos participantes creen que las encuestas organizadas por la WMF tenían un sesgo positivo hacia la nueva apariencia (por ejemplo, eliminando las respuestas que contenían lenguaje grosero), otros vieron las encuestas como una razón para apoyar la implementación de la apariencia. Aquellos a favor de mantener Vector 2022 también comentaron el hecho de que la apariencia ha estado activa en varias Wikipedias más pequeñas con distintos grados de aceptación.
Como señalaron algunos participantes, es probable que muy pocos de los que comentan en este RfC tengan experiencia en diseño de UI y, por lo tanto, las opiniones presentadas aquí son solo eso, opiniones. Los únicos datos concretos que tenemos son los estudios presentados por algunos, que, en su mayoría, coincidieron con los cambios que trajo el nuevo Vector.
Otro punto de discordia fue el hecho de que, si bien es trivial para los usuarios registrados volver a la apariencia anterior si no les gustan los cambios, los usuarios no registrados no disfrutan de esa opción. Muchos de los que apoyaron la reversión eran editores comprensivos que lo vieron como problemático. La única refutación ofrecida a esto fue que se demostró que la nueva apariencia era, según los estudios y encuestas antes mencionados, una mejora para los lectores, especialmente debido al ancho de texto reducido.
Uno de los puntos más comunes planteados por aquellos que apoyaban la reversión a Vector 2010 estaba relacionado con todos los problemas, errores y otros problemas que aparecieron cuando se implementó la nueva apariencia. Algunos de estos problemas se conocían desde la anterior RfC , que se realizó a fines del año pasado, y la declaración final dejó en claro que la implementación de Vector 2022 dependía de que algunos de estos problemas se solucionaran de antemano. Muchos participantes vieron esto como un error por parte de la WMF a la hora de seguir nuestros procedimientos.
Durante el debate, los usuarios publicaron enlaces a tickets de Phabricator que mostraban que se estaba trabajando en muchos de los problemas de los que se quejaban. Durante el tiempo que la RfC permaneció abierta, los empleados de WMF también publicaron varias respuestas, que incluían una lista de problemas que habían abordado y que abordarían en el futuro . Estas correcciones no solo significaron que WMF finalmente logró cumplir con las condiciones del cierre de la RfC anterior, sino que también plantearon la pregunta de qué tan fuertes eran cada uno de los votos ! centrados exclusivamente en estos problemas.
Esto no quiere decir que quienes se oponían a la reversión sólo presentaban argumentos sólidos. Además de los votos de tipo "me gusta" , también hubo argumentos de hechos consumados (o falacia de los costos irrecuperables ), lo que significa que, dado que el cambio ya se ha producido, no tiene sentido volver atrás. Algunos también argumentaron que decisiones como esta están fuera del alcance de la comunidad, según WP:CONEXCEPT .
A primera vista, tenemos una clara ventaja numérica para aquellos que apoyan la reversión a la antigua apariencia, pero muchos de estos votos positivos se basaron exclusivamente en problemas específicos con Vector 2022, como el ancho de texto fijo, la gran cantidad de espacios en blanco y el uso excesivo de íconos, así como algunos problemas de accesibilidad. Otros comentaron sobre errores que encontraron al usar la apariencia. La WMF ha corregido varios de estos problemas (por ejemplo, el interruptor de ancho fijo que no persiste) y es probable que se realicen más cambios.
Teniendo en cuenta todo lo que se ha discutido anteriormente, no vemos un consenso para revertir la apariencia predeterminada en la Wikipedia en inglés a Vector 2010. Si bien aquellos que estaban a favor de la reversión tenían una mayoría numérica, sus argumentos eran relativamente débiles y los cambios de la WMF a Vector 2022 desde su implementación han abordado las preocupaciones de muchos. Dado que vemos los cambios realizados por la WMF como cumplimiento con el RfC anterior, esto significa que el acuerdo anterior se mantiene.
Con respecto a la segunda pregunta presentada en esta RfC, los argumentos presentados por ambas partes fueron muy similares a la primera pregunta, en el sentido de que a algunos les gusta el nuevo ancho limitado y a otros no. Algunos de los que apoyan un ancho ilimitado señalaron que muchos artículos contienen galerías, tablas, etc., y se vieron afectados negativamente por el nuevo ancho. Hubo mucha discusión sobre si los artículos científicos alcanzaron algún tipo de consenso sobre el mejor ancho, y ambas partes presentaron estudios con puntos de vista opuestos sobre el tema. La gran cantidad de espacios en blanco fue una de las principales preocupaciones de quienes apoyaron la reversión de Vector 2022. Dado que los argumentos son iguales en fuerza, existe un consenso aproximado para hacer que el ancho ilimitado sea el predeterminado .
Como bien sabemos, el consenso puede cambiar , y una de las sugerencias que se hicieron durante este debate fue abrir una nueva convocatoria de propuestas en seis meses, después de que los lectores y editores hayan tenido tiempo de adaptarse a la nueva apariencia. Los editores interesados deberían intentar trabajar junto con la WMF para obtener estadísticas, como encuestas adicionales, que podrían usarse como base para la nueva convocatoria de propuestas. Esto también permitiría hacer preguntas más específicas a los participantes, como cómo presentar la tabla de contenidos, uno de los cambios más polémicos en el diseño o si el ancho predeterminado debería permanecer como está o cambiarse nuevamente a un ancho fijo.
Firmado,
Isabelle Belato 🏳🌈 01:46, 16 de marzo de 2023 (UTC)
- Ingenio ( discusión • contribuciones ) 01:47, 16 de marzo de 2023 (UTC)
¿Debería Wikipedia volver a utilizar Vector 2010 como skin predeterminado? ~ HAL 333 20:32, 19 de enero de 2023 (UTC)
Nota: Esta RfC fue trasladada de Wikipedia:Bombas de agua para pueblos (propuestas) el 21 de enero de 2023, con esta edición . Las discusiones de esta página fueron trasladadas a la subpágina /Discusión el 14 de febrero de 2023, con esta edición . InfiniteNexus ( discusión ) 07:18 20 feb 2023 (UTC)
Si se abordan satisfactoriamente todas las preocupaciones descritas anteriormente [...], escribieron los editores. La WMF no ha hecho esto. En su lugar, agregó un botón que los lectores tendrían que presionar en cada página, cada vez que sigan un enlace o ingresen desde Google o naveguen a nuestro sitio. Esto es cómicamente inadecuado y me resulta difícil entender por qué los lectores realmente lo harían, en lugar de frustrarse y darse por vencidos y aceptar infelizmente lo que consideran una experiencia de visualización inferior. Como dijo 24.251.3.86 en mediawiki, es "demasiado pesado para ser útil o práctico y, como tal, básicamente podría no existir por todo el bien que hace". - Kiz o r 01:57, 20 de enero de 2023 (UTC)
Los lectores tendrían que presionar en cada página, cada vez que sigan un enlace o ingresen desde Google o naveguen a nuestro sitio.Esto es falso. El botón se mantiene, al menos para mí. Aaron Liu ( discusión ) 02:05 20 ene 2023 (UTC)
El problema es probablemente el modo incógnito, supongo que esto se implementa con cookies. No estoy seguro de si esto es un problema para los objetivos de ethos, aunque me inclino más por decir "esto es un problema". Aaron Liu ( discusión ) 02:18, 20 de enero de 2023 (UTC)
a pesar de una discusión a nivel de la comunidad que concluyó que no había consenso para tal cambio. La ONUS estaba en la WMF para convencer a la comunidad y
fracasó
.- desde el cierre de la RfC a nivel de la comunidad:
vemos el apoyo de la comunidad para implementar el cambio(aunque debe notarse que está precedido por
[i]si todas las preocupaciones descritas anteriormente se abordan satisfactoriamente, entonces). — Qwerfjkl talk 20:44, 19 de enero de 2023 (UTC)
Hay problemas de privacidad que impiden que las IP elijan una skin.
no se requeriría más RfCAaron Liu ( discusión ) 02:11, 20 de enero de 2023 (UTC)
Lamento que el menú de herramientas personales te esté causando frustración. Por curiosidad, ¿qué herramienta de ese menú usas con más frecuencia y cuántas veces por visita/sesión dirías que la usas?Nunca me he molestado en llevar un registro de cuántas veces hago clic en cada enlace, pero supongo que te refieres al menú desplegable. Fácilmente sería mi enlace "Contribuciones". De hecho, tengo un acceso directo en mi navegador, lo uso muy a menudo. No entiendo por qué alguien querría que estuviera oculto en un menú desplegable. Mencioné la lista de seguimiento en esa RfC anterior. ¿Por qué usar un símbolo en lugar de simplemente llamarla "Lista de seguimiento"? Por cierto, ¿"Frustración"? Actualmente elijo no usar V22, por lo que no me está causando ninguna frustración. ¿Cómo estás ? Supongo que estoy "frustrado" y me opongo en general a la noción de que reemplazar un texto perfectamente descriptivo con símbolos vagos y ambiguos sea de alguna manera una mejora. ¿Los símbolos están diseñados para analfabetos o lectores de mentes?
Creo que quienes cerraron la última convocatoria identificaron que la principal causa de oposición era la longitud limitada de las líneas (que usted mencionó que era su "gran prohibición").Como dije en la convocatoria anterior, justo después de la "prohibición", el problema es el ancho reducido que rompe el diseño de las tablas e imágenes, evidente en innumerables artículos, incluido el artículo que la WMF eligió presentarnos como ejemplo para esa convocatoria. La forma en que se colocan las tablas en la página en relación con las demás no tiene nada que ver con la "experiencia de lectura". Implementar una máscara que coloca incorrectamente innumerables imágenes y tablas es descuidado y descuidado. Cuando planteé esta inquietud en otro hilo, la respuesta fue esta, [1] lo que implica que la idea es que nosotros (editores habituales) arreglemos los problemas que ha creado la nueva máscara. (No tengo ningún interés en hacer eso, por cierto) DB 1729 talk 15:46, 26 de enero de 2023 (UTC)
Interrumpe activamente mi lectura y, por lo tanto, me lleva más tiempo comprender el contenido.Bueno, entonces eres una minoría de personas. No digo que no se pueda tener en cuenta tu opinión, solo digo que decidieron atender a la mayoría de las personas.
Wikipedia NO tiene otros medios para recibir informes de errores. Puede que te interese nuestro phabricator. Aaron Liu ( discusión ) 15:16 29 ene 2023 (UTC)
Las páginas web no son como las antiguas aplicaciones de los teléfonos iOS que simplemente se ampliaron para que cupieran en la pantalla del iPad, pero ese es exactamente el punto. Las páginas diseñadas de manera adecuada no deberían verse como las antiguas aplicaciones de los teléfonos iOS escaladas para caber en una pantalla más grande, pero Vector 2022 se ve así. Esa es una parte importante de la crítica de que parece que fue diseñado para un teléfono. Trynn ( discusión ) 22:23, 28 de febrero de 2023 (UTC)
tc
"hace que cada artículo parezca un esbozo". Æo ( discusión ) 15:16 21 ene 2023 (UTC)
consejos u opiniones de uno o más colaboradores de Wikipedia, como se indica en {{ ensayo }} . Es algo a tener en cuenta, pero de ninguna manera es obligatorio. — Tenryuu 🐲 ( 💬 • 📝 ) 23:55, 22 de enero de 2023 (UTC)
?useskin=vector
a la URL), pero esto no se propaga al hacer clic en los enlaces. Debería ser fácil de solucionar en mi opinión, así que hazlo. 90.231.239.98 (discusión) 10:20, 22 de enero de 2023 (UTC) "Muchos de los que se oponen a continuación parecen caer en la categoría de "es hora de un cambio", pero el cambio por el mero hecho de cambiar rara vez es algo bueno. Este no es un sitio de comercio electrónico ni de redes sociales; es una enciclopedia. Los lectores vienen aquí por el contenido del artículo, no por lo que algunos podrían llamar un diseño web de vanguardia". ¡Aplausos! Lo mismo que yo creo: parece haber más atención en la "experiencia del usuario" que en el contenido de la enciclopedia, mientras que una gran cantidad de artículos están en un estado lamentable. Æo ( discusión ) 15:49, 22 de enero de 2023 (UTC)
…
botón, lo que hace que las cosas sean más incómodas que antes sin una razón clara. Quiero decir, mira la captura de pantalla oficial : hay mucho espacio para que el botón de inicio de sesión esté a un clic de distancia.≡
botón de forma predeterminada. — python coder ( discusión | contribuciones ) 04:52, 23 de enero de 2023 (UTC) why did it take 12 years to solveWinter, I guess.
work...better in mobile than actual mobileOn a phone, I don't think that's true. On table, well, ignoring the obvious editor improvements (since this is separate from the skin and people had been using the desktop skin on mobile to edit for years), the only improvements I see that can be seen as designed for mobile is just the iconifying, which I don't have much of a gripe with on desktop either. In fact with the pagetools rollout there are content flashes and crashes on way too small screens including tablets which might actually make v10 or mineurva more desirable on mobile. Aaron Liu (talk) 02:33, 29 January 2023 (UTC)
only knowing how to handle generic code borrowed from githuban insult. Aaron Liu (talk) 23:11, 29 January 2023 (UTC)
Log in
out of . —Tenryuu 🐲 ( 💬 • 📝 ) 13:47, 3 February 2023 (UTC)when the non-avian dinosaurs roamedGood one! Aaron Liu (talk) 16:53, 3 February 2023 (UTC)
there's no catch-all fix for this, but the sidebar ToC could highlight those sections which are partially/fully visible
harder to navigate, especially for people with disabilitiesI disagree. Besides tab navigation which got better, the buttons are a lot larger than text and are easier to click on. That outweighs needing to click multiple times. Aaron Liu (talk) 14:46, 5 February 2023 (UTC)
p { max-width: 45em; }li, dd { max-width: 43em; }blockquote p { max-width: 37em; }form p, form li { max-width: none; }
it is unsalveageable and its core problems fundimentially poison it at the root, but you never actually listed what you thought were its core problems. Can you elaborate on this? I'm intrigued. Also, there is literally zero chance that a refined version of V2022 isn't deployed within eighteen months if they revert back to V2010. It'll probably be deployed by 2024. Cessaune [talk] 13:19, 9 February 2023 (UTC)
this had a consistency issue and I like the old desktop interface as it makes sense for editing on a computer and browsing articles
I WOULD NOT EVEN WANT TO USE IT ON MY PHONE Pondekuda46 (talk) 16:25, 13 February 2023 (UTC)
foundation doesn’t listen, doesn’t care, and doesn’t take it backEver heard of Wikipedia:Superprotect? Aaron Liu (talk) 17:41, 15 February 2023 (UTC)
from the readers' perspective, the sidebar is not a place for useful links. Most readers focus on the content area.This explanation makes perfect sense when you consider that editors can see translation links in the header. But only them. For the average reader, the tippy-top of the page is also not a home for useful links. Mebigrouxboy (talk) 05:30, 25 February 2023 (UTC)
ivory towercomment above is representative of the rollout process. I endorse 331dot's comment as well. ThadeusOfNazereth(he/him)Talk to Me! 21:09, 19 January 2023 (UTC)
tc
20:05, 26 January 2023 (UTC)tc
20:11, 26 January 2023 (UTC)tc
20:28, 26 January 2023 (UTC)tc
21:38, 21 January 2023 (UTC)tc
22:10, 21 January 2023 (UTC)tc
22:34, 21 January 2023 (UTC)tc
10:43, 22 January 2023 (UTC)It's objectively true that the white space serves no useful purpose.
used for the eyes' resting spots, so this claim is contentious. —Tenryuu 🐲 ( 💬 • 📝 ) 17:09, 23 January 2023 (UTC)
tc
17:20, 20 January 2023 (UTC)a pop-up window with the first few sentences of text accompanied by the infobox image (assuming there is one)is actually from a different feature which users can toggle at Preferences → Appearance → Reading preferences = Enable page previews. I believe it is enabled for unregistered users by default. —Tenryuu 🐲 ( 💬 • 📝 ) 00:12, 21 January 2023 (UTC)
This question is outside of the scope of what the community controls. See WP:CONEXCEPT.Rejecting this proposal on the grounds that it would violate WP:CONEXCEPT without the WMF claiming that CONEXCEPT applies is premature. If the WMF does make that claim then we can discuss this proposal on that basis, determining whether they are correct and if so whether an IAR exception applies, but until then we should proceed on the basis that it is subject to consensus. BilledMammal (talk) 14:57, 9 February 2023 (UTC)
encourage the WMF to implement this even if the en.wiki community disapprove. The old skin is embarrassing and backwards. The new one is better. We are not professional UI designers. See this comment by Joe Roe in the 2022 RfC also. — Bilorv (talk) 23:58, 21 January 2023 (UTC)
Should Wikipedia return to Vector 2010 as the default skin?As such the scope of the consensus that forms around this one will be as a result of the rollout of Vector 2022 a few days ago. Either a consensus will be found to keep V22 as the skin, or a consensus will be found to return to V10 as the skin, or unlikely no-consensus will be found. Sideswipe9th (talk) 01:32, 23 January 2023 (UTC)
You are cross, clearly. I kind of understand why, and I have some sympathies. But uh, my friends, the best critique we can come up with is: there hath been too much white space painted upon this veranda, and it looks like a wolf in a mobile telephone’s clothing? And now we want to burn the entire thing to the ground to prove that we have control over the sheeple? Well shoot, where I come from we call that boneheaded. If someone can show me research saying that line-length should be unlimited, or a credible design guide that says white space is bad, or find a popular text-based website that don't have a limited width, I will gladly eat my proceeding paragraphs of word pudding :)
WCAG 4 LIFE <3 <3 <3 <3 2600:1700:9FFC:34B0:3178:F130:73A8:2D06 (talk) 02:01, 23 January 2023 (UTC)
While, yes, support for going back is running higher here, the margin is far too narrow to suggest that the community is of the carefully considered opinion that a mistake has been made. If we really want a discussion like this to be seen as reflective of genuine community consensus, the right thing for those who have started this RFC to do would be to withdraw it immediately, and promise to hold it a year from now. Daniel Case (talk) 03:21, 24 January 2023 (UTC)
Why isn't it possible to use the visual editor here like in articles? Using visual editor opens up access and a voice to many more people.
no consensus for such a change, many, if not most, of the opposing views supported the change if some usability changes were done, and they are being rolled out (the right bar was rolled out just this week). Betseg (talk) 05:03, 27 January 2023 (UTC)
There have been quotes from the developers brought up elsewhere in this discussion indicating that one of the design guidelines was to bring the desktop design closer to mobile design standards.[citation needed] where?
Should I be constantly resizing my window as I go from site to site?– Of course not (and nor should you have to create an account or download an extension on every site for the same control) but if you actually believe that a particular line width is the best for your reading experience, why on earth would you need to? It seems to me that any need to contantly adjust when going from site to site can only be the result of overbearing web design, which v22 is a clear example of.
Most people aren't aware of the readability improvements from shorter lines...so I guess it's your duty as a web developer to take their ability to read in a certain way away from them, for their own good, of course? I find this attitude very worrying.
Data from Fandom indicates they see little use of their full-width toggle (less than 1%). I expect we will see similar results here too.I read
a mechanism [must be] available to achieve the following: [...] Width is no more than 80 characters or glyphs (40 if CJK).It seems to me that this requirement is automatically fulfilled by the native mechanism (window resizing) unless the site has styling that obstructs this method. In any case, it is possible to provide a non-native mechanism for this within v10 without forcing it on users by default. small jars
tc
17:34, 29 January 2023 (UTC)"People hate change [...] Anytime we changed anything, there would be an outpour of negative feedback. This would mostly dissipate after the initial launch [...] Neigh sayers are usually the vocal minority, and will adapt"; this is quite stereotypical (and I see it has been repeated in many opposing comments) and disrespectful of critical views, which in many cases are very thoughtful considerations. I agree on
"how disassociated that side menu is from the content"; please see #Bring back the TOC. Æo (talk) 17:01, 30 January 2023 (UTC)
The majority of respondents reported that the new experience is easier to use or that the new and old experience are equally easy to use.The statement was true, but incredibly misleading; 60 users found Vector 2010 easier to use, 49 found Vector 2010 and Vector 2022 equally easy to use, and just 37 found Vector 2022 easier to use. BilledMammal (talk) 18:20, 6 February 2023 (UTC)
focusing on the text rather than having tons of useless wikigeek links on the side– Would we have that text in the first place without "wikigeeks"? The tools for improving Wikipedia should be exposed to every reader. Your comment only serves to demonstrate that v22 promotes a wikiconsumerist attitude and discourages boldness. small jars
tc
15:59, 26 February 2023 (UTC)"But I cannot deny that Vector 2010 is... well, very 2010. Wikipedia should evolve with the times, content wise but also in terms of UI and looks."I personally find the mobile-esque V22 to be more awkward and clumsy than V10, which in turn is wieldy and sleek. Evolution is not always in the right direction, and may sometimes turn out to be an involution. Æo (talk) 14:49, 1 March 2023 (UTC)
tc
17:38, 20 January 2023 (UTC)tc
16:20, 20 January 2023 (UTC)Only UI designers are qualified to objectively evaluate the merits of thisOnly artists can critique art, only game developers can critique games, movie directors can critique movies, writers can critique books, and so on. The general user who has to experience that has no say at all? Apple is only limited width for a section, google uses full width at 1080p when you search(and their email is always full width), nyt and wapo uses much more as well. Wikipedia is the most constricted version of any I have encountered, and has no mechanisms for using that extra space either, even fandom will fill the voids at the edges with wiki-art and ads. At ratios higher than 16:9 1080p, it becomes a tiny island in a sea of blindingly bright whitespace, with a practically invisible toggle that doesn't even work when logged out nestled in the corner of all that whitespace. Deadoon (talk) 11:45, 20 January 2023 (UTC)
Most users don't resize their browser windows or use browser plugins to improve the design of the websites they view. Wikis should be good-looking immediately, in their basic form.Aaron Liu (talk) 15:31, 20 January 2023 (UTC)
If you prefer full width, there's a button to toggle that.
The groups seems quite small (~20 participants per group), especially that it was a questionnaireMost studies sadly, regardless of field, tend to have small groups. It's often expensive to get funding for larger groups, which puts them out of reach of many researchers. The major exception that I'm aware of is clinical trials in medicine, which can have group sizes in the low to mid hundreds.
em
units, there's no exact mapping from em
to CPL, as the rendered size of 1em
is relative with regards to the font-size
being applied to the element, but it is not relative with regards to font-family
. By default (ie, no font-size
override set) 1em
is the equivalent of 16 pixels on the user's device, regardless of what font-family
they are using.ch
value for max-width
or min-width
. That unit is always relative in size to the 0
glyph of the font-family
that is being used to render the output on a user's device. Theoretically there's no technical reason why the WMF couldn't expose a setting to both logged in and logged out editors that would directly and accurately allow them to set an exact number of CPL, by giving them direct control of the ch
value which is applied to the relevant max-width
properties. The only real "gotcha" to watch out for with ch
values is that some fonts like Helvetica or Georgia do not have fixed-width characters, so you will on occasion get uneven line justification. But again, the font-family
could be exposed as a setting to the user, which gets applied at rendering time. Exposing either or both of these settings will not affect page caching, because CSS interpretation and rendering is always done on the user's device. If the WMF have considered this as an option though, and ruled it out, I would be interested to know why, as I've not seen it discussed on either of these two RfCs.ch
value for max-width
, and font-family
value), similar in style to the patch being trialled by Jdlrobson in phab:T91201, that gives the user (whether logged in or out) direct control over the maximum number of characters per line. This would be instead of or supplementary to the straight on/off toggle for limited content width. This allows non-technical users to easily set an exact line length dependent on their needs, in a unit that is relative to the font being used to render the content.There is just one thing to change and you are done.Ok, pretend for a moment you've never made a website before, maybe even never programmed anything before. How do you know there's a property to change that will fix the problem you are having? How do you know what that property is? How do you know what value to set that property to? Assuming you can figure out that there is a
max-width
property you can set, how do you make sure that you're only overriding it for the main content area, and not any of the other defined areas on the site like the TOC sidebar or header? How do you know that HTML tags have optional class or ID parameters? How do you know how to limit your max-width
override to the specific subset of classes and IDs that only affect the primary content area?These decisions shouldn't be based on the personal design preferences of a small fraction..." describes the shift to V22 as the default pretty well. Tim O'Doherty (talk) 15:51, 25 January 2023 (UTC)
could vote-> could vote in a way that is binding. And if it is not, as that is the de facto state of the large rfc, there is no reason for this to 'double up' a previous, wider consensus. — Ixtal ( T / C ) ⁂ Non nobis solum. 14:44, 20 January 2023 (UTC)
Debido a la gran extensión y tamaño de esta página, las discusiones se han movido a una subpágina y solo se han mantenido sus títulos a continuación como una lista.Por favor, agregue nuevos comentarios en la subpágina y no debajo.Gracias.
Referencias