- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 25 Oct 2022 19:01:10 -0400
- 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