[CSSWG] Minutes Telecon 2013-07-19

   - 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 ======

   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


   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

   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
   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
   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:
   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
   <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?
   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
   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: 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
   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


   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
   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
   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