search

w3c / payment-handler

Payment Handler API
https://w3c.github.io/payment-handler/
Other
74 stars 42 forks source link

ImageObjects can now reference ImageResource #238

Open marcoscaceres opened 6 years ago

marcoscaceres commented 6 years ago

We rewrote web manifest in terms of WebIDL, so it's now possible to reference ImageResource instead.

We should reuse as much infrastructure from web manifest as we can, specially around fetching images.

domenic commented 6 years ago

"purpose" and "platform" are not applicable here, so unless this can be refactored, I don't think reusing ImageResource is appropriate.

rsolomakhin commented 6 years ago

IMHO, we should refactor if necessary.

kenchris commented 6 years ago

"purpose" is a hint, so can be ignored.

domenic commented 6 years ago

It can't though. When you use a dictionary with a defined field, that field is always retrieved from the object, per Web IDL. An implementation doesn't have an option to just not follow Web IDL for things designated as hints.

kenchris commented 6 years ago

Yes, but I don't see why they are not useful. Maybe in the future there will be a "purpose" for showing the payment handler icon in a specific way, which is the reason purpose exists. Some might also want a slightly change the icon depending on platform, ie. "android" vs "windows".

domenic commented 6 years ago

I don't think we should have specs do something because maybe in the future someone might use the thing they do.

As for whether browsers intend to allow customizing payment app icons per platform, that's a question for the spec editors, but given that they currently don't allow it, I'd assumed not. (Indeed, I'd prefer not to proliferate such incompatibilies between platforms when unnecessary.)

ianbjacobs commented 6 years ago

Ping @dbaron as this relates to some of his feedback: https://github.com/w3ctag/design-reviews/issues/231#issuecomment-379432134

dbaron commented 6 years ago

The argument that purpose and platform shouldn't be present seems like a reasonable justification for having a different dictionary. However, it's not clear to me whether that justifies having different definitions for the common members. Can the definitions of src, sizes, and type (sizes being the most interesting) just reference the definitions from ImageResource?

(Otherwise, I think this has converged a bit since I last looked at it closely.)