[CSSWG] Minutes Sydney F2F 2016-02-03 Part IV: CSS Masking, Filters, Gradients & Dithering, Investigation about JS API for Realizing Level of Details, Transitions and Animations, Matrices [css-masking] [filter-effects-2] [css-transitions] [css-animations]

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


CSS Masking
-----------

  - RESOLVED: Change 'auto' value of mask-mode to 'match-source'.
  - birtles will investigate dropping mask-type. If it's not
      dropped, he will update the normative text.

Filters
-------

  - The authors will keep moving the spec toward CR.
  - Tav presented a new filter primitive he'd like added to level 2;
      dino agreed it was interesting and will look into adding it to
      the spec.

Gradients & Dithering
---------------------

  - Either AmeliaBR or Tav will create a proposal to either offer
      author control or spec guidance for browsers on dithering.

Investigation about JS API for Realizing Level of Details
---------------------------------------------------------

  - stakagi presented some very detailed work he had done (Available
      here: https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Investigation_of_APIs_for_Level_of_detail)
  - His wiki will be linked to from the spec as a list of things the
      spec needs to address.

Transitions and Animations
--------------------------

  - Both specs are being worked on.
  - dbaron expressed a desire to have help in making progress.

Matrices
--------

  - zcorpan requested review of the edits he made in the WHATWG
      geometry spec https://github.com/whatwg/compat/issues/19

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/sydney-2016

Scribe: alancutter & nainar

CSS Masking
===========

  astearns: We can go to afternoon topics: dbaron's conflicting
            values in mask shorthand.
  <astearns> https://lists.w3.org/Archives/Public/public-fx/2015OctDec/0021.html
  dbaron: mask properties do something we said we wouldn't do again.
  dbaron: I suspect... let me get the spec.
  <dbaron> https://drafts.fxtf.org/css-masking-1/#masking
  dbaron: The basic problem is the mask's position section (chapter 7)
  dbaron: It has a bunch of properties analogue to background
          properties and a bunch of new properties.
  dbaron: One you have these values...two have an initial value of
          auto.
  dbaron: Makes parsing shorthand painful.
  dbaron: Change mask shorthand to anything that is not value of
          other properties.

  dbaron: Question 1: constrained by compatibility: not do it at
          this point
  heycam: We might be the only one that do mask-mode.
  heycam: Extending mask-mode and mask properties might be two
          separate things.
  heycam: We should be safe in renaming the initial values, even if
          people use mask-mode they probably don't specify the
          initial values.
  dbaron: So does anyone implement mask-mode? looking at apple and
          edge and chromium folks.
  dbaron: Less looking at chromium.
  eae: We don't implement mask-mode.
  eae: We do not implement.
  heycam: WebKit does not implement it?
  heycam: Gecko has patches on nightly but not on other channels.
  dbaron: Mask-mode was done a year ago - separately from other
          properties and is shipping.

  astearns: Are you concerned with existing content?
  astearns: ok with getting other values?
  astearns: Mask-mode should not have a value called auto?
  dbaron: mask-mode is part of mask shorthand
  dbaron: I'm pretty sure cjs patch added a mask property
  heycam: I would be pretty surprised if we couldn't change the
          initial value names.

  dbaron: Question - initial value for this property that isn't auto
  heycam: This is the value that means...
  astearns: either luminance or...
  <AmeliaBR> "auto" means luminance for <mask>, alpha for <image>
  heycam: or alpha depending on whether we're referencing an SVG ?
          or not?
  dbaron: Yeah it really is a value we could auto - doesn't belong
          in shorthand where it also has value auto.
  astearns: It's better to change this than the mask-size property
            as that's following background-size.
  dbaron: Correct.
  dbaron: webkit implements...
  AmeliaBR: normal acceptable synonym to auto
  dbaron: Webkit implements a bunch of these but not the mode
          property.
  dbaron: Check that there isn't a normal in these other properties.
  heycam: It looks like the property got renamed at some point. When
          we shipped it it was called mask-type.
  dbaron: The spec has both mask-mode and mask-type.
  dbaron: Now we have mask-mode as well.
  dbaron: In S 9.2 has a mask-type with values luminance and alpha;
  dbaron: in S 7.1 mask-mode has values luminance and alpha.

  AmeliaBR: The different is make-type is on the <mask> element and
            mask-mode applies on the element you're masking.
  fantasai: We probably don't need both.
  fantasai: Makes a lot of sense - mask-type was for backwards compat-
  fantasai: otherwise could give it a different name.
  AmeliaBR: It's something requested of SVG a lot, possible
            introduced in SVG1.2 and wasn't in SVG1.1.
  heycam: Seems like it is safe to rename.
  astearns: Shall we resolve to fix this in some unknown feature
            solution?
  dbaron: We need a name sooner rather than later - need to ship this.
  dbaron: Others haven't implemented mask-mode
  shepazu: Do you have a suggestion?
  dbaron: Normal works, by-type or by-image?
  dbaron: Or something like that.
  <fantasai> match-source?
  <fantasai> like match-parent?
  AmeliaBR: If you're going to keep mask type-then mask-mode should
            account for the mask element itself might have a
            preference?
  AmeliaBR: The logical would be something like use-source or
            use-element.
  AmeliaBR: If it's an image use alpha.
  AmeliaBR: If they both exist then the default value of mask-mode
            is to use the mask type of the mask element.

  astearns: In example 9 it shows how you would use mask-mode to
            override mask-type
  astearns: not just a mistake of realizing the other was in spec
            already.
  fantasai: I think mask-type was added because it existed somewhere.
  birtles: I might have added it.
  AmeliaBR: It definitely used to have a default override.
  AmeliaBR: The wording of it, if using a word other than auto
            should use a word defined in the source.
  birtles: Added both properties - added mask-type first as authors
           wanted to specify..later added mask-mode..don't need
           mask-type
  birtles: Content should interpret luminance/ alpha values
  birtles: introduces complexity.
  birtles: Order by-type source-type makes more sense when referring
           to image 8.
  fantasai: We could do match-source.
  <astearns> +1 for match-source
  birtles: We probably introduced mask-type as an attribute at first
           and it became a presentation attribute.
  birtles: Probably can drop it.
  astearns: mask-mode would still need that value
  astearns: not a replacement.
  astearns: Like source-type as a value.

  RESOLVED: Change auto value of mask-mode to match-source.

  birtles: If we don't drop mask-type .. the example is right, it
           follows the mask-type of what it's following but the
           normative text says to use luminance if referring to an
           element.
  astearns: Can we put an action on you to update example and
            investigate that mask-type can be removed.
  dbaron: Update normative text.
  birtles: If we don't need mask-type we should just drop it.
  birtles: If we don't drop it, update normative text.
  astearns: Are we set for that topic then?
  dbaron: As far as I am concerned.

  ACTION birtles: Investigate dropping mask-type property
  <trackbot> Created ACTION-756

  astearns: Next topic: Transitions in animations
  birtles: Can we do that after lunch?
  astearns: After lunch, sure, after lunch.
  astearns: Let's start on filters.

Filters
=======

Spec Status
-----------

  <Tav> http://tavmjong.free.fr/SVG/FILTERS_SYDNEY_2016/
  Tav: The first part, I want to understand CSS's status, what plans
       are there to get this to CR?
  Tav: It hasn't been updated since 2014, anyone know what's
       happening?
  Tav: Anyone working on it?
  fantasai: Who is editor?
  Tav: krit.
  <astearns> (and Dino)
  ed: I'm also one of the editors - close to moving to CR.
  ed: There might be a few ...
  fantasai: Test cases are a CR issue, not a moving to CR issue.
  dino: I'm also one of the editors. Maybe I could push the last
        three issues along.
  Tav: That was the first thing.
  dino: Apple would like to see this go forward.
  dbaron: We have a bunch implemented and it's shipped.
  <AmeliaBR> Firefox & Edge have shipped, Chromium still uses
             prefixes
  Tav: I think chrome has it for HTML but not SVG.
  dino: WebKit is interested in pushing this to CR. I'll take over
        the editing.

Filter Primitive
----------------

  Tav: I have a filter primitive that I'd like to see added to a
       level 2.
  hober: What does that mean?
  <ed> https://drafts.fxtf.org/filters-2/
  Tav: I'd like to see an additional filter primitive but not as
       part of level 1.
  dino: Sure, yeah, we have all already agreed that this is what we
        will push to CR - when you say new primitive
  dino: We not might not necessarily mean a new CSS shorthand right.
  Tav: Not a shorthand, an actual primitive.
  Tav: We have a lot of filter primitives that Apple would like to
       see in our native apps.
  Tav: We've held off - waiting for other implementations to catch up.
  Tav: You'd be interested in level 2?
  astearns: There already is a level 2 document.
  astearns: Already a document that is L2.
  dino: That describes backdrop filters.
  dino: It's in a limbo where Webkit has a proprietary
        implementation. There's discussion to move it to a new
        syntax...
  <AmeliaBR> This email should turn into an issue on Filters 1 spec:
             https://lists.w3.org/Archives/Public/public-fx/2016JanMar/0020.html
  Tav: OK so that covers the first item.
  Tav: We (InkScape) have gotten a lot of complaints about uncanned
       filters.
  Tav: Some of them try to make things look 3d
  Tav: There are a lot of artifacts - this is a result of lighting
       filters of images using 3 filters channel.
  Tav: Get large steps generated by Gaussian blurr,
  Tav: There are only 8 bits per channel that causes large steps.
  Tav: You can see that what you want is a red line - you get a
       black line.
  Tav: That produces artifacts. F3 shows that where instead of using
       an internal bump map you use external one.
  Tav: One of the issues in 22950(?) all the ranges should be
       between 0 and 255 or 0 and 1.
  Tav: In spec if we state between 0 and 1 allow floating point
       value - more bits to work with.
  Tav: A quick scan of spec shows that FE filter primitives use 0 to
       255 - need to be changed.
  Tav: Idea is to allow more bits basically - to go into these
       calculations.
  dino: Sounds like a good idea that needs investigation.
  dino: Need to fix it.
  Tav: So basically you'll take on the job of finding out what's
       required?
  astearns: Amelia suggested on irc that this should be an issue on
            level 1.
  Tav: That's what I had for filter issues.
  dino: Yes, I think you weren't here for discussion on colors

Gradients & Dithering
=====================

  dino: Can we talk about positions in gradients, we get complaints
        about banding in gradients.
  dino: We have hardware that supports more colors we would like a
        way to specify colors and see less banding.
  Tav: You do dithering or something?
  dino: Actually I was always wondering why we don't have dithering
        for gradients.
  dino: Why don't we specify for css gradients (and svg) add noise
        of dithering to not see banding.
  Tav: We've gotten complaints about that, people won't use Inkscape
       because of banding or they use workaround to add the noise
       themselves.
  dino: Right, it would be good if leaverou was here - she would
        complain about it.

  dino: We have a pretty easy solution - no one has suggested we do
        it.
  shepazu: I have a suggestion.
  Florian: Is dithering difficult to implement?
  <AmeliaBR> I don't think there is anything in the spec that
             prevents implementations from using dithering
  dino: On apple platform not easy for us to do.
  dino: We will try to find a way to do it.
  Tav: We rely on a library and we're thinking of adding it to the
       library.

  Tav: What would be a way forward for dealing with this?
  dino: Someone should make a proposal to the mailing list or I
        mean...then we can have the discussion on how to add it to
        gradient syntax.
  dino: Implementation should do it by default.

  dino: There will be cases where an author wants dithering - css
        gradients are using it to stripy lines gradient effects
  dino: in a gradient.
  Tav: How do you do checker boards? Oh lots of stops I see.
  AmeliaBR: It's already an issue whether implementations alias or
            not before you get to dithering comes in.
  AmeliaBR: Some implementations don't alias the edges of
            vertical/diagonal stripes.
  AmeliaBR: That can create fuzzy edges on ... stripes.
  AmeliaBR: There's already a variety of implementations.

  Florian: As for dithering breaking these use cases - do the
           dithering carefully
  Florian: can do it in a way that doesn't break it..
  Tav: Did that use enough time?

  dino: So who is going to make this proposal, do you want to make
        it Tav?
  Tav: I could make the proposal.
  dino: Maybe AmeliaBR wants to make a proposal to control aliasing -
        use different aliasing
  dino: I don't know.
  AmeliaBR: Talking about having a property to allow author control
            or spec guidance for browsers?
  AmeliaBR: I'm looking towards making colors as smooth as possible,
            use something else for stripes.
  dino: ok

Investigation about JS API for Realizing Level of Details
=========================================================

  astearns: On to the next thing, we have 30m before lunch.
  <stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Investigation_of_APIs_for_Level_of_detail
  stakagi: Please see this wiki.
  stakagi: In response to last discussion - next chapter this
           assumes content for level of detail.
  stakagi: This investigation assumes - it's a characteristic that
           sources are embedded - our sources interact with
           geographical systems.
  stakagi: Must be documented by document object model.
  <heycam> stakagi quotes from the wiki page: "The typical form of
           the contents which this investigation assumes is as
           follows. They are the hierarchical contents by which
           tiling was performed for each level of a detail. It is
           characteristic that each resources are embedded using
           iframe. It is because our usecase is interactive
           geographic information system, so graphics must be
           operated by DOM."
  stakagi: CSSOM build modules and CSS device adaption module 1.

  stakagi: Next chapter investigates panning or zooming action.
  stakagi: As CSSOM view shows there are two kinds of zooms, page
           zoom and pinch zoom.
  stakagi: Each browser implements natively.
  stakagi: I find CSS device adaptation has called pinch zoom and
           magnifying glass type zoom.
  stakagi: Page zoom is resize event where it has an issue.
  stakagi: The issue describes - pinch zoom picture defines scroll,
           they also have issues. For scroll there's a scroll event.
  stakagi: APIs for zoom - is next API. One is page zoom there's
           device pixel ratio where there's also an issue. Pinch
           zoom also has issue.
  stakagi: There is device pixel ratio - there is also issues - and
           pinch zoom has also issue.
  stakagi: <Reading wiki>
  stakagi: <Reading "The issues on existing APIs" section>
  stakagi: <Reading "Points in question" section>
  stakagi: That is my investigation of level of detail APIs.

  astearns: Thank you for the investigation - useful info.
  astearns: Sounds like something that should go into viewport work
            that we are going to do.
  Florian: As a co editor of spec I agree there is a lot of
           editorial work needed to clarify the visual viewport.
  Florian: Having rewritten and clarified what the various
           viewpoints are gives us the various types of zooming.
  Florian: For all the points you made about this I agree it's been
           a matter of prioritization.

  Florian: One thing I disagree on is about transform.
  Florian: Maybe a discussion would change my mind if transform was
           out of scope.
  Florian: Maybe discussion is to be had but I think this is out of
           scope for transform.
  Florian: Had many side list offline discussion about what should
           happen to spec - agree to editorial problem.
  Florian: I think that what it currently defines is the right
           behavior but it should define more things.

  Florian: The problem has been having the time to work on it.
  Florian: How to make that actually happen - everyone involved in
           that spec agrees to the problem.
  Florian: I want to, but have other things to do first.
  Florian: Matt from Microsoft has been added as a coeditor.
  Florian: I would be surprised if he disagrees but probably is busy.
  Florian: Same for Rune from Opera.

  Florian: Except for transforms, I agree with everything you said.
  astearns: At the very least we should take this report as an issue
            (several) things to work on
  astearns: in that spec.
  Florian: I would rather add one issue that points to the entire
           report instead of slicing and possibly missing things.
  astearns: It records that it's something that needs looking at at
            some point in time.
  Florian: There is substantial overlap with an article and what he
           is saying.
  Florian: We can have both issues and both reports, they're asking
           for the same changes to the spec.

  astearns: I recall that we talked about having a new document that
            defined viewport better
  Florian: The document we talked about assigned to Peter, Rossen
           and I is fuzzy about the viewport.
  Florian: It's the thing around the root.
  Florian: We may find that it's the missing thing or we won't it's
           not clear.
  Florian: Once the other spec starts existing maybe some pieces can
           shift between the two.

  astearns: Is there anything you wanted to talk about on this topic?
  stakagi: Can I help your work? <points to Florian>
  Florian: I want to answer yes but I'm not sure how.
  Florian: I would like detailed issues about - but before that I
           think we'd need a rewrite to get consistent vocabulary.
  Florian: Even though the end result is correct. Maybe I'll add an
           issue in addition to the report that there should be an
           API for this.
  Florian: We could file an issue about the vocabulary, it needs a
           general overhaul.
  Florian: I have very little or no time to work on this.
  Florian: Thanks for the offer of help.

  astearns: Alright then , break for lunch - come back for one
            remaining agenda item

Best Practices
==============

  fantasai: BTW I'm doing a talk on best practices on CSS, if you
            have anything you want to convey to the web authors
            let me know.
  fantasai: "Use shorthands to reset things because they will reset
            all the things"
  dino: Don't use index over 999, anything below that is fine
  dino: use SASS
  <franremy> fantasai: use grid or flex not floats for grids
  astearns: Let's lunch

Transitions and Animations
==========================
  Scribe: ewilligers & alancutter

  astearns: The last item is a discussion of transitions and
            animations.
  astearns: Path and obstacles to CR.
  dbaron: I'm hoping I'll get time to edit the path spec/transitions
          spec. It's hard to make promises.
  dbaron: If someone wants to help that will be useful but I'll try
          to make progress.
  birtles: Working on css animations, made some edits,
  astearns: Does anyone want to have a deeper discussion about the
            path to CR?
  <AmeliaBR> Can anyone say what the obstacles are?

Matrices
========

  astearns: So we have an update that Simon wanted to give.
  <zcorpan> https://github.com/whatwg/compat/issues/19
  zcorpan: In the geometry spec there's an interface for matrices.
           I've made some edits to make it incompatible with CSS
           Matrix.
  zcorpan: This is FYI, please review.
  zcorpan: In particular that I didn't break compat.
  zcorpan: As part of this a few methods were dropped because they
           were the same as some other methods.
  zcorpan: Please review if there's a use case for them and we
           should add them back.
  <astearns> https://drafts.fxtf.org/geometry/#changes
  heycam: I'll compare it with SVG Matrix.

Summary of Scrolling Breakout
=============================

  astearns: Can we get a summary of the scrolling discussion?
  astearns: I am interested in what happened during breakout.
  shane: The full minutes are available on public-fx.
  shane: We talked about scroll triggered animations and parallax
         ideas that were brought to TPAC before last.
  shane: There are potential problems with animations re-triggering
         themselves but overall there's a fair amount of interest
         across browsers
  shane: to get this area specified.
  shane: Next steps is dino will  write an explainer document
  shane: We will be very interested in people asking questions,
         making suggestions and bashing on it.
  <zcorpan> log: http://www.w3.org/2016/02/02-fx-irc

  astearns: That exhausts agenda
  astearns: We are adjourned but we have time to keep working
            together.
  astearns: And there is the event tonight.
  shane: We have 5 talks scheduled: best practices, css grid,
         houdini, round displays, new features in svg 2
  shane: There are 180 developers of all stripes signed up to show.
  shane: Please come tonight and show who you are, it's an excellent
         opportunity to meet the people you're building features for.
         Please come.
  shane: In this room at 6:30
  astearns: Adjourned.
  astearns: <Hammer>

Received on Thursday, 24 March 2016 00:02:07 UTC