- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 3 Aug 2020 19:42:43 -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.
=========================================
CSS Sizing
----------
- RESOLVED: 'height: stretch' behaves as 100% applied to margin-box
where 'align-self: stretch' isn't possible (Issue #1614:
`height: stretch` should just behave as `height: auto`)
- There was interest/support in doing further exploration into and
creating a proposal for importing the aspect-ratio from a child
(Issue #5269: Import aspect-ratio from child image). Some items
raised on the call for the proposal to consider is behavior
around whitespace and importing from first child instead of
importing only if there's one child.
CSS Images
----------
- RESOLVED: Do not expose orientation data for cross-origin images
by treating EXIF orientation as integral (can't ignore)
(Issue #5165: image-orientation:none violates
same-origin policy)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#monday
Scribe: fantasai
Sizing
======
`height: stretch` should just behave as `height: auto`
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1614#issuecomment-661391733
TabAtkins: A little while ago we added 'stretch' keyword to width/
height
TabAtkins: width: stretch does what blocks normally do in block
layout
TabAtkins: even in cases that currently do fit-content for 'auto'
TabAtkins: The question was what happens if specify for height
TabAtkins: Initially tried to do something from an earlier attempt
from dbaron
TabAtkins: would increase height of item as much as needed to fill
height of closest definite ancestor
TabAtkins: This ended up being weird, potentially blows up further
than you want
TabAtkins: Took a resolution to make it behave like 'align-self:
stretch' wherever that has a meaning
TabAtkins: and in other cases, behaves like auto
TabAtkins: but when editing in realized we could do most of what was
wanted
TabAtkins: by treating similar to percentage height when percentages
can resolved
TabAtkins: So basically act like slightly smarter 100% (considers
margins also)
TabAtkins: wherever that's currently defined to resolve
TabAtkins: and otherwise fall back to auto
TabAtkins: no extra magic
TabAtkins: Filling container when percentage could resolve
TabAtkins: gives better abilities
TabAtkins: this proposed behavior, acting like 100% minus margins,
border, padding
TabAtkins: Gives an expected and useful behavior for 'stretch'
without causing the inflating behavior concerned with
earlier
cbiesinger: This makes a lot of sense.
AmeliaBR: If you did want the behavior of dealing with a couple
parents levels of padding and borders, just describing
each level as 'height: stretch', would that work?
TabAtkins: Just as percentage resolved against definite size is
treated as definite, stretch resolved against such would
also be definite
TabAtkins: would then follow up the tree
cbiesinger: This is basically renamed fill-available keyword, right?
TabAtkins: Yes
astearns: Questions or comments?
dbaron: I guess the one thing, the thing I originally proposed
dbaron: for orthogonal flow stuff
dbaron: somewhat different use case
dbaron: it's a little weird
TabAtkins: At least, I don't think we want that behavior by default,
so don't think hooking it into 'stretch'
TabAtkins: if we want that, maybe different keyword
astearns: So proposed resolution is that height: stretch, when can't
behave as align-self: stretch, will behave as 100% but
accounting for margins
<AmeliaBR> +1 for the proposal. Let's make this as useful as
possible.
Rossen: Would it contribute to any other height sizing algorithms
that aren't fixed?
TabAtkins: What do you mean?
Rossen: If this is just a block wrapped in a block...
Rossen: grid item has behavior already defined
Rossen: but block inside grid item is now simply defined by the
closest fixed container
Rossen: so if grid item is not fixed, then you have to propagate up
Rossen: and stretch the size minus margins borders padding to
whatever is in the further ancestry of that thing
TabAtkins: That is explicitly what we are not doing
TabAtkins: This just looks nearest container, same as percentages
TabAtkins: it is exactly identical as 100%, but sizes margin box
instead of content box
Rossen: ok, then that makes a lot of sense
<cbiesinger> nearest container -> containing block, I think?
<fantasai> not exactly, e.g. <p><span><inline-block/></span></p>
AmeliaBR: We have a few cases in CSS where percentages aren't doing
useful things
AmeliaBR: e.g. cyclic percentage contributes zero, resolves, lots of
overflow, is bad
Scribe: dael
fantasai: I think most of those cases where you have problems are
those where percent isn't 100. If you put 50% you get
weird overflow. If you put 100% these resolve ok.
TabAtkins: Child of a float fills at 100%. There will be weird
because margins/border/padding
AmeliaBR: I had it in mind with weird percentages
astearns: Other comments?
astearns: Proposal: height-stretch behaves as even better 100%
astearns: I have a concern
astearns: Is it possible for modes that doesn't match to align-self
we're in a corner?
TabAtkins: This is meant to be same as align-self in those cases. If
we didn't have that in grid and defined this it should be
same. We anticipate extensibility.
fantasai: Where align-self doesn't apply are cases where it doesn't
make sense. You have a stack of things that are placed
relative to each other. 'stretch' is not defined as whether
align-self is implemented in that mode, but if it's defined
to apply there per spec.
astearns: Okay
astearns: Objections to height: stretch behaves as better 100% where
align-self: stretch isn't possible
RESOLVED: 'height: stretch' behaves as 100% applied to margin-box
where 'align-self: stretch' isn't possible
<break type=30min>
Import aspect-ratio from child image
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5269
TabAtkins: Two big use cases people run into that make aspect-ratio
not work how they want
TabAtkins: In block layout if you have image with aspect-ratio and
wrapper doesn't effect, but in flexbox or grid there is
special code that is defeated by wrapper; Including link
or picture element which are common
TabAtkins: Request is for a parent element to get aspect-ratio from
child but only if it has a single child with
aspect-ratio. In all other cases acts like aspect-ratio
none
TabAtkins: I don't think needs to grab other intrinsic sizes, but we
can think about that. Flexbox only cases about ratio.
TabAtkins: Some unanswered questions. What do you want to do with
margins/borders/padding which change render size
TabAtkins: We can probably resolve in further issues
TabAtkins: General case to pull aspect-ratio from single child do
people think this is reasonable?
fantasai: Not sure we want to take from an only child. A lot of
cases where we pull something like this where you grab
first child. Whatever we do for grab info from child
should be consistent. Not sure it should be check for only
one child
TabAtkins: I don't think SVG is useful for examples because it
doesn't have layout. Further children don't affect. In
this case if you have an element with image and fit
caption if you take from image it's meaningless
fantasai: You can have positioned caption on top of picture which
makes sense
TabAtkins: One inflow child then
AmeliaBR: That's my point, one inflow child for case of figure with
caption on top of image.
AmeliaBR: I'm not sure what fantasai was thinking on SVG but I can't
think of a case where it gets aspect-ratio from children.
SVG in a CSS layout having these behaviors is useful
fantasai: Not specifically aspect-ratio. I think some property in
SVG grabs info from children
AmeliaBR: title and description?
AmeliaBR: Either way, need to think about would it be web compat to
make this default change? We have lots of flex and grid
layouts where if this was available authors would have
loved but they have made adjustments and doing by default
is problem
AmeliaBR: Could make keyword for aspect-ratio property. On you
picture element have an aspect-ratio from content that
would have this special behavior
AmeliaBR: If it's web compat to make it default where if you have
one inflow child with an aspect-ratio container is
aspect-ratio it would be great to be automatic.
TabAtkins: I strongly suspect its not web compat. I'd like to run on
that assumption that this is specific property; an
aspect-ratio keyword that does it
fantasai: Or some new syntax
fantasai: New keyword or something else
emilio: I was going to say behavior will be weird with applied
whitespace. Children create boxes which can be collapsed or
suppressed but that's optimization. Bit weird that
whitespace around image this trick doesn't work
TabAtkins: How weird if we did ignore collapsed whitespace
emilio: Somewhat. I don't have strong opinions. Direction with
single box is odd.
fantasai: I would have said first child element
Rossen: In doc order?
emilio: Right
fantasai: Yes
TabAtkins: If you take first child element it excludes text.
Non-whitespace text would be ignored too so should
trigger no aspect-ratio
<AmeliaBR> So… if the container has exactly one in-flow,
non-collapsed-ws child box…, then `aspect-ratio:
from-contents` works
<fantasai> I think we can let the author not specify the keyword if
there's other content they want to ignore
<heycam> in SVG we did at one point discuss allowing properties that
refer to elements by URL to have a "from-child" or
something keyword, e.g. so you could do <path
style="marker-end: from-child"><marker>. but that didn't
really go anywhere beyond an idea. (might be fantasai is
thinking about this)
cbiesinger: I'm also concerned it's a lot of magic. A lot like
emilio's comments
cbiesinger: Have to be careful to not add something that will break
this
cbiesinger: Use cases I've heard from webdev is they wanted
aspect-ratio and they were happy. Didn't ask for this
cbiesinger: Final thing, picture element should probably take
aspect-ratio from img tag
TabAtkins: I don't think just aspect-ratio is usable because of
picture. Different source could provide different
aspect-ratio and you can't easily predict
cbiesinger: Getting aspect-ratio from child makes most sense
TabAtkins: Don't see reason to differentiate between picture and a.
Picture into link is common and easy and I would prefer
it didn't break layout
cbiesinger: Careful about line breaks between a and img
TabAtkins: Unless we do something about collapsible whitespace
fantasai: Collapsible whitespace doesn't generate box right?
emilio: Maybe. In Gecko we don't when we can prove it doesn't have
to. But we need to deal with it.
TabAtkins: Unsure if it's clear if box is generated.
fantasai: If it did it would interrupt margin collapsing.
TabAtkins: Yeah, okay. Great observation. In that we observe this
with margin collapsing should be able to observe without
being particularly weird
Rossen: Looking through issue this is mostly to introduce and feel
room
Rossen: Sounds like some level of anxiety but also use cases which
are supported.
Rossen: What's next step? Work more for concrete proposal?
TabAtkins: I was seeking if objections. Information is useful. We
can put a proposal in spec and bring it to WG
Rossen: Anything else on this?
CSS Images
==========
image-orientation:none violates same-origin policy
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5165
heycam: We have image-orientation. Ignoring print processors it's
used for authors to opt out of what we're moving to with
EXIF orientation honored by defualt. It's really that EXIF
orientation is impl detail on how image is represented in
file
heycam: We have image-orientation: none which lets authors opt-out
heycam: In Gecko and Chrome image-orientation: none applies to same
and cross origin images
heycam: Anne pointed out that applying to cross-origin it's a leak
of one bit of info. For images cross-origin you can look at
width and height. Because you can tell if it's re-oriented
90 deg you can get an extra bit of info to know if image
meta was one set of value or another
heycam: Shouldn't add more leaks in theory. Perhaps arguable if it's
super important if this makes a difference and weigh it
against value for authors
heycam: It's something to discuss
TabAtkins: All this makes sense to me. image-orientation and the
image resolution which you can observe via src set is
info leaks. Way through is make cross-origin images
behave like it's information was baked in so they can't
turn off orientation. It would mean cross-origin would
act as if exif was it's native orientation. Similar logic
would apply to resolution where you could select correctly
but it would act baked in
TabAtkins: Regardless of how you look at image you get same data.
TabAtkins: Sounds good, happy to adopt
TabAtkins: Not sure if it's css or html but happy to figure it out
fantasai: It think it lives in css-images.
AmeliaBR: Support what TabAtkins said. One proposal in issue was do
reverse where cross-origin ignores exif and I don't want
that. Render it as the image format is supposed to be
rendered including exif but don't make it inspectable how
it was generated.
cbiesinger: Two comments. Seems like angle is a possible value with
same problem.
cbiesinger: In response to TabAtkins I think a lot of websites are
images from different host. Seems like not supporting
would make chrome exif a lot less useful.
cbiesinger: Don't have a good solution but it's not ideal
AmeliaBR: This would be normal http cross-origin so if you have full
control over cdn and can give correct headers that's one
way to turn off exif
TabAtkins: This should continue to work as normal for cdn but you
wouldn't be able to turn exif off. It would always be on
heycam: Possible you're using images from cdn and relying on
orientation not being applied. I don't think there's
anything special about images from cdn
TabAtkins: In general our research has shown better for web if we do
respect exif at all times
heycam: I'm in favor of model TabAtkins describes. Had one person
contact me where he would like it to continue to apply to
cross origin because they have tool to present image and get
user to annotate and then they hand over annotation to
another tool. Without being able to tell the tool the
orientation they can't tell if they have to process.
heycam: They can work around that by fetching the image on the
server side
TabAtkins: Or proxy the image request to turn on cors stuff they'll
be fine
Rossen: Where do we go from here?
TabAtkins: Unless there's objections proposal is do not expose
orientation data from cross-origin images. Do it by
having the masquerade as their exif orientation being the
native
TabAtkins: 2 resolutions. One we want, one is implementation strategy
Rossen: Proposal: Do not expose orientation data for cross-origin
images
Rossen: Comments or objections?
RESOLVED: Do not expose orientation data for cross-origin images
by treating EXIF as native resolution
Rossen: Question; for things like cloud functions are they
cross-origin?
Rossen: Cloud functions your source has an image call
TabAtkins: Don't know but definition of cross-origin is stable so
I'll rely on that. It's very precise and I don't want to
manipulate it
cbiesinger: Question is do we have use counter data for how often we
have image orientation that's not from exif?
TabAtkins: Don't think we do yet. We know in general honoring exif
is the better way to go so even if there are cases that
are specifically needing to care it's a smaller subset of
the subset we consider is okay to break
cbiesinger: Okay it's better, curious about how big the number is
<cbiesinger> looks like image-orientation in general is only used on
0.13% of pageloads so this is probably OK
Rossen: Have the resolution on record. Add anything about impl
direction or in the minutes is enough?
TabAtkins: Minutes is enough
heycam: Anne raised a separate issue about who defines this and have
a spec which can be referenced. That's something for later.
Received on Monday, 3 August 2020 23:43:37 UTC