W3C home > Mailing lists > Public > www-style@w3.org > June 2014

[CSSWG] Minutes Seoul F2F 2014-05-19 Part III: Image Values 3

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 8 Jun 2014 19:38:00 -0400
Message-ID: <CADhPm3vSLGHdL5dpx4qVoZsCtzBtfrX8fmTCjReiQD5nFRWE6w@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:22 UTC