Re: Custom Elements: is=""

My current understanding of "is=" is a request for an implementation to "plug-in" a native element's backing behavior under a custom element name. This feature would otherwise not be available without is=, as custom elements are always generic by design. As Dimitri has noted in the past, I thin

Re: CORS performance proposal

> On 9 Jun 2015, at 2:54 pm, Anne van Kesteren wrote: > > On Tue, Jun 9, 2015 at 6:42 AM, Martin Thomson > wrote: >> The security properties bother me a little. Alt-Svc is showing us >> that we can't just define a header field like that without some >> serious analysis. > > Same goes for a s

Re: CORS performance proposal

On Tue, Jun 9, 2015 at 6:42 AM, Martin Thomson wrote: > The security properties bother me a little. Alt-Svc is showing us > that we can't just define a header field like that without some > serious analysis. Same goes for a site-wide file. See crossdomain.xml. However, either coupled with "crede

Re: CORS performance proposal

> On 9 Jun 2015, at 2:42 pm, Martin Thomson wrote: > > On 8 June 2015 at 21:30, Nottingham, Mark wrote: >> A header denoting site-wide metadata would work for this too, of course, if >> folks were comfortable with the security properties of doing that (as well >> as the potential response ove

Re: CORS performance proposal

On 8 June 2015 at 21:30, Nottingham, Mark wrote: > A header denoting site-wide metadata would work for this too, of course, if > folks were comfortable with the security properties of doing that (as well as > the potential response overhead). The security properties bother me a little. Alt-Sv

Re: CORS performance proposal

Picking up an old thread... On 20 Feb 2015, at 12:54 pm, Bjoern Hoehrmann wrote: > > * Martin Thomson wrote: >> On 20 February 2015 at 11:39, Bjoern Hoehrmann wrote: >>> The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`. >> >> I missed that. In which case I'd point out tha

Re: Custom Elements: is=""

> On Jun 8, 2015, at 4:37 PM, Alice Boxhall wrote: > > > > On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa wrote: >> >>> On Jun 8, 2015, at 3:23 PM, Alice Boxhall wrote: >>> >>> On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa wrote: > On Jun 8, 2015, at 2:16 PM, Alice Boxhall wrote:

Re: Custom Elements: is=""

On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa wrote: > > On Jun 8, 2015, at 3:23 PM, Alice Boxhall wrote: > > On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa wrote: > >> >> > On Jun 8, 2015, at 2:16 PM, Alice Boxhall wrote: >> Web developers are already writing their own "custom elements" as a bun

Re: Custom Elements: is=""

> On Jun 8, 2015, at 3:23 PM, Alice Boxhall wrote: > > On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa > wrote: >> >> > On Jun 8, 2015, at 2:16 PM, Alice Boxhall > > > wrote: >> Web developers are already writing their own "custom elements" as a

Re: Custom Elements: is=""

On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa wrote: > > > On Jun 8, 2015, at 2:16 PM, Alice Boxhall wrote: > > > > Did anyone have any further thoughts on this? My concerns haven't > changed. > > Nothing new. > > > On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall > wrote: > >> On Thu, May 7, 2015

Re: Custom Elements: is=""

> On Jun 8, 2015, at 2:16 PM, Alice Boxhall wrote: > > Did anyone have any further thoughts on this? My concerns haven't changed. Nothing new. > On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall wrote: >> On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren wrote: >>> On Wed, May 6, 2015 at 6:59 PM

Re: Custom Elements: is=""

And I'm still concerned that removing is= would severely harm the cases where you need access to special parsing behavior like and

Re: Custom Elements: is=""

Did anyone have any further thoughts on this? My concerns haven't changed. On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall wrote: > On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren > wrote: > >> On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall >> wrote: >> > I definitely acknowledge is= may not be