W3C home > Mailing lists > Public > www-style@w3.org > February 2016

[CSSWG] Minutes Telecon 2016-02-17 [css-images] [css-values] [css-containment] [css-ui-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 17 Feb 2016 19:50:03 -0500
Message-ID: <CADhPm3t4RuTWnQr_dDtd18zQEBYRzfi0P35R_HACZGyPmbwVTA@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

A value for image-rendering to request high-quality rendering

  - An as-yet unnamed property will be added to allow authors to
      indicate that higher quality rendering is desired. This will
      allow implementations of 'auto' more freedom in reducing
      quality to improve performance.

Values and Units

  - The prose defining directional <<angle>>s as bearings will
      become a note stating that it is a CSS convention.
  - Review was requested on calc() serialization spec prose soon by
      those interested.
  - toggle() will move to level 4 of values and units.

Gradient rendering and image-rendering property

  - The group didn't see a need to have image-rendering apply to
      gradients. Those with thoughts on this topic will also respond
      on the list.

Layout containment and overflow

  - Generally the group was inclined to say that we allow visible
      overflow, but if it overflows the parent scroller you can't
      see it.
  - TabAtkins will discuss this decision with the implementor
      working on it to see if it fits with implementation experience.


  - RESOLVED: Spec some set of -webkit-user-select values.
  - Rossen and/or gregwhitworth will help Florian decide what that
      set of values should be.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Feb/0161.html

  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Edward O'Connor
  Simon Pieters
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Ian Vollick
  Greg Whitworth

  Tantek Çelik
  Daniel Glazman
  Michael Miller

Scribe: dael

A value for image-rendering to request high-quality rendering

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0016.html
  smfr: This started when I implemented image rendering in webkit.
  smfr: We have a behavior where if an image is painted often it
        goes to a lower quality. There's no way for the author to
        opt out for now. There used to be a value for optimizing
        quality, but it's being deprecated. There's no replacement
        to indicate 'do better than auto.'
  smfr: Amelia posted a follow-up to my message. She suggested
        smooth but I don't like it because it's not necessarily
        smooth, it's look good. I'm open to other suggestions.

  <TabAtkins> The original reason I left this out was because we
              concluded that browsers would always opt for the
              highest-quality rendering they could get anyway, and
              authors have a good chance of trying it on their own
              powerful laptop and going "performs great, ship it",
              leaving low-powered devices getting pretty pictures
              but terrible perf.
  <TabAtkins> So I think it's a quality-of-implementation thing. If
              images often get booted into low-quality unexpectedly,
              fix that. Detect things better and use higher-quality
              more often.

  astearns: Does this new value mean don't do anything, or is it to
  smfr: It's not do special processing, it's use...another thing I
        should say this applied when the image is being scaled
        usually so there's a scaling factor...it's telling the UA to
        use best quality algorithm.
  hober: Besides the aesthetics of the old name, is there a reason
         why not to un-deprecate?
  astearns: TabAtkins said on IRC why he remembers dropping.
  astearns: So do we want to have something in CSS that allows
            Safari to avoid this image optimization when that
            optimization strategy isn't optimized?

  Rossen: How is this intersecting with source and picture and all
          the other abilities authors have to optimize quality and
          payload? Isn't that what we should strive for devs to use
          rather than UA optimize this away?
  smfr: It's different. Those allow the author to supply assets.
        This is once you have the asset and scale, what algorithm to
  Rossen: Gotcha.
  Rossen: It's when scaling is applied...okay.
  Rossen: We used to have something similar.
  <astearns> best-scaling?

  Florian: For TabAtkins's IRC, even if there was high quality the
           UA could use it as a hint. So it could still drop if
           there was a performance problem. Because there is a risk
           they could just set it everywhere.

  MaRakow: smfr, were you saying don't do the proposed smooth but a
           different behavior?
  smfr: I'm okay with something like smooth, I just don't like the

  Rossen: We're converging to we need to revive the old property or
          have something else.
  TabAtkins: What was the objection to what I said? That this is
             quality of implementation issue?
  Florian: I pointed out that if we get into a place where authors
           use it too much, the UA can just use it as a hint but can
           eventually do whatever it wants.
  TabAtkins: So if you do that the value is the same as auto but if
             you're in resource constraining prioritize others over
  TabAtkins: That doesn't seem quite what is being asked for.
  Florian: It doesn't seem quite. It's a middle ground.

  TabAtkins: smfr what is the opinion on detecting better?
  smfr: We would love to improve everywhere and get rid of low
        quality scaling. But I'm not sure...on low power we may have
        performance issues. There is value in the authors saying
        something is important enough.
  TabAtkins: I see value in 'my headline is the prettiest,
             prioritize if you can'. Something like that seems
  smfr: We don't have a notion of ranking images. We just make a
        choice when we get to an image.
  TabAtkins: If we were to add a high quality value, what happens on
             a low quality device that doesn't have power?
  smfr: They could try high quality and the user gets bad
        performance or they fallback to auto. I think it's okay for
        this to be a hint that can be ignored.
  TabAtkins: I think that's the same as what I said on priority. I'm
             fine if it's explicitly said that UA can ignore and use
             low-quality when needed.
  Rossen: I'm not sure this is giving much. If we're saying please
          do it and there's still room for UA to ignore then this
          defeats the purpose. I'd rather go back to your first
          suggestion TabAtkins and let UAs do a better job. Don't
          put this in the power of users because they'll just use it
          everywhere. So I'm not in favor of having a property that
          sometimes works.
  TabAtkins: That's why I was thinking prioritization. So spend your
             limited resources on this image over everything. So
             prioritizing every image is the same as doing none. But
             if you're judicious it could be useful. but if you're
             not implementing prioritization, there's no value.

  MaRakow: I think it's somewhat interesting, but I think it would
           be to allow auto to be lower quality. The safe default is
           high quality scaling. I think being able to have a
           differentiator would let us improve auto, not have a new
           higher quality.
  TabAtkins: So by default you can degrade more heavily because
             authors have an escape.
  MaRakow: We used to have MS interpolation and didn't see
           widespread use. So I think it's more interesting to let
           us slice the auto rather than a new higher level.
  TabAtkins: I see that. I see why slicing the semantics of auto
             more could be worthwhile. Okay.

  TabAtkins: I'm fine with accepting. Do we want to take naming to
             mailing list?
  fantasai: Why don't we reuse SVG names?
  TabAtkins: We can. That's certainly a good suggestion.
  fantasai: We should definitely accept those names.
  ChrisL: If it turns out we need others, though...we should look at
          those, but we may decide that they don't do enough.
  TabAtkins: Right now optimize is mapped to auto, we map it to the
             new one. Is the SVG good enough that we can use it? We
             can move to ML.

  smfr: The crisp edges value here...I suspect no UA implements this
        and it seems to conjure pixels from thin air
  ChrisL: I think Batik did it. Adobe for a while did but people
          abused it.
  TabAtkins: Mozilla does.
  TabAtkins: I don't know what the implementation does, but it has
             an effect other than auto.
  MaRakow: I think the image in the spec is from a wikipedia page.
  TabAtkins: Yeah, it's from wikipedia. pixel art scaling thing.
  <smfr> looks like crisp-edges is

Values and Units

New prose defining directional <<angle>>s as bearings

  <astearns> https://drafts.csswg.org/css-values-3/issues-cr-2015#issue-1
  <astearns> https://hg.csswg.org/drafts/rev/98da29d1dabb
  <fantasai> https://drafts.csswg.org/css-values-3/#angles
  fantasai: TabAtkins added prose stating that angles when used as a
            direction must be treated as bearing angles. I wanted to
            check with the group that this is appropriate.
  fantasai: Do we want to add this paragraph?
  TabAtkins: Every usage is bearing angles, but should we require it
             or leave it open to be something different in the
  Florian: I'm not sure it makes much sense for vague future, but a
           note for future authors not to do this accidentally
           sounds fine.
  TabAtkins: Sounds like not an objection, but you're also happy
             with a non-normative note.

  TabAtkins: So objections to it must be bearing angles?
  ChrisL: Can you say exactly what you mean by bearing angle?
  TabAtkins: Bearing angles means 0deg is pointing north and
             positive is counter-clock.
  ChrisL: Then east and north need to be in terms of coord system.
  TabAtkins: Yeah.
  TabAtkins: The few uses of angles in SVG match this, the old oral
             style sheets match, polar match.
  ChrisL: If all existing uses match, that's fine.

  TabAtkins: So objections to me requiring that across specs? Or are
             we okay with spec doing what they need to.
  <ChrisL> require is good at this point
  fantasai: I think we switch this to a note saying it's a
            convention in CSS and that will prevent the wrong way.
  Florian: I'm not convinced it makes sense to have normative things
           apply to spec authors.
  TabAtkins: It's the same as saying a pixel is a certain lengths.
             This is saying how angle is used.
  fantasai: Pixel is the same everywhere, but angle is sometimes
            direction, sometimes rotation, etc. I think it's not
            quite the same because it can be different. Transverse
            goes the other direction, is that not a bearing angle?
  TabAtkins: So you just said we use angle units as different things.
             But angles as directions we can give a consistent
  fantasai: It's not 100% clear what's a direction. Obvious hue is
            unrelated, but transforms I might think of as direction.
  Florian: I won't object, but I'd prefer a note.
  TabAtkins: We'll go for a note.

Review of calc() serialization principles and spec prose

  <astearns> https://drafts.csswg.org/css-values-3/#calc-serialize
  fantasai: TabAtkins...there was an e-mail saying that the
            serialization for calc() isn't defined, TabAtkins said
            he'd write it, he did, but there's been no review. So
            would people who care about this please review.
  TabAtkins: I did base it off some study, there is one bit missing
             where if you're going to get clamped, it doesn't go
             negative. That needs to happen between steps 1 and 2 of
             the current algorithm.
  fantasai: The point is, please review and lets come back.
  astearns: Any comments right now?
  fantasai: I'd be happier publishing this to CR if there was a
            positive review from someone other than me an TabAtkins.
            I was planning on that this month.

  <Bert> (Minor remark on serialization text: The parentheses in
         "(Terms with a value of zero must be preserved in this
         summation.)" should probably be removed.)

Add <foo-percentage> combo productions

  TabAtkins: I thought we agreed on this as a WG.
  fantasai: Sorry, I missed that resolution.

Defer toggle() to level 4?

  fantasai: Does anyone implement toggle()?
  fantasai: Apple? MS?
  <gregwhitworth> we don't
  fantasai: Do I assume no?
  fantasai: toggle() functional notation?
  Rossen: We don't implement that.

  Rossen: Was the question do we or are we planning to?
  fantasai: If no one implements currently I think we should push to
            level 4 and wrap up level 3.
  Rossen: I'm in favor of that. That wouldn't slow us if we want to
  smfr: Webkit doesn't implement.
  fantasai: Okay. I'll remove it once we have a level 4 draft.
  <dbaron> Maybe level 4 would be a delta spec for some period of

  astearns: Anything else on values and units?
  fantasai: Nope. Please review serialization.

gradient rendering & image-rendering property

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0017.html
  astearns: This is something Amelia brought up.
  smfr: This suggested image-rendering should effect gradients as to
        if they show banding or what have you. My reaction was for
        webkit we don't have the knobs for rendering. I'm not sure
        it makes sense, I'd prefer gradient looks good everywhere.
  Florian: I'm not sure just looks good is the point. In different
           context looks good means different things.
  MaRakow: I'd agree with smfr. In general we get more complaints
           about not having support than you would expect.
  TabAtkins: The only thing that justifies the switch is if you have
             perfectly vertical stripes and they don't align to
             pixel bounders. But that's so low profile...if we can
             make gradient rendering look good in general we should
             do that.
  Florian: That's the main one. Also if your stripes or horizontal
           or vertical, you don't want the algorithm to dither your
           stripes completely.
  TabAtkins: That can't happen. Stripes are a solid color region.
             Dithering is during a gradient region when you're
             actually ramping the color do you use algorithm.
  ChrisL: It's dithering to avoid mach-banding.
  Florian: As we get higher resolution the slightly fuzzy problem
           gets smaller.

  smfr: One consideration, if our graphics could do high quality but
        expensive to render, maybe that could be opt-in.
  TabAtkins: When that happens, implementors can create ridge
             rendering to support that.
  smfr: I don't want image-rendering to apply to gradients. So if
        you say pixelated do you turn off.
  TabAtkins: Pixelation controls scale...no...I see it. Image
             rendering is sole scaling quality so technically
             wouldn't apply to gradients. This can be re-written to
             apply to image generation. I don't think anyone can
             differentiate. If they do later we can make the small
             spec change.

  astearns: So, the people who have an opinion here, can you please
            reply to the thread? It would be good for people
            participating on the mailing list get that feedback.
            That we can't do it now and in the future it might not
            be as much an issue.

Layout containment and overflow

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0034.html
  Florian: When you're applying layout containment, but not paint
           containment, if we do as specced it doesn't work...if you
           have something overflowing from layout container it can
           go so far out it causes a scroll bar to appear.
  Florian: That scrollbar causes layout problems. We can say layout
           containment is also paint containment. Or when you have
           layout overflow it's paint overflow and therefore doesn't
           have scrollbars.
  Florian: Do does that sound reasonable? Do people who implement
           this have another way out?
  TabAtkins: The correct solution is stop having layout effect
             scrollbars, but I've been beating that drum for 5 years.

  Rossen: In general I would agree layout containment should be
          stronger than paint containment. So if I was writing those
          in priority order I would consider layout first for both
          scrollbars and overflow affecting other layout.
  Rossen: So one way out is to be explicit that for paint layout
          containment it resolves in paint containment.
  Florian: It works, but it's not good. So if you're doing layout
           containment it's not clear you want shadows clipped.
           There are cases where it's fine to have overflow, but
           there are times that it does effect containment.
  Rossen: I haven't thought about this too much and we haven't
          implemented so I can't comment.

  TabAtkins: We're in the middle of implementing. I'll ask our
             implementor what he thinks on it.
  Rossen: That would be great.
  fantasai: If I recall correctly Mozilla wouldn't have a problem
            doing paint contain if you have layout, but I don't know
            if it's user friendly. It's better than clipping to
            contained box.
  Florian: The only worry...
  fantasai: So you're proposals are 1) auto clip to contained box
            and 2) allow visible overflow, but if it overflows the
            parent scroller you can't see it.
  Florian: Yes.
  fantasai: Between those two, I'd go for showing more content. That
            seems to make more sense to me. You're less likely to
            clip things the user wants. And how we handle it in
            Mozilla I think that's straightforward to implement.
            Either would be easy to implement.

  Florian: Before we conclude, actioning tab to look at his
           implementation is good.
  ACTION TabAtkins ask his implementor about layout containment and
  <trackbot> Created ACTION-757
  <TabAtkins> sent the email, will report back when I get a reply.


  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0050.html
  * tantek quickly reviewed the agenda, and has only one comment,
           which is to support Florian's proposals re: css-ui-4
           -webkit-user-select as noted:

  Florian: User-select is implemented all over and with the webkit
           prefix it's also all over.
  Rossen: IE doesn't have it, Edge does.
  Florian: It's being implemented by other than the webkit family of
           browsers. So this is a bit like we said about word-break:
           break-word where if it's needed for compat it should be
           in a spec. So I'm proposing that it should be in CSS UI
           in a compat section.
  fantasai: In this case I don't think we do an appendix and put it
            inline with an actual definition as a short hand or
            parse time alias. One sentence at the bottom that says
            UAs MAY implement, authors MUST NOT and at some point
            this may be removed. That'll call a lot less attention
            to it.
  fantasai: The other one we needed a definition, but in this case
            it should be one line of normative prose. So the UAa may
            implement if they feel it's necessary for compat, it's
            not guaranteed to stay implemented.
  Florian: In general when something is clearly required for web
           compat, I'm not sure there's value in may.
  fantasai: There may be CSS implementations not interacting with
            the web, like Prince, they have no reason to implement
            this. An e-book reader may not care.
  Florian: This property isn't implemented without a prefix. It may
           shift some web content once that happens. Here I'm okay
           with a may.

  astearns: Objections?
  Florian: Additional data, the whatwg is doing this too, but they
           are happy to drop once we have it.
  astearns: I'm happy to have it in our spec. tantek mentioned in
            IRC that we should spec.
  TabAtkins: We should spec it.

  smfr: For impl with -webkit-user-select, how compatible is that
        with the unprefixed?
  TabAtkins: I don't think we have a difference.
  Florian: The differences are irrelevant for difference and used
           for none.
  smfr: So the spec will say only none or it's a synonym.
  Florian: That was my plan.
  smfr: I think we have very different behavior for user-select: all.
  <gregwhitworth> looking through bugs this morning it was mainly
                  focused on the none value
  Florian: There were differences on other values that were
           mentioned in spec. My assessment was this wasn't
           different enough for compat problems. It wouldn't cause
  Florian: Based on that people can align. If you're finding that
           the -webkit is different and you need to preserve both,
           that's something I'd like to know.
  smfr: I don't have data. I seem to recall in the past people had
        discovered incompatibilities.
  Florian: I found differences, but not ones that caused

  smfr: So UAs other than webkit; would you expect them to take all
        the values?
  Florian: I would not. I think syntax level alias is sufficient.
  smfr: I'm fine if the other vendors agree.
  Florian: Draft doesn't specify -webkit, just a behavior.
  astearns: Should the draft say people may implement this syntax
            level alias because web compat is required for the none
            value and mention there's no need to have other
            implementations match -webkit-user-select on the other
  astearns: Or is that too much detail?
  Florian: Overkill.
  Rossen: I'd agree.
  Rossen: In general we're implementing whatever makes the web work
          and we don't go into implementing everything that's in a
          webkit prefix if no one is using it.

  astearns: smfr are you okay with what's been proposed?
  smfr: I guess so. It sounded like Rossen was arguing it's not a
        pure synonym and it would make sense to only say the common
  Rossen: And it would give a way to deprecate them.
  fantasai: We can do that. We do something similar with page-break
            where the values map to a subset of the break values. If
            there's only one or two on -webkit that we care about we
            can say only those are alias and the others invalid.
  Florian: I'm not against, but I don't think that's what's being
           implemented. I don't want to spend extra work writing
           what's not being done.
  Rossen: So speccing only the fully interop set makes sense. The
          perfect example is all gregwhitworth's work with tables.
          It's not meant to describe new behavior, it's documenting
          status quo.
  Rossen: If you spec more you're encouraging interop gaps.
  Florian: So I'll need to test...there's one value only on IE and
           Edge and I'm not sure if it's alias to -webkit
  Rossen: I have to go and check.
  smfr: webkit doesn't support contain. Just auto, none and all.
  Florian: Yes, that came from Microsoft. So do they support it
           though the prefix.
  Florian: I'm in favor to just spec reality. If non-webkit just
           alias I'll spec that. If they only do the restricted set
           I'll do that.

  RESOLVED: Spec some set of -webkit-user-select values.

  ACTION Florian determine set of -webkit-user-select values to spec
  <trackbot> Created ACTION-758

  fantasai: Florian may want to come back with his set. We have
            'what's implemented' and 'what's needed' and we're not
            sure which set. Rossen is what's needed and Florian is
            what's implemented.
  astearns: Even if there's a larger set implemented we should only
            spec it if it's interoperable.
  Florian: I don't think interop is a problem here.
  Florian: I can't evaluate if extra values are needed. I take it if
           other browsers implement them, they are. So that's why I
           want to spec what the browsers do.
  Florian: If spec what they do isn't right, some one else needs to
           decide needed.
  fantasai: Can Rossen or gregwhitworth figure out what's needed for
  <gregwhitworth> sure - I'll take it

  ACTION Rossen figure out what's needed for -webkit-user-select
  <trackbot> Created ACTION-759

  astearns: We are done.

  <Florian> Just checked, and both Edge and Firefox do a direct
            property name alias on -webkit-user-select, meaning that
            they support under that prefix all the values they know
            about, including the ones webkit never supported.
  <Florian> So Firefox supports "-webkit-user-select: -moz-none" and
            Edge supports "-webkit-user-select: element"
Received on Thursday, 18 February 2016 00:51:10 UTC

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