- From: Fuqiao Xue <xfq@w3.org>
- Date: Tue, 20 Sep 2022 19:37:24 +0800
- To: www-international@w3.org
https://www.w3.org/2022/09/13-i18n-minutes.html
– DRAFT –
TPAC 2022 Internationalization WG
13 September 2022
[2]Agenda.
[2] https://www.w3.org/events/meetings/6e9d6b4f-04c3-4941-a56e-3664d103f504#joining
Attendees
Present
Addison, Atsushi (virtual), Bert, David-Clarke,
David-Clarke_, Ding Wei (guest, Fantasai, Florian
(physical), Fuqiao (virtual), Manuel (Igalia),
physical), Ralph (guest, Richard (virtual), virtual)
Regrets
-
Chair
Addison Phillips
Scribe
addison, atsushi, Bert
Contents
1. [3]specdev
2. [4]Info Share
3. [5]specdev
4. [6]Infoshare 2
5. [7]String-Search
6. [8]specdev publish to TR
7. [9]~* Break *~
8. [10]timezone, ltli
9. [11]CSS #775
10. [12]Intros
11. [13]CSS 5478
12. [14]whatwg#2404
13. [15]ALReq#217
14. [16]~* Lunch *~
15. [17]tonight's discussion with payments
16. [18]AOB?
17. [19]Discussion with Payments
18. [20]Summary of action items
Meeting minutes
<addison-mobile> Reagent, draft minutes
<addison-mobile> Running late: will start at 705 pacific
<r12a> addison, what's today's zoom link ?
Passcode: 259641
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
<r12a> [21]https://github.com/w3c/csswg-drafts/issues/6770
[21] https://github.com/w3c/csswg-drafts/issues/6770
<r12a> [22]https://github.com/w3c/csswg-drafts/issues/4605
[22] https://github.com/w3c/csswg-drafts/issues/4605
<r12a> [23]https://github.com/w3c/csswg-drafts/issues/4910
[23] https://github.com/w3c/csswg-drafts/issues/4910
addison: other thing, mostly other CSS issues, like spacing in
punctuations
<r12a> [24]https://github.com/w3c/csswg-drafts/issues/4566
[24] https://github.com/w3c/csswg-drafts/issues/4566
<r12a> [25]https://github.com/w3c/csswg-drafts/issues/4442
[25] https://github.com/w3c/csswg-drafts/issues/4442
<r12a> [26]https://github.com/w3c/csswg-drafts/issues/4397
[26] https://github.com/w3c/csswg-drafts/issues/4397
addison: also language tag, with blank or asterisk
… also blank vs. und
<r12a> [27]https://www.w3.org/International/questions/
qa-no-language.en.html
[27] https://www.w3.org/International/questions/qa-no-language.en.html
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, [28]xml:lang is allowed to be
empty
[28] https://www.w3.org/TR/xml/#sec-lang-tag
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
specdev
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]
Info Share
r12a: unicode edcom released version 15 today
… also in review edition will be released soon
Ding_Wei: from Huawei
[29]https://www.unicodeconference.org/
[29] https://www.unicodeconference.org/
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
specdev
xfq: received email for white space, but haven't got time to
work in
addison: picking personal name's one
[30]https://aphillips.github.io/
bp-i18n-specdev/#personal_name_examples
[30] https://aphillips.github.io/bp-i18n-specdev/#personal_name_examples
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: [31]https://
ja.wikipedia.org/wiki/%E6%9D%8F_(%E5%A5%B3%E5%84%AA)
[31] https://ja.wikipedia.org/wiki/杏_(女優)
[conversation for names listed in the table]
addison: should we back to original f/m separated list?
r12a: don't think so
[32]https://w3c.github.io/bp-i18n-specdev/
[32] https://w3c.github.io/bp-i18n-specdev/
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
[33]https://github.com/w3c/bp-i18n-specdev/issues
[33] https://github.com/w3c/bp-i18n-specdev/issues
addison: issues here
r12a: when you do reviews from spec, you should tag
[34]https://github.com/w3c/i18n-activity/issues/1581
[34] https://github.com/w3c/i18n-activity/issues/1581
[35]https://github.com/w3c/secure-payment-confirmation/issues/
206
[35] https://github.com/w3c/secure-payment-confirmation/issues/206
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> [36]Language enablement index
[36] https://www.w3.org/TR/typography/
<r12a> [37]https://github.com/w3c/i18n-editors/
[37] https://github.com/w3c/i18n-editors/
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].
<r12a> [38]https://www.w3.org/International/i18n-activity/
guidelines/review-instructions.html
[38] https://www.w3.org/International/i18n-activity/guidelines/review-instructions.html
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].
Uniview v15.0
Infoshare 2
<r12a> [39]https://r12a.github.io/uniview/
[39] https://r12a.github.io/uniview/
r12a: two item
String-Search
[40]https://w3c.github.io/string-search/
[40] https://w3c.github.io/string-search/
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
[41]https://aphillips.github.io/string-search/
[41] https://aphillips.github.io/string-search/
[42]https://aphillips.github.io/
string-search/#south-asian-scripts
[42] https://aphillips.github.io/string-search/#south-asian-scripts
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
[43]https://github.com/w3c/string-search/files/9278962/
ILs-text_variations-final.pdf
[43] https://github.com/w3c/string-search/files/9278962/ILs-text_variations-final.pdf
[44]https://github.com/w3c/string-search/issues/10
[44] https://github.com/w3c/string-search/issues/10
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> [45]https://r12a.github.io/scripts/arabic/
arb.html#ijam_tashkil
[45] https://r12a.github.io/scripts/arabic/arb.html#ijam_tashkil
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].
[46]https://github.com/w3c/string-search/files/9278962/
ILs-text_variations-final.pdf
[46] https://github.com/w3c/string-search/files/9278962/ILs-text_variations-final.pdf
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 *~
timezone, ltli
[47]https://w3c.github.io/timezone/
[47] https://w3c.github.io/timezone/
addison: I started a revision of [48]‘Working with Time and
Timezones’
… Could be useful for ECMA, who want to add temporal support to
JavaScript.
[48] https://w3c.github.io/timezone/
[49]https://pr-preview.s3.amazonaws.com/w3c/ltli/34/
409daae...aphillips:b9fb565.html#metadata-versus-text-processin
g
[49] https://pr-preview.s3.amazonaws.com/w3c/ltli/34/409daae...aphillips:b9fb565.html#metadata-versus-text-processing
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.
<r12a> [50]https://www.w3.org/International/questions/
qa-text-processing-vs-metadata
[50] https://www.w3.org/International/questions/qa-text-processing-vs-metadata
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.
<r12a> [51]https://w3c.github.io/bp-i18n-specdev/#lang_misc
[51] https://w3c.github.io/bp-i18n-specdev/#lang_misc
[52]https://aphillips.github.io/
bp-i18n-specdev/#sec_text_processing_lang
[52] https://aphillips.github.io/bp-i18n-specdev/#sec_text_processing_lang
addison: And specdev also has ^^
[53]https://
deploy-preview-75--string-meta.netlify.app/#protocol-strings
[53] https://deploy-preview-75--string-meta.netlify.app/#protocol-strings
<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.
addison: OK
… Done.
… I will look up the RFC it mentions [in the Webtransport
example] and link to it.
<r12a> yes
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.
CSS #775
[54]https://github.com/w3c/csswg-drafts/issues/775
[54] https://github.com/w3c/csswg-drafts/issues/775
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> [55]https://language.moe.gov.tw/001/Upload/files/
SITE_CONTENT/M0001/deploy/html_en/index.html
[55] https://language.moe.gov.tw/001/Upload/files/SITE_CONTENT/M0001/deploy/html_en/index.html
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’
[56]http://unicode.org/iso15924/iso15924-codes.html
[56] http://unicode.org/iso15924/iso15924-codes.html
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
[57]https://github.com/w3c/csswg-drafts/issues/771#
[57] https://github.com/w3c/csswg-drafts/issues/771
fantasai: Issue was focused on latin text, should we have a
separate issue for Chinese?
[58]https://github.com/w3c/csswg-drafts/issues/779
[58] https://github.com/w3c/csswg-drafts/issues/779
florian: Issue #779
florian: Bopomofo is not exactly centered, but close.
<fantasai> [59]https://github.com/w3c/csswg-drafts/issues/
771#issuecomment-1182339573
[59] https://github.com/w3c/csswg-drafts/issues/771#issuecomment-1182339573
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.
[60]https://github.com/w3c/csswg-drafts/issues/7055
[60] https://github.com/w3c/csswg-drafts/issues/7055
<florian> [61]https://www.w3.org/TR/
css-text-4/#text-spacing-property
[61] https://www.w3.org/TR/css-text-4/#text-spacing-property
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: [62]https://www.w3.org/2022/03/
04-clreq-minutes.html#t07)
[62] https://www.w3.org/2022/03/04-clreq-minutes.html#t07)
fantasai: Can you add the i18n recommendation to the issue?
[63]https://github.com/w3c/csswg-drafts/issues/6001
[63] https://github.com/w3c/csswg-drafts/issues/6001
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> [64]https://github.com/w3c/csswg-drafts/issues/6950
[64] https://github.com/w3c/csswg-drafts/issues/6950
<fantasai> [65]https://github.com/w3c/csswg-drafts/issues/
6950#issuecomment-1025401290
[65] https://github.com/w3c/csswg-drafts/issues/6950#issuecomment-1025401290
<fantasai> CLREQ response [66]https://github.com/w3c/
csswg-drafts/issues/6950#issuecomment-1103480275
[66] https://github.com/w3c/csswg-drafts/issues/6950#issuecomment-1103480275
<fantasai> Japanese-perspective response [67]https://
github.com/w3c/csswg-drafts/issues/6950#issuecomment-1164087402
[67] https://github.com/w3c/csswg-drafts/issues/6950#issuecomment-1164087402
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?
<r12a> [68]https://github.com/w3c/csswg-drafts/issues/7183
[68] https://github.com/w3c/csswg-drafts/issues/7183
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.
addison: emojis?
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> [69]https://github.com/w3c/csswg-drafts/issues/7183
[69] https://github.com/w3c/csswg-drafts/issues/7183
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> [70]https://www.w3.org/TR/
css-text-4/#valdef-text-spacing-punctuation
[70] https://www.w3.org/TR/css-text-4/#valdef-text-spacing-punctuation
fantasai: But if you turn the property on explicitly, you get
what you want.
(btw. Danda: [71]https://www.unicode.org/notes/tn33/)
[71] https://www.unicode.org/notes/tn33/)
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].
Intros
<r12a> [72]https://github.com/w3c/csswg-drafts/issues/5478
[72] https://github.com/w3c/csswg-drafts/issues/5478
CSS 5478
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 :-)
whatwg#2404
[73]https://github.com/whatwg/html/issues/2404
[73] https://github.com/whatwg/html/issues/2404
<r12a> [74]https://github.com/whatwg/html/issues/2404
[74] https://github.com/whatwg/html/issues/2404
<r12a> [75]https://github.com/w3c/alreq/issues/217
[75] https://github.com/w3c/alreq/issues/217
ALReq#217
Discussion about whether this was already discussed.
<fantasai> [76]https://github.com/w3c/csswg-drafts/issues/
1282#issuecomment-952428897
[76] https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-952428897
fantasai: This needs to come up in the CSS WG now.
<fantasai> [77]https://github.com/w3c/csswg-drafts/issues/
1282#issuecomment-1105613943
[77] https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-1105613943
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]
action-1193?
<trackbot> [78]action-1193: Addison Phillips to Ping css for
their list of hot issues -- due 2022-09-15 -- OPEN
[78] https://www.w3.org/International/track/actions/1193
close action-1193
<trackbot> Closed action-1193.
action-1194?
<trackbot> [79]action-1194: Elika Etemad to Summarize into
issue, for discussion in csswg -- due 2022-09-19 -- OPEN
[79] https://www.w3.org/International/track/actions/1194
close action-1194
<trackbot> Closed action-1194.
action-1181?
<trackbot> [80]action-1181: Addison Phillips to Send xfq
comments on pattern_white_space, etc. -- due 2022-08-18 -- OPEN
[80] https://www.w3.org/International/track/actions/1181
close action-1181
<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.
AOB?
Discussion with Payments
addison + ian + stephen
just chicken scratch here in case we need it
---
<Ian> [81]https://github.com/w3c/secure-payment-confirmation/
issues/202
[81] https://github.com/w3c/secure-payment-confirmation/issues/202
<Ian> [82]https://github.com/w3c/secure-payment-confirmation/
issues/202
[82] https://github.com/w3c/secure-payment-confirmation/issues/202
Summary of action items
1. [83]richard: find instructions for doing reviews and add to
i18n-editors page
2. [84]richard: add instructions for t: labels to the github
review instructions
3. [85]addison: import ijam/tashkil into glossary
4. [86]richard: read the ILs-text-variations-final doc and
make sense of it for addison
5. [87]richard: publish current specdev to TR
6. [88]richard: file an issue on the danda and SEAsian
punctuation
Received on Tuesday, 20 September 2022 11:37:30 UTC