W3C home > Mailing lists > Public > www-style@w3.org > April 2019

[CSSWG] Minutes San Francisco F2F 2019-02-26 Part I: ResizeObserver, CSS properties should apply to some SVG properties as well [resize-observer]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 4 Apr 2019 19:06:58 -0400
Message-ID: <CADhPm3uZCRTsGTK+C+c6g2iEvUe7wciR6oeDvoTc8Wmoq3=+bA@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.
=========================================


ResizeObserver
--------------

  - Issue #3554 (device-pixel-border-box) is a request to create a new
      box with a better name and how the resulting API shape would
      change, if any. The group worked through the use case and
      possible implications but didn't reach a resolution so
      discussion will continue on github.
  - One proposal was to add a new box to watch that represents the
      size of the box in device pixels, returns device pixels, and
      fires on any change in the size in device pixels; it would only
      be available on <canvas> and maybe a few other elements.

CSS properties should apply to some SVG properties as well
----------------------------------------------------------

  - In general there was support on having the applies to more
      rigorously defined, though there wasn't a specific proposal
      available.
      - The definitions will reference SVG 2 mostly and only 1.1 when
          logical.
  - AmeliaBR will file a separate issue to stop using "applies to" in
      the definition of getComputedStyle.

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

Agenda: https://wiki.csswg.org/planning/sf-2019

Present:
  Rachel Andrew, Fronteers
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  Amelia Bellamy-Royds, Invited Expert
  Tantek Çelik, Mozilla
  Emilio Cobos, Mozilla
  Dave Cramer, Hachette Livre
  Elika Etemad, Invited Expert
  Jihye Hong, LGE
  Koji Ishii, Google
  Brian Kardell, JS Foundation (phone)
  Ian Kilpatrick, Google
  Rune Lillesveen, Google
  Chris Lilley, W3C (phone)
  Cameron McCormack, Mozilla
  Theresa O'Connor, Apeoplee
  François Remy, IDLAB
  Manuel Rego, Igalia
  Florian Rivoal, Invited Expert
  Hiroshi Sakakibara, BPS(Beyond Perspective Solutions)
  Jen Simmons, Mozilla
  Hyojin Song, LG Electronics
  Alan Stearns, Adobe
  Morten Stenshorne, Google
  Greg Whitworth, Microsoft
  Fuqiao Xue, W3C

Scribe: gregwhitworth

ResizeObserver
==============

device-pixel-border-box
-----------------------
  Github: https://github.com/w3c/csswg-drafts/issues/3554

  atotic: I've been working on the spec
  atotic: The graphics team came to me - the problem they have is a
          way to determine the device pixel size of canvas
  atotic: Why do they need to do this - the reason why they need to do
          this - is there is no way to do this
  atotic: The way the devs do high-dpi in canvas it has CSS Pixels and
          what they do is they create the bitmap size they create the
          canvas in physical pixels it gets shrunk to CSS pixels so
          they can draw really fine hairlines
  atotic: device pixels are never rounded - there is no doubles or
          floating point, etc
  atotic: Since the canvas's actual device pixel size is affected by
          pixel snapping, there is no way for webdevs to determine
          its exact device pixel size
  atotic: Pixel snapping depends on not only pixels but also position
  atotic: I asked to add it to canvas, and they said sure but they
          also need to be notified when it'ss resized
  atotic: Currently the proposal will be that you will get device
          pixel inline and border size if its a canvas

  fantasai: Are you proposing to add it somewhere else
  atotic: No
  fantasai: So the only way to get this is to add the resizeObserver
  atotic: Yes

  dholbert: Does devicePixelRatio?
  atotic: They get a bad pattern from hacking this because it can't do
          pixel snapping correctly
  dbaron: Under what conditions does Chrome change the device pixel
          backing size when it's repositioned?
  dbaron: atotic is saying that, if you make a subpixel change in the
          top coordinate of a canvas, if it's 100.25 px tall
  dbaron: and it's top is positioned at a pixel aligned position it
          would round to 100, if it's further down it will be 101
  dbaron: Do you actually change the backing store
  dbaron: the number of image pixels in the canvas ?
  dbaron: I guess that's the height and width
  dbaron: They want to change those the attrs based on the device
          pixel sizes
  atotic: The developer determines the size of the backing store, what
          Chrome does it will copy that bitmap to the CSS size of the
          canvas, if the ratio is a nice even number then we don't get
          moire patterns - if we don't
  atotic: there is a CSS size which can be fractional - but there is
          also the real bitmap to paint the canvas and that bitmap is
          in physical pixels
  <bkardell> how is that different from a url background image?
  <bkardell> " if the ratio is a nice even number then we don't get
             moire patterns - if we don't"
  <bkardell> that bit
  dbaron: bkardell is asking why don't you get moire pattern in
          background images
  atotic: It will scale, but background image is fundamentally
          different
  atotic: We probably do get them but you usually aren't doing hidpi
          background image or you can't tell
  atotic: Where they primarily have this issue is in the 3d context
          and they'll have patterns that look different

  bkardell: The act of painting a thing on a canvas - the bitmap comes
            from an image and we rescale the image - it shouldn't
            matter who creates this image?
  atotic: You will see artifacts - but they'll create 3 different
          images
  <dbaron> So I understand the use case -- but I'm a little suspicious
           of making it <canvas>-only, though.

  iank: Within painting, we know where the pixel snapping is so we can
        account for it
  atotic: Also we're talking about every frame in video games, it
          happens a lot more

  dbaron: I understand the usecase I just don't know if I like that
          it's <canvas> only
  atotic: I agree, but there is a performance penalty to calculate
          them and most people don't care about this except in a
          canvas context
  atotic: If we find that it's useful in other areas it's easy to
          extend it
  <dbaron> I'd have expected it to be implemented a different way, but
           okay...

  AmeliaBR: If this is a <canvas> thing - why are we doing this here.
            Especially since this is a really hacky way to do it
  atotic: From what I understand from the history, there was a high-dpi
          way in which to do this but the other standard didn't go
          anywhere
  hober: We also saw that people still create the larger one
  atotic: I agree ResizeObserver is an odd place but the dimensions
          change if you move around you still need to be notified
  liam: Checking the device pixel size, it seems easy to check every
        frame
  liam: Why would you not check it?
  atotic: If you're a game developer maybe
  fremy: If you want to draw a perfect line in your table you'll need
         to resnap it
  atotic: Exactly, you need it on RO or you add it to both specs

  florian: Another thing - here we know what CSS & device pixel things
           are, but it's very easy to get confused
  florian: I don't know exactly what we want to add so let's not add
           it to too many places because it will get misused
  atotic: It would only happen on canvas - you would see
          inlineDevicePixel and blockDevicePixel

  [gregwhitworth, recaps the resolution from yesterday]

  heycam: Before you were seeing a perf penalty - why not add a new
          box-watching keyword?
  heycam: You can still have the device pixel border box of another
          element
  florian: But that was my point - if you make it broadly available
           they'll abuse it
  florian: They'll think they want device pixels but they'll probably
           be incorrect
  liam: To be clear, the only usecase this solves compared to
        ResizeObserver plus having a method on canvas

  emilio: This canvas snapping happens during painting or layout? If
          it happens at painting you wouldn't want to wait for
          painting to be done
  smfr: The only way to really know this you is to do it at painting
        you have to take transforms into account
  Rossen: If you have a scale it's broken
  gregwhitworth: I'm against adding this based on what smfr and emilio
                 said
  atotic: It will be blurry anyways so it doesn't matter
  gregwhitworth: In your use case, you may be right, but if we add
                 this, there may be people who want to use it in the
                 more general case that includes transforms
  gregwhitworth: So taking all web devs into account, this looks like
                 a partial solution, not good enough
  iank: I'll need to ask Chris, but we may compute the transforms
  atotic: resizeObserver doesn't watch transforms
  smfr: Then this is the wrong API to bolt this onto
  atotic: Ok, the high-dpi with an ancestor that has a transform or
          something
  atotic: that should still work because it will then get transformed
  florian: Then it's broken because the second you scale it's broken
  florian: People will assume they can and it will fail
  * bkardell is wondering - if you put an image element in the page,
             does device pixel ratio snapping thing apply too?

  atotic: I thought one of the issues on the webplatform you don't
          want to expose zoom because it will break
  heycam: Pinch zooming and transforms on ancestors is different
  atotic: We were talking about the pinch zoom of the page and they
          would end up with arbitrarily long page
  florian: Pinch zoom, leaving it out - but transform?
  atotic: If we were going to do transforms, there will be a subset of
          these that should work
  atotic: We want this to be a size API not a quad API
  gregwhitworth: I feel this is a chrome only perspective, safari and
                 Firefox don't seem up to it. Should we go back to the
                 github issue?
  atotic: ResizeObserver itself does not work with transforms

  fremy: If you're going to draw a canvas you're not trying to do a
         transform on top of that
  fremy: transform is for animations
  fremy: Why would you intend to do this if you're focused on pixel
         perfect drawing
  liam: I agree it doesn't make sense, it does make sense to center a
        canvas
  florian: Offset path will also impact this as it can change the
           position

  atotic: We're going to notify you when the border box changes
  atotic: There's nothing that says we're not going to change on the
          transforms
  dholbert: How integral is the movement of the subpixel
  atotic: When you're moving it's blurry anyways, it's a video game
  dholbert: I'm feeling like a static API is more desirable than an
            ResizeObserver API
  dholbert: The canvas API makes sense to have this
  atotic: But people want to get an observation
  <bkardell> it is possible to make a subclass phase 2 of this that
             was specifically for observing that?
  <bkardell> .. or something

  AmeliaBR: Is it reasonable to trigger ResizeObserver on something
            may have changed even if the sizes haven't changed - they
            then can do a canvas pixel
  atotic: I thought of that - but you end up getting a bunch of ROs
          without knowing why
  AmeliaBR: We have a way of adding device-pixel-border-box back?
  atotic: Where most observers they look at the border box or content
          box, what is this box and creates a larger turbulence
  AmeliaBR: Maybe I don't care about those and you're adding a perf hit
  heycam: You can rename the type of the box, canvas-bitmap-box if
          you're worried about
  atotic: It kind of locks us into watching the canvas only

  fantasai: I think agree with atotic about not naming specific to
            canvas - so we shouldn't lock that down
  fantasai: because there might be other elements in the future where
            we want to use it, and we should be able to just re-use
            the same thing for those cases

  smfr: We simply snap device scale factor - if you're inside the
        scale transform we don't snap all the time, so we do need to
        go outside of layout a bit.
  atotic: It has a perf hit
  smfr: If you drag to another screen would it fire
  atotic: Yes
  smfr: It's not real device pixels, because you're not taking
        transforms into account
  chrishtr: It's the dims of the texture of the backing store
  smfr: What you just said is very impl specific
  chrishtr: It's the CSS pixel size snapped and multiplied by the
            devicePixelRatio without taking into account transforms
  chrishtr: It has to take into account zoom
  smfr: Ours doesn't
  chrishtr: The spec says to
  dholbert: Doesn't it fire after layout?
  atotic: Yes
  dholbert: So after layout
  dholbert: It would need to be extended to take into account after
            the fact
  liam: I don't think this a great fit
  iank: It's where all other resizes are triggered, it's actually bad
        to try to keep it in sync with ResizeObserver

  fantasai: One thing to note if we have a ResizeObserver, if it's 100
            CSS pixels and I move it to the hidpi screen it's still
            100 CSS pixels. And it's a canvas specific issue
  fantasai: It would be nice to not get the extra events unless I
            actually care about the device pixel border box
  atotic: Yes
  atotic: you could register to observer device-pixel-content-box
  fantasai: Yes, I think it should be the content box, not the border
            box, since that's what you're painting into

  myles: So in conjunction with what fantasai was saying then you need
         to know the pos and size.
  fantasai: No, only if those pixels change
  gregwhitworth: That's already in the algorithm
  fantasai: You can resize as result of repositioning, but maybe not
  <dbaron> (sounds like people were leaning towards registering for a
           separate box name rather than giving these notifications
           magically in some case)

  fremy: I think it's going to be tricky in a sense, for the usecase
         your using - have you considered the paint() API?
  iank: We don't have webgl and a bunch of other APIs
  fremy: oh ok

  <fantasai> Proposal: Register for changes to devicePixelContentBox,
             get back sizes in device pixels, throws an error if
             registered on anything other than a canvas element, fires
             whenever device pixel size changes whether due to change
             in screen resolution, element position, or element
             resizing. Does not fire if device pixel size does not
             change.
  <dbaron> still doesn't deal with the issues about rectilinear
           transforms, offset-path, etc.

  chrishtr: I just wanted to follow up on explicitly defining the API,
            in the CSS paint worklet callback you can see the device
            pixel backing size. It helps devs to distinguish between
            the two and can discover it. I think it would be useful to
            distinguish
  atotic: I think we have agreement to watch a separate box?
  smfr: I just want to say that I don't think canvas is the only one,
        I think other situations may care about the same thing
  smfr: I think people will want it in other elements

  smfr: I was proposing this is the snapped content box multiplied by
        device pixel ratio
  dbaron: But you all agree to ignore transforms?
  chrishtr: Because it should be a paint based situation for perf
  dbaron: I don't think that's actually true
  chrishtr: Unless overflow it's almost post paint
  krit: Even SVG?
  <AmeliaBR> I like the connection with Paint API. Even comes with a
             nice name, "paint size":
https://drafts.css-houdini.org/css-paint-api/#paintsize
  Rossen: My proposed closing of the issue - let's bring the proposal
          back to github and then bring it back and we can resolve then
  atotic: thank you

CSS properties should apply to some SVG properties as well
==========================================================
  github: https://github.com/w3c/csswg-drafts/issues/3414

  AmeliaBR: I don't have a whole lot to update
  AmeliaBR: in comparison to the telecon
  AmeliaBR: The issue came up because we want an easier way for
            defining what applies to SVG instead of having to update
            every time a new CSS prop is added
  AmeliaBR: Having to update the spec to say, "hey this also works" -
            some specs do this but it's not at all consistent
  AmeliaBR: The applies to in the definition is loosely defined
  AmeliaBR: When you look at CSSOM for getComputedStyle it has
            normative impacts on whether you return the computed or
            used style
  AmeliaBR: I think this issue got added to the F2F that I would come
            with a pretty proposal but that hasn't happened

  AmeliaBR: In general I'd like to suggest that the applies to more
            rigorously defined which categories are used?
  AmeliaBR: As far as how it works on SVG side is, it shows all
            elements but is it ALL elements considering SVG?
  AmeliaBR: instead of using the term elements we can use rendering
            tree terminology, etc
  AmeliaBR: Also others mix elements and rendering tree words it's
            very inconsistent
  AmeliaBR: The SVG element the same element in different layout
            contexts may or may not have a CSS box

  AmeliaBR: Another thing for SVG - text content elements: many text
            related props will apply to SVG Text but not all
  AmeliaBR: because the actual text layout is different
  AmeliaBR: It would be valuable to not have to re-analyze if it
            impacts SVG text, etc

  fantasai: What are we trying to conclude
  AmeliaBR: At this point it's just an update and they've been
            surprised that it has normative impact on getComputedStyle
  AmeliaBR: Should we somehow extract that, and make it informative
            and then define getComputedStyle in some other way
  AmeliaBR: if it's a normative impact then we need to be strict terms
            that are clearly defined

  heycam: I guess I am one of those people that applies to has
          normative impact, I always thought it was an informative
          information and prose would define it
  heycam: maybe I missed an earlier discussion
  AmeliaBR: The summary, getComputedStyle for many props it doesn't
            return the computed style that gets inherited such as % or
            auto only pixel value
  AmeliaBR: That's where the applies to the normative impact
  heycam: Does CSSOM point to applies to?
  TabAtkins: Yes
  TabAtkins: but none of us knew this - so maybe we fix that
             definition. None of our applies to are not written as
             though they're normative
  <TabAtkins> https://drafts.csswg.org/cssom/#resolved-value-special-case-property-like-height
  <TabAtkins> and the next instance of the phrase "applies to" as well

  dbaron: I think the spec for getComputedStyle is not yet where impl
          should change to match the spec
  dbaron: Maybe someone took a shortcut to point to applies to - but
          it's probably not an accurate definition
  AmeliaBR: I'm not asking impl to match the CSSOM spec it's about
            spec consistency
  AmeliaBR: but it's using a terminology that isn't explicitly defined
            elsewhere

  florian: Also applies to it's not just a yes/no category - there has
           to be prose
  florian: I'd be in favor in keeping applies to somewhat wishywashy
  florian: but also helping clarity for SVG is useful

  krit: Besides that Applies to we need to look at the prose, many
        text layout keep SVG in mind as well
  krit: If there is anything that the SVG specs can do to help that
        would be good to know as well
  krit: That would help interoperability between SVG/CSS very good as
        well
  AmeliaBR: That's very good feedback as well

  AmeliaBR: I don't think we have them defined in one place, so we can
            improve that on our end
  AmeliaBR: So then it's kind of - the current specs it'll be a
            massive review and giant PR to make sure we do have clear
            defs for what applies to SVG and how
  florian: This will probably be more than a blue box change but a
           prose change
  AmeliaBR: Then moving forward, try to think about how it works on
            SVG, feel free to reach out. We've discussed content,
            contain, etc. but the questions need to be asked

  florian: It's a process question, these categories can be aware of -
           are they different between SVG1.1 & 2?
  AmeliaBR: Some of them have changed and some have been simplified
  AmeliaBR: I think there are a couple new categories
  <chris> There are changes in SVG2, mostly simplifications.
  florian: It would be unfortunate if no spec can get to rec until SVG
           2 does
  florian: I don't want to gate everything on SVG getting to rec
  AmeliaBR: Most will be in SVG 1.1 already but the SVG editors need
            to make sure those defs are in one place
  AmeliaBR: That covers the main topic of this issue

  chris: The issue that florian raised is a quite large CSS one
  chris: Whenever a spec goes to rec but it has these refs to EDs etc
  chris: We have a highly intertwined set of specs and it's really
         hard - and SVG doesn't really change this but adds
  florian: The problem is we have the bedrock of CSS2.1, at times it's
           more convenient to link to newer things because it has more
           things and it kind of makes it possible, but SVG is outside
           of that bedrock
  chris: There have been a few cases in SVG2 that are linking to
         SVG1.1, etc
  chris: As for CSS, I think it shouldn't be too large of a problem -
         there is a last resort
  florian: If it's a generic ref SVG then that's fine, but if we're
           starting to add 3 paragraphs prose about SVG that don't
           exist then you need to implement it and get that to rec and
           have a hard dependency.
  chris: We have some concepts for graphic elements and SVG1.1 has
         this stuff

  krit: Just one comment
  krit: SVG2 categories are supposed to make things easier
  krit: but if you would like to link to 1.1 that's fine for normative
        reference as long as it's defined what happens to the content
        in SVG we don't care if it's 1.1 or 2
  AmeliaBR: If there isn't something in there, then you can add some
            examples that says you don't have to implement and give
            branches
  florian: That spec that references it can't go to rec either because
           they're dependent on it
  krit: In those weird cases, sure link to 1.1 SVG
  krit: Most of the issues are text related
  Rossen: ok, that sounds good

  AmeliaBR: We should open an issue into defining getComputedStyle
            further
  ACTION AmeliaBR Open an issue to define getComputedStyle
  <trackbot> Created ACTION-876
Received on Thursday, 4 April 2019 23:07:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:13 UTC