W3C home > Mailing lists > Public > public-houdini@w3.org > October 2015

Minutes Paris F2F 2015-08-29 Part I: Next F2F Meeting, Custom Paint

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 16 Oct 2015 19:44:37 -0400
Message-ID: <CADhPm3vyMXans9M8HviWHsh-_3Vm3NakhcCdB5LcDYpJ_Y+vPQ@mail.gmail.com>
To: public-houdini@w3.org
Next F2F Meeting
----------------

  - RESOLVED: Meeting 30 and 31 January in Sydney.
  - RESOLVED: Meet for a half day at TPAC during plenary day

Custom Paint
------------

  - One of the main issues remaining is if the spec should re-use
      the existing canvas rendering 2D which has a lot of
      unnecessary properties or create a new context.
      - Most people thought there should be no readback.
  - The buttons on http://materializecss.com/ were brought up as a
      use-case that this spec should make easier to do.
  - There is an open question as to how to deal with
      box-decoration-break: slice
  - Another open issue is how to deal with a paint that happens to
      be an image.
  - There should be an examples to show that randomness needs to be
      in a property that's an input to ensure you get the callback
      once for each heading with a different image and that the
      callback needs to be consistent about what results from a
      particular custom property value since the callback might get
      called multiple times for various forms of redrawing.
  - It was thought the spec should allow, but not require, backing
      stores.
  - The visual overflow should do a callback right after it styles
      to do the tree walk.
  - The inability to use intrinsic size for border-image will be
      marked as an issue.
  - Allowing 3D was briefly discussed, but several people felt it
      was likely too complex to be part of the first version of the
      spec.
  - Another outstanding issue is if you stretch do you want to
      rescale or do you want to know your new geometry.
  - In some future level of the spec there should be a mechanism to
      create new rendering contexts.
  - If a paint function throws an error in the middle, a blank image
      with no dimensions will should (hooking into the existing
      behavior of CSS Image)
  - Long running paints should be handled in the same manner to long
      running JavaScript.
  - For version 1 of the spec doing full invalidation is fine.
  - RESOLVED: FPWD for Custom Paint (which will include the feedback
              from today and more examples)

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

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Rick Byers
  Tantek Çelik
  Dave Cramer
  Rob Flack
  Simon Fraser
  Dael Jackson
  Dean Jackson
  Brian Kardell (phone)
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Cameron McCormack
  Simon Pieters
  Liam Quin
  François Remy
  Florian Rivoal
  Simon Sapin
  Elliott Sprehn
  Alan Stearns
  Shane Stephens
  Ojan Vafai
  Lea Verou
  Ian Vollick
  Greg Whitworth
  Steve Zilles

Regrets:
  Daniel Glazman

  agenda: https://wiki.css-Houdini.org/planning/paris-2015?&#agenda
  scribe: dael

Next F2F Meeting
----------------

  Rossen: Good morning, everyone.
  Rossen: I don't think we have a next meeting planned. We mentioned
          briefly we might want to do Sydney. There's TPAC in
          between.
  dauwhe: TPAC is iffy because people have tickets.

  shane: Let me check into space for Sydney. It's a bit iffy because
         SVG is meeting.
  plinss: Last time we talked SVG was after CSS and Houdini was
          before.
  shane: I have that week and the weekend before and after blocked
         out. We can't overlap because there's only one room.
  Rossen: heycam what's on your calendar.
  heycam: I'm not sure.
  shane: Let me check on dates.

  Rossen: From what I'm hearing people are concerned about TPAC.
          What if we could find non-CSS dates?
  TabAtkins: I'm down with that if we need it. Do we need something
             in 2 months or give ourselves 6 months?
  shane: This event felt like a forcing function so I suspect if we
         decide we'll next meet in Sydney we won't see work until
         close to then, like happened for this. TPAC is a short term
         target.
  Rossen: That's true, but is that the only way to have a forcing
          function?
  ojan: I want the forcing function, but don't think I can make it
        to TPAC.
  Florian: The Sunday before TPAC we have the CSS Japanese Community
           Meet-Up.
  shane: Could we do a half day?

  gregwhitworth: I think we should use the plenary day as a half day.
  TabAtkins: So those of us there will meet up and talk and it's not
             a big deal if you can't be there.
  dauwhe: Sounds good to me.
  TabAtkins: Use part of the plenary day to do some spec review.
  dino: Okay.
  Florian: Like two time slots.
  dino: So we're not getting a meeting room, we'll just use the
        plenary. OK
  liam: Keeping momentum is good.
  Rossen: Sounds like a half day on the plenary day of TPAC is good.

  Rossen: How about Sydney? The weekend before or after?
  heycam: SVG was the 4-6. Is that Thursday to Saturday?
  Rossen: And CSS is the 1st?
  plinss: Through 3rd.
  Rossen: So for Houdini we only have 30 and 31 Jan which is a Sat.
         and Sun.
  ojan: Could we do 28 and 29 Jan?
  shane: Depends on if I can get meeting rooms.
  shane: We made it 30 and 31 to minimize time in Sydney to reduce
         travel costs. Florian were you one that asked for that?
  Florian: I may have been, but I'll be in Japan now.
  TabAtkins: My travel cost is time spent away from home.
  Rossen: Me too.

  Rossen: If we did the weekend is that okay dino?
  dino: It's okay. I'd prefer not weekend, but it seems like the
        consensus is to minimize time.
  shane: I'd prefer not weekend too, but I understand.
  Rossen: Is anyone not able to make the weekend 30 and 31 January
          in Sydney?

  RESOLVED: Meeting 30 and 31 January in Sydney.
  RESOLVED: Meet for a half day at TPAC during plenary day

  Rossen: Do we need to plan anything ahead? I guess not

Custom Paint
------------

  <iank> https://drafts.css-houdini.org/css-paint-api/
  iank: What I was hoping was to get a discussion about author
        current issues and if this is a good way to move forward. Do
        people want a rough overview?
  many: Yes.

  iank: I'll skip to the example. What you get is inside one of
        these Houdini workers you get a registered paint function.
        This allows you to register a custom paint function, a list
        of property dependencies, and a paint callback. This gives
        you a canvas rendering context, just 2D, it gives you your
        geometry of the fragment you're painting into and it gives
        you a typed property map.
  iank: This is how you use it. The image type in CSS is extended to
        be image or paint now and this can accept the named function
        and paints into the background image layout.
  Rossen: Can you go over the context?
  iank: This is one of the big issues. In the spec it raises canvas
        rendering 2D, but it doesn't have any readback or other
        methods that make no sense. Things like drawing focus rings.
        The reason you can't get data is it works in an intermediate
        mode. There's no retain on it, you have to paint every time.
  iank: This is one of the big issues. There's three ways of looking.
        We can re-use the existing canvas rendering 2D, but it has
        all the functions that make no sense. The better option is
        to create a new canvas rendering context that's write-only
        canvas rendering that takes a strict subset.
  iank: Do people have thoughts on which is right?

  smfr: The write-only one can be a base class.
  iank: Yeah. We can do a parse interface and just mix it in. The
        base class might be interesting for webcompat.
  dbaron: Are there any similarities to the workers on canvas?
  iank: I think they explicitly allow grabbing the image out.
  dbaron: I would have thought they wouldn't have had the various
          a11y things.
  iank: That's true. They explicitly want the readback.
  esprehn: I think the goal was to split canvas into a series of
           partial interfaces.

  Florian: Why no readback?
  iank: It doesn't allow for a bunch of optimizations. So things
        like being able to, if you have a long page, the UI can opt
        to through the previous data; if there's readback you can't.
  smfr: And you may want to not store this as pixels.

  iank: So it sounds like we should talk to the canvas folks.
  dino: I don't think there is canvas folks.
  iank: Yeah. We've got our subset. Anyone opposed?

  Florian: On the syntax side, I'm not sure which I prefer. That
           paint function which isn't what you would have in a
           normal CSS design thing, you don't have the magic there.
           If you have a separate property you can have a trigger
           and then you need a double hook.
  Florian: On one hand this is weird, on the other hand I'm not sure
           if we want to expose the broadest place if it's the
           background or cursor and that long list looks bad.
  iank: So you're saying a more idiomatic way would be verified
        reference of the layout property.
  smfr: This is similar to what we do in canvas. I think it's okay.
        I'm not sure paint is the right thing.
  iank: I'm fine with bikeshedding.
  Florian: The way the syntax is described here is fine, but you're
           having a double dependency here and so you can't have a
           background circle property that would trigger the circles
           being drawn, you also need the paint function.
  shane: I think this is a trade off. On one hand you have the
         double dependency, but this lets us slot into the existing
         way CSS does images and you can also stack these things. So
         I think it's worth it.
  TabAtkins: And if you didn't want to write the background image
             you can register an apply hook to the property, you can
             write it yourself as the only controller.
  Florian: So the current proposal looks like the best thing, but
           I'm still iffy.

  esprehn: The only proposal today that has what you're explaining
           is inheritance.
  Florian: Another comment, you list the dependency property, you
           probably need to specify you're depending on the used
           value. That's because if you're depending on width you
           want to call again if the used value is called.
  TabAtkins: Yeah.
  shane: The properties don't have to be used value.
  Florian: They have to be actual.
  iank: When your layout changes, your paint function will get
        called if your geometry or your layout gets changed.
  TabAtkins: There's no explicit width or height dependency. What
             you actually want is not width or height, you may be
             using this in a list marker. You just want to know if
             the size has changed.
  Florian: We should take it as late as possible in the chain.
  TabAtkins: Given that it's late in the chain anyway, that's fine.

  TabAtkins: Are we planning to do argumented in this level?
  TabAtkins: This won't do let's do a custom conic gradient.
  iank: One thing this doesn't cover is how to do conic gradient.
        This doesn't allow you to do your own custom gradient.

  smfr: Can I do the same paint function on different elements with
        different sizes on mobile?
  iank: Yes. It registers one function, it may be used 50 times.
  heycam: What happens when you have something split over lines.
          There's one that controls how background image splits?
  iank: It'll get called twice for each fragment. This is an open
        issue. One you could expose the geometry you are and your
        sibling fragments.

  TabAtkins: That brings up another question. This interaction with
             box-decoration-break, if you're cloning it's obvious
             each fragment should get a different call. If slicing
             it makes sense to draw into the combined size and then
             slice.
  smfr: I'd argue it would be better if this is agnostic about
        box-decoration-break. Authors may want to do special
        behavior with splitting and broken.
  TabAtkins: I'm not sure I agree. I'd like box-decoration-break to
             work automatically for now.
  dbaron: If you got a separate callback for the cloning one...What
          if that had enough information to do whatever you want. If
          box-decoration-break is slice it would automatically break
          it up. If you want to clone it gives you the number of
          boxes and you can do something else there. Is the default
          slice?
  TabAtkins: [tentative yes]
  <dbaron> The idea was that box-decoration-break:slice would mean
           the UA would give a canvas covering the whole thing and
           auto-slice it up; box-decoration-break: clone would mean
           multiple calls to the paint callback for each fragment,
           with the fragment number, which would allow the callback
           to do whatever arbitrary behavior it wanted.
  iank: So we need to expose all the information of the fragments.
  Rossen: Or enough of the previous fragments.
  smfr: Level one might be good for just boxes.

  Rossen: If it fragments this does work?
  smfr: Weeeeelllllll...
  iank: A simple thing we can do is which edge of my box was
        connected to my previous fragment as a simple version 1.
  Rossen: Is there any other state you need? Like if background is
          active?
  TabAtkins: For now without arguments you just register the paint
             style.
  dino: You don't need an argument you can just do a different
        custom property.
  TabAtkins: They are a different function, but only if you're
             calling once per element.
  franremy: The issue with using custom properties for arguments if
            you want more than one gradient as background you're
            screwed because you can't send arguments to each.
  shane: I think we'd add that in a future level.
  TabAtkins: This gives you all the power in webkit-canvas and most
             of the element function.

  gregwhitworth: When you said they're meaningful consumption, we'd
                 like real use cases.
  iank: A couple we would use internally is the material design
        button. They went through lots of iterations to get that
        performant.
  TabAtkins: Is everyone familiar with the button ripple in our
             material design?
  iank: [pulls up http://materializecss.com/] There's a ripple
        following out from when I click on the button. The DOM
        structure is 'interesting'
  iank: That's the kind of thing.
  heycam: You're saying that's possible at the moment or you'd like
          to make it possible?
  iank: It's possible, but we'd like to make it easier and more
        performant.
  Rossen: In this example your geometry isn't changing? What is
          triggering the additional callback when geometry isn't
          changing?
  iank: As an input you'd have a custom property that is a list of
        where your click originated and a time and animate on the
        radius.
  dino: You'd have a set of custom prop when the user clicks, then a
        transform, okay, I get it.

  smfr: Can you get time?
  iank: There isn't in this. If you wanted one you would create a
        custom property and throw a web animation at it.
  smfr: So the geometry or custom property needs to change.
  iank: Yeah.
  ojan: This is similar to how the underlying system works.
  TabAtkins: In the worst case you could have a dummy custom
             property you have to tickle to change, but if that
             becomes a problem we can change.
  shane: We don't want people register sensitivity to time.
  iank: As soon as time is an input we'll get wildly differing UI
        behavior.
  heycam: That's what you'll get anyway. What's the difference
          between that and having a time passed in. I was thinking
          of creating a custom property that represents the time.
  shane: You can do that, but there's better way to do that.
  iank: We don't want to paint indefinitely into time.
  TabAtkins: You could, but only on an animation that's set to
             infinite.
  shane: And that's under the control of the animation system.

  shane: I'd like to suggest we take this to FPWD.
  Rossen: Thoughts?
  smfr: I think people will want to draw images. People talk about
        wanting custom border radius, so adding images is important.
  iank: I think that's part of the typed OM spec. It would have if
        this image has loaded and you could also have an image
        bitmap.
  TabAtkins: That implies you're passing in via a custom property.
  dino: You might want to use a mask image.
  shane: Once we have function arguments for paint.
  dino: I want it where I can find a function.
  TabAtkins: You want a paint that happens to be an image.
  shane: You have to get it into the context somehow.
  TabAtkins: How do we get it in there is the issue.
  dino: The paint global scope...you could have some kind of a pair
        function.
  rbyers: This goes back to the debate about the state. You'll have
          life cycle.
  franremy: When you load the image previously it will possibly not
            be ready to paint. That's not something in the draft.
  heycam: In the worst case you can encode the URL. Update the
          script that says run worker and update that.
  iank: We'll take that as an issue.
  dino: Having some kind of initialization would be useful.
  smfr: There may be extensive set up.
  TabAtkins: And you want to be able to cache for painting and
             register that. Any relatively expensive thing you don't
             want to recompute every call
  iank: This has a paint callback and there's an issue to make this
        class paste instead. This will be fairly easy to do in the
        constructor.
  ojan: I think that syntax gets you multiple callbacks.

  smfr: Second issue is that if you register this on multiple
        elements you get called for each elements. I don't want to
        use more backing store than webkit-canvas so I want to be
        able to store for elements with the same geometry. I want to
        say that I don't want to call this more than once for items
        with the same geometry.
  TabAtkins: Could that be controllable? I've thought of use cases
             where I'd like every heading to look a bit different.
             In the default it would register the same. But we
             should have an opt in for 'no, never mind'.
  ojan: Would those be different property?
  TabAtkins: So I want a fancy, unique drawing on each heading.
  rbyers: Then you have to do that with custom properties with a
          different value.
  shane: You can't have both not random and not specific.
  TabAtkins: Okay. I get you. Never mind.

  ojan: The main open question is if the spec should say
        implementors are required to called once or allowed to call
        once.
  iank: I think, calling how ever much you want is fine.
  ojan: I was going toward the opposite.
  TabAtkins: If you want randomness you have to be able to control
             how many times you are called.

  Florian: If you want the painting of a background to be influenced
           by the content of the element, how do we extend this to
           allow that?
  esprehn: There are properties that instead from only accepting CSS
           you an accept more complex values. You have to be
           explicit on what you depend on.
  Florian: We have the element function, how do we track that it
           changed?
  TabAtkins: Given security concerns that won't be exposable. If you
             want to do something like text-shadow, some of those
             move into the user land. Shaders was something that
             everyone thought was too complex for now. Nothing
             conceptually against it, but it's hard implementation-
             wise.
  dbaron: It seems like a useful example to put in the spec where
          there is a different thing for each heading and to explain
          that you have to be consistent about painting each time
          you get the callback and that you have to define custom
          property to do it.
  TabAtkins: Can we see randomness in JS?
  several: nope.
  <dbaron> that example helps clarify both that the randomness needs
           to be in a property that's an input to ensure you get the
           callback once for each heading with a different image,
           and that the callback needs to be consistent about what
           results from a particular custom property value since the
           callback might get called multiple times for various
           forms of redrawing.

  esprehn: The API, you shouldn't have to construct backing stores.
  smfr: The implementation may use back store because that's what
        they use.
  shane: It shouldn't be prescriptive.
  esprehn: But it's open for optimization.
  smfr: One other concern I see the spec addresses.

  iank: So the visual overflow is not how CSS works today. Do people
        think that the visual overflow saying statically you have
        20px on each side or should it react to style?
  dino: It has to react to style.
  iank: Yep. The question is how do we do that?
  heycam: A second callback that returns out.
  iank: So in the class base structure you have a computed 'my
        overflow' by default.
  iank: The only problem is that when you're working out when you
        need to paint...it might be fine...When you're walking down
        you need to know ahead of time what your visual overflow
        rectangle is.
  dino: It still should be dependent.
  iank: So we call right after it styles to do the tree walk. We'll
        see if we can implement that.

  smfr: One thing I'd like the spec to say is what the origin of the
        context is when you do the call back. It's expecting it to
        be the top left.
  iank: At the overflow or logical coordinates?
  smfr: Logical.
  iank: And you paint your overflow into negative space. Yep.

  smfr: Something else...let's say you want to use this for
        border-image, I don't think you can give an intrinsic size.
        You get sized to the element plus the overflow. So you
        couldn't optimize your backing store by doing a small paint.
  iank: Yeah. That's something I've thought about. With border-image
        it makes you declare at the time.
  dino: So the set up could pass in what size it wants. I'm going to
        produce and output of 50x50.
  iank: And we can drop border-image for the first version.
  smfr: I think that's one of the most useful cases.
  iank: I'll drop that as an issue.

  dino: Are we sure 2D is enough?
  iank: For version 1.
  dino: One thing is people want to do really fancy painting.
  ojan: We have examples of that, definitely.
  iank: For version 1 I want to keep this simple and punt 3D to
        version 2.
  ojan: I shared your feeling for why not and someone convinced me
        there is a lot of complexity.
  iank: How do you put custom into WebGL with 3D and how does
        invalidation work?
  dino: I don't think it's version 1.
  iank: We can always pull it in when we get stable.

  TabAtkins: Is there a practical limit on number of 3D per page?
  dino: Very much so. Depending on what you're trying to accomplish
        you'd want one shared context that draws a lot of things.
        That's what canvas workers are trying to get to. If you can
        draw once and using it in multiple places, that's better.
  esprehn: Sounds like there's an action to bring images into the
           spec.
  smfr: That's one side. If you were able to declare an intrinsic
        size you can treat it as a sprite sheet.
  TabAtkins: Yes, we do need intrinsic size.
  dino: I think this is what we said before. If you can spec what
        your output size and custom paint will be.
  TabAtkins: There's the three dimensions, width, height, aspect
             ratio, and we need to deal with those.
  TabAtkins: I suspect the paint class itself is fine.
  smfr: You need the size before you call the paint callback.

  ojan: Is the thing you put in like 100px or a function of the
        paint callback?
  dino: There's cases for both.
  TabAtkins: There are. We could set up a default, but maybe we
             could have a way to set it. Maybe that's version 2.
             Having a static size you set might be version 1.
  astearns: With background-repeat you might want to get what the
            size of a whole background will be and then modify the
            tile you're going to paint to be able to multiple to
            fill without clipping.
  TabAtkins: Background-size has that. So we'll pass that in as the
             canvas size.
  dino: Background-size has this? I think astearns is saying he
        wants 1, 2, 3...
  astearns: I might want it to decide the size.
  TabAtkins: background-repeat: round.
  dino: You won't be pixel perfect when stretching.
  TabAtkins: Do you want to rescale or do you want to know your new
             geometry. I don't know which we want to default.
  TabAtkins: If you set 20x20 and someone sets 100x100, do you want
             us to lie and say 20x20?
  dino: Yeah.
  TabAtkins: I think that's an issue.
  TabAtkins: When CSS scales you do you get told that or told your
             original size.

  SimonSapin: Is there a reason to paint other than device pixels?
  TabAtkins: Simplicity. If you expect a 20x20, you might not write
             code for a 700x700 canvase.
  astearns: I'm a little concerned with making a new image or paint
            type that has to be added.
  TabAtkins: It should be image.
  iank: Cursor.
  TabAtkins: If that's a problem. Cursor can disallow custom
             painting.
  Florian: What's wrong with it?
  rbyers: Yeah, why not?
  TabAtkins: I don't know what the issue is.
  TabAtkins: If it's hard I believe you, I want to know why.
  rbyers: We'd only call it once.
  iank: Unless you invalidate.
  TabAtkins: Cursor allows you to ignore the animated images, so we
             can say you only call once.
  gregwhitworth: But if you only call once and you can provide a
                 png, why do it?
  esprehn: This doesn't sound version 1.
  TabAtkins: Yeah. I'd like to discuss privately because I don't
             understand.
  esprehn: I mean, maybe punt it forever.
  iank: I'll take it as an issue.
  iank: So this should be part of image and we'll discuss what
        happens with cursor later.

  franremy: Can you actually ask the engine to cache whatever
            painting you've made? If you have a looping animation
            you want to draw everything one time and re-use.
  iank: We were discussing that a couple days ago. This is the read,
        modify, write use case. I don't think it should be level 1,
        but one easy way to provide this is if you say you want to
        you get an additional argument that's your last bitmap
  shane: franremy is looking for multiple images.
  smfr: Sprite sheet.
  franremy: Where do you store it?
  TabAtkins: Can we load a cached image, can we load a drawing?
  esprehn: I think that would be necessary because a lot of canvas
           features are such that you can draw a canvas to a new
           canvas. So such a feature needs to exist and you can do
           new paint canvas and store it.
  iank: It sounds like, then, create a way to create new rendering
        contexts.
  iank: Take that as an issue for a future spec.

  smfr: I don't think spec says it, but the initial state of this
        context should be said.
  iank: That's an issue in github.

  iank: Just going to read through and see if there are other big
        use cases.
  iank: Issue 8 I'd like feedback. If for some reason your paint
        function throws an error in the middle, what happens? Do you
        output blank or what you've processed?
  heycam: I think painting what you got up to is more flexible.
  smfr: You can debug.
  heycam: If you're immediately applying those paints, it lets you
          have the flexibility.
  TabAtkins: CSS images has an invalid image that is transparent
             with no dimensions. We can link to that.
  Rossen: Which is the equivalent of not painting.
  TabAtkins: Yes, but hooking spec-ese into it is good.
  heycam: I suppose that this is in a separate thread so it won't
          immediately paint.
  iank: Yeah.

  iank: Anyone opposed to partial commands?
  TabAtkins: I'm somewhat opposed. I'd prefer a whole image or none
             so we can invoke fallback correctly.
  shane: As a dev it's nice to see how far you've gotten.
  TabAtkins: Whatever exception was thrown in the canvas, we can
             surface that on the main thread.
  esprehn: I'd prefer we don't paint partial commands.
  shane: Not in the page, but if dev tools are open?
  TabAtkins: I don't want to show partial because if anyone
             implements image() it lets you paint a color if the
             image is still invalid.
  iank: Sounds like we do blank image.

  smfr: Related, in these limited scripts the author can't do
        console.log so some way to get an error out is fairly
        important.
  liam: Especially if the context is more restrictive.
  esprehn: console.log is available to workers.
  iank: I had consoles and could debug.
  ojan: You need console logging and post something back to the main
        thread.
  iank: This goes into the isolated workers spec.
  ojan: I get we have a solution, but it's a version 1 use case.
  iank: There was a big thread about supporting partial invalidation
        on canvases. I'm personally not in favor for it as version
        1, but I'd like other feedback.
  smfr: It doesn't seem necessary for version 1.
  iank: Anyone opposed?
  gregwhitworth: I think MaRakow had opinions.
  Rossen: I'm the one who raised it, but as a version 1 solution we
          discussed it and full invalidation is fine.

  iank: In Sydney we talked about configuring a clipping a context
        so we can pass filters and I think we punt that from this
        level.
  iank: So you can't say the global alpha for all your background.
        Getting to that isn't this level.

  iank: And then there's issue 3 about what should we be writing in
        the spec where we've got things that are being nasty. I
        think if it's valid code and a complicated paint we should
        wait and paint it. But I'd like other opinions.
  iank: We could also keep this issue for later.
  iank: No opinions, awesome.
  dino: I think we should wait to see.

  iank: I think that's it for me. Anyone else?
  smfr: Does this describe when paint callbacks get called?
  iank: Basically this is section 2. Something becomes invalid when
        the geometry or the computed style changes. When displayed
        on the screen the UA has to request.

  liam: Two editorial comments. One is you have an issue 18 or 19
        about fallback.
  liam: It would be nice to fill in the example showing how to
        fallback to a static image.
  liam: I don't know, but it may be worth a note on the a11y.
  iank: Yeah. It's not a11y. I think this might help a11y because
        people aren't creating unnecessary DOM structures.

  smfr: Can you use custom fonts and set font style?
  iank: I think you should be able to draw text, but I don't have a
        good answer for how the fonts are resolved yet.
  dino: I guess the font-size resolves? In the paint callback it
        needs to know...it has to be dependent on the font-size
        property?
  smfr: What if you set font-style to 2em?
  TabAtkins: Oh, this runs by necessity at least at used value time,
             maybe after.
  smfr: Are you resolving against the element? That breaks the
        sharing.
  dino: If in the canvas you say you want to draw text at 5em, what
        do you resolve the em against?
  esprehn: The default canvas is resolved against the default font.
  iank: Sounds good.

  dino: For the long running paints, do we need this to be different
        than long running JS?
  iank: I think we want the same behavior, yes.
  iank: I think this will help in that sense because you'll be able
        to attribute the long code to a specific paint function.

  Rossen: Let's move on. So shane proposed FPWD for this.
  smfr: This depends on custom prop, right?
  shane: Not in a sense that...without having custom properties you
         can install these now. It's banded with them, yes.
  TabAtkins: You can install a null. With Typed OM you can install
             non-null. With custom properties you can animate those.
             We have nice gradated steps.
  Rossen: Anyone opposed to publish FPWD?
  dbaron: This includes the feedback from today?
  Rossen: Yes.

  RESOLVED: FPWD for Custom Paint (which will include the feedback
            from today and more examples)

  <break=10min>
Received on Friday, 16 October 2015 23:45:37 UTC

This archive was generated by hypermail 2.3.1 : Friday, 16 October 2015 23:45:38 UTC