W3C home > Mailing lists > Public > www-style@w3.org > July 2018

[CSSWG] Minutes Sydney F2F 2018-07-03 Part I: 2019 Meetings, Values & Units, CSS Cascade, Scroll Snap, Writing Modes [css-values] [css-cascade] [css-scroll-snap] [writing-modes]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 19 Jul 2018 20:26:09 -0400
Message-ID: <CADhPm3tJ-YD-h4TaK=2KxThcFNRAE9yWm=Wif8JUcds3GyX9vw@mail.gmail.com>
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.


Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule

  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
  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

  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
  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
  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
  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
  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
  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


  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:
  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
  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
  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
  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
  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
  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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:09 UTC