- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 19 Jul 2013 15:17:53 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Lea Verou as CSSWG Invited Expert
- Discussed editorship of CSS3 Positioning and 'position: sticky' edits
- Discussed renaming/dropping 'default', requirements for 'all' shorthand.
- Discussed adding feature for dense-packed grid-auto-flow
- Discussed interaction of background-clip and 'background-attachment: local'
- Discussed "Applies to" of shape-outside and allowing exclusions
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Shezan Baig
David Baron
Bert Bos
Elika Etemad
Daniel Glazman
Koji Ishii
Chris Lilley
Peter Linss
Anton Prowse
Matt Rakow
Florian Rivoal
Simon Sapin
Leif Arne Storset
Nick Van den Bleeken
Lea Verou
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2013/07/17-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jul/0425.html
Scribe: antonp
Administrative
--------------
Rossen: A css-shapes issue I wanted to add, medium priority
Topic: Invited expert
plinss: Lea will be leaving W3C, want to bring her back into the WG as an Invited Expert
<ChrisL> +1
<Bert> +1
<Zakim> + +1.212.318.aadd
<smfr> +1
<dbaron> +1
<florian> Florian: +1
<leaverou> :D
<SimonSapin> +1
<fantasai> +1
<ChrisL> wb lea
<leaverou> thank you all so much!!!
<Rossen> ++
RESOLVED: Lea is back!!
Topic: Paris F2F
glazou: Dates etc? Please could Mozilla comment
dbaron: OK
Positioned Layout Status
------------------------
arronei: I'm still around ;-) Paying attention but also working on
other things
arronei: In a F2F about a year ago, we agreed to add Ted as an Editor,
but I haven't seen any updates
arronei: I'd prefer another editor to help me out
arronei: This spec isn't going to be a priority for me
Rossen: The spec only has a couple of issues; can't we try to push it
out of the door
Rossen: It contains a load of css21 stuff, plus a couple of other things
worth reviewing and possibly moving to LC.
Rossen: Are you guys (smfr) still gonna work on position:sticky?
smfr: Yeah we're interested in that area, but not sure we'll be involved
in speccing
smfr: ...
dbaron: He's an intern, will be around for a couple of months
Rossen: Sounds like there's interest in Sticky, but not interest in the
positioning spec!
...: if somebody provides content, we can get it into the positioning spec
fantasai: propose that spec = css21 + sticky
Rossen: That's pretty much what it already is
fantasai: Tab and I could help out on the spec after the summer, maybe
Rossen: Let's take up the Sticky conversation on the mailing list
dbaron: sounds good
CSS Cascade
-----------
http://lists.w3.org/Archives/Public/www-style/2013Jul/0021.html
fantasai: 'default' keyword doesn't have a good use case
fantasai: Places where it could help have other solutions possible
<glazou> +1 on the confusing name...
fantasai: Even if we go with the proposed "initial or inherit" definition
of 'default', the word 'default' is a confusing name
fantasai: Doesn't behave as one would expect.
fantasai: Also, default style in CSSOM doesn't refer to "initial or inherit",
it refers to something else, so again confusing.
fantasai: So first proposal is drop 'default
fantasai: Second is have a value meaning 'initial-or-inherit'
florian: let's wait for use case before creating the keyword!
ChrisL: name sounds reasonable for what it is
<leaverou> florian++
...: What authors really want is a way of saying "I wish I'd never
set these rules" - and we don't have that
dbaron: the use case is a low-level thing. Sometimes amount to explaining
how existing things work
dbaron: authors like reset stylesheets
dbaron: We introduced 'all' property, which only makes sense with this value.
I think if we drop this we should drop 'all'.
Glenn: TTML uses: default is a generic font family name, so uses it
as a keyword effectively
fantasai: CSS spec reserves 'default'. TTML using it that way wasn't
such a good idea
<glenn> btw, 'default' wasn't a reserved keyword in CSS2 (1998) which
was what TTML originally referenced
florian: Calling it undeclare/reset avoids the issues we've been raising
Rossen: "reset" is weird
<Rossen> width: reset; - this is a bit weird
<Bert> q+ to say it seems 'all' is only useful with 'inherit-or-initial'
and vice-versa. That suggests 'all' is maybe not a property at all.
fantasai: Use case: the 'all' shorthand
fantasai: that's the use case that makes most sense
Rossen: Sounds like an infrequent use case. The longer "inherit-or-initial"
is more descriptive
florian: It's a little ambiguous to me
florian: If you know cascade well, it might be obvious. Otherwise,
you don't know what it's going to do!
florian: Hence prefer undeclared
Bert: Agreed that use case is 'all' property
Bert: so maybe think of that case as something other than a property,
e.g. an @-rule
Bert: Only useful with !important added, else you don't reset everything??
<fantasai> I guess, 'reset' for 'initial-or-inherit' and 'unset' for
'default', both useful for 'all'
<Rossen> width: unset
antonp: I quite like 'unset'
Rossen: +1
fantasai: 'reset' is good for 'initial-or-inherit' I guess
Rossen: when you say "width:reset" it sounds like a layout instruction
rather than a cascade instruction
Rossen: 'unset' doesn't suffer from that.
florian: +1 for unset
<leaverou> the good thing about all is that people already know it from
transition-property
leaverou: Is 'unset' going to be a property?
fantasai: no, a value
ChrisL: Is it allowed on shorthands, and is it fully specified?
<fantasai> http://dev.w3.org/csswg/css-cascade/#inherit-initial
fantasai: yes
fantasai: One concern: "all" shorthand, you might actually want the behavior
that's currently specified for 'default'
fantasai: you might want to say "Blow everything away but leave UA stylesheet
intact"
dbaron: That's sort of what you have with the new version of 'default'
fantasai: yes, exactly
fantasai: that's the only use case I can think of for 'default' that
isn't handled well at the moment
<dbaron> original proposal:
https://lists.w3.org/Archives/Member/w3c-css-wg/2002OctDec/0191.html
florian: Does "default" only leave UA and User stylesheets, or does it
remove either/or of those?
fantasai: It removes whichever stylesheet (user/author) you're in
fantasai: Dunno, maybe it's not needed
fantasai: I haven't quite fully thought through
dbaron: Concern about fiddling with the name: we've had it on the table
for over 10 years and made it a reserved keyword in a bunch of
places
<dbaron> s/lots of/a bunch of/
florian: we wouldn't be the first group to do that ;-)
glazou: nor the first time the group has spent 10 years not doing
something ;-)
dbaron: Though if the name is obscure enough, we'd probably be okay.
florian: I think "unset" is clear; I don't expect many fonts to be
called that
glazou: Will implementors implement it in the timeframe of PR?
fantasai: initial-or-inherit behavior will be very straightforward
dbaron: +1; an hour's work
Bert: I don't think that's the right argument. Rather, how useful is this?
fantasai: "all" shorthand is the most important use case
<dbaron> I would object to dropping this value without dropping the
'all' shorthand as well.
fantasai; The only value which makes sense for "all" is "initial" and this.
(inherit is useless)
dbaron: I don't think 'all: inherit' is useless in the presence of things
like 'display: contents'.
fantasai: OK, /almost/ never useful ;-)
dbaron: <explains>
fantasai: as dbaron says, you need this value or something like it in
order for "all" shorthand to be useful
* leaverou wonders if all: initial sets all properties to their initial
values, what's all’s initial value?
<fantasai> it's a shorthand, doesn't have one
<leaverou> fantasai: ah, right, thanks
Bert: why does a property only have one useful value?
fantasai: either don't set, or set it to initial which breaks inheritance,
or you set it to this value which allows inherited properties
to inherit
Bert: dbaron's example: same as setting "all" to new keyword, it seems to me
dbaron: That might be true if it has exactly one child, but a bit different
if more than one
Bert: Setting on element, 'display' value gets reset (becomes inline)
dbaron: I think that's not true in flexbox, grid
Bert: should be in grid. Flexbox might be strange
florian: We seemed to like "unset"
florian: as a new name for "initial-or-inherit"
Bert: I think the name is fine, but I question the need for that value
plinss: Do we drop "default"?
fantasai: Proposal is to remove "default" and change the name of
"initial-or-inherit" to "unset"
fantasai: Taking the proposal in full, for "all" you don't have the
option of saying "blow away my styles but leave UA styles intact"
florian: In any case, you still have the !important playing around, right?
florian: so using that property in an author stylesheet would still leave
!important user styles in place
fantasai: correct
fantasai: I'd like another week to think about this
plinss: so revisit next week?
fantasai: OK.
Grid Layout
-----------
Topic: Grid auto-flow followup
plinss: we had a resolution, Tab had a follow-up comment
<Tab is on holiday>
<plinss> http://lists.w3.org/Archives/Public/www-style/2013Jul/0223.html
plinss: e-mail about switch for dense vs sparse packing
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jul/0226.html
<fantasai> propose to use tight or dense keyword (optional) in grid-auto-flow,
if we want this
Rossen: Based on their implementation, they've implemented 'dense' or
are going to?
fantasai: They've implemented dense packing for grid-auto-flow
Rossen: Having a switch shouldn't be a problem if the default is sparse
fantasai: yeah
fantasai: And we can mark it at risk
Rossen: I agree
dbaron: Do we actually want this switch?
Rossen: I'm not sure *we* do. In fact we don't want to implement dense
because we haven't heard any demand
Rossen: If chrome is implementing it I'm guessing they have use case
Rossen: Currently we're not interested in dense
plinss: anybody else implementing this?
<silence>
plinss: OK so we add it at risk
Rossen: Now, or we wait for Tab to make a case for it on the call?
Rossen: I'm with dbaron: I want to hear a case, not introduce it and
then remove it down the line
plinss: OK, defer until Tab comes back
fantasai: are people happy with proposed syntax if we /do/ add it?
<various agreement>
plinss: Noted that we like the syntax.
CSS3 Backgrounds
----------------
Topic: css-backgrounds] Painting area and 'background-attachment: local'
SimonSapin: Two parts in the proposal to discuss separately
http://lists.w3.org/Archives/Public/www-style/2013Jun/0276.html
SimonSapin: <explains issue>
* smfr would love to see some pictures
ACTION: fantasai add diagrams to this section
<trackbot> Created ACTION-568
Rossen: So is the summary, "scroll the clip the same way that you want
to scroll the background, given that it's local"
SimonSapin: yes
<SimonSapin> https://test.csswg.org/shepherd/testcase/attachment-local-clipping-color-6/spec/css-backgrounds-3/
SimonSapin: I have some test cases
<SimonSapin> https://test.csswg.org/shepherd/reference/attachment-local-clipping-color-6-ref/spec/css-backgrounds-3/
SimonSapin: <explains>
SimonSapin: It's the same argument as the recent change for background-origin,
i.e. consistency
Rossen: In your ref, the clip will /not/ apply in this case?
SimonSapin: What do you mean?
<Rossen>
https://test.csswg.org/shepherd/repository/49f0d56a1c4a98ee4fec497c29412d89179fc012/contributors/mozilla/submitted/css3-background/background-attachment-local/attachment-local-clipping-color-6.html
Rossen: Is this the test case you were referring to?
SimonSapin: yes
Rossen: this one has a clipped circle
SimonSapin: yes, there's overflow hidden
SimonSapin: Background-attachment: clip only has an impact when overflow
is other that visible
SimonSapin: In this case when you scroll, the white part at the top scrolls
away because it's part of the scrolled content.
Rossen: You propose we scroll the clipped circle as well?
SimonSapin: yes, that's the second part of my proposal
fantasai: How about I make some spec edits for this, and then we review
them and see if they make sense?
SimonSapin: Works for me
Rossen: So we're not accepting anything until we have the edit
SimonSapin: Second part of proposal: overflow:hidden and attach background
local, makes sense that background should be clipped
SimonSapin: <explains>
SimonSapin: Should behave just like it was set on another element inside
the overflow:hidden element, which is indeed how the ref was built
smfr: I'm confused; we don't have any spec text which describes how rounded
corners affect the appearance of backgrounds
fantasai: yeah we do
<fantasai> http://www.w3.org/TR/css3-background/#corner-clipping
SimonSapin: I used rounded corners to make the test more obvious, but
they're not necessary. If you have a border which isn't
completely opaque
dbaron: You seem to be asking to switch an optional behaviour to a required
behaviour
SimonSapin: It should have something that implies the same but for a
different reason
SimonSapin: It's more complicated with rounded corners; you really want
two clips.
fantasai: I'm gonna edit the spec, and your issue is whether or not the
background is allowed to paint into the border area or not.
Spec currently allows it, some imps do it. You're proposing
it not be allowed
fantasai: I don't really have an opinion
fantasai: It's a bit odd to have things outside of the scrollbar but
scroll with the scrollbar
<fantasai> but doable, has been done
SimonSapin: What is attached to the contents should be clipped with the
contents. Everything is derived from that.
Rossen: That will break a bunch of optimizations that people may have
done for scrolling
Rossen: so it might not get much traction
Rossen: For clipping and layering, inside of the scrollbar, for example,
there may be optimizations when repainting
Rossen: If you allow to scroll outside, the optimizations are no longer valid
SimonSapin: don't you have the same problem with background-attachmnet:local,
even without my proposal?
fantasai: I think everyone is confused. Let's wait for the spec edits
and then open an issue about whether the behaviour should be
optional or required
Bert: shouldn't it be to make the optional behaviour forbidden?
fantasai: You're allowed to do two things. Proposal is that only one
should be allowed
Bert: not sure
plinss: ETA of edits, fantasai?
fantasai: I'll ping you when ready
<SimonSapin> https://test.csswg.org/shepherd/search/testcase/spec/css-backgrounds-3/load/t120/ attachment-* test
SimonSapin: ^ more tests, may help
SimonSapin: reftests. These are what *I think* should happen
Shapes
------
Rossen: applicability of shapes
<Rossen> http://lists.w3.org/Archives/Public/www-style/2013Jul/0286.html
Rossen: Alan made a couple of edits in the last round of edits for css-shapes
Rossen: he restricted the applicability of what shape-outside is allowed
to apply to, and he made it apply to floats only
Rossen: The restriction at the moment looks very artificial
Rossen: He seems to agree with that, and said that he didn't want to take
a normative reference to the exclusions spec. He didn't want the
specs tied.
Rossen: But I don't see why the restriction should be to floats and not
include block-level block
Rossen: if it applied to block-level block and implemented exclusions,
can benefit
dbaron: Say in the shapes spec applies to float
dbaron: and then say in the exclusions spec that that spec makes shapes
apply to more things
dbaron: I think that's perfectly reasonable in this set. Shapes without
exclusions doesn't make sense for it to apply to anything other
than floats
Rossen: Sure, and visually there will be no effect
Rossen: If you apply a shape to a non-exclusion, nothing will be visually
different
Rossen: If you want to see the effect, you have to apply it to exclusions
Rossen: It applies to block-level blocks, and if it happens to be an
exclusion you'll see an effect
dbaron: But the thing only applies to floats or exclusions!
szilles: are you arguing over the difference between "Applies to" and
"affects"?
dbaron: we often try to write the "Applies to" line in that way
Bert: Applies To line should only apply to things that actually exist.
A note could say that the applicability can be extended later
Bert: It's common to comment that things are expected to have wider
applicability in the future
Rossen: as long as we're not excluding exclusions from applicability,
I can live with that
dbaron: IIUC then I'm ok with that
<stearns> (just got out of my other meeting)
<stearns> Bert: the shapes draft does have a note mentioning that shapes
will be extended later to exclusions.
====== Appendix A: Pre-telecon IRC snippet ======
<SimonSapin> do we have "fuzzy reftests" where up to some number of different
pixels is acceptable?
<Ms2ger> Nope
<SimonSapin> :/
<SimonSapin> Should I add new tests in incoming or a submitted?
<SimonSapin> http://wiki.csswg.org/test/css2.1/contribute says submitted
<stearns> SimonSapin: incoming is your scratch space. submitted is for
tests you think are ready
<SimonSapin> stearns: I have reftests passing in Gecko. I think they’re
ready but I haven’t really been reviewed
<stearns> SimonSapin: submitted, then
<SimonSapin> they also test details that are not in the spec yet, some of
of which don’t have a WG resolution yet
<fantasai> SimonSapin: submitted is probably fine. Put the issues on the
WG agenda
<SimonSapin> "Painting area and 'background-attachment: local'" is already
on the agenda for today
<fantasai> didn't we figure it out already?
* fantasai just hasn't made the edits
<SimonSapin> fantasai: positioning yes
<SimonSapin> painting/clipping, there are two parts
<SimonSapin> I think we have consensus that values of background-clip should
represent the same rectangles as background-origin, ie. scroll
with the content. (No WG resolution yet)
<fantasai> I'm happy to say it's implied from the previous resolution.
Doesn't make sense otherwise...
<SimonSapin> But I also proposed that if a background layer is attached to
the scrolled content, it should be clipped like the scrolled
content because of 'overflow'
<SimonSapin> … and thus not paint below the border
<SimonSapin> fantasai, see https://test.csswg.org/shepherd/testcase/attachment-local-clipping-color-6/spec/css-backgrounds-3/
and its ref
Received on Friday, 19 July 2013 22:18:23 UTC