[CSSWG] Minutes Seattle F2F Mon 2014-01-27 PM III: Selectors, Display


   - Discussed :has() vs. subject indicator. Plan to poll authors.
   - Went through Selectors spec to determine what to keep.
     Plan to defer: reference combinator, :local-link()
   - The following are scheduled for further investigation:
     :drop(), :-moz-ui-valid, :read-write, column combinator
   - RESOLVED: complex selectors in :matches/:not to move to fast
               profile, assuming bz agrees
   - RESOLVED: Drop :nth-match(), move functionality to :nth-child()
   - Still need a better name for :blank


   Some properties needed renaming. Current propositions:
     box -> display-box
     display-extras -> display-decoration

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

Selectors 4

   TabAtkins: Simon brought up issue of how exactly do we write the
              ancestor selector
   TabAtkins: If I want to select <p> containing <img>
   TabAtkins: currently written as !p > img
   TabAtkins: jquery writes it as p:has(img)
   TabAtkins: I understand the arguments for the first one
   TabAtkins: on the other hand, difficult to do multiple branches
   glazou: How do you do !p ~ img
   SimonSapin: p:has(~img)
   TabAtkins: Any arguments about this being intuitive are nil, because
              jquery people use it all the time
   fantasai: That proves it's useful, doesn't prove it's intuitive
   glazou: Seems to me we are inserting more and more ugliness in Selectors.
           No, don't think we should do :has()
   SimonSapin: We only have this syntax with :matches() and :not()

   SimonSapin: for same reason as shadowDOM combinators, I think it's better
               to have a name than random meaning for ascii characters
   glazou: At some point in the past we also had p:subject
   glazou: The history of that proposal. Initially I submitted to WG as !p
   glazou: Then ! was rejected due to negation
   glazou: we went to :subject
   <tantek> IMO the whole use of "!" in CSS has been a disaster.
   glazou: now back to !p
   <tantek> !p is terrible
   <astearns> +1 tantek
   <plh> +1
   <tantek> (nearly) every documentation about "! important" makes some
            joke about it being unintuitive.
   * fantasai actually suggested !! earlier
   <glazou> fantasai, I could live with !! :-)

   glazou: I think opening a parentheses and starting with a combinator
           is awkward
   plinss: This preserves the fact that the rightmost thing is the one
           you're selecting
   TabAtkins: Also, ! it's very confusing where exactly it can go
   TabAtkins: e.g. :matches() and :any() can take !, but :ancestor() can't.
   fantasai: If :has() is equivalent to !, then why different?
   fantasai: ! on the rightmost compounds selector doesn't change the
             meaning of the selector, just like * in front of a pseudo
             doesn't change the meaning of the selector.
   various examples thrown around
   <dbaron> one of the examples was "div:ancestor(!.light-theme) > foo",
            where fantasai and glazou say the ! doesn't change anything
            since the ! is only moving the subject of what's inside the ()

   shepazu: As a non-CSS person, I'd be able to guess what :has() means,
            whereas for ! can't do that
   * gsnedders agrees with shepazu here for all nothing it is worth
   shepazu: Any problems with jQuery?
   TabAtkins: No, the meanings are identical
   TabAtkins: It takes a relative selector, which is a selector that starts
              with a combinator (possibly an implied descendant combinator)
   <dbaron> for the record, I'm for :has()

   <smfr> http://dev.w3.org/csswg/selectors4/
   TabAtkins goes through the Selectors spec to see what needs to be cut

   :matches() and :not()
   dbaron considers :matches()
   dbaron: Don't know why we restrict :matches() to compound selectors
           in the fast profile
   TabAtkins: c:matches(a c, b c) hits more combinatorial cases
   SimonSapin: bz points out that with some new things, like parent selector,
               would need to do hard things
   dbaron: I think if the syntax makes sense to allow combinators, then
           allow it
   TabAtkins writes out example
     .q c:matches(.a c,.b c) expands to
     .q .a c,
     .q .b c,
     .a .q c,
     .b .q c,
     .a.q c,
     .b.q c
   TabAtkins explains that people often do just the common combinations,
             this would allow them to exactly express what they want
   dbaron asks about :nth-last-match(), and what exactly it means
   dbaron: OK, think that's alright
   [brief discussion of :not()]
   RESOLVED: complex selectors in :matches/:not to move to fast profile,
             assuming bz agrees

   TabAtkins: Case-sensitivity, the 'i' flag of attribute selectors.
   TabAtkins: I think we're planning to implement this
   glazou: Is that implemented in gecko?
   dbaron: no
   glazou: I have a patch for that.

   TabAtkins: Linguistic pseudos are new
   fantasai: :dir() has implementation in mozilla
   fantasai: :lang() was expanded to do lists, that's implemented in MS
   SimonSapin: Also does full BCP47 matching, a bit more complex
   Keeping that

   TabAtkins: Location pseudos
   TabAtkins: :any-link is shortcut for :matches(:link,:visited)
   dbaron: Gecko has it for over a decade
   TabAtkins: :local-link()
   fantasai: I think that one we will need to defer
   TabAtkins: :target already done
   TabAtkins: :scope has been around for awhile
   dbaron: When does :scope apply in normal style sheets?
   TabAtkins quotes from spec -- equivalent to :root
   dbaron: OK

   TabAtkins: Drag and drop pseudos. Do we have any implementations of
              the functionality?
   fantasai: There's an implementation of some kind of drag and drop thing,
             don't remember which one
   fantasai: Suggest we add an action to find out what, exactly, is
             implemented. Otherwise keep it.
   fantasai: Seems like we hashed over this enough that the definition is
             relatively stable.
   fantasai: Does anyone have any concerns or feel like this might need
             more work?

   TabAtkins: We have time-dimensional pseudos, defined for WebVTT.
   TabAtkins: Anyone know if they're implemented anywhere?
   ACTION fantasai: make sure timeline is defined for Speech
   <trackbot> Created ACTION-607

   TabAtkins: New input pseudos, mainly :placeholder-shown
   dbaron: We used to implement it under a different name, then removed it
   dbaron: Does WebKit do pseudo-class or pseudo-element?
   fantasai: For :placeholder-shown, do we have implementations?
   dbaron: We have implementations for the functionality, might not match

   TabAtkins: There was an issue raised by hixie wrt dropping :read-only
              and :read-write, because no known use cases
   tantek: I have mixed feelings on that. Would prefer more data
   ACTION TabAtkins Run a search on use of :read-only and :read-write

   TabAtkins: :user-error implemented by Moz under a different name
   dbaron: :moz-ui-invalid
   <tantek> FYI http://wiki.csswg.org/spec/css4-ui
   <tantek> has collected a bunch of these
   <tantek> as well as http://wiki.csswg.org/spec/selectors4#ideas-to-consider
   dbaron: We also have the opposite, :moz-ui-valid
   TabAtkins: That's just :not(:user-error)
   fantasai: Not necessarily. Could be triggering only over time period
             that :user-error could trigger
   fantasai: e.g. turning something green instead of red
   ACTION: fantasai and Tab to investigate :moz-ui-valid
   <trackbot> Created ACTION-608

   glazou: :blank's definition is really confusingly worded, fix it
   glazou: change "excludes" to "allows"
   ACTION fantasai fix :blank's definition to make sense
   <trackbot> Created ACTION-609
   TabAtkins: Are we keeping :blank?
   fantasai: A bit concerned about the name, makes me think of form elements
   dave: Also have a :blank page selector
   <dbaron> Gecko has :blank under the name :-moz-only-whitespace
   SimonSapin: Does it depend on computed value of white-space?
   fantasai: No, that also needs clarification
   TabAtkins: OK, naming issue, but keeping it

   TabAtkins: An+B.. probably need to kill this section in favor of Syntax
   fantasai: might leave some informative notes

   TabAtkins: :nth-match(), keep or punt?
   dbaron: Keep. This is one of the most wanted features.
   fantasai: One problem with this. Imagine a table
   fantasai: I want to color every other row silver, that is shown and
             not collapsed
   fantasai: So instead of :nth-child, I use :nth-match
   (this is also a problem with :nth-child)
   fantasai: The data is complex, and I split the data into sections
             using multiple <tbody>
   fantasai: Now there might be 2 white rows adjacent to each other
   dbaron: One possibility, might be weird, might be to keep the restriction
           of not having combinators inside :nth-match() and :nth-last-match()
   dbaron: and use that to change what scope you're matching
   dbaron: So for this example, you'd use ...
   dbaron: note, this wouldn't make the fast profile
   fantasai: We do have some space to play around before the 'of' (anything
             after that keyword will be consumed as a selector, including
             idents and commas)
   <dbaron> (I'm proposing putting relative selectors inside :nth-match,
             essentially, but with a default of child rather than descendant.)

   fantasai: or, we could expand :nth-child() to take the syntax of :nth-match()
   TabAtkins: thoughts?
   fantasai: I think it's more clear. :nth-match() could be interpreted as
             matching against the tree, not just against children
   RESOLVED: Drop :nth-match(), move functionality to :nth-child()

   TabAtkins: Next one is the reference combinator
   glazou: This is based as on ID attribute, which is a problem
   glazou: What if we have a reference between elements, but there's no
           DTD declaring IDREF relationship?
   TabAtkins: There's no relationship other than structure in XML
   TabAtkins: You can never have a reference combinator of any kind for XML
   fantasai: OK, so there's two things here
   fantasai: You need to know which is the ID attribute. You need that for
             ID selectors anyway
   fantasai: whether that's via DTD, or HTML spec, or xml:id
   clilley: no one uses xml:id any more
   glazou: It's easier just to look for the first occurrence, don't worry
           about if it's an ID attribute or not

   fantasai: I think we should drop this feature. no implementations, not
             a high request
   dbaron: I'm a bit queasy about this being a combinator, rather than a
           pseudo-class like :matches()
   dbaron: Also don't even want to see the term IDREF
   dbaron: Say language-specific knowledge if you need to, but don't say
   dbaron: But also happy to punt to next level.
   TabAtkins: OK, so put for now, fix later
   <liam> [the equivalent in XPath is a frequently-asked question, people
           want it all the time, even without id/idref]

   Bert: Been wanting it for labels and inputs
   Bert: Maybe with !! etc. could handle those cases
   plinss: in simple cases, can do that, but some cases might be in e.g.
           different table cells, harder

   TabAtkins: Column combinator, which is ||
   dbaron: I'd prefer a :column() pseudo-class
   fantasai: It's a combinator because it describes the relationship between
             two elements, which is what a combinator *is*
   TabAtkins: Do we want to keep here, or punt to next level?
   Bert: How do you know what's part of the column?
   Tab, fantasai: Markup magic.
   ChrisL: CSS display
   fantasai: no, only based on markup
   [discussion of whether to keep or punt]
   [discussion of :hover problems]
   dbaron: we could add :column-hover and :column-active
   fantasai: or change definition of :hover and :active so it works on columns
   fantasai: Main issue seems to be whether this is a pseudo-class or a
   glazou: I can live either way
   fantasai: Oh! You (dbaron) wanted to have an = combinator. We could use
             that for rows.
   fantasai: If you have a spanning cell, you can't tell it belongs to the
             third row by child selector.
   fantasai: So use || for column relationship, and = for row relationship :)
   TabAtkins: I hate column combinator now...
   dbaron: glazou is proposing that td:column(.foo) matches td that is in
           a column either with a class of foo, or that contains a cell
           with class of foo
   TabAtkins: This works equivalently for pseudo-class and combinator syntax.
              This is the column relationship selector.
   dbaron: I might prefer 2 separate selectors, but ok with it...

   TabAtkins: So, are we keeping in 4 or punting to 5 and what do we agree
   dbaron: I think it might be worth getting some author feedback.
   dbaron: I would like to see it stay in 4
   dbaron: I would like to hear author feedback on syntaxes and whether
           td matching is wanted
   dbaron: I suspect pseudo-class will be more preferred, but not sure.
           Would prefer to ask authors
   glazou: td selection is really useful
   dbaron: Not arguing that, wondering if should be same feature or
           different ones
   glazou brings up issue of hidden rows, selecting every other row
   ACTION TabAtkins Add this as an example for :nth-child()
   <dbaron> tr:nth-child(even of :not(.hidden)) ?

   glazou: Specificity, question wrt reference combinator. Think it should
           be counted somewhere.
   TabAtkins: We're punting to L5
   glazou: Keep track of it

   TabAtkins: OK, topic's done!

   Tab: need somebody to edit the spec
   tantek?: Authors are asking why ::selection isn't specified
   Tab: dbaron had a proposal to address issues
   dbaron: need to see if it's web-compatible
   * tantek was just pointing out the recent thread where author(s) asked
            about status of ::selection in specs since it appears to be
            implemented cross-browser.

Bikeshedding Display

   Tab wants better names for properties in Display module
   fantasai: I propose renaming 'box' to 'display-box'
   SimonSapin: So still violating naming convention of shorthands, since
               it's not part of the shorthand.
   * dbaron is unsure
   <fantasai> reasons being:
   <fantasai> a) display-box connects authors with display, so that
                 help them transition from display: none
   <fantasai> b) display properties are all about box generation. This
                 is about box generation
   <fantasai> c) We have in some cases properties which look like longhands
                 of a shorthand, but are actually independent because we
                 have a specific reason for them to be independent, even
                 though they are closely related. This seems such a case.
   TabAtkins: Ok, that makes sense to me.

   Tab: What about naming of what I currently have as display-extras,
        for list-item value?
   dbaron: Isn't there an association with display-outside, when marker
           is outside?
   dbaron: what happens when you give a display:table-cell an outside
   SteveZ: display-decoration?
   TabAtkins: better than display-extras
   [various discussion of list bullets, unminuted]

ACTION to all to read MQ4 for tomorrow
Meeting closed.

<SimonSapin> proposed definition for :blank
<SimonSapin> The :blank pseudo-class is like to the :empty pseudo-class,
              except that it additionally matches elements that only
              contain characters affected by whitespace processing. [CSS3TEXT]
<SimonSapin> looks good?
<liam> all characters are _affected_ by whitespace, maybe you mean that
        are classed as whitespace in [reference]?
<liam> well, maybe it's clear enough
<SimonSapin> well, Text doesn’t really classify characters
<liam> then how is the reference to CSS 3 text helping? maybe it's the
        HTML spec that's needed? dunno
<liam> (I don't mean, it's not helping, I mean, I don't understand how
        it's helping)
<SimonSapin> TabAtkins: https://dvcs.w3.org/hg/csswg/rev/e3a564cf9e04

Received on Thursday, 30 January 2014 13:42:16 UTC