Tess: I was involved ... i think it's fine ... i wish there was more alignment between CSS and web manifest in terms of how things are expressed. But two languages are under diffeent constraints considering processors that handle web manifest files and how much of the web stack is available to that processor... certainly they ended up with a solution that's fairly simple and extensible to other theme color type things... like having colorscheme .. seems sensible to me. These are initial thoughts.

Dan: they punted on s&p review, does it make much of a difference? Information already exposed through CSS. Multistakeholder support? After incubation?

Peter: colour scheme and a set of keys rather than colour scheme _ is more fragile for extensibility. How adding more css colour scheme media features fits in, if they're putting values with the key names

Tess: fair feedback. Doesn't seem that bad now because they only have this once case, but adding more gets ugly

Peter: only dark and light right now, but others might be defined in the future

Dan: punt to next week

punted to plenary

Tess: Peter raised the point that it's weird they're combining properties and values, media features and values, in the keys. Their response is basically about keeping structure simple, less nesting. I don't think the latter falls from the former. If I'm writing code the difference between Peter's suggestion and what they have is a quesitno of where you end the string and where you put the brackets. From a dev perspective they're equally simple.

Rossen: from an extensibility point of view..

Tess: also broadly equivalent.. Preference for less nesting feels like a personal preference of the feature designers as opposed to something justified on simplicity grounds, because I don't think it's any simpler. It's valid, but doesn't strike me as the strongest argument

Peter: if i want to iterate through all the colours chemes specified I need to start parsing keys

Tess: great followup point, that's why they're not the same

Rossen: my reaction too. Jamming in values along with the attributes of properties in this case syntactically, Tess, I agree with what you said. You could put them in the same line or space them with new lines and braces. But dark and light and everything else that's gonna come up are values of that property we all know so combining them together leads to all kinds of residiual issues like the one Peter pointed out. Stronger arguement to put them on a separate level

Tess: worth replying ot the last comment pointing out that they didn't take your point that iterating over these would require parsing keys and in the other design it wouldn't. That's absent from their reply.

Peter: on the other side, I do reall having this conversation before about something else in th emanifest and they took the same appraoch. So if there's consistentcy..

Tess: cnsistency on the platform is nice when we manage to pull it off. Overall there is lots of inconsistency. All things being equial, consistency is nice, but in this case there's a real downside to this design that you've identified. Might be worth not being consistent with other bad things.

Peter: perpetuating a bad pattern

Tess: I can leave feedback, these aren't interchangeable for that reason

Dan: Lea has left a couple of comments in the meantime. Also while we were speaking my computer has turned to dark mode and github has gone from light to dark.

Lea: comment I left was not immediately related to this discussion. They said it's already definable through CSS - what are they referring to? Custom properties for theme colours? SOmething I don't know about? Assuming it is definable through CSS why would we duplicate it into a different API? What if you could link to a stylesheet that defines these very eseential things that you want a splash screen to have access to before the app loads. Takes an extra request, but so do other things in the manifest like icons.

Tess: linking to a css file from the manifest would mean that the manifest parser would have to have a css parser in it .. big ask

Lea: true. Fair enough. Down the line, what if we need to duplicate more CSS in the manifest?

Tess: oh yeah, your worry is very well-placed

Rossen: yoru point is generally speaking something I agree with. We had this conversation about how much of the platform you expose to the manifest and end up duplicating. But from the app packaging point of view it's been a hard argument to come around on either side. Not the hill we want to die on.

Lea: agreed. I can edit to add the part about the CSS parser.

Tess: need to take some time to write a comment

Dan: comment responding to Tess's point

Peter: not sure I buy that comment. It's just JSON.. if you have multiple matching key in JSON the last one wins in a JSON parser?

Tess: yes

Peter: so if they say first one wins they write a custom JSON parser? What?

Tess: seems like completely missed the point. They even said they wanted it to be consistent with that other thing, and Peter's proposal is consistent and their proposal isn't... Someone should point out that's not how JSON works.

Dan: Pending feedback, Peter left a comment..

Sangwhan: can nudge

Peter: I think we can close this. They took our feedback on board. Lea had some additional non-blocking

Dan: terrific! closing comment

closed