Meeting minutes
Timeline - https://github.com/w3c/personalization-semantics/wiki/Timeline
<LisaSeemanKest> can we add cost grant to the agenda
sharon: Seems some deadlines may need to be pushed back slightly; is there a specific process to follow?
janina: Best to keep APA updated (which we are doing as-and-when). Can raise in APA meeting if need be.
LisaSeemanKest: Can we add to the agenda: if there might be funding to help young researchers get to face-to-face?
janina, CharlesL: W3C has announced there'll be no face-to-face TPAC this year.
Lionel_Wolberger: regarding TPAC, should we start preparing; put it on the agenda? [Some approval; no objections]
zakin, next item
New I18N issue #175 - https://github.com/w3c/personalization-semantics/issues/175
<Zakim> JF, you wanted to comment on Issue #175
sharon: This relates to discussion we had last week?
<JF> <form lang="he"> <label for="foo" dir="rtl">מהי שפת האם שלך</label> <input type="text" purpopse="langauge" id="foo" dir="rtl"> </form>
JF: [Responded via GitHub with code examples last week]
JF: The purpose of the attribute is to identify the purpose of the control; not the language on the screen.
janina: [Responded on-list] https://
<janina> ma: Don't believe i`18n is misunderstanding
<janina> ma: Believe they want us to ensure that any value the user inputs will be a valid value
<janina> ma: From our perspective that would be up to the ua
<Lionel_Wolberger> Re: Matthew_Atkinson comment, mozilla writes: ""language" A preferred language, given as a valid BCP 47 language tag."
JF: We shouldn't require the user to know the language code—this is a free text field and whatever the user wants to enter should be accepted.
<JF> http://
JF: The language form control on this autocomplete-able form will look up the value the user stored on their machine.
becky: Can we solve this by saying that we expect the value could be converted into a language code?
<Lionel_Wolberger> Sees Chromium (chrome browser UA) has the BCP codes in this autofill (autocomplete) file, https://
<Lionel_Wolberger> s/sutfill/autofill
Matthew_Atkinson: Maybe we have to stick to mentioning the code because this is what the shared WCAG/W3C definition for this autocomplete purpose prescribes? Then it's up to the UA/app to map to a code. Is this a clear-cut spec consistency issue?
JF: The purpose is to capture something from the user, it could be anything (including Klingon, e.g.)
<JF> <input type="text" purpose="language" value="klingon">
janina: To what end are we asking the browser to collect this data? Is it really going to be a free-form text field. Do we need another vehicle for collecting the data? [cited examples in various OSes in list post]
janina: If we are collecting something; we need to say _why_.
<JF> we are not collecting *anything* - we're annotating the purpose of the text input
janina: Also think that i18n is concerned about consistency and valid designations for the collected language (in which case it's the UA's responsibility).
becky: Just checked the WHATWG spec and it should be a valid BPC47 language tag (and has a format of text). Agree with JF, but if the spec is saying it should be a language tag, we need to as well.
becky: As with Matthew_Atkinson's concern, we need to check the WCAG autocomplete definition.
<JF> <input type="text" purpose="language" value="klingon">
JF: We're not collecting anything; the author of the form is collecting the information. Name, email, language, all can be random strings. The form is collecting the info; the form has a language but that is separate from the language being entered by the user.
JF: With the autocomplete feature, the form can be pre-filled. Klingon uses an odd character set, but we could write "Klingon" (in English) as the value for the language field.
<JF> <form lang="he">
JF: In this form, the input will be in Hebrew, so the user could write that their languge is Hebrew _in Hebrew_.
CharlesL: +1 to JF; seems i18n may be missing the purpose of the form.
CharlesL: Let's have a joint call with i18n to explain what we're trying to do.
becky: I still agree we're only asking for the user's language; but the "purpose" values in the HTML spec says the value of the field with a "purpose" of "language" should be a valid BCP47 code.
becky: Maybe the browsers are doing it wrong, but this is out of the scope of our spec.
<Lionel_Wolberger> +1 Charles, John: this label, 'language', is meant to be handled by the User Agent, if the user stored a 'language' as a default. We see that Mozilla is storing it as BPC47. But Chromium or Edge may store it differently.
<Zakim> JF, you wanted to propose filing a bug against WHAT WG spec
janina: +1 to Becky. We don't need to be too concerned about this; it will come up rarely. To make the value useful, we would make sure it wasn't free-form. Don't need to have a call with i18n.
JF: Bug in HTML spec—we should not expect users to know what their language code is.
janina: Could have a list where the languages are presented in user-friendly format, written in the respective languages, and the app will map to the BCP47 code.
JF: If all of the form is written in Chinese, then all the language values would be written in Chinese so that the Chinese user could read them.
JF: This means the only way to collect this info is as a <select> but what about free text? And languages that don't have a valid code.
<JF> @Charles, correct, but we cannot limit authors on HOW they collect the user's preferred language
CharlesL: <select> is a valid option; so is free-form. We're talking about one level up from the control being used; we're just talking about the purpose of the field. One level up from the mechanics of how we gather the info.
<JF> +1. @purpose is machine-readable code that furnishes a "hint"
becky: So we can add a reminder that it _should_ be a BCP47 code, (en, en_GB, en_US, en_CA, ...) but we can leave it at that.
becky: ACK that this is here to help the user by pre-filling.
JF: These attributes will allow things to be presented in different modalities (icon instead of text, e.g. an envelope icon instead of "email address").
JF: so it comes even before pre-filling the form; it's a hint to the UA.
JF: Validator doesn't raise an error when a free text field is marked up as haivng a purpose of "language"
https://
JF: [will file an issue on HTML]
sharon: Next steps? Consensus we're looking for is who's in agreement regarding the BCP47 code? Or can we put a note that any text is valid?
janina: adding a note should satisfy i18n; their concern is about consitency across specs, so a note to clarify that when such a thing shows up in a form, the UA is responsible for making sure the value stored conforms to BCP47, however it's represented on-screen.
<JF> https://
<CharlesL> +1 to waiting for i18n responce
JF: Can we wait to see how i18n response to my response first?
+1 to waiting for i18n's response
<sharon> +1
janina: agree; could ask a clarifying question as to what their concern is.
sharon: Shall we wait one more week?
janina: OK to wait one more week; need to ensure we each understand eachother.
<CharlesL> +1 for waiting a week.
Oops; had not moved Zakim forward; apologies!
Issue 79 - https://lists.w3.org/Archives/Public/public-personalization-tf/2021Mar/0025.html (John)
janina: looks good to me
JF: our code example has spaces around the "+" sign but because we're doing space-separated values, this could introduce some ambiguity.
JF: [details from research are in the linked post]
JF: Recommend not having spaces around the "+" symbol.
+1
becky: +1 - adding a space makes the parsing harder
janina: +1 - consistency with other W3C specs clinches it
JF: In HTML and derivatives, e.g. ARIA, this is how it works. (I.e. not commas)
sharon: Looks like everyone's agreeing. Next steps?
JF: Make a change to the draft spec.
janina: +1
<becky> +1
JF: [will make a PR]
CharlesL: +1; will review
Action: : JF to make editorial change to remove spaces on either side of "+" symbol - and create pull request
2 new values for distractions https://lists.w3.org/Archives/Public/public-personalization-tf/2021Mar/0020.html (John)
JF: This arose from a conversation on an ARIA issue in GitHub. [details in the post linked above]
JF: Relates to images that convey a mood; may not be directly related. Therefore: two types of decorative image: one that is purely decorative and one that enhances the mood.
<Lionel_Wolberger> Matthew_Atkinson: The issue seems related to how distracting or essential the content is
Matthew_Atkinson: wondering if we should consider both approaches (not sure either way)
becky: Not sure if it is needed, but if it was picked up by ARIA we could use it.
JF: Whether it's via @distraction or @simplification, this is adding an additional level of granularity.
JF: There are images that are decorative but can add some value to the page.
Lionel_Wolberger: +1 to this being fascinating, and we deal with this a lot, particularly with catalogue sites. ARIA feels like it could be the right place.
<CharlesL> 1+ not in 1.0 :)
janina: Not sure if this is a 1.0 issue; ARIA is screen-reader only; Zoom lets you choose skin tone of thumbs-up/-down.
sharon: We'll continue next week.