W3C home > Mailing lists > Public > www-style@w3.org > December 2014

[CSSWG] Minutes Santa Clara F2F 2014-10-27 Part II: Animations, Media Queries

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 17 Dec 2014 20:42:37 -0500
Message-ID: <CADhPm3vsRa=cPpUeh-CUWfJW=ujUon4sAk70+gpzT0jim6n-Mg@mail.gmail.com>
To: www-style@w3.org

  - RESOLVED: In level 1 we describe the current behavior of
      findRule and deleteRule
  - RESOLVED: Make appendRule always add at the end of the keyframe
      no matter if the key already exists.
  - RESOLVED: No change for now for Should CSSKeyframesRule inherit
      from CSSGroupingRule bug

Media Queries

  - There was a broad discussion about features that improve
      accessibility that should become a part of Media Queries both
      for their accessibility value, but also because they can have
      value to designers in general.
  - RESOLVED: Review all accessibility related issues to come up
      with a broad proposal.
  - RESOLVED: Reject scroll-position Media Query
  - RESOLVED: The media features overflow-inline and overflow-block
      are fine as they are. No change for current concerns.


  Scribe: dael


  glazou: Let's start again
  glazou: sylvaing are you on?
  sylvaing: I am.
  glazou: Since you're on the call, I suggest we do Animations.

findRule with multiple indexes

  sylvaing: Let me paste the issue.
  <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14788
  sylvaing: The question was... We have 3 issues left. In this one
            if you do a findRule can you use a comma separated list.
            Today the answer is not really. Most browsers don't.
  sylvaing: You need to be able to do it. Some rules will be comma
            separated. So, if a rule is 25%, 40% there is no notion
            of if you want the findRule for each. You'll only get a
            rule that has both keys. It attempts to match the whole
  sylvaing: The original question was if you can get more than one
            rule by patching in multiple values.

  glazou: My problem with finding only one complete key is that you
          need to have access to all the keys and parse them for
          individual values if you have two inside a key. That will
          be tricky for Animations editors.
  glazou: I'd rather have findRule work on individual keys. That
          leaves an issue for deleteRule.
  sylvaing: Right now...it's not super hard, it is extra work.
  sylvaing: The bigger question is if you...you want multiple rules
            to come back, right?
  sylvaing: Meaning you don't expect just the selector to be
            separate items. You expect to be able to delete/find
            more than one. That's a bigger challenge.
  glazou: Everything comes from that we want to delete a rule. The
          old works on indexes. The new OM there is a way to delete
          based on a rule itself.
  TabAtkins: I don't know.
  glazou: It was a suggestion. That way you can find the rule, check
          if it's made of the individual key, and then either delete
          or change the individual key you found.
  glazou: That's simpler. Different, but better.
  sylvaing: Right now you find/delete by selector and it's not super

  TabAtkins: I kinda propose we figure out the reasonable,
             compatible behavior, spec that, say it's deprecated,
             and make methods that don't suck.
  glazou: I agree if browsers will implement.
  sylvaing: There's an intermediate possibility. You can add the
            ability to get a list of all the keys. You can get them
            all and do find, find, find.
  sylvaing: The other rule...never mind.
  glazou: You still need to browse the keyframes, split from the
          comma, and trim. We could add that.
  TabAtkins: Yes.
  glazou: So that's getKeys on the keyframes rule.
  TabAtkins: Or have a forward attr.
  sylvaing: You have that with CSS Rules
  TabAtkins: We could have a separate one that gives you a list or
             array and make the existing one a put forwards of that.
  <glazou> DOMTokenList ?

  sylvaing: So saying you have a rule 25%, 50% and you get did key.
            Now if you do delete 25%: do we fail or do we succeed
            and it's there with only 50%?
  glazou: I suggest the second.
  sylvaing: I wondered about browser vendors.
  TabAtkins: That's what I'd want.
  glazou: If we don't spec it that way, authors will do it themselves
  sylvaing: There's a bunch of issues. If you have a selector with
            multiple values, if you can delete with only one value,
            you should be able to find the same way.
  sylvaing: You'd have to give findRule(25%, 50%) to get it. I think
            we should find it with just 25%. Once we go down the
            road of providing all the keys as an array and giving
            people access to rules, we get to a point of redoing the
  TabAtkins: That's what I said.

  glazou: But deprecating doesn't work and these things will stick
          forever and be used forever. Deprecate is only in our
          vocabulary, not in the users' vocabulary.
  TabAtkins: People respond to deprecation when writing tutorials.
             They don't do it with copy/paste code. That's why it's
             not remove.
  florian: It means we have a better thing to use.
  glazou: If we deprecate findRule, what will be the name?
  TabAtkins: findRules
  TabAtkins: or find-Rule

  dbaron: I think we want them more different. I'm also happy with
          just documenting what they do and design better.
  glazou: Okay. Is everyone okay with that strategy?
  shans: So will someone work out with the browsers?

  glazou: So there's two steps.
  glazou: sylvaing will you document existing behavior?
  sylvaing: Yeah.
  glazou: What about the second? The next version that's better?
  sylvaing: To be clear, the first step is describing existing
            behavior in level 1 and doing better in level 2 or
            something else?
  glazou: What you said.
  sylvaing: Can we resolve in level 1 we describe the current
  dino: And we hope the browsers are doing it the same. Even if we
        document this we hope someone will change. I don't know if
        they are.
  gregwhitworth: I think that lets us know where our issues are.

  glazou: Will you make a note that it will change?
  sylvaing: Yeah, I think we decided to do that last week.
  glazou: I can help.
  TabAtkins: I can help too.

  RESOLVED: In level 1 we describe the current behavior of findRule
            and deleteRule

appendRule and Existing Keys

  sylvaing: The next one....
  <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25035
  sylvaing: The question here is, if we append a rule with an
            existing key, what should happen?
  TabAtkins: Can you just append it..it goes to the end?
  sylvaing: I think glazou thought it would update the existing, but
            we can redo that. Have more than one rule with the key
            and append at the end, re-cascade and re-compute.
  sylvaing: This one is for clarification. I think to follow the
            existing API it just adds at the bottom. I believe
            that's what browsers do.

  glazou: To be clear, I have no preference, I just want it defined.
  sylvaing: Yeah.
  sylvaing: So any objections to making appendRule always add at the
            end of the keyframe, no matter if the key is existing?
  TabAtkins: As long as that's consistent with implementations.
  RESOLVED: Make appendRule always add at the end of the keyframe no
            matter if the key already exists.

CSSKeyframesRule inheriting from CSSGroupingRule

  <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25670
  sylvaing: Last one is about making the CSS keyframes rule inherit
            from the grouping rule. It sounds like yes for the next
            version from the discussion we've had.
  TabAtkins: I'm fine with making the change in spec now, but I'm
             not really bothered about it.
  sylvaing: I can't imagine it would bug anyone. Would it?
  dbaron: One issue is they both have a deleteRule method.
  sylvaing: Ah yes. It wouldn't be so clear. Once we inherit we're
            changing the API. I think it's good to move to the next
  dbaron: I don't know if that will be web compatible.
  sylvaing: CSSGroupingRule is recent.
  dbaron: The problem would be changing keyframes rule's deleteRule
  * smfr deleteRule(DOMString key); vs deleteRule (unsigned long
  sylvaing: I'm hearing this won't happen for a little while?
  glazou: Everyone agrees?

  RESOLVED: No change for now for Should CSSKeyframesRule inherit
            from CSSGroupingRule bug


  sylvaing: Then we have resolution on all issues.
  sylvaing: Next step is I'll edit this week and then there's the
            one from Sophia that I need you all to figure out. Once
            that's done we can do LC.

  glazou: Is that all for animations?
  sylvaing: That was the only 3 issues left.
  glazou: There was a bullet on the wiki about Animations level 4.
  dino: That was to discuss the proposal. That's about additive and
        cumulative Animation. Maybe do that tomorrow for Brian?
  glazou: Can you attend tomorrow sylvaing?
  sylvaing: 11am to 3pm is good.
  dino: There's a bunch of scrolling stuff. Even if that's
        Animations we can wait for Brian.
  ??: Theres a bunch of other people who want to attend.
  dino: It would go for more than an hour.
  glazou: Tomorrow at 11am?
  dino: We break at 1 tomorrow?
  glazou: Yes. sylvaing good for you?
  sylvaing: Yes.
  dbaron: Does that overlap AC?
  glazou: I don't think so.
  glazou: We have a problem. AC meeting is between 11 and 3. It
          means a bunch of people won't be here.
  sylvaing: That's okay. There may be background noise at a
            different time. Afternoon is better for me.

  dino: The new animation suggestion is not level 1.
  sylvaing: If you think it can happen, it can. It can happen...I
            can do it before 11, but there will be noise.
  dino: And do you want to listen into scrolling stuff? I'm sure
        dbaron does.

  TabAtkins: Can you link your e-mails on the wiki?
  dino: Yes.

  glazou: So tomorrow.
  glazou: Probably discuss this after 3. After the AC meeting.
  glazou: That closes Animation.
  glazou: Can we do layout this afternoon and MQ now?

Media Queries

a11y queries

  florian: First item has been discussed before, but not concluded.
  florian: One is Microsoft high contrast extension. The other is
           ink saving mode while printing.
  florian: Both inform about an intent. There is a request from the
           user. It doesn't just indicate a request, it indicates
           that something has been done to the page.
  florian: I think in general the right thing to do is nothing.
           Browser has adjusted. Sometimes the author can say I know
           how to respond. You need to be aware the user has
           requested and have to be able to say that the browser
           shouldn't do its thing, I have magic to do.
  florian: This property lets you say don't do the magic, I have a
           better solution.
  florian: Microsoft has high-contrast with 'auto' and 'none'. If
           you say 'none' you can do your thing.
  glazou: So the UA can override platform settings.

  smfr: I don't think that's doable on all.
  TabAtkins: It's per type of feature.
  florian: There's another discussion about type of high contrast.
           This is the thing that modifies.

  jcraig: I think you're thinking about the old increase contrast.
          On iOS8 and OSX10 there's things that allow changes of
          colors. It's a lot more subtle.
  florian: Microsoft's is more subtle.
  jcraig: Sorry, I meant "subtle" in that OS X and iOS settings
          "increase" contrast by more subtle amounts, while
          Microsoft's rendering change most colors to 100% black or
          100% white.
  florian: Even though you know the UA is adjusting to make higher
           contrast, you don't know how. The only way to respond is
           do nothing or turn off auto adjustment. Trying to overlay
           won't work nicely.
  jcraig: We have some idea. I'm not saying it's a bad idea, but
          they need to be extending to account for more platform
          differences. Or reconciled so we can check on user
          background/foreground colors.
  jcraig: I like the "don't adjust for this value" proposal, but I
          think it should be property level: e.g. don't remove
  florian: You want to do specific properties?
  jcraig: I was thinking more specific things. That's the major
          problem with Microsoft's where it removed background
          images and we've seem a lot of problems.

  TabAtkins: I was talking with James about OSX10's accessibility
             and it's impressive.
  TabAtkins: I think we should basically find the union of these
             things, more or less. It's not huge, and spec a big
             block of a11y media queries. Some are 'I'm requesting
             something', some of them are 'I'm doing something to
             you'. Some of them are a per-element, others are pixel
  TabAtkins: I think we should sit down with these and set some
             meaningful conventions. We should then come to the
             group with a solid proposal in a month.
  florian: And if you do this at property level saying 'I've done
           this to you', do we still want a property to disable that.
  TabAtkins: Generally you'll need one to disable the adjustment.
             Mac has one to adjust to 'not quite as white'.
  TabAtkins: So it's hard to hit everything there.
  florian: So you're agreeing with the general intention, but want
           something more specific.
  TabAtkins: And I want to spend time with a systematic proposal.

  jcraig: We have reduce motion setting, a setting to turn off
          transparency, and a "differentiate without color" setting.
          These are things we wouldn't override mechanically in the
          UA, but if a page author can adjust for a preferred
          rendering, they should be able to detect that preference.
  jcraig: Some of the others are....increased contrast and that's
          more of a preference to allow the web page to know the
          user prefers that.
  TabAtkins: There's enough things around that I want to spend some
             time on this, but your direction is the right way.

  TabAtkins: Do people think it's okay to spend time on this?
  fantasai: I think looking at everything together is a good idea.

  florian: The one problem is these are a11y only instead of being
           general features as well as general use.
  glazou: On some mobiles you have power saving mode. My comment
          earlier was if the user settings on the mobile say power
          saving and the style sheet can override that, that's an
  glazou: It's contrary to what the user wants.
  TabAtkins: If it's at pixel level you can't override. If it isn't,
             apps today can respond or not. An app can do it so I
             think it's reasonable.

  florian: There's a dangerous aspect. You could have someone just
           make the screen blink because they hate animation
  jcraig: There will always be people that use things maliciously;
          thankfully most people don't. We've found when we added
          features to the accessibility sections, they gained
          popularity in the mainstream user base, so over time we
          moved them out of the a11y-specific section (for example,
          bold fonts and large text). A power-saving mode could also
          change the reduce motion MF or the washed or dimmed MF.
          They're not all accessibility-specific. There's overlap.
  jcraig: You can make them specific to the feature and they get
          used more widely.
  TabAtkins: I think a lot can be cast in a more general way than
             pure a11y. They may not be super general, but okay.
  florian: I think that's cool.

  glazou: The proposal was to review all a11y features.
  florian: And the intent is something along what I proposed earlier.

  RESOLVED: Review all a11y related issues to come up with a broad


  florian: Another topic, there was a request for a scroll-position
           Media Query and I don't think we can do that because it's
           layout specific.
  florian: It's clearly interesting to do things style-related, but
           I don't believe Media Queries is the right mechanism.
  TabAtkins: I think the right one is attached to the animation
             behavior dino was talking about.
  florian: Yes. I'd like to resolve to reject that.
  TabAtkins: Even if you said selector, the same objection would
             apply. Like a media class.

  RESOLVED: Reject scroll-position Media Query

overflow-type queries

  florian: We have a couple things about overflow-inline and
           overflow-block. We're trying to break the types into
           essential features. One type about print is that you're
           on a page. Inline-direction and block-direction tends to
           be different
  florian: A printer will page in the block direction. But there are
           times it will go the other way. But before that we had a
           question about what is it you overflow in this context.
  florian: We concluded that what it was is the ICB if you're in a
           scroll and the paged media if you're in paged media.
           There's no word for either of these. Is this the right
           object and, if so, what's it called?

  TabAtkins: So naming suggestions for something more generic than
             ICB or paged area.
  fantasai: Wait...what?
  TabAtkins: The thing that when you overflow causes pages to wrap.
             On printed it's the page area. You'll overflow to new
  fantasai: So on the first page, they're the same.
  fantasai: You're a MQ so you don't know what page you're on.
  TabAtkins: This is the general strategy.

  fantasai: I'm having a hard time because I don't have context.
  TabAtkins: We need a name for the thing that when you're larger
             than it, causes overflow.
  Bert: Is it fragmentainer?
  Rossen: No. Not necessarily.
  fantasai: Send me a link to the paragraph where you need this term.
  <smfr> http://dev.w3.org/csswg/mediaqueries-4/#mf-overflow-block
  <TabAtkins> http://dev.w3.org/csswg/mediaqueries/#mf-overflow-block

  florian: Away from naming and back to what it is.
  florian: When you overflow that thing in inline and block
           direction, it causes different things.
  florian: If you think of a matrix printer if you overflow inline.
           Or a unix terminal. They all have variations. The set of
           values that represent what can happen in inline is
           different than the block direction
  florian: If you overflow in inline you scroll or clip. There's a
           case for tiling too.
  florian: To be able to do the tiling, you need to know where the
           pages are physically. That only happens in the inline
           direction. Maybe also in block. Inline doesn't have
           regular paging.
  florian: Regular pagination can't happen in inline.
  florian: Given that they're different, it brings us to having two
  florian: If you change the block direction in your stylesheet, the
           meaning of the two inverts. Either you need to do a
           special thing where you resolve the writing mode in this
           MQ, or you put the same set of values on both axises.

  fantasai: Another option...if you have a thing you can turn like a
            piece of paper you can turn it.
  florian: I think you've made this argument before, but can you
  fantasai: If you have a thing that's turnable, you can say the
            overflow block is paged etc. and if the author makes a
            document that changes the writing mode, you turn it so
            that page/screen is landscape and keep the same behavior
  fantasai: For writing mode when you change it you want to do it
            anyways. You'll want to be paging in the block direction
  florian: A receipt printer scrolls until you ask for a cut. You
           can't turn because it only prints in one way. The page
           can't turn.
  fantasai: If the root element is set to be vertical and it's sent
            to a receipt printer, you want vertical in the short
  florian: And once it's printed you turn it.
  fantasai: That's the way screens behave. If you set vertical, the
            block scrolling goes off the screen. For paging also we
            will define page in the block direction for the root.

  Rossen: I think it's still worth figuring out when do you tile and
  florian: Since it's a MQ, it's not telling the UA to do anything,
           it's just figuring out what it is. If it's tiling you
           don't lose content, if it's clipped you lose content.

  astearns: One of your options was have the same options in both. I
            think when dauwhe brought up an issue about a table...
  florian: I don't think it would be the same. You need to know how
           the pages will layout next to each other and that's not
           regular pagination. It's pagination-ish, but not the same
  dauwhe: I'm not convinced there isn't a requirement for pagination
          in the inline direction. We have books with massive
          foldouts. You have a range of content going out to the side

  florian: There's a few sets where it's straightforward and we
           should have values for those now. The types we need to
           handle a case like that needs two axises.
  fantasai: We have the concept of spreads and that needs to get
            into CSS.
  florian: I agree and this needs to respond once we figure out
  fantasai: It might be you have to tile two pages.
  florian: Is it tiling, is it a big page...?
  TabAtkins: This is why we don't want to address it yet.
  florian: I don't think this is incompatible with the end result
           for spreads, but if you disagree that's fine.

  SteveZ: I'm confused by dauwhe's example. I need a clear example
          between pagination and tiling. Pagination to me is
          dependent on how much fits in the block. To me tiling is
          taking whatever is in the overflow direction and
          generating pages to hold that.
  SteveZ: There's two ways to do that. There's what you want for
          tables which is layout in a bigger space and chop it into
          chunks. A second way would be I don't do that for
          overflows and I re-paginate the content in the overflow. I
          don't know how that would create a usable result.
  dauwhe: I was thinking of a case with hundreds of digits of pi
          where you want to maintain it.
  fantasai: You don't want to slice the middle of the word.
  florian: There's where do you cut and what do you do with the bit
           that has been cut.
  SteveZ: So its already laid out, you're just picking out a chunk.
  florian: So, with tiling the bit you're picking out would want to
           appear in a specific place.
  fantasai: For pagination you have a centered block, it should be
            centered on the next page.
  florian: But that's because that's how you styled it.
  Bert: Think of a float, it has the same width on both pages if
        they both have the same width.
  astearns: The distinction is pagination finds a break opportunity.
            In inline it could be a character boundary. That's what
            makes it sound paginated to me.
  fantasai: The layout of the contents creates the division. For
            tiling nothing changes and you just have a bigger thing.
  florian: And you may want to be smart about where you slice.
  fantasai: You don't want to cut tables. You really want to cut at
            a column. Tiling is we ran out of room and if you tape
            these things together it looks right.
  SteveZ: Is this like a spread case where you need to be more
          specific in how you handle it? I don't think we have
          anything written about this.
  fantasai: We have things that clip and scroll in the inline
            direction. Tiling might be an option, but it's not
            implemented and so we should work on how it fits into

  florian: So as we expand pagination specs you can then use this MQ
           and extend it to match the different modes. Right now
           inline has clip and scroll.
  florian: That's where I propose to start. Thank you for helping me
           understand the rotation. I think we need to figure out
           the name, but the spec can stay as-is elsewise.

  dauwhe: One terminology question. Since one of the overflows uses
          -x, -y, do we want to have that?
  florian: We're conflating two issues. If it's -x you're saying do
           the block direction. I think for this we can ignore, but
           for overflow-x/-y I think it's unfortunate.
  fantasai: I think they're physical. I think we're stuck.
  florian: Are they still used?
  Bert: Yes. They've been used a long time.
  fantasai: (We also have repeat-x and repeat-y.)

  florian: Other than the terminology, do we want to keep the spec
  fantasai: That seems to be where we're at.
  dauwhe: I'm fine with terminology as-is.
  florian: Now we says overflows the initial containing block and it
           should add or the paged area if you have one?
  dauwhe: We've used all the good words.
  TabAtkins: Initial page-taining block.
  fantasai: I'm not sure about the problem, so I can take a look.

  florian: If you're in a paged thing, the initial containing block
           isn't the paged area.
  fantasai: It is.
  TabAtkins: If your paged size changes in the document.
  florian: Ignore me.

  RESOLVED: The media features overflow-inline and overflow-block
            are fine as they are. No change.

Custom Media Queries

  florian: So we have custom media queries. Do you want that one
  TabAtkins: I don't recall what we need to do except I need to
             finish the spec.
  florian: We can discuss what's called issue 4.

  <florian> http://dev.w3.org/csswg/mediaqueries4/#script-custom-mq
  TabAtkins: This would be easier if the spec was on the screen.
  TabAtkins: Ignore that some of those use underscores, we changed
  TabAtkins: We already discussed custom media queries being aliased.
             If you want custom MQ that aren't aliases, I was looking
             at an API like this.
  TabAtkins: You have a custom media query that's a map and you set
             the value. Current plan is it's a number or it's one or
             more strings that have to match the ident production.
  TabAtkins: I don't have a good way to talk about units in here. If
             we pretend it has a length, you have to assume the 5 is
             pixels. When we have the better OM eventually we can
             have it take those and all the links will be
             interoperable, but for now I think it should be int and
             they document what it refers to with the assumption
             we'll make it better.
  TabAtkins: This has been up for a while, but if there are comments
             that would be good.

  * fantasai wishes custom things didn't require double hyphens
  * fantasai thinks they look awkward
  * fantasai -this- looks less awkward

  Bert: I don't understand the order they're evaluated. In this case
        I assume script first because foo isn't defined.
  TabAtkins: foo is false and when it has a value it works.
  florian: You just have to be careful to define the difference
           between false and syntax error
  Bert: So you can have a media attr on a link element: that cannot
        include the script?
  TabAtkins: Links can have a media and you should have that work
             here. Scripts always run.
  TabAtkins: MQ on elements, picture in particular, are used by the
             preloader and that would never be usable by this.
  TabAtkins: I'd like a solution that lets us define this in a way
             that's preloader friendly. That would define a custom
             MQ that you could use in stylesheet, but also for page
             where the preloader could figure out what is going on.
  TabAtkins: Right now you have to repeat yourself over and over
             again. I'd rather a nice way to make those rely on a
             single point so there's less editing badness.
  TabAtkins: I will want to do something with that in the future.

  plinss: Is the custom media scoped to the stylesheet?
  TabAtkins: Yes.

  ??: What if you have MQ for bar and you haven't set it and you do
      later. Are we dropping it?
  TabAtkins: Unknown MQ evaluate to false. That's in the spec. It
             doesn't drop the entire MQ.

  SteveZ: Did you say this is only scripts?
  TabAtkins: No.

  glazou: CSS is a global object. That means CSS gets the media set
          by one document. That seems wrong.
  TabAtkins: We've run into that before where namespace is on window
             not document. Maybe we put CSS namespacing on an object.
  zcorpan: That CSS is on window doesn't mean it effects them all.
  TabAtkins: All things see the window
  dbaron: Lots of things are effected. The spec calls the consistent
          thing a window proxy.
  TabAtkins: This is all confusing. If it's sufficient to say only
             the primary document needs to know about this and
             saying this kind of stuff only applies to the document,
             I'm fine with that.

  florian: And I think we're done with MQ.
  glazou: So we can find another topic now, or go to lunch now.

  [lunch break]

  glazou: We start again in an hour.
  florian: TabAtkins and I have a few edits that don't need
           discussion now, but once we do we'll be ready for a new
Received on Thursday, 18 December 2014 01:43:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:49 UTC