Meeting minutes
fantasai: Tim wanted to publish a FPWD of Forms?
astearns: yup, people should weigh in on the issue
astearns: will take it up next week
<fantasai> w3c/
astearns: maybe should have co-editors?
fantasai: I think jarhar has been co-editing, functionally speaking
astearns: Luke would be a possibility too, they've been doing PRs. I'll get some co-editors together for next week.
<astearns> https://
astearns: First - register for NY meeting
astearns: Attending in-person *or* virtually, put availability in the wiki so I can construct the agenda
github-bot, take up w3c/
[css-view-transitions-2] view-transition-name: auto when matching id should namespace
<github-bot> OK, I'll post this discussion to https://
vmpstr: we added v-t-name:auto
vmpstr: matches the VT name based on the element's ID attribute, and acts as match-element otherwise
vmpstr: this name isn't exposed anywhere, it's "auto" in serializations
vmpstr: but wanted to clarify that the ID ident shouldn't match another VT that specifies a manual ident that happens tob e the same
vmpstr: Like `v-t-name: foo` on one element and `v-t-name:auto` on an element with id="foo" shouldn't match
astearns: looks like there's agreement in the thread
sounds fine to me
astearns: anyone in the room actually want the behavior we're prohibiting?
no opinion either way, really, happy to defer to editors
<bkardell_> makes sense
<noamr> +1
fantasai: I thought that's what we'd adopted originally, that the ID would only be used to link elements together, not something exposeable to other CSS. So this makes sense to me.
vmpstr: proposed: v-t-name:auto will never match an explicit v-t-name:<ident>
astearns: any objections?
RESOLUTION: v-t-name:auto never matches an explicit v-t-name:<ident>
github-bot, take up w3c/
[css-align][css-anchor-position] Default safety and fixpos
<github-bot> OK, I'll post this discussion to https://
<noamr> TabAtkins: a corner case in anchor positioning, common in certain situations. original containing block, plus "safety". If something overflows the containing block it can still overflow until its original containing block
<noamr> TabAtkins: the problem is that for fixed positining you'd get some bad behavior, because the original containing block is the viewport. if you scroll a bit you'd get bad overflowing behavior
<noamr> TabAtkins: proposing to always to default a fixed pos element to unsafe element, rather than default to the medium safety
<noamr> TabAtkins: this shouldn't have real effects to users of the feature, the element should remain on screen when possible, but it's a bit of a tweak
<noamr> astearns: is this modifiable by the author?
<noamr> TabAtkins: this is just the default behavior if you don't say safe/unsafe on one of the alignment keywords
<noamr> TabAtkins: we shouldn't have the default do the wrong thing for common scenarios. We just propose to change the default safety
<noamr> fantasai: re-adjust it to be as if it was safe?
<noamr> TabAtkins: the medium safety is correct but can't be implemented. current definition of medium safety rely on layout information but not on scroll information
<noamr> TabAtkins: anchor position can respond to scrolling. in order to do the medium safety, it can't work in the way defined in the space. We need to define it as unsafe in the layout and then correct it using the scroll adjustment behavior
<noamr> TabAtkins: rather than layout time behavior creating the medium safety, it needs to be created by scroll adjustment, in order to be compositable
<fantasai> w3c/
<fantasai> This never got resolved either
<noamr> fantasai: I am glad that we're not changing the user observable behavior; no opinion about how we get there
proposed: change the way medium-safety alignment is handled to instead invoke the scroll adjustment machinery when handling an anchorpos fixpos element
(note to the above IRC-only comment; the resolution was in the preceding comment, the edits were for that)
RESOLUTION: change the way medium-safety alignment is handled to instead invoke the scroll adjustment machinery when handling an anchorpos fixpos element
github-bot, take up w3c/
[css-text-4] [text-autospace] Spacing across element boundaries for BiDi content
<github-bot> OK, I'll post this discussion to https://
fantasai: so text-autospace inserts spaces between "changes" in a script
fantasai: if you ahve chinese with a little englihs, there should be some gap around the english otherwise it feels cramped
fantasai: q is what to do with bidi text
fantasai: we dont' insert space between chinese text and a *symbol*, only between chinese text and a letter
fantasai: so if you had a stretch of rtl text, like hebrew that ends with a symbol
fantasai: and you give it a direction so it all flips
fantasai: so symbol is on the left, hebrew letters on the right
fantasai: chinese text before and after
fantasai: if you insert space before reordering, you'll put it on the left side, which ends up between the chinese text and the symbol, while the hebrew and chinese dont' get a space
fantasai: so correct answer is to manage the sapce in visual order, after bidi reordering
fantasai: this is challenging, it interacts with linebreaking in awkward ways. hard to get perfectly right without maybe some backtracking
fantasai: so i think th e correct answer is visual spacing
fantasai: for practicual purposes, might tolerate getting it wrong in some complex cases
florian: do we need to spec the allowance for getting it wrong?
florian: or jsut spec the right thing and expect people to get it wrong sometimes, but they should still try?
fantasai: i'm not sure
fantasai: i think it's important to maek sure we get right - if both sides require spacing, it's done correctly, never get double space on one side
fantasai: that's minimum bar
astearns: I think we should specify what we want to see, without allowance, and only do that "getting it wrong is allowed" part if we have to
fantasai: i think that's reasonable.
fantasai: if authors are running into problems with certain cases, they can complain, and then we'll know those cases matter.
astearns: so proposed resolution is we specify that autospacing is done after bidi reordering
astearns: and you should never double auto-space any side
fantasai: yeah, that's implied
florian: do we want to add a note about it being hard?
TabAtkins: Useful to acknowledge if something is significantly difficult
TabAtkins: Here be dragons, when implementing
fantasai: i think they'll notice
astearns: would be good to have at least one example, hopefully we can find a real-world example
florian: could have a note which is less silly than my earlier phrasing. "CSSWG acknowledge that the interactino of this with line-breaking may be challenging to implement"
fantasai: or, as bkardell suggests, literally say "here be dragons"
astearns: [restates proposed reoslution]
RESOLUTION: autospacing happens *after* bidi-reordering, and we'll add a complex example to the spec
Sizing
github-bot, take up w3c/
[css-sizing-3] Content contribution of min-inline-size:fit-content and max-inline-size:fit-content
<github-bot> OK, I'll post this discussion to https://
oriol: when you're computing intrinsic cocntirubtion of a fit-content element, what should happen?
oriol: if you use fit-content on the preferred sizing property, it's clear that for the purpose of computing min-content contribution, you treat it as min-content; for max-content contrib, you treat it as max-content
oriol: but if you use this keyword on min or max sizing properties, it's less clear what shoudl happen
oriol: what webkit does is it just ignores the keyword, so in a min property it treats as 0, in max it treats it as none
oriol: blink used to have the same behavior, but changed to align with firefox
oriol: firefox beahvior is, when computing intrinsic contribs, fit-content acts as min-content in min sizing property, and as max-content in a max sizing property
oriol: i was implementing in servo and i think there's a better behavior, and i think it's what's actually specified in the spec, and is a bit simpler to implement
<oriol> w3c/
oriol: some testcases ^^^
oriol: in this testcase, magenta wrapper has a fixed width - first very narrow, then between, then wider
<3 Oriol's examples
oriol: element with black border is inline-block, so shrink-to-fit
oriol: the inline-block contains one element with `width` to a huge amount, and max-width:fit-content
oriol: so webkit ignores the max-width so the width makes it all explode
oriol: gecko and blink treat it as max-content, so the inline-block is always sized as max-content
oriol: i think the servo column is better. do the smae for the three sizing props
oriol: you always treat it as min-content when doing min-content contribution, and similar for max, for all three properties
oriol: so if magenta wrapper is narrow you'll use the min-content contribution, if wide you'll use the max-content contribution, and if between it'll be between
oriol: i think this is a better match for fit-content, trying to fit into the container
oriol: so i propose the spec is right, and servo is right, and other browsers should match
fantasai: thanks for the fantastic examples
fantasai: as editor, i think Servo's impl is correct. it reflects the author's request
fantasai: in 2.1's definition of min/max sizing properties, it says you literally run layout by subbing in the value for 'width' and then clamp appropriately; this matches that behavior as well
iank_: I think this is likely fine.
iank_: hopefully no compat issues, but on the surface it's not too difficult for us to do
astearns: so are we resolving the spec is correct?
oriol: yes
iank_: it's not obvious to me that the spec is correct, so clarifying would be good for the future
oriol: at end of th eissue i posted the quote of the spec that i think is backing the servo behavior, we can clarify or add some examples
examples++
fantasai: the spec doesn't make a distinction between what fit-content size means based on property, so i don't think it can support an interpretation that it works differentyl in the different properties
astearns: so let's make that explicit
astearns: so proposed resolution is we add examples like Oriol's and make the implication clear in the spec
RESOLUTION: No normative change to spec, but add example like Oriol's and make the implication clearer in the spec.
github-bot, take up w3c/
[css-sizing] How to transfer intrinsic keywords via aspect ratio?
<github-bot> OK, I'll post this discussion to https://
iank_: replaced elements ahve three things
iank_: natural width, natural height, natural aspect ratio
iank_: you can have a natural widht of 20, height of 10, and ratio woudl be 2/1
iank_: it used to be possible (in svg, at least) to have the natural sizes not match the aspect ratio
iank_: this is more of a problem now with aspect-ratio proeprty
iank_: can have natural width/height of 20px and 10px, and an aspect-ratio proeprty of 1/1
iank_: so what happens
iank_: there's places where you're sizing a replaced element where you only llook at natural sizes, but then the aspect ratio comes in (to transfer min-height to a width, for example), and they're disjoint
iank_: there's a step which normalizes the natural sizes and aspect ratio
iank_: I think simplest answer is we coerce the natural sizes to match the aspect ratio
iank_: so if your natural sizes are 20px/10px, and aspect-ratio is 1/1, we coerce the block size to match and it becomes 20px/20px natural size
iank_: we have this normalization step for SVG. you can specify only a natural width, no natural height, yes natural aspect-ratio, adn we harmonize the three together
iank_: so I think we should do the same when all three are specified but disagree
astearns: when you say you don't care, you example had us adjusting the block natural size
astearns: is the other option adjusting inline size...?
iank_: you could adjust block/inline/width/height
fantasai: or larger/smaller
iank_: mild preference for adjusting block size
fantasai: I think if we do this fixup, adjusting the block size makes sense
fantasai: in most layout algorithms block size is the dependent size
fantasai: aspect-ratio in general works that way, it prioritizes that dependency direction
oriol: yeah in my second comment, i say we adjust the block size when transferring. so i'd prefer to be analogous
<TabAtkins> +1
dholbert: makes sense about aspect-ratio proeprty
dholbert: without aspect-ratio i think this doesn't matter? SVG says to derive the intrinsic aspect-ratio from the intrinsic sizes if they're present, ignoring the view-box. Is that right, Ian?
iank_: I thought there was a case...
iank_: viewbox aspect ratio fo 1/1, width=10 height=0
iank_: in that case the natural sizes are 10/0
dholbert: right, the 0 is equivalent to not having a size, not worried about that corner case
iank_: okay, then yeah i think it's otherwise correct, we can discuss offline if necessary
iank_: a little icky with a 0 width or height, i think we have some compat for it rendering as 0 height, and this would change it to non-zero
TabAtkins: So ignoring SVG complications, we can limit this to just aspect-ratio property?
iank_: I think we want this for aspect ratios generally
iank_: this is part of the nromalization step, svg's a-r comes from the width/height, and only if that doesn't exist does it come from the viewbox
iank_: so now we'll take aspect-ratio property into account
iank_: this can also happen in contain-intrinsic-size, it gives a natural width/height
iank_: so this can't just be for the aspect-ratio property, need fixup to work consistently
<dholbert> this is the SVG spec text I'm remembering RE getting aspect-ratio from width/height (if present), and falling back to viewBox ( https://
astearns: so this just applies to repalced?
[some confusion, but yes]
iank_: proposed resolution: for the final step in determining natural sizes, use the determiend aspect-ratio to coerce the block size to match
astearns: questions? objections?
RESOLUTION: for the final step in determining natural sizes, use the determined aspect-ratio to coerce the block size to match
github-bot, take up w3c/
[css-sizing] Adding a 'size' shorthand for 'width'/'height'
<github-bot> OK, I'll post this discussion to https://
fantasai: wow this was old.
fantasai: not clear what to do here, but people want it solved
fantasai: complication is there's an existing size proeprty in @page rules
fantasai: and it's not equivalent to setting width/height
fantasai: width/height apply to the page area
fantasai: this is implemented by PDF renderers
fantasai: added this after chatting with emilio, who suggested maybe we just treat 'size' in @page specially, so they set a different size property, while everywhere else it's a shorthand
w3c/
fantasai: so wanted to know if it's viable
<ntim> i like the idea
astearns: seems a little icky to have different processing based on where 'size' comes up
astearns: but maybe in this case its' reasonable
(I think there's not really any better solution. Also slightly icked but okay with it for the benefit.)
florian: Yeah, unfortunate, but since the weirdness is so scoped it's probaqbly okay
oriol: in @page, it has descriptors not properties
oriol: so a name conflict isn't *great* but not a big deal technically. can just say that 'size' descriptor and 'size' shorthand are different
emilio: i think this is the onlyw ay to make it work
emilio: but maybe it could be cool to make 'size' in @page a legacy alias for some other name, like 'page-size'?
emilio: that would be easier to implement, I think, then I don't need to deal with the name conflict as much.
<florian> +1
emilio: and maybe less confusing long term
astearns: do you have a mechanism to only apply an alias in one at-rule context?
emilio: yes, easily
emilio: just within the @page descriptor, if descriptor name is 'size' return 'page-size'
<Zakim> fantasai, you wanted to reply to emilio
<ntim> p+
w3c/
fantasai: we'd previously resolved to make it an alias and have page-size be the name
fantasai: response we got was some products support JS and 'size' has been supported as long as PDF renderers have existed
fantasai: so we could do aliasing, but would have to make sure it doesn't break CSSOM
emilio: yeah, aliases already work nicely for that
ntim: any usage data on 'size'? i guess elika has answered the question
ntim: any browser have data?
fantasai: primary usage isn't in browsers, it's in pdf renderers. so big market difference in both content and userbase
emilio: i think browsers do support 'size' in printing, it's fairly used
iank_: yeah people generate PDFs from brwosers all the time, and do use the 'size' descriptor
iank_: so the markets are acteually pretty overlapping
florian: and epub readers too
florian: at least notionally, interactive pages user agents
ntim: common on web sites tho?
florian: when you print a web site, yeah, reasonably
iank_: very common in enterprise use-cases to have printable pages
iank_: and they use @page on those
https://
ntim: i ask because in webkit, @page is pretty poorly maintained and we haven't seen many bug reports
iank_: I suspect we have the best support among browsers here, and enterprises are just targetting Chrome for printing webapps
astearns: so proposed resolution is we add 'size' shorthand proeprty that has nothing to do with '@page/size'
astearns: concerns?
RESOLUTION: Add a 'size' shorthand property (for 'width'/'height'), no relation to @page's 'size' descriptor
ntim: woudl longhand be physical or logical
fantasai: i think would have to be physical because that's how we generally handle shorthand properties with both directions
fantasai: we map to the physical directions by default
florian: would be good to have a switch but we dont' have yet
ntim: possible confusion with inline-size/block-size, versus width/height
ntim: but otherwise fine with this
emilio: should we discuss the alias in @page?
astearns: separate issue
emilio: i'll file one
github-bot, take up w3c/
[css-sizing] Resolved value of min size properties doesn't round-trip
<github-bot> OK, I'll post this discussion to https://
oriol: Sizing 3 changed the initial value of min size properties. Was '0', now is 'auto'
oriol: but for back-compat, on block/inline-blcok/inline/table, when you use gCS() 'auto' can serialize as 0
oriol: problem is Sizing 4 added aspect-ratio, and that makes 'auto' behave differently than 0 on those boxes
oriol: so if you use gCS() you see 0, but it has a different meaning. if you assign it back, the value changes.
oriol: so I propose if aspect-ratio is a non-initial value, the "auto can serialize to 0" hack isn't applied
oriol: hopefully webcompatible to change
iank_: i'm a little concerned. we already had auto problem for flex/grid, min-size:auto was treated differently too
iank_: didn't roundtrip there either
iank_: a little concerned that if gCS() starts returning 'auto' things could break. scared about compat.
iank_: mostly because this is the default
iank_: but width/height also don't fully roundtrip anyway
emilio: i think they do in gecko, blink has some bugs with scrollbars
iank_: nah, height:auto vs explciit value changes definiteness, which affects %s
iank_: so the idea that width/height roundtrips is a spec fiction
emilio: similar concern. i think in principle we should probably do this, but it does scare me compat-wise
emilio: can try it, see what happens
emilio: middle ground, maybe less scary, is doing this for layout boxes where we know it makes a difference, like for flex items
emilio: but still not sure it's worth
oriol: you mentioned flex items, for those it's alreayd the case, 'auto' serializes to 'auto'. it only serializes to 0 for block/inline/inline-block/tab le
oriol: so only *those* will change, and only when aspect-ratio is a non-initial value
astearns: out of time. can resolve to try fixing this roundtripping, or take it back to the issue. ian, emilio, preference?
iank_: can we put it at start of call nexte week? want to check some things. I didn't realize we were alreayd doing this for flex/grid items.
emilio: same. I think this makes it a bit less scary.
astearns: so let's take it back to the issue. we'll revisit next week.
github-bot, end topic
astearns: HDR breakout in a few hours
astearns: 2 issues, about 'auto' value and about 'initial' value
HDR
[css-color-hdr] auto value of dynamic-range-limit
ChrisL: Note that we changed 'high' to 'no-limit'
ccameron: with 'auto', I'm struggling to understand what the goal is
ccameron: Not necessarily agree with goal
ccameron: browser-defined incompatibility mode
ccameron: Might want to have UA limit how much headroom is available
ccameron: but that limit should be applied to page altogether
ccameron: don't want each element to get its own headeroom
ccameron: ... if want to e.g. hint that you really want HDR, and once can do constrained with video, etc. then can implement that
ccameron: so that's direction I would see it going
ccameron: Not a fan of 'auto' in current format for that reason
weinig: I'm also not clear on what 'auto' would do or why it would be a good idea
weinig: seems like if property intention is to provide upper limits on how much HDR headroom something should have, 'auto' doesn't really make sense
weinig: Idk how authors would use that
astearns: unfortunately Said who opened the issue isn't here
ChrisL: Agree that I don't think 'auto' adds much value.
ChrisL: incompatibility mode ... when you don't set anything
ChrisL: and then other values to get some sort of defined behavior
astearns: Table discussion until we have more clarity
[css-color-hdr] Initial value of `dynamic-range-limit`
ccameron: should it be auto or no-limit?
ccameron: I'm sympathetic to idea that if we're doing this ex-novo, make HDR opt in and whatever for the default
ccameron: but given every browser is shipping HDR on video by default
ccameron: and HDR images is not implemented yet only due to technical complexity
ccameron: I think UA should pull down everything together, and e.g. UA limits to 2x and you have to hint that you want HDR to get it
ccameron: or have mode where try to be smart in that property
ccameron: right now UA can do anything
ccameron: But I think everything should be limited on a page together
ccameron: if global limit, then adjust
ccameron: if there's behavior we want to care about
ccameron: better to let HDR images shine out, if too bright, that's just bad content
ccameron: clear signal that your HDR content is not authored in a good way
ccameron: we want people to integrate in a good way
ccameron: encourage people to create good content
ChrisL: I tend to agree with that
ChrisL: e.g. you could create lime green with flashing gif
<ccameron> I haven't been to Geocities that recently....
ChrisL: we don't limit that
weinig: piece we're missing is, what's the goal of this property?
weinig: establish goal, then we can figure out our values
weinig: but without that, it's hard for us to make smart decisions
weinig: general premise of protecting people from poorly designed website is not our battle
weinig: But author may not know the source of images, so having author's abilitiy to limit
weinig: in this index, we're going to constrain HDR, because we dont' know what they contain
weinig: let's not waste that power
weinig: but default should be no limit, no use case for auto
<weinig> fantasai: believes that WebKit's position was that the initial value should be constrained
<weinig> fantasai: and things on a case by case basis should be marked unconstrained by authors
<weinig> fantasai: unfortunately not sure of the details, smfr would know more
<weinig> fantasai: authors do have the issue of things like 3rd party content, ads,
<weinig> fantasai: if the default is no-limit, those ads might do bad things, and they would not know, because things works fine now
ads or user-generated content
<weinig> ccameron: would it be better to have a global hint?
<weinig> ccameron: we have to deal with the fact that video is already not constrained today
<weinig> ccameron: lots of people count on that
<weinig> fantasai: webkit/apple thinks a ua style sheet for video would help
ccameron: some browsers are shipping HDR images already, would break that behavior
<weinig> ccameron: for chrome, this would break things for images and webgpu canvas, which have already shipped
ccameron: hard to explain why we have this default a few years from now
ccameron: why not have a global signal
ccameron: whole page, if you want to keep the old behaviors, you need to opt into it
ccameron: roll that out slowly later
weinig: 2 weeks ago, position was that webkit/apple really wanted images also to be HDR unconstrained
weinig: in addition to video
fantasai: I can't remember which elements were proposed to except. ^_^;;
weinig: What if we split property in two, and have one limit apply to things like video/image/canvas -- replaced content
weinig: and separate one that applies to CSS colors etc.
weinig: then you could decide... is bg one or the other
Said: I've been working with HDR for awhile now, and I feel it is really distracting to see HDR and SDR together in the same page
Said: I tried to get high quality HDR, but still same experience
Said: So it makes sense to me, to always have mixed content always be constrained
Said: and only allow no-limit for fullscreen(?)
Said: This is my experience with SDR and HDR in the same page
ccameron: Right now the UA is free to do that, to limit all the HDR in the page to nothing for e.g. background windows (like Preview does on MacOS)
ccameron: and they can also limit the range heuristically, based on outlines
ccameron: Key thing is that the limit is imposed by UA on all content, so that page is affected all together, not element by element
ccameron: dynamic-range-limit property is author saying what they wayt
ccameron: if UA wants to do something beyond that, is compatible
ccameron: Sympathetic to opt-in idea, but given where we are, disagree.
astearns: Wrt separate properties idea, aside from images and video, you can define a bg color as HDR color
astearns: if we decide initial value of dynamic-range-limit is constrained, then it's double-opt-in for that color? You'd have to specify the color and also raise the limit
ChrisL: You'd still get an HDR color, just a more subdued color
astearns: That's a fair argument for not having a constraint, since we tend to avoid double opt in
weinig: We would re-imagine existing CSS colors as all being HDR capable, as long as their components were large enough
weinig: it wouldn't be a double opt in, you just need a color bright enough to warrant using some headroom
<weinig> fantasai: the idea that the UA can do anything it wants
<weinig> fantasai: works well in cases where the UA has the final say, like background window
<weinig> fantasai: but it doesn't work well when the author overriding things
<weinig> fantasai: in that case, a property makes sense
<weinig> fantasai: element by element makes sense
<weinig> fantasai: but a different default for fullscreen or loaded alone might make sense
<weinig> fantasai: but allowing a page to have a mix of HDR and non-HDR might make sense too
<weinig> fantasai: like YouTube, where there is video, but also other content
<weinig> fantasai: but only the main video should be HDR
<weinig> fantasai: magic limits later seems worse
<weinig> fantasai: should figure this out now, and make it work with the cascade
<weinig> fantasai: weird huerstics are worse, viewport metatag is awful
Said: We should take consideration the default, any possible auto values, take into consideration the transition
Said: At this time [missed]
Said: For example eBay, suppose someone decided "well, now all browsers support HDR, let's use this ability"
Said: [missed2]
astearns: I'm not sure I understand the story of having a constrained default be useful if we are also specifying that videos and images are not constrained for compat reasons
astearns: story of page with a lot of videos, if videos have their headroom expanded in UA stylesheet, that default is doing nothing for that case
weinig: We have to figure out and agree on our goal
weinig: sounds like we dont' quite agree on it
weinig: is the goal that videos, images are constrained or unconstrained? constrained in some circumstances? browsers can have different goals?
weinig: I see different goals here. We need to converge on the goal.
weinig: Another issue is that chrome has shipped this, so we also potentially have a compat problem here
weinig: Maybe Apple can give a concrete proposal
Said: My understanding is that we like to provide the nicest experience for the user even during the transition period
Said: Having HDR without constraint doesn't seem nice
Said: so we want the default to be constrained-high for images
ccameron: One of my goals is to not lull people into the idea that they have good content because it looks good by default
ccameron: I want to show exactly what was specified up to capabilities of the machine
ccameron: and hope this will inform people to make good choices about how they use HDR
ccameron: if specify too much, and end up getting 2x as bright because ...
ccameron: There is concern that I'm authoring to 10, but not knowing it
ccameron: HDR video authored with PQ is usually quite good.
ccameron: HDR images on iPhone, Pixel, etc are also good. They don't blow your eyes out.
ccameron: But ?? video shot at iPhone and Pixel is way too bright, looks bad, ruins people's eyes
ccameron: problem with that is, people were allowed to create the content without seeing what they're specifying
ccameron: I think it's better to show what was specified, and hope they are not making it unpleasant to view
ccameron: Should it turn out that we're wrong, and ppl can't do this right even when seeing what they're producing, then maybe ratchet down the defaults or global switch or something
ccameron: If we limit things by default, they will create bad content because won't see what they're specifying
ccameron: I want to give ecosystem a chance to get it right
ccameron: otherwise will be bad forever
Said: I disagree with ccameron
Said: Here's an example
Said: In WebKit, we limit animation to 60fps. But in Chrome, it uses device frame rate
Said: Chrome has already hit a problem where the frame rate can be 200 or 500, some device has this kind of speed
Said: and Chrome can't cope with this speed, and begins to limit it
Said: So I think unlimited would give you a bad experience
Said: We want to give the normal user the best experience.
<weinig> fantasai: Chris is making the argument we should give the author the opportunity to get it right
<weinig> fantasai: I am making the argument that there is a bunch of content out there where the author is not going to know, and user will get annoyed
<weinig> fantasai: not just about the transition period
<weinig> fantasai: constrained is a better default for the web
<weinig> fantasai: sophisticated authors will get it right
<weinig> fantasai: but many won't know how to make things right
<weinig> fantasai: better to make things opt in
<weinig> fantasai: you should not need to learn everything to use CSS
<weinig> fantasai: shouldn't have to learn to turn down the headroom
<weinig> astearns: could be argued in either way
<weinig> astearns: could be hard to figure out how to make your photos look right
fantasai: If you want extra brightness you're expecting but not getting, then you can go looking for how to do it.
fantasai: but if your page is tacky and uncomfortable, as someone who isn't a designer, you might not even know why or that it's fixable
ccameron: I'm sympathetic to that argument, but in that case I would suggest a default of SDR
ccameron: since constrained high is [missed3]
ccameron: I could go for that. And maybe there's a bridge to that somehow.
ccameron: Keep going back to global thing.
ccameron: (something about gainmaps)
ccameron: even if you have a very small headroom
weinig: I do think that the ideal default would be SDR
weinig: I would ask the browser vendors if that is a possibility, even though it would make some content that currently works not do what is expected
weinig: majority of content that wants to benefit from HDR values will learn about these properties
weinig: and in time get those properties set on them
weinig: whereas if we start with unconstrained or a middle ground, it will always be fighting one battle or the other
weinig: both argument fantasai made and astearns made, that each group won't get behavior that makes sense
weinig: it would take video that's already HDR and make it not
weinig: but maybe that's OK
weinig: maybe there aren't enough websites that having this blip of compatibility isn't doable
ccameron: In terms of video, one difficulty is that right now tone-mapping videos to SDR is to do terrible and undefined things to the video
ccameron: One of the nice things about images is that, from the moment they were defined in terms of SDR and in HDR, its' all parameterized in terms of headroom and it's great
ccameron: but for video, don't have that
ccameron: in many cases no ability to even tell the OS to render under constraints
ccameron: so that limits what we can do for video. Even if we want to, in some OSes it is technically impossible
ccameron: I do horrible things to make it "work" in Chrome
ccameron: We're working on standards to improve the situation
ccameron: There's work going on in standards to improve video, to have double-graded content
ccameron: but for right now.... it would be a big amount of work
ccameron: and it yes, there are pages that serve HDR content, usually professional stuff and they are paying for the bandwidth
ccameron: I think there's a chance we could push in a different direction in the future, but really built in right now
ccameron: Can we switch topic to names?
ChrisL: +1
astearns: I wonder if we can decide on an sdr default with video override in the UA stylesheet
weinig: I think we really need Simon for that
weinig: since I proposed that last time, and he had objected
astearns: OK, we'll take that back to the issue for now
[css-color-hdr] New values for dynamic-range-limit property
Suggestions from ccameron at w3c/
<weinig> fantasai: its not clear that constrained is less constrained than standard
<weinig> ccameron: standard lines up with the media query, meaning most locked down
ccameron: Standard lines up with terminology and media query
ccameron: no-limit is pretty clear
ccameron: Do we agree on the two end points?
ChrisL: Yeah, it's just the middle one
ccameron: Constrained seems great to me, but I've been deep in this for a long time
<weinig> fantasai: maybe we can resolve on standard and no-limit, and ask the rest of the wg on names
<weinig> ChrisL: we already are pretty resolved on standard and no-limit
<weinig> fantasai: asking a person if constrained or standard is more constrained...
<weinig> w3c/