Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[scroll-animations-1] view-timeline-inset as part of view-timeline shorthand? #8926

Closed
fantasai opened this issue Jun 6, 2023 · 6 comments · Fixed by #9189
Closed

[scroll-animations-1] view-timeline-inset as part of view-timeline shorthand? #8926

fantasai opened this issue Jun 6, 2023 · 6 comments · Fixed by #9189

Comments

@fantasai
Copy link
Collaborator

fantasai commented Jun 6, 2023

There's been an issue marked in the draft for a long time, which is whether view-timeline-inset should be a part of the view-timeline shorthand or not.

The key question here should be, do we want casual uses of view-timeline to reset the inset if it has been set already, or do we want it to cascade independently?

Note: For text-decoration, for example, we allow it to reset most of the line properties (line type, style, color, thickness) but intentionally don't reset the position or offset so that flipping decorations on doesn't change the positioning.

@bramus
Copy link
Contributor

bramus commented Jun 20, 2023

It would make sense to add view-timeline-inset to the shorthand.

As for the key question: I think it should reset when omitted from the shorthand, as that’s basically how I expect shorthands to behave. Are there more precedents, other than the mentioned text-decoration shorthand, that don’t reset certain longhands?

@fantasai
Copy link
Collaborator Author

@bramus If it's part of the shorthand, then it will reset. A shorthand always resets all of its longhand properties.

The key question is whether we want it to reset: that's what determines whether it belongs in the shorthand or not:

  • If it's better for insets to get reset every time the author declares a timeline, then it should be included.
  • If it's better for insets to cascade independently, then it should stay separate.

@flackr
Copy link
Contributor

flackr commented Jun 22, 2023

I don't have a good sense for how important it is to cascade independently. I could imagine use cases but it's not clear to me whether they're contrived or not. I lean in the direction of including it, as it feels like it should be part of the shorthand, authors don't have to worry about a previously cascaded inset if they set the shorthand, and they can always make their inset rule cascade after if necessary.

@bramus
Copy link
Contributor

bramus commented Jun 22, 2023

@bramus If it's part of the shorthand, then it will reset. A shorthand always resets all of its longhand properties.

Oof, a relief to hear it was me just misunderstanding that part of the question 😅

Still think it should be included as I don’t see a need for the insets to cascade independently.

@ydaniv
Copy link
Contributor

ydaniv commented Jul 9, 2023

I think that it would be actually a very good idea to make view-timeline-inset as part of the shorthand. For starters, insets can be specified inside view() and then it becomes confusing that they can't be specified in the shorthand.
And second, insets can become very handy for specifying a responsive offset using percentages that are only relative to the scrollport and ignore the subject's size. Now, I'm not sure whether the second point is a case for including them in the shorthand or not - I still think it does.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [scroll-animations-1] view-timeline-inset as part of view-timeline shorthand?, and agreed to the following:

  • RESOLVED: Put view-timeline-inset into the view-timeline shorthand.
The full IRC log of that discussion <TabAtkins> fantasai: when i drafted up the view-timeline stuff I wasn't sure if we wanted *-inset to be part of the shorthand or not
<TabAtkins> fantasai: currently it's not and this issue is open for discussion
<TabAtkins> fantasai: the reasons either way is
<TabAtkins> fantasai: if it's better for the insets to be reset every time the author changes the itmeline name, it should be in the shorthand
<TabAtkins> fantasai: if it's better for them to cascade independently they should stay separate
<flackr> q+
<TabAtkins> fantasai: since i didn't know which was better i opened the issue
<TabAtkins> q+
<bramus> q+
<astearns> ack flackr
<TabAtkins> flackr: i'm not aware of strong use-cases for ti cascading independently
<TabAtkins> flackr: and not having it part of th ehsorthand is an ergonomic issue
<TabAtkins> flackr: so i'm in favor of it being in the shorthand
<astearns> ack TabAtkins
<fantasai> TabAtkins: I agree with what flackr just said
<SebastianZ> +1 on what flackr said.
<fantasai> TabAtkins: I suspect that if you change what you pay attention to, you probably want insets adjusted as well
<fantasai> TabAtkins: when specifying first time, you probably want to specify insets together in one declaration
<ydaniv> +1 on adding
<astearns> ack bramus
<fantasai> TabAtkins: also, if no great reason to make exception to the 'all longhands with this prefix are part of the prefix shorthand'
<TabAtkins> bramus: I was also wanting it in the shorthand for all those reasons
<astearns> ack fantasai
<Zakim> fantasai, you wanted to say about 'auto' initial value removing a lot of the reasons to need this
<TabAtkins> fantasai: I think having "auto" become the initial value for this prop removes a lot of the reasons to have it cascade independently, since it refs scroll-padding and that alleviates a lot of the concerns
<TabAtkins> astearns: so proposed resolution is to put view-timeline-inset into the shorthand
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Put view-timeline-inset into the view-timeline shorthand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

5 participants