- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Nov 2022 17:26:10 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `JS API for view-timeline-inset`, and agreed to the following: * `RESOLVED: Insets accept either a string containing CSS, or a sequence of TypedOM values.` * `RESOLVED: Accept fantasai's proposal for resolution 2` * `RESOLVED: Defer adding inset properties to the timeline object` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: JS API for view-timeline-inset<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7748#issuecomment-1306097703<br> <TabAtkins> flackr: Proposal was to allow insets in the ViewTimelineOptions object as either a string or a pair of CSSNumericValues<br> <TabAtkins> flackr: But I recalled on other issues there were parsing concerns for things other than idents<br> <TabAtkins> flackr: So i pinged Tab on this issue<br> <TabAtkins> flackr: So yes we should add this attr, but should it support strings?<br> <fantasai> scribe+<br> <fantasai> TabAtkins: While we aren't 100% consistent, we try to avoid doing CSS parsing on small instances of CSS values<br> <fantasai> ... in APIs like this<br> <fantasai> ... because in the rare cases where you need to do an escape, it needs to be double-escaped<br> <fantasai> ... The general rule for identifiers is that we don't parse stirngs [missed]<br> <fantasai> ... You can express any string as an ident if it's properly escaped<br> <fantasai> ... [something else]<br> <fantasai> ... So I proposed not allowing string-based values here, and just sticking with the TypedOM objects<br> <fantasai> ... They're easy to work with<br> <fantasai> flackr: should still allow string for auto<br> <fantasai> TabAtkins: especially because we need to allow identifiers, we'd need to do string parsing in identifiers<br> <fantasai> ... if you wanted a name with a weird thing, would need to double-escape<br> <fantasai> ... would have string just be the literal value of the string<br> <fantasai> ... which means we can't mix keywords with other values in strings<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: I think the arg for wanting to allow string-based is that you can pipe getComputedStyle() right back into it<br> <TabAtkins> fantasai: and just easier to write as a literal "2px" rather than CSS.px(2)<br> <TabAtkins> fantasai: re ident escaping concerns, there's no custom idents in this API so escapes are never necessary anyway<br> <Rossen_> q?<br> <flackr> q+<br> <TabAtkins> flackr: I'm a little curious - if we want to use typedom objects going forward, is there easy ways to get that?<br> <fantasai> TabAtkins: There's a TypedOM for computed style<br> <fantasai> ... not all values have that defined, but for simple things it should work<br> <fantasai> ... for more complex ones, will just get a string<br> <TabAtkins> flackr: so maybe that alleviates some simple concerns<br> <TabAtkins> fantasai: Well what's the computed style of -inset? It's one or two values, so what will we get out of typed om computed style?<br> <TabAtkins> flackr: this is a new property, we can define it to be what we want for the input<br> <TabAtkins> fantasai: So what would that be?<br> <TabAtkins> flackr: A sequence of numeric or identifer values<br> <Rossen_> ack flackr<br> <dbaron> https://developer.mozilla.org/en-US/docs/Web/API/CSS_Typed_OM_API#browser_compatibility<br> <TabAtkins> flackr: So I propose we onlya ccept the typedom representation, and specify the computed typed om for the property to give the same values, to support passthru<br> <TabAtkins> dbaron: is the API not gonna work right if the impl wants to do this without typed om?<br> <TabAtkins> dbaron: I ask because typedom is implemented right now in chromium but not gecko or webkit<br> <TabAtkins> flackr: sounds like it would be an issue<br> <iank_> I believe webkit has an implemtnation just not shipped yet<br> <TabAtkins> fantasai: What's the downside of stringbased?<br> <TabAtkins> fantasai: If we have both you can use whichever is easiest<br> <ydaniv_> +1 for both<br> <TabAtkins> TabAtkins: my only concern is impl complexity, and slightly being more consistent about parsing css vs taking strings literally, but i can go either way<br> <fantasai> Proposed to accept both string and TypedOM 2-value sequence inset within ViewTimeline Options<br> <TabAtkins> PROPOSED RESOLUTION: Offsets accept either a string or a sequence of typedom values<br> <fantasai> s/Offsets/Insets/<br> <TabAtkins> chrishtr: Do we need to specify how the string is parsed?<br> <TabAtkins> flackr: Matches the CSS property<br> <TabAtkins> RESOLVED: Insets accept either a string containing CSS, or a sequence of TypedOM values.<br> <fantasai> Proposed that existing ViewTimeline.startOffset and .endOffset attributes incorporate inset calculations (so that they continue to accurately represent the start/end scroll offsets of the ViewTimeline within the scroll container).<br> <flackr> +1<br> <ydaniv_> +1<br> <bramus> +1<br> <TabAtkins> RESOLVED: Accept fantasai's proposal for resolution 2<br> <Rossen_> s/Accept fantasai's proposal for resolution 2/Existing ViewTimeline.startOffset and .endOffset attributes incorporate inset calculations/<br> <TabAtkins> fantasai: final, do we expose the viewtimelineoptions on the timeline itself? doesn't seem to be use-cases. But we *could* add an inset or startInset/endInset to the timeline if we wanted to.<br> <flackr> +1 to deferring for now<br> <fantasai> s/viewtimelineoptions/inset values/<br> <flackr> (this is resolution 3 from https://github.com/w3c/csswg-drafts/issues/7748#issuecomment-1306097703 )<br> <TabAtkins> fantasai: not sure if it needs to be done or not, so unless someone thinks it's important we recommend resolving not to do it for now<br> <TabAtkins> RESOLVED: Defer adding inset properties to the timeline object<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7748#issuecomment-1325424372 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 November 2022 17:26:12 UTC