- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 30 Jan 2013 21:46:49 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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 ======
Present:
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
Administrative
--------------
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
instead.
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