- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 May 2017 20:54:15 -0400
- To: "www-style@w3.org" <www-style@w3.org>
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Tate Yoko Award
---------------
- The working group hosted a talk by Kobayashi-sensei on the
challenges in typography currently faced by the Japanese
language community.
- Many different use cases were raised for further thought by the
working group.
- The group appreciated Kobayashi-sensei's insights and expertise
on line rhythm, kanbun, step-sizing, and other topics.
- Suggested to add class=advisement to paragraph recommending
authors use 'font-variant-*' instead of 'font-feature-settings';
this point also needs better evangelism among the authoring community.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Scribe: none
Tate Yoko Award
===============
Note: The speaker for this topic was not minuted; just the working
group's side discussions on his talk.
<bobbytung> Tate Yoko Award: https://tategaki.github.io/awards/
<ChrisL> When kerning is enabled, the OpenType kern feature is
enabled (for vertical text runs the vkrn feature is
enabled instead).
<fantasai> Should be using font-kerning, not font-feature-settings
<fantasai> https://www.w3.org/TR/css-fonts-3/#font-kerning-prop
<fantasai> font-kerning should handle this correctly.
[would make sense to check the source code]
[Yanagi-san will contact the authors and clarify what they're doing]
hiroshi: (shows http://wwwc.webcrow.jp/)
hiroshi: The problem is that some browser put "より" on the right
side instead of center.
fantasai: Maybe bug of Chrome.
(seems Edge works ok)
fantasai: Hopefully can be fixed
<fantasai> https://www.w3.org/TR/css-writing-modes-3/#inline-alignment
<fantasai> https://www.w3.org/TR/css-writing-modes-3/#text-baselines
<fantasai> “In vertical typographic mode, the central baseline is
used as the dominant baseline when text-orientation is
mixed or upright. Otherwise the alphabetic baseline is
used. ”
Rossen: Please let us know if there are bugs.
<Florian> Having checked with the author, he was not aware of the
higher level properties that should be used (when
possible) instead of font-feature-settings. Maybe there
is an effort to do on the readability of the spec of
this topic
<fantasai> Florian, maybe can use class=advisement, but I think
it's mostly a problem of implementations releasing
font-feature-settings before higher-level features were
implemented
<Florian> fantasai: agree about both points
<BogdanBrinza> Microsoft Edge public bug tracker:
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/
zhengxu: Would like to know the priority of font rendering issues.
<astearns> currently looking at a requirement for line breaking at
punctuation - not covered by CSS at the moment
<astearns> in this case, if a line is too long to fit with no
punctuation to break at, there are several
possibilities. Maybe you'd break the line as normal,
maybe you'd have overflow (to scroll to)
<astearns> the way it's currently done is to add a <br> in the
markup after the punctuation
<Rossen> It sounds like they want to have the ability to size the
block to the size of the minimum line length
<astearns> maximum, yes
<fantasai> yeah, we can do that
<fantasai> max-content
<Rossen> basically <div style="width: min-inline-content;">...
<Rossen> max-content will result in the longest possible line
<Rossen> min-content will result in the longest possible word...
<fantasai> It's also important to know whether this is a stylistic
choice or if it's based on type of content (prose vs
poetry)
<Rossen> so if we assume that they need the shortest line then we
don't have that
<fantasai> they're using the longest one afaict
<fantasai> the breaks are at punctuation
<fantasai> and are forced
<Rossen> right, but then he said something about wanting to have
smaller size of the container and use scrolling...
<fantasai> Yeah, that's nowrap :)
<fantasai> We can solve this case
<fantasai> Once we have line break transformations correctly
implemented, we can even handle the choice between the
left and right cases at the style level
<fantasai> by using pre-lines for the right case, and normal for the left (white-space)
[wrt complaint that italics is not interoperable for vertical text]
<fantasai> https://lists.w3.org/Archives/Public/www-style/2013Jul/0065.html
<fantasai> “RESOLVED: Leave synthesis of italics in vertical text undefined.”
[discussion of mousewheel direction]
<fantasai> fantasai: if the primary scroll direction and page
progression direction are not derived from the same
information, pages will print/scroll incorrectly when
they are designed for scrolling/printing
<fantasai> (mousewheel should follow primary scroll direction /
page progression direction)
<BogdanBrinza> Edge supports -ms-scroll-translation property with
vertical-to-horizontal value:
https://msdn.microsoft.com/en-us/library/hh973361(v=vs.85).aspx
<dbaron> But there seems to be a desire for horizontal scrolling,
but only once various UI issues (e.g., mousewheel) are
fixed.
<dbaron> is the page progression direction determined by
writing-mode on the root?
<dbaron> (and is there propagation from body to root?)
<fantasai> yes
<fantasai> body, actually
<fantasai> because WebKit
<fantasai> we take writing-mode and direction from body (or root
if no body) to determine the scroll directions and page
progression
<astearns> so fantasai is saying we need more slashes?
<dbaron> https://drafts.csswg.org/css-text/#propdef-text-transform
says:
<dbaron> full-width
<dbaron> Puts all typographic character units in fullwidth form.
If a character does not have a corresponding fullwidth
form, it is left as is. This value is typically used to
typeset Latin letters and digits as if they were
ideographic characters.
<dbaron> ... which seems like it ought to work here.
<fantasai> we only trigger tate-chu-yoko on ascii digits, currently
<fantasai> so there's an interaction here that's a bit tricky
<fantasai> (originally we did any digits, but jdaggett wanted a
simplification)
<BogdanBrinza> https://blogs.windows.com/msedgedev/2016/08/11/edgebug-twitter/#rfzCkGZwfebJuxTA.97
<BogdanBrinza> ^ #EdgeBug
<dbaron> florian talks about https://www.w3.org/Submission/CSJTUWT/
<dbaron> Florian's summary of the key part of Kobayashi-sensei's
point was I think that the things that are most important
for legibility in Japanese are line length and character
spacing (related to character grid and line grid), and
today they're all horrible on the Web
<dbaron> (I should have tried to write it down right as he said
it, though)
<dbaron> jlreq is https://www.w3.org/TR/jlreq/ , for the record
<tantek> who showed the dot-leader example on the screen?
<dbaron> https://drafts.csswg.org/css-content/#leaders
<dbaron> The current spec for Leaders feels more like a feature
wishlist than a spec
<astearns> Could you automatically shift the color over video
continuously using blend modes?
<myles> astearns: think of the perf
<myles> astearns: and it would have to pierce through compositing
layers making it expensive
<astearns> it would make my eyes hurt to try to read
shifting-color text anyway
<myles> Yes
<flackr> astearns, myles ^ it's not nice on the eyes, but seems to
work in chrome at least
<flackr> http://jsbin.com/faputep/edit?html,css,output
<bobbytung> Should it be resolved with TTML?
<myles> bobbytung: if the content uses TTML :P
<BogdanBrinza> https://blogs.windows.com/msedgedev/2016/04/20/building-a-more-accessible-web-platform/#Iym2qYXS7kFCQydY.97
Section "Improved web legibility in high contrast"
Rhythm discussion notes
-----------------------
Scribe: fantasai
- Current discussion is on rhythm
- Koji is projecting a document with two columns that shows the
text rhythm being kept when the text is interrupted by an
image, the rhythm is not resumed, it is merely restarted as a
result, the columns don't align across the gap.
- Koji asserts that there are professional users for whom this is
unacceptable
- They would prefer to insert extra space to resume the rhythm
- Koji also asserts that for casual users, they prefer to not
insert extra space in order to resume the previous rhythm.
- Kobayashi-sensei asserts that there are no such people.
- He draws some content.
- Says that the top and bottom of the page need to be aligned
properly.
- The drawing is of two columns or two facing pages. Problem is
them not being aligned, the reason is because of inserted
images.
- (two interruptions in the text)
- (in the middle, the text isn't aligned to the line grid)
- If tried to align, the spacing before and after the image would
be uneven. If there is just one column, don't do this.
- This kind of adjustment is not done automatically in DPT
software, can be done by setting fixed position for the
middle? block of text
- If you just have one column, being even is better; if you have
two, lining up is better
- Since it's not achieved so far in DTP, not requiring that Web
does it but he wishes that we solved that problem.
- If we did some kind of vertical justification by spreading the
leftover space... Can't get into details, it's more
complicated, so far hasn't been solved
- Another problem is when you have cite-outs
- You want to line up the sidenote with the thing being annotated,
there is also this requirement.
- In DTP software, they would draw a line and attach things to it.
- (There are various names for these kinds of alignment)
- If you go in inline direction, have problem of things lining
up... justification is generally solved by DTP software.
- Florian explains: this is a similar problem to justification,
which is a mostly solved problem; the vertical equivalent
isn't solved.
- Kobayashi-sensei continues...
- It's a problem worth solving, but also it's hard.
- The desire to align the bottom edge of things is also strong.
- But that might be different from print and web; on print it's
really important, but on the Web less important maybe because
we are scrolling.
- Maybe we have one less constraint when playing wiht this
justification-like thing, that we don't need to have the
bottom align.
- But when we print, it does matter.
- So just wants us to make sure that this problem is important and
hard.
- Please think about this; let's go to next topic.
- Kobayashi-sensei has written a 50page thesis on this available
on the web, written in Japanese, Title is Something Something
Vertical Something.
<bobbytung> The Document Mr. Kobayashi mentioned is here (in
japanese): http://www.cas-ub.com/project/publications/nihongokumihan.pdf
myles: This was super awesome, thank you very much
koji: I want to emphasize, from his statement, while line grid is
important, in some cases there are more important things
than aligning to the grid.
koji: If those things happen, breaking rhythm is better.
koji: In this discussion, people really want grid to be strong,
while I feel grid is one of criteria, and when there is more
important concern, need to shift.
<dbaron> So one thing I wanted to understand was when he was
talking about how breaking the rhythm was ok in one
column but not when columns lined up -- and talked about
having the thing that broke the rhythm top-aligned within
the gap rather than centered -- I was wondering if anyone
actually ever *wanted* it top-aligned, or that was just a
deficiency of the software being used.
dbaron: [example of image in the middle breaking the rhythm, and
how image was top-aligned rather than centered]
dbaron: In the multiple-column case, and wondering if idea of
having that image top-aligned within the space
dbaron: rather than centered within the space
dbaron: was because of limitations in the software.
dbaron: Was it preferable to have it centered, if that was
possible?
Kobayashi-sensei: Ideal is centered
kobayashi-sensei: but some things are better top-aligned, e.g.
side notes.
[kobayashi-sensei draws some text with interruption as an image.
Goal is to get spacing even on either side
Draws a different example of vertical text, end-note of
paragraph (after-paragraph note) end of chapter/section etc.
This note is inserted at the end of the paragraph... has
smaller text and line-spacing
Spacing between lines and note is equal, but the space after
the note is bigger
There are cases where you center, and others where you start
align
For this situation, end notes, but not only
also for pull-quotes (or block quotes?)
In this case do the same as for end notes
But some people like it centered
]
myles: Is difference between two cases because vertical vs
horizontal text, or difference is because image vs text.
Kobayashi-sensei: Depends on content, not on writing mode.
[Although this is a bit nuanced... according to Kobayashi-sensei,
such end notes are more appropriate in vertical text, an
footnotes are better for horizontal text.
Also depends on if it's the kind of footnote you want people
to read or if you want people to ignore them.
]
inline step sizing
------------------
<murakami> http://www.cas-ub.com/project/publications/nihongokumihan.pdf
fantasai: In print, the kihonhanmen size is chosen so that if
it's all Japanese characters then everything fits
perfectly
fantasai: but on the web you don't choose the size -- the width is
chosen by the width of the window
fantasai: we have a request for step size of line box to be an integral
multiple of the character count -- but then on the web we have
extra space. What do we do with the extra space?
[Kobayashi-sensei draws a book:
text is single column; index page is double column
different text sizes
if you have exact line length on both, because font size etc.
are all different; size of content area on page is different.
You want index to be smaller than main content
The extra space is distributed evenly around
but sometimes you want to be slightly bigger on top
this is independent of whether vertical or horizontal writing
because humans have very good perception of equality in
horizontal dimension,
but there's an optical illusion, that things that look
centered vertically aren't quite
and this extra space is added to accommodate
So you want centered, but ideally you want perceptual
centering, which is not quite the same
]
<astearns> the need to specify whether to center, top align or
align baselines (for side notes) is why there are so
many values for the box-snap property
https://drafts.csswg.org/css-line-grid/#box-snap
Kanbun
------
kanbun are Japanese version of Chinese writing, has little
annotations around the characters
It's for High School students
(skk was explaining this)
Kobayashi-sensei: There was this kind of material in JISX4051, but
JLREQ considered it too advanced.
skk: Challenge to create e-textbook using HTML/CSS/EPUB and this
is becoming a requirement.
Kobayashi-sensei: There's a lot of variations in this display, so
creating a spec and implementations for this,
it's extremely difficult.
Florian: It's important Japanese cultural thing, but also horribly
complicated.
skk: Currently working around with abspos.
fantasai: That's probably the right solution.
koji: Kobayashi-sensei said, there were two types of Kanbun. First
step is Japanese textbook with box of kanbun, but more
advanced is whole book in kanbun, so need to page or scroll
things.
koji: Latter case is hard to do in abspos or svg
Makoto: If you use a ?, then visual sequence is different from
oral sequence.
[Makoto points out the ordering of the example, it jumps around]
dbaron: So you write it in Chinese grammar.
?: It's originally Chinese poetry.
koji: Order is Chinese, and the check mark here, it means read the
earlier one first.
koji: The numbers say which needs to be read first in more
complicated cases.
Kobayashi-sensei: On the right side it's the readings annotations
Kobayashi-sensei: Some of the annotations are how to read the
Chinese character in Japanese, others are how to
conjugate in Japanese
Kobayashi-sensei: This character here has multiple possible
Japanese readings
Kobayashi-sensei: This mark says which one to use
myles: This is really scary
Kobayashi-sensei: Sometimes have one annotation, sometimes have
more
Kobayashi-sensei: Depending on expected level of the reader, will
but varying levels of annotations
Kobayashi-sensei: This is just one type of example
xidorn: I've seen much more complicated examples, e.g. with a
pronunciation for multi-character word
Florian: Sometimes root of word is written with Chinese character,
and conjugations are hanging off it.
fantasai: You can get the layout into HTML+CSS using abspos. Not
perfect, but probably best we can do, certainly for a
long while.
kobayashi-sensei: Best to just give up.
fantasai: Use inline-grid for each one and its annotations :)
[Makoto draws
placement in example projected is incorrect
ordering annotation should be left edge of gap between two
chars
pronunciation should be to the side,aligned to the bottom
or to the top
]
fantasai: I recommend marking it up as multi-level ruby and
handling the display by styling each ruby as inline-grid.
Kobayashi-sensei: If you have both reading and conjugation, they
stick together and grow downward.
Kobayashi-sensei: In a child's book, character can be really big,
and you can have long annotation with wrapped
annotation text.
koji: Annotations here are explaining Chinese, so can be really
long.
ChrisL: Animation: follow the dot.
Stretchy-brackets
-----------------
Kanai: Here is a photograph of a Japanese cookbook.
Kanai: Here there is a bracket symbol.
Kanai: Explains how to make a custard... ingredients are bracketed
together for this step.
fantasai: Need stretchy brackets for math as well.
dbaron: Looks a bit like a border image.
<dbaron> it would be a little hard to do with a border-image
<dbaron> to get the alignment points right
fantasai: Do it with list items and the unicode box drawing
characters, giving the first and last special characters.
?: line-spacing would break that
koji: Is this particular to Japanese?
bobbytung: No, also in Chinese.
Florian: In English not quite the same, but have curly braces
doing similar things.
Kobayashi-sensei: This is not that common in Japanese either.
Murakami-san: Inline block with big curly bracket?
[warichu discussion]
<dbaron> you can do it with border-image by setting roughly 1em
border-image-width for the top and bottom sides, and
leaving border-image-width as 1 on the left and right,
and only having a border-width on the left
myles: How important is this?
Kanai: I'm a recipe book lover, so I always see this type of
layout in cookbooks.
Florian: Things that have lots of lists.
??: I never see this
??: It's not important
??: for this cookbook, it's a graphic support, designer can do.
You can use image or list tag
??: issue of character alignment
[discussion of using SVG]
dbaron: border-image can do the right kind of stretching
??: Not a must, just nice to have.
Murakami-san: Can already do with border-image.
Florian: One difficulty is if you try to line up this corner with
the font, because you need to guess the font metrics.
koji: Best solution is custom paint.
dbaron: Don't see how that's any better than border image.
[skk wraps up]
Received on Saturday, 27 May 2017 00:54:49 UTC