Re: [public-personalization-tf] <none>

Hi Lisa,

I remain quite concerned about this - it is completely missing the point of
our attributes and token terms, which is simply to furnish
unambiguous, *machine-readable
identifiers for page elements* - including form inputs - but for much more
than just that.
THEY HOWEVER HAVE NOTHING TO DO WITH THE FORM'S OUTPUT!

Thinking this through yet again, one of the principle benefits we've often
noted is that with these terms, we can output/convert (for example) the
form label to use an icon (instead of text). Why then do we insist that for
this one specific token we *also *insist that the output matches a specific
format?

*Our attributes are NOT for specifically filling out forms*, but rather
these @purpose attributes are *for machine-labelling the inputs*. The
"output" is content negotiated by the form owner and the individual user
(in any language, and in any format the form owner wants or needs), and I
continue to argue, IS outside of the scope of our specification. If the
form owner needs/wants the language in an ISO code, they can create their
form to support that (use a drop-down select) - if they are less concerned
about the format of the form response(s), they can certainly ask for a text
string - why would our spec impose a response in a specific format when the
form author neither needs or wants that?

Returning to the WHAT WG HTML5 spec
<https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofilling-form-controls:-the-autocomplete-attribute>,
and reviewing the @autocomplete values (the original source of our terms
for @purpose), and I note that there is a similar and somewhat related
issue with "country" and "country-name", where "country" must also take "...
*Valid **ISO 3166-1-alpha-2 country cod*e
<https://www.iso.org/iso-3166-country-codes.html>" but "country-name" takes
"..*.**Free-form text, no newlines;*" yet for language they only have
"language" but not "language-name". None-the-less I continue to argue that
this is closer to what we want, and so one way forward is to NOT have an
attribute value of 'language', but instead have a (NEW) attribute value of
"language-name" with no requirements on the output. (Yes, it is more
verbose for no practical reason, but it may get us around any confusion
about what we are attempting to do with our spec - which is NOT to pre-fill
form outputs. Content authors can also use @autocmplete to do that.)

Finally, a review of our current spec sees both country and country-name as
additional @puropose, and I would also now propose we remove one of those
(country) and leave just the country-name value, for exactly the same
reasons used for 'language'.

JF

On Sun, Apr 11, 2021 at 1:35 PM Lisa Seeman <lisa1seeman@gmail.com> wrote:

> HI
>
> I saw in the minutes that we are proposing the following note:
>  Personalization notes that there is ambiguity regarding the formatting of
> language: i18n requested adherence to BCP47 but there is a strong opinion
> that such adherence would restrict user activity unnecessarily
>
> Can we say something more diplomatic such as: Personalization notes that
> there is ambiguity regarding the formatting of language. We recommend
> authors also confirm BCP47 in cases where this would not unnecessarily
> restrict user activity.
>
> All the best
>
> Lisa
>
>

-- 
*John Foliot* | Senior Industry Specialist, Digital Accessibility

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"