- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 4 Apr 2019 19:06:58 -0400
- 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