[CSSWG] Minutes Telecon 2013-08-21


   - Status updates:
       - Counter Styles LC just received many comments, which will
         need to be processed before CR
       - Fonts CR transition discussions deferred to next week
       - Transitions and Animations waiting on edits
   - RESOLVED: Drag-and-drop pseudo-classes as :drop(active|valid|invalid)
   - Discussed whether to allow syntax like [rel=next,prev,up] in attribute
     selectors. No conclusions yet.
   - RESOLVED: Accept work on scroll-snapping properties, initially as a
               separate module, potentially folded into another one later.
   - RESOLVED: Shift CSS4 Color proposal to ED
   - Discussed behavior of 'outline' properties. Two use cases conflict:
     focus outlines (original intended use case), and "fake borders".

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

   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   Tantek Çelik (via IRC)
   David Baron
   Bert Bos
   Jason Erenkrantz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Rebecca Hauck
   Dael Jackson
   Philippe Le Hégaret
   Peter Linss
   Edward O'Connor
   Chris Palmer
   Anton Prowse
   Matt Rakow
   Florian Rivoal
   Simon Sapin
   Dirk Schulze
   Leif Arne Storset
   Nick Van den Bleeken

<RRSAgent> logging to http://www.w3.org/2013/08/21-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Aug/0388.html
Scribe: antonp

Status Updates

   TabAtkins: Counter Styles to CR: lots of issues have come up this week,
              so let's not discuss this yet.
   TabAtkins: Loop back next week

   plinss: Fonts CR transition will wait for John next week

   dbaron: Transitions and Animations are waiting on me to do a bunch of
           edits that I haven't had time to do.
   smfr: I haven't had time to look through test cases, next step will be
         to put together issues based on behaviour in those tests
   krit: I'm still working on tests
   plinss: Will they be ready for F2F?
   krit: unlikely.
   dbaron: 50/50 chance of getting my edits done for f2f
   plinss: Let's try to get this spec advancing

Selectors 4

   Topic: Drag and Drop
   <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2013Aug/0076.html
   TabAtkins: Great response to the survey; let's do this kind of thing again!
   <krit> TabAtkins++
   Results: http://lists.w3.org/Archives/Public/www-style/2013Aug/0265.html
   <plinss> https://docs.google.com/spreadsheet/ccc?key=0AmRB4Bq4bNRBdEw4TlU5cGNTNGQ1VHF4ZFFORTFoTkE&usp=sharing

   [...] One of the consistent themes: People like the repeated part of
         the name come first.
   florian: The functional notation is interesting if you plan to extend.
            Do you?
   TabAtkins: Useful part: combine multiple keywords inside of the functional
              notation, gains readability
   florian: All the suggestions look reasonable, err towards third.
   Bert: I prefer to avoid parenthesis, which makes things look like a
         formula / maths
   fantasai: we also have the option of doing pseudo-classes with parts
             reversed, which gets repeated part of the name to come first
   TabAtkins: if you put 'drop' first, it looks like a verb rather than
              a noun.  This makes it awkward to put it first if you
              just dash-separate the words
   fantasai: fair enough

   plinss: Any strong opinions, or we go to straw poll?
   [Discussion of valid and invalid]
   plinss: Need to define :drop() by itself, no arguments
   fantasai: Yeah, would mean all possible drops
   plinss: Do you want invalid + valid?
   fantasai: Most people won't care wrt valid/invalid, so simple case would
             be using active-drop and drop.
   fantasai: Distinguishing valid/invalid is more advanced.

   Poll: using the numbering in the e-mail
   <florian> everything acceptable, 3rd preferred
   <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2013Aug/0265.html
     1. :current-drop / :valid-drop / :invalid-drop
     2. :active-drop / :valid-drop / :invalid-drop
     3. :drop(active) / :drop(valid) / :drop(invalid)
   [above is a list of the options]
   <TabAtkins> 3
   <sgalineau> 3
   <fantasai> 2 or 3
   <smfr> 2
   <florian> 3,(no objection to the rest)
   <plinss> 3
   <Bert> 1 or 2
   <SimonSapin> 2 or 3
   <leif> 3 or 2
   antonp: 2
   <plh> 2
   <jerenkrantz> 3
   <hober> 2, 1
   <dbaron> 2 (or maybe just abstain)
   <dbaron> though we should also note that (1) won the poll
   <florian> to dbaron, yes but 2 wasn't in the poll, and is more similar
             to 1 than to any other option actually in the poll
   <leif> oops! I meant to vote for the poll winner as second choice,
          so my preference would be 3, with 1 as backup
   <SimonSapin> if picking one, s/2 or 3/3/
   <TabAtkins> #1 = 2 votes, #2 = 8 votes, #3 = 8 votes
   plinss: Is there anyone who can't live with 2 or 3?
   <Rossen> 3
   plinss: Let's call it 3 then, and move on
   RESOLVED: :drop(active|valid|invalid)
   <tantek> Happy to give into consensus here on bike shedding those UI

   Topic: Comma separated attribute value selectors
   <SimonSapin> do it
   TabAtkins: It's about adding comma-separated values to the attribute
              selectors, as syntactic sugar

   florian: Is there an issue with the comma as part of an attribute value?
   TabAtkins: comma is not part of an ident, if you want it you can use a string
   dbaron: I'm concerned about readability
   <TabAtkins> [foo=a,b,c] === [foo=a], [foo=b], [foo=c]
   Bert: Is it an AND or an OR?
   plinss: It's an OR.  Couldn't possibly be an AND.
   Bert: I think it adds complexity without adding functionality
   Bert: Use a preprocessor
    * sgalineau what I heard was 'if it's just usability we shouldn't do it'
   TabAtkins: Just because you can use a preprocessor, it doesn't mean that
              we should.  Puts a lot of overhead on

   Bert: e.g. Perl is easy to write, but hard to read.  It's about readability.
   <TabAtkins> https://dvcs.w3.org/hg/csswg/file/bb3efb2a3181/default.css#l171
   <TabAtkins> [data-link-type=property, propdesc, descriptor, value, function,
                               at-rule, selector, maybe]::before { ... }
   TabAtkins: In the link is an example
   Bert: commas are small, and are easy to miss
   Bert: I already have a problem with commas so I put clauses on separate lines
   TabAtkins: That's good practice anyway.

   Bert: The next thing you'll want to add is regular expressions! Bad direction
   TabAtkins: I don't like slippery slope arguments.  I'm not planning to add
   SimonSapin: Implementation-wise, it doesn't add much complexity if we
               already have 'matches'
   TabAtkins: It can sort of be the inverse of matches if you need to internally
   plinss: How will it serialize?
   TabAtkins: <replies>

   <sgalineau> straw poll?
   (+1 is for commas,  -1 is against)
   <fantasai> +1
   <florian> +1
   <Bert> -1
   <SimonSapin> +1
   <TabAtkins> +1
   <smfr> +1
   <sgalineau> +1
   <jerenkrantz> +1
   <dbaron> -1
   <hober> +0.75
   antonp: abstain

   <dbaron> p[class, id]
   <sgalineau> dbaron, do you mean [foo=1,bar=2]?
   dbaron: why does comma have lower precedence than equals sign?
           Attribute selectors can take 'attribute' or can take
           'attribute = value'.
   <dbaron> p[class=foo, id]
   <dbaron> p[class=foo, class=id]
   dbaron: the second example I typed is conceptually the same as the third
   fantasai: I don't see this as being a problem.  Commas are lower precedence
             than = in HTML (eg class=foo,bar - the value of class becomes
   fantasai: Having the same pattern in CSS makes sense to me
   plinss: I do see dbaron's point.

   plinss: Shouldn't we do this for all the other types of attribute
           selectors not just = ?
   TabAtkins: Yeah, it's not just for =
   plinss: p[class, id] is invalid?
   TabAtkins: yes

   * antonp likes this even less now, in the light of dbaron's comment
   * smfr likes this less now too
   <SimonSapin> I see the precedence argument as well
   TabAtkins: We could take this back and think about it some more
   <sgalineau> in favor of thinking about syntax more
   TabAtkins: Let's do that.
   plinss: OK, so not accepted for now, but you can raise it again later
           if you want.

   fantasai: Nothing else to discuss today, will bring more stuff later.
   <dbaron> I think I gave a list of things in selectors4 I'm still iffy
            on at the end (?) of last week's telecon.

Scroll Snapping

   <plinss> http://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html
   plinss: interesting comment from roc
   plinss: anyone interested?
   TabAtkins: I'm in favor and could be an editor on this
   smfr: I like it and would like to see it advanced
   Rossen: We're also interested I think
   plinss: OK, hearing strong support
   Rossen: have Matt Rakow with me, who's a member of the WG and our lead
           on this

   TabAtkins: Separate spec I'd prefer
   fantasai: It might fit in to UI
   fantasai: but let's start it as a separate spec
   TabAtkins: I think it's likely that this spec could grow
   plinss: sticky positioning?
   fantasai: No, that's positioning, not scrolling
   Bert: It's related to overflow isn't it?
   TabAtkins: This is about scrolling behaviour, not about all the other
              stuff surrounding overflow, so it makes sense to me to keep
              it separate
   Bert: It doesn't relate to marquee but all other modes are affected
   TabAtkins: Paged overflow isn't affected
   Bert: sure it is, in interactive paged media
   TabAtkins: No, I don't think so
   plinss: OK, let's start as a separate doc and fold it in to something
           else later
   RESOLVED: accept work on scroll-snapping

CSS Colors Level 4

   <SimonSapin> https://rawgithub.com/tabatkins/specs/master/css-color/Overview.html
   TabAtkins: It's "which of these proposed things do we want to pursue"
   <TabAtkins> http://tabatkins.github.io/specs/css-color/Overview.html#changes-from-3
     1. rgb() and rgba() functions now accept <number> rather than <integer>.
     2. hsl() and hsla() functions now accept <angle> as well as <number> for hues.
     3. All uses of <alpha-value> now accept <percentage> as well as <number>.
     4. 4 and 8-digit hex colors have been added, to specify transparency.
     5. The color-correction property has been pulled in from the unpublished Color Correction proposal.

   TabAtkins: Adding 4- and 8-digit hex colours has been a long-standing
              author request
   TabAtkins: #1 is something we should fix because it's a common authoring
   TabAtkins: Problem when doing something in JavaScript, have to round,
              floor etc
   TabAtkins: #4 is also for author convenience
   TabAtkins: #2 and #3 are less so, but are nice
   Tabatkins: This spec also pulls in dbaron's color correction proposal
   TabAtkins: I'm fine with taking over editing that, if he's able to consult.

   Tabatkins: There are also some other nice things
   [plinss and TabAtkins discuss #1]
   plinss: Concern about interpreting number as 0-1
   TabAtkins: No, use % for that. Number would be 0-255

   dbaron: I'm not crazy about adding syntactic sugar in general, because
           it adds more compatibility hurdles
   dbaron: It might be worth doing for color stuff, given the demand, but
           I'm not sure it's high priority
   TabAtkins: sure
   <sgalineau> may not be high priority, but is it expensive?
   <smfr> i like them
   glenn: TTML specifies use of a #rrggbbaa syntax since 2010
   TabAtkins: The compat issue applies reasonably to #2 and #3.
   Tabatkins: but #1 and #4 are fixing stuff
   <krit> some SVG authoring tools use #rrggbbaa internally as well like

   plinss: How many people use HWB notation?
   TabAtkins: Used in SASS, tint and shade is used quite a lot
   SimonSapin: what is HWB?
   TabAtkins: Hue, Whiteness, Blackness.  Transform easily from eg RGB
   TabAtkins: It's just an alternative that's intuitive

   plinss: opinions?
   plinss: ok, let's move forward
   RESOLVED: Shift these into a CSS4 Color ED
   TabAtkins: I'm fine with pushing features out if we don't like them yet

Outline Properties

   <dbaron> http://lists.w3.org/Archives/Public/www-style/2013May/0668.html
   dbaron: I sent a message about a bunch of cases in which there's no
           interop on outlines, and I'd like to hear what people think we
           should be doing
   dbaron: I guess there are 2 common differences: I think the spec is clear
           that when an inline is broken across multiple lines then you want
           the outline to surround the whole thing and not around the
           individual lines
   dbaron: Other thing was drawing the outline around the overflow, useful
           when eg image inside link.  Gecko is probably only browser which
           does this.
   smfr: webkit does that if outline thing is an inline, but doesn't if
         it's a block, IIRC
   florian: interop problem if you apply a rotation, IIRC
   TabAtkins: smfr, no we don't do anything special in the inline case

   dbaron: One question that's fundamental is that "we should optimize for
           focus outlines"
   dbaron: But authors like to use outlines for other things, like "border
           which doesn't affect layout".  Hence they demand better interop...
           but we should ask how much we care about that and similar use
   dbaron: With Gecko, it's becoming harder to maintain in the presence of
           3d transforms
   dbaron: I've been inclined to just drop the behavior of overflow
   dbaron: despite the entire demand coming from authors using it for
           non-focus use cases

   Rossen: How are authors using this reliably if you guys are the only
           ones doing this
   dbaron: They was interop on other implementations, and they are complaining
           to us
   krit: There is strange behavior on outline in WebKit,Blink on things
         that create a stacking context from time to time.

   plinss: OK, two issues: Does the outline contain overflow content?
           What's it's behaviour on wrapped inline elements?
   dbaron: The overflow one is the main one I think
   plinss: on the overflow topic, what do people think?
   dbaron: I have mixed feelings about supporting this case
   plinss: maybe we should introduce a property to control this behaviour?
   dbaron: Seems like overkill to me...
   krit: Regarding outline on svg, most browsers don't even support it.
         So the spec is a bit weak.
   smfr: In webkit we use different behaviour for focus ring(?) than with
   smfr: if outline style is auto, we fall into focus ring behaviour which
         does go around overflow content

   plinss: suggestions for path forward on these issues?  We have test cases,
           but do we need more discussion etc?
   dbaron: I may want to look into webkit behaviour some more, given what
           smfr said

Meeting closed.

<florian> dbaron: the outline on this TC behaves differently between
           gecko/webkit vs presto
<florian> http://files.florian.rivoal.net/outline.html
<florian> I don't have IE here to test what it does
<Bert> I like Opera's outline best.
<florian> I think the problem with firefox's and webkit's approach is when
           you start to have 3d transforms. I don't think transforming the
           outline in 3d is a good idea.
<florian> it works ok when people use it as a second border, but not when
           it is supposed to related to focusing
<Bert> Yes, imagine tabbing through a document, e.g., with the remote of
        your TV. When the outline changes too much from one element to
        another, you'll have a hard time finding where it went.
<florian> Let's move this conversation to the mailing list, I have to go

Received on Wednesday, 21 August 2013 23:22:34 UTC