- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Jul 2020 19:12:13 -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.
=========================================
Scheduling
----------
- There will be 4 4-hour F2F timeslots the week of July 27th.
Details are on the private list.
- Please begin to tag any F2F agenda items on GitHub. If you have a
preferred day or timeslot use the milestone to indicate that.
Media Queries 4 & 5
-------------------
- A joint session with the media working group was held to discuss
the video media queries. Though they heard the CSSWG's concerns
about the solution they still believe that the best way forward
is the proposed media queries. Discussion will return to github
in issue #5044.
- RESOLVED: Mark Update media feature at-risk in MQ4
- RESOLVED: Update CR of MQ4
- RESOLVED: Republish WD of MQ5
Pending Pull Requests
---------------------
- Editors are reminded to stay on top of PRs as old PRs have merge
problems. (Issue #5314)
CSS Pseudo Elements
-------------------
- Most of the group agreed the the proposal for ::first-letter to
include space separators (Issue #5154) however there was an
objection based on a lack of real world examples. Examples will
be gathered and then discussion will continue.
CSS Grid
--------
- RESOLVED: grid-template-areas should not accept empty strings
(Issue #5110: Should grid-template-areas accept empty
strings?)
- RESOLVED: Accept edits to spec for explicit grid (Commit with
edits:
https://github.com/w3c/csswg-drafts/commit/bae5afe6d692a2ae96bb524360f269933a5b044b)
(Issue #4914: Does grid-template-areas really expand the
explicit grid?)
CSS Lists & Pseudo Elements
---------------------------
- RESOLVED: Add ::marker { text-transform: none; } to UA stylesheet,
at least for now (Issue #4206: Does text-transform
inherit to ::marker?)
- RESOLVED: text-transform applies to ::marker (Issue #4206)
CSS Inline
----------
- There wasn't enough time left on the call to reach a resolution
for issue #5120 (initial-letters-wrap: first, whitespace
collapse needs defining) but everyone who spoke was in favor of
discarding the space when there's a drop-cap and keeping with
raised-cap. Unless there's objections raised in github a
resolution will be called for next week.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jul/0009.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Christian Biesinger
Mike Bremford
Oriol Brufau
Tantek Çelik
Hui Jing Chen
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Megan Gardner
Daniel Holbert
Dael Jackson
Sanket Joshi
Brian Kardell
Brad Kemper
Daniel Libby
Chris Lilley
Peter Linss
Alison Maher
Stanton Marcum
Devin Rousso
Jen Simmons
Miriam Suzanne
Greg Whitworth
Regrets:
Greta Krafsig
François REMY
Scribe: dael
Rossen: It is 9:02
Rossen: I think we have quorum. Hello!
Rossen: Any last minute agenda items or changes?
florian: I suggest a de-briefing of media WG meeting?
Rossen: Agree. We'll timebox and mingle with the MQ4 topic
Rossen: Anything else?
Scheduling
==========
Rossen: One housekeeping item
Rossen: Proposed dates for next virtual F2F as well as help we want
to request for topics you want to see or participate in a
time zone which is convenient for you
Rossen: We have proposed 2 timeslot A and 2 timeslot B meetings week
of July 27th
Rossen: We ask if you open any GH for agenda+ F2F please do add
topics. If you have a time slot please set the milestone to
be timeslot a or timeslot b for a date.
Rossen: As an example I've set milestone to be July 31st Slot A.
Rossen: It is one preference only so if there is overlap we'll
discuss with participants
Rossen: I'll clear this issue but that's the request.
Rossen: Any questions?
Media Queries 4 & 5
===================
Recap of MQ5 joint meeting with mediawg
---------------------------------------
Rossen: Since we are talking MQ it would be good to take a couple
minutes to recap the Media WG joint meeting. florian can you
do that?
florian: To avoid confusion joint meeting was about a MQ5 item
florian: My sense from our last discussion is we agreed on use case
and accepted a few video queries but looking closer group
was less convinced this was right way to solve
florian: From csswg there was limited attendance. I presented our
concerns but Media WG thinks this is still right approach.
We're back to GH to add or do further convincing
Rossen: Thank you. I would urge those interested in continuing to
discuss on GH.
florian: Because we have concerns and no conclusion I added issues
inline in spec in case anyone wanted to read.
Rossen: Makes sense. I got impression Media WG thought it was ready
to go.
Request for an updated CR for MQ4
---------------------------------
Open issues (none as of now):
https://github.com/w3c/csswg-drafts/labels/mediaqueries-4
Disposition of comments:
https://drafts.csswg.org/mediaqueries-4/issues-cr-2017-09-05
Changes Section: https://drafts.csswg.org/mediaqueries-4/#changes-2017-9
Calls for wide/horizontal review:
- > 1 month ago:
https://lists.w3.org/Archives/Public/public-review-announce/2020May/0008.html
-> In preparation of the previous CR:
https://lists.w3.org/Archives/Public/public-review-announce/2017May/0011.html
florian: We have no open issues.
florian: We have DoC and change section. Posted for horizontal
review 49 or 50 days ago
florian: Tests for everything new since last CR. Not a complete test
suite, but tests for delta
florian: List of changes is short, deprecated speech, added notes,
fixed a grammar bug, moved a definition to Values 4, added
some terms, dropped another value
florian: I suggest we mark Update media feature as at-risk as there
is no impl
chris: I was going to ask about how far from PR
florian: For everything except Update I think we have impl. Since
test suite isn't complete not sure.
chris: Untested features?
florian: Yes, I think so. Every diff from last CR is tested but bulk
was not. Far from complete.
florian: I plan to write more but I don't think should block CR
chris: No, not trying to block. Just wondering next step
Rossen: Question on tests, you mean in general for MQ4 or Update
features?
florian: In general. Some tests that are not exhaustive. All changes
from last CR have tests
Rossen: One at a time. Any impl with intent to impl Update media
feature and thinks we shouldn't mark at-risk?
Rossen: Obj to mark Update media feature at-risk?
RESOLVED: Mark Update media feature at-risk in MQ4
Rossen: Objections to update CR of MQ4?
RESOLVED: Update CR of MQ4
Media Queries 5 Publication
---------------------------
florian: Thanks. Follow-up.
florian: MQ5 was a delta spec. I have folded L4 in. Do we want a WD
of that?
<astearns> yes
<fantasai> yes
Rossen: I believe we resolved to republish 2 calls ago?
florian: I think a little more. There is a recent publication but it
doesn't include L4
chris: Would that make L5 the current work?
florian: Possibly?
fantasai: We never figured out policy for unleveled URLs. We often
switch at CR. I think that needs to be a general
conversation. We should publish updated WD of L5
Rossen: Absolutely. I believe previous resolution stands
fantasai: New resolution
florian: My memory is we published after last resolution.
florian: I don't know if folding in L4 falls into editorial changes.
If we're okay let's resolve
fantasai: We're spending more time discussing if we need a
resolution than if we just made one
Rossen: Obj on republish WD of MQ 5?
RESOLVED: Republish WD of MQ 5
Pending pull requests
=====================
github: https://github.com/w3c/csswg-drafts/issues/5314
chris: Reminder, lots of PRs that are old. As long as they languish
the older they get
chris: You can reject if you don't like, but please keep on top of it
chris: Quick reminder
plinss: We have 5 additional branches in main repo with 5 PRs. 4
have PRs open with 1-3 years old. Please review and handle.
Then please don't branch from main.
florian: Can we kill the one without a PR?
plinss: It's from TabAtkins
TabAtkins: Okay, will take care of it
CSS Pseudo Elements
===================
::first-letter should include space separators
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5154
fantasai: Issue about how not including spaces but only punctuation.
fantasai: Number of punctuation related patterns with punctuation
space letter.
<fantasai> https://github.com/w3c/csswg-drafts/issues/5154#issuecomment-655940861
fantasai: Proposal is update as description ^ to include intervening
whitespace in ::first-letter
Rossen: Feedback or objections?
faceless2: If not followed by letter does that go with it?
fantasai: Currently ::first-letter is a letter or digit. If you have
a paragraph with only punctuation there is no
::first-letter
tantek: I accept the situation exists in prose. What I'm not seeing
in issue is documentation or example like print example of
::first-letter with punctuation and space and letter all as
first letter
tantek: Open to keeping issue open but needs more data to accept
because otherwise might make worse
tantek: Inclusion of punctuation in ::first-letter at all we had
numerous examples in multiple languages. Since I'm not
seeing that I would reject
fantasai: Do you have those examples?
tantek: Yeah, need to check my bookshelf
fantasai: Typical case is if " in French you have to include space.
Usually not full sized.
tantek: My point is a French first letter with a " and a letter.
Need to see that example to move forward.
<astearns> there are two references in the initial comment
myIes: I think I disagree with tantek. If we're doing ::first-letter
that punch through punctuation this has to happen if we
support French
florian: Question is valid, does French do that
fantasai: This was raised because issue filed against browsers and
browsers wanted spec update
<fantasai> https://bugs.chromium.org/p/chromium/issues/detail?id=638267
Rossen: And there are bugs linked in issue
tantek: At time we found print examples in magazines so it was not
hard to find. If that's not true in French I'd push back.
Someone more familiar with French I'd ask have they ever
seen it in French and share an example rather then rely on
theory
Rossen: French only?
tantek: I think Norwegian is also provided in issue
tantek: Either is sufficient evidence.
tantek: When talking details I'd rather based on examples and not
completion-ism reasoning.
dauwhe: We use spacing like this all the time " and than ' would be
separated by a space. If that's all ::first-letter we'd want
it all selected. We use spaces between punctuation all the
time.
tantek: That's different than proposal.
fantasai: That's included. All punctuation before the first letter
is included as well as any intervening space. So this
would solve dauwhe use case
tantek: Have you seen it in print?
fantasai: We have it in English
dauwhe: I can't remember if I've seen that at start of chapter with
initial-letter. Somewhere that I'd need a ::first-letter
selector to capture that combo of glyphs
tantek: Anything adding complexity to platform has a cost. It's
reasonable to request some examples produces, esp with other
languages
astearns: True there is a cost, but this is a case without interop.
We can spec what is requested and have engines that don't
do it match those that do and we gain interop
Rossen: And this is Mozilla right that would need to add to be
interop
tantek: I couldn't determine from issue which engines did what
astearns: We know some do and some don't. Seems reasonable to spec
this knowing there are strings that have this behavior and
people like to apply ::first-letter to things. I don't
know it's necessary to come up with print example to spec
this and have engines match
Rossen: I think 2nd paragraph in opening issue comment. Safari
includes spaces, Chrome doesn't. There's a 10 year old bug
from Mozilla describing this.
Rossen: Safari is ahead and Mozilla and Blink need to catch up
Rossen: There is precedent for interop
plinss: If there isn't interop there is fail in testing or unclarity
in spec. Need to fix either way
tantek: I'd worry about compat if there's a 10 year old bug
fantasai: Safari shipped with this. Not sure why worried about compat
tantek: Safari might have compat problem
fantasai: Doubt it
florian: Especially since people are filing bugs against Chrome and
Firefox
fantasai: We've spent a long time on this. I'd rather we not spend
more time. tantek will you block and want us to go look
for more because the lack of interop and old bugs is not
enough?
tantek: Prefer to request examples and leave open
florian: I would agree with tantek if there had been interop and we
were proposing to change, but there isn't interop and we're
trying to align, so I don't agree
Rossen: Sounds like tantek you object on resolving based on lack of
evidence.
Rossen: Let's record that objection. It will go into the issue.
Rossen: I'm hoping dauwhe or Richard can get an example and we can
resolve next week.
Rossen: Either way we'll come back to discuss this around interop.
<tantek> That's fine, didn't intend so much time on this issue
Rossen: tantek do you agree with this?
tantek: Yes, reasonable. Thank you
CSS Grid
========
Should grid-template-areas accept empty strings?
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5110
TabAtkins: Oriol raised issue that technically spec does not
disallow empty strings in grid-template-areas
TabAtkins: No reason to do it either way but no one wants to put
empty string in. Both Chrome and Edge consider it to be
invalid
TabAtkins: As long as no objections we're going to say we require
one cell to be expressed or it's invalid
Rossen: Other opinions?
plinss: Requires at least one cell with a name?
TabAtkins: A cell. It can be empty.
plinss: If you define an area with empty string for name what does
it mean?
TabAtkins: It's got a track but no alignment
plinss: Same as dot?
florian: No, empty string would be parse error
TabAtkins: We don't give strings per cell name. String is name of
all cells in row
plinss: Right.
oriol: Difference between empty string and string with dot is it
forces it to have specific number of column and rows. If
allow empty strings grid would force 5 rows and no column
oriol: Strings with dots you could have 1 column. That's difference
TabAtkins: Given no use case for rows with 0 columns and it doesn't
go the other way around I'm inclined to call it invalid
which is matching Chrome and Edge
florian: Doesn't seem to be a use case to allow. It's a weird error
and we can align, the market share of browsers who do this
already prove it's possible
Rossen: I can see it spit out by preprocessors or tools. Having spec
is good
Rossen: I don't hear objections or pushback.
Rossen: Other questions or reasons why we shouldn't?
dholbert: Sounds fine to me/Mozilla
RESOLVED: grid-template-areas should not accept empty strings
Does grid-template-areas really expand the explicit grid?
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4914
<fantasai> https://github.com/w3c/csswg-drafts/issues/4914#issuecomment-609914410
TabAtkins: Issue here is grid-template-rows/columns/areas don't have
to agree number of rows or columns expressing. You can
have a template with 5 rows and only put 1.
TabAtkins: Question is what defines explicit grid. Explicit rows and
columns?
TabAtkins: Browsers agree on behavior but it's not well specified.
They are part of explicit grid, can detect by span to -1
line. Will fill space of grid-template-area. Sized as if
implicit tracks from grid-auto-rows properties.
TabAtkins: Reasonable, want to canonicalize in spec.
TabAtkins: We checked in edits and added tests. If there's
objections we can revert. Otherwise current spec has
intentions. Explicit grid is the larger option and if
it's more than rows and columns it's sized by grid-auto
Rossen: Thoughts or objections?
RESOLVED: Accept edits to spec for explicit grid
CSS Lists & Pseudo Elements
===========================
Does text-transform inherit to ::marker?
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4206
fantasai: One browser blocks inheritance of list marker
fantasai: Blocking text-transform makes sense. ::marker means UA
should set text-transform:none and author can set to
inherit. But default it should not inherit.
<florian> +1
fantasai: I want to go through text-transform before other properties
<TabAtkins> +1 to text-transform
oriol: Not sure I agree. text-transform applies to text like color.
If you set color it's inherit, why should text-transform be
different? For ::before and ::after it inherits. If you set
something case sensitive you would close it. Why should
marker be different?
florian: In general we don't know if text is case sensitive but we
do know markers are
TabAtkins: Agree with fantasai and florian where we have 2 pairs of
markers that are explicitly case sensitive. Having
text-transform for in is likely unintentional. Having it
automatically it may make it confusing to read. Should be
allowed to set
fantasai: Can also be semantic where nested lists have some upper
and some lower and then they're referenced in other parts
of text. If you transform the case it breaks the link. The
default would be safer if we don't have this inherit by
default
dbaron: I think there's some question if the thing is markers or
counter references
dbaron: I think the thing we're talking about is references to
counters which are lower-roman, upper-roman. If we were to
have a feature for counter references then the thing we want
to not be transformed is the counter reference.
dbaron: If rule in css is the counter references are not text
transformed there's no way for author to say they really do
want.
fantasai: Interesting point. Advocate a separate issue for that. In
meantime set text-transform to none so we get markers as
defined today
<florian> +1
dauwhe: Author PoV I found it surprising that I do something to list
item and changes list numbering
oriol: Should we allow it to list of properties allowed in markers
so authors can set to inherit?
fantasai: Yes, that's part of proposal
Rossen: Nearing a resolution. Other questions or PoV?
Rossen: If not I'll ask if there are objections.
oriol: Should we discuss other properties in issue? Text-indent
seems more obvious
fantasai: Let's not all properties together. Let's do one and move
to next.
TabAtkins: Unless you think they're linked.
Rossen: Do you believe they should be linked?
oriol: Independent
Rossen: Objections?
fantasai: text-indent is #4568
florian: You mean text-indent?
Rossen: Where should the resolution go?
fantasai: Here.
dbaron: I think at some point there was summary of existing impl
dbaron: Trying to understand that state
fantasai: Top of issue
dbaron: Claim Gecko blocks inheritence of text-transform. Do we
support text-transform:inherit?
oriol: In Gecko markers if you use content:normal it uses
nsBulletFrame which doesn't support text-transform. Content
to something different than normal it's a different box and
it inherits like Chromium. If you set it to something else it
will also do that
dbaron: I think implication is trying to resolve on something done
by some impl. I don't think that's the case
fantasai: I think there's some spec in what's impl. Effect on
existing pages...features where we don't have the behavior
are new and not much used. Discussion in the issue but I
concluded we should block text-transform on markers
dbaron: Rather than say it doesn't apply to counter references
fantasai: Until that's defined I think it's important to not
establish a precedence in the majority of cases with
markers
dbaron: Okay
<TabAtkins> I could see a list style that's like "First: ",
"Second: ", etc., which is fine to text-transform and
probably *expected* to respond to that. Maybe this does
need to go into the @counter-style definition, like
dbaron's earlier comments suggested...
<dbaron> (I think I probably prefer tying this to counters than to
markers, but I don't object.)
<fantasai> yeah, I could live with that... but I'm not sure how
we're going to make that work yet, and until we do I
think this is a good move
Rossen: Going back, any new objections from this conversation?
RESOLVED: Add ::marker { text-transform: none; } to UA stylesheet,
at least for now
Rossen: Next set of properties in the issue?
<fantasai> https://github.com/w3c/csswg-drafts/issues/4568
fantasai: Separate issue open which is #4568 which discusses all
properties
<fantasai> https://github.com/w3c/csswg-drafts/issues/4568#issuecomment-562734422
fantasai: I suggest we continue there.
fantasai: My take is we need to define what is inherited through
::marker vs properties that are for paragraph or line box.
Properties for block containers shouldn't be for ::marker.
Once we define the interesting question is if word-spacing
or letter-spacing is also reset.
fantasai: Not sure we should take it now.
florian: Given resolution we took I think we need to say
text-transform applies to ::marker
fantasai: Sure
florian: We said we'd put the property in the UA stylesheet without
saying to property applies
fantasai: Does it apply to marker or text. Need clarity
florian: That is applies somehow needs to be resolved
fantasai: Sure
Rossen: What's the proposal?
florian: text-transform applies to ::marker
Rossen: Thoughts or objections?
RESOLVED: text-transform applies to ::marker
Rossen: fantasai you asked if we should open #4568 about which
properties reset?
fantasai: I think today we should move on
CSS Inline
==========
initial-letters-wrap: first, whitespace collapse needs defining
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5120
fantasai: Appears that current suggestion is raised-caps should have
whitespace between them and first line but drop-caps
should not
fantasai: Question is do we make edits to make that happen
Rossen: Edits to make that happen in text? Or where?
fantasai: Changes to initial-letters spec. If you have a raised
initial then whatever whitepsace collapsing which would
take effect should happen. Word, raised-initial letter
should have all spaces
<tantek> yeah with dropcaps that space after the initial letter
would look like an errant text-indent
fantasai: drop-caps if you have that behavior it would be weird so
we should collapse the white-space.
<dbaron> This seems related to 'initial-letter-wrap: first'.
<dbaron> There's an example at
https://drafts.csswg.org/css-inline-3/#valdef-initial-letter-wrap-first
fantasai: dauwhe do you want to explain more?
dauwhe: It's a weird case. When the initial-letter is a word.
Example in English it's an A or an I that starts a sentence.
We need to retain the space so reader is not confused. Some
examples in spec I think. Sunk drop-cap gives you space
automatically. Raised-cap you don't so need to retain the
space
dauwhe: What fantasai proposes seems reasonable
tantek: Proposal the space when it's drop-cap?
fantasai: Discard space when drop-cap. Keep with raised-cap
tantek: Yeah. That's what I'm seeing in print
tantek: Print examples conform to that
<tantek> FWIW the print example I found was on p.80 of How To Spec
Type by Alex White
dbaron: Reasonable but makes me wonder if initial-letter-wrap should
default to first instead of none
fantasai: Does that because people didn't want to implement first
<fantasai> (so we couldn't make it the default)
Rossen: We're overtime and people are dropping
Rossen: Ready to resolve or table?
Rossen: We're losing people. Let's not resolve now and take this
first next week.
Rossen: Please add agenda+F2F issues and mark with dates for time
constraints.
Rossen: Thank you for sticking through the end. We'll chat next week.
Received on Wednesday, 15 July 2020 23:13:04 UTC