- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Nov 2022 19:51:30 -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.
=========================================
Administrative
--------------
- The group will meet next week. November 30 will be a longer meeting.
- plinss gave an update on the server work done to add stability and
what is left to do.
Media Queries
-------------
- There is still discussion necessary on issue #7306 (Move the
definition of "display mode" back to Manifest spec) about if this
should be generalized before a resolution can be reached.
CSS Contain & Sizing
--------------------
- RESOLVED: Take second solution for this case. Update the last
remembered size if element doesn't skip its contents
(Issue #7807: content-visibility: auto kinda broken by
not using last remembered size with contain: size)
CSS Values
----------
- Issue #3320 (Clarify fragment URLs resolve against the current
tree, not document tree) needs more discussion about the
motivation behind the behavior before a resolution can be reached.
- RESOLVED: Add this definition to values-4 and evaluate new
definition against existing test suite (Issue #5210:
Define when border rounding happens, and to which
properties it applies)
CSS Contain
-----------
- There was disagreement on the value changing fragmentation as
proposed in issue #5648 (contain:size shouldn't fragment as
monolithic) as well as how common the use case will be once
container queries are more common. Discussion will continue on
github.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Nov/0007.html
Present:
Adam Argyle
Rossen Atanassov
David Baron
Oriol Brufau
Tantek Çelik
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Paul Grenier
Daniel Holbert
Brad Kemper
Jonathan Kew
Chris Lilley
Peter Linss
Morgan Reschenberg
Florian Rivoal
Alan Stearns
Miriam Suzanne
Lea Verou
Eric Willigers
Regrets:
Tab Atkins
Yehonatan Daniv
Vladimir Levin
Eric Meyer
Khushal Sagar
Bramus Van Damme
Chair: astearns
Scribe: dandclark
Administrative
==============
astearns: We will have a meeting next week. We'll see how many people
we get. We'll figure out an agenda to fit the people there.
Regular call next week, longer call at end of month.
astearns: We're skipping #12 due to lack of people on the call.
Rossen: If you have agenda items to be part of long call, please mark
them. At this point we have ~60 issues. Won't be able to
cover all. So mark issues that are a must to cover.
astearns: So please help figure out what is a must-cover for the long
call.
Rossen: We have 3 agenda f2f topics that are leftovers from the past.
Please go ahead and add Agenda+ F2F
Media Queries
=============
Move the definition of "display mode" back to Manifest spec
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7306
ericwilligers: The motivation is the webapps wg will be writing
definitions for more display modes. Makes sense for
them to vote on modes and their positions.
ericwilligers: uncontroversial in webapps wg
florian: There's editorial and substantive aspects to this.
Substantive aspect is that while most display modes are only
invoke-able by app manifest, there's at least one that I'm
not sure if should be. that's fullscreen.
florian: If you invoke UI to switch viewport to full screen, should
this be recognized as full screen?
florian: When you're in full-screen mode, you're in full-screen mode
regardless of how you got there. If you want full-screen
mode to be strictly about the manifest, can do what was
suggested.
florian: But if you want media queries to be generalized, we can move
the bulk of what's here to the spec but might need to leave
a bit behind in media queries.
<tantek> +1 I think I'm agreeing with florian, which is to keep the
more abstract (non-manifest-specific) definitions in MQ5
Ericwilligers: Manifest might say fullscreen but you're not in that
mode at the moment ??? This would be similar to
standalone. I think uncontroversial that if you start
in browser and go to fullscreen, it should go to
fullscreen. Don't think there's a problem. Distinction
between what manifest says and what the browser's
doing.
florian: Two nuances, we agree on first but not sure on second. If
you have manifest but mode isn't active, what counts is
what's actually active. If you don't have manifest, and you
put browser in full-screen, I think you're saying you agree
full screen mode should apply. We agree. But PR to put it
back to the web manifest spec doesn't agree.
ericwilligers: We can quickly resolve this afterward, test what the
browsers do.
florian: Do we want to generalize this to be more applicable broadly?
<tantek> +1 worth generalizing
florian: If we accept PR as is, applies to web manifest only, but
it's worth generalizing
ericwilligers: I don't see any problems
florian: We need some things in both specs. IF only need this to
apply to webapp manifest, almost everything should move
there. Only need cross-referencing.
florain: To apply more broadly, need some definition in media queries.
astearns: Do we resolve to accept PR now?
astearns: ...and then track remaining work in this issue or another?
Or not accept PR yet?
ericwilligers: Resolve to have remainder here
florian: Not sure, e.g. definition of display-mode itself. If this
notion is broadly applicable, not sure if should move.
rossen: This conversation suggests this isn't ready to merge. Close
but not quite. Take this extra time with florian and come
back when it's ready?
ericwilligers: I guess we can do that
<tantek> +1 Rossen. Iterate on the PR and re-review next week?
astearns: Take the time to hammer it out and we'll take it up again
CSS Contain & Sizing
====================
content-visibility: auto kinda broken by not using last remembered
size with contain: size
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7807
oriol: content visibility: auto, elements either enter screen or get
out of the screen, can loose size containment, which changes
size
oriol: Problem if you have scrollbar
oriol: Changing size of elements can change scrollbar thumb size.
Added ???-auto. Stabilizes content-visibility: auto
oriol: ... is triggering non-stable behavior. Have example in issue. <
describes example in the issue>. Basically as elements gets in
or out of the screen, is switching between 100-115 pixels.
Getting instability when should be stable.
oriol: So 2 possible solutions. 1st is changing requirement for using
last remembered size. Now checking element is skipping
contents. Instead check content visibility but still check
size containment.
oriol: If content-visibility: auto ??? would still be able to use
last remembered size. 2nd possibility is changing requirement
for using last remembered size.
oriol: ???? So if the element is skipping contents, use last remember
size. If not skipping contents, update last remembered size.
oriol: Vlad likes both but leans towards second.
oriol: I don't have strong opinion between the 2.
oriol: Anyone else have 3rd possibility to propose?
florian: I agree 2nd is the better one. But thinking longer may have
different opinion.
astearns: proposed resolution: take second solution for this case.
Update last remembered size if element doesn't skip its
contents.
RESOLVED: Take second solution for this case. Update the last
remembered size if element doesn't skip its contents.
CSS Values
==========
Clarify fragment URLs resolve against the current tree, not
document tree
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3320
fantasai: Short version of problem is there was resolution to change
how fragment urls are handled when fragment url is changed.
fantasai: e.g. using <base href>. But most implementations don't
follow that, so not sure if we want to keep. Need
implementers to review.
fantasai: Different engines doing different things.
emilio: I think what FF and Blink do is consistent with other things.
Like other specs, SVG and stuff that should behave
consistently for base URI case.
emilio: Whatever we do should also check...is the WebKit behavior
consistent here?
<tantek> +1 emilio, what FF + Blink do seems both consistent and
interoperable, can we resolve on that being what we want?
<fantasai> https://www.w3.org/TR/css-values-4/#local-urls
fantasai: Pasted link to what spec currently says.
fantasai: I'm not convinced this is what we want to do, and it's
certainly not what's implemented.
emilio: Resolving against node tree is a bit undefined I think. Also
I'm pretty sure we don't use StyleSheet owner node.
emilio: I suspect blink does the same, so it's tricky
emilio: I guess that's the intention for ShadowDOM.
* fantasai thinks the example is particularly illustrative
tantek: I would flip question around. Are there objections/problems
from web dev perspective to how it's implemented? If there
are no problems, makes sense to resolve and move forward.
Spec is behind, fix the spec accordingly.
fantasai: This is a change from L3 that was requested. Not convinced
this is what we need to do.
tantek: I mean behind reality. This has happened before.
<fantasai> I would say it differs from reality, it's not *behind*
reality.
astearns: So the question is should resolve fragment against node
tree or current tree?
emilio: The tree we're resolving against, is it correct? And are base
URIs taken into account? I think they should be, agree with
fantasai that it's weird they're not.
emilio: There's also trickiness in shadowDOM behavior.
emilio: Not sure we match with spec here.
astearns: I assume motivating bit is what we do with shadowDOM, given
linked issues.
astearns: Don't know enough about this to have good idea of what
direction to take.
fantasai: Might make sense to kick to f2f
tantek: To decide, is the methodology. Define from 1st principles or
based on interoperable implementation behaviors. I'm OK with
either approach but that's high level question to settle
first.
astearns: Closing to take back up in a couple weeks. I will ping
ryosuke to try to get more details.
Administrative
==============
plinss: We got funding to do server work. Old server is quite old,
debian release 3 major releases back. Building new server and
migrating rather than update old.
plinss: New server has the fundamental infra. That's been migrated
over. Migrated SQL DB which was what kept falling over.
plinss: Running old software but running DB from new server. Haven't
had issues since doing that. Also fixed bugs causing
background processes to crash
plinss: So stable now, but performance not great. Getting hit by
webcrawlers. Work there is to switch draft server over.
plinss: Fun problem is that there's lots of interdependent services,
hard to move some but not all.
plinss: They're on python2, PHP5, need to be updated
<fantasai> strong +1 to serving flat files
fantasai: I made updates to inline layout that haven't shown up. When
do we expect it to catchup?
plinss: Didn't know it was behind, looking, I see an issue. It'll
start generating now.
chris: Thanks for that work. Downtime is much less now. My question
is bout test suite, also hosted there. That's a separate piece
of work?
plinss: Yes. Current funding covers server upgrade and porting python
2-3, ???, mercurial to git update. Don't have budget for
updating tests.
plinss: Can take simple bugs, but don't have current funding to
rebuild test build system etc
plinss: Everything we have will be migrated though
chris: For some specs, results out of date for 2 years. Any modified
since then are incorrect.
chris: Is that something could expect to be fixed?
plinss: All fixable but depends on the problem. Are problems will
build system not running to completion I'll look at. Depends
on if this is simple bugfix or something more fundamental.
chris: So we'll look for future update when you're done
plinss: We have a gitea and drone server. If you want more control
than github offers, or CI that github doesn't offer, we have
that available now.
florian: The calendar file is unreliably available. Sometimes you get
500 error. Aware of that?
plinss: Not aware, send me a note. Not hosted as current infra.
Calendar is hosted from w3ctag.org server.
CSS Values
==========
Define when border rounding happens, and to which properties it applies
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5210
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/5210#issuecomment-1292794138
dbaron: There have been differences in how border rounding works
between impls.
dbaron: Traian landed change to make Chromium match webkit, gecko.
dbaron: we think border-rounding is interop now.
dbaron: given this, and that there's dependency on it which may
increase, we should spec it.
dbaron: emilio opened this 2+ years ago, does he have anything to add?
emilio: <missed>
dbaron: In last comment I attempted to write definition in spec
language. Other folks from other engines should look. If
we're ok with it, lets move forward and try to spec it.
emilio: I was misreading, I think that definition is correct.
astearns: This is matching existing tests?
dbaron: Yes there are various tests. I think there are a bunch of wpt
tests for this behavior.
dbaron: I know when Traian was making chromium changes, making
changes caused Chromium to fail some existing tests.
Encouraged him to test only interoperable behavior.
asterns: Proposed resolution: Add this definition to spec and
evaluate new definition against existing test suite.
fantasai: Propose to add to values-4
dbaron: <missed> I don't strongly about which spec, I leave to
editors.
asterns: Proposed resolution: Add this definition to values-4 and
evaluate new definition against existing test suite.
RESOLVED: Add this definition to values-4 and evaluate new definition
against existing test suite.
<dbaron> (and the issue should have links to the WPT PR)
CSS Contain
===========
contain:size shouldn't fragment as monolithic
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5648#issuecomment-1240067326
florian: Situation is size containment has requirements about
fragmentation we need to satisfy for it to work.
florian: Reused frag. of monolithic elements because if fulfilled
reqs but it does more. Solves problem but with unnecessary
side effects. Can we relax solution to solve problem without
side effects?
florian: Size containment requires size of element doesn't change
when content changes, and if element is fragmented, size of
fragments don't change
florian: Could have first without second if move fragmentation point
florian: By saying size-contained element is monolithic, do get that
property.
florian: Slice the element <missed> and that solves the problem.
florian: If the element contains content, maybe interesting in some
scenarios the boxes themselves to that but the content is
allowed to fragment in fixed-size fragments.
florian: If have 3 lines of text in element and frag point is in
middle of second line, take the entirety of second line and
put it in next fragment
florian: 2nd and 3rd line could fit in second fragment without
overflow
<dbaron> sounds a lot like printing on paper
florian: Could be interesting to allow browser to either slice or
allow content, but allow fragmentation within these sizes.
florian: Should we do this? I don't think any browser does now.
florian: But could be interesting to allow them to
<iank> I slightly prefer leaving as is
iank: The way that balancing works is that it does need to know about
contents and where you slice
iank: and that has dependency on height. Also engines don't implement
fragmentation primitives well. Hesitant about adding another
iank: especially for such a narrow use case
iank: So prefer leaving it
miriam: As container queries becomes more popular, how much of an
edge case [connection lost]
iank: This is only needed when got full size containment or
containment in block axis
iank: Not needed in inline axis, which is dominant case for container
queries
florian: I think that's true, haven't thought about it a lot
florian: way I was proposing to address was to invent something to
size the content the same; don't require but allow normal
fragmentation
florian: It's just an allowance, don't have to take it
florian: Theoretically it would be fine. But only worth speccing if
there's interest in pursuing it.
florian: Another solution is to defer it and look again in 5 years
florian: Not time sensitive since it's an allowance only anyway
iank: Don't have immediate interest. Prefer leaving as monolithic at
the moment. Can change later if there's demand.
iank: There's demand for strongly making elements monolithic.
iank: Which capability doesn't exist now.
iank: There are cases where break inside avoid <missed>. I can raise
separate issue about that
florian: My sense is for this issue, defer it long term. Nothing
wrong with proposed solution but no point if no one wants to
do it.
florian: Can close issue, or mark deferred.
fantasai: If want to allow in future, should put it in spec,
otherwise people won't know we considered it.
fantasai: If think it's bad idea, should close no change
iank: Not sure if good or bad idea. It's ehhh.
<tantek> do we already link to it in-context in the spec as an open
issue? so implementers can be more aware of it?
fantasai: People make web page, use containment stuff. Then try to
print the doc. Do we think it's best to cut lines in half?
fantasai: I expect contain to be used all over the place. So
significant amount of printed content will be cut in half.
iank: Disagree with premise. Inline size containment will be used
heavily, but full size containment not that prevalent.
<chris> Haven't seen bisected lines of text on printing since, like,
Netscape 2 or something
astearns: Out of time. Will leave issue and keep discussing.
Received on Thursday, 17 November 2022 00:52:33 UTC