- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 31 Jan 2024 17:59:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] [css-view-transitions-2] consider a living-standard model for view-transitions`, and agreed to the following: * `RESOLVED: Keep view-transitions l2 as a leveled delta spec` <details><summary>The full IRC log of that discussion</summary> <Frances> 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?<br> <Frances> khush: A living spec in how html is organized, alot 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.<br> <Frances> khush: delta spec, each new level only includes editions from previous levels. Need to redefine the algorithm and add new steps to it.<br> <Frances> khush: Con if you fix something in l1, would have to copy it to latest algorithm<br> <Frances> 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. dr is completely stable. living spec is nice personally. New implementer can take a spec which has cr.<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to comment that referenceable work need to be in /TR, not ED<br> <Frances> elika: 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.<br> <TabAtkins> q+<br> <Frances> fantasai: level 2 implementation is compliant to implementing all features in level 1, could be more specific or have more features.<br> <Frances> fantasai: start next level as delta spec for convince. Merge all text, with more features and more details, lower level 1 has less.<br> <khush> q+<br> <fantasai> s/convince/convenience/<br> <astearns> ack TabAtkins<br> <Frances> fantasai: delta spec would be my preferred model<br> <fantasai> s/delta spec/splitting by levels in some way/<br> <florian> q?<br> <florian> q+<br> <khush> q-<br> <Frances> tab: 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.<br> <Frances> tab: allow view-transition spec to have a rolling model<br> <Frances> tab: not a 1 vs 2 split<br> <noamr> q+<br> <astearns> q+<br> <Frances> fantasai: need a way to keep the compatibility<br> <florian> q- later<br> <astearns> ack noamr<br> <Frances> tab: might not continue to work reliably. Need a source of truth, not delta spec where porting relevant changes.<br> <khush> q+<br> <Frances> noam: 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.<br> <Frances> alan: 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?<br> <astearns> ack astearns<br> <Frances> fantasai: view-transitions level 1 and then ship and then pick up level 2<br> <Frances> khush: level 1 has set of failing features. Do level distinctions help implementers?<br> <khush> q?<br> <astearns> ack florian<br> <bkardell_> but it's not wrong that that is wonky in practice<br> <Frances> Alan: It is often the intent. Move entirely sure stuff to the next level. Testable and can be interoperable.<br> <vmpstr> q?<br> <Frances> 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.<br> <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.<br> <vmpstr> q+<br> <astearns> ack khush<br> <Frances> khush: Have an algorithm to cache element, could be difficult to patch across algorithms.<br> <Frances> khush: fresh algorithm to add, prefer one living spec<br> <Frances> khush: Us implementers are used to working with the model<br> <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"<br> <Frances> alan: 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.<br> <florian> q+<br> <astearns> ack vmpstr<br> <Frances> khush: feature that has already been defined, as implementer in the implementation first vs second feature, what mental model is easier to work with?<br> <Frances> Vladimir: 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.<br> <astearns> ack florian<br> <Frances> 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.<br> <Frances> 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.<br> <khush> q?<br> <Frances> 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 stable section is low. Can mature small pieces and land progressively.<br> <khush> q+<br> <Frances> fantasai: syntax could be maintained, when developing significant new features.<br> <fantasai> s/table section/change/<br> <Frances> florian: changing core progressively and could be uncomfortable<br> <astearns> ack ntim<br> <astearns> ack khush<br> <Frances> tim: 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.<br> <Frances> 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.<br> <astearns> ack fantasai<br> <Frances> tim: sounds good<br> <Frances> fantasai: In earlier phases of the spec development, do whatever is easier to communicate.<br> <Frances> fantasai: Make clarifications in level 1 to make features in level 2 easier to understand.<br> <Frances> khush: cut the line for l2 also<br> <Frances> fantasai: seems fine<br> <fantasai> s/communicate/edit or communicate, wrt describing a diff or rewriting a section/<br> <Frances> alan: Could be put in with an at risk label, and as soon as it would make sense for the editors.<br> <Frances> fantasai: level 1 is in tr and cr.<br> <fantasai> https://www.w3.org/TR/ vs https://drafts.csswg.org/<br> <Frances> tab: tr is on the w3c site vs in editor's draft repository<br> <fantasai> WD, CR, PR, and REC are all on /TR ; ED is Editor's Drafts<br> <Frances> Alan: pr is proposed recommendation for next step<br> <Frances> khush: As another implementer implements spec would be more completely stable. Make l2 and copy everything over.<br> <Frances> florian: graduate status would be to graduate from what is currently is, would be a good model.<br> <Frances> PROPOSAL: Keep view-transitions l2 as a leveled delta spec<br> <Frances> Alan: Any objections?<br> <khush> Thank you all!<br> <Frances> RESOLVED: Keep view-transitions l2 as a leveled delta spec<br> <florian> s/graduate status would be to graduate from what is currently is, would be a good model./to skip jargon, we can stay that the model described by kush is right, and the spec will graduate to the next status when those conditions are met<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9850#issuecomment-1919627409 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 31 January 2024 17:59:39 UTC