[CSSWG] Minutes Telecon 2016-03-30 [css-align] [css-shapes] [css-values] [mediaqueries]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Recap of CSUN meeting with members of the APAWG

  - Rossen gave the working group a summary of the requests and
      concerns from APAWG.
      - Their main complaint is CSS creates inaccessible content
          when additional content is added, such as generated content.
      - They were also concerned about content doing visual
      - The primary request from the group was to start work on CSS
          AAM and the secondary request was to create a task force
          to ensure that AAM progresses.
  - The group didn't object to working on AAM, so Rossen will check
      to see if the work is covered in the charter or if it would
      require a re-charter.
  - There wasn't any strong sentiment that a task force was needed,
      though there was a suggestion that a liaison may help
      - A decision on this will wait until the charter investigation
          and further discussion on developing AAM.

Spec Updates

  - RESOLVED: Publish a new WD of Box Alignment with a note about
              the default behavior when safe and unsafe is not
              listed explicitly.
  - RESOLVED: Publish new version of CSS Shapes

Comments on Serialization of calc()

  - Rossen brought his feedback from Microsoft to the group and he
      had three major concerns.
      1) It won't be something they would want to spend time to
      2) Interoperability will be limited
      3) Authors will find the simplification confusing
  - TabAtkins was only on IRC, so discussion will continue on the
      mailing list so he can respond.

Media Queries

  - RESOLVED: Add defining a minimum for the onload property as an
              issue in the spec.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Mar/0418.html

  Rossen Atanassov
  Tab Atkins (IRC Only)
  Bert Bos
  Tantek Çelik
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Myles Maxfield
  Thierry Michel
  Edward O'Connor
  Simon Pieters
  Anton Prowse
  Florian Rivoal
  Alan Stearns
  Ian Vollick
  Steve Zilles

  David Baron
  Dave Cramer
  François Remy
  Jen Simmons
  Lea Verou
  Greg Whitworth

Scribe: dael

  Rossen: I think we've given enough extra time. Hello everyone.
  Rossen: Any extra items besides what I've captured in IRC which is
          tantek request for updates and fantasai added one for grid
  Rossen: Any additional items people want to request?
  Rossen: I'll take that as a no.
  Rossen: We'll add extras to the agenda if we have time.

Recap of CSUN meeting with members of the APAWG

  Rossen: This was a meeting with Mike Cooper and Rich from APA WG.
          I wanted to give a quick update on that meeting and some
          action items they have requested from us.
  Rossen: The reason for the meeting was mostly from Rich and
          Michael in relation to their concerns that CSS is evolving
          at a rate they're having a hard time keeping up with and
          things happening are potentially disruptive for a11y. In
          summary their main complaint is CSS creates inaccessible
          content when additional content is added, such as
          generated content, counters etc.
  Rossen: Those of you following a11y, this is nothing new. We've
          spent most TPACs in joint meetings on this. Our message
          has been the same, we have a spec describing how generated
          content etc. need to be addressed for assistive
          technology, CSS Speech, but no one is implementing it.
  Rossen: The other complaint was one we discussed about a month ago.
          Content and visual reordering.
  Rossen: Again I restated that there is nothing new there and
          content in the visual reordering has been a capability
          since negative margins and abspos and whatnot.

  Rossen: What do they want from us? In order to avoid formal
          objections that are potentially going to be raised by IBM,
          they wanted to work on CSS a11y mapping spec, which exists
          for every other part of the platform. They want us to work
          on a API mapping like that on CSS. That would let us
          explicitly say generated content needs to do this to be
          part of the a11y tree. Same with counters.
  Rossen: Other thing they want us to work on is how visual order
          can be made a11y to keyboard nav. I did push back on this
          since visual nav is difficult. They want to see at least
          an acknowledgment we're working on it.

  Rossen: Last ask if there could be a joint task force between APA,
          Aria, and CSS so this can be driven. I don't see how such
          a task force can speed things up, but I'm putting this in
          front of you so that if there are people who want to
          participate in or create this task force, it's on the table.
  Rossen: So in summary, asks are start work on API spec and joint
          work with the task force.
  <TabAtkins> Rather than a TF, just start up a spec in the WICG
              about it?

  Florian: One question on visual ordering. We talked about this
           over and over. My impression is they have not as a group
           acknowledged or understood our feedback that we thought
           about this. Do you get the same feeling?
  Rossen: We have talked and discussed and explained everything I
          mentioned multiple times. There's nothing new here on our
          end. Their requirements as far as I gather are in the same
          place. Basically half the people want to nav visually,
          half don't. They're hoping UAs will get together and
          create both approaches.
  Rossen: In my opinion this is a difficult ask and can't be solved
  Rossen: So, yes, none of this information is new. The only more
          formal ask is the work on CSS AAM spec which came up
          during the last conference call fantasai and I attended to
          speak about flexbox. We softly agreed on that phone call
          that the spec can be done. Now we need to acknowledge that
          and put text.
  Rossen: My personal action was to recap all of this with the WG
          and try to understand if there are objections to have CSS
          AAM spec to be part of our charter so we can start working
          on it.

  tantek: A lot of these questions, as Florian pointed out, we've
          answered in the past. We can probably do some digging and
          find a DoC from a 10 year old CR that answers that. It
          sounds the answers aren't easy to find, though. So if we
          can get a discrete list of concerns we can put them in a
          FAQ so that we make it clear that we do care and we are
          listening and if we have answers we can point people to
          them and iterate where there's confusion
  tantek: It's come up frequently enough that it deserves an FAQ.
  tantek: I'm not sure how else to move forward on this
          communication issue.
  fantasai: We have 2 things in queue. There's clarifications to
            flexbox based on that conversation with a11y. dauwhe and
            I have been working on an update to generated content to
            make it easier to find these things are in.

  hober: Rossen you were trying to ask if we can add CSS AAM to the
         charter, right? Do you believe the current charter covers
         this, or do we need to recharter?
  Rossen: Depends on if there's a joint TF that we take on. It would
          be the TF charter to come up with AAM. I don't think we
          need to recharter because a11y is part of our charter.
  Florian: Yeah, do we need a TF or do we need a liaison?
  * fantasai prefers latter
  Rossen: I believe either are fine for them. Either of those will
          be more than what we have.
  Rossen: I think they'd be happy with them.
  Florian: Another comment. I have no problem about the group taking
           on the spec work, but I reject the framing that this is
           necessary to not object to flexbox.
  Rossen: I wouldn't hold flex up for this. If formal objection
          needs to be raised, I told them to raise it and we'll deal
          with it as we would with anything.

  Rossen: So we took 20 minutes. It was my action and obligation to
          take this up with the WG. If we're okay to add this to the
          charter, I'll go and read through the charter to see if
          it's covered, but would there be anyone objecting?
  <tantek> +1 on adding it to charter explicitly
  Rossen: I don't hear any. So we can start on CSS AAM. As for TF or
          liaison, a more formal relationship, we'll defer and do if
          the need arises.

  Rossen: We have MQ, Values, and the extra items on grid and spec
          updates on the agenda.

Spec Updates

  Rossen: tantek you wanted to put this on with some specs?
  tantek: I have specifics. Let's do this easy half and then hard
          half. I'd like to propose CSS Masking, Box Alignment, and
          Values and Units updated WD. Most of those are at least a
          year out of date. I know we've resolved previously, but
          we've had edits since. I think they're good enough to
          publish. If we agree that empowers the editors to publish,
          even with outstanding issues.
  tantek: So I propose that the WG update CSS Masking, Box
          Alignment, and Values and Units.
  fantasai: Masking and Values and Units are CR.
  tantek: Sorry, I misread that.
  fantasai: I'm planning to republish Values and Units anyway, but
            we're waiting on a solid review of the calc() because
            that's new.
  Rossen: And we have a topic on it today.
  tantek: Okay, I appreciate the correction. So revised to publish
          an update to CSS Masking.
  fantasai: Also in CR.

  tantek: Box alignment
  fantasai: I'm happy to take an action to prepare a publication in
            the next few weeks, but I want to check for edits that
            need WG resolutions.
  tantek: Since it's a WD I'd rather just publish and we can publish
          again with more edits. Since it's a year out of date, I'd
          like to publish as-is.
  tantek: I don't want to stop energy on things a year out of date.
  fantasai: Okay. There's one issue I want recorded which is the
            default behavior when safe and unsafe is not listed
  tantek: I'm absolutely for capturing the issue.
  Rossen: Is this discussed on the ML?
  fantasai: I haven't completely thought it through. I want it noted
            as an issue that may change.
  Rossen: It would be good to capture your personal concern. So
          objections to publishing a new WD of Box Alignment?
  <tantek> PROPOSAL: Publish CSS Box Alignment Working Draft with
           noting issue raised by fantasai
  <ChrisL> +1 to publish

  RESOLVED: Publish a new WD of Box Alignment with a note about the
            default behavior when safe and unsafe is not listed

  <ChrisL> fantasai, if that spec is ready to go by Monday I can set
           it up for Tuesday, otherwise it will be Thursday

  tantek: Harder proposal is we have a number of CRs that are long
          out of date. I have to thank fantasai for reminding me to
          look at this. So there's three CRs CSS Masking, Values and
          Units (which as fantasai noted calc() needs review) and
          CSS Shapes
  <fantasai> V&U is on my list :)
  tantek: Shapes is a year out of date, two years.
  Rossen: I don't think there's anything added.
  tantek: It was edited as of Jan 31 this year.
  fantasai: Formatting and linking fixes, you need to look at change
            log to see if it was substantial. We should get
            resolution if needed
  Florian: I don't believe we've done anything substantive in Shapes.
  <ChrisL> linking fixes are good
  astearns: There's edits resolved in November that I haven't done.
            It makes sense to do those and then republish.
  Rossen: At least for CSS Shapes, let's record a resolution. For
          the rest, fantasai I think you were editor.

  fantasai: V&U we're waiting to resolve all the issues and have a
            DoC. That's on my list. Masking I don't edit. We did
            resolutions in Sydney and we should have those in the
            draft and bring them to the group.
  tantek: Normative?
  fantasai: Yes.
  Rossen: Sounds like these aren't ready, but on the way.

  tantek: V&U is a topic later on the call, Masking I'm worried
          because it's more than a year out of date. I know there
          are pending changes, but why wait?
  fantasai: Publishing a CR takes a lot of process. We need a DoC
            and if there's nothing to put it's not worth
            republishing. I don't know if there's normative changes,
            they could just be editorial. The normative changes from
            Sydney are quite significant.
  tantek: I'd like TabAtkins' opinions on that too since he wasn't
          in Sydney.
  fantasai: We've renamed a keyword and that needs to be ASAP.
  ChrisL: If there are normative changes we need a DoC. There has to
          be a meeting and the less it looks correct the longer it
          will take.

  <TabAtkins> What needs an opinion from me?
  tantek: TabAtkins it's the pending normative changes in CSS
          Masking because we resolved on those when you're not there
          in Sydney. So 1) are the changes good with you? and 2) if
          so is there a rough estimate of when you'll apply the
  tantek: So we can do a CR with a DoC including those changes.
  tantek: I'm fine waiting, I just want to know the next steps.

  <TabAtkins> Ah, I have no clue what those changes are, so I'll
              have to review all of them. ^_^
  * TabAtkins has the entire Sydney minutes in his backlog.

  Rossen: While we wait on TabAtkins are these specs of interest to
          you because the dates, or is there anything else?
  tantek: Both the dates and these are implementations priorities
          for us, at least parts. That's my filter for bringing
          these up.
  tantek: So it's implementation request, not just busy work.
  Rossen: That's fair.

  Rossen: TabAtkins says he has no clue and has to go and review.
          That's your answer. So we can't resolve for that today.
  tantek: We got box alignment and shapes. We have to postpone
          masking until TabAtkins does minutes and V&U is coming up.
          I can bring it up again in a week or two.
  Rossen: Sounds good.
  Rossen: Objections to publishing box alignments and shapes?
  Rossen: Let's call it resolved.

  RESOLVED: Publish new version of CSS Shapes

  * tantek thanks Rossen for bumping up republication in the agenda

Comments on Serialization of calc()

Rossen https://lists.w3.org/Archives/Public/www-style/2016Mar/0369.html

  Rossen: This was about adding simplification to serialization for
          calc(). I wasn't here last week but I can update our
          position. I guess one question was when we are defining a
          simplified serialization what does that mean?
  <Rossen> calc(9px + 8em)
  Rossen: If I have something like ^
  <Rossen> 9px + 8em
  Rossen: It should output as ^?
  <Rossen> calc(9px + 8em + 5px + 3ex)
  Rossen: The first question is if I have something like ^
  Rossen: what is that serialized as?
  Rossen: Are all of them folded and computed to minimum possible
          types? Or only adjacent?
  Rossen: It's not clear to me what the ask is. And it's unclear how
          this makes it easier for authors to enter a random calc()
          and make sense of it during debug.
  <glazou> +1 to everything what Rossen said
  Rossen: I'm kind of uneasy
  ChrisL: That's a good question on debug. If people type in 4
          things and find 3 they'll find it weird.
  Rossen: Reading the e-mails it seems like it was this is what we
          do and it seems easy so we should do it. I don't see how
          it helps ergonomics. That was my feedback that was
          requested of us. At this point we're mostly against this.
  * fantasai thinks she agrees with Rossen's position here as well.

  glazou: In general, I agree with everything you said. In general
          if you change what an author specified the author will be
          lost when you try and debug or make edits because you
          don't find what you authored.
  glazou: We used to have a basic principal to avoid touching things
          the author specified. I know it's not always feasible but
          in general we should try and reach that goal as much as we
  * tantek wonders if there's a tension here between
           canonicalization and author-text preservation
  <tantek> AKA debugging
  Rossen: On our end we go to great lengths to keep all author spec
          stuff for debugging. The serialization in this case is
          lost. If we have a lossy serialization who knows what's
  Rossen: As to my point as to what are we combining, that will make
          it hard on the testability side. I don't want to have a
          whole bunch of new ways for browser detection because
          someone figured out how to use calc() to probe different

  <TabAtkins> Oh my god, this wasn't supposed to be re-litigated. We
              were just waiting for MS to make sure our tentative
              decision was implementable on their end.
  <TabAtkins> It is. End of story. Let's resolve the tentative
              decision we made last week.
  Rossen: There's no one on the queue.
  Rossen: I'm reading TabAtkins replies on IRC.
  Rossen: I'm not sure I read TabAtkins right. He says we don't want
          to re-litigate this decision from last week that was
          waiting for MS and now that I am speaking on their behalf
          and I'm expressing concern it seems TabAtkins doesn't want
          to take this. Again, I wasn't here. Was there a resolution
          last week?
  dael: There wasn't.
  Rossen: Okay.
  <TabAtkins> There was no resolution *because Greg asked me to make
              sure it was implementable by y'all*.
  Rossen: If it wasn't my position is not not simplify serialization.
  Rossen: If this needs more baking time I'm fine to go on the ML
          for this discussion.
  Rossen: I don't see or hear any push back. It looks like
          TabAtkins ....
  ChrisL: TabAtkins seemed to say there was a tentative resolution
          but gregwhitworth wanted more time to check.
  <TabAtkins> :(((((
  Rossen: And I did. I'm the implementor in charge of this and I
          have 3 push backs. 1) this won't be a trigger for us to
          implement 2) interop will be flaky at best and 3) this
          isn't helping authors. It's going to be hard for tools.
  <TabAtkins> What is this about "flaky interop"???
  <ChrisL> That makes sense
  astearns: The last point on helping authors wasn't part of last
            week's discussion.
  Rossen: Okay.

  Rossen: I don't believe we can resolve without TabAtkins on the
          call. I'd like to continue on the ML
  Rossen: We'll bring it back next week.
  <TabAtkins> arghgaldsg;s
  <astearns> TabAtkins: I think the main point is that the
             discussion last week talked about *whether* we could
             simplify, but not *why* - Rossen is arguing that it's
             not author-friendly to simplify
  <TabAtkins> And I *definitely* talked about why to simplify.
  <TabAtkins> I'm typing up an email right now.

  <ChrisL> florian, rossen - I'm at a conf next week so if we can do
           the color MQ this week that would be helpful. I have
           opinions on the questions posed

Media Queries - Scripting

  Florian: This has 3 values. none, interact (suggested to rename)
           which is normal scripting, and onload which is when they
           run normally but have something that stops it. One
           question was should we be explicit about a minimum amount
           of time that things need to run before you can be onload?
  Florian: TabAtkins said be fuzzy on time, fantasai says make it
           explicit. What do others think?
  Florian: Nothing...
  Rossen: Apparently not enough traction

  Florian: So the idea for having a minimum is that if you use it
           you want to rely on it for some things. So you want to
           know an event will fire. The alternative from TabAtkins
           is that determining which threshold is hard, but looking
           at it by the UA is easy, so let's not invent problems and
           keep it fuzzy for now.
  smfr: Do we know what Opera mini and UA do in printing?
  Florian: Opera mini I remember in a faint way...It does a combo of
           go at least as far as an onload and let the scripts run
           out as long as they do in a time frame. If not, send the
           results to a thin client.
  Florian: For printing, I'm not sure.
  zcorpan: I think Opera mini does the timeout even if you let
           scripts run. So it's interacting for a bit, but if you
           interact after 5 minutes, you reload the page.
  smfr: Seems like we should keep it fuzzy. I don't see how to spec
  fantasai: Should we set a min so that the author can rely on at
            least this has happened.
  smfr: Min seems to be you get a load event for the main resource.
  fantasai: That would be useful to put in the spec so someone
            doesn't decide as soon as the script loads we're done.

  zcorpan: What's the printing scenario?
  Florian: So can you do XHR once it loads, or do you assume there
           is no scripting engine and all content must be done
           server side? Can you use Houdini to do your layout?
  <Bert> (Both Prince and PDFReactor use JS on load to allow things
         like making ToCs or filling in subtotals on tables)
  zcorpan: Do you know of an app that would benefit from scripting
           on an onload?
  Florian: Yes, I think...If you know you're not going to have
           long-term running scripts you shouldn't set up handles
           for users to interact with and have scripts respond. But
           this is different than no scripts because the scripts can
           be used to layout the doc or content manipulation.
  <zcorpan> i still don't understand the use case
  <TabAtkins> zcorpan: The use-case for (scripting) in general?
  <zcorpan> TabAtkins: the difference between on and onload
  <TabAtkins> It means you can apply CSS that depends on JS working
              early, but shouldn't apply CSS for anything that would
              require JS to be running continuously.

  Rossen: So Florian what do you want from the WG?
  Florian: Are we happy to leave as is without an explicit set of
           requirements for a minimum of what you must run for
           onload or to we want to spec a minimum?
  smfr: Does anyone care for impl?
  fantasai: It would help for testing, otherwise what do you test?
  smfr: Yes, but does anyone impl this MQ?
  Rossen: We don't.
  fantasai: I would be mainly opera mini and printing engines.
  Florian: For Vivliostyle, we don't implement media queries yet,
           but we will soon and first would be onload.
  smfr: Given the level of interest I think we have to leave it fuzzy.

  Florian: On the ML we had a proposal that says you should go as
           far as loading the DOM Content. I'm okay with either, but
           if we don't write anything it's hard to test.
  <fantasai> I think it's useful to know if events fire at all, or
             if you only run inlined scripts
  iank: I think we need real-world feedback on this. I don't think
        there's a strong need to define it at this point.
  Florian: I'm okay with that. fantasai?
  fantasai: I'd prefer if we had a minimum bar which is you do all
            the scripts before onload or something. I don't care
            which, it can be conservative, but the author should be
            able to rely on something happening. Like do I have to
            do everything in an inline script? That would be useful
            for the authors to know when I'm working with this kind
            of media, I can position my scripts so they run
  fantasai: UA do all kinds of things because they're not targeting
            things like the script is only running for a part of the
            time. We're creating a MQ so the author can say what
            situation I'm in. If we don't tell them what they have
            to do to get their scripts to run that's not as useful.
            The impl won't care because they can do more. But for
            the authors it's useful to know if I put my script in
            this way it'll run. We need a boundary so they know what
            to target
  <tantek> tends to agree with fantasai
  <tantek> re: sympathizing with the model for the user
  Florian: I agree it would be useful for what you say. But given
           that we have limited UA experience should we wait?
  fantasai: If we don't have information we should ask for it. I
            think this is an open issue in the spec until we have a
            minimum. I want guidance for authors.
  <tantek> I'd prefer to keep it as an open issue on the spec as
           fantasai described
  <tantek> and frankly, publish with that explicit open issue

  Rossen: It sounds like you have preference for defining in this
          way. Implementors are saying we don't know until we play
          with it.
  fantasai: We don't have the right implementors on the call.
  Rossen: The implementors on the call who might implement this
          can't say this is easy to decide before we try.
  Florian: We're not proposing a definition, we're setting a minimum.
           I wouldn't be comfortable giving a max, but if we set a
           min that's fine. We'll probably do more, but we'll do that.
  tantek: I don't think we're going to come to consensus, but we
          agree there's an issue. I propose we capture the issue in
          the spec and then do a new publication.
  Florian: tantek that's why we're going through these issue is to
  tantek: So we should capture the issue. I don't think we'll
          resolve on the call. Capture as an issue and iterate it
  Rossen: Is everyone okay with an issue?
  fantasai: I'd like it marked as an issue and the editors take an
            action to contact people who would implement this and
            find a minimum.

  RESOLVED: Add defining a minimum for the onload property as an
            issue in the spec.
  ACTION Florian work with print related impl to find the best
         minimum for this MQ
  <trackbot> Created ACTION-762

  <ChrisL> won't be on the call next week (web audio conference) but
           wants to discuss the color one
  Rossen: This is the top of the hour. We have 3 MQ topics left. One
          was requested by Chris, color-gamut. Was there anything
          you needed captured?
  ChrisL: First is that I agree 'display' is correct term. Second,
          this should be restricted to RGB devices because that's
          current implementor need.
  Rossen: I'm not opening for discussion, I just want to capture
          Chris's thoughts since he won't be here next week.
  Florian: I want Chris's opinion, but a more productive way to
           capture them is...TabAtkins edited the spec. I'd like
           ChrisL's opinion on the latest version.
  ChrisL: I'll do that on the list.
  Florian: I do want your feedback.

  Rossen: Thank you all. That takes us to the end of this call.

Received on Wednesday, 30 March 2016 23:28:19 UTC