W3C home > Mailing lists > Public > www-style@w3.org > September 2015

[CSSWG] Minutes Paris F2F 2015-08-27 Part III: Selectors [selectors4]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 14 Sep 2015 13:59:07 -0400
Message-ID: <CADhPm3v+WfeGQfBwwx8QBuiOjn2k38V_DcKW17Cm81VgZb1nbQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:33 UTC