JLreq TF meeting notes 11/02

https://github.com/w3c/jlreq/issues/314 <https://github.com/w3c/jlreq/issues/314>

Attendee

bin-sensei, kobayashi-san, murakami-san, murata-san, tahara-san, tajima-san, kida

Miscel

Recommended reading by Bin-sensei:「インターネットは言葉をどう変えたか (Because Internet - understanding the new rules of language, Gretchen McCulloch 2020)」

Updates on ruby T2S discussions at TPAC (Murata-san)

Right now T2S on text containing ruby is disastrous. Most readers read both the base and ruby which can alter the meaning or making it un-interpretable. Murata-san developed a proposal for two roles for ruby to improve its accessibility on the web and discussed it at ARIA and I18N WG.

ARIA WG

He believes the proposal was well accepted. There was a discussion re: if the roles should be ARIA’s roles or attributes in HTML. It was leaning towards HTML as they can be useful for other areas.

I18N WG

There was a discussion regarding if the note should be I18N’s or joint with WAI (web accessibility initiative group). Operational matters.

JDLReq goals, contents, and how we proceed

Name

Tentatively JDLReq. Is it Japanese Digital Layout Requirements? Also, probably we want to discuss if it is Req or Rec, requirements or recommendations.

Goals

Kida explained that the text he wrote for the APL report (attached in JLReqTF email on 11/1 title “JDLReq 内容案”) describes his vision well. There was an overall agreement on the vision. The discussion will be kept open as sharing the same vision is important in creating the JDLReq together. Based on it Kida will develop a paragraph that will be placed somewhere early in the document (but it will be done after end of Feb as he will be busy by then).

Kobayashi-san explained that JLReq was somehow perceived as the only correct way to do the Japanese layout - anything that are described are correct and need to be implemented in that way. By presenting the only way it made people to stop thinking. He wants to avoid it with the new document.

The discussion concluded that however it will provide priorities and recommended defaults, it would be a good idea to add “discussions” blocks (with a distinct background color) that will provide backgrounds, alternatives, what to look, open questions, etc.. Such will provide readers in depth information and will make the whole document inspiring. Making the document inspiring might be interesting as a goal.

Kida also added that as the technology is advancing, and people are exploring what are possible with digital text, the JDLReq will need to be updated every few years. It can’t be something definitive. It would be a good idea to clearly state it.

We want to analyse areas where the standardisation or implementation are not progressing as we expect, and will try offering some additional data that might possibly help resolving them.

The accessibility part of the goals document is still lacking contents. todo: Murata-san to look at it.

Applications that are target and non-target

Applications who’s role is to generate print on paper is not a target. JLReq provides requirements for them.

Graphic design, and advertisements are not targets as they are very specialised area. We’ll cover some basic staff + what to consider for titles in large point sizes.

General contents

Who’s option should it be?

When there are multiple options in doing certain thing, is it implementers’ choice that they provide only one option, or should it be user’s option, which means the implementers should provide both. It can be different between different features but it should be made clear.

Processing of Notes (currently section 4.2)

This is one of the area where things are significantly different between print and digital. and therefore it will be interesting :) There was a discussion whether to include ruby in the Notes section or not and there was not an agreement. Will continue discussions.

Positioning external objects (illustrations, charts, movies)

There aren’t much to discuss on non-paged media. Things get complicated with pages and spreads. Therefore it might make sense to include it in the Pages section.

TODOs

Based on the current TOC plan, Bin-sensei and Kobayashi-san will start collecting existing contents and paste them into the TOC. Kobayashi-san will write up something regarding to the functional roles of various features. The next four meetings will be used to review and discuss on such contents.
The next meeting

Will be on 11/30

//