Autor: Gonzalo

Categorías
Open Data Web Semántica

El manual de datos abiertos (Open Data Handbook)

Aprovechando las circunstancias, estoy volviendo a retomar mi interés por la Web Semántica, o como se llama ahora, Open Data 🙂

Mi objetivo es que el cliente en el que estoy publique datos abiertos e intentar que sean buenos. Estoy desarrollando un vocabulario controlado (inspirándome mucho en Dublin Core), utilizando algunas herramientas que desconocía y, en definitiva, volviendo a estar entusiasmado por la manteria.

Lo que quería recomendar es un recurso divulgativo bastante bueno: Open Data Handbook. Se trata, como su nombre indica, un manual de datos abiertos, con la ventaja de que está traducido a bastantes idiomas, entre otros el castellano.

Creo que su lectura puede clarificar posibles dudas o lagunas sobre los datos abiertos, y pueden surgir ideas interesantes. A mí me está siendo muy útil, de ahí que lo recomiende.

Post ScriptumA la hora de escribir estas palabras, estamos confinados en casa por el desgraciadamente conocido COVID-19. Ánimo a todos.

Categorías
Desarrollo web

Comparativa de frameworks front-end

Antes de empezar, una confesión: como en los clientes en los que he trabajado siempre se ha restringido el acceso a node.js y creo que eso me ha ahorrado una nada despreciable cantidad de horas de probaturas.

Pero, para los que tengan tiempo y ganas para investigar, o al menos tengan curiosidad para ver algunas alternativas que hay, puede dar un vistazo a A RealWorld Comparison of Front-End Frameworks 2020.

Categorías
CSS

Metodología BEM: Block, Element, Modifier de CSS

La metodología BEM fue desarrollada por el equipo que trabaja en yandex (una empresa de tecnología de origen ruso).

El objetivo principal de la metodología es mejorar la organización de CSS utilizando una nomenclatura para los nombres de clases compuesto por:
* El nombre del bloque HTML
* El elemento dentro de ese bloque
* Un modificador, que define la apariencia, estado o comportamiento.

Veamos un ejemplo (adaptado de la documentación oficial):

<!-- bloque `search-form` -->
<form class="search-form">
    <!-- elemento `input` element del bloque `search-form` -->
    <input class="search-form__input">

    <!-- elemento `button` del bloque `search-form` -->
    <button class="search-form__button">Buscar</button>
</form>

Ventajas:

  • Ofrece un sistema para organizar y nombrar clases.
  • Permite trabajar de forma coordinada y asíncrona a los miembros de un equipo.
  • Permite conocer de un vistazo la estructura, tanto del documento HTML, como de las clases CSS.
  • Permite evolucionar y modificar elementos con facilidad (creando clases de modificadores)

Inconvenientes:

  • Hay que ajustarse a las normas y reglas de la metodología.
  • La cantidad de clases utilizadas puede ser más elevada que otras alternativas.
  • La teoría de que cambiando una clase se cambia el aspecto de una web, no aplica aquí: para ser coherente hay que crear clases que modifique el aspecto de los elementos, y añadirlos al código HTML.
Categorías
CSS

Aprender de una vez posicionamiento CSS

Ahora hay más alternativas en CSS, pero una de las cosas que más me ha costado aprender es el posicionamiento CSS.

Bueno, pues hay un simpático tutorial para refrescar, o aprender de una vez: Learn CSS Positioning.

Categorías
accesibilidad recomendaciones W3C

WCAG 2.2: publicado el primer borrador de trabajo

The Accessibility Guidelines Working Group (AG WG) has published a First Public Working Draft of Web Content Accessibility Guidelines (WCAG) 2.2. WCAG provides recommendations for making web content more accessible to people with disabilities. It addresses accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines also makes your web content more usable to all users in a variety of situations.

FIRST PUBLIC WORKING DRAFT: WCAG 2.2

¿Qué ha ocurrido? La Iniciativa de Accesibilidad Web, del W3C ya está trabajando en una nueva versión de las Pautas de Accesibilidad Web, la 2.2. Puedes encontrar el actual borrador de trabajo en Web Content Accessibility Guidelines (WCAG) 2.2. First draft y la actualización más reciente de la versión en Web Content Accessibility Guidelines (WCAG) 2.2. Last version.

WCAG 2.2 was initiated with the goal to continue the work of WCAG 2.1: Improving accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices. Many ways to meet these needs were proposed and evaluated, and a set of these were refined by the Working Group. Structural requirements inherited from WCAG 2.0, clarity and impact of proposals, and timeline led to the final set of success criteria included in this version. The Working Group considers that WCAG 2.2 incrementally advances web content accessibility guidance for all these areas, but underscores that not all user needs are met by these guidelines.

WCAG 2.2: Comparison with WCAG2.1

Novedades de las WCAG 2.2

¿Qué nuevas características trae las WCAG 2.2? Un nuevo Success Criteria o criterio de conformidad:

Success Criterion 2.4.11 Focus Visible (Enhanced)

When a User Interface Component displays a visible keyboard focus, all of the following are true:

  • Minimum area: The focus indication area is greater than or equal to the longest side of the bounding rectangle of the focused control, times 2 CSS pixels.
  • Focus contrast: Color changes used to indicate focus have at least a 3:1 contrast ratio with the colors changed from the unfocused control.
  • Contrast or thickness: The focus indication area has a 3:1 contrast ratio against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS pixels.
Note

A focus indicator that is larger than the minimum area may have parts that do not meet the 3:1 contrast ratio, as long as an area equal to the minimum does meet the contrast ratio.

WCAG 2.2: Success Criterion 2.4.11 Focus Visible (Enhanced)