[CSSWG] Minutes Telecon 2013-01-30


   - RESOLVED: viewport units in case of 'overflow:auto' are sized as if
               scrollbar is *not* present (even if they are)
   - Discussed status of CSS3 Box module
   - RESOLVED: keep compositing/blending of backgrounds the compositing spec for now.
   - Discussed WebKit's 'overflow: overlay' value. No consensus to add it;
     see minutes for background and rationale.
   - RESOLVED: non-ascii starts at 0x80
   - Discussed some other css3-syntax differences from CSS2.1.
   - RESOLVED: allow @page selectors to be comma-separated lists

====== Full minutes below ======

   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   David Baron
   Bert Bos
   Rik Cabanier
   Tantek «elik
   Arron Eicholz (via IRC)
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Rebecca Hauck
   Brad Kemper
   Peter Linss
   Alexis Menard
   Ted O'Connor
   Anton Prowse (via IRC)
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Nick Van den Bleeken (Inventive Designers)
   Lea Verou

<RRSAgent> logging to http://www.w3.org/2013/01/30-css-irc
Scribe: Bert
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jan/0557.html


   Topic: Welcome Nick
   Nick will not be at the ftf.

   Topic: Agenda F2F
   plinss: Please add topics to wiki
   plinss: Any questions, issues about ftf?

Viewport Units

   <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jan/0312.html
   fantasai: Seems a growing consensus on www-style.
   fantasai: Seems like many uses of viewport units try to fit things in
             viewport and don't want scroll, except as a fallback in case
             things really don't fit.
   fantasai: So suggestion is that 'overflow: auto' measures viewport like
             'overflow: hidden'.
   fantasai: If you *do* expect to scroll, and want viewport units to size
             accordingly, workaround is using 'overflow: scroll'.
   fantasai: Alternative is to treat 'auto' like 'scroll'. But then workaround
             for that, in case you want to size without scrollbars, is
             'overflow: hidden': which has side effect of clipping in cases
             where things *do* overflow. This seems worse.
   ??: I agree with that
   Rossen: Me too.
   plinss: Objections?
   RESOLVED: viewport units in case of 'overflow:auto' are sized as if
             scrollbar is *not* present (even if they are)

   dbaron: Worth saying something about overflow:scroll;
   <fantasai> In case of 'overflow: scroll', scrollbars are accounted for
              in calculating viewport units
   <fantasai> (so that 100vh/100vw will not cause scrolling, just disabled
              scrollbars )

   plinss: You mean horizontal scrolling?
   SimonSapin: with 100vh, will get overflow?
   rossen: with 100.1vh you will have scrollbars.
   <SimonSapin> 100vw + lots of content vertically to trigger a vertical scrollbar
   <SimonSapin> => horizontal scroll by the width of the scrollbar?
   [discussion of overflow-x/overflow-y]
   plinss: Any objection now, after this explanation?
   plinss: When there is overflow:auto the units will be as if there is no
           scrollbar, but with 'overflow: scroll' the units *will* deduct
           the scrollbar.
   <SimonSapin> ok, `overflow-y: scroll` would take care of my use case

   <sylvaing> could we have width:100% and width:100vw be different?
              Does that matter?
   <SimonSapin> I think itís possible with `overflow: auto` on the root
   <sylvaing> SimonSapin, right. Just stating it looks like it could happen.
             I'm not sure it's a problem though.

Box Module

   plinss: Question was if we want to update the WD.
   bert: what was the discussion last week?
   plinss: No resolution last week.
   Bert: Would like a new WD soon, because current is very old. Most issues
         listed in draft.
   Bert: On the other hand the order of sections in the draft is in flux.
         It's chaos atm
   Bert: Would like a few weeks for the editors to make sure that it is at
         least readable, I'm not sure that's the case at the moment
   Bert: Started to look if all the issues were there. E.g. noticed some
         were mentioned 3 times
   Bert: With a few days of work, could me much nicer draft than now.
         Not opposed to publishing now, but would be more readable with
         some time to clean it up a bit.
   fantasai: I think we should defer to the editor (Bert) and let him
             decide when it's ready to republish.
   Bert: Maybe one week after F2F?
   plinss: Ok, we'll return to this later.

Compositing Background Images

   <cabanier> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#cssbackgroundsyntax
   cabanier: Q is if this is usful feature to pursue.
   cabanier: It really belongs in BG & Borders.
   cabanier: It is kind of hard in the Compositing spec.
   TabAtkins: Good idea, the visual effect. I can't say what the imple cost is.
   TabAtkins: Putting it in background4 spec may may make spec.
   cabanier: Yes, then can put it in shorthand.
   TabAtkins: let it depend on which spec is faster.
   cabanier: Pretty simple in terms of implementation cost.

   plinss: Only multiple background images of a single element?
   cabanier: Yes.
   TabAtkins: Cool.
   plinss: But if we ever want compositing of backgrounds with other elements,
           syntax should not preclude that.
   cabanier: Yes, we can add something. or another property later.
   dbaron: Curious about use cases.
   TabAtkins: The use cases of compositing and blending in general.
   TabAtkins: I mght want to animate backgrounds together.
   cabanier: Some clouds, text that inherits what's behind it...
   cabanier: designers can tell you much better what they want with it.
   plinss: Objections?
   RESOLVED: keep it in the spec for now.

Overlay value for 'overflow'

   TabAtkins: Don't know where it came from, but it is in WebKit (unprefixed).
   smfr: A feature that is no longer part of our browser.
   smfr: Should have been prefixed. And we don't want to standardize it.
   TabAtkins: What are you opposed to?
   smfr: It is a user control, not an author control.
   * fantasai agrees with smfr
   dbaron: Agree with smfr
   <tantek> agree with Simon as well

   <sylvaing> We expose auto-hide overlay scrollbars in IE10/Win8 as an overflow-style
   <sylvaing> to the extent authors can MQ touch/mouse it may be interesting
              for them to pick a default as well

   TabAtkins: It's nice to avoid jumping text when it gets long.
   dbaron: And what if user has never seen an ovverlay scrollbar before?
   TabAtkins: It looks exactly like a normal scrollbar.
   rossen: Only present in case of interaction. User will understand when
           he sees it.
   TabAtkins: Chrome draws a normal scrollbar, it just overlaps. It looks
              weird anyway.
   TabAtkins: But another way would be perfect fine as well.
   rossen: If the platform decides to do it, then that's what you get.
   TabAtkins: Not a difficult problem for design.
   * sylvaing doesn't have a strong opinion except: this shouldn't be a
              value of the overflow property

   sylvaing: Do people do these scrollbars, e.g., with jQuery?
   TabAtkins: I don't know.
   smfr: We don't allow to style scrollbars, they look like traditonal
         scrollbars on Mac.
   smfr: If the user hovers near the edge, the scrollbar will appear.
         Authors should be able to know if such scrollbars are used,
         maybe a Media Query.

   fantasai: Wrt Tab's case of not jossling layout when it overflows,
             that's what 'overflow: scroll' is for.
   TabAtkins: People don't like scrollbars, so don 't use 'scroll'
   fantasai: Overlay scrollbars are great. All platforms should just use them.
             Let's solve this by waiting for that to happen.

   BradK: Maybe spec scrollbars that somehow don't obscure content.
   TabAtkins: Every platform that has overlay scrollbars has done something
              like that.
   [discussion of putting gutters for scrollbars into a design]
   <fantasai> wrt smfr's mq idea, mq should be for how wide the scrollbars are

   BradK: But overlay scrollbars are hidden. Maybe use a partial transparency
   TabAtkins: I get your point.
   smfr: [something about google site]
   * darktears smfr +1 these scrollbars are horrible

   <tantek> if scrollbars are ugly, why not just use overflow:hidden?
   <smfr> tantek: overflow:hidden prevents user scrolling
   <tantek> smfr - perhaps that's the answer then - overflow:hidden-scroll
   <tantek> hide the scrollbars, but allow scrolling
   <tantek> (native apps seem to do this)  <tantek> (which should be
            sufficient a use case to justify overflow:hidden-scroll )
   <sylvaing> tantek, this is what iOS and Win8 do. no scrollbar until
              you start moving around
   <tantek> (they don't even bother to show overlay scrollbars, they
            just show no scrolling UI, but allow touch scrolling)
   <fantasai> tantek, not sure what you mean. I don't have a scroll wheel,
              how exactly am I supposed to scroll a window without scrollbars?
   <tantek> sylvaing - I'm talking about native apps (e.g. iOS) which don't
            even show a scrollbars.
   <tantek> fantasai - touch, page up page down, etc. native apps do this
            today on mobile.
   <fantasai> tantek, that's not at all obvious, especially when it's a
              scroll view inside the page rather than the main viewport
   [fantasai does not have a touch screen]
   <tantek> fantasai - it doesn't work in all cases, just like not all
            color/bg combinations work in all cases
   <tantek> "not at all obvious" in some cases is never an argument against
            a style feature - that's a strawman.
   <fantasai> tantek, sorry, I don't think you are making any sense
   <tantek> Ö just as color/bg combinations do NOT work in all cases
   <tantek> fantasai - just because you can come up with a confusing
            example (strawman) doesn't negate the utility of a feature.
   * fantasai is not going to argue this point with you anymore

   plinss: General principle is also to not let authors change the
           fundamental UI of a platform.

Syntax Issues

   SimonSapin: q what is a non-ASCII character.
   TabAtkins_: No, that is the 1st character out of that range.
   TabAtkins: Yes, change it to 7F. Should not matter. Nobody uses 7F-9F
   dbaron: is nbsp inthe range?
   <oyvind> nbsp is a0

   dbaron: I'm ok with it; changing Firefox is relatively straightforward.
   bert: is this an errata for 2.1?
   TabAtkins: Yes, should be.
   RESOLVED: non-ascii starts at 0x80
   ACTION bert: add errata to 2.1 about non-ascii from 0x80

   TabAtkins: Some special characters are now allowed instead of undefined.
              So may have effect on parsers.

   <SimonSapin> TabAtkins, you actually use an "empty selector" in
                "parse a declaration block"
   <SimonSapin> though not that selector is not parsed
   TabAtkins: But another issue: 2.1 grammar allowed empty selector.
   TabAtkins: I disallowed that in 3.
   bert: What does "not allow it mean"?
   TabAtkins: It's either a syntax or a semantics error.
   TabAtkins: Should not affect any use in browsers.
   bert: then I say do it as it was: allow in the syntax, it just doesn't
         match anything.
   <SimonSapin> 2.1 allows it
   plinss: Seems reasonable to not disallow it.
   plinss: Maybe we want it in the OM and add a selector by script later.
   TabAtkins: Potentially.
   TabAtkins: Isn't selector readonly?
   SimonSapin: Empty selector problem doesn't show up in the OM.
   plinss: Just leave it open for the future.
   TabAtkins: Syntax error resynchs at closing '}'
   <oyvind> selectorText is read/write
   Tabatkins: (Well, tiny thing. Doesn't matter.)

   plinss: Other grammar issues?
   TabAtkins: Nothing that needs WG attention right now.

plinss: Other topics?

@page Selectors

   <SimonSapin> https://www.w3.org/Style/CSS/Tracker/issues/95
   <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2009Feb/0562.html
   SimonSapin: I'd like a feature in @page: multiple selectors with a comma.
   TabAtkins: That seems like it was an oversight... See no reason to disallow.
   plinss: Objections?
   RESOLVED: allow commas in @page selectors

Meeting closed.

Received on Thursday, 31 January 2013 05:47:19 UTC