W3C home > Mailing lists > Public > www-style@w3.org > October 2022

[CSSWG] Minutes TPAC/Vancouver 2022-09-16 Part IV: Toggles Proposal, CSS Contain, Values & Writing Modes, CSS Fonts [css-contain] [css-values] [writing-modes] [css-fonts]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 25 Oct 2022 19:01:10 -0400
Message-ID: <CADhPm3uMiTffbX7jjLxCMOdFQJ=hSqoYkRKVsme-RtZxyHoBTw@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Toggles Proposal
----------------

  - TabAtkins reviewed the current draft of the Toggles proposal
      ( https://tabatkins.github.io/css-toggle/ ). The ARIA group has
      also been reviewing the work. There are accessibility issues
      still to resolve before an ED would be requested.
  - There was discussion of some examples this may not solve and they
      will be added to the explainer for further investigation.
  - In Chrome there is an example prototype implementation to help with
      solving the remaining accessibility issues as well as prove out
      this would work as planned
  - Concern was expressed that some of this proposal was outside the
      scope of CSS, though it was also pointed out that there are other
      similar capabilities in CSS that don't strictly conform to the
      scope. Still, this could get used by authors in other ways than
      intended.
  - Bert reminded the group he had done some similar work a while ago
      that didn't get traction at the time, but was worth revisiting
      for new use cases (
https://www.w3.org/People/Bos/css3-links-attempt-2002.html )

CSS Contain
-----------

  - RESOLVED: Use overflow-clip edge instead of border-edge for
              determining whether box is onscreen (Issue #5271:
              Interaction between content-visibility and
              overflow-clip-margin)
  - RESOLVED: Accept edits, if any issues open a new issue (Issue
              #5611: content-visibility should pause css animations in
              subtree)
      - original edits:
https://github.com/w3c/csswg-drafts/commit/82fc7ddb1abf9ce0c3f616cbd91a0f1d2069a215
      - subsequent edits:
https://github.com/w3c/csswg-drafts/commit/1ef126260e59fb486bc3749d731b8ba22556d92a
  - RESOLVED: New WD of CSS Contain L2, editors to work on that "note"
              (Issue #7576: Do we need a resolution for this commit?)

Values & Writing Modes
----------------------

  - There was concern that if the ic character (Issue #7577: Revisit
      decision to use 永 instead of 水 as the ic unit) is changed it
      could have ramifications on alignment when measurement is
      required. astearns will discuss with the Adobe team and come
      back with details on whether this will improve, regress, or
      have no impact so the group can resolve.

CSS Fonts
---------

  - RESOLVED: If OT spec says a feature is required, UAs MAY ignore
              attempts to turn it off (Issue #7634: Some font features
              should not be disable-able)

===== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/csswg-drafts/projects/32

Scribe: fantasai

Toggles Proposal
================

  TabAtkins: Not yet ready to ask for ED, so just a progress update
  <TabAtkins> https://tabatkins.github.io/css-toggle/
  <dbaron> also https://css.oddbird.net/toggles/explainer/
  TabAtkins: Dropped the URL, in my personal repo atm
  TabAtkins: As a note, I'll be asking for this to be an ED in a month
             or two, still working on the a11y bits
  TabAtkins: because that part is important

  TabAtkins: CSS Toggles is a proposal to put a notion of
             somewhat-durable state into the DOM
  TabAtkins: controlled via CSS properties
  TabAtkins: that can be manipulated by people activating things on
             the page
  TabAtkins: again with CSS properties
  TabAtkins: Authors do weird hacks all the time for this
  TabAtkins: classic checkbox hack, you display:none the checkbox but
             clicking label will change the checkbox checked state
  TabAtkins: and then style based on that
  <jensimmons> Or styling anything on the page with :has()
  TabAtkins: this is not accessible, or very usable in general
  TabAtkins: but it's useful enough that people do it all the time
  TabAtkins: e.g. I have a personal site I use because it's just me and
             my wife using, and we both use mouse
  TabAtkins: Beyond this, people do things like this by hand in JS all
             the time
  TabAtkins: tabs, sections, accordions, popups
  TabAtkins: All of these boil down to I want to activate this element,
             and make a state change happen
  TabAtkins: usually showing/hiding, sometimes other things like
             highlighting something
  TabAtkins: Toggles introduced simple set of primitives
  TabAtkins: and also addresses problem that none of these are
             accessible generally
  TabAtkins: Idea supported by our a11y folks and aaronlev, one of
             inventors of ARIA
  TabAtkins: this should obviate the need to throw around aria attrs
             for these patterns
  TabAtkins: most stuff should be automatically taken care of

  [Tab presents]
  TabAtkins: First you create toggles with the 'toggle-root' property
  TabAtkins: take name of toggle, how many states, and what states it
             starts in
  TabAtkins: Once you create a toggle, can't remove it
  TabAtkins: modifying state can only be done with user
  TabAtkins: or by JS
  TabAtkins: never by CSS
  TabAtkins: Next is toggle-trigger, says that it modifies the toggle
             state via activation
  TabAtkins: provide name of toggle, and what it'll do to it:
             increase, decrease, or set to specific value
  TabAtkins: this is open to in the future allow other types of
             activation, e.g. gestures
  TabAtkins: Toggle shorthand sets both at the same time
  TabAtkins: e.g. having something like a checkbox, where it wants to
             host and be the activator for its own toggle
  TabAtkins: but thing like tabset, would want to set toggle higher up,
             and set the trigger on the tabs
  TabAtkins: you can then respond to the toggles with the toggle
             pseudo-class
  TabAtkins: Example with ingredients, whether used or not
  TabAtkins: :toggle(used) whenever it's in active state, then I gray
             out and put a line through
  TabAtkins: can do this with arbitrary values also
  TabAtkins: tri-state checkbox
  TabAtkins: can do arbitrary stuff with this
  TabAtkins: Only remaining property is toggle-group
  TabAtkins: modifies how a toggle act so that it behaves more like a
             radio-button
  TabAtkins: only one can be active at a time
  TabAtkins: anything active sets others to inactive

  TabAtkins: Finally, for a very common thing to do is control whether
             an element is visible or not based on a toggle
  TabAtkins: in order to accommodate that in a semantic way and
             integrate in other way
  TabAtkins: We have the toggle-visibility property: takes a toggle
             name and potentially a value, and whenever it's active the
             element is shown or not shown
  TabAtkins: connection is 2-way, just like content-visibility:auto,
             where find-in-page will automatically start showing
  TabAtkins: If something not currently being shown, but would want to,
             we automatically trigger the item
  TabAtkins: this way your UI is in sync, not only visible but also has
             a thicker border that it's active or whatever other
             styling you wan to do

  TabAtkins: There's a bunch of open issues on the draft, will transfer
             issues when ready for ED
  TabAtkins: just had good discussion with ARIA group, had lots of
             questions
  TabAtkins: but it seems like the possibility of this to make a lot of
             very common and very commonly inaccessible patterns
             automatically accessible and also vastly easier for author
             swill be attractive feature for them
  TabAtkins: So, happy to answer questions
  TabAtkins: when I finish up a11y stuff, especially certain aria
             patterns autodetection, so everyone uses same heuristics
             [will request ED]
  TabAtkins: for now just for review

  fremy: To me, I get the idea of trying to make patterns accessible
         with toggles
  fremy: but to me it doesn't seem possible that something that does so
         many things can actually be made accessible
  fremy: aria attributes depend exactly on what you are doing
  fremy: not different for tab with multiple panels or hid/reveal
  fremy: you need to create connections between trigger button and
         showing/hiding content
  fremy: I don't believe this is possible, because :toggle() can change
         anything
  fremy: depends on state of the DOM when you do it
  fremy: I like the idea in general, I like idea of making accessible,
         the two together don't see like a great match
  fremy: I'd like to see toggle be split up
  fremy: based on the type of effect
  fremy: I don't see a way to just with toggle pseudo-class make all
         possible cases make things accessible
  fremy: On the contrary, think it will make things appear as being
         accessible but not actually be
  fremy: and that's why I'm concerned
  fremy: If you have examples in the spec that show it's possible,
         okay, but uncertain about accepting until prove it can be done
  TabAtkins: That's why I'm not asking for ED yet
  TabAtkins: Me and Aaron believe this is possible
  TabAtkins: and we're going to try as hard as possible on automatic
             inference
  TabAtkins: but we feel pretty strongly that this is a tractable
             problem, and a sufficiently large number of common ARIA
             cases can be inferred with good reliability
  TabAtkins: also fact that current way that it works is that
             practically zero percent ar correctly annotated
  TabAtkins: so literally anything we do will put us in a better
             situation!
  TabAtkins: but we think we can do genuinely good majority of the time
  TabAtkins: hopefully strong majority of the time, will at least be
             close to right, vs literally nothing today
  astearns: fremy can you add some examples you're concerned with?
  fremy: I think I did but can't find right now

  florian: This may be naive question, but seems to me the feature set
           overall is useful
  florian: but confused why parts of this other than toggle are in CSS
           vs HTML
  florian: state management seems like it belongs in the DOM
  TabAtkins: 2 basic reasons why, first is perennial thing that CSS is
             easier to use
  TabAtkins: Years ago I proposed Cascading Attribute Sheets
  TabAtkins: but that's not the main thing
  TabAtkins: toggle, a lot of things is not a semantic thing
  TabAtkins: What you toggle and how can change based on how you present
  TabAtkins: e.g. q&a might be always open on desktop, but compacted on
             mobile
  TabAtkins: so decision of when toggle is not something you make at
             authoring time but based on MQ
  TabAtkins: Same reason why overflow is in CSS

  Bert: I thought about how to solve this toggle problem several years
        ago, didn't get as far as Tab did
  Bert: my apologies for only hearing this proposal until recently
  Bert: but does seem similar to what I tried to do, let me drop a link
  <Bert> -> https://www.w3.org/People/Bos/css3-links-attempt-2002.html
         Hyperlinks in CSS - an attempt from 2002
  Bert: This doesn't deal with DOM APIs or a11y APIs, never got that far
  Bert: but maybe some ideas there that might be useful
  Bert: Also started with different perspective, as you see it's part
        of hypertext proposal of the time
  Bert: was trying to do what hypertext did, but open/close expand in
        place in the document
  Bert: while trying to do that, thought what about expanding to
        multiple states
  Bert: So this is much simpler than what Tab has, as I never got much
        interest
  Bert: doesn't define properties, only a pseudo-class selector, the
        modes in this draft
  Bert: are just numbers, 0 being normal and others being arbitrary
  Bert: you get as many as you declare
  Bert: Many things are not specified, are implicit
  Bert: doesn't say how you change modes, presumably browser notices
        there are multiple modes and allows changing
  Bert: but spec doesn't say how that is done
  Bert: how many modes is also implicit by what's in the stylesheet
  Bert: something figured out automatically
  Bert: ideally browsers notices if 2 modes are not different and
        merges them, but that might be hard to detect
  astearns: Maybe best if Tab reviewed the proposal?
  Bert: Yes, it's very short
  Bert: Things like scope, which TabAtkins has, doesn't have. Scope is
        whatever reachable by selector
  Bert: which currently means only elements after
  Bert: no explicit scope
  Bert: that's it
  Bert: If Tab has interest in looking over, I can try to explain
        anything not clear
  TabAtkins: Okay, looking now! Thanks!

  fantasai: Was wondering about ED
  fantasai: might be useful to keep track of the history of what's
            going on with the draft
  <TabAtkins> Also I can maybe try to do a history transfer, I suppose.
              There are tools that can reproduce commits like that.

  JakeA: In frameworks, they tend to want to declare what state they
         want toggles to be in, e.g. checked attribute
  JakeA: I see you have a place to state the initial value rather than
         current value
  JakeA: is it compatible with this ?
  TabAtkins: There's an easy API to grab toggles and adjust in JS
  JakeA: Not quite the same
  JakeA: I have used this hack that you talk about but done it for forms
  JakeA: is there any interaction of this with form data?
  JakeA: not compatible with React
  <dbaron> you can look at element.toggles.get("togglename").value
  TabAtkins: Not yet
  TabAtkins: right now, you can go check your toggles and paste into
             forms
  TabAtkins: no automatic links
  TabAtkins: but I think that's a reasonable thing to future
  <flackr> I'm not clear, but couldn't react recreate the toggle with a
           new initial value?
  <TabAtkins> only if it blows away the element, flackr
  <TabAtkins> if diffing doesn't blow it away, they can't change the
              value

  fantasai: This looks really cool, glad you're working on the a11y
            aspects
  fantasai: Concerned people will use this for things that ought to be
            in the markup
  fantasai: e.g. the did I buy this ingredient yet list
  fantasai: That really ought to be a checkbox in the document, rather
            than a styling thing in CSS
  fantasai: it's conveying information in the document, not just about
            visual state
  fantasai: Not that we shouldn't have something in CSS where it is all
            about visual state, but how do we allow things that ought to
            be in the document to be there?
  TabAtkins: I challenge the notion that "this should be in the
             document" goes here.
  TabAtkins: The effect on any tool that cares about it semantically
             should be the same
  TabAtkins: CSS already affects a11y tree in certain ways
  TabAtkins: affects whether things show up
  TabAtkins: so the effect of CSS on a11y and semantics in non-visual
             presentations is already there but ill-defined
  TabAtkins: Topic in ARIA is wanting to officially define a CSS a11y
             tree mapping
  TabAtkins: describing CSS effects on it, including toggle
  fantasai: It's not just that
  fantasai: Let's say I want to capture the current state of the
            document to save for later
  fantasai: would be ideal if you could just spit out the DOM
  fantasai: things that represent the state of the document, not just
            where you're scrolled to, but information that's being
            stored. that should be in the DOM
  fantasai: If you're storing just to adjust layout, that's one thing,
            but if you're storing the state of whether you bought an
            ingredient in CSS, that's not right
  fantasai: We should be encouraging good practices, designing our
            technology to make it easy to do the right thing
  TabAtkins: I don't think we should be concerned with serializing DOM
             state
  fantasai: The arch of the Web is that data is in the DOM, and styling
            is in CSS, and there are places where boundaries are
            blurred, but we try our best to put things in the area they
            belong
  fantasai: I can see use cases for toggles that are solely in CSS
            because it's how you're displaying the page, and only about
            the visual presentation, but I'm seeing some of the
            examples in the spec and it's about the underlying
            information in the document
  fantasai: I'm concerned about us doing that in a way that encourages
            authors to do the wrong thing
  <florian> +1 to fantasai

  dbaron: Might be worth looking at examples in the explainer rather
          than spec
  dbaron: I agree with you that there are a bunch of things that you
          can do with CSS Toggles that don't belong in CSS
  dbaron: A lot of other features in CSS have that quality
  dbaron: I think we should try to encourage people to make the right
          distinctions
  dbaron: but I think there are a lot of things that toggle can do that
          do make sense in CSS
  fantasai: I wasn't arguing that we shouldn't toggle in CSS at all
  dbaron: I do think we should make the documentation reflect good usage
  dbaron: I have implemented a prototype of much of the spec in
          Chromium, still some a11y and activation that Tab is trying
          to work out
  dbaron: and also haven't implemented toggle-visibility, quite
          interesting and useful
  dbaron: but that's the main thing I've been working on the past month
          or so

  heycam: Comments about state living in CSS or the DOM make me wonder
          if the design of this feature could be extended to do either
  heycam: and you could design it so that e.g. data attributes in the
          DOM are used to store state
  heycam: That won't help authors select the right one, you would have
          to select the right storage mechanism but maybe that's one
          alternative
  TabAtkins: You can get the toggles off the element in the DOM, but
             not HTML syntax
  TabAtkins: I don't think we should care about that
  TabAtkins: HTML is HTML's concern
  heycam: I would compare it to how form controls work, and checked
          attributes get added and removed and ???
  TabAtkins: Neither of those happen
  TabAtkins: checked only sets the initial state, neither of them are
             updated live
  TabAtkins: it's annoying :)

  dbaron: I realized I didn't finish
  dbaron: the prototype I have is intended to be experimental, goal of
          implementing was to figure out whether it addresses bunch of
          use cases we think it addresses
  dbaron: and also to help sort out some of these a11y issues
  dbaron: to have something that we can test it on, not implementing
          because we want to ship
  TabAtkins: It's part of some of our medium-term plans, but not
             short-term shipping plans
  dbaron: I also have to go now [to another meeting]!

  astearns: Wanted to talk about next steps, Tab you're going to be
            working on things, and some point will ask for ED?
  astearns: Wondering whether the point, should we have a joint
            CSS-ARIA meeting?
  astearns: since both groups will have concerns
  TabAtkins: I wouldn't be concerned, will be talking with ARIA anyway
  <tantek> +1 to joint CSS-ARIA meeting for toggles
  astearns: Thanks for presenting this, looking forward to it

CSS Contain
===========

  florian: Before we dive into issues, goal of this session is to
           republish
  florian: Last publication was December 2020
  florian: many changes editorial, many have WG resolution
  florian: but while reviewing the whole thing for publication, which I
           hoped I could just do
  florian: I found 3 changes which either don't have a resolution or
           not fully backed
  florian: so I'm hoping the WG to agree to publish, possibly with
           these 3 issues being closed
  florian: They've been in the ED for awhile, they've had some
           discussion, so hopefully we can resolve to publish and if
           something is wrong will publish later

Interaction between content-visibility and overflow-clip-margin
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5271

  florian: Content-visibility can hide stuff in some cases
  florian: and there was a discussion about when box gets close enough
           to viewport, when do you take into account
  florian: Question is which box
  florian: Initially spec said "border box", but I think later it
           should have been "padding box"
  florian: but since then we've added overflow-clip
  florian: and this was aligning the area we care about for painting to
           both use overflow-clip-margin
  florian: I believe this is fine and non-controversial
  florian: proposed that element is considered on-screen if paint
           containment box [missed the rest]
  florian: instead of overflow clip edge, previous version said
           border box

  PROPOSED: use overflow-clip edge instead of border-edge for
            determining whether box is onscreen
  <flackr> +1
  TabAtkins: Overflow clip edge is term of art linked to
             overflow-clip-margin
  astearns: Other questions?
  astearns: Objections?
  fantasai: +1

  RESOLVED: Use overflow-clip edge instead of border-edge for
            determining whether box is onscreen

content-visibility should pause css animations in subtree
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5611

  florian: We had that discussion and had a solution, but afterwards
           discussion because some things weren't clear
  florian: Tab made edits based on subsequent discussion, so had
           resolution on fundamentals
  florian: but commit contains more
  florian: I suspect it's fine, but precise thing in the spec is beyond
           what we resolved in
  florian: Suggestion is if you care about it, please review it, and
           open a new issue if you don't like it
  <TabAtkins> original edits:
https://github.com/w3c/csswg-drafts/commit/82fc7ddb1abf9ce0c3f616cbd91a0f1d2069a215
  <TabAtkins> subsequent edits:
https://github.com/w3c/csswg-drafts/commit/1ef126260e59fb486bc3749d731b8ba22556d92a

  RESOLVED: Accept edits, if any issues open a new issue

Do we need a resolution for this commit?
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7576

  <TabAtkins> this commit:
https://github.com/w3c/csswg-drafts/commit/84e3e7838f35e502f11983c2cd91d34055e1e4b8
  fantasai: It's a note, who cares!
  florian: It makes the note normative
  chris: But it starts with "Note that"
  florian: It says something useful, but ...
  astearns: Proposed to accept the change and work on it further
  chris: Not objection, but suggest to remove "note that" if it's not
         a note
  * chris Suggests s/Note that elements/Elements
  florian: It seems to need more work
  florian: should say something more like mustn't happen
  fantasai: I say we leave the issue open for editorial work and
            publish anyway
  florian: I believe everything else is either editorial or resolved,
           so would like a new WD

  RESOLVED: New WD of CSS Contain L2, editors to work on that "note"

Values & Writing Modes
======================
  scribe: TabAtkins

Revisit decision to use 永 instead of 水 as the ic unit
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7577

  astearns: So issue is whether the change the current "water"
            character used as the ic reference to the "eternal"
            character.
  astearns: I propose we make this change, don't see a reason not to.
  heycam: It generated a surprising amount of confusion.
  heycam: Just because it looks so similar to the typical one used for
          calligraphy
  [looking for Myles]
  [reviewing elika's comments in the thread]
  astearns: My take on her input is that it would be fine either way;
            we did have reasons for that particular character, but
            there aren't reasons not to use the other one
  TabAtkins: One reason in the thread is that the water character is
             prioritized higher in CJK split fonts, so it's more likely
             to have been loaded already, versus the eternal character
  astearns: It was noted that this isn't necessarily problematic, fonts
            can change
  TabAtkins: Sure, they could put any char there. But it's not there
             now.
  heycam: I think we should change; I think it's unlikely we'll
          encounter situations where fonts have different glyph
          coverage that is an actual problem.
  heycam: And without the change we'll likely get a slow trickle of
          people asking why we're using that character.

  [fills in myles on context]
  myles: I think approximately zero people will notice either way
  astearns: A decent number of people seem to have noticed our current
            value and would welcome the change.
  astearns: And the only technical argument against the change is the
            bit about it being more quickly loaded in many situations.
  astearns: But it's been argued convincingly to me that it's an
            artifact of current font subsetting.
  astearns: And something that could change.

  [fills in fantasai]
  fantasai: Depends.
  fantasai: First, do people actually want to implement the change?
  fantasai: I heard someone say they want to change the spec but they
            won't change impl
  astearns: Is it testable?
  fantasai: Yes
  myles: You make a font with different characters
  astearns: Is it testable with current existing fonts?
  heycam: In a subsetting situation and you forget a later one that has
          the eternal in it, but seems unlikely
  myles: I think it's fine to change and see if problems arise

  fantasai: Second reason is there is the ideographic character face
            top line and bottom line, which are two metrics we need for
            alignment of CJK characters
  fantasai: If those metrics aren't in the font, we might have to
            measure them.
  fantasai: So if you have to measure, is it better to measure water,
            eternal, or does it not matter?
  fantasai: It will matter, since they have different shapes
  fantasai: Which is better? We should ask Ken Lunde or someone at Adobe
  fantasai: because that's a practical implementation
  fantasai: It would be great symbolically if we use eternal, but if it
            objectively gives us worse results we shouldn't use it
  myles: What were the metrics?
  fantasai: ICFT line
  fantasai: [describes the ICFT]
  fantasai: The characters are drawn in the box, slightly inside the
            em square

  astearns: For this issue, the character we use for ic extent doesn't
            necessarily specify what the UA would use for this purpose
  fantasai: Right but if we used a different character for each usage,
            that's not amazing
  astearns: My point is there might be an even different character
            better for that, as it's more close to the edges
  astearns: So is one or other of these chars more or less likely to
            hit what the browser will use for this approx?
  fantasai: I looked at a bunch when studying this, and a lot you'd
            think would be good are actually *smaller* than water
  fantasai: Like the one that's just a box, due to optics it's actually
            smaller than the ink extent of water and eternal
  fantasai: So I tried to find a char that used as much space as
            possible, and was reasonably frequent, that's how I got
            water
  fantasai: Don't have a problem with eternal, just want confirmation
            this won't give us worse results for other purposes

  drott: In trying to figure out this change, it seems like one of the
         concerns is people coming across the spec and taking issue
         with the char.
  drott: So maybe being less specific and just saying "a representative
         character"
  fantasai: We want interop, and don't want people to pick a bad char
            without giving thought
  fantasai: Same as for ch unit, we didn't say a representative char,
            we said 0
  myles: Unsure how interop measuring ink is in reality because
         browsers can use diff points
  myles: Also in OT, some points can have semantic meaning beyond just
         glyph bounds, which browsers would want to use
  fantasai: Yeah point is just you don't want the ONE character, for
            example, because it's a horizontal line. So we want the same
            char for all implementations.

  fantasai: It's definitely not very much difference. But I want
            somebody who knows how they're typically drawn to confirm
            it won't be a regression.

  myles: So 2 options are character that's representative of ic and the
         other metrics we're interested in, or use separate characters
         for each.
  astearns: We're not speccing the char for the box dimensions if the
            info's not available in the font.
  fantasai: The ic unit is different from the icft, different from the
            advance width
  fantasai: Better to use one char for all of these, rather than diff
            for each.
  astearns: But right now we only specify ic, right?
  fantasai: No, WM uses a char to specify width of tatechuyoko
  myles: Interested in knowing what browsers follow those specs
         right now
  fantasai: If WG wants to change it because people are mad, can do
            that and I won't object, but I think it would be good to
            actually find out if this would be practically better or
            worse.
  myles: This topic isn't urgent, so I don't think we need to push to
         resolve it right now if we want extra info.
  astearns: I'll action myself to talk to Adobe fonts people about
            metrics, particularly when they're not in the font.

  astearns: One clarification, fantasai asked explicitly about willing
            to implement
  astearns: myles you said we should try it and see?
  myles: If the spec changes we're willing to try
  astearns: So no change to the spec today, I'll see what info I can
            get, perhaps someone with Google Fonts connections?

  drott: Yeah, we have some performance concerns of bucketing of
         CJK fonts.
  drott: We haven't done a lot of investigation about this yet, so
         we'll have to look at this more closely.
  drott: But we do currently expect water to be in the first bucket.
  drott: And can see if Google Fonts is willing to make a change to
         keep eternal in the first bucket

CSS Fonts
=========

Some font features should not be disable-able
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7634

  myles: The OT spec describes that some features are "always applied"
  myles: one that is the provoking feature for this issue is rlig, for
         arabic text
  myles: if you disable it, arabic text is totally broken
  myles: But this isn't the only feature described like this
  <chris> https://docs.microsoft.com/en-us/typography/script-development/arabic#features
  myles: Our platform text engine, CoreText, makes it impossible to
         turn off rlig. It's doing you a favor, nobody wants illegible
         text.
  myles: But this makes us fail some WPT
  myles: So I at least want to allow our behavior, but ideally forbid
         these from being disabled.
  chris: Agree. Earlier I was trying to see both sides, but as I did
         that there's lots of ways to produce examples of how you don't
         render text
  chris: It's not that it looks a bit wrong, it completely falls apart.
         So I do think we should forbid disabling these.
  chris: So question is, do we just defer to OT, or do we have a list?
         Then we'd have to keep it up to date as OT changes, which
         gives me pause.
  chris: But I want it testable.

  myles: Is this thought an editorial concern?
  chris: In the issue you gave a link to OT about Arabic, I agree it's
         motivating but there are other examples.
  chris: So do we just point to them? And if so, how do you test?
  myles: We do already normatively reference OT spec
  myles: If we do normatively add a statement forbidding disabling
         based on OT, this would be testable for a specific version
         of OT.
  myles: Don't want to force a link to a specific OT version.
  chris: Right, just don't want a change in 3 years being impossible
         for them to do because we currently allow it.
  myles: I think there's enough overlap we're okay

  fantasai: You mentioned there's plenty of situations where authors
            can hurt themselves disabling rlig accidentally
  fantasai: How accidentally?
  chris: copy-paste from an example not realizing it works like every
         other property, not realizing that everything *not mentioned*
         is turned off.
  fantasai: So it turns off all features not turned on explicitly?
  chris: Yes
  fantasai: My recollection is it would leave things as they are and
           only set explicit ones.
  <chris> "The entire property value is set at once. Unlike the
          font-variant properties, there is no way to modify the
          inherited value by adding or removing individual features. "
  <chris> from the spec
  drott: Me and myles both thought that font-feature-settings doesn't
         disable things unspecified, it just changes the things given
         literally
  fantasai: Right, so to turn off rlig, they have to explicitly turn
            it off.

  fantasai: If they're being that explicit, I don't see why to make it
            not work
  myles: Because they've just broken their text.
  fantasai: This is intentionally low level, I feel we should just let
            it be.
  fantasai: But I understand that some platforms don't let it be turned
            off.
  fantasai: So I think we should say that if OT says it's required,
            impls should be allowed to not turn it off.
  fantasai: But I don't think tracking a list of things you can't turn
            off is what we should be doing here.
  myles: I think there's a bit of disagreement about what it means to
         be low level.
  myles: This is certainly lower than font-variant
  myles: But I don't think this should be low enough that authors can
         make their text illegible
  myles: Almost all features that font-feature-settings is designed for
         are swashes or old-style numerals, etc
  fantasai: Those already have dedicated syntax in font-variant, fwiw
  [discussion about specific examples]
  chris: Scientific inferiors for formulas, there's no font-variant for
         that, you need font-feature-settings for it

  fantasai: So you have to really work hard to keep an rlig off
  fantasai: Are people actually doing this?
  TabAtkins: Problem is there's a test for that, and wk is thus failing
             the test
  fantasai: So let's make it optional and remove that test
  <iank> (we don't have to remove the test - but we can mark it as
         .optional)

  drott: Also we have Google Fonts people who want to be able to test
         switching it off and on, agree it's hard to do it by accident
  drott: Also sometimes ligatures aren't put in the right spot, put in
         rlig even tho they should be clig or something, so turning off
         rlig for non-Arabic text can be reasonable.
  drott: So I agree we should make it optional to ignore these features.
  drott: Same position as fantasai
  <fantasai> Proposal is to say that if OpenType mandates a feature,
             the UA is not required to turn it off.
  myles: I think this is the wrong decision, but it's okay
  iank: Clarification we don't have to remove the test, we can mark it
        as optional

  RESOLVED: If OT spec says a feature is required, UAs MAY ignore
            attempts to turn it off.
Received on Tuesday, 25 October 2022 23:01:53 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC