Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

the user interface's language should not be derived from the body element #895

Closed
janiceshiu opened this issue Jan 23, 2020 · 3 comments · Fixed by #896
Closed

the user interface's language should not be derived from the body element #895

janiceshiu opened this issue Jan 23, 2020 · 3 comments · Fixed by #896

Comments

@janiceshiu
Copy link
Contributor

From the payment request spec,

payment-request/index.html

Lines 1094 to 1097 in fe208db

of the user when presenting payment methods. It is RECOMMENDED that
the language of the user interface match the [=node/language=] of the
<a data-cite="HTML/dom.html#the-body-element-2">the body element</a>
element.

The body element's definition states "The body element of a document is the first of the html element's children that is either a body element or a frameset element, or null if there is no such element."

Thus,

  • <body> is a node can can have a language
  • <frameset> is a node
  • null is not a node and cannot have a language.

In this PR, @annevk states

I'm not sure I support the use case. Other APIs, e.g., the notification API, have no such defaulting and have explicit support for language annotation. And especially for the frameset case it seems that it's highly likely it might not match the language of the application anyway.

Thus, the user interface's language should not be derived from "the body element". The spec could probably include explicit support for language annotation the way the notification API does it.

cc @marcoscaceres
@marcoscaceres
Copy link
Member

Agree, we should drop this requirement as I don't think anyone implements this. It should just be noted that, by default, payment sheet will use the browser's default language.

In future version of the spec, we should add {dir: "", lang: ""} members to either the PaymentDetailsInit or to individual PaymentItems. Not sure yet what the right level of granularity should be. I think we discussed something similar a few years ago... we should do some archeology.

@marcoscaceres
Copy link
Member

marcoscaceres commented Jan 24, 2020 •
edited
Loading

Dug up:

@marcoscaceres marcoscaceres mentioned this issue Jan 24, 2020
Merged
1 task
@marcoscaceres
Copy link
Member

Sent PR: #896

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Remove recommendation to localize sheet based on body element w3c/payment-request
2 participants
@marcoscaceres @janiceshiu