W3C home > Mailing lists > Public > www-style@w3.org > March 2013

[CSSWG] Minutes 2013-03-20

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 20 Mar 2013 10:56:41 -0700
Message-ID: <5149F859.2070902@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - RESOLVED: css3-values to say: viewport units in continuous media are
               based on the ICB, in paged media undefined (expected to be
               defined in css3-page)
   - Discussed renaming :matches() to :any()
   - Plan to update CSS3 Values; if any issues missed, let us know.
   - Reviewed status of Text Decoration CR: waiting on 2 issues
   - Discussed Shadow DOM CSS/Selectors features and coordination with WebApps
       http://lists.w3.org/Archives/Public/www-style/2013Mar/0283.html
   - RESOLVED: grid line numbers always count from the before/start edge,
               negative numbers count from the end/after edge.
   - RESOLVED: Have 'order' property affect auto-placement and z-index
               in grid, just as it does in flexbox
   - Call for review of Grid Layout changes; plan to publish updated WD
     next week
   - Reviewed edits for Flexbox issue #12
       http://lists.w3.org/Archives/Public/www-style/2013Mar/0260.html

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

Present:
   Glenn Adams
   Rossen Atanassov
   Bert Bos
   Tantek Çelik
   Jim Dovey
   Arron Eicholz (via IRC)
   Elika Etemad
   Simon Fraser
   Daniel Glazman
   Rebecca Hauck
   Koji Ishii
   Dael Jackson
   Brad Kemper (late)
   Philippe Le Hégaret
   Peter Linss
   Edward O'Connor
   Anton Prowse
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Nick Van den Bleeken
   Lea Verou
   Steve Zilles (late)

<RRSAgent> logging to http://www.w3.org/2013/03/20-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Mar/0336.html
Scribe: Anton

Administrative
--------------

   plinss: no additions to agenda

   Topic: Update form PLH on IETF liaison
   plh: no update yet

Viewport units in paged media
-----------------------------
                                                                        X
   SimonSapin: complicated, no solution yet
   SimonSapin: Suggest to make undefined in css3-values, noting that it's
               expected to be defined in css3-page
   TabAtkins: ok
   fantasai: are we making both viewport units used in the document and
             viewport units used on @page undefined?
   SimonSapin: both
   fantasai: if we'll figure it out in the next couple of weeks, shouldn't
             we wait?
   plinss: How about: instead of saying they're undefined in values,
           say explicitly that they /will/ be defined in css3-page?
   fantasai: how about: it's defined one way if you support css21 page
             stuff, otherwise ??
   SimonSapin: uncomfortable with values saying it's based on the first
               page; not sure that will be true
   TabAtkins: I agree
   plinss: <wants to avoid confusion>
   Rossen: By undefined, remove definition or explicitly state it as
           undefined?
   TabAtkins: both
   SimonSapin: new values module will state that viewport units are based
               on ICB in continuous media, and undefined in css3-page
   RESOLVED: css3-values to say: viewport units in continuous media are
             based on the ICB, in paged media undefined (expected to be
             defined in css3-page)
   * fantasai thinks it's still based on ICB or else we're failing
              something here, it's just a question of which ICB since
              Paged Media has several ;)

Renaming :matches()
-------------------

   <smfr> http://lists.w3.org/Archives/Public/www-style/2013Mar/0275.html
   <tantek> sounds reasonable
   <smfr> url?
   TabAtkins: original name was 'any()'; we changed it for various reasons
   TabAtkins: Brian K pointed out that if we want to extend :matches() and
              :not() to express logical combinators, the name doesn't fit
              in well with that
   TabAtkins: I agree with his argument, and I liked 'any'
   * tantek likes :any
   * stearns prefers any-of
   SimonSapin: I like 'any'
   <tantek> or any-of

   <Bert> (I don't understand :any(), it's whether an element has a certain
          descendant, isnt it? so :matches() is fine, or :has() )

   ?: but what were the reasons for changing?
   <fantasai> It doesn't make much sense if there is only one argument.
   fantasai: originally the opposite of :not() which only takes one argument
   fantasai gives examples
   fantasai: I think :any() doesn't make sense when there's only one argument
             inside it, whereas :matches() does.
   TabAtkins: I'm comfortable with that argument
   SimonSapin: I agree with that argument too
   TabAtkins: common case will be multi-argument, so not sure of relevance tho
   glazou: lots of docs on the web already describes 'matches'
   glazou: I don't think 'any' is best choice, even though 'matches' isn't
           perfect
   TabAtkins: doc exists for 'any' as well though
   * fantasai is ok with either name, as long as we've considered this and
              agree its better in all cases, or at least on balance

   <tantek> but aren't there more documents that actually use :any(-of) ?
   <tantek> documents trump documentation right?
   <tantek> seems like an easy opportunity to agree with web authors
   <tantek> if we can go either way (can live with), then why not go with what web developers are asking for?
   <tantek> (which seems to be :any)

   glazou: matches with a group of selectors means you match against any of
           the selectors
   glazou: so don't think that 'any' gains us something semantic that was missing

   <glazou> tantek, speak up!
   Tantek: people don't have strong opinions. Web Devs lean towards 'any' or
           'any-of'(?).  Let's listen to that feedback since we are on the fence
   fantasai: if we present it to the webdev community, we should use the single-argument case as an example
   tantek: we should indicate the two leading options: any, and any-of
   fantasai: I'll send an e-mail
   tantek: and we can reassess next week

   <Bert> So selector1:matches(selector2) is an element that matches both
          selector1 and selector2? Then it is maybe an :and()...
   <leaverou> the most common case is when you have multiple arguments
              and it works as OR
   <Bert> A:matches(B, C) = an element that matches (A and B) or (A and C).
          Hmm, that is not an easy logical primitive...
   <leaverou> more like A && (B || C)
   <SimonSapin> Bert, the comma is OR, joining simple selectors without
                whitespace or separator is AND, :matches is just grouping
   <fantasai> It's A:matches(S) where S is a selector
   <fantasai> Similarly a:not(S)
   <fantasai> The comma is part of the selector
   <fantasai> it means whatever it usually means
   <Bert> A:matches(B, C) == A:matches(B), A:matches(C)

CSS3 Values Update
------------------

   Reissue css3-values CR?
   TabAtkins: Editors are not aware of any new issues beyond the one that
              someone brought up today; let us know very soon if there are any!

CSS3 Text Decoration
--------------------

   Go to CR?
   fantasai: i18n had things they wanted to discuss; wait to see if they're ok.
   fantasai: They had no call last week
   TabAtkins: So wait for their approval?
   fantasai: yeah, or resolve to go to CR and tweak it based on their feedback:
             given that the call takes a month to schedule it seems, we have
             plenty of time before it ;-)
   <glazou> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013
   <confusion about URLs>
   fantasai: dbaron has an issue he wanted to talk about
   glazou: Issue 6?
   TabAtkins: wait for i18n and dbaron

Shadow DOM
----------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0283.html
   glazou: spec starts being used by lots of other specs in and out of our WG,
           as a way to specify widgets etc
   <glazou> @host + CSS bits
   glazou: we need to evaluate that stuff
   glazou: TabAtkins, what is ETA, implementation report, rec track etc
   TabAtkins: I'm directly involved but not necessarily the right person
   TabAtkins: I e-mailed the WG last Nov about shadow dom

   [TabAtkins summarizes CSS-related stuff in Shadow DOM]
   <glazou> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#host-at-rule
   TabAtkins: first: the @host rule.  Stylesheets inside a web component
              inside shadow dom are scoped to that shadow dom; can think
              about it as a separate context
   TabAtkins: Stylesheets inside and outside cannot cross the boundary
   TabAtkins: Common to want to style the shadow dom differently in certain
              situations
   TabAtkins: @host allows to relax constraint
   Tabatkins: we were considering @global which takes a scoped stylesheet
              and relaxes it
   ACTION Sapin: ask about @host grammar: ruleset vs. declarations
   <trackbot> Created ACTION-550

   TabAtkins: shadow dom allows you take elements from the DOM and distribute
              them ??
   < TabAtkins__ gives example >
   TabAtkins: we introduced a ::distributed() pseudo-element to select elements
              distributed to a distribution point ...
   Tabatkins: we added ::shadow() which works in the opposite way from
              ::distributed
   glazou: your pseudo-element makes sense, similar to -moz-bound-element in Mozilla
   glazou: @host selects element in shadow host, but you cannot write a rule
           whose selectors are matching elements in the shadow host and
           shadow dom?
   TabAtkins: yes you can
   glazou: ok, that's more powerful than the Mozilla pseudo
   glazou: the whole thing makes sense now! Much better

   glazou: Should these bits remain in that doc, or should that shadow-dom
           be joint work between webapps and us?
   TabAtkins: it's unofficially joint already
   TabAtkins: I don't mind either way
   glazou: Members: is it ok to invest time in this in the group, if it's not
           in the charter?
   plh: The good thing about one single spec is that it's easier to assimilate
   plh: will be a joint effort between webapps, us and HTML
   TabAtkins: doing it joint won't be a big effort
   TabAtkins: I'm not currently acting as an informal co-editor
   glenn: maybe we could propose a co-editor from CSSWG to contribute
          (eyeballs, etc)
   glazou: Would dimitri be prepared to join our WG for purposes of formally
           making the spec joint?
   plh: Best to use TabAtkins ?
   glazou: OK

   glazou: @host with new pseudo relies on the fact that in the new grammar
           the pseudo doesn't need to be in last position
   TabAtkins: actually, no.  Not relevant
   ?: do you have an example?
   stearns: boundary of light and dark CSS; if the light css defines a
            counter style, can the dark css refer to it?
   TabAtkins: yes
   SimonSapin: scope is only about selectors?
   TabAtkins: yes

   plh: link to that draft from css4-selectors draft?  Should all selectors
        be listed in one doc?
   TabAtkins: I think it's reasonable to have a link.  c.f. values and units
   TabAtkins: plh, glazou : all agree
   <SimonSapin> so, should Selectors 4 also link to css4-pseudos, css3-ui,
                and anything that adds selectors?
   <fantasai> SimonSapin, informatively, probably would be a good idea
   <SimonSapin> fantasai, yes, informatively
   <glazou> fantasai, SimonSapin : agreed

   ACTION: TabAtkins to ping the WG whenever Dimitri finishes the edits
           related to CSS

   stearns: select a custom component based on a media query?
   TabAtkins: we don't have anything for that.  Can do it right now using
              JS version of the API.  There's nothing declarative right now
   Alan: in the component itself, the dark css could have a MQ ...
   <Alan and TabAtkins__ discuss>

   glazou: @host - contains only style rules right now.  Why not nested
           @-rules?
   TabAtkins: spec currently has old version of @host.  Only allows
              compound selectors
   TabAtkins: grammar production will be similar to stuff defined in
              conditionals, will allow arbitrary nesting

Grid Layout
-----------

   plinss: publish WD?
   TabAtkins:  we've switched over grid positioning properties into
               line-based properties.  We think it's complete enough
               to be a WD, and changed enough that we really need a
               new WD.
   <stearns> +1 to publish
   fantasai: to avoid confusion, let's go through a couple of the issues
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Mar/0266.html

   <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Mar/0182.html
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Mar/0184.html
   <fantasai> (this is issues 1 / 2 in that list)
   <TabAtkins explains the issue - see pasted URL>
   <TabAtkins describes potentially confusing syntax>
   glazou: I like the proposal
   <SteveZ> +1
   TabAtkins: matches programming languages such as Python
   plinss: -1 means last line?
   TabAtkins: correct.
   RESOLVED: line numbers always count from the before/start edge, negative
             numbers count from the end/after edge.

   Bert: what happened to grid-area property?
   TabAtkins: it's still there

   plinss: still some discrepancy about conflating line names and area names,
           but I see that's flagged as an issue

   fantasai: Can we deal with ordering issue?
   plinss: [...]
   TabAtkins: it may still affect z-index, but otherwise yes.
   RESOLVED: Have 'order' property affect auto-placement and z-index in grid,
             just as it does in flexbox

   TabAtkins: I wanted to point people to the abspos section of the spec;
              it looked like it was easy to get abspos to be useful
   http://dev.w3.org/csswg/css3-grid-layout/#abspos-items
   TabAtkins: please review
   plinss: what about left/right/top/bottom?
   TabAtkins: they respond to the containing block; the grid-placement
              properties just change the containing block

   rossen: Can we have a week to go through issues and give feedback?
   TabAtkins, plinss : that's fine

Flexbox
-------

   <glazou> FWIW, I have now a basic layout editor based on the most
            recent flexbox spec
   <glazou> http://lockerz.com/s/287452841

   TabAtkins: Are Rossen et al happy with the changes we made to address
              Rossen's issue?
   TabAtkins: about stretching elements
   <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-12
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0251.html
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Mar/0260.html
   TabAtkins: orthogonal flow issue: resolve it in a similar way to multicol,
              to get good behaviour. Current spec is terrible
   fantasai: Defining intrinsic sizing on flexbox made a lot of issues fall
             out correctly
   fantasai: Just need review.

plinss: Bye everyone
Meeting closed.
Received on Wednesday, 20 March 2013 17:57:10 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:07 GMT