[i18n-activity] Short_but_informative_title_here (#1472)

r12a has just created a new issue for https://github.com/w3c/i18n-activity:

== Short_but_informative_title_here ==
## Proposed comment

2.2.1. Detecting Word Boundaries: the [word-boundary-detection](https://www.w3.org/TR/css-text-4/#propdef-word-boundary-detection) property

> [<lang>](https://www.w3.org/TR/css-text-4/#typedef-word-boundary-detection-lang) must be a valid CSS [<ident>](https://www.w3.org/TR/css-values-4/#typedef-ident) or [<string>](https://www.w3.org/TR/css3-values/#string-value). It represents an IETF BCP 47 language range (see [[BCP47]](https://www.w3.org/TR/css-text-4/#biblio-bcp47)). If the UA does not support word-boundary detection for all languages represented by the specified range, that specified value is invalid (and will cause the declaration to be ingored).


I think the language information used should be that provided by the `lang` attribute, and not supplied as a parameter with this property value.  The choice of whether or not to apply the word boundary detection algorithm for a dialect should be a choice of the user agent.

I don't think the content author is able to guess what languages are supported by the user agent, so it doesn't seem useful to make them specify language in the property value.  I think that the approach currently described in the spec also requires the content author to have a level of understanding about language tagging that is too high (see the examples about Cantonese). 

I also think that it is odd to use a range of languages, rather than base decisions on the actual language in question (which is what `lang` gives you).

Instead, we should have a simple recommendation that user agents SHOULD NOT apply a boundary detection algorithm to text in a language for which the algorithm is not defined (modulo decisions wrt dialect support).




---
## Instructions: 

This follows the process at https://w3c.github.io/i18n-activity/guidelines/review-instructions.html

1. Create the review comment you want to propose by replacing the prompts above these instructions, but **LEAVE ALL THE INSTRUCTIONS INTACT** 

2. Set a label to identify the spec: this starts with s: followed by the spec's short name. If you are unable to do that, ask a W3C staff contact to help.

3. Ask the i18n WG to review your comment.

4. After discussion with the i18n WG, raise an issue in the repository of the WG that owns the spec. Use the text above these instructions as the starting point for that comment, but add any suggestions that arose from the i18n WG. In the other WG's repo, add an 'i18n-needs-resolution' label to the new issue. If you think any of the participants in layout requirements task force groups would be interested in following the discussion, add also the appropriate i18n-\*lreq label(s).

5. Delete the text below that says 'url_for_the_issue_raised', then add in its place the URL for the issue you raised in the other WG's repository. Do NOT remove the initial '§ '. Do NOT use \[...](...) notation – you need to delete the placeholder, then paste the URL.

6. Remove the 'pending' label, and add a 'needs-resolution' tag to this tracker issue. 

7. If you added an \*lreq label, add the label 'spec-type-issue', add the corresponding language label, and a label to indicate the relevant typographic feature(s), eg. 'i:line_breaking'. The latter represent categories related to the Language Enablement Index, and all start with i:.

8. Edit this issue to **REMOVE ALL THE INSTRUCTIONS & THE PROPOSED COMMENT**, ie. the line below that is '---' and all the text before it to the very start of the issue.

---


**This is a tracker issue.** Only discuss things here if they are i18n WG internal meta-discussions about the issue. **Contribute to the actual discussion at the following link:**


§ url_for_the_issue_raised


Please view or discuss this issue at https://github.com/w3c/i18n-activity/issues/1472 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 15 February 2022 16:14:24 UTC