- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 30 Jan 2014 05:39:08 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Selectors
---------
- 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
Display
-------
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?
Unknown.
fantasai: For :placeholder-shown, do we have implementations?
dbaron: We have implementations for the functionality, might not match
spec
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
IDREF
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
combinator
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
on?
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!
Pseudo-elements
---------------
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
marker?
...
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