- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Feb 2021 18:02:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-2] Proposal: content-visibility: hidden-matchable`. <details><summary>The full IRC log of that discussion</summary> <Rossen_> Topic: [css-contain-2] Proposal: content-visibility: hidden-matchable<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5595<br> <Rossen_> q?<br> <emilio> q+<br> <myles> 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<br> <smfr> q+<br> <myles> 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<br> <myles> solution<br> <myles> emilio: that's my main concern.<br> <myles> emilio: I'm not sure how people are going to use this.<br> <Rossen_> ack emilio<br> <fremy> q+<br> <myles> 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.<br> <chrishtr> q+<br> <tantek> +1 emilio<br> <Rossen_> ack smfr<br> <myles> 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 visibilty: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.<br> <myles> 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<br> <myles> Rossen_: we've been shipping reader mode for quite some time<br> <tantek> +1 strong agreement with smfr. the complexity this adds to the author model (display:none, visibility:hidden, etc.) makes a bad thing worse.<br> <Rossen_> q?<br> <myles> smfr: In order to get reader mode correct you have to resolve styles and layout inside content-visiblity:hidden-matchabe, which defeats the optimization wehre the browser can skip layout. So if your UA needs to look through the page content to determine if there is readerable content, itw ould 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.<br> <myles> Performance will not be portable between implementations.<br> <bkardell_> q+<br> <myles> Rossen_: You're under the assumption that reader mode won't take advantage of content-visbility: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.<br> <Rossen_> ack fremy<br> <myles> 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<br> <myles> 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.<br> <myles> 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 shoudl be able to say "layout just the pages I need, but search through the entire book"<br> <smfr> q+<br> <bkardell_> q-<br> <Rossen_> ack chrishtr<br> <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)<br> <myles> 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 int he 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<br> <myles> 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.<br> <myles> chrishtr: There are no new arguments here. I am expressing frustration.<br> <tantek> +1 chrishtr, this is my recollection also<br> <myles> 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 hte TAG<br> <myles> Rossen_: From architectural poitn of view, it makes sense.<br> <tantek> +1 myles, we have these issues AND there should be a TAG review<br> <tantek> q+<br> <Rossen_> ack smfr<br> <tantek> q++ emilio<br> <tantek> qq+ emilio<br> <tantek> q- +<br> <tantek> q- later<br> <myles> 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><br> <myles> smfr: the problem with reader is detection, not display. we show a badge to let the user opt-in to reader.<br> <Rossen_> ack emilio<br> <Zakim> emilio, you wanted to react to smfr<br> <Rossen_> ack emilio<br> <myles> 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.<br> <myles> emilio: There are other tasks that shows the element, the find process is ... you cannot use the feature any more. which is kinda weird<br> <myles> Rossen_: do we have an issue on this<br> <myles> emilio: I raised it on the HTML spec issue. This issue is spread around so much, i don't even know where I ....<br> <myles> 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 ....<br> <fremy> q+<br> <myles> chrishtr: Can we move forward and work through these issues?<br> <myles> Rossen_: many issues.<br> <myles> chrishtr: Can we just resolve that we'll generally add the features and work on the details later<br> <myles> emilio: the details are important.<br> <tantek> I would object to starting the work without considering an attribute instead<br> <tantek> and I think the TAG neglected that part of the review<br> <tantek> q?<br> <myles> 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<br> <myles> Rossen_: unless we think this doesn't belong to CSS then ....<br> <myles> tantek: I think it doesn't belong to CSS.<br> <Rossen_> la<br> <Rossen_> q<br> <Rossen_> ack tantek<br> <myles> 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 contetn shoudlb e searchable, which is semantic. Meaningful = shows up in searches. I am surprised this even got so far. I read TAG 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<br> <myles> have the purview to question and push back on.<br> <myles> 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 teh layout. Until that, we are jumping the gun and it<br> <myles> will be bad<br> <myles> chrishtr: HTML attributes are already brought up to the TAG. Semantics are mixed between CSS and HTML. Alice, and expert, says there are plenty of other semantics things that are in CSS<br> <Rossen_> q?<br> <myles> 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.<br> <Rossen_> Zakim, close queue<br> <Zakim> ok, Rossen_, the speaker queue is closed<br> <myles> chrishtr: There are argumetns 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 discsusion<br> <myles> tantek: I did.<br> <myles> chrishtr: The TAG did think deeply about this.<br> <tantek> the text in 511 does not back that up<br> <myles> 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.<br> <myles> Rossen_: I appreciate the candor here but this is not how things went there.<br> <myles> tantek: Your description doesn't match issue 511.<br> <myles> tantek: There needs to be more discussion there.<br> <myles> Rossen_: Feel free to add to the tag review additional questions or reopening it if you want to.<br> <myles> Rossen_: if you believe this doesn't belong to CSS primarily, please reopen.<br> <tantek> if there's an hour of minutes about that, please point to that. that was not clear at all in 511<br> <myles> 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 visula presentation and how contents vs content-visiblity 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<br> <myles> hide boxes for elements that are represented in HTML and in teh DOM while these elemnts are searchable and machable, with display:contents<br> <myles> 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<br> <myles> 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.<br> <myles> 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 counsil for resolution<br> <tantek> clearly there are many aspects we disagree on<br> <myles> fremy: smfr, can I talk to you?<br> <myles> 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<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-776129419 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 February 2021 18:02:54 UTC