- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Feb 2021 19:21:39 -0500
- 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