- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 8 Jun 2014 19:38:00 -0400
- To: www-style@w3.org
Image Values 3
--------------
- The two disparate types of image fallback were addressed with
the group expressing strong support for fallback to a color,
but wishing to simplify image fallback.
- RESOLVED: Drop fallback from image except fallback to color.
Later we introduce that fallback as an explicit function.
- RESOLVED: Cut out everything not defined for image-orientation,
remove additions, move it to an appendix, call it obsolete
and make a custom CR exit criteria stating it doesn't need to
be tested to exit CR.
- RESOLVED: Specs that define obsolete features don't need to test
those features to exit CR.
- Of the possible solutions for non-square pixels, the group
leaned toward deferring to HTML's handling of video.
- TabAtkins plans on bringing requesting a LC for Image Values 3
on the first telecon after the meeting.
==== FULL MINUTES BELOW ======
Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael
Image Values 3
--------------
TabAtkins: There's more issues in values and units.
glazou: That's this afternoon.
glazou: Image values now.
plinss: It's dropping features from image.
TabAtkins: Currently image function is image(features, image*,
color) this is roughly the grammar.
fantasai: I don't think we have features
dbaron: Later?
TabAtkins: That's next level.
TabAtkins: It does image fallback and does each one in turn. If it
can't do an image it goes to the next one. If it can't
it does a solid color fallback image.
TabAtkins: This function will also be how we provide additional
features later.
hober: What is the intrinsic size of image when you do fallback?
fantasai: It doesn't have one.
TabAtkins: Problem now is we also have image-set() in level 4 which
is image-set([image resolution]#)
TabAtkins: This doesn't fallback, it just selects based on
resolution.
TabAtkins: So now we have two types of fallback in ways that don't
work well together.
TabAtkins: You can't do what you want even if you combine these
together.
krit: image-set takes a function or type, right?
TabAtkins: Yes, but it doesn't work the way you want.
krit: You can't have it for each resolution?
TabAtkins: You can't in image-set() size both.
hober: Because you can't make the 1px work with a 2px with
different aspect ratios.
dbaron: Is there a use case for people having 1x and 2x in different formats?
TabAtkins: 404ing might be the case.
TabAtkins: Images are currently is half format, half network error
protection.
TabAtkins: Since this was solving in two ways.
hober: These functions have different purposes. image-set doesn't
have a fallback
hober: It isn't trying to solve fallback at all.
TabAtkins: You're saying pick a version based on this url, but
they decide how to choose differently.
hober: If it was called fallback it would be clearer.
TabAtkins: We have two "pick an image from this set", but they
don't work the same.
krit: They have two purposes.
TabAtkins: They don't. That's what I said.
hober: You can use image-set for an image function.
TabAtkins: You can't do that at all.
<hober> image(image-set(a 2x, b 1x), b, black)
<krit> image-set(image(list) 2x, image(list) 1x)
TabAtkins: Any way you can write it only works in one direction.
TabAtkins: It only works if you're falling back in that way you
described.
TabAtkins: What if the browser chooses b and it's 404ing so let's
load a, you can't.
TabAtkins: You can only pick an exact path. You can't say pick the
best of these.
krit: For each image set condition you have one list of images
that apply to this condition. Why wouldn't that work?
TabAtkins: That's different fallback behavior.
TabAtkins: So what he put is valid, but it doesn't let you provide
a set of images and provide a resolution that works.
hober: It would be great if we had a image function that took a
bunch of information and always magically did the right
thing.
TabAtkins: I think we can, but a combination of image and
image-set isn't right.
TabAtkins: So I say we make some kind of image option and than
later create a property that allows for a "do what I
mean" approach.
krit: That works in the beginning, but what about the future?
TabAtkins: We don't want one thing doing everything. This already
does fallback color and adding full fallback makes
things too complex.
hober: First, what's the compat risk of not allowing 0 fallback?
TabAtkins: None. No one implements it.
hober: Second, I like separating fallback from other features, but
I'm not crazy about squeezing it into image-set.
hober: Suppose we had a fallback that takes a sequence of
arguments and either shared micro-syntax or use image-set
and when you do select it, it imposes an order.
TabAtkins: That's how I want to handle this.
hober: What I like is it doesn't make micro syntax complex.
hober: It's a bit magical because it imposes an order that wasn't
there. That's weird, but not that weird.
hober: If you're using fallback, you want it.
TabAtkins: To check, you have a fallback and you load an image set
and it still tries to load the best, but if it fails it
falls back
hober: Yes, I imagine the check would be the same, but the second
ordering is used if there's a failure
krit: With image function, what do you suggest now?
<dbaron> Tab writes "fallback(imageset(a 1x, b 2x))"
TabAtkins: Drop the fallback. In level 3 it would be an image and
color.
dbaron: You're preserving fallback from image to color?
TabAtkins: Yes.
dbaron: It's a feature we had previously deferred and brought back.
<dbaron> (from background-color taking 2 values)
hober: If we don't have implementation so no compat risk, there's
also no risk in changing the name of image. It seems very
generic.
hober: It's also providing additional information and a color.
It's the odd man out.
hober: I can't tell from the function name what it does.
dbaron: There's other things we wanted to tie in like media fragments.
We also have a proposal to tie it to handling EXIF.
dbaron: Basically, saying that something should have its EXIF
interpreted.
<clilley> http://en.wikipedia.org/wiki/Exchangeable_image_file_format
dbaron: So we're designing the modern way to handle an image, but
we've tied it to options?
TabAtkins: That's why we have a generic name.
hober: And that's why there's no implementations. You need to have
the add-ins.
TabAtkins: You don't. You have to either understand media fragments
or treat as broken.
TabAtkins: Minimum is url and fallback color.
krit: People often want image not because the fallback, but
because you can say a color to fallback to.
TabAtkins: We're keeping that.
krit: That's why I was concerned. I'm supportive of limiting image
functions.
TabAtkins: That's good since you were opposing this earlier.
zcorpan: So do we need the fallback function? Do we need to
fallback?
hober: I think it's useful and I like that it's generic and
separate. You can use it for something like a font case.
TabAtkins: There's the transient image issues, but there's also an
issue for unsupported types.
zcorpan: Then you'd want to add the type up front.
TabAtkins: Yes. I was waiting on a decision.
zcorpan: But for type fallback we don't need network fallback.
hober: It's true they're different.
TabAtkins: Technically, but to authors they're the same. You can
omit type and network would still work.
TabAtkins: That's why they should be together. In terms of things
authors would use, they're the same.
TabAtkins: Were you suggesting we only keep type fallback?
zcorpan: Yes, I think network has complexity and authors don't
need it.
hober: We don't have that elsewhere.
TabAtkins: The image function does do network fallback. If
something happens you get a solid color.
zcorpan: Yes, but solid color doesn't get you another network item
TabAtkins: I've kinda added type fallback to image-set. I want to
make it similar to picture.
TabAtkins: We can always just have image-set features equivalent
to picture and we can decide on full network fallback
later.
TabAtkins: So are there objections to this proposal?
TabAtkins: The proposal is we drop fallback from image except
fallback to color. Later we introduce that fallback as
an explicit function.
* krit picture(<source src="image1.png"><source src="image1.jpg>)
clilley: Is that better separate?
hober: Suppose in the future you define it...
TabAtkins: You still want to just say load the image you want in
image-set without extra requests, but with the option
to say I do want to burden the network
hober: That sounded separate. First question was to drop.
TabAtkins: Well, it's to drop and add later.
RESOLVED: Drop fallback from image except fallback to color. Later
we introduce that fallback as an explicit function.
glazou: We have 2 things on image values. Dropping image
resolution and orientation.
TabAtkins: We can do that after lunch
krit: Can someone update the agenda?
TabAtkins: What's on there is what we have.
dbaron: And there's a large number of time constraints for people
calling in.
glazou: So I suggest lunch break.
[break = lunch]
glazou: Let's get started. Deprecating/dropping image-orientation.
TabAtkins: There's a proposal for dropping auto-applied and to let
it just be an HTML thing.
TabAtkins: If we can't, drop everything except what's supported by
printers.
clilley: That's odd since HTML isn't the only place that brings up
images.
dbaron: You do it in a different way for CSS.
TabAtkins: In the image function.
clilley: I don't like building a gap.
TabAtkins: The reason it was thought weird is the only thing that
should be applied is use the native orientation.
TabAtkins: The only thing we have in this level is just to use the
one orientation.
TabAtkins: The question is do we drop this or just keep what's
needed for printers?
hober: Do you mean in the print screen?
TabAtkins: No.
clilley: Is this XHTML print?
fantasai: We have a CSS print profile that's referenced by
printers/scanners that we can't remove, but we can
obsolete it in the performance notes saying that it's
not required.
clilley: That CSS thing and the XHTML print were coupled.
Can't we get XHTML print to have this attr?
fantasai: I don't think that's good.
fantasai: The XHTML print stuff is to allow printers to create
templates for themselves. This is old.
fantasai: I don't think anyone wants to work on that. We'll do the
minimum to not break anything and that's to say here's
the spec, it's obsolete. Don't implement it unless you're
implementing CSS Print Profile.
clilley: So the spec that referenced it, what stage is it?
fantasai: I don't know.
clilley: It has a forward reference to something we haven't spec'ed
fantasai: It was in paged media and we pulled it out to Images
when we created that module, because it fit there better.
fantasai: Paged media hit CR but we pulled it back for being underspecified.
clilley: Well that's the weasel out; it's we're saying people
aren't depending on it.
fantasai: They are, but they're not on the web. We say if you're
on the web, this isn't useful for you.
zcorpan: Do we need to have it at all?
fantasai: They have implemented it, andthey're fine with what's there
now. They're satisfied.
clilley: They were fine with a non-standard thing. What's the
benefit of putting in our own spec?
fantasai: Well, we pulled it out and put it here so it has to be
somewhere.
clilley: Right, I'm saying they were using something old.
fantasai: Well, we moved it and didn't want to break the links.
clilley: We moved it because we thought we wanted it and don't now.
hober: If we don't want it and they do, why don't they define it?
fantasai: All we need to do is put an obsolete notice.
hober: But we don't need it at all because they're using it and
don't need us to have it.
fantasai: I don't want to break people. Leave it with a note in 3
and remove it from 4.
TabAtkins: Who is broke?
fantasai: This is referenced.
fantasai: I don't see the problem with leaving it and marking as
obsolete.
clilley: Marking obsolete or deprecating?
fantasai: Either.
clilley: One says don't do it, the other says everyone should
implement it, but we're not using it anymore.
clilley: I don't want effort into something we don't want.
hober: I'm perfectly happy with fantasai adding a note in the
document or whatever.
fantasai: I don't want to break references to exit CR
clilley: Skipping is fine until we're at CR.
hober: But we can define our own criteria saying that obsolete
features don't need to be implemented.
TabAtkins: That means I have to add things to bikeshed.
hober: Other groups have custom criteria already.
TabAtkins: Okay. Sounds good. I will cut out everything not
defined, remove my additions, move to an appendix, call
it obsolete and make a custom CR exit criteria for that.
plh: Is it normative or informative?
TabAtkins: It'll be normative. Web browsers must not support it
and we don't have to test it to exit CR.
glazou: No objections?
RESOLVED: Cut out everything not defined for image-orientation,
remove additions, move it to an appendix, call it
obsolete and make a custom CR exit criteria stating it
doesn't need to be tested to exit CR.
hober: Since clilley seems interested, it might be worth
considering the general case. Do people like that specs
that define obsolete features don't need to test those
features to exit CR?
hober: So can we resolve now?
glazou: We just put it on the radar. We define our own criteria.
glazou: It's basically a generalization of what we said.
RESOLVED: Specs that define obsolete features don't need to test
those features to exit CR.
dbaron: This resolution is for features that should not be
implemented in browser engines.
<hober> Just making sure it gets minuted that obsolete !=
deprecated
dbaron: So what is the name of this HTML attr?
TabAtkins: I have to look. I saw it in a recent bug.
dbaron: I want to make sure this really happens because we
implement the image orientation
dbaron: I'm okay with changing it, but we're not going to remove
image-orientation until the HTML exists.
dbaron: If we leave it too long we may not be able to remove
completely.
TabAtkins: Let me ping Hixie and get him to put it in.
dbaron: What I need to know is the attr name and it's not in the
spec.
dbaron: If that doesn't get specced soon, I might have to object
to this resolution.
glazou: You can't say you might object in the future.
plinss: Well, you can't say you may have objected in the past.
glazou: I don't want to make life hard, I want this to be simple
now.
hober: Its always been the case that we can revisit issues if new
information arises.
clilley: And in this case if Hixie gets back to TabAtkins and it's
not there we need to revisit.
dbaron: I think it will be fine, I'm just saying that it might not
be.
TabAtkins: Okay.
TabAtkins: Next is two-value image-resolution.
<TabAtkins> http://lists.w3.org/Archives/Public/www-style/2013Jul/0568.html
TabAtkins: SimonSapin pointed out that some formats allow separate
X and Y resolutions.
TabAtkins: Especially TIFF and technically SVG.
hober: That never went through.
TabAtkins: Oh.
clilley: I think TIFF is for geoTiff.
* liam used to work with laser printers that had hexagonal pixels
<liam> [ccitt group 4 fax can have different x & y res too]
TabAtkins: There's two reasonable answers. One is keep image-resolution
as spec'ed and when provided with non-square pixels, take
the vertical and adjust to create square pixels.
clilley: So it would have to re-sample the image?
TabAtkins: Yes.
dbaron: So you're changing aspect ratio?
TabAtkins: Transferring from non-square and aspect ratio into
square aspect ratio.
TabAtkins: Assuming there's non-square pixels.
TabAtkins: We'd say whatever the resolution is we'd set it to the
height and the image keeps same size.
TabAtkins: That's one option. The other is we add a 2nd optional
value to allow it to handle non-square and define how
that works with normal.
hober: So the first possibility requires authors to do what?
TabAtkins: Nothing.
hober: And the second would allow a new thing that would require
implementation?
TabAtkins: Someone has to write down what's there now.
clilley: But that's what it has to do now.
TabAtkins: Or ignore it completely.
hober: So where is the burden of the work?
TabAtkins: Neither case on authors. Someone has to write it in
either case.
TabAtkins: So do we care about adding the feature?
dbaron: For what it's worth I've had monitors with non-square pixels.
TabAtkins: Those just map one square to one non-square
hober: Seems we need a use case to justify this.
hober: What I've heard is there are small number of odd cases and
we don't need to add features for that.
<clilley> I was wrong, its TIFF from Faxes
https://forums.adobe.com/message/3843629
<clilley> https://discussions.apple.com/thread/2627401
clilley: It's not geoTIFF it's TIFF from faxes. It's going away
but more wide spread.
<clilley> "A typical fax machine has a default (Standard)
horizontal resolution of 8 pels/mm, which is roughly 204
pels per inch (or 204dpi). Some faxes are also capable
of increasing the horizontal res to 16 pels/mm - roughly
400dpi."
dbaron: I think there was confusion on the wording.
dbaron: I think the proposal should be defined so you end up with
the size you want and you shouldn't talk about super
sampling.
dbaron: You should assume there would be a pass of image scaling,
but we shouldn't say there has to be 2 passes
TabAtkins: So in this case it's spec'ed as 2x2 and wants to be 2x4
and we say that's okay.
zcorpan: So we say the size of the pixel are whatever that one
dimension is?
TabAtkins: I prefer one dimension.
hober: So if you pick width...
Rossen: Quick question. What is the intrinsic size of that image
and what do you see in CSS?
TabAtkins: The size is the number px in that dimension by the size
of those.
Rossen: So in your example it's 2x2.
TabAtkins: It'll be treated as 2x4.
Rossen: So you're saying intrinsic size is on the x axis?
TabAtkins: This will be pixels in the x direction and their size.
zcorpan: But why the width instead of using the smaller number?
TabAtkins: Seems easier.
zcorpan: The image could get smaller than intended.
TabAtkins: Not smaller, blurrier.
hober: So we need to say we square-ify the image.
hober: But if we don't say how we can defer to implementors.
TabAtkins: We still need to say it's inter-operable.
clilley: [Reads IRC comments]
TabAtkins: So it ends up in tall case.
hober: So if we do width, the fax case will look better.
TabAtkins: Yes.
zcorpan: I didn't follow the dimensions.
TabAtkins: Normally intrinsic is px x/y. This is px by size of px.
zcorpan: I think the resulting size should be the same but flipped.
TabAtkins: No.
zcorpan: I want the one to resolve to 2 x 4 because the other is
4 x 2
TabAtkins: It is really what dimension to you apply image
resolution to.
hober: Let me try. There are two dimensions. One of them is more
interesting.
hober: In an information way, there's more going on. So if you
break up the other dimension you're not losing quality.
TabAtkins: zcorpan is suggesting to never break up image quality.
hober: So both are easy to implement, one is slightly more complex.
zcorpan: I think HTML spec deals with this for video. I haven't
been able to pull it up, but I think it uses smaller
dimension.
TabAtkins: Interesting.
plinss: Non-square is more common in video.
TabAtkins: So that is what it does, use the smaller?
hober: Can we resolve now to match HTML?
TabAtkins: That's fine.
TabAtkins: So, square-ify the pixels...
<zcorpan> "If an anamorphic format does not define how to apply
the aspect ratio to the video data's dimensions to
obtain the "correct" dimensions, then the user agent
must apply the ratio by increasing one dimension and
leaving the other unchanged."
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-video-intrinsic-width
zcorpan: So if you have the right case, you stretch.
TabAtkins: So it's making sure you never lose information.
TabAtkins: So apply resolution to the smaller pixel size.
clilley: Sample up not down.
TabAtkins: That's fine.
<liam> [many flatbed scanner devices can also generate images with
different x and y resolutions - usually in TIFF]
<clilley> linescan Narrow Angle Camera images
clilley: I found two more use cases. One is some video formats,
the other is space imaging using scan.
TabAtkins: Proposed resolution is keep resolution with a single
value and apply that value to the smaller of the two
pixel dimensions. Then treat it like it has square
pixels while maintaining image aspect ratio.
hober: Can you coordinate that with Ian to defer to HTML?
TabAtkins: Yes.
TabAtkins: Though it sounds the HTML video turns the pixels square.
TabAtkins: I can think on this a bit.
clilley: What do you mean turns them square? You mean distorts
aspect ratio?
plinss: Sometimes you want to do that in video.
hober: I'm hoping for a default that can be in UA sheet and
matching HTML video.
<clilley> for video. it isn't appropriate for those fax and
scanner tiffs.
adenilson: I have a question. The description is for both, isn't
it re-sampling, but favoring the smaller resolution axis?
TabAtkins: It has to be harder because you can't just take the
smaller size because you want to make sure elements
stay wide/tall.
adenilson: So we won't re-sample in the same way both axis.
TabAtkins: Yes.
adenilson: So it won't be symmetric, it'll be asymmetric. If I
recall a similar strategy in a anisotropic sampling.
adenilson: So we can say in such a case we can go with that
sampling?
TabAtkins: Yes.
adenilson: If is recall there's a mathematical formula.
TabAtkins: I don't know, but I'm happy to write something up and
have you suggest better terms.
TabAtkins: I need to publish a new thing for Images. These are the
big changes. Would we be okay with a quick 3 week LC to
CR cycle?
fantasai: I think we should fold in all the changes.
TabAtkins: After I edit.
fantasai: Let's do that and give a week on www-style for people to
notice changes.
dbaron: What's the timeline for the new W3C process?
clilley: 6 months to a year and there's an odd transition period.
plh: And the reason is that new specs will reach LC for a short
period.
TabAtkins: That's in most cases, yes.
TabAtkins: So it's a bit more busy work, but we'll cycle quick. In
two weeks I'll ask for a LC.
TabAtkins: So please have objections ready.
* plh notes that new W3C Process could take effect as early as end
of June
Received on Sunday, 8 June 2014 23:38:28 UTC