Meeting minutes
Go through the issue list
https://
w3c/clreq#616
huijing: unlike text, vertical form controls are a kind of UI without precedent
huijing: Many design issues remain unresolved
xfq: Blink and WebKit support vertical form controls now
xfq: Do we need to write about the behavior of vertical form controls in clreq? There's some information in mlreq, for example.
<huijing> https://
huijing: what about Japanese?
[Discuss w3c/
xfq: the select element in HTML is different in vertical writing mode
… we should probably mention this kind of menu in clreq
Eric: Regarding clreq issue #500, can we tell browser vendors that Chinese is from top to bottom and Japanese is from bottom to top?
huijing: Currently Firefox and Chrome's implementations are opposite
… one of them needs to change
Eric: Is there a consensus between Chinese and Japanese? If not, then we should deal with it separately according to the language.
Zhengyu: I think this is not a typography problem, it is a UI design problem. Even in the English world, there are vertical progress bars.
Zhengyu: There is no necessary connection between the direction of the progress bar and the surrounding writing mode.
xfq: Even so, we still need a default direction, but we can allow authors to manually control the direction.
Zhengyu: But I still think this is not a "layout requirement". This may be a thing that needs to be considered in the internationalization of the layout engine, but it has little to do with text layout itself.
… see w3c/
… In vertical Chinese text, there will be horizontal progress bars
… We can't force the progress bar to display vertically
… The direction of the progress bar should not be strongly correlated with the text writing mode
… Regarding the default direction of bars in HTML progress, meter & input=range elements under vertical writing mode, I think this is not a problem of Chinese layout requirements, but a higher-level problem.
xfq: Back to clreq #616, I think we can at least write some related requirements, such as this: in vertical writing mode, popping up the menu options from right to left is better than popping up from top to bottom.
huijing: We can mention the vertical form controls that have text within them.
xfq: OK
Zhengyu: OK
Eric: OK
Zhengyu: Regarding `input type=checkbox switch`, I also doubt whether we should rotate it in vertical writing mode.
Zhengyu: switches do not necessarily rotate according to the text writing mode
Eiso: Do klreq folks have any comments?
xfq: I don't think we have asked them yet
… Chinese, Japanese, and Mongolian have greater demands
… but we can ask them
huijing: we can add some text about select first
xfq: The buttons should rotate too?
Zhengyu: yes, because there's text in it
… The pop-up direction of the select element depends on its position on the page. If the element is on the left end of the page, it should pop up to the right. If it is on the right end of the page, it should pop up to the left. If it is in the middle of the page, it can pop up to the left or right.
xfq: At least it shouldn't pop downwards.
Bobby: by the way, about <input type="date">, it would be useful to to be able to specify the format of the numbers, and whether the numbers are half-width or full-width. Currently this is not possible.
Zhengyu: Currently it seems to be bound to the browser's language preference
… and it is sometimes inconsistent with the page language
… I don't know if it's a feature or a bug
Bobby: I added a comment in w3c/
Zhengyu: This will cause a problem: the internationalization status of the date component is separated from the internationalization status of the whole page.
xfq: we can discuss this in the i18n WG
[Discuss which section this should be placed in]
xfq: we have unified the document structure of other lreqs
xfq: like this https://
huijing: Is this mentioned in jlreq?
xfq: no, not for now
huijing: maybe a new section
xfq: section 5?
huijing: regarding https://
… I think "Forms & user interaction" should be section 10, instead of section 9.4
xfq: I agree
Zhengyu: agreed, I don't think "Forms & user interaction" is related to "Page & book layout"
xfq: I can discuss this with Richard
Eric: agreed
… I think the rest is well organized.
… clreq can probably adopt this structure, except the "Forms & user interaction" part, which should be a new section
… what do you think?
huijing: agreed
Zhengyu: about section 9, I think Page layout and book layout should be two different sections
Zhengyu: Page layout can be applied to web pages, but book layout is more independent
… and "Forms & user interaction" should not be in this section
https://
Bobby: it looks like dpub-latinreq hasn't been updated
xfq: I will contact the relevant people about this
… it's not in the i18n WG
Eric: I will go to Taipei in July
w3c/clreq#593
[xfq introduces the issue]
Eric: It's a chicken-and-egg question
… because there's no good support for Kai and Fangsong generic font families
[Discuss how to push the implementation of new generic font families]
Eric: I'll reply and close the issue
Next teleconference time
June 26 (Wednesday), 19:00-20:00 (UTC+8)