- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 4 Nov 2020 21:38:01 -0500
- 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.
=========================================
Flexbox
-------
- RESOLVED: Close this issue as an editorial change (Issue #5663:
Should definite cross size be used to compute flex
item's transferred size suggestion?)
- RESOLVED: Add an appendix to flexbox spec for the webkit prefix
properties (Issue #5634: Move -webkit- prefixed aliases
into flexbox?)
- RESOLVED: Add these to the appendix as MUST or MAY depending on
implementation [web exposed implementations are a MUST,
otherwise it's a MAY] and SHOULD NOT for authors. Add
details about how they're not simple aliases (Issue
#5634)
CSS Contain
-----------
- RESOLVED: Uncomment possibility of an exception and accept the PR
(PR #5643: Clarify how sizing containment works)
- The group agreed that allowing a browser to search content that is
currently hidden when doing find-in-page and
ScrollToTextFragment was a valuable use case to solve (Issue
#5595: Proposal: content-visibility: hidden-matchable). Before
reaching any resolution, though, there is a desire to explore
further if there are other types of finding hidden content which
should be included such as searching by text fragment ID. There
also needs to be a review of the proposal to ensure that it will
provide a good experience when it interacts with various
accessibility tools.
Resize Observer
---------------
- gregwhitworth will review PR #4150 (Remove SVG specific text) to
see if it needs to be re-written.
Logical Properties
------------------
- RESOLVED: Add an optional line in propdef table for logical
property groups (Issue #2822)
CSS Sizing
----------
- There needs to be some additional exploration of use cases for
issue #5650 (Add fill(<length-percentage>) / rename stretch
keyword for width/height?) prior to a resolution. The group was
leaning toward keeping the keyword name as 'stretch'.
- RESOLVED: Close this issue as fixed (Issue #3731: How should
inline-axis intrinsic sizing work for 'fit-content' and
'fit-content()'?)
Values & Units
--------------
- RESOLVED: Interpolate ratios using logarithm (Issue #5953: How to
interpolate <ratio>?)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Nov/0002.html
Present:
Joseph Arhar
Rossen Atanassov
Tab Atkins-Bittner
Christian Biesinger
Oriol Brufau
Hui Jing Chen
Elika Etemad
Brandon Ferrua
Simon Fraser
Megan Gardner
David Grogan
Chris Harrelson
Dael Jackson
Vladimir Levin
Daniel Libby
Ting-Yu Lin
Peter Linss
Alison Maher
Myles Maxfield
Cameron McCormick
Florian Rivoal
Miriam Suzanne
Greg Whitworth
Regrets:
Daniel Holbert
Scribe: dael
astearns: Anyone have any changes or additions to the agenda?
<fantasai> https://github.com/w3c/csswg-drafts/issues/5630
fantasai: Request. There are some questions from privacy group. It
would be nice to have a party from each impl answer the
questions in the original post
fantasai: I need webkit and blink answers
chrishtr: I can answer
astearns: Thanks
chrishtr: Thanks for bringing attention
astearns: One additional item. As we mentioned on past calls we have
/tr publications that are out of date. I've discussed
privately with people. I'm going to have to start to call
people out publicly.
astearns: CSS Scoping has updates in ED and it's 6 years out of
date. TabAtkins do you have a plan?
TabAtkins: Soon. I don't have a timeline. It's been on my list. It
will get up there when I can
astearns: Hopefully it can be elevated above some others on the list
Flexbox
=======
Should definite cross size be used to compute flex item's transferred
size suggestion?
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5663
TabAtkins: There's a question about terms we're using in 2 parts of
spec. In 9.8 where we define extra ways for lengths to
get definite we talk about outer cross size. In earlier
sections for min size one of the conditions was stated as
relying on cross size being definite. Unclear if one
being definite was meant to apply to other term.
TabAtkins: Edited spec for more consistent. Didn't have right terms
back then and said "property" but what we want is
preferred size. dgrogan confirmed it looked good. Unless
other thoughts I think we can close with this fix
astearns: Original commenter just replied saying good
fantasai: I say we close as editorial
astearns: Proposal is close this issue and an editorial change
astearns: Objection?
RESOLVED: Close this issue as an editorial change
astearns: Thanks for the updates
CSS Contain
===========
Clarify how sizing containment works
------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/5643
florian: A while back Mats pointed out the text of size containment
wasn't clear. Phrasing was handwavy. Long discussion in
github of how it could be interpreted and which is right.
florian: Made a PR which clarifies. Reviewed by fantasai and I think
TabAtkins. Reasonably confident it's good
florian: There was a longer discussion that maybe original intent
wasn't right because possibility size containment was
toward container queries and maybe wanted to ignore things
like grid-track-sizing instead of treat grid as empty. That
would make it nicer for when element queries are a thing.
florian: Separate GH about if container queries is possible here
florian: Could have css contain open a door for possible exceptions
in other specs. Size as if empty but we apply all
properties unless stated otherwise in other specs.
florian: Specs like grid are further back in rec track so we don't
consider it in css contain or we close the door now
florian: Except for that I'm confident text is good. Didn't get
review from Mats unfortunately. Hard to read as a diff
because a lot of red but there's a link to read
florian: Would like approval to merge unless comments.
fantasai: Should this go into contain 1 as well?
florian: Yes. Editorial compared to intent of spec. Editorial
compared to text is debatable. But yes to get into L1
chrishtr: Does the PR make it any different from browser behavior?
florian: Nothing interop changes. Corner cases about size
containment to grid container with sized tracks which are
different between FF and Chrome which would change
chrishtr: Are they enumerated?
florian: I know them and can write them down. I plan to write tests
to expose details
astearns: Not currently any tests?
florian: Tests that fail in FF and remain valid. Test are for
original intent which was not clearly expressed
florian: Now it's more precise we can write more tests
astearns: Usually when we have an issue and decide on a fix we close
and put needs test cases. Since this is a PR I'm worried
someone looking for test cases wouldn't find it to write.
I wonder if it would make sense to create an issue for
testing where it enumerates the new cases
florian: I intend to write tests in a day or two of resolution, but
I'm okay to have more
astearns: If that's the case then no need
astearns: Any other comments?
heycam: I can ping Mats but don't want to block
astearns: Proposal: Accept the edits and create tests
florian: With open possibilities for other specs to exempt from the
rules or close the door?
heycam: Always possible for specs to override?
florian: It's nicer to call it out, but even if we don't you can
still do the override
astearns: Since it's not clear we'll go ahead maybe leave it in as a
we don't know yet
astearns: Other opinions?
astearns: PR has the exceptions can be made?
florian: Commented out. I need to un-comment
astearns: Proposal: Uncomment possibility of an exception and accept
the PR
astearns: Objections?
RESOLVED: Uncomment possibility of an exception and accept the PR
florian: Thank you
Resize Observer
===============
Remove SVG specific text
------------------------
github: https://github.com/w3c/csswg-drafts/pull/4150
astearns: I think this was on to see if we should re-work or close.
astearns: gregwhitworth have you had a chance to look?
gregwhitworth: Have not, I'll review it tonight
astearns: afaict it's a change we need to make but a question of if
we can land the PR
gregwhitworth: I'll review. Because it's over a year I don't know
florian: I put it on the agenda because plinss pointed out it's in
the main repo which causes slowdowns. So we should land or
delete it
gregwhitworth: Sounds like a plan. I'll get it tackled
Flexbox
=======
Move -webkit- prefixed aliases into flexbox?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5634
TabAtkins: Currently the whatwg compat spec defines the aliases from
old webkit prefixes for flexbox because required for
compat. gsnedders asking to move out of compat and into
flexbox
TabAtkins: In general we're okay with putting compat in a spec
TabAtkins: I'm fine
TabAtkins: I would like to put in appendix as fantasai pointed out
TabAtkins: Two things, should we move? If yes, what level of wording
astearns: Add an appendix to flexbox spec for the prefix properties
RESOLVED: Add an appendix to flexbox spec for the webkit prefix
properties
TabAtkins: Not consistent with 2019 usage for legacy. We lean toward
MUST. Images has SVG with MUST but writing mode was using
MAY. We should make the usage consistent but figuring out
how is a separate issue
TabAtkins: For now I'd like a MUST since that seems the more
consistently used. Later can have issue to make all
consistent
florian: Makes sense and so does having MUST as default since we
wouldn't spec it if it wasn't necessary
fantasai: Yeah, but if you're css renderer who isn't doing web
content you won't care
heycam: I think it makes sense MUST. -webkit-appearance type there
could be impl with problems but I don't think this is a case
fantasai: There is a renderer who isn't compat with web but does
flexbox. I don't want to make them non-conformant
iank: When you move this into flexbox make sure you don't list as
aliases, they're more complex then that. Compat spec was lying
a bit there.
TabAtkins: You're saying compat spec is incorrect?
iank: My quick reading of it I believe so. My understanding of how
we impl is if you've got display-webkit-box you don't look at
webkit ordinal and then order, you only look at ordinal. You
look at one set of properties as a whole. It's a higher level
switch. Compat spec says they're alias which is incorrect
heycam: I don't remember off the top of my head but Daniel did the
implementation
TabAtkins: We'll resolve it when we do edits
iank: Yeah, just an FYI. I can give more detail and hacks when
you're writing
heycam: WPT doesn't have tests on -webkit-flex things so tests would
be good.
fantasai: If they're not simple I'm rather against a MUST for non-web
TabAtkins: I'd propose putting as a MUST for web exposed impl and
MAY or SHOULD for others
fantasai: Sure. Go with MAY
astearns: Proposal: Add these to the appendix as MUST or MAY
depending on impl and SHOULD NOT for authors. Add details
about how they're not simple aliases
florian: If you support is may or must depending on context but if
you do you have to do it how iank described?
fantasai: Yeah
astearns: Concerns? Objections?
RESOLVED: Add these to the appendix as MUST or MAY depending on
implementation and SHOULD NOT for authors. Add details
about how they're not simple aliases
astearns: If we uncover any differences between how blink and gecko
support these it would be good to tease it out
TabAtkins: Yep
heycam: Might be good to file an issue to capture the discussions
astearns: I'm happy to have first attempt go into spec and if there
are concerns we should open an issue
heycam: Okay
Logical Properties
==================
Spec should introduce propdef table notation for logical properties
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2822
fantasai: Need to ID properties that belong to logical property group
fantasai: One way is shorthand in prose but suggested we add a new
link to propdef tables for properties part of logical
property mapping group with same ID
fantasai: If we do this I think it should be optional in propdef so
we don't have a bunch of empty fields
<iank> An example of only looking at the "set" of properties:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22display%3A%20-webkit-box%3B%22%3E%0A%20%20%3Cdiv%20style%3D%22-webkit-box-ordinal-group%3A%202%3B%22%3EA%3C%2Fdiv%3E%0A%20%20%3Cdiv%20style%3D%22order%3A%203%3B%22%3EB%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
astearns: Do you agree with oriol about in associated physical
properties?
fantasai: Of course. They're part of the logical property group
astearns: How many specs, how many properties?
fantasai: Backgrounds & borders, positioning, scroll-snap, and box
are the only one affected, I think
fantasai: border, margin, padding, scroll snap margin and padding,
inset properties
fantasai: Most specs not affected which is why I think when making
propdef don't include unless needed
<oriol> overflow too
astearns: Opinions?
astearns: oriol mentioned overflow
fantasai: Yeah
astearns: Proposal: Optional line in propdef table for logical
property groups
fantasai: Yeah. May fiddle with name.
heycam: I also see groups for min size and max size?
fantasai: Yeah, sizing also affected
astearns: Objections to adding a line?
RESOLVED: Add an optional line in propdef table for logical property
groups
<fantasai> I'm thinking maybe it should be called "Mapping Group"
and we should call logical property group "logical
property mapping group" or something...
CSS Sizing
==========
Add fill(<length-percentage>) / rename stretch keyword for
width/height?
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5650
fantasai: As I was going through some of sizing occurred we might
want to have the ability to represent the size as I want
you to fill this length or %. What this would do which is
different is account for margins
fantasai: We have a keyword currently called stretch which should be
same name as function. Gives the fill of the block
element. Introduce a function which does same but fill
arbitrary elements. Call it fill or stretch depending on
how we name the keyword. Should match.
TabAtkins: Sounds reasonable to me
astearns: Sounds reasonable, but that's a low bar. I think I'd like
to see use cases
fantasai: Sure. Max-height fill 100vh on images. Long scrolling doc
with images want to make sure they're not bigger then the
viewport. What if you want to account for margins? You can
subtract for a length but with this you can subtract the
margins.
fantasai: We can discuss later but I think we need to decide if we
want to keep stretch or fill as keyword for the overall
behavior
chrishtr: Could you add the examples to the issue?
astearns: The 100vh one is.
astearns: I'm partial to stretch term. Fill isn't quite the meaning
in my mind. I don't know if anyone else has opinion
oriol: I prefer to keep stretch because matches the keyword in
justify/align-self which is same behavior w/o max width and
height properties aren't taken into account. Easier for
authors if keep same name.
astearns: A little concerned about weird edge cases where stretching
or accommodating margins makes things more complicated.
Just a general worry this isn't as simple as stated.
astearns: Other opinions?
astearns: Shall we go back to the issue for now?
astearns: Since fantasai mentioned you're happy not to resolve today
fantasai: Yeah, I mentioned that
astearns: Let's keep this open and talk through more use cases and
edge cases.
astearns: If anyone interested in drawing out impl of this that
would also be useful
How should inline-axis intrinsic sizing work for 'fit-content' and
'fit-content()'?
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3731
fantasai: I believe the issue is solved. I'm looking for
confirmation we're okay. Seemed there was some confusion
but I answered the question. oriol looked and thought it
was fine I think. I'd like to close the issue at some
point. I don't believe further edits are necessary
astearns: dbaron isn't on. We could close and if there is anything
additional he can re-open with a comment
astearns: Any objection to close this as fixed?
astearns: And keep commenter response pending tag on it
RESOLVED: Close this issue as fixed
Values & Units
==============
How to interpolate <ratio>?
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/4953
TabAtkins: Currently the value and units spec defines that ratios
are interpolated by dividing and interpolate the number.
Bad. It's simple but has bad properties. Grossly
asymmetrical between tall and wide. Tall has 1-0 range
and wide is 1-infinity
TabAtkins: If going from 1-1 to 10-1 if it goes tall it spends most
of it's time being close to square. Takes a long time to
go 1 -> .1 But if you're going wide you're spending most
of the time close to 10
TabAtkins: A much better way to preserve the symmetry is to take the
log of the division results and interpolate that and use
the exponent to get back to the ratio. Gives you
identical behavior. Makes sure if you're going 2-1 that
halfway is square
TabAtkins: Suggestion from dbaron has other asymmetries. If you want
details it's in the issue and oriol has examples of where
the asymmetry comes in
<fantasai> oriol made demos at
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8634
TabAtkins: Would like to transition ratios using log of result. I
think this is fine for future uses. Produces pleasing
visual transition. Symmetry should be good for all cases
TabAtkins: Propose to resolve to use the log. Other thoughts we can
go back to the issue
astearns: Additional comments?
<florian> sounds good to me
astearns: Proposal: Interpolate ratios using logarithm
RESOLVED: Interpolate ratios using logarithm
CSS Contain
===========
Proposal: content-visibility: hidden-matchable
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5595
jarhar: I proposed this property which allows UA to search for text
inside hidden content which find in page and scroll to text
jarhar: Looking for resolution on 3 points. 1) is the general idea
good? 2) is using content-visibility a good idea? 3) does it
make sense for script to be responsible to reveal or the
browsers?
jarhar: Starting with 1 does it sound like a good idea?
TabAtkins: Yes, I like the feature. We should pursue something
astearns: Anyone with opposite opinion?
smfr: Do we think authors can make rational decisions about to use
hidden-matchable vs hidden? Is there a case where they would
not want find in page behavior?
chrishtr: Yes, one example is when you want to hide content which
does not make sense for user. Your site has tabbed content
and it's a previous view. Not in your current route so
doesn't make sense to search
smfr: Makes sense
smfr: I think it's reasonable feature. Seems special-case-y, I don't
really like it
Rossen: What was the use case?
jarhar: Use case if the user searches for something with find in
page. Page has hidden content like mobile wikipedia where
there's collapsed sections. User wants to find text inside
the collapsed. Page should be able to show the sections in
response to the search
TabAtkins: One use case for content-visibility is let page spam a
bunch of content into the dom and this allows the dom
content to be searchable even if not displayed
astearns: Rossen is that enough of an answer?
Rossen: Thank you
heycam: I don't have a strong opinion. Seems reasonable. I think we
need to have some way to expose hidden content for
searching. I wonder if some better names could be used.
Seems clearly 2 use cases. Some content that's hidden away
and not part of current presentation but there's some
content hidden for virtual scrolling. Wonder if better names
might help authors to use the right one. No specific
suggestions
smfr: On a previous call I mentioned things in browsers that index
content of web pages. Scroll to and find text isn't the only
things that care. Browsers will index for selecting later.
Somewhat concerned about a11y. Content must not be accessible
to things such as tab order. Weird if you can find the content
since there's a result in there if you're using voice over do
you instantiate the content when voice over goes there or are
they hidden?
jarhar: I see the tab order point.
jarhar: I'm not very familiar with voice over or indexing pages for
later use within browser features
TabAtkins: Tab order is intentional. Tabbing the auto-expended
sections open. Good a11y is the thing that expands the
section should be tabbable. Don't know you should be able
to tab in
vmpstr: No use case where the only way to find content is via find
in page. You can expand with tab or click. This is expanding
to find via find in page. No case where only way to find it
is find in page
chrishtr: For a11y doesn't make sense to expose to default order
just like doesn't make sense for tabbing because you're
tabbing through what's seen right now. Would be good to
expose find in page to cause hidden content to be shown
when you search it
fantasai: Based on the use cases I think behavior of keeping out of
tab order makes sense. I think targeting element using
fragment ID should be similar to find in page. Possibly
some other API
chrishtr: You mean fragment navigation?
fantasai: Yeah
jarhar: We were thinking of that earlier but got complicated when we
implemented async flow where we make browser wait to scroll
for two request animation frames so we give the page time to
reveal the element before browser scrolls. Couldn't do the
same thing for element fragment ID scrolling because page
can observe synchronous change so we would need to not
include the async step or break the current behavior
jarhar: Considering the page can see changes to fragment ID seemed
like we could not fire before match on fragment IDs
fantasai: But then page needs to know if it's a dependent. If you
look at use case with collapsible sections you want them
to auto-expend even if someone gave you a link into the
subsection. That shouldn't be worse than a text fragment
ID. The fact that the sub-section has an ID is a good
thing and we shouldn't treat it as less convenient.
Shouldn't make the author do extra work to support that
jarhar: Makes sense.
jarhar: Wondering about separating navigating to and script showing
it. Not sure right now on the best path forward
astearns: We're at time. Answer I'm hearing to the first question is
yes it's a good idea but not just for the things you have
defined. Good to flush out other ways of navigate to other
hidden places
smfr: Would like an explicit request for a11y input
astearns: I'll cut it off there
astearns: Thanks everybody for calling in and we'll talk next week
Received on Thursday, 5 November 2020 02:39:07 UTC