W3C home > Mailing lists > Public > www-style@w3.org > November 2016

[CSSWG] Minutes Telecon 2016-11-16 [css-ruby][css-inline][css-pseudo][css-2][css-position-3][css-values][css-device-adapt][mediaqueries][css-align][css-selectors-4][css-text][css-transforms]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 16 Nov 2016 20:13:34 -0500
Message-ID: <CADhPm3s+8=SHN4to6mETwm9-Qu6g2RqDUKQgL9EYjm=tRkZ2yA@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.
=========================================


Interaction of initial letter and ruby
--------------------------------------

  - RESOLVED: initial-letter and ruby is explicitly undefined.
  - dauwhe will incorporate this change into the spec.

Absolutely positioned boxes in inline relatives: not interoperable
------------------------------------------------------------------

  - RESOLVED: Standardize on Edge behavior as described by dbaron in
              the issue
(https://github.com/w3c/csswg-drafts/issues/609#issuecomment-259058527)
  - Rossen will incorporate this change into the spec.

Clarify that most (all?) high-dpi devices anchor on pixel, rather
    than physical, unit
-----------------------------------------------------------------

  - RESOLVED: Accept pull request from issue 713:
              https://github.com/w3c/csswg-drafts/pull/713

Port HTML note on zoom/accessibility
------------------------------------

  - RESOLVED: Take pull request 714:
              https://github.com/w3c/csswg-drafts/pull/714

Steps to CR: Box Alignment, Media Queries 4, Selectors 4, Text 3
----------------------------------------------------------------

  - Media Queries 4
      - There are several edits that need to be made to incorporate
          resolutions from previous telecons.
          - Most of them can be done by Florian or TabAtkins; ChrisL
              will need to do a few that relate to Color.
          - Florian will organize the effort to get these
              resolutions published.
      - Florian will try and prepare the only unresolved topic
          (https://github.com/w3c/csswg-drafts/issues/690) for
          telecon discussion soon.
  - Selectors 4
      - dbaron will add the language change he needs to write to
          github and try to write the changes soon.
  - Box Alignment
      - There are multiple edits around grid resolutions that need
          to be edited in before republishing a WD.
      - After that most remaining issues are around two value
          keywords and may be forked to a later level.
  - Text 3
      - astearns will try and incorporate the pending edits and will
          reach out for help if he runs short on time.
  - Transforms
      - astearns was actioned to remind people to incorporate the
          edits from the Lisbon F2F.
  - There was a general agreement that more people could be involved
      in incorporating edits into specs.
      - The "needs edits" flag will begin to be user regularly to
          indicate issues where this is a resolution reached but the
          spec needs it edited in.
      - There was also a suggestion that a flag should be added to
          indicate what edits would be good for someone new so they
          can get their feet wet and more experienced editors can
          focus on harder edits.
  - The end of year publication deadline is 19 Dec which means the
      last date for a CR resolution that could potentially be
      published this year would be 6 December.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Nov/0067.html

Present:
  Rachel Andrew
  Rossen Atanassov
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Daniel Glazman
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Myles Maxfield
  Anton Prowse
  Liam Quin
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Steve Zilles

Scribe: dael

Interaction of initial letter and ruby
======================================

  astearns: We have enough people so let's start
  astearns: Does anyone have any additional items? I noted Florian's

  <Florian> https://github.com/w3c/csswg-drafts/issues/654
  Florian: I want to clarify I'm not bringing this up because
           there's a use case, I think we should be clarifying the
           spec.
  Florian: For unrelated reasons I was reading the ruby layout
           section but had initial-letter in the back of my mind. I
           couldn't tell if it was trying to define something or not.
  Florian: After diving in further I think the right answer is to
           disallow initial-letter. If we spend a bit of time
           convincing ourselves we can close for good. If we think
           even that is not worth our time we could at least make it
           explicit that this is undefined rather than have a bit of
           text trying to define something maybe but it's not clear.
  Florian: That would save the next person trying to look it up.

  dauwhe: I'm fine with that. Certainly as a L1 feature I don't
          think we need it since we haven't seen a lot of use cases.
          I'm not qualified to design how it would work.
  Florian: I've spent a fair amount of time looking for use cases
           and I've failed. It tells me it's not terribly important.
           When we have ruby on the over side of an initial-letter
           it's clear, but when it's under it's a lot less clear how
           it would work. Between the challenge of how to have it
           work and the lack of evidence it's wanted I think we can
           disallow. But we can also have the ability to leave it
           undefined.
  Florian: It's hard to make sense of what it means.
  <SteveZ> +1 for leaving it explicitly undefined
  Rossen: Can we resolve on undefined in case someone has time and
          finds a use case? Then they can not be compltely blocked
          out. If we define it as not-supported they're blocked.
  <tantek> +1 for explicitly undefined
  <bradk> +1 undefined
  dauwhe: I'm fine with that. I can add an explicit statement to
          initial-letter that it's undefined in ruby and come talk
          to us if there's use cases
  <Bert> +1 for explicitly undefined
  <glazou> +1
  astearns: Proposed resolution: explicitly say it's undefined.
            Objections?

  RESOLVED: initial-letter and ruby is explicitly undefined.

  astearns: Who will make edits?
  dauwhe: I can.
  Florian: I think you should say what's in the github issue exactly
  <Florian> undefined whether it applies to children of ruby base
            container boxes and of ruby container boxes
  dauwhe: Okay.

Absolutely positioned boxes in inline relatives: not interoperable
==================================================================

  astearns: Unfortunately, fremy isn't on.
  Rossen: I'm here. I went through this briefly before the meeting.
          Issue on github was converging to spec the Edge behavior
          and Chrome in ltr case. I saw support from dbaron and I
          think fremy was looking for resolution on that proposed
          behavior.
  Rossen: That's as far as I know.

  astearns: dbaron described the issue in github as he understands
            and is happy to standardize on it.
  dbaron: Edge and Chrome agree for ltr but disagree in other
          directions. I think Edge does the parallel for other
          directions and Chrome is doing silly things so I'm happy
          with Edge.
  dbaron: Original proposal was standardize on Edge and Chrome
          behavior which is only a single thing.
  astearns: Anyone from Chrome with an opinion on their rtl behavior?
  Rossen: And vertical.
  astearns: Right.
  Rossen: In our case everything is logically the same regardless of
          direction.

  Rossen: No one here from Chrome or webkit?
  myles: I'm here from webkit.
  Rossen: Opinion?
  myles: Nope.
  astearns: Proposed resolution: standardize on Edge behavior as
            desc by dbaron in the issue.
  <dbaron> https://github.com/w3c/csswg-drafts/issues/609#issuecomment-259058527
  astearns: And we can have it reopened by Chrome or webkit if
            necessary.

  RESOLVED: Standardize on Edge behavior as described by dbaron in
            the issue
(https://github.com/w3c/csswg-drafts/issues/609#issuecomment-259058527)

  ACTION Rossen incorporate the language for the resolution
         "standardize on Edge behavior as desc by dbaron in the
         issue"

Clarify that most (all?) high-dpi devices anchor on pixel, rather
    than physical, unit
=================================================================

  <Florian> https://github.com/w3c/csswg-drafts/issues/708
  Florian: We have this whole logic on how CSS pixel works etc and
           then say for high def use physical inches which is not
           what they do in general.
  Florian: We should leave mechanics as they are and only leave
           print to anchor on physical and switch high def to user
           reference pixel.
  ChrisL: I agree I think when it was written [missed]
  <ChrisL> it was just printers we were thinking of at the time
  Florian: He says when written only thing high res was printers.
  <ChrisL> so +1

  astearns: My understanding is that sentences would change to say
            for print media anchor is a physical unit. For devices
            it's recommended that the anchor be a pixel unit.
  Florian: Yes and there's a pull request for that.
  <Florian> https://github.com/w3c/csswg-drafts/pull/713
  astearns: Let me look at that.
  astearns: [reads]
  astearns: Seems fine to me.
  astearns: Objections?

  RESOLVED: Accept pull request from issue 713:
            https://github.com/w3c/csswg-drafts/pull/713

Port HTML note on zoom/accessibility
====================================

  <astearns> https://github.com/w3c/csswg-drafts/pull/714
  Florian: This is about css device adapt. It has a zoom descriptor
           and at least in the viewport equivalent and meta viewport
           equivalent browsers have started to ignore it because
           it's user hostile. So there's some scenarios where UA
           honors when it's a web view in an app. Since it's
           sometimes honored it's worth specing. This warns authors
           if you try and disable zoom it might not do it.
  <tantek> seems reasonable
  Florian: This is in parallel to one that does the same in HTML.
  Florian: It makes sense to me but since it's a normative change
           allowing UAs to ignore makes sense to me.
  Rossen: We're proposing that we add the warning that suppression
          of zoom may or may not work.
  Florian: It's also a normative allowance for browsers to ignore.
  Rossen: So at this point it becomes a rec for how the zoom should
          be handled...it's a hint but may not be honored.
  Florian: Yes.
  Rossen: I'm fine with that.

  astearns: Other options?
  tantek: Sounds good to me.
  astearns: Thanks.
  astearns: Proposal: take pull request 714 which allows UA to
            ignore the zoom factor limit and adds a note on the fact
            that UA almost always allow users to zoom and gives you
            some hints about what you might want to do as you're
            creating a browser.
  astearns: Objections?

  RESOLVED: Take pull request 714:
            https://github.com/w3c/csswg-drafts/pull/714

Steps to CR: Box Alignment, Media Queries 4, Selectors 4, Text 3
================================================================

Media Queries 4
---------------

  astearns: fantasai sent an update, but didn't do MQ4
  <dbaron> fantasai's update was
https://lists.w3.org/Archives/Member/w3c-css-wg/2016OctDec/0130.html
  <tantek> re: MQ4
https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Amediaqueries-4
  <ChrisL> reminder that progress of in-process transitions is at
           https://github.com/w3c/csswg-drafts/blob/master/Transitions.md

  Florian: Mostly I haven't had time to work on it but there's
           almost no blocker. There has been an issue raised on
           pointer, hover, and variance. This is highly
           controversial discussion at the moment with sides not
           understanding each other. We'll have to go through it but
           I haven't prepared today.
  Florian: As far as I'm aware this is the only issue.
  astearns: Could you prepare it for next week?
  Florian: Maybe. I can try.
  astearns: Is there someone that can help?
  Florian: It would be good if TabAtkins looks.
  Florian: We should look in the coming weeks. I can't promise next
           week, but soon.
  astearns: Do you have a link?
  Florian: I'll paste it.
  <Florian> https://github.com/w3c/csswg-drafts/issues/690
  astearns: Let's get TabAtkins mentioned on the issue.

  tantek: Florian, you said only one issue with a normative change?
  Florian: No, I mean we've resolved on the others and I need to
           make the changes.
  tantek: Oh, so the others are still open because the edits haven't
          been made.
  Florian: Yes. I think we've resolved on everything else and I just
           need to make the changes.
  tantek: Cool. Sounds like we're close.
  astearns: Do you think you can get the edits in time to publish
            this year?
  Florian: Probably.
  astearns: Can anyone help?
  Florian: TabAtkins can do it as much as I can, yes.

  Florian: There were 1 or 2 color related issues that ChrisL said
           he can do so we're waiting on him for those.
  astearns: Can I action you to organize the work?
  ChrisL: Florian if you can point me to the issues?
  Florian: Yes.
  <Florian> for Chris: https://drafts.csswg.org/mediaqueries-4/#issue-156eb0fd
            and https://drafts.csswg.org/mediaqueries-4/#issue-2650c6fe

  ACTION Florian organize the MQ4 work
  <trackbot> Created ACTION-800

  <Florian> chris: this one is also about color, but I don't *need*
            your help on it, since we have a clear resolution
            (IIRC): https://drafts.csswg.org/mediaqueries-4/#issue-d9e3b586

Selectors 4
-----------

  astearns: [reads fantasai comment on selectors 4] there's a
            section for dbaron?
  dbaron: I'm not the only person that could do it, but I and some
          others weren't happy with the previous re-write which
          described selector processing as rtl.
  astearns: Do you know how to re-write it?
  dbaron: I hadn't thought about it. I didn't realize until
          yesterday that she thought I was writing.
  astearns: We can be pretty sure that she doesn't have time so can
            you look and see if you can get to it in the next week
            or two?
  dbaron: I can look.
  astearns: Feel free and send something to the list saying it's
            more work than you can get to.

  tantek: Which issue is it?
  <tantek> looking at
https://github.com/w3c/csswg-drafts/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3Aselectors-4%20
  dbaron: I think it does exist but I need to look.
  dbaron: Discussion might predate the github switch.
  Florian: It does.
  tantek: It's worth having an issue if it's a WD blocker.
  astearns: Agreed.

  ACTION dbaron to set up and issue for the selectors 4 change
  <trackbot> Created ACTION-801

Box Alignment
-------------

  <tantek> box alignment is presumably
https://github.com/w3c/csswg-drafts/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3Acss-align-3%20
  astearns: Box Alignment which fantasai wrote needs 1 change for
            grid items and then could be republished. Then she talks
            about stripping bits of it so we can just have Grid and
            Flexbox items.
  astearns: Does anyone else have additional things to happen to box
            alignment?
  astearns: tantek just listed issues.
  tantek: I'm just asking github. Nothing intelligent.

  <tantek> is that label:"Needs Edits" is for?
  <tantek> are we consistently using label:"Needs Edits" ?
  <tantek> does label:"Needs Edits" mean issue resolved but just
           needs edits to be made to the draft?

  astearns: We did resolve the shorthands would be place-* but we
            don't have syntax for the value which Mats is asking for.
  astearns: I was supposed to split that into another issue...that's
            on me.
  astearns: Who are Box Alignment editors? Just fantasai and
            TabAtkins?
  Rossen: I think it's just them.
  astearns: Would it be good to add another person? It looks like
            there are resolutions that could have been edited in.
            Anyone interested in taking it on?
  [fantasai joins the call]
  fantasai: Hi!
  fantasai: I think for alignment most of the issues are around
            anything with two values. If we drop those we can go to
            CR quickly. That include the shorthand issues.
  astearns: Are these edits something you can get to in next few
            weeks? I'm assuming not.
  fantasai: I might have a few hours around Thanksgiving. And then
            hopefully we can make sure anything other than issues
            around two values is handled. Then someone can strip the
            two values items out of the spec and do CR.

  astearns: You said it would be okay to republish with a change to
            deal with grid items. Is that a first step?
  fantasai: That's a good idea. Pushing that edit would be good. I
            think it need corresponding edits in Grid.
  astearns: So first is get intrinsic ratio edits in, republish as
            a WD.
  fantasai: Yeah. If TabAtkins has time he could do that.

Editing in resolutions
----------------------

  astearns: To answer tantek there is a Needs Edits label in github.
            I don't think we're using that and it would be fine if
            we did.
  tantek: It could indicate an issue has reached resolution as well.
  astearns: That's how I would interpret the label. There are issues
            with a note saying that there's a resolution with a
            minutes link. It's not easy to see what's awaiting
            edits. It would be good to have that label.
  tantek: Especially for things trying to take to CR.
  <rachelandrew> I would be happy to help with Grid or Box Alignment
                 edits, I know those specs well although might need
                 some initial help with process.
  tantek: It also may help when you've asked for additional editors.
          It could alert the broader community if you want to get
          your feet wet by submitting edits here's a bunch of them.
  astearns: We could have the starter issue label too to indicate
            there's some that don't need years of experience. Some
            things, like the selectors one, we need a dbaron level
            of experience.
  tantek: Yes, this could also let experienced people focus on
          harder ones.
  astearns: Thanks rachelandrew for volunteering. Look at the issues
            list and see if there's something you could put a pull
            request for.

Text 3
------

  astearns: Last spec is Text 3. Still has some issues, but could be
            published. koji are you on?
  astearns: This is one where there are a bunch of edits anyone
            could do.
  astearns: I may have time in next week or two. If I run out of
            time I'll ask for help.
  <tantek> +1 to Text WD

  astearns: Are there any other publishing topics people want to
            bring up? Terribly old WD?
  <ChrisL> https://github.com/w3c/csswg-drafts/blob/master/Transitions.md
  ChrisL: I would like to point out that we have a document for
          transition requests in progress. If you do a request this
          should say latest status.
  <gregwhitworth> ChrisL: isn't Tables done? That should probably be
                  updated

Transforms
----------

  fantasai: Transitions, animations, and transforms are all likely
            out of date.
  astearns: We did resolve in Lisbon to push 3d transforms to next
            level and push transforms to PR. Is anyone working on
            that?
  ACTION astearns poke people about getting transforms edits done.
  <trackbot> Created ACTION-802

  astearns: gregwhitworth had a question on table transition?
  ChrisL: I'll check and update the doc. Anyone else can update it
          too.

Last publication date
---------------------

  astearns: tantek had a process question about last publish date
            for CR this year.
  astearns: When does publishing moratorium start?
  ChrisL: Dec 19
  <ChrisL> December 19 - Jan 1
  astearns: So last chance date for CR would be a week or two before?
  ChrisL: Yeah.
  Florian: So we have 2 weeks.
  tantek: We'd need CR call before.
  ChrisL: You have to have a transition request and have a week
          between. Call can happen between. If DoC is in good shape
          you can skip the transition call. We're getting better at
          that.
  tantek: I noticed.
  tantek: CR transition requires manual publish.
  ChrisL: So it's a Tuesday or Thursday, yes.
  ChrisL: The system can't handle the patent policy aspect.

  tantek: What's the last Tuesday or Thursday before Dec 19 because
          that will be busy?
  <gsnedders> Thursday 15th
  ChrisL: 19th is a Monday so Thursday the 15th
  tantek: So call completed by 13th and stage 14th?
  ChrisL: Correct.
  ChrisL: So 6th is the hard deadline to put in a request.
  ChrisL: Nicely done tantek that's good to have.
  * tantek is slowly becoming a project manager
  * ChrisL grins

  astearns: Let's see what we can get done by the end of this month.
            Possibly all the way to the 6th if you really want to
            see how quickly things can be done...or not.
  astearns: Any other topics? If not we can close early.
  astearns: Thanks everyone for calling in!
Received on Thursday, 17 November 2016 01:14:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 17 November 2016 01:14:39 UTC