W3C home > Mailing lists > Public > www-style@w3.org > February 2021

[CSSWG] Virtual F2F 2021-02-09 Part II: Selectors 4, CSS Contain [selectors-4] [css-contain]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 24 Feb 2021 19:21:39 -0500
Message-ID: <CADhPm3s65QWda54Q_FAN3WT0Yk4jeyD3LDY+kzN3uLnsZ9d5Zg@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Selectors 4
-----------

  - RESOLVED: Remove the example (Issue #4278: Browser focus styles
              and focus-visible, example 38)

CSS Contain
-----------

  - The TAG has reviewed issue #5595 (Proposal: content-visibility:
      hidden-matchable) and believed it did belong in CSS. However,
      there was disagreement from within the group about that.
  - There are also still ergonomic concerns about the design of the
      property, particularly its inability to be useful without JS,
      as well as concerns about adding a new visibility state
      and about the event model.
  - The call ran out of time before a decision could be reached.
      Discussion of the concerns continued on IRC and moved to GitHub
      and will be added back to a future meeting.

===== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/csswg-drafts/projects/14

Scribe: myles

Selectors 4
===========

Browser focus styles and focus-visible, example 38
--------------------------------------------------
  GitHub: https://github.com/w3c/csswg-drafts/issues/4278

  rego: florian reported it, but I added it to the agenda
  rego: florian was asking about :focus-visible in the spec. Was asking
        about using :focus-visible to remove the old line from the
        element
  rego: The thing is that, this was confusing to some people, and kind
        of a hack to disable the whole line instead of the focus when
        you have focus visible, to see the whole line but not always
  rego: This is kind of confusing. You expect when it matches
        focus-visible, it matches only when the outline is painted.
  rego: And if it's not painted it's not
  rego: Chromium was not using that in its default visible. So you
        would get an outline but the element wasn't matching
        focus-visible
  rego: Chromium's impl is updated. The default stylesheet uses
        :focus-visible. So this example can be removed from the spec.
        Because it was only due to some browsers' implementations.
  florian: We should double remove it.
  florian: This is no longer how browsers work. It shouldn't stay
           there. Also, even when we were before that change, specs
           are a bad place to put descriptions of hacks you need to
           use to force browsers to not follow the spec behave
           correctly. And if we do that, it needs to be described
           deliberately
  florian: Now that it's no longer relevant, remove it, and if we need
           to highlight workarounds in the spec, be clear they are
           workarounds.
  rego: So the proposal is to remove the example from the spec
  bkardell: We should remove it. My recollection is that we added that
            to help people understand what it was doing, because you
            could explain that focused matched all the time, and
            people said it this way, but people wanted to remove it
            when that wasn't the case. But that made it into the spec
            in a way that it should not have. We should take it out.
  Rossen: Proposed resolution: remove the example
  ??: Do we need a resolution to remove an example?
  [Technically no, but]
  <fantasai> If we agree on something, we resolve on it, so it's clear
             there was an agreement.

  RESOLVED: Remove the example

CSS Contain
===========

Proposal: content-visibility: hidden-matchable
----------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5595

  jarhar: content-visibility: hidden-matchable allows the UA to search
          for content inside the content, for like find-in-page, which
          will fire an event before the browser scrolls, which allows
          you to report a match before the browser does. There was a
          TAG review. We brought up reader mode, a11y, and css
          property vs html attribute. The TAG review has been
          approved. Looking forward to the next steps

  emilio: I still feel like ... this allows the page to show content
          in response to ... putting this property on an element
          interacts with beforematch which allows you to show the
          content, and the page needs to a handshake with the browser,
          where the browser fires an event, and asynchronously will
          restart the search after the next runloop .... I haven't
          thought deeply about alternative solutions to this, but it
          sounds like complex, hard-to-get-right solution
  emilio: That's my main concern.
  emilio: I'm not sure how people are going to use this.
  emilio: Ideally, I think the UA could show the content instead, but
          that's hard with it being a CSS property. It being an
          attribute could maybe allow this, but it restricts how
          authors can hide the content.
  <tantek> +1 emilio

  <tantek> trying to read https://github.com/w3ctag/design-reviews/issues/511
           to understand why it was considered acceptable to consider
           this as a CSS property (seem very much tied to content
           semantics)

  smfr: I just wanted to reiterate what I said in the past. I don't
        like how we're adding yet another state to the whole
        display:none content-visible visibility:hidden matrix. Will
        add complication in the future. I agree with emilio about the
        beforematch algorithm is complicated and error-prone. I would
        prefer the UA is the one to reveal the content.
  smfr: I still think that the fact that UAs that have reader mode
        basically mostly undoes the optimization that is
        content-visibility:hidden-matchable is unfortunate. I'm not
        sure anyone in TAG was representing UAs that have reader mode
        and would be impacted by that
  Rossen: We've been shipping reader mode for quite some time
  <tantek> +1 strong agreement with smfr. the complexity this adds to
           the author model (display:none, visibility:hidden, etc.)
           makes a bad thing worse.
  smfr: In order to get reader mode correct you have to resolve styles
        and layout inside content-visibility:hidden-matchable, which
        defeats the optimization where the browser can skip layout. So
        if your UA needs to look through the page content to determine
        if there is reader-able content, it would have to do almost
        all the work you would have to do if you had the real content.
        So it's unfortunate we've designed a feature that has that
        performance trap. Performance will not be portable between
        implementations.
  Rossen: You're under the assumption that reader mode won't take
          advantage of content-visibility:hidden-matchable the way the
          regular presentation in non-reader mode would do it. I'm not
          sure how all reader mode implementations are done.

  fremy: My impression of the use case, let's say you have a book or a
         long word document, you already know the text on each page,
         but you don't want to lay out the whole book before the user
         can see the first page. So you'll put each page in a div, and
         you want the user to search through the book, and so if the
         user agent finds some text on page 30, the UA goes to page 30
         and says to the website, I'm about to display page 30, please
         re-lay-out
  fremy: I don't see any other way you can do that optimization. If
         you were to hook up directly into the browser UI... when I'm
         first loading the webpage, don't do a whole layout, but when
         you search on page 30, the browser really needs page 30.
         Before the browser actually scrolls to page 30.
  fremy: If you have reader mode, it can just stop doing layout
         eventually... like if you have already 10 pages, just stop
         laying out, and if the user scrolls, then continue. Or you
         could skip dirty page of the book and do the layout later. If
         I have a book, I should be able to say "layout just the pages
         I need, but search through the entire book"

  chrishtr: It's not hard for sites to implement against this feature.
            We've found the opposite with experiments in partners.
            These are sections of the UI in the page that are already
            there and there are already a click handler that shows the
            hidden section. So the click handler is registered against
            another event and that's all you do
  chrishtr: All these points about reader mode were discussed multiple
            times in previous CSSWG meetings. We all agreed we would
            defer to the upcoming TAG review for them to weigh in on
            it.
  chrishtr: There are no new arguments here. I am expressing
            frustration.
  <tantek> +1 chrishtr, this is my recollection also
  Rossen: I appreciate, the function of the TAG is not to make
          decisions on behalf of CSSWG. CSSWG is the venue for this.
          It's up to us, not the TAG
  Rossen: From architectural point of view, it makes sense.
  <tantek> +1 myles, we have these issues AND there should be a TAG
           review

  smfr: Clarification in response to fremy: find has to resolve styles
        and do some amount of layout to determine if something should
        be shown. It will not show things that are 1px tall, not show
        display:none. So when you have hidden-matchable stuff ...
        <missed>
  smfr: the problem with reader is detection, not display. We show a
        badge to let the user opt-in to reader.

  emilio: Regarding complexity: the feature gets disabled once the
          page happens to not show the element in time. Because that's
          racey. Not only racey with loading, but other user actions.
          If the user hides by clicking on the icon in the next event
          loop turn, the page will not be able to show anything, or
          find again, ever.
  emilio: There are other tasks that shows the element, the find
          process is ... you cannot use the feature any more. which is
          kinda weird
  Rossen: Do we have an issue on this
  emilio: I raised it on the HTML spec issue. This issue is spread
          around so much, I don't even know where I ....
  emilio: I don't want to formally object, because I don't have a
          better solution that addresses all the features, but I don't
          want to be unconstructive. But ....

  chrishtr: Can we move forward and work through these issues?
  Rossen: Many issues.
  chrishtr: Can we just resolve that we'll generally add the features
            and work on the details later
  emilio: The details are important.
  <tantek> I would object to starting the work without considering an
           attribute instead
  <tantek> and I think the TAG neglected that part of the review
  Rossen: The expectation is that we're resolving on starting the
          work, not ending the work. I heard 3 or 4 major issues that
          people want to put forward for this feature. I didn't hear a
          major objection that says "the feature doesn't make sense,
          or belong to CSS" which is what we're trying to identify in
          order to add this to our charter
  Rossen: Unless we think this doesn't belong to CSS then ....
  tantek: I think it doesn't belong to CSS.
  tantek: Fundamentally this is about the semantics of content. I'm
          surprised this has gotten this far as a CSS property because
          this should be in HTML. This is about whether content should
          be searchable, which is semantic. Meaningful = shows up in
          searches. I am surprised this even got so far. I read TAG
          issue 511, and it's pretty thin on whether it should be a
          CSS property or an HTML attribute. The TAG didn't come to a
          good conclusion there. This WG should have the purview to
          question and push back on it.
  tantek: The ergonomic issues that smfr and emilio are sufficient to
          object to starting work, until: 1. it becomes an HTML
          attribute, and works well with summary and details elements,
          which is where the use cases would work "despite the fact
          it's in details, it should be searchable". Once we get that,
          then I'd be open to re-opening the discussion about the CSS
          interaction: the visibility model and the layout. Until
          that, we are jumping the gun and it will be bad
  chrishtr: HTML attributes are already brought up to the TAG.
            Semantics are mixed between CSS and HTML. Alice, an
            expert, says there are plenty of other semantics things
            that are in CSS
  tantek: The excuse "there are already other things in CSS" is not a
          good excuse at all. Just because there is some overlap
          doesn't mean we should continue being sloppy. I have great
          respect for Alice, though.
  chrishtr: There are arguments in the issue about why it makes sense
            to be a CSS property. Please respond to those. Please look
            at the issue and see the arguments I'm making, try to
            respond to them, and we can have a constructive discussion
  tantek: I did.
  chrishtr: The TAG did think deeply about this.
  <tantek> the text in 511 does not back that up
  Rossen: Yes we did! We considered the presentation model of this,
          compared to other ways in CSS to hide and reveal content. We
          did consider HTML API surface and the event model and how it
          fits. This was not a lightweight flippant "go ahead we don't
          want to deal with this" review.
  Rossen: I appreciate the candor here but this is not how things went
          there.
  tantek: Your description doesn't match issue 511.
  tantek: There needs to be more discussion there.
  Rossen: Feel free to add to the tag review additional questions or
          reopening it if you want to.
  Rossen: If you believe this doesn't belong to CSS primarily, please
          reopen.
  <tantek> If there's an hour of minutes about that, please point to
           that. that was not clear at all in 511
  Rossen: This topic has been discussed for hours before in CSSWG, and
          1 hour in TAG, specifically on that topic. We did discuss
          the entire name computation model for aria and other
          a11y-related topics and whether it makes sense. It does. We
          talked about the visual presentation and how contents vs
          content-visibility and how it works. If we had
          display-contents:none with searchable, that would be sort of
          this feature is describing, similar to the way we hide boxes
          for elements that are represented in HTML and in the DOM
          while these elements are searchable and matchable, with
          display:contents
  Rossen: If you're arguing about this not being in CSS, then you're
          also arguing against a bunch of parts of CSS which have
          already shipped
  Rossen: I find it very surprising to hear the fact that you're
          arguing against a large discussion and reasoning in TAG on
          the basis, and dismissed it as a "light" discussion. It was
          not a light discussion. I'm not going to force a resolution
          though. I will give people 1.5 days to cool off on this
          issue.
  Rossen: I'm happy to have this as the opening topic on Thursday when
          Alan is going to chair. And have the final resolution
          adopting this as part of CSS charter, and starting work, not
          ending work, and having this to be formally objected and
          brought back to the objection counsel for resolution
  <tantek> clearly there are many aspects we disagree on

  Rossen: I need to end the meeting. Please don't talk over me. We
          resume back on Thursday afternoon pacific time. Please stay
          healthy and happy

++ IRC and phone conversation after the meeting ++
  phone conversation [intermittent] scribe: fantasai

  <tantek> irony here is that trying to search for "attribute" in the
           github issues, I'm not seeing any results from inside the
           closed disclosure triangles of minutes etc.
  <tantek> this isn't just about what *can* (or should) go in CSS or
           HTML (though yes that's an issue)
  <tantek> this is also about fitting in well with existing features,
           in this case the summary/details element pair
  <florian> tantek, maybe summary/detail should be using this system…
  <fantasai> summary/detail should "just work" wrt matching content
             inside
  <fantasai> imho
  <fantasai> regardless of what happens here in this issue
  <tantek> per florian's request, this comment would be greatly
           improved by linking to the respective minutes of the
           "Kronos" meeting that is referenced:
           https://github.com/w3ctag/design-reviews/issues/511#issuecomment-767932845
  <tantek> fantasai, I think I agree with that default. Maybe that's
           worth filing a bug against the HTML spec?
  <fantasai> "If a fragment ID or find-in-page targets content inside
             a closed details element, it should auto-open the
             element. Otherwise it's confusing."
  <fantasai> anything more to add to the issue?
  <tantek> strongly agreed with hober. TAG should be asked for
           guidance and input, not "deferred to"
  <tantek> FWIW <details> should have been searchable by default
  <tantek> discussion of lack of implementer interest incubation
  <tantek> and encouraging fast failure of incubations
  <tantek> I noted the difference between lack of interest, and active
           disinterest, discomfort, or even resistance from other
           implementers
  <tantek> need separation of use-cases (explainer) and specific
           solutions (proposals)
  <tantek> the example of a book with chapters is a good one. you
           don't want to display all the chapters but you want to be
           able to search the entire book

  florian: Incubation is the phase in which you're trying to convince
           people
  florian: If someone wants to keep trying, let them keep trying. But
           not graduate until convinced other people.
  hober: generally, yeah, but chairs also have to manage time
  florian: incubation is the set of practices where you go from ideas
           about what you need to "this is officially on standards
           track"
  florian: identifying use cases, coming up with potential solutions,
           assessing strengths and weaknesses of solutions, convincing
           ppl you're on the right track
  florian: Once ppl convinced you're on the right track, can start
           standardizing
  florian: this proposal is in the uncomfortable place of not being
           obviously wrong, but not being obviously right to enough
           people
  astearns: we have agreement that we should work on the problem, but
            not on the solution; but only one group is working on it,
            don't have an alternate proposal

  <fantasai> https://github.com/whatwg/html/issues/6370
  <fantasai> chrishtr, smfr ^
  <tantek> fantasai, re: https://github.com/whatwg/html/issues/6370,
           that's also missing a key piece that the text in <details>
           SHOULD be findable by default. Feels like potentially a
           separate issue (be findable, then yes, when found, open it)
  <fantasai> tantek, add a comment?
  <tantek> wasn't sure because it feels like a different issue? to be
           cross-linked of course
  <fantasai> nah, just put it in
  <fantasai> if it needs splitting out, can be split out, but they
             kinda go together
  <tantek> they do kinda go together

  <tantek> I don't think I agree with "bias towards action" in the
           context of improving the web platform, I think that's how
           you end up bloating the platform with a lot of hastily
           designed features
  jensimmons: websites have to ship in 6 months, but this is the
              foundation
  jensimmons: need to look forward 50yrs, 20yrs
  jensimmons: what we add is permanent, need good solutions not fast
              ones. We need regions 5 years ago, still don't have it
              because we don't have a good solution yet
  jensimmons: I'm frustrated by that, but I agree with waiting for a
              good solution, because what we need is a good solution
  <fantasai> +1
  <tantek> +1 to what jensimmons is saying
  <tantek> I think platform ergonomics is MUCH more important than
           "bias towards action"
  christr: It's just a small feature
  smfr: It's more than that, it's an entirely new visibility state
  tantek: it's not about the number of properties or complexity of the
          algorithm, but it's at the interface between semantics and
          presentation and that's what makes it complex
  smfr: Shouldn't collapsed sections be accessible without JS enabled?
  smfr: revealing content should just be done by the UA
  <tantek> +1 smfr, simple thing should be possible without script

  <nicole> @tantek you aren't wrong regarding poorly designed
           features. Can be de-risked with well chosen developer
           partners and incremental testing?
  <nicole> When we don't bias toward action developers chooses native
           apps over the web
  <nicole> So how to balance the two opposing (but important) goals
  <florian> nicole, maybe that's OK? Native apps platform don't all
            last as long as the web
  <nicole> It matters when users make the same choice... e.g. they
           think of the web as something they access through the
           facebook app
  <tantek> I don't really believe in the native app as bogeyman.
           native apps are ephemeral fruit flies. they live much
           shorter lives than websites.
  <nicole> Because then momentum is on the wrong side. It feeds into
           devs choosing apps and then more users choosing apps
  <fantasai> smfr: Should be able to make this work without JS
  <nicole> Um, facebook is ephemeral?
  <tantek> florian is right too, native app platforms / APIs
           themselves are ephemeral compared to the web
  <tantek> facebook is a website
  <tantek> their apps are ephemeral
  <nicole> I'm not talking about a bogeyman, I mean literally users
           spending more and more time in apps.
  <nicole> time spent on their phones
  <astearns> I have never been convinced that we should accept
             attention-time as an OKR of the web
  <nicole> To be clear, I don't believe in the "web is dying"
           bogeyman. But I do think it's likely to need to massively
           reinvent itself.
  <nicole> We probably need to start thinking of more of these apps as
           "browsers"
  <nicole> For example, pinterest, it lets you browse the web through
           the lens of photos and pins
  <nicole> Is it not a browser?
  <tantek> I'm not sure what pinterest is except an inaccessible
           aggregator of images optimized for Google SEO :P
  <nicole> Anyway, my real point was that both the desire to ship
           quickly and the desire to ship the right thing are
           valuable goals
  <nicole> AND can be opposition to one another

  <fantasai> https://drafts.csswg.org/css-contain-2/#content-visibility

  <tantek> fantasai brought up the 'hidden' attribute and how it was
           created maybe too late compared to display:none to be
           properly designed together, and this made me wonder if
           there was more we could have done there, or can do there now
  <tantek> since 'hidden' is a boolean attribute, adding new values
           that work like the existing default but with some
           additional functionality is potentially backcompat
  <tantek> e.g. (just off the top of my head) hidden='findable' would
           have the right backcompat fallback behavior
  <tantek> to be clear, this is not a formal proposal, nor is it meant
           to be treated as something "instead of" a CSS property, but
           rather as another aspect to expand the discussion space
  <tantek> obviously there are very different ergonomics between an
           HTML attribute (even "just" a new value) and a CSS property
  <tantek> there are also other examples of where we've had a division
           of responsibilities / powers / capabilities between markup
           and styling
  <tantek> e.g. direction attribute vs property
  <tantek> e.g. lang attribute and :lang selector
  <tantek> I think there are some ergonomically positive aspects to
           separating semantic being expressed vs a desired behavior
  <fantasai> +1
  <tantek> I will also note that I looked into mobile Wikipedia and it
           does NOT use summary/details (really long h2 and div/span
           etc. markup)
  <tantek> However GitHub *does* use summary/details and thus would be
           improved by fixing the default findability of details
           elements per https://github.com/whatwg/html/issues/6370
  <tantek> (like we'd be able to "find" on a GitHub issue and text
           inside any CSS discussions would be found)
  <tantek> CSSWG* telecon discussions
Received on Thursday, 25 February 2021 00:22:21 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 25 February 2021 00:22:22 UTC