Re: JLReq and Gap Analyses

Thank you for your thoughts, Richard.

I don't believe we disagree at all on the goal, and my point was to say that the value of the GA is increased if it can also critique how the current CSS properties work, while proposing wholly new solutions to the problems identified in the JLReq. My feeling about certain properties that originally were defined to serve JLReq needs is that they fall short due to incomplete testing or incomplete understanding among implementers. 

I also want to say that the basic requirements described in the JLReq should ideally be those that apply to all Japanese text; not only that for Print, or only that for Web. I would hope that in describing the requirements in the context of both Print and Web that the core requirements and therefore implementations could be greatly improved, and the union of the two worlds will result in a definitive document. I therefore would like (to try at least) to keep the document whole and single, because I believe that the fact that one world is static and has all this history wrapped up in the machines that made it, whereas the other is dynamic and one's interaction with it so much more varied, does not take away from the fact that it still all is Japanese language, and to make it beautiful one must consider how it gives life to a given medium and flows through, and contributes to, the overall "balance" of the design.

With more and more media guided by machine learning and automatic adaptation, I feel it is imperative the rules of the road, as it were, were able to define what underlies the Japanese aesthetic I am talking about. Or, at least define what is appropriate for a layout engine to do itself, and what requires human intervention so that the beauty is preserved (yet adaptable).

--Nat
 
On 6/18/19, 3:52 AM, "r12a" <ishida@w3.org> wrote:

    Just a couple of points to add, from me.
    
    On 17/06/2019 23:57, Nat McCully wrote:
    
    > As for the Gap Analysis and Tests, I hope that they can serve the role of showing not only which CSS properties have been created to solve the problem of a lack of support for basic Japanese layout needs; but also to show if basic and more advanced layout can actually be achieved using them, across the major Web rendering stacks. The value of the Gap Analysis goes up when it can show not only that a given CSS property exists, but that the property can be used to achieve a representative use case for the feature. We probably need to review the existing tests to make sure they can show this.
    
    I'd like to apply a very slight course correction here.
    
    The goal of the Gap Analysis work is not to show which CSS properties 
    have been created.  It's goal is to identify things that Web users and 
    content authors are struggling with.
    
    It *follows* from that that we need to check whether any blockage is 
    caused by a deficiency in CSS (or HTML, or something else for that 
    matter), or whether it's due to the browser or ebook implementers not 
    adding specified features to their user agents.
    
    But the main goal of the GA work is to identify things that 
    users/content authors want to do but cannot (and prioritise those things 
    in terms of the pain it gives them).
    
    > The Web is changing faster and faster, and so for new CSS properties under review or discussion, we should draw up a set of tests that essentially make sure the property will fulfill its promise for the Japanese use-case, as it makes its way from draft to implemented-in-all-browsers finality, to aid in its utility for the originally intended use-case.
    
    I'm beginning to think that if we develop a version 3 that is more 
    Web-focused, it should perhaps be a separate document from the existing 
    jlreq doc.  (It could be called "Japanese Layout Requirements for the 
    Web", or some such thing.)  I agree with Nat that there's lots of very 
    good print related stuff in the current jlreq, and that we need to be 
    careful not to lose it, but i also think it will be difficult to manage 
    both types of information in a single document.  So why not take a copy 
    of jlreq, give it a new title, then rework the text as needed to make a 
    new document.
    
    By the way, we should also be careful not to tend too far in the 
    opposite direction – we need to address fixed page layouts in ebooks as 
    well as the highly fluid layouts that are possible on a web page.
    
    hth,
    ri