- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 5 Sep 2019 08:38:15 -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.
=========================================
Process updates from AB
-----------------------
- fantasai introduced the proposed process changes that will be
presented formally at TPAC. The presentation is here:
https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_16
Mailing list is: https://lists.w3.org/Archives/Public/public-w3process/
and GitHub for issues is: https://github.com/w3c/w3process/issues
- The goal of this new process is to make it easier to keep CR and
REC level specs up to date by reducing the steps needed for
Director approval and changing patent review triggers.
Media Queries
-------------
- RESOLVED: Add navigation controls media query to MQ 5 (Issue #4187)
- The group was leaning against issue #4162 (Expose User Preference
Media Queries as HTTP Client Hint or HTTP Header) because the
general feeling is that is would not have a significant benefit
and may be another vector for fingerprinting. These concerns
will be added to GitHub and discussion will continue there.
CSS Overflow
------------
- The main part of issue #4123 (It should be detectable whether an
element ellipsized the text) can be closed, though there is a
sub-issue on some APIs not reporting subpixels which will need
to be addressed still.
CSS Lists
---------
- RESOLVED: No change re computed value of list-style-type (Issue
#4210: Compute non-existent `list-style-type`
<counter-style> to `decimal`?)
CSS Display
-----------
- RESOLVED: Do not add table-cell/table-caption as display-outside
values at this time (Issue #3940: Make `table-caption`
and `table-cell` <display-outside> values)
Scheduling
----------
- Anyone unable to attend a call next week due to travel to Japan
should say so early on so a determination can be made if there
are enough people to get quorum next week or if the call should
be canceled.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Sep/0004.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Brian Birtles
Oriol Brufau
Tantek Çelik
Elika Etemad
Simon Fraser
Dean Jackson
Peter Linss
Myles Maxfield
François Remy
Florian Rivoal
Devin Rousso
Jen Simmons
Regrets:
Rachel Andrew
Christian Biesinger
Dave Cramer
Benjamin De Cock
Dael Jackson
Cameron McCormack
Christopher Schmitt
Scribe: AmeliaBR
Scribe's Scribe: fantasai
astearns: Any agenda additions?
astearns: We may push multicol issues to next week / TPAC.
Process updates from AB
=======================
<fantasai> https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_16
fantasai: We will be presenting these slides ↑ at TPAC
<fantasai> https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_0
fantasai: Maintaining a spec that is in late stages up to date is
difficult. Want to reduce overhead of frequent updates.
fantasai: While maintaining wide review & making sure that is
handled.
<fantasai> https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_0
fantasai: Proposal is to update W3C Track Process. E.g., get royalty
commitments earlier in the process (CR or WD).
fantasai: For CR, want to automate more routine Director approvals
for updates — e.g., if there has been no disagreement/
objections.
fantasai: Ideally, you just fill out a form. If all checks are OK,
the director isn't going to object anyway.
fantasai: But frequent updates are a problem for patent review;
don't want patent reviews more often than 6 months. So we
want to split CR publication updates from reviews.
fantasai: While do the approvals & reviews periodically, but not
every time you push a minor update.
fantasai: We'll also be formalizing the system that Tantek &
(missed) started, annotating spec with notes about what
has changed and why. So the review is more predictable.
fantasai: So we can issue a call for review on those specific
changes. And everything can be reviewed at the same time.
fantasai: (This is specifically about changes to a REC spec)
Changes can go through full review without re-reviewing
entire spec.
fantasai: For these easier updates to REC specs, you can only do
this if chartered for "extensible specs".
fantasai: Some specs have a need to be predictable and fixed.
fantasai: (something about registries. I got behind, sorry)
<florian> thanks fantasai for the nice summary
astearns: How do we give feedback?
<fantasai> https://lists.w3.org/Archives/Public/public-w3process/
<fantasai> https://github.com/w3c/w3process/issues
fantasai: Here is the mailing list & process repo.
astearns: Are issues on the repo recommended?
fantasai: Yes. Minor questions about the slides can be sent direct
to me. But issues on repo.
astearns: If these changes go through, should CSS WG change to
Living Standard specs for each module?
fantasai: I'm mostly happy with how we work with versioned specs.
Switching to updating recs would mean all new development
would need to be isolated to note boxes until ready to
commit.
fantasai: And I wouldn't want to change until we see how this works.
But other changes will help.
TabAtkins: I mostly agree. But I'd like to get CSS Syntax as a
permanent REC. So that all updates get immediately
integrated.
fantasai: And we're not adding many features to Syntax.
<florian> https://w3c.github.io/w3process/everblue/
florian: One comment about that repo link: Most of what fantasai
described hasn't yet been merged into the main branch.
florian: But most of it is in this branch of the Process [link]
florian: except a few bits, e.g. ...
florian: the bit about only some CRs triggering reviews.
astearns: I'd add, if you are an AC rep for / part of an org that
cares about patent law, make sure your lawyers see this
presentation. It doesn't have all info they need, but they
should know what's coming.
<fantasai> https://lists.w3.org/Archives/Member/w3c-ac-members/2019JulSep/0024.html
Patent Policy Survey
fantasai: There's an open survey for AC reps on Patent Policy. One
of many surveys likely going forward.
fantasai: (brief summary of Patent Policy survey questions)
<fantasai> Open questions other than the patent policy application
poll:
https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_0
<fantasai> Depending on results, we may be able to update things
more smoothly.
Media Queries
=============
Proposal for Navigation Controls
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4187
TabAtkins: Request for a way to tell if there is a back button or
similar (e.g., PWA shells don't always have this), as a
media query. Normal browser it would be true. PWA may be
false, so you might want to add a back button in your
page UI.
TabAtkins: For now, the request is only for back button, but the
proposal is designed in an extensible way.
dino: I don't understand the scope of "back button". Would a
back-swipe gesture count? Generally support the idea, but we
need to define it.
dino: I can also see other use cases, like is there a share button?
TabAtkins: Question on back swipe is interesting. Not all UI options
are equal. Keyboard controls might not be well known. But
depends on the platform.
dino: That's just an example. My concern is that the query should
focus on the functionality rather than the "button" nature.
<jensimmons> +1 to being generic... not too focused on How People Do
Things in 2019.
florian: Individual parts of the media query are useful. But how
would it be collapsed to a boolean level, without breaking
extensibility?
TabAtkins: Current proposal is boolean means any navigation control,
of which back button is the simplest. If we can't make
that assumption, that the boolean mode is probably
meaningless.
myles: Some browsers are designed as standalone apps; other browsers
integrate with a system, like an iOS webview. Whether there's
a backbutton or not depends on the embedding app. Webview
doesn't know, may be difficult to implement.
TabAtkins: In that case, if the rendering agent doesn't know, they
should probably be conservative & assume there isn't
anything.
florian: And maybe embedded web views could add an API for the
environment to tell them if they're handling navigation.
myles: That doesn't help with existing apps
florian: But it could help in combination with sensible defaults.
TabAtkins: And the default wouldn't be any worse than today.
Rossen: Is there a reason we're only talking about back button right
now & not navigation controls as a group?
TabAtkins: No reason to avoid other features. It's just that
back-button has the strongest use case & is the one that
is most commonly available.
TabAtkins: But I made sure syntax would work with other buttons, too.
TabAtkins: If we find anything that is really important we can add
them too.
Rossen: If we are only doing back-button for now, why not just use
that in a boolean sense?
TabAtkins: I didn't want "any"/"none" because that could be more
complicated for adding things.
AmeliaBR: Would a URL bar be included inside this general concept of
navigation controls?
TabAtkins: If people think that's a useful thing to expose, sure
TabAtkins: Number of possibilities we could
AmeliaBR: URL bar allows copy/paste of current URL and also allows
navigation
AmeliaBR: Also can be used to share
TabAtkins: Interesting question of whether that should be distinct
from share button
florian: Wrt URL bar, I could imagine a UI which has URL bar only
but not back button
florian: so assumption of always having a back button might not be
correct
TabAtkins: Theoretically, but I don't think that will happen
florian: Without a time machine
drousso: One clarification: Are we talking about the *presence* of
these buttons, or whether they are enabled? E.g., in a new
tab, back button is disabled.
TabAtkins: I could be convinced either way, I think it's best to say
"is it present", regardless of whether currently
disabled. Probably don't want to toggle this on and off a
lot. Might be used via JS to download extra scripts.
AmeliaBR: What is the request at this time?
TabAtkins: To add to draft. Can discuss specifics later.
astearns: Any objections to adding to a media queries draft?
RESOLVED: Add navigation controls media query to MQ 5
astearns: We should also get in touch with the original proposer
(fallaciousreasoning) for giving credit.
Expose User Preference Media Queries as HTTP Client Hint or
HTTP Header
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4162
TabAtkins: Idea is that some of the preference media queries trigger
fairly substantial changes to a page. E.g., reduced
motions might trigger more than just CSS fix-ups.
TabAtkins: If you want to make changes on first display, need that
before the page downloads.
TabAtkins: Idea is to pass this info to server as a client hint &
server can respond with the good stuff
TabAtkins: Some debate on the invalidation logic. The settings can
change over the course of a session.
TabAtkins: But overall, idea seems reasonable. But I'm not well
versed on client hints.
dino: My preference is that this shouldn't happen. Media queries are
supposed to be dynamic & can cause page changes.
<tantek> +1 dino
dino: Changing which JS you download doesn't seem to conform.
dino: Could also make pixel tracking techniques even easier.
TabAtkins: I disagree that changing downloads is a minor benefit.
Could help make sure that initial payload is as small as
possible, good for many use cases.
TabAtkins: Already, sites can *try* to do this by setting server
cookies based on previous MQ results. That's more likely
to mess things up than using HTTP headers.
<tantek> CSS is a tiny fraction of what G sends down compared to the
heaps of JS. Not buying the "send less CSS" argument as a
practical impact here
<tantek> LMK if there's a noJS version of G properties that has well
designed CSS for normal/dark mode and what % of the page
download that would impact
drousso: Using the example of dark mode, downloading only a
slimmed-down dark mode CSS. If that MQ changes, then the
cache invalidation must need to handle the change in state,
to know what to download.
TabAtkins: I suspect this is similar to state handling in many JS
based apps, but I'm not an expert.
drousso: Would probably need to add query parameters to CSS so that
it can be invalidated.
dino: I think the savings for cutting out a bit of CSS is probably
not worth the overhead. Cookie tracking might not be that bad
an alternative.
<tantek> +1 dino thanks for making the right argument. sending both
normal/dark CSS rules are tiny compared to all the rest of
the page load size
TabAtkins: Sounds reasonable. Can you add these comments to the
issue so we can close it with reasons?
<tantek> I'd say, the additional fingerprinting from Client Hints
for this are not worth the fractional anticipated
performance gain by less CSS compared to the massive JS in
practice.
florian: Another concern is privacy. If we allow this on HTTP as
well as HTTPS, preferences get leaked everywhere. Also,
logged on all sorts of servers
dbaron: I am also generally skeptical. But I think some arguments
given here aren't correct & what to make sure those are
clarified. Client hints spec integrates with vary headers,
so that caching can handle it. And designed so
fingerprinting is active rather than passive as suggested.
dbaron: I'd also want more details on proposal anyway before
accepting.
astearns: OK. So let's follow-up on issue.
CSS Overflow
============
It should be detectable whether an element ellipsized the text
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4123
TabAtkins: Issue comes down to some APIs not reporting subpixels,
which can give weird results sometimes. That's worth
addressing but I think we can close main issue.
florian: Worth mentioning that the use case is JS code to *show*
ellipsized text. If more browsers offered that as a
built-in feature, wouldn't need to hack around it.
CSS Lists
=========
Compute non-existent `list-style-type` <counter-style> to `decimal`?
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4210
TabAtkins: fantasai discovered this when cleaning up lists spec.
Issue is what should computed style be if you set the
list-style-type to a custom ident that doesn't currently
exist.
TabAtkins: The used style is decimal. But computing that eagerly (as
Firefox used to do) can be problematic, since @-rule
could be added later.
TabAtkins: I don't think any other browsers yet implement custom
idents; they reject at parse time. I think best to follow
current Firefox. Computed value is the custom ident.
astearns: There are Firefox folks in thread pointing out that
current behavior wasn't really intentional.
TabAtkins: That's OK. It's still good behavior. Let's spec it
properly.
dbaron: If Emilio's OK with it, I'm OK with it.
TabAtkins: He wrote the current Firefox behavior, so I hope so.
astearns: And this will just be no-change to current spec.
RESOLVED: No change re computed value of list-style-type
Scheduling
==========
<dbaron> btw, are we having a call next week? (Will a lot of people
be en-route to Japan or already there?)
<florian> a call next week would not be very convenient for me, but
I could probably make it
astearns: I was planning to have a call next week. dbaron notes many
will be travelling.
astearns: We can try to have a call, but see if we will have quorum
or not.
<florian> I would like to know in advance, cause staying up till the
middle of the night and then not have a call isn't nice
CSS Display
===========
Make `table-caption` and `table-cell` <display-outside> values
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3940
fantasai: Mats wanted to support allowing flex/grid inside table
caption. Maybe also table-cell, but there are more layout
issues there, so the focus is on caption right now.
TabAtkins: Chrome would have issues with doing this for table cell,
although that makes me sad. But I think caption is OK.
iank: I think it's OK to do this with table-caption. Will need to
check.
dbaron: Do table captions affect the table size, or does the table
size affect the table caption's size?
fremy: They can in that if the caption is wider than the table, the
table gets stretched to the wider size.
florian: That doesn't seem like a very hard interaction to handle.
dbaron: The harder interaction would be if the table layout affected
the caption size.
iank: Was there any demand from authors, or just requesting for
completeness?
iank: Can we delay this, then?
florian: So, no to table-cell since it's too hard. And not yet to
table-caption as there isn't strong enough demand.
astearns: objections to wontfix?
RESOLVED: Do not add table-cell/table-caption as display-outside
values at this time
Scheduling (part 2)
===================
fantasai: It would be nice to know before next meeting if there will
be a meeting or not. Especially for those calling in very
late from Japan.
<tantek> posting regrets for next week's call now :)
<dbaron> Definite regrets from me -- can't do a 1am-2am call and
then be ready for a 9am all-day TAG face-to-face meeting
<iank> regrets for next week.
<smfr> i can show up
<plinss> regrets for next week
<myles> I will not attend next week. Tokyo FTW
<florian> I don't wanna show up next week
<AmeliaBR> regrets for next week. I will be in a plane if all is as
scheduled.
<fantasai> next week is inconvenient but possible for me, week after
TPAC should be no problem
Received on Thursday, 5 September 2019 12:39:18 UTC