Hey Demetrios,

Thank you for raising the issue. However, I think this discussion is likely
better suited for a spec venue like WHATWG (
https://github.com/whatwg/html/issues).

As far as I can tell, Blink/Chromium implements the specified behavior. It
seems like this causes problems, so maybe we should revisit whether the
spec should change.

Thanks,
Vlad

On Thu, Feb 12, 2026 at 7:41 PM Demetrios Papadopoulos <[email protected]>
wrote:

> Reviving this older through about the hidden="until-found", since it seems
> to be causing issues (newly thrown TS compiler errors with the upcoming TS
> v6) due to HTMLElement's hidden property channging from a boolean to
> boolean|"until-found". Plese see my comment at
> https://github.com/web-platform-dx/developer-signals/issues/170#issuecomment-3894089666
> for more details. Wondering if the complications with changing the
> property's type was already considered, and whether there is any workaround
> beyond just trying to accomodate for the new type across a codebase.
>
> Thanks!
> On Wednesday, March 23, 2022 at 8:25:53 AM UTC-7 Daniel Bratell wrote:
>
>> LGTM3
>>
>> /Daniel
>> On 2022-03-23 05:50, Yoav Weiss wrote:
>>
>> LGTM2
>>
>> On Thursday, March 17, 2022 at 8:10:47 PM UTC+1 Joey Arhar wrote:
>>
>>> Contact emails [email protected]
>>>
>>> Explainer
>>> https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md
>>>
>>> Specification https://github.com/whatwg/html/pull/7475
>>>
>>> Design docs
>>> https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md
>>>
>>> Summary
>>>
>>> This feature extends the existing hidden attribute with a new value,
>>> "until-found", which makes the element searchable by find-in-page, scroll
>>> to text fragment, and fragment navigation. When these search/navigation
>>> features want to scroll to something inside a hidden=until-found element,
>>> the browser removes the hidden attribute from the element and fires the
>>> "beforematch" event on it so that the newly revealed content can be
>>> scrolled into view.
>>>
>>>
>>> Blink component Blink>HTML
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML>
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/511
>>>
>>> TAG review status Issues addressed
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risks: This feature is built on content-visibility,
>>> which is gradually being implemented in other browsers. The way this
>>> feature extends the existing hidden attribute means that browsers which
>>> don't implement this feature will still render hidden=until-found content
>>> as expected, but without the new find-in-page and ScrollToTextFragment
>>> auto-revealing functionality. Mozilla says this feature is worth
>>> prototyping. Compatibility risks: This feature is unlikely to break
>>> existing websites because they must opt-in by setting the "hidden"
>>> attributes on elements to "until-found". In the unlikely event that
>>> existing websites use hidden=until-found, it will just replace their
>>> "display:none" with "content-visibility:hidden" which will likely render
>>> the same.
>>>
>>>
>>> Gecko: Worth prototyping (
>>> https://github.com/mozilla/standards-positions/issues/612)
>>>
>>
>> I'll just note that this is not yet the official label, although it seems
>> like it's going that way.
>>
>>
>>>
>>> WebKit: No signal (
>>> https://lists.webkit.org/pipermail/webkit-dev/2022-March/032142.html)
>>>
>>> Web developers: No signals
>>>
>>> Other signals:
>>>
>>> Ergonomics
>>>
>>> This feature can be used in tandem with scroll to text fragments. This
>>> feature will not make it hard for Chrome to maintain good performance.
>>>
>>>
>>> Activation
>>>
>>> This feature will benefit from having example code in the explainer repo
>>> to show developers how to use it.
>>>
>>>
>>> Security
>>>
>>> What the user types into the find-in-page box should not be visible to
>>> websites, and the beforematch event is a new way for websites to try to
>>> read this information on top of the existing scroll events. I created a
>>> privacy mitigation for all of these attack surfaces for find-in-page by
>>> adding a delay before find-in-page scrolls text into view when needed so
>>> websites are unlikely to be able to incrementally build what the user is
>>> typing into find-in-page.
>>>
>>>
>>> WebView Application Risks
>>>
>>> *Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?*
>>> No
>>>
>>>
>>> Debuggability
>>>
>>> There are no DevTools features for the scrolling, URL fragment, and
>>> event firing impacts that beforematch has.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>> ? The find-in-page portion of this feature can't be tested because
>>> find-in-page can't be tested in WPT yet:
>>> https://github.com/web-platform-tests/wpt/issues/29915
>>> Here are some tests which I will try to move to WPT soon:
>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/display-lock/beforematch/
>>> Here are WPTs for the hidden IDL changes to allow "until-found":
>>> https://github.com/web-platform-tests/wpt/pull/32465
>>>
>>> Flag name --enable-blink-features=BeforeMatchEvent
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1055002
>>>
>>> Launch bug https://bugs.chromium.org/p/chromium/issues/detail?id=1302408
>>>
>>> Estimated milestones
>>>
>>> 102
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5400510406328320
>>>
>>> Links to previous Intent discussions Intent to prototype:
>>> https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/beforematch%7Csort:date/blink-dev/QKUZ_ALJdM8/j6daEdmUAgAJ
>>> Intent to Experiment:
>>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/aTrk7__Eiq4/BOGSzGHeAwAJ
>>>
>>>
>>> This intent message was generated by Chrome Platform Status
>>> <https://chromestatus.com/>.
>>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>>
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5930d990-4a7c-4dea-8952-23bcb7d68e8dn%40chromium.org
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5930d990-4a7c-4dea-8952-23bcb7d68e8dn%40chromium.org?utm_medium=email&utm_source=footer>
>> .
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3c0f15c2-ed6a-460e-b309-a5e9b198239fn%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3c0f15c2-ed6a-460e-b309-a5e9b198239fn%40chromium.org?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2M1OzOo2Bh8mzcj35SL4tyFBvNtNn4nCWCX3oLTeN_hZg%40mail.gmail.com.

Reply via email to