- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 24 May 2021 18:46:44 -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 Fonts
---------
- RESOLVED: font-stretch should serialize to a number/percentage,
not a keyword (Issue #6171: Computed value of font
stretch)
- RESOLVED: Add new metrics that can be used to harmonize the font
size of fonts used in fallback (Issue #6160: Extent
font-size-adjust to take a pair of values: <metric>
<number>)
- RESOLVED: Add font-face descriptor overrides for vertical writing
modes (Issue #6152: Vertical metrics overrides)
- RESOLVED: Clarify that font-size-adjust computations will effect
things in such a way that the descriptor overrides have
no effect (Issue #6128: How do font-size-adjust property
and size-adjust descriptor work together?)
Flexbox & Sizing
----------------
- RESOLVED: non-replaced elements with an aspect ratio honor the
intrinsic size in flexbox for min-height:auto (Issue
#6069: Interaction of flexbox minimum height and
aspect-ratio minimum height)
Sizing
------
- Being able to address issue #1771 (Auto-resize iframes based on
content) would require input and work from the WHATWG as well.
The proposed solution would be a double opt in approach which
would support security but get author expected behavior. There
was interest in pursuing a solution, though not everyone was
convinced it is a good idea. More use cases outside of the ad
space may be needed.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/16
Present:
Rachel Andrew
David Baron
Christian Biesinger
Mike Bremford
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Sanket Joshi
Brian Kardell
Jonathan Kew
Ian Kilpatrick
Peter Linss
Rune Lillesveen
Alison Maher
Myles Maxfield
François Remy
Morgan Reschenberg
Florian Rivoal
Cassondra Roberts
Jen Simmons
Alan Stearns
Miriam Suzanne
Lea Verou
Greg Whitworth
Scribe: fremy
CSS Fonts
=========
Serialized value of font stretch
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6171
emilio: The spec has a note that says that, for compat reasons,
computation of font-stretch should stay a keyword if it was
one, instead of the percentage
emilio: webkit doesn't do that
emilio: tests either require one or the other, there is no consensus
emilio: I would like to remove this note
myles: There is no known issue I was working around
dbaron: Usually, we try to stick to the most compatible
representation, for compat
emilio: Returning the keyword makes it difficult for authors because
they need to reverse-compute the keywords
emilio: Font-3 used to report the keyword all the times
myles: At least in webkit, we implemented font-stretch at the same
time as the numerical values
myles: so the span of time where we didn't support numbers for it
was short
myles: possibly not even a release
dbaron: Given that, I think it's fine to break the general principle
astearns: Ok, so the proposed resolution is to not use the
font-stretch keywords in serialization
emilio: And return a percentage
astearns: Ok, any objection to this?
RESOLVED: font-stretch should serialize to a number/percentage, not
a keyword
Extend font-size-adjust to take a pair of values: <metric> <number>
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6160
jfkthame: This was prompted by the discussion about size-adjust
descriptor
jfkthame: We want to harmonize when we have mixtures of fonts
jfkthame: font-size-adjust allows you to use the x-height of the
font to size things
jfkthame: This is very latin-centric however
jfkthame: for example you might want to harmonize the ascent/descent
of the font instead
jfkthame: because x-height might be meaningless to my language
jfkthame: This sounds like a natural extension to me, but I wanted
feedback
fantasai: This makes sense to me
fantasai: I support the proposal
florian: Same
florian: I would like to note that the ascent+descent combination is
problematic
florian: because it depends on the baseline
florian: It's easier to stick to things that are distances from the
baseline
florian: otherwise you need to add a feature to realign
jfkthame: I don't propose to adjust the alignment
jfkthame: just the font size
fantasai: Yes, e.g. you would need to use ideographic alignment in
some cases
florian: Ok, that sounds convincing, you can use vertical-align to
deal with any alignment problem
myles: Did we consider IC-height?
<florian> [IC = Ideographic Character]
fantasai: We probably want to have logical variants of these as well
myles: Philosophically this proposal makes sense
myles: but to change the spec, I will need a list of tokens to
consider for the first argument
myles: I might have some opinions on the set
myles: descent doesn't seem useful for example
astearns: How often do people use font-size-adjust?
fantasai: It's not cross-browser so it might be lower than we think
jfkthame: I found a lot more uses that I expected actually
jfkthame: but however it often has no effect since it only applies if
font don't load
astearns: Are we sure we don't complexify too much?
fantasai: I think it's fair to support non-European languages better
fantasai: Some writing systems don't even have opentype metrics yet,
but at least this would add support for languages for which
we have metrics
fantasai: and it provides a design which works to add new metrics if
they are created later
astearns: Which browsers support this right now?
myles: Probably just firefox?
jfkthame: And behind a flag in chrome
myles: And webkit would implement when we add the overrides in the
font description block
myles: No objection to add, we can discuss the set later
astearns: Sounds like we have a consensus
astearns: Any objection?
RESOLVED: Add new metrics that can be used to harmonize the font
size of fonts used in fallback
florian: btw we need to find a way to work with the opentype people
florian: so we can provide feedback
florian: I don't have a plan to propose, but there is a community
group created recently
florian: I don't know for sure how to engage with the fonts people,
but it would be nice to figure it out
astearns: Indeed, the set of metrics can be a good think to ask to
the opentype people
astearns: Let's make sure that we don't ping them about bad fonts
though
astearns: There are lots of fonts that are reporting wrong metrics
astearns: and it's not the fault of the committee
<florian> https://github.com/w3c/font-text-cg/
Vertical metrics overrides
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/6152
fantasai: These overrides are applicable in vertical text
if you rotate the characters
fantasai: But, for example, ascent and descent are given differently
depending on the axis
fantasai: We probably need to add independent values for overriding
metrics in vertical typesetting modes
fantasai: because using the horizontal values in vertical writing
mode doesn't make any sense
myles: In upright vertical text, the ascent would be horizontal?
fantasai: Yes, horizontal
(some pondering)
astearns: Do we need to support both or a switch?
fantasai: I think both might be required to be specified at the same
time
myles: This proposal would require a different implementation
myles: This is fine, but this something worth noting
fantasai: But the font has y values, you just need to override them
myles: Possibly? But the problems that this solves are less
important that the horizontal writing mode
fantasai: I would agree that this is less severe in most cases
fantasai: because in vertical writing mode the baseline is often the
middle, and it is fine
myles: And the CJK scripts don't have diacritics so they usually fit
in the 1em box
fantasai: Some cases might still exist
astearns: Are there arguments to not complexify?
astearns: If we add this, I would like to view examples
astearns: because I don't have an idea in mind of what this would do
astearns: Any objection to add this to the spec at this time?
jfkthame: line-gap override could be useful too
jfkthame: No reason this should be left out
astearns: ok, any objection?
RESOLVED: Add font-face descriptor overrides for vertical writing
modes
How do font-size-adjust property and size-adjust descriptor work
together?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6128
jfkthame: The question came up about the interaction between these
two properties
jfkthame: The proposed solution in the issue
jfkthame: is that font-size-adjust takes precedence in a given
element
jfkthame: that does erase the changes in the descriptor
jfkthame: I think this makes sense
myles: One way of looking at it is that they both occur, but
font-size-adjust changes things to the same solution
regardless
myles: When writing the spec text, I would go with this
jfkthame: I think that is true
<dbaron> (Myles's description makes sense to me.)
jfkthame: basically the calculations of font-size-adjust cancel out
any previous adjustment
astearns: Sounds like we have a general agreement
astearns: Any objection to this clarification?
<fantasai> +1 to jfkthame's proposal
RESOLVED: Clarify that font-size-adjust computations will effect
things in such a way that the descriptor overrides have no
effect
Flexbox & Sizing
================
Interaction of flexbox minimum height and aspect-ratio minimum height
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6069
cbiesinger: The aspect ratio spec says that with min-height: auto,
you compute height using the aspect ratio, and you expand
to the content height
cbiesinger: but in a column flexbox, the height is the minimum of
the transferred height and the content height
cbiesinger: It's not clear to me which one should win
cbiesinger: fantasai clarified the aspect ratio version should win
cbiesinger: but does the working group agree to this?
fantasai: This is different for replaced and non-replaced elements
fantasai: because the intrinsic size of replaced elements is not as
strict
fantasai: so we need to keep that behavior for them
fantasai: but for non-replaced elements, the intrinsic size is more
meaningful
florian: I'm not sure about what the alternative is?
cbiesinger: width:100px + aspect ratio 1:1 but intrinsic-height:200px
florian: Ah ok, got it
cbiesinger: Because it used to be the minimum
jensimmons: The default of flexbox is that it's shrink then grow
jensimmons: but the proposal is that for replaced elements, we make
aspect ratio "work"
fantasai: Yes, that is the heart of the issue
<fantasai> [Jen's explanation was that if there's a bunch of
elements you want to be squares, they will be squares
unless they contain too much content, in which they grow
to accommodate that content. That's the behavior we
specced for block boxes with aspect-ratio; and the issue
is making sure it works the same for flexbox.]
astearns: Last week there was more contention
iank: That was me last week
iank: I am now fine with this
astearns: Is the spec edit correct for what we discussed
fantasai: I think it is correct
fantasai: but we need to update the spec
fantasai: Proposal is non-replaced elements with an aspect ratio
honor the intrinsic size in flexbox
<cbiesinger> for min-height:auto
jensimmons: I am seeing a lot of tutorials about aspect-ratio on
replaced elements
jensimmons: in particular using object-fit etc
fantasai: that should continue to work
fantasai: That is why we don't do this for replaced elements
fantasai: non-replaced elements have an intrinsic size that depends
on content, that might not be easy to resize
jensimmons: The previous text for images would still apply then?
fantasai: Yes
astearns: Any objection to keep fantasai's edit in the ED?
RESOLVED: non-replaced elements with an aspect ratio honor the
intrinsic size in flexbox for min-height:auto
<br length=15min />
CSS Sizing
==========
scribe: fantasai
scribe's scribe: TabAtkins
Auto-resize iframes based on content
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1771
TabAtkins: Fairly old issue, #1171
TabAtkins: Originated in HTML in the form of 'seamless' attribute on
iframes
TabAtkins: meant to allow isolating parts of a page, but still lay
them out as if in the page
TabAtkins: There were a bunch of issues, dropped from HTML
TabAtkins: core ideas still requested by people, in various variants
TabAtkins: We believe there's a useful and safe set of resizing
behavior that we could expose now
TabAtkins: that would solve some of the use cases
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-805117925
TabAtkins: Core idea is that just the resizing portion of seamless
is valuable
TabAtkins: But there are security issues around being able to tell
the size of 3rd-party content
TabAtkins: Bare minimum, different sizes of content depending on
whether the user is logged in or not
TabAtkins: So should only be allowed to take size of 3rd-party
content if it wants to allow that
TabAtkins: Another problem, if 3rd-party page can trigger resizing
without consent of containing page, can create problems
as well
TabAtkins: So proposal is a 2-way agreement on sizing
TabAtkins: First, outer page needs to opt into resizing based on
iframe content
TabAtkins: Suggestion is to use new 'resize' value in 'allow'
attribute
TabAtkins: Then for 3rd-party content, there's a window.resizeTo()
method which is a no-op in iframes
TabAtkins: Inner page can request such sizes
TabAtkins: using this API
TabAtkins: Whenever inner page wants a resize, triggers an event on
iframe which bubbles up
TabAtkins: if not preventDefault, then the iframe changes it's size
TabAtkins: if cancelled, doesn't change size
TabAtkins: This allows control over layout behavior across the page
astearns: Possible scripts using resizeTo() and relying on the fact
that it does nothing?
TabAtkins: It's a no-op currently, so don't think so
TabAtkins: ... [ missed ]
astearns: Making page decide to allow event or not, already in place
due to opt-in to resize behavior
cbiesinger: Nothing sounds like CSS thing
TabAtkins: Kinda sorta
TabAtkins: It's a cross-spec thing, does interact with CSS by
adjusting intrinsic size of iframe
TabAtkins: Gets into issue of same-origin content
fantasai: You wanted a 2-way handshake for security
fantasai: saying resizeTo() gives you 2-way for page consenting
fantasai: What if that page is already firing resizeTo() and
expecting it not to have security implications?
fantasai: I don't think paying attention to resizeTo() would break
the framed page...
fantasai: But if they're asking for it and it's currently not
changing size, the outer page probably isn't expecting a
problem.
fantasai: [clarifying] the issue isn't an attack due to sizing, it's
a possibly unexpected info leak from the frame'd page,
leaking the size it wants to size to
florian: Currently, calling resizeTo() doesn't leak information
TabAtkins: Could check if stuff in iframes do this currently...
fremy: It's not about stuff currently in iframes, but a page could
put *anything* into an iframe
fremy: which would leak information from that page, which was not
intended to be in an iframe
florian: resizeTo() doesn't have an effect on pages that are loaded
into a window with multiple tabs
florian: for exactly this reason: it would leak information about
that page to other pages in the same window
florian: Opening up this leak through iframes is similarly bad
(worse maybe)
TabAtkins: Yeah, OK, we need to think about that more. Maybe needs a
new API
<iank> another path would be an additional dictionary argument to
resizeTo, e.g. window.resizeTo(100, 100, {something: true});
<fantasai> +1 iank
florian: In the case where resize does work, thing it affects is the
natural size, right?
TabAtkins: Yes. Right now iframes have natural size of 300x150, and
this would change that
TabAtkins: Totally controllable, it's the weakest size input possible
fremy: Do iframes have an aspect-ratio applied to that intrinsic
size?
TabAtkins: currently iframes do not have an aspect ratio
TabAtkins: Ability to infer an aspect ratio is an interesting
possibility
florian: As long as we're there, should we specify min size and max
size separately
TabAtkins: Interesting. Not unreasonable to consider.
jensimmons: Curious about use cases
jensimmons: All I can think of is what ad networks will do, and I
don't like those thoughts.
TabAtkins: There's another proposal for 1st-party content, which
addresses more use cases
TabAtkins: but even within 3rd-party stuff, currently they do this
resizing already, just with postMessage back and forth
TabAtkins: This would standardize that
TabAtkins: There's also things like Disqus, which does such
special-case postMessage things
TabAtkins: which is complicated and no standardized way to handle
across multiple systems
TabAtkins: YouTube player, e.g., might want to do this. CodePen
might want to ask for sizes on its examples. Anything
that wants to embed, has a reasonable use case for
wanting to request a particular size and have it
potentially honored by containing page
jensimmons: If goal is to reduce jankiness of ad network...
TabAtkins: That is one goal, but not all of it!
<leaverou> need to drop off briefly for another call, but I'm very
supportive of this, and I hope we can find a way to
implement it in a privacy and security preserving way.
emilio: How do you react to resize in parent page when using the API?
emilio: User shrinks the page, need to somehow coordinate between
both. No auto size, only fixed intrinsic size
TabAtkins: I don't think there's a reasonable direct analog to block
auto-sizing ..
emilio: I guess at that point... You don't really need JS on the
parent page to get auto height
emilio: If you require JS on the parent page then it's not great
emilio: So inner page can send resizeTo() whenever it gets Resize
event
emilio: and then containing page doesn't need to do anything ...
emilio: [missed]
TabAtkins: Possible this makes it easy enough that it's a concern
emilio: resize event ... your own resize event
TabAtkins: I suspect that's something that would show up fairly
quickly
emilio: It only consumes CPU, not while:true. I send a message, it
resizes me, sends a message back. Code keeps working, just
uses a ton of CPU
emilio: It's a bug in the page, but.
TabAtkins: no-op loops can't happen because if the iframe's
resizeTo() doesn't change its size, won't get an event
because size didn't change.
TabAtkins: Either it'll grow or shrink infinitely, or will jiggle,
which should be noticeable
emilio: Concerned about e.g. floating point issues, and rounding
errors
emilio: I've seen that kind of stuff happen
<iank> we also already have the "jiggle" problem today with frame by
frame resize-observers.
<fantasai> if not causing change in size, then shouldn't cause a
problem
fremy: Can't put a breakpoint in the main page to figure it out
because no JS
fremy: Already have these kinds of bugs today
smfr: The HTML5 event loop spec is very specific about when resize
steps happen
smfr: When we spec this, we need to spec it in terms of that event
loop spec
smfr: Nobody mentioned resizeobserver yet
smfr: It's designed to avoid infinite recursion
smfr: We might need something here with nested iframes, so don't get
into crazy infinite resizing
TabAtkins: Yes, want to handle events in descending order like
resizeobserver does
TabAtkins: Need some thought to ensure not creating bad cross-tree
resizing behavior
TabAtkins: Not too concerned about page vs iframe vibration, but
much worse if grandparent grandchild interactions cause
problem, because then nobody knows what's going on
fremy: Main question here was, I guess point of allow attribute is
to allow resize
fremy: External page wants to allow iframe to resize
fremy: Not sure I understand point of resize function
fremy: why not some CSS value that allows resizing by containing page
fremy: Reason I think about that is that resize takes 2 arguments,
width and height.
fremy: Not that interesting to change intrinsic width of iframe
fremy: Why not say that "I'm fine with my scrollHeight to be
reported to the containing page"
<gregwhitworth> +1 to fremy
iank: scrollHeight isn't always what you want
fremy: Could be something smarter, max-content maybe
TabAtkins: Second part of proposal also, about same-origin content
and no-JS solution
smfr: Other point, iframe calls resizeTo() and has to provide a
size. What size should it provide? Does it do
getBoundingClientRect() on the body or what?
smfr: Is there some convenient way to get the height of the content?
TabAtkins: For 1st-party content, making it easy. But for 3rd-party
content wanted to be more explicit
TabAtkins: But maybe we can reduce that restriction
TabAtkins: 2nd part of proposal is about same-origin content
TabAtkins: Right now, minimum solution still requires some JS on the
framed page (not containing page)
TabAtkins: but for same-origin content, there's a certain degree of
implicit trust we can rely on
TabAtkins: and might not require auditing
TabAtkins: For this, I propose that on a 1st-party iframe, or
something that's srcdoc
emilio: srcdoc is not ?
emilio: data URIs are
TabAtkins: sorry, I'm thinking about sandbox
TabAtkins: In my original proposal, I had a new property that could
be set on the root element to set the requested intrinsic
size for each axis (auto | <length>)
TabAtkins: Page could opt into ? via 'from-element' keyword,
providing fallback length
TabAtkins: fantasai later suggested the page could just set an
explicit width/height on the HTML element
TabAtkins: Possibly we don't need to mint a new property, can just
take from the root element
TabAtkins: If that's problematic from existing, maybe mint something
new
TabAtkins: but either way, that'll allow getting the size without JS
TabAtkins: Just set allow=resize, and inner page does whatever it
needs to do
TabAtkins: and those sizes automatically communicate back and forth
TabAtkins: Acts like an element, no JS required
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-805117925
fremy: That only works in 1D, right? You can't do both dimensions
fremy: Then you wouldn't get the resize
fremy: If you get width + height, wouldn't know you need more space
TabAtkins: If you set both to auto, you'll need to rely on outer
page to set your width...
fremy: ah, ok, make sense
iank: I don't think that width/height on HTML will work, because
people do set an explicit width on HTML and use e.g. auto
margins to center
iank: HTML is not the root, bit of disconnect
iank: Likely for auto behavior, might want something like scrollWidth
/scrollHeight as was discussed
iank: There's a little bit of danger here
<fremy> +1 to scrollWidth/scrollHeight (adjusted if necessary)
iank: You might get content that, if you have a fixed-position
content that rises to ICB, and has height 120%, could create
an infinitely-growing iframe that way?
iank: I'm not too concerned about that
TabAtkins: Yeah, need to think about loop detection...
fremy: We can set a threshold, if you fire too many resize events in
a certain amount of time don't allow it or whatever
iank: That might block some valid use cases. E.g. comment expansion
might want to animate growing
<gregwhitworth> resizeObserver has the same error handling
gregwhitworth: Effectively what you just outlined is something we
wanted at Salesforce. All over the web people are
using Salesforce but not aware of it.
gregwhitworth: Would like to see network headers
gregwhitworth: enable this auto behavior for cross-origin
gregwhitworth: if a grid with min/max content, how can I lay out my
content and pass back my height
gregwhitworth: I can work it out in JS, but want it automatic
TabAtkins: Reason restricted right now is trying to be cautious
gregwhitworth: We could write blog posts about how to do it, but
would rather not
TabAtkins: I would want to have more security eyes on it
gregwhitworth: ...
emilio: There is some kind of precedent for this, loading a doc and
sizing it intrinsically, which is SVG
emilio: Even if the SVG is not an actual image, if you have an
object tag with SVG source, that's actually a document
that's ...
emilio: in FF and Chrome at least, that size is intrinsic to SVG's
viewbox
emilio: it would be good to figure out if there's something that we
need to learn from that or not
emilio: that's probably legacy behavior
emilio: While we were doing site isolation
emilio: I just wanted to mention that precedent
emilio: I think those can run script, even if SVG
TabAtkins: A few people in thread mentioned OBJECT
TabAtkins: If currently allows that behavior and think it's OK, then
maybe can allow it
TabAtkins: I haven't thought about it yet
fantasai: On the topic of 3rd party sizing info without JS, I think
it makes sense to allow
fantasai: If both the container and the inner page have explicitly
allowed for it
fantasai: That indicates trust between the two
fantasai: For doing it declaratively, Ian's point about width/height
on root not being what we want makes sense
fantasai: Tab mentioned setting a property giving the behavior
explicitly
fantasai: I don't think that's a CSS property, it's more of a
security handshake
<gregwhitworth> +1 fantasai
fantasai: So maybe an attribute on <html> that opts the iframe'd
page into the behavior
fantasai: And would let you specify which size you want (scroll
height, border-box height, etc)
fantasai: I think the size shouldn't be specified in HTML, should be
in CSS; but allowing this should be an HTML attribute
dholbert: Should any page on the internet be able to get that info?
dholbert: maybe same-origin addresses it
dholbert: Don't want to allow inadvertent stealing of info from the
page
TabAtkins: Right, which was why I initially wanted to disallow it
TabAtkins: and fantasai was talking about explicit opt-in
TabAtkins: I think there's some kind of iframing options setting?
iank: There's ??? HTTP Header which restricts which origins you can
be embedded in. Most banks etc. use that.
TabAtkins: Requiring that, reasonable thing to start with
iank: Would need to set Access-control: allow-origin or whatever
astearns: Sounds like you got some good feedback, something to work
on
TabAtkins: Plan is that parts of this that relevant to CSS would go
to contain spec
TabAtkins: and sizing spec
TabAtkins: to talk about natural size being controllable this way
TabAtkins: If we do have a new property... probably in sizing? maybe
contain?
TabAtkins: Rest will be pursued in HTMLWG
astearns: Should CSS part depend on the HTML part being accepted?
TabAtkins: Sure
myles: This entire discussion about how / technical considerations.
Not about whether to do it all.
myles: Want to make sure that it's not a foregone conclusion that we
should do this.
TabAtkins: Decent part of this was sussing out whether there's
interest in doing this
TabAtkins: Seems people are interested
TabAtkins: I suspect discussion in HTMLWG will be more contentious
TabAtkins: OK to object over there :)
astearns: But feel free to object over here also, if you think it's
a terrible idea!
TabAtkins: We don't have any major internal partners clamoring for
this, it's an old issue that's a frequent author
requested, and we found a way to address an important
part of it
<br duration=12min>
Received on Monday, 24 May 2021 22:47:26 UTC