Selection.direction spec issue, what should happen on multiple click?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- html
- Área
- web-dev
Línea de trabajo
Start with the Selection.direction definition in the linked Selection API specification and read the referenced Bugzilla discussion. Compare the proposed boundary-point interpretation with the reported double- and triple-click cases. Done means the specification explicitly defines the direction for multiple-click selections and the project reaches agreement on the wording.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Based on the documentation, it only specifies the Selection.direction based on the position of the boundary-points.
(...) first indicated boundary point is after the second, then the corresponding selection must initially be backwards. If the first indicated boundary point is before the second, then the corresponding selection must initially be forwards. Otherwise, it must be directionless.
The spec does not mention what should happen in case of double or triple click, when a whole word/line is selected.
The Mozilla's position is that the direction should be "none" in case of double-click, since it does not involve any direction.
Bugzilla: Selection.direction's value is incorrect
My opinion is that the direction would be useful if its value were calculated based on the positions of the boundary points, because I don't see any advantage of knowing whether the selection was made by mouse dragging or multiple-click.
- Lenguaje dominante
- HTML
- Estrellas
- 49
- Forks
- 30
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de w3c/selection-api
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
w3c/selection-api#354 ·
-
Agenda+
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
w3c/selection-api#361 · 2 comentarios ·
-
Remove single range restriction for selection interface apisQuizá libre de nuevo @sambandaru la tomó hace 140 días y no hay ningún pull request abierto. Abierto
w3c/selection-api#358 · 2 comentarios · 1 asignado ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
w3c/selection-api#355 ·
-
the steps of Selection.extend() does not check whether the given offset is valid in the containerAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 55/100
w3c/selection-api#353 · 1 comentario ·
Todos los issues de w3c/selection-api
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
openlibhums/janeway#5604 ·
Los mantenedores suelen responder en 1 día
-
fix(ui): say the connector edit sheet drops the stored secret when the endpoint moves originAbiertobug observability station:mac ui-dashboard
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
Unable to select the sectionAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Simple presets ignore a feedback's affectedProperties and add a deprecated imageBuffers layerAbiertoBUG
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
PostHog/posthog.com#20628 ·
Los mantenedores suelen responder en 1 día