[blink-dev] Intent to Prototype: CSS line-clamp property

Contact emails abote...@igalia.com Explainer https://github.com/Igalia/explainers/blob/main/css/line-clamp/README.md Specification None. CSS Overflow Module Level 4 defines a version of the line-clamp property (https://drafts.csswg.org/css-overflow-4/#line-clamp), but that is a different versio

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

As for having a premonition that this would be added, there is at least one post in the original Github issue saying that the poster already expected the two-argument overload to be supported (https://github.com/whatwg/url/issues/335#issuecomment-919700370). Andreu On 5/18/23 23:42, PhistucK

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

an I'd expect for an argument that didn't do anything before, so likely the value passed doesn't make sense and will result in the parameter not being deleted for delete(), which could be a problem. What can you say about usage in the wild here? +Andreu Botella <mailto:abot

Re: [blink-dev] Intent to Ship: Fetch: Headers.getSetCookie()

headers somehow in the actual connection with the proxy server, so they aren't filtered out. On 2/23/23 10:23, Yoav Weiss wrote: On Thu, Feb 23, 2023 at 10:14 AM Andreu Botella wrote: Sorry for taking so long to reply. One possible client-side use case enabled by this add

Re: [blink-dev] Intent to Ship: Fetch: Headers.getSetCookie()

Sorry for taking so long to reply. One possible client-side use case enabled by this addition is as part of a JS API for a proxy, possibly one that allows access to public servers that aren't CORS-accessible: // example.com doesn't support CORS! const {headers, body} = proxyFetch("https://exa

[blink-dev] Intent to Ship: Fetch: Headers.getSetCookie()

Contact emails abote...@igalia.com, ri...@chromium.org Explainer None Specification https://fetch.spec.whatwg.org/#dom-headers-getsetcookie Design docs https://github.com/whatwg/fetch/issues/973#issuecomment-902578584 https://github.com/whatwg/fetch/issues/9

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

Oct 29, 2021 at 9:41 AM Chris Harrelson > wrote: > >> LGTM3 >> >> On Fri, Oct 29, 2021 at 12:18 AM Manuel Rego Casasnovas >> wrote: >> >>> LGTM2 >>> >>> On 29/10/2021 06:56, Yoav Weiss wrote: >>> > LGTM1 >>> &

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

do we have anywhere written what > are the browser's differences on structured clone algorithms? Is it a spec > issue? Could we add WPT tests for it? > > On Wed, Oct 27, 2021 at 2:45 PM Andreu Botella > wrote: > >> * Contact emails* >> and...@andreubotella.com,

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

32 AM UTC+8 fs...@chromium.org >> wrote: >> >>> This is amazing! :) >>> >>> I agree it shouldn't block this, but do we have anywhere written what >>> are the browser's differences on structured clone algorithms? Is it a spe

[blink-dev] Intent to Prototype and Ship: self.structuredClone

* Contact emails* and...@andreubotella.com, jbro...@chromium.org, su...@chromium.org *Explainer* https://github.com/whatwg/html/issues/793 *Specification* https://html.spec.whatwg.org/#structured-cloning * Summary* Enables using the HTML structured clone algorithm synchronously for cloning a

Re: [blink-dev] Intent to Ship: Late newline normalization in form submission

Just to clarify: inspecting a FormData object isn't the only way to observe this change. If you call fetch() with a FormData body, have a form-associated custom element whose submission value is a FormData, or modify a form's entry list through the FormData object passed in the formdata event,