- From: Fuqiao Xue <xfq@w3.org>
- Date: Fri, 11 Apr 2025 11:06:13 +0800
- To: www-international@w3.org
https://www.w3.org/2025/04/10-i18n-minutes.html
text version:
– DRAFT –
Internationalization Working Group Teleconference
10 April 2025
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/events/meetings/b7edae68-f52c-4aab-a1a6-3c37459e0786/20250410T150000/
[3] https://www.w3.org/2025/04/10-i18n-irc
Attendees
Present
Addison, Atsushi, Bert, Fuqiao, JcK, Richard
Regrets
-
Chair
Addison Phillips
Scribe
xfq, addison
Contents
1. [4]Agenda Review
2. [5]Action Items
3. [6]Info Share
4. [7]Review RADAR Review
5. [8]Pending Issues Review
6. [9]discuss pointerevent 505
7. [10]specdev prs
8. [11]Summary of action items
Meeting minutes
Agenda Review
Action Items
<addison> [12]https://github.com/w3c/i18n-actions/issues
[12] https://github.com/w3c/i18n-actions/issues
<addison> #165
<gb> [13]Action 165 add a conformance section to suppress the
respec warning to specdev (on aphillips) due 2025-04-10
[13] https://github.com/w3c/i18n-actions/issues/165
<addison> #164
<gb> [14]Action 164 add the google local fonts proposal to
future agenda (on aphillips) due 2025-04-10
[14] https://github.com/w3c/i18n-actions/issues/164
addison: google local font proposal, I'll add to next week's
agenda
<addison> #163
<gb> [15]Action 163 ask bidi related groups about pointerevents
505 (on xfq) due 2025-03-27
[15] https://github.com/w3c/i18n-actions/issues/163
<addison> xfq: did this. saw some replies that logical versions
of pan pointer events could be useful
<addison> #162
<gb> [16]Action 162 poll I18N/CSS for new day/time (on
aphillips) due 2025-03-25
[16] https://github.com/w3c/i18n-actions/issues/162
addison: I'll keep 163 for now
<addison> #159
<gb> [17]Action 159 write up proposal for specdev char-string
section, adding material that deals with the encoding interface
et al (on aphillips) due 2025-02-27
[17] https://github.com/w3c/i18n-actions/issues/159
<addison> #157
<gb> [18]Action 157 write glossary proposal identifying options
and next steps for those options (on aphillips) due 2025-02-20
[18] https://github.com/w3c/i18n-actions/issues/157
<addison> #136
<gb> [19]Issue 136 follow up on XML errata (by aphillips)
[task]
[19] https://github.com/w3c/i18n-actions/issues/136
addison: #160, I finally got a reply from florian, I'm going to
hold this for now
<gb> [20]CLOSED Action 160 review graphemes in specdev and add
balinese example and otherwise fix the text (on aphillips) due
2025-03-06
[20] https://github.com/w3c/i18n-actions/issues/160
<addison> #135
<gb> [21]Action 135 follow up on XR issue 1393 about locale in
session (on aphillips) due 2024-10-17
[21] https://github.com/w3c/i18n-actions/issues/135
<addison> #127
<gb> [22]Action 127 make a list of shared topics of interest
between TG2 and W3C-I18N (on aphillips) due 2024-09-30
[22] https://github.com/w3c/i18n-actions/issues/127
<addison> #89
addison: XML errata, next week I should have an answer
<gb> [23]Action 89 update i18n specs to support dark mode (on
xfq) due 2024-04-18
[23] https://github.com/w3c/i18n-actions/issues/89
<addison> #33
<gb> [24]Action 33 Close issues marked `close?` or bring to WG
for further review (on aphillips)
[24] https://github.com/w3c/i18n-actions/issues/33
<addison> #7
<gb> [25]Action 7 Remind shepherds to tend to their awaiting
comment resolutions (Evergreen) (on aphillips, xfq, himorin,
r12a, bert-github) due 18 Jul 2023
[25] https://github.com/w3c/i18n-actions/issues/7
<addison> #4
<gb> [26]Action 4 Work with respec and bikeshed to provide the
character markup template as easy-to-use markup (on aphillips)
due 27 Jul 2023
[26] https://github.com/w3c/i18n-actions/issues/4
Info Share
addison: I saw JcK's email on the art list, I started writing a
response
Review RADAR Review
<addison> [27]https://github.com/orgs/w3c/projects/91/views/1
[27] https://github.com/orgs/w3c/projects/91/views/1
Pending Issues Review
<addison> [28]https://github.com/w3c/i18n-activity/
issues?q=is%3Aissue+is%3Aopen+label%3Apending
[28] https://github.com/w3c/i18n-activity/issues?q=is:issue+is:open+label:pending
discuss pointerevent 505
<addison> [29]pointerevents#505
[29] https://github.com/w3c/pointerevents/issues/505
<gb> [30]Issue 505 ‘Logical’ values for the ‘touch-action’
property (by aphillips) [i18n-needs-resolution] [future]
[30] https://github.com/w3c/pointerevents/issues/505
[31]w3c/pointerevents#272
[31] https://github.com/w3c/pointerevents/issues/272
<gb> [32]Issue 272 Add logical dimension values for
touch-action property, since logical is/has shipped (by
jonjohnjohnson) [future]
[32] https://github.com/w3c/pointerevents/issues/272
[33]w3c/alreq#289
[33] https://github.com/w3c/alreq/issues/289
<gb> [34]Issue 289 Should `touch-action` support logical
directions like `pan-inline` / `pan-block`? (by xfq) [question]
[i:bidi_text] [i:interaction] [l:arb] [l:pes] [l:ug] [l:ur]
[l:ks] [l:ku]
[34] https://github.com/w3c/alreq/issues/289
<addison> xfq: the pan-inline could be useful. you could use
css rules or js to do this currently.
<addison> ... they won't add in L3 and add in L4. already a PR
for that to work on in L4.
r12a: I read this alreq issues and people saying oh yeah it's
necessary here's an example
… but I couldn't see why you needed logical values for those
examples
addison: I think what r12a's trying to say is is there a moment
when you would want the pan direction to be different than the
different than the touch event direction
addison: so the reason to use logical rather than physical
would be to say I want to restrict scrolling to only be left or
right or up or down without having to specify the specific
direction you're locking it off from
… you would use this property to say don't allow this page to
scroll horizontally
Bert: I think the use case is to @@1
… to say that gesture should be passed on rather than ignored
you use this property
… the logical values mean you can scroll in the forward
direction whatever that forward direction is
addison: I would prefer if in the future CSS started from
logical and add physical when physical has more meaning
… in this case actions are almost always in a physical
direction regardless of how the text is laid out
… so I get the need for physical directions
r12a: one possibility is if you're not touching the screen
because you don't have hands or you are not able to get closer
to the screen, you could issue a voice command that says pan
forward and then you'd have to know where forward was?
… my initial assumption would be that it has to use the
direction of the document
Bert: the whole thing of the property is you make a movement it
cannot be used for scrolling but please don't ignore it and
turn it into a pointer event and send it up to the parent
element or whatever
… script handler
addison: it generates a pointer event that isn't consumed by
the scrolling action and it's handed to you to do something
with
… this is a way to hook that
… so that I can do something else
… like if you get to the top of a page and you pull down
Bert: I think it's okay to leave this to later if you add
logical values later
[35]w3c/pointerevents#496
[35] https://github.com/w3c/pointerevents/pull/496
<gb> [36]Pull Request 496 Add logical/abstract values for
`touch-action` (by patrickhlauke) [future]
[36] https://github.com/w3c/pointerevents/pull/496
Bert: I think that doesn't remove any of the current
functionality
[37]w3c/alreq#289 (comment)
[37] https://github.com/w3c/alreq/issues/289#issuecomment-2786402829
<gb> [38]Issue 289 Should `touch-action` support logical
directions like `pan-inline` / `pan-block`? (by xfq) [question]
[i:bidi_text] [i:interaction] [l:arb] [l:pes] [l:ug] [l:ur]
[l:ks] [l:ku]
[38] https://github.com/w3c/alreq/issues/289
addison: xfq asked some bidi people, and at least a couple of
them came back with yeah this is a real thing
… there's a video of this ^
r12a: what's different there actually I think is the transition
direction
addison: by having logical values you could just program at
once
… you just pan-inline-start and it pulls from that side of the
screen
… rather than having to have a set of pointer events for rtl
and ltr layouts
In addition, it was noted that authors would likely use the
directional touch-action in combination with overflow. It
appears that currently, logical values for overflow are only in
draft in their respective spec, so the general feeling was that
merging #496 into the future/next version (Level 4, or
potentially "living standard") is not going to be
a critical blocker right now for authors.
<gb> Issue 496 not found
addison: the reason that they're deferring to L4 is touch
action is mainly used in combination with overflow and overflow
is only kind of drafty
… overflow doesn't have logical directions yet
… they claim to want to do both in L4
… we're requiring bidi people to rewrite things backwards
xfq: and people using vertical text
Bert: I don't mind postponing
addison: let me propose that we propose permit them to go
forward with L3
… ask they work really hard on getting it in L4
… does that sound like the right result?
<r12a> "These four properties form a logical property group
together with the overflow shorthand, and interact as defined
in CSS Logical Properties 1 § 4 Flow-Relative Box Model
Properties."
<r12a> [39]https://drafts.csswg.org/
css-overflow/#overflow-control
[39] https://drafts.csswg.org/css-overflow/#overflow-control
ACTION: addison: reply to pointerevents 505
<gb> Created [40]action #166
[40] https://github.com/w3c/i18n-actions/issues/166
close #163
<gb> Closed [41]issue #163
[41] https://github.com/w3c/i18n-actions/issues/163
specdev prs
[42]https://
deploy-preview-155--bp-i18n-specdev.netlify.app/#characters
[42] https://deploy-preview-155--bp-i18n-specdev.netlify.app/#characters
addison: I made changes
[43]https://
deploy-preview-155--bp-i18n-specdev.netlify.app/#example-encodi
ng-terminology-illustrated
[43] https://deploy-preview-155--bp-i18n-specdev.netlify.app/#example-encoding-terminology-illustrated
addison: in reponse to last week's discussion
… I have fixed the table under the first piece of mustard as
discussed
… with dotted lines and getting rid of the repeated use of the
word character
… and then I redid the I love Swiss cows example
… any high-level comments on this?
… is that example effective?
… or should I just rip it out?
r12a: seems okay to me
addison: so my proposal here would be please review this if you
have time in detail
[44]https://
deploy-preview-154--bp-i18n-specdev.netlify.app/#char_truncatio
n
[44] https://deploy-preview-154--bp-i18n-specdev.netlify.app/#char_truncation
[45]https://
deploy-preview-154--bp-i18n-specdev.netlify.app/#example-code-u
nit-trunc-bad
[45] https://deploy-preview-154--bp-i18n-specdev.netlify.app/#example-code-unit-trunc-bad
addison: I incorporated an image indivisible and memorable
… I think I've mostly addressed the comments
r12a: looks all right now
addison: is this good enough that we could let other people to
see it and we can always come back and do more work on it?
… or if there are specific things to fix then I'm happy to fix
them
addison: I think all of your comments were addressed
… I left open ones where I did something different than your
comment
[46]https://
deploy-preview-154--bp-i18n-specdev.netlify.app/#char_trunc_uni
t_rec
[46] https://deploy-preview-154--bp-i18n-specdev.netlify.app/#char_trunc_unit_rec
r12a: that sounds okay to me
xfq: looks good to me
r12a: we can merge it
<Bert> +1 to merging
xfq: +1
[47]https://datatracker.ietf.org/doc/draft-bray-unichars/
[47] https://datatracker.ietf.org/doc/draft-bray-unichars/
Summary of action items
1. [48]addison: reply to pointerevents 505
Received on Friday, 11 April 2025 03:06:29 UTC