- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 19 Jul 2018 20:26:09 -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.
=========================================
2019 Meetings
-------------
- RESOLVED: Summer 2019 meeting in Toronto, hosted by Mozilla.
- RESOLVED: Tentatively have Feb meeting in Hawaii, hosted by
Google; backup is Kyoto.
CSS Values & Units
------------------
- RESOLVED: Empty URLs are treated as "about:invalid"
- RESOLVED: Publish Values & Units 3 as CR.
- RESOLVED: Publish Values & Units 4 as FPWD.
CSS Cascade
-----------
- RESOLVED: Republish Cascade 3 as CR.
- RESOLVED: Republish Cascade 4 as CR.
Scroll Snap
-----------
- RESOLVED: Republish Scroll Snap as CR.
Writing Modes
-------------
- fantasai will prioritize the implementation report and the group
will look to see what can be done to get all the tests to pass.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Mozilla
Brian Birtles, Mozilla
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre
Emil A Eklund, Google
Elika J Etemad, Invited Expert
Jihye Hong, LGE
Koji Ishii, Google
Dean Jackson, Apple
Ian Kilpatrick, Google
Chris Lilley, W3C
Peter Linss, Invited Expert
Myles C. Maxfield, Apple
Cameron McCormack, Mozilla
Xidorn Quan, Mozilla
Francois REMY, Microsoft
Florian Rivoal, Invited Expert
Hiroshi Sakakibara, BPS
Alan Stearns, Adobe
Shane Stephens, Google
Lea Verou, Invited Expert
Philip Walton, Google
Eric Willigers, Google
Scribe: TabAtkins
2019 meetings
=============
Rossen: Haven't figured out next year yet.
<astearns> TPAC 2019 Sept 16-20 in Fukuoka, Japan
[In Lyon for TPAC this year, in Sydney now, in Japan for TPAC next
year.
Can have Feb and May for two meetings before.]
dbaron: If we wanted 1/3 spacing between TPACs, want to meet around
Feb 11 and May 26
florian: I suggest slightly later in Feb to account for people not
working in Dec.
florian: Due to December, 1/3 spacing is even in days, but not in
work amount.
dbaron: That also move sit slightly away from Chinese New Year,
which is a good thing.
dbaron: With even spacing, we have about 3 1/2 months between each
meeting.
fantasai: I'm concerned about overflow from TPAC since we have only
two days, but four months until TPAC.
fantasai: I think we're gonna end up with too much in the TPAC
agenda.
tantek: in reality only 1.5 days, because of joint meetings
fantasai: I would hesitate to create extra space after TPAC, because
we'll have overflow
fantasai: So not sure about late February.
astearns: Do we have any host for February
tantek: Anyone hosting?
astearns: Maybe Toronto for summer; it's not suitable for winter.
astearns: That gives us a North America meeting, and with next two
TPACs we have Europe and Asia covered.
florian: Should I see if we can host in Kyoto?
florian: Kyoto is great in Autumn, but with TPAC, and it's too
crowded.
TabAtkins: Where were we in Kyoto?
koji: A conference center
[something about Boston in February being bad]
dino: Could have it in Yass...
[more location discussion]
Rossen: San Diego?
plinss: I can host if someone else pays...
[Santa Monica, Seattle, ... ]
Rossen: So May/June in Toronto. That confirmed?
dbaron: We can host in late May or June. Can't go deep into June,
but early is fine.
Rossen: So summer in Toronto, hosted by Moz.
RESOLVED: Summer 2019 meeting in Toronto, hosted by Mozilla.
[discussion about Hawaii]
dbaron: Only problem with holiday destinations is you probably don't
have >9hr flights, so fewer direct
Rossen: Anyone with a problem coming to Hawaii?
TabAtkins: I'm happy to try to get a Hawaii conference room.
RESOLVED: Tentatively host Feb meeting in Hawaii, hosted by Google;
backup is Kyoto.
Rossen: What about Seoul?
Rossen: We have LG, some people from Samsung.
dbaron: Anyone know where next spring's AC meeting is?
florian: Some time in late March.
florian: In East Canada somewhere.
Rossen: First week of June? 3-6
TabAtkins: I'm MCing an Amsterdam conference, probably 13/14 June,
but *might* be 6/7 June. Maybe can do previous week?
fantasai: That's Memorial Day weekend.
* fantasai suggests checking in with dauwhe when he calls in
Rossen: So we're thinking June 3rd in Toronto, last week of Feb in
Hawaii. That's plan for now, we'll confirm soon.
Publishing stuff that's almost ready
++++++++++++++++++++++++++++++++++++
CSS Values
==========
Scribe: fantasai
DoC: https://drafts.csswg.org/css-values-3/issues-cr-2016
fantasai: One issue open, then should be able to publish.
empty url behavior
------------------
github: https://github.com/w3c/csswg-drafts/issues/2211
TabAtkins: url() function with empty string as its argument...
TabAtkins: I changed spec to match behavior of empty resource
requests in HTML
TabAtkins: and y'all reverted the change because you didn't
understand why I did it.
TabAtkins: Answer is to be consistent with HTML!
TabAtkins: Empty URL is technically a relative URL to the resource
itself
TabAtkins: But e.g. in HTML <img src=""> doesn't load the resource
TabAtkins: Empty URLs will still resolve in some cases, like in links
TabAtkins: But not for resource loading like this. Makes no sense to
load the CSS stylesheet as an image of itself.
...
chris: Do we expose imports in the OM, and would ...??
TabAtkins: I don't know
TabAtkins: But recursively attaching the same URL again wouldn't be
useful
TabAtkins: I would like it to automatically fail, invalid URL.
tantek: But not invalid syntax
TabAtkins: No, not invalid syntax
TabAtkins: There's no place in CSS where resolving the URL as the
URL of the stylesheet would be useful
TabAtkins: Proposal is that the empty URL, rather than being treated
as a relative URL, is treated as an invalid URL
TabAtkins: Computed value is still an empty string, just treated
like 'about:invalid'
TabAtkins: There should be no noticeable behavior difference, since
the stylesheet is not a valid image/etc.
Rossen: Other comments?
<tantek> +1
RESOLVED: Empty URLs are treated as "about:invalid"
Publishing CSS Values 3
-----------------------
Scribe: TabAtkins
Rossen: So this is the last Values 3 issue.
fantasai: And the spec is already in the state we just resolved (it
didn't actually change yet from the previous resolution)
Rossen: So it's been a CR since 2016
fantasai: Probably earlier
Florian: 2012
Rossen: So yeah, let's repub CR.
chris: V&U can't be used by itself, you can only test it by testing
other properties.
chris: But can't just depend on 2.1, since there are new values used
since then.
chris: I think that needs a bit of discussion.
fantasai: That's easy. You write a test off of 2.1 - all our specs
are based off of it. So write your test with a CSS2.1
feature, then exercise all units for that property.
fantasai: So like border-width, and have a stack of elements that
should all resolve to the same value, expressed in
different units.
chris: So you're asserting that there are no values or units only
applicable outside 2.1.
fantasai: Time, maybe... Can write against transitions.
dbaron: Write the tests against the thing that's most likely to be
supported / been around the longest
florian: And resolutions, write against MQs maybe
fantasai: An impl can't conform to V&U alone, but that's already
explained in Conformance, or was in the past.
florian: Using MQ is easy because it's already in Rec, but TTA
aren't in CR...
tantek: Some way to look up which RECs use Values normatively?
florian: For Rec, CSS3 UI.
fantasai: We have some boilerplate that goes in all specs - Module
Interactions and Values.
fantasai: It talks about where the values come from and such.
fantasai: So all of our specs with this boilerplate are written such
that their actual dependency is against 2.1, but if you
implement V&U 3 it replaces those.
fantasai: So you can always fall back and reference 2.1.
fantasai: So there's no issue about advancement, we figured this out
in 2007.
tantek: I don't think we figured out how best to construct the test
suite for V&U. We're talking about that now, didn't figure
it out in 2007.
tantek: Another suggestion - for every type in V&U, pick a property
we think is supported, regardless of what spec it's from.
fantasai: That's what we just said, yeah.
tantek: And for each new unit we added, if we can capture its
use-case, go back to their properties they were meant for
and test that specifically.
florian: I think in theory that makes sense, but in practice the
only stuff we'll have problem with outside of 2.1 and MQ is
<time>.
Rossen: So back to publishing. We have list of changes?
fantasai: Yeah.
Rossen: Any objections?
RESOLVED: Publish V&U 3 as CR.
fantasai: Good to go as soon as we add the empty-url thing to the
changes list.
TabAtkins: Man, I added that back in 2016, I'm bad at this.
Publishing V&U 4
----------------
TabAtkins: I was delaying publication until I added unit math, which
is done now.
fantasai: There's a changes list with new units,
min()/max()/clamp(), and unit math.
<fantasai> https://drafts.csswg.org/css-values-4/#changes
Rossen: Any objections to publishing as fpwd?
RESOLVED: Publish V&U 4 as FPWD.
Cascade 3 & 4
=============
Publishing
----------
Rossen: Is this just a repub request?
fantasai: We added the shorthand stuff we resolved on in Berlin, so
we wanted to repub.
<fantasai> https://drafts.csswg.org/css-cascade-4/#aliasing
TabAtkins: Florian had an issue about aliased properties in value
space - what do you get if you do `transition-property:
old-name`?
fantasai: That's handled by the "operation similar to case-folding"
thing. You get new name; parsing converts it.
florian: Is that what's implemented?
dbaron: I know we have a bug on transition-property where it wasn't
where I wanted, but that was pre-Stylo.
TabAtkins: I think this is the most consistent way to handle this,
and any differences we might have are just bugs that we
can fix.
Rossen: What about that vague issue in the Privacy-Security section?
chris: @import allows embedded content, so just mention all the
usual fetch stuff.
TabAtkins: I can turn that into something actionable.
<tantek> priv-sec section still needs usual @import about fetching
URLs, CORS etc.
Rossen: Any objections to repub?
fantasai: Cascade 4 - we haven't made changes to Cascade 3. It's
just waiting for testing/evaluation.
tantek: Could repub 3 as an editorial update that links to the test
suite.
chris: Tangential, let's turn on test-suite stuff on TR docs.
fantasai: Oh, 3 does have changes - we dropped scoped styles, and
removed the override origin per WG resolution.
Rossen: So any objections to publishing Cascade 3?
RESOLVED: Republish Cascade 3 as CR.
Rossen: So level 4?
fantasai: We have some issues asking for clarification on shadow DOM
stuff, but I don't think we need to address that
immediately.
fantasai: Multiple specs with shadow DOM issues, and not entirely
clear where they go; need to sit down and figure it out.
florian: That sounds normative.
fantasai: Yes, but we're not sure it goes here.
chris: Can just say "these things aren't resolved yet, want review
of everything else"
Rossen: So objections?
RESOLVED: Republish Cascade 4 as CR.
CSS Display
===========
Publishing Display 3 as CR?
---------------------------
fantasai: There's one open issue
florian: There's a few open with "needs edits"
fantasai: One is for Tables edits, not Display
florian: And then "computes to instead of behaves as"
TabAtkins: Y'all resolved that last week.
fantasai: Main blocker is 2673, but we need Oriol.
TabAtkins: Let's pick this up in two weeks.
Scroll Snap
===========
Publishing updated Scroll Snap CR
---------------------------------
Rossen: Changes?
<fantasai> https://github.com/w3c/csswg-drafts/issues/2232
TabAtkins: We fixed an issue where something was defined backwards.
Also did clarification on several bits, worth
republishing.
astearns: There's one open issue...
fantasai: It's a question, and the responder hasn't responded back
yet. If he does, it's a new feature request, which
probably goes to next version.
Rossen: Any objections?
RESOLVED: Republish Scroll Snap as CR.
Writing Modes
=============
Writing Modes Next Steps
------------------------
fantasai: I need to finish impl report. We need two passes on some
new tests.
florian: Half a dozen new tests
fantasai: Fix is pretty trivial, not auto sizing or anything.
Question of computing an extrinsic size - "auto" based on
viewport. You have to factor in height and max-height; we
need passes on those tests.
chris: Any bugs on browsers for those tests?
florian: Don't think so; I don't recall. I'll do so.
fantasai: I think easiest way to get this passing is to get Blink
and Gecko conforming.
Rossen: So what's a timeline expectation?
fantasai: Not sure.
fantasai: Could do impl report in an afternoon, but not fixes.
skk: Do we wait for browser implementation?
florian: Yes, and test report.
koji: Do we want to wait for that one thing to be implemented, since
if it takes 6 months or something we'll get more issues.
koji: Can't fix it in new layout engine right now; we have other
issues.
koji: So in reality it's probably 6-12 months to fix.
florian: There was political value in getting it to REC last year,
unsure if it's still valuable to those people in Japan...
koji: I'm getting pinged before every f2f
florian: So question is if we should push for a symbolic REC, even
if not technically interoperable?
fantasai: I think I could do Gecko impl of the fix, I know that
codebase, but we need a 2nd impl.
florian: Let's discuss offline.
fantasai: If impl report is #1 thing, I can do it next week.
Rossen: I'd consider this spec high-priority, as it would take spec
to REC.
fantasai: Koji already gave me a template with a lot of work done, I
just need to update it.
florian: Could Edge fix this particular issue? Doesn't need to pass
*everything*.
Rossen: Will see.
Rossen: Our release schedule isn't too friendly for that...
TabAtkins: That doesn't matter, an unreleased version *intended* for
release works fine.
fantasai: We'll take this offline to finish.
<dbaron> BTW, does anyone know why the test results in wpt.fyi show
tons of failures on writing modes tests that look like they
pass when viewing them? (Is it possible to see the reftest
images that are used in wpt.fyi test runs?)
<fantasai> dbaron, I think those are anti-aliasing issues
Conditional Rules
=================
dbaron: I don't know about the edits since last CR, but I know of
one issue that's somewhat substantive.
<dbaron> https://github.com/w3c/csswg-drafts/issues/1016
fantasai: Big changes were editorial and converting to Bikeshed.
fantasai: Substantive is whitespace around "and"/etc, and allowing
.supports() to drop parentheses around a single condition.
fantasai: Those went in, but there was no CR update.
Rossen: So how about we take this into break and discuss publishing
CR after?
fantasai: Yeah, maybe dbaron and TabAtkins can discuss that.
<br dur=15min>
Received on Friday, 20 July 2018 00:27:05 UTC