Meeting minutes
Agenda Review
Action Items
<addison> https://
<addison> #165
<gb> Action 165 add a conformance section to suppress the respec warning to specdev (on aphillips) due 2025-04-10
<addison> #164
<gb> Action 164 add the google local fonts proposal to future agenda (on aphillips) due 2025-04-10
addison: google local font proposal, I'll add to next week's agenda
<addison> #163
<gb> Action 163 ask bidi related groups about pointerevents 505 (on xfq) due 2025-03-27
<addison> xfq: did this. saw some replies that logical versions of pan pointer events could be useful
<addison> #162
<gb> Action 162 poll I18N/CSS for new day/time (on aphillips) due 2025-03-25
addison: I'll keep 163 for now
<addison> #159
<gb> 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
<addison> #157
<gb> Action 157 write glossary proposal identifying options and next steps for those options (on aphillips) due 2025-02-20
<addison> #136
<gb> Issue 136 follow up on XML errata (by aphillips) [task]
addison: #160, I finally got a reply from florian, I'm going to hold this for now
<gb> CLOSED Action 160 review graphemes in specdev and add balinese example and otherwise fix the text (on aphillips) due 2025-03-06
<addison> #135
<gb> Action 135 follow up on XR issue 1393 about locale in session (on aphillips) due 2024-10-17
<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> #89
addison: XML errata, next week I should have an answer
<gb> Action 89 update i18n specs to support dark mode (on xfq) due 2024-04-18
<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> #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
Info Share
addison: I saw JcK's email on the art list, I started writing a response
Review RADAR Review
Pending Issues Review
<addison> https://
discuss pointerevent 505
<addison> pointerevents#505
<gb> Issue 505 ‘Logical’ values for the ‘touch-action’ property (by aphillips) [i18n-needs-resolution] [future]
<gb> Issue 272 Add logical dimension values for touch-action property, since logical is/has shipped (by jonjohnjohnson) [future]
<gb> 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]
<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
<gb> Pull Request 496 Add logical/abstract values for `touch-action` (by patrickhlauke) [future]
Bert: I think that doesn't remove any of the current functionality
<gb> 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]
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> https://
ACTION: addison: reply to pointerevents 505
<gb> Created action #166
close #163
<gb> Closed issue #163
specdev prs
https://
addison: I made changes
https://
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
https://
https://
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
https://
r12a: that sounds okay to me
xfq: looks good to me
r12a: we can merge it
<Bert> +1 to merging
xfq: +1