- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 14 Sep 2015 13:59:07 -0400
- To: www-style@w3.org
Selectors
---------
- RESOLVED: Put a SHOULD recommendation in for authors to use the
double-colon not the single-colon pseudo-element syntax.
- RESOLVED: Keep section 3.6.3. (Pseudo-classing Pseudo-elements)
overall. Add guidance to people developing new pseudo-
elements on when to specify if they accept user action
pseudo-classes. Remove the statement from :hover
that it applies to all pseudo-elements: pseudo-elements
must individually enable pseudo-classes they need.
- RESOLVED: Pseudo-element and pseudo-class combinations are
invalid unless defined to be a valid thing that could
potentially match something (for pseudo-classes on
pseudo-elements)
- RESOLVED: :matches() and :not() are allowed on pseudo-elements.
They are only valid when they contain only
pseudo-classes that are valid in that context.
- RESOLVED: If any simple selector accepts a given type of
selector it must also accept :not() and :matches(). If
it accepts a combinator after it it also must accept
:has().
- RESOLVED: Behavior defined for combinators after pseudo-elements
as written in the pseudo spec is okay.
- RESOLVED: Close issue on naming :any-link because there's no
better ideas
- RESOLVED: rename :user-error to :user-invalid
- RESOLVED: Add :user-valid, mark :user-valid and :user-invalid as
at-risk
- RESOLVED: Drop :blank
- RESOLVED: Change the spec so :empty will trigger on white space-
waiting on compat data to confirm this is an okay
change.
- RESOLVED: Keep :drop(), mark at-risk.
- RESOLVED: Keep :nth-child(An+B of <selector>) where <selector>
is limited to a compound selector containing only
feature selectors. Absolutely no nesting :nth-child().
- :nth-child(An+B of<selector>), :nth-last-column(),
:nth-column(), :drop, and :focus-within will be marked as
at-risk.
- :has, :placeholder, :read-write and :read-only will stay in this
level.
- :column() will be deferred to level 5.
- RESOLVED: drop >>
- Publication will wait until the interested parties have come to
a conclusion about the algorithm describing how to evaluate a
selector.
===== FULL MINUTES BELOW ======
scribe: dael
Selectors Open Issues
=====================
plinss: Let's get started.
<fantasai> https://drafts.csswg.org/selectors-4/
Deprecating Single Colon (issue #4)
-----------------------------------
fantasai: We need to publish an update. I finished going through
all the changes. There's a few TabAtkins and I don't
agree on. There's also a bunch of issues we want to
clear out. I'll start with issues.
<fantasai> https://drafts.csswg.org/selectors-4/#issues-index
<fantasai> https://drafts.csswg.org/selectors-4/#issue-eb31bbbc
fantasai: 1st issue is #4 which is we have 2 syntaxes for
::before, ::after, ::first-line and ::first-letter.
There's single and double colon and right now we don't
say which to use. TabAtkins wants a requirement on
authors that they should use ::. That means a validator
of CSS should throw an error with single colon.
TabAtkins: I think it's good to call single colon to deprecate is
authors have no clue between pseudo-class and element
and it's highly exasperated with the single colon syntax.
Let's make sure the recommended syntax is double.
rachelandrew: I'd agree.
fantasai: Other opinions?
<tantek> yes let's fix it!
zcorpan: I think it's slightly a case where it generates warnings
from validators for something that works fine. It doesn't
make them understand the difference better.
TabAtkins: Depends on how much you want to change a validator for
this will break you or one for linting. That's a
personal opinion and what you code in your validator.
hober: Nothing stops validators for warning about single colon.
TabAtkins: There's nothing preventing a validator today from
saying you shouldn't use single and nothing making a
validator do it tomorrow.
fantasai: But saying what an author "should" do informs the
validator implementers.
<Ms2ger> I don't think the validator should warn, that just makes
it less useful for authors
<TabAtkins> Ms2ger: That's for validators to decide, shrug.
<TabAtkins> Like I said, "this is a problem" validators vs linters.
tantek: Should not must?
fantasai: Definitely. There's a reason for the single which is if
you have to support really down-level clients.
tantek: I'm fine. If you'd like you can include suggested
validator text. I think it would lower the barrier to have
it show up.
TabAtkins: Okay. I can do that.
fantasai: So Ms2ger says he doesn't want the validator to warn
because it dilutes the real errors.
plinss: I'm not hearing strong objections.
plinss: I'd say, the old syntax was deprecated 15 years ago and we
should put the recommendation in to not use them.
RESOLVED: Put a should recommendation in for authors to use the
double colon not the single colon.
Pseudo-classing Pseudo-elements (issue #6)
------------------------------------------
<fantasai> https://drafts.csswg.org/selectors-4/#issue-99d9962e
fantasai: Next issue is this. It's about pseudo-classing
pseudo-elements. If you have a pseudo-element, in the
past that was the end of your selector. You couldn't
select anything special about that. We're proposing in
level 4 to allow user-action pseudo-classes to match
against pseudo-elements.
fantasai: If I use p:hover::first-line that will match whenever any
line of text is hovered it highlights the first line.
But ::first-line:hover will only highlight if you hover
over the first line.
tantek: Why is this useful?
TabAtkins: Before :hover, being able to use the pseudo-class on
the element.
tantek: What case of generated content before you hover?
TabAtkins: ...
fantasai: He wants a specific use case.
plinss: There's a use case which is the IRC logs. If you hover
before the line the click handler pops up.
fantasai: There's an element in the DOM in that case because you
needed a click handler. So why can't you use :hover on
that element?
TabAtkins: You can't for the same reason you can't on the parent
of any child. It's too large.
<tantek> you're using generated content to create UI?!? Ok I'm out.
* tantek SMH.
fantasai: For his case it's a click target. You're clicking on the
::before pseudo.
TabAtkins: For the UI think your doing it's the before that's
important.
hober: The only reason is because you can't put it directly on the
pseudo.
fantasai: But you can put it on the target. If the click target is
visible somewhere else and you've got a :before
somewhere else, you might want to highlight if either
are being hovered.
<plinss> http://log.csswg.org/irc.w3.org/css/2015-08-27/
plinss: Right now if you look at the IRC log, if you hover over
the # at the beginning you get the flag.
plinss: Ideally the flag should show when you hover over the flag,
not the thing next to it.
fantasai: To the point where we don't have click event handling it
doesn't make sense....we should fix them together unless
someone has another use case.
plinss: :first-line and :first-letter are also usable. There will
be more pseudo-elements.
fantasai: It's additional stuff to implement and we might as well
wait until it's useful to implement- I think that's
tantek point.
tantek: Encouraging people to build UI of generated content is a
mistake.
tantek: You're lowering the barrier so you are.
TabAtkins: It's already used widely.
plinss: I don't think it's more of a layering violation. There's
lots of UIs dependent on the presentation. It's not more
than generated content.
tantek: Generated content is different.
plinss: There's bits of the UI that will differ depending on if
they want to show.
tantek: That's decorative.
Bert: The region spec...at some point could style regions, but I
think it's not there anymore. It might need the same
mechanism.
fantasai: We shifted a rough description of that from Regions into
Scoping module. The plan is to continue and use the same
mechanism for styling pages and fragment and regions.
They should share the same syntax. We haven't fleshed
that section out.
<fantasai> http://www.w3.org/TR/2014/WD-css-scoping-1-20140403/#fragment-scoping
<Bert> -> https://drafts.csswg.org/css-template/#select-after-pseudo
Some musings on styling content (incl. other elements)
inside pseudo-elements.
fantasai: Any opinions to add?
Florian: Even if you're not doing interacting UI bits, it's useful
to have little bits of decoration. I don't see it as
critical.
fantasai: Does anyone here want to implement it in the next 2
years? We're at the point that we need to trim to
implemented or imminently implementable.
gregwhitworth: I see the use case, but I can't stand ::before and
::after.
dbaron: I see tantek's point, but I think there are other elements
where we want the pseudo-classes. I'm trying to figure out
what gecko does right now. I think we support some.
gregwhitworth: I think we should bust the two apart.
dbaron: I think it would be nice if the selectors module provided
a mechanism for pseudo-elements to have pseudo-classes,
but we should apply to ::before or ::after.
tantek: or ::first-letter and ::first-line.
esprehn: We'd rather pseudo-elements were exposed as events first
then add new selector features.
tantek: I agree with dbaron's scoping. For pseudo-elements trying
to address pieces of UI in the doc that makes sense.
<dbaron> Gecko supports pseudo-classes on :-moz-number-wrapper,
:-moz-number-text, :-moz-number-spin-box,
:-moz-number-spin-up, :-moz-number-spin-down,
:-moz-progress-bar, :-moz-range-track,
:-moz-range-progress, :-moz-range-thumb, :-moz-meter-bar,
:-moz-placeholder, and :-moz-color-swatch.
<fantasai> https://drafts.csswg.org/selectors-4/#pseudo-element-states
fantasai: The section we're discussing is this^ which allows for
specific pseudo-elements to say specific pseudo-classes
apply to them.
fantasai: I'm hearing we should keep this but remove the statement
in :hover that it applies to everything.
tantek: I'd restrict to a pseudo that's accessing a piece of UI.
fantasai: That's a guideline we can use when writing.
tantek: I'm saying it should be in that intro paragraph to provide
guidance.
fantasai: So I'm hearing we should keep the section overall, add
guidance to people developing new pseudo-elements as to
if they should accept user action pseudo-classes and
remove the statement from :hover that it applies to all
TabAtkins: The only one it will apply to are the undefined pseudo
that people build.
RESOLVED: Keep section 3.6.3. (Pseudo-classing Pseudo-elements)
overall, add guidance to people developing new pseudo-
elements as to if they should accept user action
pseudo-classes, and remove the statement from :hover that
it applies to all pseudo-elements.
fantasai: Next is, we're allowing in general pseudo-elements to
take things like :hover and :focus. If that pseudo-
element doesn't support that pseudo-class, does that
make the selector invalid?
fantasai: As a syntax error, or never match?
zcorpan: It seems to me better to not match. That allows you to
have a group of selectors.
dbaron: The current behavior is it's a syntax error.
dbaron: The question is do we want to change it from being a
syntax error to not being one.
Florian: Can we?
dbaron: We could if we wanted to, but I'm inclined it's better to
not.
tantek: We only should if we have a good reason.
fantasai: Pseudo-element and pseudo-class combos are invalid.
TabAtkins: They're invalid or they don't match, that's what we're
deciding on.
RESOLVED: Pseudo-element and pseudo-class combinations are invalid
unless defined to be a valid thing that could
potentially match something (for pseudo-classes on
pseudo-elements).
TabAtkins: There is a sub issue of that.
fantasai: ::first-line:not(:focus)?
fantasai: Given what we resolved that's invalid.
TabAtkins: If you're accepting any pseudo-class on a
pseudo-element, should we require accepting the
inherent...[missed]
fantasai: :not() and :matches() should be correlated to if its
argument is valid.
TabAtkins: If it accepts :hover should we require it accepts :not
and :matches.
fantasai: As long as the contents of :not and :matches are valid
independently. This is a bug fix.
dbaron: It's fine with me, though it's not what we do now. It
shouldn't be hard. Is it well defined what happens if you
say pseudo-element:not(p)?
TabAtkins: Yes, they don't have names.
dbaron: If the pseudo-element is on a <p> element, is that
invalid, valid but not matching?
fantasai: The first.
dbaron: I don't care about what the answer is, I just care that
the spec says what the answer is.
TabAtkins: So it doesn't match.
fantasai: We need to make sure it's invalid.
TabAtkins: We can do that too. I'm happy to do it either way so we
only allow use of the valid pseudos. If we do that it's
minimum insertion of abilities.
TabAtkins: The syntactic pseudo-classes are allowed we will make
them only valid when they contain only pseudo-classes
that are valid in that context.
fantasai: :not() and :matches(). :has() is not allowed.
* zcorpan doesn't follow why it wouldn't match
<fantasai> zcorpan, the pseudo-element is not the originating
element
<fantasai> they're bound, but not the same
<zcorpan> fantasai: yeah, and :not() negates the result
RESOLVED: :matches() and :not() are allowed on pseudo-elements.
They are only valid when they contain only pseudo-classes
that are valid in that context.
Pseudo-Element Internal Structure
---------------------------------
<fantasai> https://drafts.csswg.org/selectors-4/#pseudo-element-structure
fantasai: If you scroll down to this section ^ we define that some
pseudo-elements have an internal structure and
therefore may be followed by child selectors.
fantasai: Combinators are otherwise invalid.
fantasai: This is why :has needs to be invalid in the above--it
corresponds to this case, not the previous case.
TabAtkins: Okay. I don't feel strongly.
dbaron: I agree with fantasai.
TabAtkins: Sure.
TabAtkins: I get the distinction, I just like keeping the three
together. I'm okay with it.
fantasai: The reason we added this expansion is because the
::shadow requires it. Also the things for ::page
::region and ::fragment will require this syntax so we
were opening it up for those to be defined. Also,
defining that these will be invalid with sibling
combinators.
fantasai: Does that all work for everyone?
<Florian> wfm
fantasai: So behavior defined for combinators after
pseudo-elements as written in the pseudo spec is okay.
fantasai: And we need to clarify that such pseudo-elements can
accept :has().
TabAtkins: If any simple selector accepts a given type of selector
it must also accept :not() and :matches() with that
selector. If it accepts a combinator after it it also
must accept :has().
RESOLVED: If any simple selector accepts a given type of selector
it must also accept :not and :matches. If it accepts a
combinator after it it also must accept :has().
RESOLVED: Behavior defined for combinators after pseudo-elements
as written in the pseudo spec is okay.
<leaverou> what about ::attr():hover? Invalid or not matching?
<TabAtkins> leaverou: In the absence of a spec defining it as
valid, it's invalid.
<leaverou> http://www.w3.org/TR/selectors-nonelement-1/
tantek: Since you brought up content, do we have any way of
selecting an element based on its content?
fantasai: No.
TabAtkins: It's deliberately omitted. If you look at selectors 3
there's a black section that removed the :content.
fantasai: We have ::content and if we add that back we'll also
have :content().
TabAtkins: Let's not re-open naming discussions.
tantek: It couldn't have began with shadow to distinguish?
<tantek> e.g. ::shadow-content since it applies specifically ONLY
to shadow projected content
<fantasai> yeah, we discussed it, came up with several options,
and Blink didn't want to rename 'coz they'd shipped
fantasai: There's two types of elements. Real you can select with
tags and they can have attr and types?
TabAtkins: Unless specifically allowed, they're disallowed.
Florian: Everything is opt in.
tantek: The reason I asked is I was trying to come up with
contradictions to not putting pseudo-class after pseudo-
element. The one that's useful is some kind of content on
::first-letter. I previously proposed this as
parenthetical syntax.
<tantek> specific example: ::first-letter("A") to select first
letters when they're an "A"
<tantek> pretty sure I've proposed that in the past (like many
years ago)
fantasai: That seems like a reasonable request, but it would go
against pseudo-elements spec. We split pseudo-elements
from selectors because they're specific to CSS.
fantasai: Throw an e-mail onto the mailing list and we'll track it.
:any-link
---------
fantasai: We have an issue on naming :any-link. Unless there's
suggestions we should close it and ship.
Florian: Hasn't it shipped?
fantasai: Prefixed in Moz, I think.
Florian: I'm fine as-is.
fantasai: Anybody else?
RESOLVED: Close issue on naming :any-link because there's no
better ideas
<SimonSapin> Servo implements :any-link, but it might not count as
"shipping"
<TabAtkins> SimonSapin: No, Servo doesn't count as a shipping
implementation yet.
:user-error/:user-invalid
-------------------------
<fantasai> https://drafts.csswg.org/selectors-4/#issue-baf555b0
fantasai: Next is about :user-error pseudo-class. Has anybody
implemented it unprefixed?
TabAtkins: We have not.
fantasai: Mozilla calls it :-moz-ui-invalid
smfr: Nope.
gregwhitworth: I don't think we do.
fantasai: It was raised we should add the :-moz-ui-valid
pseudo-class.
fantasai: :user-error was taken from :-moz-ui-invalid. It doesn't
match whenever the control is :invalid, but does match
if you try and submit the form and it's invalid.
fantasai: :invalid is still useful for JS, but the UI wants some
statefulness--to match only if the user has interacted
with the invalid control.
fantasai: :-moz-ui-valid is the opposite: if the user has
interacted and it's valid.
fantasai: We renamed :-moz-ui-invalid to :user-error because we
were combining checks for both validity and omission.
You could be valid but an empty required form control
that was omitted.
fantasai: But if we want :-moz-ui-valid, it should have parallel
naming.
fantasai: I can't think of something that would match user-error.
fantasai: Does anybody have an answer, or should we rename to
:user-invalid and add :user-valid as its opposite?
dbaron: One data point is we have this valid selector and we have
no uses outside of tests. Our user stylesheet uses :user-
invalid.
TabAtkins: I've seen this in the wild. It's more usual to not do
something for the valids, but it's done.
tantek: It's rare, but it's the better practice to show that
things are correct.
tantek: It's like carrot vs. stick gamification of forms.
Florian: If this is a useful pattern and Mozilla has the tool, are
people not using it because they don't know, because it's
only Mozilla, or because it doesn't do quite what they
want?
fantasai: I don't know. We can not add it in this level, but if we
intend to add it, we want the names as a pair.
fantasai: Either somebody comes up with a new name or we rename to
:user-invalid and ship that in this level.
Florian: I don't have a strong pref between the two. The
distinction is too small to be noticed.
RESOLVED: Rename :user-error to :user-invalid.
fantasai: So do you want us to add :user-valid to this level, or
next level?
tantek: We have an implementation.
dbaron: It's worth being clear about what it means. Does it mean...
is :user-valid the same as...is it a time when we would
have marked it as :user-invalid, but it's valid?
TabAtkins: The same criteria for when we would start using
:user-invalid would be for :user-valid.
Florian: Does that match implementations?
fantasai: Probably close enough.
fantasai: Our criteria in the spec is looser. You must match
between these two times, you can match outside these
times.
Florian: Maybe we'll require timing later.
fantasai: Yes. For now we're leaving it out so UA can represent
their best option.
Florian: So should it be at risk?
fantasai: Both should be.
RESOLVED: Add :user-valid, mark :user-valid and :user-invalid as
at-risk
<dbaron> we also have a separate :-moz-submit-invalid for controls
(button, input type=button) that would submit the form
<dbaron> although :-moz-submit-invalid appears to predate
:-moz-ui-invalid and :-moz-ui-valid
<dbaron> (it comes from https://bugzilla.mozilla.org/show_bug.cgi?id=580575)
<dbaron> (seems like :-moz-submit-invalid used to be in our UA
sheet but no longer is)
<dbaron> (or maybe it never was)
:blank pseudo-class
-------------------
<fantasai> https://drafts.csswg.org/selectors-4/#the-blank-pseudo
fantasai: Next is on :blank. We have :empty that selects if an
element is completely empty. If you have an element
that's effectively empty, like if you have a <p> with
white space in between, it's going to be empty for
all general purposes. But there's no way to select that
because they show as not empty.
fantasai: We added :blank, but it might imply that it's for things
that should be filled out so the name isn't great.
fantasai: There's also the option to change empty to also match
things with white space or call it :no-content. So
change definition of :empty to accept white space,
rename :blank, or drop.
TabAtkins: The preference is the first one--to redefine. Will
there be compat problems?
zcorpan: We need to research.
dbaron: It's hard to know. I think the most likely compat problem
comes from people who wrote it in their style sheet, it
didn't work, and they left it.
TabAtkins: For now we can leave an issue in the spec that
implementors are experimenting with changing :empty to
also match CSS white space and drop the other
suggestions for now and we'll finish with data later.
Florian: I'm not sure we don't want both. If you do
white-space: pre-wrap or something these will show up. If
you know I have things that only have white space, you
might want to decide if you select these things.
fantasai: You can't select things that only have white-space. You
can select nothing or stuff. I think the case of
white-space: pre-wrap isn't used a lot. That's basically
code blocks and I can't see this being used for stuff
inside code blocks. This doesn't seem a common use case.
Florian: I meant not matching on code blocks.
TabAtkins: So write your selector to not match those elements.
fantasai: You're more likely to want this on table elements. So
highlight all the empty table elements to style as empty.
Table elements have an optional close tag and your
selector won't work because it'll include your line feeds
and indentation for the next element's start tag.
esprehn: Authors already assume it works this way and their pages
are broken.
fantasai: Once we fix this they'll work as intended. Our fear is
they have been designed past.
RESOLVED: Drop :blank
fantasai: We should resolved to change the spec to trigger on
white space and we're waiting on compat data.
RESOLVED: Change the spec so :empty will trigger on white space-
waiting on compat data to confirm this is an okay change.
tantek: I thought we tried to change this and we failed.
fantasai: I think the group was more adverse to changing existing
specs to that point. It might not have had to do with
content dependency.
tantek: If we can do it, sure, but I'm skeptical.
TabAtkins: We'll tell you if it works.
dbaron: I'm skeptical too.
Bert: What's your definition of fix.
TabAtkins: Growing the web platform is bad. We can change legacy.
Bert: You can start over.
TabAtkins: That's growing.
TabAtkins: We can review what to cut after lunch. We'll write up
the cut and keep.
<leaverou> "Growing the web platform is bad. We can change
legacy." THIS. Yes!
plinss: Have we published a FPWD of this?
fantasai: We have.
plinss: I'm not finding it.
<fantasai> http://www.w3.org/TR/selectors4/
<dbaron> http://www.w3.org/TR/2013/WD-selectors4-20130502/
<dbaron> previously http://www.w3.org/TR/2012/WD-selectors4-20120823/
and http://www.w3.org/TR/2011/WD-selectors4-20110929/
plinss: So some discussion over lunch, after lunch we'll decide if
we publish or not.
dbaron: Did you fix the what counts as white space? We had a
similar problem with :first-letter. I went through and no
one matched.
TabAtkins: I can reference the rec spec.
<br type=lunch>
<fantasai> Tantek just noted that the trigger times for
:user-invalid and :user-valid should be different
<fantasai> So we need to make sure the spec allows for that (i.e.
doesn't bind them together)
<zcorpan> i see 32,464 matches for :empty in text/css files in
httparchive
<zcorpan> afaict the most common usage of :empty, from looking at
a few at random, is from bootstrap:
https://github.com/twbs/bootstrap/search?utf8=✓&q=%3Aempty
which presumably won't break with the proposed change
<liam> isn't the potential breaking case where :empty was used
erroneously & didn't match, but now will start matching?
<zcorpan> liam: yeah
<zcorpan> excluding "bootstrap" leaves 16,624 matches for :empty
<liam> that doesn't sound huge unless they're on major sites, but
maybe major sites would fix the problem
</br>
plinss: Let's start up.
tantek: Btw, we want to allow different trigger points for
:user-valid and :user-invalid. From a user prospective you
want to wait for the user to leave for :user-invalid, but
for :user-valid it's a more friendly experience to have it
turn green as you type. We should undo the decision to
keep the triggers the same and instead give flexibility
and guidance.
Florian: We might want the same definition where you can be
flexible.
Florian: The current definition doesn't say where it is.
tantek: We shouldn't say it should be the same. We should provide
guidance that they should be different because it better
guides.
tantek: I have no idea how to select an input element that's empty
vs has one that a user has selected.
dbaron: We've talked about it but it's abstract.
tantek: You can't use attr selector because the user is typing.
fantasai: [:value=token] (dbaron's idea)
tantek: Does an implementor have a prefix to select empty vs not
empty?
fantasai: So probably not this level, but it should be level 5.
tantek: I just want to make sure this gets in the minutes.
<tantek> request: a way to select an input element that has a
value or not or has a specific value (:empty doesn't
apply since input is always an empty element, and [value]
selector applies to static attribute, not what the user
has typed in)
ACTION fantasai add value selector to level 5
<trackbot> Created ACTION-718
Features to Keep and to Defer
=============================
<Florian> http://www.w3.org/mid/55AEABE6.9010001@inkedblade.net
fantasai: We wanted to go over the features we want to keep vs
defer and make the edits.
fantasai: We're definitely keeping everything in level 3. We're
keeping the case insensitive :matches, :not, :dir, and
:lang. :any-link. :user-invalid we're keeping.
Drag & Drop
-----------
fantasai: We have :drop pseudo-class and I think Mozilla has a
prefixed subset of the functionality. Are other people
interested in implementing?
TabAtkins: Mozilla has a selection of them with some type of names.
I forget if we do have a version in webkit.
Florian: I think we went back and forth on semantics. If we're
sure we have the right one and there's a implementation,
it's fine to keep, possibly marking it as at-risk. If
we're not sure it's maybe level 5.
<gregwhitworth> https://drafts.csswg.org/selectors/#drag-pseudos
fantasai: We have a functional syntax that lets you select active,
valid and invalid drop target.
tantek: Does this include items that are so covered you can't drop
in invalid? And is can drop determined the way of hit
testing?
fantasai: It could match valid, but never active.
tantek: So how useful is that?
fantasai: It's a lot harder to detect that case than if this is a
drop target you can drag to.
fantasai: This is equivalent to people asking for a visible
pseudo-class.
tantek: I'm trying to provide an argument against a half usable
feature.
plinss: It could be exposed and I can't get to it. Do I want it to
have never shown up? By your logic yes, but that's a lot
of code to figure that out? How far to we want to go?
rachelandrew: There are some things where you have to assume the
person developing the interface has some idea of
what they're doing.
tantek: So is this the distinction is between active and valid?
TabAtkins: Valid is all the things that can accept the dropping.
tantek: And active requires hit testing?
Florian: Yes.
tantek: So the only request is the document refers to hit testing.
TabAtkins: The document refers to how the drop works and doing it
via hit testing.
dbaron: It could be that HTML defines when you drop something on
the label of the form control it drops onto the form
control and we don't want to define CSS differently.
tantek: Whatever you're using to drag the thing, finger or mouse.
fantasai: Voice interface.
Florian: The semantics we have now. We know we can go back and
forth. Are we confident we're not going to change this?
tantek: Has anyone else implemented?
TabAtkins: Firefox has different names versions.
TabAtkins: And I think you have :-moz-drag-over
tantek: That's the one. Last time this was on the wiki it was
different names.
dbaron: Is anyone planning to implementing this in the near future?
fantasai: Next two-ish years.
TabAtkins: I have no idea.
tantek: That says to me it should punt.
fantasai: Authors want this.
Florian: at-risk is reasonable.
fantasai: Okay.
<tantek> at a minimum at-risk
RESOLVED: Keep :drop(), mark at-risk.
:focus-within
-------------
fantasai: Our goal is to put everything into keep, at-risk, or
drop to the next level.
fantasai: We have :has() which it sounded like the WG wanted to
keep. Since there were strong opinions I suggest we
don't drop. There's :focus-within pseudo-class.
Florian: You can use it in style sheets.
Florian: It does document magic through labels and you can't use
:has in style sheets.
fantasai: We don't have it implemented currently. If anyone is
interested in implementing? If not we should at-risk. If
there's no interest we should drop.
dbaron: I think it's trivial once you have :first. Was there
demand?
fantasai: Yes.
dbaron: I'd keep and mark at-risk.
plinss: Is it completely equivalent to :has?
TabAtkins: Yes.
Florian: No because it's smarter and deals with the shadow DOM.
TabAtkins: shadow DOM surfaces focus to the outer document.
TabAtkins: Equivalent to :has(:focus) is if we had a deep
combinator still.
fantasai: That's at-risk.
RESOLVED: mark :focus-within at-risk
:read-only and :read-write
--------------------------
fantasai: We have :read-only and :read-write. I recall hearing
there were issues?
dbaron: Aren't they not new?
Florian: They're in gecko prefix and ?? non-prefix.
dbaron: Aren't they in 3?
Florian: They're in HTML 5 which is REC
<Florian> http://www.w3.org/TR/html5/disabled-elements.html#selector-read-only
TabAtkins: Trying to remember why issues.
fantasai: content-editable, I think.
TabAtkins: I think it was hixie that wanted it.
Florian: :read-write by three browsers, :read-only is by two.
fantasai: So we'll keep those.
:placeholder-shown
------------------
fantasai: :placeholder-shown
Florian: Webkit has it in nightlies
TabAtkins: Yes.
dbaron: We used to as :placeholder. I should put it back.
<Florian> webkit has place-holdershown in nightlies
https://trac.webkit.org/changeset/172826
fantasai: So keep that.
:nth-child( An+B of <selector> )
--------------------------------
TabAtkins: :nth-child( An+B of <selector> ) syntax. This is up to
implementor interest as to if it stays or is punted.
fantasai: So if you have a bunch of hidden aliases and you want to
have even/odd striping you could hide every other.
dino: webkit has this.
fantasai: We have one implementation, it's useful. Everyone else
thinks this is a thing to keep.
Florian: There's author demand in the room.
tantek: Is there anyone else that will implement?
tantek: It's probably at-risk since no one else is jumping.
esprehn: We're not excited about implementing ever increasing
complications. We'd rather authors added classes.
Bert: But that's in the HTML
esprehn: I think we can ask authors to change their HTML.
fantasai: We're failing to fulfill the common use case.
tantek: This is an expansion of :nth-of-type that's what's going on.
dbaron: I thought there was a bunch of author demand, but I only
found a Mozilla bug from Mar 2013 which has 3 people cc'ed.
fantasai: It's not immediately obvious what this bug is.
dbaron: I have seen demand in other places.
leaverou: Authors have been asking for this since :nth-child was
implemented. They thought it would do this and were
disappointed it didn't.
leaverou: I don't think we can make them change their HTML.
tantek: You don't like nth?
esprehn: It's linear behavior in the browser, which isn't
desirable.
<esprehn> or n^2
dbaron: There are performance problems with this stuff that aren't
present with classes and authors use slow selectors
without knowing what's slow.
ChrisL: Forcing people to do even/odd with classes seemed wrong.
plinss: I think we're going in a rat hole.
dbaron: I'm vaguely interested in implementing but it's decent
work?
fantasai: You can't hook into nth-of-type code?
dbaron: It's similar.
tantek: Are there limits that can go on the spec?
fantasai: Maybe. I think the dynamic profile should only allow
some selectors.
dbaron: I don't think limiting helps.
tantek: If you're doing nth of type and you get attr, you've got
attr and class and you can stick language in there.
hober: Our implementation supports complex selectors because
authors want it.
TabAtkins: Complex is combinators.
esprehn: What we're not interested in implementing is the
nest-ability. You can nest :nth-child() inside as deep if
you want.
fantasai: Noooo. That's terrible. I'm 100% for disallowing
:nth-child() nesting.
tantek: I'm going back to limiting to element names, language and
class.
<dbaron> I think people might want pseudo-classes, but...
TabAtkins: The feature selectors are things that don't have colons
on it.
fantasai: Feature selectors, :matches and :not and we'll run with
that for now.
liam: The contents of :not have the same restrictions?
fantasai: Yes.
Florian: So Apple since you have more are the rest used?
smfr: we haven't shipped it yet.
fantasai: It's okay if you implement more.
tantek: If you want to be able to write tests shrinking the
surface is good.
fantasai: I like your thinking.
dbaron: I think the performance characteristics won't be as good
as :nth-child() because we can have caches for levels and
it depends on there only being two things to cache. This
extends to having an arbitrary number of things to cache.
I think if it's not cache-able the performance isn't
acceptable.
fantasai: On the plus side, the vast majority of use cases will
have only two ways of counting the thing.
TabAtkins: We don't cache nth of type so it shouldn't be work.
dbaron: The obvious stupid way to hash is by the memory address.
SimonSapin: Do we want a single selector or more than one?
esprehn: Compound selector is fine.
fantasai: It's the same caching.
RESOLVED: Keep :nth-child(An+B of <selector>) where <selector>
is limited to a compound selector containing only
feature selectors. Absolutely no nesting :nth-child().
Combinators
-----------
fantasai: The descendant selector which is written as >>, we're
proposing to drop.
TabAtkins: We liked it better when we had deep.
fantasai: Everybody agrees?
RESOLVED: drop >>
fantasai: The next is column selectors. For styling tables people
want to do striping on the tables and you can do that by
styling the column elements themselves.
fantasai: However, we don't have a way to say "I want all the cells
in this column to be aligned center" because that
requires applying styles to the cells, and properties
can't inherit from the column to the cell.
fantasai: You have to put this styling on each cell.
fantasai: Note, colum selectors only work on HTML tables. It's
based on the semantic markup. Even if you display the
table in another transformed way, the selections will
work. This solves most of the use cases because the
tables where you want to do this are those with data.
leaverou: Is this solved by the last issue?
fantasai: :nth-child() handle spanning cells.
ChrisL: How does this work with spanning?
fantasai: Depends on your cascade.
leaverou: So is this a pseudo-class that relies on DP?
fantasai: There's a column combinator that expresses the
relationship between a column element and its TD. And
there's the :nth-column() pseudo-classes that apply to
the TD.
liam: I don't see anything in the spec that defines what a column
is.
TabAtkins: It's up to the document language to define what a
column is.
liam: [hesitant yeah]
TabAtkins: The document says what cells make up a column.
liam: It wasn't clear if multi-col is a part of this.
TabAtkins: Not in the document language.
leaverou: So to use this you still need to add <col> elements to
your markup, right?
fantasai: Not for the :nth-child(), but to use column combinator
it only makes sense if you have a column element to
combine.
leaverou: Right.
tantek: Implementations?
TabAtkins: No. I suspect interest is low enough we should put it
off.
tantek: I'd tend to agree.
dbaron: I've seen more demand for this than other things in here.
several: Yeah.
dbaron: I don't like the column combinator syntax. I liked the
pseudo-class one better.
fantasai: This is structural, it's representing the relationship
in the tree, which is what a combinator is. It's just
not expressed by parentage.
dbaron: The number of performance compromises we make with
combinators makes me not want to do combinators.
fantasai: How is that different than pseudo-elements? It's just
syntax.
dbaron: It's not that simple. We're not going to re-write all the
selectors.
TabAtkins: I'll trust you if you say it's difficult for
implementation reasons because we also have weird
things and it's harder to optimize combinators.
dbaron: There's a lot of code where you have to think carefully
about every combinator. When there's four that's doable,
when it's 10 you start being unable to think about that
problem.
Florian: And the pseudo-classes that behave like combinators don't
behave like that?
dbaron: No because they don't break the chain.
<dbaron> td:column(.heading)
dbaron: What I was prop was something like ^
dbaron: That would match a cell with class=heading
<SimonSapin> div col || td p
<TabAtkins> div td:column(col) p
<TabAtkins> ^^^ translation of Simon's case
<fantasai> div td:column(.heading) td p
leaverou: What selectors would that pseudoclass accept?
dbaron: I don't care that much. It has the advantage authors can
see it and figure out what it is, which is harder than two
double bars.
TabAtkins: It's probably equivalent. The only thing that would
make it not equivalent...you could do something with a
<colgroup> and <col> and their relationship and the
combinator, but I don't care.
fantasai: The difference is you could say I'm in:
<fantasai> .foo td:column(.highlight) p
fantasai: Or if you have the column combinator
<fantasai> .foo .highlight || td p
leaverou: What I like about dbaron’s suggestion is that it's more
readable, whereas another combinator is turning
Selectors even more into ASCII art.
fantasai: In the first case the .foo could be the table row but in
the second case it had the be the parent.
fantasai: So you couldn't select in column groups.
dbaron: You could if you allow combinators.
fantasai: Do you want to?
dbaron: Not really.
fantasai: Combinators keep a single path up the tree. You walk to
the tree.
dbaron: From an implementor prospective that's a massive
disadvantage.
fantasai: With your syntax you could branch. Being able to select
on the <col> group is important. Sometimes you'll want
the column, sometimes the column group.
tantek: I'd like to repeat what leaverou said. The more you add
the more CSS resembles Perl.
fantasai: We don't add many, we have four.
tantek: We have a lot of combinators and punctuation. That cost
should not be underestimated. I don't think it's worth it.
TabAtkins: I have nothing against the column pseudo-class. I think
the combinator is more elegant, but if it's easier to
implement or read that's fine.
fantasai: I want this to work for column groups.
TabAtkins: It'll be fine.
leaverou: If we add combinators it should be for cases where
people would see them again and again so they learn them.
If it's for columns people will see them so rarely
people won't get it. And it's hard to Google for it.
fantasai: If this works for column groups it's fine either way.
TabAtkins: So are we marking this as at-risk or punting to level
5? It sounds like there's implementor interest so we
should keep it at 4. Are you okay with this dbaron?
dbaron: I'm okay with either.
tantek: I don't see a downside to punting this.
fantasai: We've had this in since we first drafted this.
rachelandrew: I think it's very useful. It depends on what you're
doing and I spend a lot of time building data tables
and this would be useful. As soon as I saw this I
thought it would be great.
fantasai: There hasn't been discussion on changing :nth-column and
:nth-last-column and that would get you most of the use
cases.
dbaron: And I think they're easier to implement.
fantasai: So push :column() to level 5 unless an implementor wants
to do this, mark :nth-column() and :nth-last-column() as
at-risk
TabAtkins: I'm okay with that.
dbaron: I think maybe.
<dbaron> ... though maybe handling dynamic changes for :column()
isn't actually any harder than the others
fantasai: Okay, I think that's everything in selectors.
TabAtkins: Yes.
fantasai: In that case we should switch. There's still a couple of
issues, but I think I need to talk with dbaron and
TabAtkins separately.
plinss: So not ready to publish?
fantasai: Not yet.
Algorithm for Evaluating Selectors
==================================
fantasai: Let me pull up the issues. There's one major one that's
still open. I'm going to show you what it is and if no
one else cares we can resolve to publish pending the
people that do care agreeing.
<SimonSapin> https://drafts.csswg.org/selectors-4/#evaluating-selectors
fantasai: This is a section where dbaron had comments on it being
the wrong algorithm. If people care how it's written,
raise your hand. I see TabAtkins, dbaron, and SimonSapin.
fantasai: So this is a section with a few problems. The algorithm
isn't used by a UA. The hooks the DOM is using also
isn't correct.
ChrisL: Why is it different?
TabAtkins: Because you can define selectors going left or right or
right to left. Explaining it left to right is easier
once you get multiple trees. But right to left is still
the best approach in an implementation.
hober: Within each tree you can go left to right and read right to
left.
TabAtkins: If people really think it's important to describe the
evaluation to be right to left I can do that.
dbaron: My concern is that there are going to be some things that
are easy to describe in one way. If we build a spec that's
the opposite of how implementors build it we'll end up
with things that are easy to spec or hard to build or the
reverse. There's also a risk of thinking things are the
same and they're not.
TabAtkins: The easy to implement, hard to describe is the
situation we have today.
<bkardell> the spec does say that it's valid to eval them rtl as
long as that elements returned are the same tho
fantasai: The point is nobody disagrees on the functionality, only
on how we describe the functionality. I agree with dbaron
we should try to reword to address his concerns, but I
don't think this is the setting to do this in. I wanted
to bring this up and find out who is interested.
ChrisL: And how does rewriting it affect the HTML WG?
TabAtkins: No effect. This is internal language.
ChrisL: I thought the constraint was schedule and content.
fantasai: That is one problem. I have a problem with how this is
used as the hook. It takes a bunch of inputs that are
complex and it gives you a bunch of outputs that you
have to tell it how to give you. I feel like these are
API-user things the DOM API should specify. We should
only say if the selector matches and the DOM can say go
over the chain and return the list and that would make
the interface between specs a lot simpler.
fantasai: The idea of matching a selector is an old concept and
it's easily consistent forward whereas this will not be
easy to understand and it doesn't match the DOM spec.
That's one of the problems I have and that impacts HTML4.
TabAtkins: I disagree with everything fantasai said and I explained
in an e-mail why so we don't need to discuss it here.
fantasai: These are what needs to be discussed, we should figure
out soonish.
ChrisL: If another group is looking into this that is in scope for
us so I think this does matter.
TabAtkins: In general I agree with that concept.
fantasai: I propose that if people care about how this section is
worded and how DOM and selectors specifically interact
I'd like to know who they are so we can have those
people discuss it.
astearns: bkardell raised his hand.
tantek: I am interested in contributing.
zcorpan: I'm interested.
SimonSapin, TabAtkins, and dbaron are all interested in this issue.
fantasai: So if we can take a resolution pending agreement of this
subset we can do that. Discussing it here won't be
helpful. Does that sound good?
hober: We can publish now with a note saying this might be wrong.
TabAtkins: That we might change all this.
fantasai: The wording might change and that would effect people.
fantasai: Do we want to resolve with wording that this whole
section might be changed?
fantasai: It's a WD. We're far from CR.
Publishing
==========
tantek: A bunch of these features we've asked if anyone has
implemented. There's a handful of selectors I had captured
for CSS UI 4 and there's no evidence of them being
considered. These are all prefixed in Mozilla.
fantasai: I went through the whole list and don't remember seeing
those.
tantek: Broken, suppressed, and a few others.
hober: They're tracked as issues.
tantek: They were considered for CSS UI 4.
Florian: They're in the wiki of 4.
tantek: You want them considered.
hober: Yeah, but I don't care about which document they get
specced in.
fantasai: I think the...we wanted to have things that has a spec
and review and implement. Things that start from scratch
take time. We want this in CR by end of year.
tantek: The things I mentioned are in MDN so it's not from scratch.
<tantek> here is where I've been collecting them:
https://wiki.csswg.org/spec/css4-ui#more-selectors
fantasai: Do they need to be in?
tantek: If there's any other implementors that are interested, yes.
at-risk.
Florian: Could we start level 5 and if they're ready first we suck
this in?
TabAtkins: We have a document of things we've pulled from
selectors 4.
Florian: So call that 5 and put them there.
tantek: Because it's a WD why not 4?
fantasai: I want to trim this and review the heck out of it to get
it ready. To write more things will slow this down.
tantek: These are above the bar on what we've kept.
<tantek> FYI:
<tantek> https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-broken
<tantek> https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-user-disabled
<tantek> https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-suppressed
<tantek> https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-loading
<tantek> https://developer.mozilla.org/en-US/docs/Web/CSS/::-moz-progress-bar
fantasai: There's a limitation on editor resources.
hober: That's the key. I don't think we should hold up your work
for these.
fantasai: If this is all I was working on, sure, but I have 7 other
specs to publish next week, and that's not even all of
them.
tantek: I pasted into IRC where I was tracking the features for
CSS UI 4 and I posted links to the ones that Mozilla has
implemented so that any other implementor can look and
speak up and push something forward. So we can take the
burden off you on evaluating.
fantasai: So. The goal is we want to publish asap. We should
resolve to publish with all edits, agree with the group
for editing, or with a note saying this section might be
changed or deleted or whatever? HTML WG wanted us to
publish a week ago.
tantek: The HTML group?
<tantek> there hasn't been an HTMLWG telcon in months
<tantek> so I don't understand how this request can come from "The
HTML group"
plinss: Let's not rat hole.
dbaron: Is the thing they want to reference is the algorithm? If
that's the case I'd like to hold off until we sort it out.
TabAtkins: What are they caring about?
fantasai: DOM 4
TabAtkins: It's an obsolete spec. It has a lot of errors. We block
it and we actively block it. I will block it for you.
tantek: The easiest way to block would be to drop this section.
TabAtkins: The real DOM needs it and is using it so it needs to
stay.
fantasai: If we don't publish we'll have plh say we're publishing
now.
plinss: Can we move on?
fantasai: We'll worry about publishing after solving this thing
per dbaron's request.
ACTION fantasai: work on the algorithm problem with the team you
have assembled
<trackbot> Created ACTION-719
plinss: Has anyone heard from jdaggett?
dbaron: He said he'd be back after 2pm.
<tantek> sidenote: re: selectors-4 issue 12 ":dirty" pseudo-class -
I really dislike the term :dirty - it is very programmer
specific. I think something like :user-changed would be
better since it parallels :user-invalid / :user-value -
and should be triggered by ANY user action that changes
the state of the control, e.g. typing, paste from
clipboard, and right click / context-menu to insert (or
again, paste)
<tantek> aside: I now have a public real world example of an input
using :-moz-ui-invalid and :-moz-ui-valid - polyfilled to
"work" while the user is typing, even before blurring the
input element (which is the desired behavior)
http://tantek.com/relmeauth/
Received on Monday, 14 September 2015 18:00:07 UTC