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

[CSSWG] Minutes Telecon 2014-04-16

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 16 Apr 2014 20:41:49 -0400
Message-ID: <CADhPm3v_2d6jCmJhdtyuWdzDtpKgGEP5QEiTc553C15DHZ3Lhg@mail.gmail.com>
To: www-style@w3.org
Fallback for "ch"
------------------

  - RESOLVED: Default for CH unit is 0.5EM

Add -x/-y longhands to background-* properties
----------------------------------------------

  - RESOLVED: background-position-x/-y, background-repeat-x/-y
        approved for level 4 of backgrounds and borders.
  - background-size-x/-y was also discussed, but didn't garner much
        support.

Image Orientation for Backgrounds
---------------------------------

  - RESOLVED: Make the image() function always respect EXIF
        orientation metadata.
  - The future of comma delimited lists in images was also raised,
        but there was a feeling of unpreparedness, so discussion
        will continue on the list.

Changing MediaQueryList to use events
-------------------------------------

  - There were lots of questions about the implications of this
        change.
  - The main issue was how a single event that would change multiple
        items would be handled. TabAtkins will bring this item to
        the mailing list for feedback.

Scrollbar Tracking Control
--------------------------

  - TabAtkins presented the idea for being able to position the
        scrollbar at a certain distance from the bottom once you
        scroll to the bottom of the content.
  - There was discussion about the use cases for a property like
        this and the interplay between this proposed property and
        sticky positioning.
  - RESOLVED: Discussion continues over e-mail

Subgrid
-------

  - Deferred to next week

calc() pow operator
------------------

  - The working group wasn't against adding a pow operator, but some
        people didn't feel there were sufficient use cases. General
        feeling was that this is something that can be done in the
        future, but is not a priority.

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

Present:
  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Elika Etemad
  Sylvain Galineau
  Daniel Glazman
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Taichi Kawabata
  Brad Kemper
  Philippe Le H├ęgaret
  Chris Lilley
  Michael Miller
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Greg Whitworth
  Steve Zilles

Regrets:
  Simon Fraser
  Peter Linss
  Simon Pieters
  Anton Prowse

  ScibeNick: dael

  glazou: Let's get started.
  glazou: plinss isn't going to be here today, so I'm chairing. Any
          extra items? I saw TabAtkins's.

Extra Item: Fallback for "ch"
-----------------------------

  TabAtkins: The ex unit says that if font metrics are impossible
             you can use a fallback, but ch doesn't have similar
             wording.
  TabAtkins: I just suggest we have similar wording that allows the
             fallback of 0.5em in the exact same cases.
  TabAtkins: Any objections?

  glazou: I saw ChrisL say he's okay
  glazou: Any other opinions? Objections?
  glazou: No one cares?
  <fantasai> seems fine to me
  <dbaron> I wouldn't want this fallback to happen too often, but it
           sounds ok
  glazou: No objections?

  SimonSapin: There was an IRC comment that said it would be easier
              to just register not support the ch unit.
  TabAtkins: That seems inconsistent with the ex unit.
  SimonSapin: I don't really have an opinion.
  TabAtkins: If it means a syntax error you won't know it's font
             stuff after parsing time. If it's something else you'll
             fail weird so it may as well be as close as possible.
  SimonSapin: Okay.
  glazou: Any obj?

  RESOLVED: Default for CH unit is 0.5EM

Add -x/-y longhands to background-* properties
----------------------------------------------

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0085.html
  TabAtkins: So several browsers, webkit blink have supported
             background-position-x/-y
  TabAtkins: There's been some debate on this but I believe the plan
             on record is that we're going to add both variants of
             names and have a mechanism to decide which.
  TabAtkins: That allows us to add both background-position and
             background-repeat -x-/y
  TabAtkins: So I think we should add because authors rely on it.
  TabAtkins: I think it gets odd with size, but we can make it work.
             I'm not sure if there are others that need to be split;
             position, size and repeat.

  dbaron: I'm definitely in favor of it for background-position, but
          I'd like to see data on who supports the others,
          especially size because of the difficulties with cover and
          contain.
  TabAtkins: I don't know if anyone does size, but webkit does
             repeat with some odd work arounds. I'm not sure if
             anyone else does, though.

  MaRakow: For IE we support it with the value of repeat-x and
           repeat-y.
  TabAtkins: They do background repeat property with those keywords?
  MaRakow: Right.
  MaRakow: We don't support the individual properties, just the one
           property with those values  .
  <gregwhitworth> Yeah I'm testing background-position-x and that
                  doesn't work in IE.
  <gregwhitworth> So webkit only.

  koji: I think that possibly fantasai or someone from Mozilla was
        especially opposed in the past.
  fantasai: It was largely because concerns about interactions with
            logical version of properties and if that's sorted, and
            I think it might be, than there's not reason not to.
  fantasai: It's a question of if this is compatible with start and
            end keywords.
  TabAtkins: Plan is to support background-position-inline and other
             features.

  koji: We had to use adjust position?
  TabAtkins: Right now position and repeat. Those are the two I'd
             like resolution on today.
  fantasai: I think dbaron wanted more data on repeat.
  fantasai: Let's just position now
  TabAtkins: He only asked who supported repeat.

  dbaron: So what are the values of repeat x/y?
  TabAtkins: yes/no/repeat and no-repeat
  dbaron: I'm okay with position and repeat.

  SimonSapin: I'd like a proposal on how we'll do logical directions.
  fantasai: I think this should be B&B 4 along with the logical
            keywords.
  TabAtkins: I don't want to delay to 4 since it's not real yet and
             both these properties have been supported for a long
             time.
  TabAtkins: Position definitely can get into 3's CR and repeat
             could likely too.
  dbaron: I'd rather not add to 3. We've done it too much.
  krit: So if we do it in 3 it should be in version CSS Masking 1 as
        well?
  fantasai: I think we should do this in 4 and people can support
            earlier.
  fantasai: -x and -y have been around for a long time.
  fantasai: We have a legacy prefix and clause.

  TabAtkins: So add background position and background repeat -x/-y?
  Bert: The reason to have these in the past was to quickly switch
        background but now that we're using media fragments, do we
        still need it?
  * fantasai glazou, I have a follow-up to Bert's point

  TabAtkins: No one supports media fragments yet.
  dbaron: Gecko supports it.
  <dbaron> ... or we're very close to it
  TabAtkins: They're used commonly.
  glazou: dbaron did you say Gecko supports?
  dbaron: I'm not sure. We're close.

  sgalineau: It'll be a while before people can depend on it.
  fantasai: So one of the...this is different but related. In the
            images 4 draft we have a function that takes comma
            separated list, but no one supports it.
  fantasai: But there were various reasons to support. We marked
            comma separated as at-risk and I think we should drop
            that.

  krit: Webkit, it is mostly the test suite that's missing.
  TabAtkins: I can work on that now that I know it's a thing.
  fantasai: The test suite for what?
  TabAtkins: Image function.
  fantasai: I still think we should push commas to level 4 and
            figure out how it can interact.
  TabAtkins: Can we defer since that's tangential?
  fantasai: Yes.

  TabAtkins: So from before, are there objections to background-
             position and background-repeat -x/-y in Level 4?
  fantasai: I'm okay if we add logical keywords at the same time so
            we can make sure they work out correctly.
  TabAtkins: Sure.
  glazou: Sounds like a compromise
  krit: I would like to have a follow-up resolution.
  glazou: Okay.
  glazou: Any objection to setting -x/-y to background-position?

  bert: I don't think we should add properties that make things
        confusing for authors. They can use position already, so
        unless there is a really strong use case, don't add more
        redundant properties
  glazou: I think browsers are implementing the longhands.
  rossen: For the background-repeat we support repeat-x repeat-y
          because we thought of those as mutually exclusive. What
          would the both specify to repeat?
  TabAtkins: That's a longstanding part of background. Those values
             for position translate into longhand values.
  TabAtkins: Background-repeat-x becomes background-repeat-x-repeat.
  rossen: So when I spec that they both repeat, are you saying only
          one repeats?
  TabAtkins: That's the repeat value. It has four values, repeat on
             either end.
  Rossen_: Okay, than it's fine.
  glazou: So any objection?

  RESOLVED: background-position-x/-y, background-repeat-x/-y
            approved for level 4 of backgrounds and borders.

  krit: Should we also do this for masking level 1?
  TabAtkins: I'm fine either way.
  glazou: Is there a use case?
  TabAtkins: I don't know
  krit: There's prefixing so perhaps we need it for alignment
  krit: It can wait for masking 2

  <SimonSapin> background-repeat/position: also, resolved to add
               logical directions at the same time

Image Orientation for Backgrounds
---------------------------------

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0149.html
  glazou: This is something Boris posted.
  TabAtkins: I'd prefer for that to stay on list. Well, not talk
             syntax now, but we can discuss ideas.

  TabAtkins: Does anyone need refresher on the idea?
  [general consensus of yes]

  TabAtkins: If you're familiar with EXIF metadata, orientation can
             be whatever and some cameras will record that.
  TabAtkins: So later it can be displayed however you held your
             camera.
  TabAtkins: The web doesn't normally care, it just displays the
             same as in image. This would allow you to display how
             you took it.
  TabAtkins: Boris brought up where people were asking to auto-apply
             the rotation in the background. So the suggestion was
             to add this to the image function either as auto or as
             a keyword you can opt into.

  ChrisL: I think option 2 is better, first because some cameras get
          it wrong and second, because some viewers don't do it so
          people manually rotate.
  <gregwhitworth> Not to mention it's possibly creates a huge compat
                  issue
  dbaron: I actually disagree because in a vast majority of cases,
          they want EXIF to be honored.
  dbaron: If image always honors EXIF people will see it's wrong and
          fix it first so then when we build new things we should
          honor it.

  TabAtkins: If we do by default, should there be a way to turn it
             off?
  ChrisL: There's lots of content such as JPEG where it is not
          honored. So we'd change existing webpages.
  dbaron: We're not changing existing webpages because it's only if
          people use this new feature.
  ChrisL: That's what I mean by opt-in.
  dbaron: We want to say all the features of this new thing rotate.
  <Bert> (url() continues to ignore EXIF, but image() honors it.
         Subtle, but might just work...)
  glazou: So the conclusion is this is a feature we want and want to
          continue technical discussion on the ML?
  TabAtkins: We may have resolved. I'm okay if image() should always
             respect EXIF metadata.
  * ChrisL yay go for a resolution
  ???[attributed to dbaron]: That's fine
  <dbaron> that wasn't actually me, but I'm also fine with it
  Bert: I think that's okay, given that we don't have tests for it
        yet, anyway.
  florian: As long as it's contained to image() it's fine.

  RESOLVED: Make the image() function always respect EXIF
            orientation metadata.

  <sylvaing_> always or will we ever want an override in image()

  fantasai: On that topic can we have the image() function drop
            comma separation and decide if we want that level 4?
  TabAtkins: I'm cool with that. I'd like fallback to
             interoperability better so let's do that.
  krit: Wait, then you can't extend image later and attach
        mediaquery-like features like adding images.
  krit: You can't do that later without commas.
  TabAtkins: We're not removing commas, just the list feature. We're
             recasting image() as a better url for images.

  <fantasai> http://www.w3.org/TR/2012/CR-css3-images-20120417/#image-fallbacks
  fantasai: We're dropping this feature (above), but keeping image
            fragments and solid color images
  krit: But not comma separated values, just one value, one string.
  krit: That's a big step. Wasn't image supposed to allow fallback
        features?
  fantasai: That's the intent, but we want to address it in level 4.
  fantasai: You may want to change which image due to supported,
            size of screen, and visibility and there's no coherent
            solution.
  fantasai: Since we have those requirements when we designed
            fallback, we want to come up with a solution that makes
            it work together.
  fantasai: For now we know for sure we want EXIF metadata and solid
            color images to work as well as mediaqueries.
  fantasai: That's all straightforward and should stay in CR.

  krit: Do we need to rush this decision or can we stay on the ML?
  krit: You can get feedback so people that are interested can speak
  TabAtkins: Are you implementing?
  krit: No, I know there's a patch.
  krit: In general I don't feel confident resolving. Can we talk
        next week?

  sgalineau: Quick question, if you want to override you'd have to
             do it manually or is there override?
  TabAtkins: Right now you'd have to do URL, but I'm fine with a
             keyword.
  * fantasai override what?
  * fantasai missed that
  <SimonSapin> fantasai, EXIF orientation
  * sylvaing_ override EXIF i.e. if you need to do that, do you use
              url() or would we some day add a flag to image()
  * sylvaing_ was clarifying the resolution which said image() would
              *always* respect EXIF
  * fantasai ah, right. :) Yeah, i think just tossing in an <angle>
             into image() would do it
  * sylvaing_ fantasai, an angle, really? So I could set 31.7deg?
              there is a use-case for that?
  <BradK> sylvaing: I also question the use case for angle (
          something like [vertical | horizontal] seems better to me)
          but that's a separate topic.
  <sylvaing_> BradK: yes. my understanding is that there is at most
              4 angles here so <angle> seems odd
  * sylvaing_ actually, EXIF has 8 orientations but <angle> seems
              even odder here:
              http://www.impulseadventure.com/photo/exif-orientation.html
  * MaRakow sylvaing, agreed there doesn't seem to be a great use
            case for arbitrary angles, but seems difficult to put
            appropriate names on the orientations of an image where
            you don't really know which way is up
  <BradK> sylvaing: Spec has it rounding up to 90deg increments, but
          even so, seems to rely on knowledge of content of whatever
          page and image it is used on.
  <sylvaing_> MaRakow: my initial suggestion was to have a flag that
              says 'behave like url()'. Specifying an orientation is
              something else...
  * MaRakow ah, I see -- yeah, that sounds simpler
  <sylvaing_> MaRakow: yeah, the idea was there is a feature of
              image() you want to use but you want the EXIF metadata
              ignored. not sure it matters. we'll see...

  * krit TabAtkins just to make sure, it is not an existing patch
         for WebKit that makes me careful on changing image()
         without thinking about it more.

Changing MediaQueryList to use events
-------------------------------------

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0603.html

  TabAtkins: The thing returned by the match function has a custom
             fallback for when they stop matching.
  TabAtkins: The suggestion is to switch to using the event listener.
  TabAtkins: This is a very minor behavior change if you're
             depending on specifics on how events vs callbacks are
             registered.
  TabAtkins: I suspect that's rare.
  TabAtkins: The benefit is this makes us more standard event style
             and reduces special case code.
  TabAtkins: Boris said there's no code, but Elliott from Blink said
             there's a lot of extra code to do this in Firefox,
             Webkit and Blink
  TabAtkins: We'd like to drop and use standard event process.
  <dbaron> I don't know where this extra code in Firefox is.

  florian: If we're starting from scratch, sure, but this has been
           out.
  TabAtkins: You can move cleanly to the event-base except for a few
             edge cases that are difficult anyway.
  TabAtkins: Only change is timing and, if you register the same
             function multiple times, if it gets called once or twice
  florian: If it's that tiny, why is it so much code?
  TabAtkins: Because it's re-implementation a portion of what we do
             for events.
  TabAtkins: With events we just do a few lines of hookup code which
             works.

  TabAtkins: From the thread I don't believe there were strong
             objections. Boris had minor objections because he said
             it was easy in code, but Elliott pointed out it wasn't.
  TabAtkins: Are there objections now?

  dbaron: What are the rules?
  TabAtkins: I don't know if current spec defines them, but event
             spec does.
  dbaron: What does event spec define as?
  TabAtkins: I don't know.
  dbaron: I'd like to know before I agree.

  dbaron: I want any added listeners to not effect...Like if you add
          a new listener in the middle I want the event not to fire.
  TabAtkins: Is that specific to mediaquery, or is this in general?
  dbaron: I don't know.
  dbaron: Part of the problem is you can fire the event on multiple
          listeners so multiple MQ change as a result of same thing.
          Event spec will define a single event, but not multiple.
  TabAtkins: That's because it would be multiple callbacks.
  dbaron: What we have to define is that a single thing causes
          multiple things to change. The MQ change adds an event to
          another event that changed and does that event happen if
          it's fired later?
  TabAtkins: It seems like you just want this to be well defined in
             general, not just in this case.
  dbaron: I think the problem is if we make the change we'd have to
          define order. If you can define listeners that fire within
          each other it matters what order they happen.
  TabAtkins: And I think the callbacks don't handle order
  dbaron: But the callbacks don't effect each other, at least not in
          Gecko.
  florian: Is that gecko specific? Because unless it's in spec we
           have the same problem.
  dbaron: So I guess I'm okay with it.
  TabAtkins: I'll post to the thread to make sure we get some
             discussion about that.
  glazou: Okay. So discussion continues on ML

Scrollbar Tracking Control
--------------------------

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0112.html

  TabAtkins: This is an issue that I've been trying to bring up for
             a year.
  TabAtkins: It would be convenient if CSS could declare that a
             scrollbar in an element, once it's close to the bottom,
             attaches to the bottom
  TabAtkins: This is common in chat windows and things were you
             continually add content to the bottom of the list.
  TabAtkins: It's quite hard to get this to work well. Gmail has a
             constant fight with the chat windows; getting them to
             stick when the height can change unpredictably.
  TabAtkins: So have something where if a user scrolls a certain
             distance from the bottom it stays.

  florian: Do we need a distance or can we say distance zero?
  dbaron: I was trying to find my objections and I think I've found
          them.
  <dbaron> http://lists.w3.org/Archives/Public/www-style/2012Dec/0077.html
  dbaron: I think my biggest one is that I think it's not
          particularly related to distance from the edge.
  dbaron: It's more to which end the content should stick to no
          matter where you are relative to the edge.
  dbaron: There's cases where people will add to the top and you
          want to maintain scroll relative to top such as with
          twitter.
  dbaron: So you want to hold scroll close to bottom.
  TabAtkins: Twitter adds content on both sides. So that would be if
            you're sufficiently far from the content added so you
            adjust your scroll so the content doesn't move.

  florian: So you may not want to maintain because if you scroll up
           to read more, you want to stay there unless you're at the
           bottom.
  florian: I think I'm with TabAtkins, but with that user case.
  TabAtkins: I think that's interesting and useful, but different.
             I'd be willing to look into it.
  <BradK> When you are at the bottom of twitter, you do NOT want to
          stay at the bottom when new content is added to the bottom.
          You want to stay on the tweet you are on.

  dbaron: But I think what I'm objecting to is that it should be two
          properties, not one.
  TabAtkins: Can you elaborate?
  dbaron: It's too long ago.
  TabAtkins: Maybe it was semantic, where it should be about any
             edge?
  TabAtkins: That way you could add to either side and it would
             stick?
  TabAtkins: Is this something you'd like to discuss on thread?
  dbaron: One this was which end the content was coming from and the
          other was how different you are from the edge.
  florian: I'm not sure that would work in twitter. Content can add
           from both sides.
  TabAtkins: If you're willing to discuss on the list, that's okay.
             I've brought it up and got crickets and I want to make
             progress.
  dbaron: You should go ahead ... I don't have time to discuss it.

  florian: If we get snapping to scroll would that fix it?
  TabAtkins: Current proposal is that the user agent defines. There
             may be cases where you want to say exactly how far you
             are from edge.
  florian: Where would you want to not be at the edge?
  TabAtkins: For example, when I use IRC cloud it does only at edge
             and it messes up because you can't scroll through the
             edge. I'm not sure where the bug is, but you can be 2px
             from the edge and can't get all down.
  * sylvaing_ hasn't noticed that in Aurora fwiw.
  * sylvaing_ uses IRCCloud.
  * krit sylvaing_ me neither in Safari
  * sylvaing_ agrees; hasn't seen it in Safari either

  florian: But if you do scroll snapping, you can do it.
  MaRakow: I think if you have multiple snap points and the content
           changes enough you may snap to a point that's further
           away and snap to the middle. But that would happen here
           too if you can define multiple.
  TabAtkins: This is just top, bottom, left, or right. And if you
             define distance from edge you stay the same distance.
  MaRakow: So this is on the scroller?
  MaRakow: So when you're resizing and want to keep your content it
           would be off?
  TabAtkins: That's part encompassed by twitter case, but it's
            beyond what I'm asking for. It's interesting, but
            doesn't tie in.
  florian: Your 2px thing sounds like a bug not a use case.
  TabAtkins: Could be, but sometimes I don't scroll all the way down
             and it doesn't recover.
  * sylvaing_ thinks we should establish that this is a reproducible
              cross-browser issue that derives from CSS
  * sylvaing_ specifically, some simple repro of the Gmail chat
              logic may help here...

  florian: If you scroll close the the edge but not quite with this
           new prop, the person that designed the thing with
           incorporate scroll snapping, take you to the edge, and
           have you stick there.
  MaRakow: Also, I feel like this is similar to the use case for
           keeping the same content in view while resizing
           responsive web pages.
 <dbaron> I think this design isn't great for extending to say
          whether it's distance-from-top or distance-from-bottom
          that you want to hold constant when the current scroll
          position is in the middle

  TabAtkins: I don't think this links to snapping. Because having
             something that moves you all the way is sometimes
             useful, sometimes annoying.
  TabAtkins: They work well together, but shouldn't be tied together
             explicitly.

  glazou: So any objections to continuing discussion in email and,
          once stable, TabAtkins requests an ED?
  glazou: I think this is interesting and want to see a proposal.
  TabAtkins: The proposal is in the e-mails, but we can discuss.
  glazou: I'm going to contribute too. Let me think about it.
  TabAtkins: Contribution is what I need

  RESOLVED: Discussion continues over e-mail

  glazou: Any remaining items that can be done in 4 minutes?

Subgrid
-------

  fantasai: There was no discussion on ML
  TabAtkins: Yeah, not in 4 minutes
  glazou: Okay
  TabAtkins: I think the pow operator?

calc() pow operator
------------------

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0057.html

  TabAtkins: So it was suggested to add pow operator to calc().
             There's a unit as the base on one side and the exponent
             on the other.
  TabAtkins: Seems reasonable and no odd problems as long as we keep
             the exponent non-negative.
  TabAtkins: Only issues is precedence. You'd have to use
             parenthesis for anything more than a single number.
  TabAtkins: Presumably this is only when both are unit-less
  TabAtkins: Given that we're not using unit algorithm both things
             need to be a number, but you can multi by 1px to
             convert to px.

  fantasai: I missed the use case
  glazou: Me too.
  glazou: I wonder if it's worth the implementation. Of course the
          browser vendors get final word.
  TabAtkins: The use case was in the link. It's for mathematically
             pleasing things.
  * dauwhe I'm skeptical about the use case

  glazou: I have no real opinion. I think we can, but don't see the
          interest.
  TabAtkins: It's low value, but simple and does have cases.
  glazou: If we follow that path we'll need sin/cos etc. because
          that's what we do with complex animations.
  glazou: I'm not sure if we want CSS to have a full calculator.
  TabAtkins: I'm not sure it's slippery slope, but I can understand
             it's not important enough.
  fantasai: I think we don't have to address this. We can do
            variables now so you can do variable constants. This can
            be a preprocessor.

  SimonSapin: Did I miss the use case?
  TabAtkins: It's the link in the agenda.

  glazou: I'm not hearing consensus. I think consensus is we can do
          this in the future, but it's not high priority.
  sylvaing_: I think the common opinion is we're unsure what it is
             for.

  glazou: So I think we won't resolve for the time being.
  glazou: So we're 2 minutes past the hour. The two remaining items
          will be for next week. Talk to you next week!
Received on Thursday, 17 April 2014 00:42:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 17 April 2014 00:42:20 UTC