Meeting minutes
Agenda Review
Info Share
<addison> https://
<addison> #176
<gb> Action 176 add WG comment to html 11395 (on aphillips) due 2025-07-03
<addison> #175
<gb> Action 175 respond to our #2005 (on aphillips) due 2025-06-26
<addison> #174
<gb> Action 174 add 'typeface style` to the glossary (on r12a) due 2025-06-19
<addison> close #174
<gb> Closed issue #174
<addison> #173
<gb> Action 173 ping zainab (on aphillips) due 2025-06-19
<addison> #169
<gb> Action 169 reply to html 10843 and css 9832 (on aphillips) due 2025-05-08
<addison> #162
<gb> Action 162 poll I18N/CSS for new day/time (on aphillips) due 2025-03-25
<addison> #157
<gb> Action 157 write glossary proposal identifying options and next steps for those options (on aphillips) due 2025-02-20
<addison> #127
<gb> Action 127 make a list of shared topics of interest between TG2 and W3C-I18N (on aphillips) due 2024-09-30
<addison> #33
<gb> Action 33 Close issues marked `close?` or bring to WG for further review (on aphillips)
<addison> #7
<gb> Action 7 Remind shepherds to tend to their awaiting comment resolutions (Evergreen) (on aphillips, xfq, himorin, r12a, bert-github) due 18 Jul 2023
addison: I closed a number of marked closed issues
<addison> #4
<gb> Action 4 Work with respec and bikeshed to provide the character markup template as easy-to-use markup (on aphillips) due 27 Jul 2023
Review RADAR Review
Pending Issue Review
<addison> https://
Control the line height / proximity of text containing emphasis marks
<gb> Issue 11257 [css-text-decor] Control the line height / proximity of text containing emphasis marks (by xfq) [css-text-decor-3] [css-text-decor-4] [i18n-tracker] [i18n-jlreq] [i18n-clreq] [i18n-klreq] [i18n-mlreq]
<addison> fuqiao: this css issue that i raised in november
<addison> ... when using text emphasis in cjk
<addison> ... in many fonts, it tends to increase the line height
<addison> ... that's undesirable, seen people reporting this multiple times, need some way to address this
<addison> ... that's what the issue says
<addison> ... line height is one issue
<addison> ... proximity of emphasis mark and text is too wide sometimes
<addison> ... not exactly the same issue, but related
<addison> ... propose that we mark this issue as needs-resolution
r12a: I think two ways that we might expect these marks to be implemented
… is the emphasis marks are in the font, there's not much to say, because it's up to the font designer to get that positioning right
… in terms of the closeness of the marks to the text, there might be an issue if the marks are sythesized
https://
r12a: @@1
https://
r12a: the size of the dot is dictated by the font
… unless the font doesn't contain a glyph for that particular code point
addison: it's a little weird to be using a shape that's just a normal code point in the font and repurposing it
r12a: I think that's the way it's been done for years and years now
… but I'm not quite clear on the detailed mechanics
… why some of the these emphasis marks are closer than others
… what determines that?
addison: when I switched to Chrome it does a different thing
r12a: yeah
… in Firefox the thing that's labeled 'hiragino sans' is @@1
… you probably also need the language to be specified
addison: I've certainly seen the line spacing problem
… I think it's clear that there's at least some question about positioning
<atsushi> +1
addison: needs-resolution seems like the right thing to do
… anybody opposed to just tracking?
r12a: I don't object to that
… but there's another thing I wanted to bring up
… related to line spacing
… I remember bringing this up many years ago
… more than one occation with Japanese folks
… the content author has to set the line height to @@2
addison: if they're going to emphasize then they need to make enough space for that to take place
r12a: I'm questioning whether there is actually an issue
<Zakim> atsushi, you wanted to discuss in JLreq, or normal Japanese typography, emphasis marks are defined as 1/2 of base text..., not for zh-*?
r12a: "force the browser to select a font that displays emphasis marks correctly without widening line spacing, and/or"
… is there an expectation it could use a different font?
… because that seems to be the implication of that line
… than the one which is being used for the content
… or is the expectation that emphasis marks are chosen by the browser from a particular font and they're always the same
… and if so what does that have to do with default widening line spacing
… manage the spacing and proximity of the emphasis marks alongside the text was fine
xfq: @@3
addison: for example, if the guidance is "if you don't want the text emphasis marks to interrupt your line spacing, you should set your line spacing to accomodate emphasis marks, because the browser won't do that for you automagically"
… that might be worthy of a note, but it doesn't mean that we would change the spec
xfq: @@4
the UA may opt to use a font known to be good for emphasis marks, or the marks may instead be synthesized by the UA.
addison: it could mean just be sure you pick a font that has a glyph
Typeface Style in the glossary
<addison> w3c/
<gb> CLOSED Action 174 add 'typeface style` to the glossary (on r12a) due 2025-06-19
[r12a does live edits]
r12a: I put a link to "Typeface styles & font fallback"
Bert: should you use the word classification instead of style?
r12a: it's a bit of a mouthful
… it clashes with the word 'class', which is also used in HTML and CSS
addison: c12n
Bert: Vox-ATypI classification
Bert: I think the word 'style' might be a bit confusing
r12a: we changed the first word from 'font' to 'typeface'
… people refer to them as styles already
addison: we're inventing a neologism here
… maybe we're not all satisfied with the specific term
… is the definition good?
r12a: btw, it's not completely a neologism either, because it came out of Wikipedia
Specdev PR for Bidi Mirroring
<addison> w3c/
<gb> Pull Request 163 Mention layout mirroring for bidi (by xfq)
<addison> https://
https://
r12a: it points to a label that doesn't exist
… I made a comment about that
w3c/
r12a: my concern is that's a bit too specific
addison: there's a possibility that we want to separate this from other bidi text ones, or not
… whatever we do, if we create a new label we want to link to it
r12a: I don't know what the answer is, I'm saying that we just need to think about it a bit
addison: in recent years I've tried harder not to do the rtl penalty box
r12a: are we seeing this from our perspective, or are we seeing it from the perspective of the people who come to this document?
… I suspect that a lot of people who come to this document may be more interested in a section on typographic control than they are on a section in text direction
… because they are on a section in text direction, because they just don't know
xfq: maybe merge it with logical properties and rename it to bidi styling?