- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 31 Jan 2024 19:34:05 -0500
- 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.
=========================================
Adopt triage Service-Level Objectives (SLOs)
--------------------------------------------
- RESOLVED: Adopt triage Service-Level Objectives (SLOs) (Issue #9820)
View Transitions
----------------
- RESOLVED: Keep view-transitions l2 as a leveled delta spec (Issue
#9850: Consider a living-standard model for
view-transitions)
====== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jan/0014.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Oriol Brufau
Keith Cirkel
Stephen Chenney
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Paul Grenier
Chris Harrelson
Brian Kardell
Brad Kemper
Vladimir Levin
Alison Maher
Eric Meyer
Tim Nguyen
Florian Rivoal
Noam Rosenthal
Miriam Suzanne
Bramus Van Damme
Jeffery Yasskin
Regrets:
Yehonatan Daniv
Cassondra Roberts
Chair: astearns
Scribe: Frances
Adopt triage Service-Level Objectives (SLOs)
============================================
github: https://github.com/w3c/csswg-drafts/issues/9820
jyasskin: System in place to look at every issue when it comes in and
take to deal with or if it is an open ended issue and force
the deadlines if we miss them
jyasskin: Would like feedback on changes to the design from the
working group, add to fantasai's suggestion to phrase them
in terms of GitHub labels and an automated system.
Everything in discussion looks implementable.
<chrishtr> I'm a big fan of this, it will help us avoid accidental
mistakes
astearns: Sounds great, we can try a few things out. Some might be
useful, some might not.
fantasai: Previously had only agenda+ in a previous upcoming agenda.
Need prioritization especially with 50+ items. Possible
agenda+ urgent. Could be a good change to the labels.
fantasai: With regards to prioritizing all issues, prioritization is
not always obvious currently
jyasskin: Extra agenda+ labels, have a system the other working
groups can adopt, consistent meaning across working groups.
Endorse agenda+ later or low priority.
jyasskin: Expect that the default label does not have a deadline and
default of no deadline
Florian: agenda+ may mean we have discussed asynchronously enough,
put it in the call. Or possibly that we need to ship, need a
decision now. Ready for a decision vs we need a decision now.
Florian: Has to be different than a company such as in x weeks. Need
to give enough room from some that are late. Focusing on
triage is more important.
jyasskin: Can't assign work, this is volunteer. Labels are under the
control of the working group, companies can't assign labels.
jyasskin: Create a blocksshipping label for a higher priority label.
fantasai: Rather than blocks shipping, possibly urgent instead, since
things can be urgent for different reasons, not only
blocking shipping
jeffrey: There is already an urgent label. agenda+ and urgent labels
are reasonable set of labels
astearns: Other comments?
jyasskin: Adopt labels and label things. Label everything with
priority eventually label and label them as they are
triaged.
fantasai: Something can be urgent but not important and vice versa.
Two axis. But I think you want one axis.
jyasskin: Want to something better than numbers, can possibly go by
numbers.
Florian: If something is urgent, need it soon. Might not be urgent to
everybody, but is important to at least one person in the
WG, need to answer it quickly.
jyasskin: Might make sense to use eventually label.
fantasai: Agree, makes sense. But importance is a different axis, so
if need a level between Urgent and Eventually that means
Soon, just call it Soon?
Chris: Urgent and important are names for p0 and p1. urgent means it
needs to happen soon. It is on the same axis.
chrishtr: Concept of soon, concept of right away, and pick names.
jyasskin: Possibly rename priorities to soon, eventually, and right
now
chrishtr: asap one is used sparingly, could cause a compat risk. Need
to possibly indicate when getting done soon. Vs eventually
does not need to get done as soon.
florian: Plenty information to triage things accordingly.
<bradk> “Eventually” means could be years?
<jyasskin> bradk, Yes.
fantasai: For all Agenda+, handling soon is good, because otherwise
lose context and discussion is weak. Should not have so
many issues for agenda+. Outside of agenda+ in issues and
triage, editor needs to handle things as separate. Priority
just sits on issues outside Agenda+ also, would be expected
to affect triage I suppose.
jyasskin: Could use agenda+ instead of soon.
<schenney> Sorry, there are two distinct concerns in my mind. One is
"what do we do now" and one is "how do we have data to
inform future decisions". We need to consider the latter
even if we don't act on the data.
astearns: Any objections?
RESOLVED: adopt this triaging tool
PROPOSAL: Adopt triage Service-Level Objectives (SLOs)
RESOLVED: Adopt triage Service-Level Objectives (SLOs)
View Transitions
================
Consider a living-standard model for view-transitions
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9850
khush: How to organize spec for view-transitions. Features need to
add steps to algorithms defined in the L1 spec. How should we
structure and make the spec look?
khush: A living spec in how html is organized, a lot of precise
algorithms, edits directly to the spec. Possibly editors draft
while incubating new features. Working group can do one pr for
a stable feature to a living spec.
khush: delta spec, each new level only includes editions from
previous levels. Need to redefine the algorithm and add new
steps to it.
khush: Con if you fix something in l1, would have to copy it to
latest algorithm
khush: Full spec, add new features on top of it. One source of fruit
spec. Delta spec model will remain a working draft as the
features happen. tr is completely stable. Living spec is nice
personally. New implementer can take a spec which has cr.
fantasai: One constraint is that any spec that is being referenced
outside of the working group needs to be a working draft or
a cr. Working drafts are scratch space. We should not be
editing editor's specs.
fantasai: level 2 implementation is compliant to implementing all
features in level 1, could be more specific or have more
features.
fantasai: Start next level as delta spec for convenience. Merge all
text, with more features and more details, lower level 1
has less.
fantasai: Splitting by levels in some way would be my preferred model
TabAtkins: Issue with description conforming to level 1 vs level 2 is
irrelevant distinction for web compatibility. Delta spec
is useful for organization in many cases. Spec with
complex algorithms need to be edited and looked at
closely. If inconvenient in some cases. Would like to
adopt living spec model. What is the css syntax matters in
terms of syntax rather than historically.
TabAtkins: Allow view-transition spec to have a rolling model
TabAtkins: not a 1 vs 2 split
fantasai: Need a way to keep the compatibility
TabAtkins: Might not continue to work reliably. Need a source of
truth, not delta spec where porting relevant changes.
noamr: Can find a different way to help implementers so spec isn't
always in flux. Implement tr spec, if we change an algorithm,
we can describe what is needed in the algorithm.
astearns: Levels work best for separate features. Expected an
implementer is going to start with level 1 and then stop.
Is it the case for view-transitions?
fantasai: view-transitions level 1 and then ship and then pick up
level 2
khush: level 1 has set of failing features. Do level distinctions
help implementers?
astearns: It is often the intent. Move entirely sure stuff to the
next level. Testable and can be interoperable.
<bkardell_> but it's not wrong that that is wonky in practice
florian: Implementations as being compliant to one another,
implementing level 2 is not compatible with implementing
level 1. Define a bunch of features in level 1, level 2 is
things in progress. When stable, go to level 3 and keep on
moving.
<TabAtkins> My point of "whatever is in the pile labeled 'level 1'
isn't relevant, it's whatever the web expects" still
stands to this point, Florian.
khush: Have an algorithm to cache element, could be difficult to
patch across algorithms.
khush: fresh algorithm to add, prefer one living spec
khush: Us implementers are used to working with the model
<noamr> Both ifdef and levels would "work", but ifdef keeps one
source of truth, and divides implementations by features and
not by an artificial notion of "levels"
astearns: Your example would work as a leveled algorithm, such as is
necessary for level 1 vs level 2. New algorithm to pay
attention to when going to next level.
khush: Feature that has already been defined, as implementer in the
implementation first vs second feature, what mental model is
easier to work with?
vmpstr: For l2 algorithm, could go over steps that are required,
could happen to overlap in 80% of cases. Help implementers in
the algorithm. Living spec model could help, and deviate
later on.
florian: Patent policy, if we want the most up to date version and
make it different in level 2, it is possible. If the spec
doesn't reach level 2, the patent policy might not be
implemented, and could not make it to cr with no patent
commitment.
florian: What is added needs to be mature, if in level 2, the most up
to date algorithm would not be in level 1, it would be in
level 2. Would have to maintain both to some degree.
florian: An alternative would be to mature things and reviewers and
people trying to use the spec. Different in syntax don't
know what status of spec is, but maintaining as cr or later
is doable. Rate of change is low. Can mature small pieces
and land progressively.
fantasai: Syntax could be maintained, when developing significant new
features.
florian: Changing core progressively and could be uncomfortable
ntim: Like having something stable to work from. Such as level 1
staying as it is, I don't mind level differing. If we need to
change the core of the spec in general, it would be a sign that
the spec matured too quickly.
khush: If the group is navigating to keeping it leveled, keep l2 to
public working draft. Any algorithms that need to change could
be okay. Redefine things in l2.
ntim: Sounds good
fantasai: In earlier phases of the spec development, do whatever is
easier to edit or communicate, wrt describing a diff or
rewriting a section.
fantasai: Make clarifications in level 1 to make features in level 2
easier to understand.
khush: Cut the line for l2 also
fantasai: seems fine
astearns: Could be put in with an at risk label, and as soon as it
would make sense for the editors.
fantasai: level 1 is in tr and cr.
<fantasai> https://www.w3.org/TR/ vs https://drafts.csswg.org/
TabAtkins: tr is on the w3c site vs in editor's draft repository
<fantasai> WD, CR, PR, and REC are all on /TR ; ED is Editor's Drafts
astearns: pr is proposed recommendation for next step
khush: As another implementer implements spec would be more
completely stable. Make l2 and copy everything over.
florian: To skip jargon, we can stay that the model described by
khush is right, and the spec will graduate to the next
status when those conditions are met
PROPOSAL: Keep view-transitions l2 as a leveled delta spec
astearns: Any objections?
<khush> Thank you all!
RESOLVED: Keep view-transitions l2 as a leveled delta spec
Received on Thursday, 1 February 2024 00:34:41 UTC