<addison-mobile> Reagent, draft minutes
<addison-mobile> Running late: will start at 705 pacific
<r12a> addison, what's today's zoom link ?
addison: conversation continued yesterday, see note. MathML, CSS issues
addison: longest conversation was on generic fonts
… asked us to come back to say on different generics via gap analysis
… we are asked to guide addisions, and guidelines for adding new generics
… associating new generics to existing ones
… goal is to collect generic classes in different area
… second part is how those map to five generics
… like Nastaliq is not sans-serif, or so
r12a: you are talking about long discussions, we held
addison: different sized bar among CSS participants
… we spent long time with stating the same thing
addison: other thing, mostly other CSS issues, like spacing in punctuations
addison: also language tag, with blank or asterisk
… also blank vs. und
addison: is xml:lang not allow blank?
… from definition, it cannot be empty
… guess schema has a bug?
addison: for topic, we can spend some time for our remaining open issues
<Bert> according to the XML spec, xml:lang is allowed to be empty
addison: one is talk about specdev, one editing in flight with more time than usual
… PR open again string-meta, is mustard for specdev also
r12a: for sure, if we make changes to string-meta, should also be lunched to specdev
… don't need is to copy words
r12a: we have lots of items in both
addison: original concept was checklist and pointers
r12a: discussed some monthes ago, summary text and pointing out are included
… you could basically read specdev like a document and to get idea, and get more detail via sources pointed
[moving physical room to correct one]
r12a: unicode edcom released version 15 today
… also in review edition will be released soon
Ding_Wei: from Huawei
addison: 28th of this month, unicode consortium will have virtual event for introduction of unicode and internationalization
… series of records from groups, one tutorial of internationalization
… series of records and live conversations
xfq: received email for white space, but haven't got time to work in
addison: picking personal name's one
addison: we list personal names' examples in block
… discussed that making sortable table, completing notes, and language tags
… question to ask people to contribute or not
r12a: thinking, we are picking names from various regions, but not sure whether to indicate as region but as country
… we need to establish this table with all of regions
addison: that's one I haven't finished
<xfq> There is a famous actress with the name An: https://
[conversation for names listed in the table]
addison: should we back to original f/m separated list?
r12a: don't think so
addison: richard you wanted to add some text for TBDs
… do we have some plan to build text for those?
r12a: got a detailed plan, step 1 someone write text, step 2 we review, step 3 we publish!
r12a: remember this is for spec developers
… also if you click links, you will see several review comments and what things to do or taken
addison: should we build backlog for people can check, or?
r12a: we could, but in sense of spec-dev, people can take from contents. there are already pipelines
addison: when we read as a block, you will notice the gaps
… sometimes we do on mustard, but sometimes don't
r12a: we have somewhere, in some cases but not all. we should have here and also links
… brief description is necessity, for reading these
… we need to go through, and check whether text is complete
addison: issues here
r12a: when you do reviews from spec, you should tag
addison: review comment for secure-payment-confirmation here, I don't think spec-dev doesn't say anything relates to this
r12a: not everything we need to create text for specdev
addison: on review, we have new action to tag each issue
… on some level, I would expect to have a policy what to write
xfq: I can look into some text, after finishing the whitespace stuff
r12a: better to have more people than you and me
… if you review something, and there is nothing in specdev, one should propose something to specdev
addison: one proposal, if one review and found nothing within label, one propose some text?
r12a: there are TBC label
r12a: if you choose t: label, you will see section number and title
… TBC is not sure which section is related, x is not in specdev
… like bidi_x
r12a: i: is index
… those labels relate to index, t: labels are for specdev. there should be some documentation.
<xfq> Language enablement index
ACTION: richard: find instructions for doing reviews and add to i18n-editors page
<trackbot> Created ACTION-1198 - Find instructions for doing reviews and add to i18n-editors page [on Richard Ishida - due 2022-09-20].
ACTION: richard: add instructions for t: labels to the github review instructions
<trackbot> Created ACTION-1199 - Add instructions for t: labels to the github review instructions [on Richard Ishida - due 2022-09-20].
r12a: two item
addison: string-search is a part of charmod, specific to string search
… basically, this document syas, considerations need to be taken when spec wants search
addison: not the highest priority, but at some point touch on this. there are bunch of examples
… set of examples and links to issues
… like issue #10
addison: my statement here is about writing allow languages @@@1
… like, here is some variations, looks similar, but don't know spelling variations
[on specific example in detail, incl. Marathi]
<r12a> wait !
<r12a> wrong one
Writing परसवणर is optionally allowed only forततसम words and not for non-ततसम words. Also, for meaning change as inवेदांत which means- ‘in the Veda’ as against, वेदानत which means- end of the
you can write the word with anuswara or a half-form of the nasal, although in some cases a particular word is preferred to have one or the other
… but in general you can switch between the two depending on how you like to write it
… this is just one example of how you can type differently
r12a: section south asian language should be titled as multiple ways of spelling
addison: will call as variations of user inputs/spelling
r12a: as mentioned before, variations are common among there
… that is choice of person's writting
addison: I should break this section, one for Arabic specific, and spelling slightly different
r12a: above link is for alternative encoding of Kashimiri
richard's link is better, use that
addison: import these documents?
r12a: go ahead
ACTION: addison: import ijam/tashkil into glossary
<trackbot> Created ACTION-1200 - Import ijam/tashkil into glossary [on Addison Phillips - due 2022-09-20].
ACTION: richard: read the ILs-text-variations-final doc and make sense of it for addison
<trackbot> Created ACTION-1201 - Read the ils-text-variations-final doc and make sense of it for addison [on Richard Ishida - due 2022-09-20].
r12a: could read through the document, and can put some text for Indian scripts
<Bert> (Typo in French example 6: s/côtè/côté/ )
addison: want to get this document updated, and bring into /TR/
… a lot of work to do, to provide a guidance for writting 'find' spec
r12a: want to recommend, to have specdev to /TR/ also, although empty section
specdev publish to TR
r12a: links to labels, needs to be updated
ACTION: richard: publish current specdev to TR
<trackbot> Created ACTION-1202 - Publish current specdev to tr [on Richard Ishida - due 2022-09-20].
addison: no additional item, break until 10am
~* Break *~
addison: I started a revision of ‘Working with Time and Timezones’
addison: LTLI, we discussed it a while ago.
… Decided to not incorporate some text, because of diff. in audience.
<r12a> i believe so
addison: But we still have a pull request waiting.
… OK, so I will undo the pull request.
addison: That does not belong in specdev, because it is not for spec authors.
… Do we have defs in the glossary?
r12a: I think it does belong in specdev.
addison: And we do have defs in the glossary.
addison: And specdev also has ^^
<r12a> metadata to associated with the
r12a: Can we put the mustard in that section before the text? We always do that, mustard and then explanation.
… I will look up the RFC it mentions [in the Webtransport example] and link to it.
addison: Does the mustard capture the essence?
r12a: [on IRC:] yes
addison: Those were editorial things on the top of my mind? Any others?
… Only outstanding is an action on formatted text. Did not have time yet.
… Volunteers to help welcome!
… May get to it in a month or two.
florian: Issue CSS#775 waiting for an answer
fantasai: The comment in the issue is a good summary.
addison: So it is trying to shrink bopo, but nut pinyin?
florian: Shrinking 50% OK for kana. For pinyin, may also depend on the font.
addison: So the language tag is a proxy for determining if it is bopo or pinyin?
fantasai: Yes, we have no other information.
florian: May make for verbose markup with all the lang tags, but it is the right thing to do.
… Question is not if this captures everything, but if it is the right default.
r12a: I was concerned about applying the sizing to the bopomofo. The bopomofo can be in the same position as kana or pinyin, but usually it is along the side.
… You can set CSS properties to do that.
… So is the 30% right in that case?
florian: You cannot have a CSS property depend on the value of another property.
addison: What if you remove the 30% rule?
florian: Then the bopomofo size would be wrong.
r12a: You need something different for bopomofo to get the position correct.
florian: You can have three characters bopomofo ruby, and then 50% won't fit.
… We are trying to say ruby in general sizes to 50%, but when it is bopomofo size to 30%.
… For the default; author can always change it.
… Size works, no matter what side of the base the ruby is displayed on.
r12a: Inter-character layout is very specific.
… And is the 30% instead of 33% to leave room for tone?
fantasai: Comes from ministerial recommendations for size ratios.
… See document from Taiwan ^^
florian: clreq has the same.
addison: OK, so the size is right. Now how do know a text is bopomofo?
florian: Hong-Kong vs Taiwan.
r12a: This is about the size. Isn't the centering also an issue?
… Because bopomofo isn't vertically centered, according to the Taiwan document. At least in inter-character. But bopomofo is rarely in other positions.
fantasai: Language tag matching is according to RFC. Subtag order does not matter.
addison: But if you do prefix matching...
fantasai: Browsers are supposed to apply the RFC 4347 algo.
addison: So if tw is not in the subtags, the pinyin may end up small.
florian: We might specify ‘not hk’.
… Smaller size may be harder to read.
David-Clarke: So, accessibility issues.
florian: So better to miss some cases than apply too much.
fantasai: Require language tags: Is there a way to express that a document is in a mix of scripts?
addison: There is ‘hanb’
addison: For Han with Bopomofo.
florian: That's perfect.
addison: ‘Perfect’ not the word I was thinking of....
florian: But perfect for this situation.
… So I think we add zh-hanb.
r12a: Looking at the Taiwan document, the pictures are different. Figuring out the sizing...
florian: There are some 9's and some 8's, while clreq only has 9's in the ratios.
… 9/30 in clreq, and 8/30 in the Taiwan document some of the time.
r12a: About half of the time.
fantasai: zh-hanb is now added in the CSS Ruby spec.
florian: I think the 8 or 9 is fine, it is always 9, but some fonts may have non-square, 8x9 characters.
… So size is correct, though positioning may be a problem.
fantasai: So OK for square and portrait characters. Landscape characters a problem.
addison: OK, sounds reasonable. As a default.
addison: OK, so shall we turn to the centering issue?
florian and fantasai discuss the process for the CSS WG to approve the issue.
fantasai: issue #771
fantasai: Issue was focused on latin text, should we have a separate issue for Chinese?
florian: Issue #779
florian: Bopomofo is not exactly centered, but close.
fantasai: in #771, the proposal is to have a separate justification algo for ruby.
… It says spaces are not a justification opportunity.
… We can say Bopomofo doesn't have justification opportunities.
florian: The removal of justification opportunity effectively results in centering, which for bopomofo is almost right.
fantasai: The 'auto' value can do this.
… Without justification opportinuties, it falls back to centering.
addison: Seems reasonable...
r12a: Yes, reasonable. But:
… Need to be clear that is an approximate kludge.
florian: If we would specify 'center', it would also be wrong in the same way.
… For the difference between centering and actual bopomofo layout, you would need dedicated engines in any case.
fantasai: So we are adding a justification mode, which removes justification opportunities from bopomofo. As it is an 'auto' value, implementers can do better, but that may take a while to happen.
… We need to bring this to the CSS WG.
florian: I have added a corresponding tag to the issue.
fantasai: And I will add the conclusion in the issue.
addison: Do you want us to review?
florian: We can ping you when it is ready for review.
addison: Tracking in issue #779, rather than #771.
florian: The diff between allow-end and trim-end is whether you trim the white part of punctuation if it appears at the end of the line.
… allow-end may lead to ragged right appearance.
r12a: It doesn't depend on justification..
addison: So the issue is about the default behavior.
florian: Yes, and the argument in the issue to use trim-end seems reasonable.
… So, the i18n wg recommends to accept the proposal?
addison: I don't see any harm in making it the default.
r12a: Yes, I already agreed in a comment in the issue.
(notes that we discussed this: https://
fantasai: Can you add the i18n recommendation to the issue?
fantasai: So seems the conclusion is to close the issue ^^ with no change?
florian: That seems to be the conclusion in the corresponding clreq issue.
fantasai: OK will do.
<fantasai> CLREQ response https://
<fantasai> Japanese-perspective response https://
fantasai: Seems there is a preference for turning on auto-spacing by default. Separate question is compatibility with browsers.
… Chinese suggestion is 1/8 em, Japanese suggestion is 1/4 to 1/6 em.
florian: Precise size can be an issue in layout of a button or menu. So my suspicion is that there are pages that break when auto spacing is on by default.
fantasai: So spacing is preferable, if it is compatible. Other question is what the default size is, 1/8? 1/6? Or depending on language?
atsushi: From jlreq perspective, 1/6 em comes from traditional spacing. Research exists that sizeof spacing between ideographic and alphanum
… in jlreq consensus that some spacing is better than nothing.
fantasai: So 1/8 is probably the least intrusive change then.
florian: Is is user-selectable?
fantasai: Not currently, but we should make it so.
florian: As it is not implemented yet, seems better to keep it simple for now.
r12a: It is implemented in IE, and MS Word does it.
florian: Yes, and other programs, but question is about CSS and browsers.
fantasai: MS Word also has to be compatible with practice in the 90s. Need research of current practice.
florian: Would be good to have a conclusion from i18n that some spacing is desirable, and exact size is to be researched.
addison: That seems not controversial. If compatible.
… And you would do research what sophisticated layout engines do today.
florian: I think the Japanese 1/4 comes from when that was simple to do in typesetting.
addison: What at boundary between ideographs and, say arabic?
r12a: Or Thai?
florian: Latin is by far the most common.
fantasai: I suspect it is for everything that is not ideographs. That is what the spec says now.
florian: They are neither letters nor numerals.
fantasai: So conclusion: spacing between 1/8 and 1/6 em, depending on further research.
… Other question is what to do if there is already space in the source.
… Throw it away and put in the 1/8em?
… And would it be web-compatible if we *only* did that?
r12a: That would only shrink the text somewhat, so not as dangerous for buttons and menus, as Florian mentioned.
r12a: That is also a part of my issue ^^
r12a: Auto-spacing is bound to get a lot more complicated, when we get to other languages.
… E.g., the vertical bar that ends a sentence.
… Some people put a space before it, size can differ.
… And some traditions have a lot more space after than before the symbol.
florian: For French, practice differs. There are rules, but some authors ignore it, some put a normal space because it is hard to get the right one...
fantasai: But if you turn the property on explicitly, you get what you want.
(btw. Danda: https://
ACTION: richard: file an issue on the danda and SEAsian punctuation
<trackbot> Created ACTION-1203 - File an issue on the danda and seasian punctuation [on Richard Ishida - due 2022-09-20].
About which quote characters to select when a quote is in a different language from the surrounding text.
fantasai: I already have an action for that. Can try to work on it on...
r12a: It is part of the gap analysis documents.
fantasai: Seems it was checked in for Gecko already.
r12a: And the issue talks about Chromium. Is webkit doing it?
fantasai: Seems Chrome was updated also.
r12a: OK, I need to run my tests again.
… That will change the color of a large percentage of my language-enablement matrix.
addison: So it will be the tipping point and we can say the web is now internationalized :-)
Discussion about whether this was already discussed.
fantasai: This needs to come up in the CSS WG now.
fantasai: There was a proposal to use 'margin' as shorthand for physical, and 'marginS' as shorthand property for logical.
addison: There could be a switch in the style sheet to switch between physical and logical. Is that a good summary of what we said?
… In other words, once all physical properties have a logical equivalent, there could be a switch to turn all shorthands into logical shorthands.
fantasai: A switch at syntax level, but only for the shorthands. 'Margin-left' would still be left, but 'margin' would affect the logical properties.
r12a: I believe Chrome has a flag.
… I'll send you the article I've written, which talks about ':dir(rtl)'
fantasai: Send me an email, otherwise I'll forget to look at it.
addison: Next meeting is Thursday. I'll have a meeting with Ian [on Web Payments] and I'll report on that.
atsushi: What is the zoom for Thursday?
addison: The one we use for the regular telcons.
… I'll send the agenda tonight, probably.
[Lunch. Back in 1 hour]
<trackbot> action-1193: Addison Phillips to Ping css for their list of hot issues -- due 2022-09-15 -- OPEN
<trackbot> Closed action-1193.
<trackbot> action-1194: Elika Etemad to Summarize into issue, for discussion in csswg -- due 2022-09-19 -- OPEN
<trackbot> Closed action-1194.
<trackbot> action-1181: Addison Phillips to Send xfq comments on pattern_white_space, etc. -- due 2022-08-18 -- OPEN
<trackbot> Closed action-1181.
~* Lunch *~
addison: I talked with some a11y people over lunch, among other things about tagging old languages.
David-Clarke_: Like Shakespearian English?
… And they do teach Latin on Duolingo.
… I studied some old Japanese, and the professor explained how they knew the pronunciation has changed.
… E.g., Japanese ‘oh’ which once was ‘woh’.
tonight's discussion with payments
addison: I'll talk tonight to Ian about Web Payments. Things related to string-meta.
… And I'll need to get TC39's attention.
Discussion with Payments
addison + ian + stephen
just chicken scratch here in case we need it