Re: [custom-elements] Prefix x- for custom elements like data- attributes

w it is forward parsable... But they haven't had a way to be useful. Custom elements, make them useful, but put them in a compelling box that allow us to add anything that isn't dasherized. That was a long long long way in the making, I can't honestly see it being undone in an even stricter fashi

Re: [Custom Elements] Extension of arbitrary elements at runtime.

Pea > > Is there a reason that you cannot wrap with fallback? For example, in your github issue you are given and existing app with markup like: Hello and the issue wanted to change it to Hello Is there a reason it could it not just be Hello There isn't really a significant difference between div and motor-scene to non-supporting browsers. -- Brian Kardell :: @briankardell

Re: Telecon / meeting on first week of April for Web Components

On Mar 21, 2016 3:17 PM, "Ryosuke Niwa" wrote: > > For people participating from Tokyo and Europe, would you prefer having it in early morning or late evening? > > Because Bay Area, Tokyo, and Europe are almost uniformly distributed across the timezone, our time slots are

Re: Art steps down - thank you for everything

On Jan 28, 2016 10:49 AM, "Chaals McCathie Nevile" wrote: > > Hi folks, > > as you may have noticed, Art has resigned as a co-chair of the Web Platform group. He began chairing the Web Application Formats group about a decade ago, became the leading co-chair when it merged

Re: Custom elements contentious bits

d way too much contention, more code, pitfalls and performance issues. In the end it was much simpler to have two for now and reap a significant portion of the benefit if not the whole thing. Anywho... I'm really curious to understand where this stands atm or where various companies disagree if they do. -- Brian Kardell :: @briankardell

Re: App-to-App interaction APIs - one more time, with feeling

tobre 2015 18:33 > > Hey WebAppers, > > > > Just ran into this dragon for the 1,326th time, so thought I would do a > write-up to rekindle discussion on this important area of developer need the > platform currently fails to address: > http://www.backalleycoder.com/2015/10/13/app-to-app-interaction-apis/. We > have existing APIs/specs that get relatively close, and my first instinct > would be to leverage those and extend their capabilities to cover the > broader family of use-cases highlighted in the post. > > > > I welcome your ideas, feedback, and commentary, > > > > - Daniel > > -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Is polyfilling future web APIs a good idea?

go and specifically opt in an update, make sure there isn't API breakage - you won't get native benefits automatically, because we can't peer into a crystal ball and know that will be the fact. On Aug 7, 2015, at 7:07 AM, Brian Kardell bkard...@gmail.com wrote: On Thu, Aug 6, 2015 at 6:50

Re: Is polyfilling future web APIs a good idea?

the console.warn (which again, in this case seems incorrect in the message at least) it should be generally be identical to the oneliner I gave before - the prototype for _foo is the polyfill version. -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Is polyfilling future web APIs a good idea?

an entire codebase is a bigger ask than a nice simple pattern that lets you just say something like: // Hey, our prollyfill matches native, now it's a polyfill! HTMLElement.prototype.foo = HTMLElement.prototype._foo; -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Is polyfilling future web APIs a good idea?

underscore, I can just about promise that without any agreements - but I agree it'd be great if we just had one. -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Is polyfilling future web APIs a good idea?

, create a good feedback loop that developers can actually be involved in and measure something experimental before we ship it. -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Inheritance Model for Shadow DOM Revisited

. That's has-a relationship which is appropriate for composition. - R. Niwa Is there really a hard need for inheritance over composition? Won't composition ability + an imperative API that allows you to properly delegate to the stuff you contain be just fine for a v1? -- Brian Kardell

Re: Proposal for changes to manage Shadow DOM content distribution

On Apr 21, 2015 10:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 21, 2015, at 10:17 PM, Brian Kardell bkard...@gmail.com wrote: On Apr 21, 2015 8:22 PM, Ryosuke Niwa rn...@apple.com wrote: Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template

Re: Proposal for changes to manage Shadow DOM content distribution

On Apr 21, 2015 8:22 PM, Ryosuke Niwa rn...@apple.com wrote: Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template transclusions and inheritance in shadow DOM, Jan Miksovsky at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting

Re: Minimum viable custom elements

On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote: On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote: On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com wrote

Re: Minimum viable custom elements

Elements). But that doesn't seem like a deal breaker to me, if subclassing needs to be postponed. Chris As I pointed out ealier: input is=x-foo x-fooinput/x-foo seems like barely a ternseness savings worth discussing. -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Shadow tree style isolation primitive

On Wed, Feb 4, 2015 at 7:56 AM, Olli Pettay o...@pettay.fi wrote: On 02/03/2015 04:22 PM, Brian Kardell wrote: On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi mailto: o...@pettay.fi wrote: On 02/02/2015 09:22 PM, Dimitri Glazkov wrote: Brian recently posted what

Re: Shadow tree style isolation primitive

. If this doesn't seem -hostile- to decent further improvements, finding something minimal but still very useful might be good. -Olli -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Minimum viable custom elements

On Thu, Jan 29, 2015 at 1:50 PM, Elliott Sprehn espr...@chromium.org wrote: On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell bkard...@gmail.com wrote: On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson bru...@opera.com wrote: On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com

Re: Minimum viable custom elements

-functional pages is vital for the people who don't use latest greatest Chromium or Gecko browsers. b But in the context of custom elements (not shadow dom) these should be able to do 'createdCallback' etc on the server... I can't really see any reason why they couldn't/wouldn't. -- Brian Kardell

Re: Minimum viable custom elements

Not to sidetrack the discussion but Steve Faulker made what I think was a valid observation and I haven't seen a response... Did I miss it?

Re: Minimum viable custom elements

. -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Shadow tree style isolation primitive

On Tue, Jan 13, 2015 at 8:09 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 13, 2015, at 3:46 PM, Brian Kardell bkard...@gmail.com wrote: On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa rn...@apple.com wrote: To separate presentational information (CSS) from the semantics (HTML). Defining

Re: Shadow tree style isolation primitive

in your opinion? Like, forget shadow dom as it is today in chrome or proposed -- should you be able to do something like ``` element.isolateTree = true; ``` and achieve a similar effect? If not, why specifically? -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Shadow tree style isolation primitive

with qsa/find/closest (at minimum) - and I think it is the least surprising thing to do - then you've merely moved where the cognitive stress is, and in a really new way... Suddenly your CSS is affecting your understanding of the actual tree! That seems bad. -- Brian Kardell :: @briankardell

Re: Shadow tree style isolation primitive

interference from the page, potentially through some assembly on the server or preprocess or something? Or it is just like this is actually really hard to manage with CSS and here's potentially a way to make it 'scope' easier? -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Shadow tree style isolation primitive

? In any case, I agree with you, it's possible to have this conversation without those two as a start and I'd suggest we do that. - R. Niwa -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Shadow tree style isolation primitive

On Mon, Jan 12, 2015 at 7:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 4:16 PM, Brian Kardell bkard...@gmail.com wrote: Sure, here are some use cases I can think off the top of my head: 1. Styling a navigation bar which is implemented as a list of hyperlinks 2

Re: Shadow tree style isolation primitive

On Mon, Jan 12, 2015 at 11:51 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jan 12, 2015 at 5:47 PM, Brian Kardell bkard...@gmail.com wrote: Controlling it through CSS definitely seems to be very high-level. To me at least it feels like it requires a lot more answering of how since

Re: Shadow tree style isolation primitive

. -- https://annevankesteren.nl/ -- Brian Kardell :: @briankardell :: hitchjs.com

Re: Shadow tree style isolation primitive

On Jan 9, 2015 8:43 AM, Anne van Kesteren ann...@annevk.nl wrote: I'm wondering if it's feasible to provide developers with the primitive that the combination of Shadow DOM and CSS Scoping provides. Namely a way to isolate a subtree from selector matching (of document stylesheets, not

Re: Shadow tree style isolation primitive

of? I guess you're not proposing that but I am saying what about a proposal like that would it answer your concerns? -- https://annevankesteren.nl/ -- Brian Kardell :: @briankardell :: hitchjs.com

[shadow dom] relitigation

://hacks.mozilla.org/2014/12/mozilla-and-web-components/ -- Brian Kardell :: @briankardell :: hitchjs.com

Re: [shadow dom] relitigation

not even a member - it's just something I hear a lot of people discussing and thought worth bringing into the open. Brian Kardell :: @briankardell :: hitchjs.com

Re: [shadow dom] relitigation

On Wed, Dec 17, 2014 at 4:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 17, 2014, at 3:18 PM, Brian Kardell bkard...@gmail.com wrote: On Wed, Dec 17, 2014 at 3:24 PM, Ryosuke Niwa rn...@apple.com wrote: Hi Brian, The WebKit team has given a lot of feedback over the years on the Shadow

Re: HTML imports in Firefox

Very generally: this is actually why I said way back that a lot of things seem like prollyfills (we hope that's the future) rather than polyfills (it's a done deal) and advocated we make sure it's a future-safe, forward compatible approach. On Dec 15, 2014 4:06 PM, Ashley Gullen ash...@scirra.com

[Push] one or many

I'm really confused by what seems to me like contradictory prose... In the interface definition it says Note that just a single push registration is allowed per webapp. But in multiple places it seems to suggest otherwise, for example, in the section on uniqueness it says: webapps that

Re: [Push] one or many

On Thu, Oct 9, 2014 at 2:01 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 9, 2014 at 7:53 PM, Brian Kardell bkard...@gmail.com wrote: Can someone clarify why those seem contradictory? Can a webapp have 1 registration, or many? The term webapp also seems wrong. There's

Re: XMLHttpRequest: uppercasing method names

On Aug 12, 2014 9:29 AM, Anne van Kesteren ann...@annevk.nl wrote: In https://github.com/slightlyoff/ServiceWorker/issues/120 the question came up whether we should perhaps always uppercase method names as that is what people seem to expect. mnot seemed okay with adding appropriate advice on

Re: XMLHttpRequest: uppercasing method names

On Aug 12, 2014 11:12 AM, Takeshi Yoshino tyosh...@google.com wrote: On Tue, Aug 12, 2014 at 10:55 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 12, 2014 at 3:37 PM, Brian Kardell bkard...@gmail.com wrote: If there's no really good reason to change it, least change is better IMO

Re: Blocking message passing for Workers

On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com wrote: Le 09/08/2014 15:51, Alan deLespinasse a écrit : Thanks. Apparently I did a lousy job of searching for previous discussions. I just found this later, longer thread:

Re: =[xhr]

On Aug 1, 2014 9:52 AM, nmork_consult...@cusa.canon.com wrote: Thank you for letting me know my input is not desired. As Tab said, you can visually and functionally lock user input in your tab and even provide a progress meter. Nothing you suggest is difficult with a sync xhr and promises, and

Re: Fallout of non-encapsulated shadow trees

[snip] On Jul 1, 2014 10:07 PM, Maciej Stachowiak m...@apple.com wrote: (3) A two-way membrane at the API layer between a component and a script; approximately, this would be the Structured Clone algorithm, but extended to also translate references to DOM objects between the worlds. Has this

Re: [Bug 25376] - Web Components won't integrate without much testing

On May 23, 2014 10:18 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 20, 2014 at 8:41 PM, Axel Dahmen bril...@hotmail.com wrote: I got redirected here from a HTML5 discussion on an IFrame's SEAMLESS attribute: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25376 Ian

Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28

On May 21, 2014 10:29 AM, Arthur Barstow art.bars...@gmail.com wrote: On 5/21/14 7:02 AM, Anne van Kesteren wrote: Developers seem to complain about us using mailing lists to communicate rather than GitHub or some other centralized platform that is not email. Might be worth checking with

Re: Custom Elements: 'data-' attributes

without getting too crazy? -- Brian Kardell :: @briankardell :: hitchjs.com

Re: [custom-elements] :unresolved and :psych

element is created and it's ready for user interaction for some custom elements. Custom pseudo, for example, seems like a more appealing solution in that regard. - R. Niwa On Mar 25, 2014, at 2:31 PM, Brian Kardell bkard...@gmail.com wrote: I'm working with several individuals of varying

[custom-elements] :unresolved and :psych

and let the author participate in that somehow, perhaps the same way (optionally return a promise from created). Either way, it seems to me that if we had that, my folks would use that over the current definition of :resolved in a lot of cases. -- Brian Kardell :: @briankardell :: hitchjs.com

Re: [custom-elements] :unresolved and :psych

(populated) element was ready. -- Brian Kardell :: @briankardell :: hitchjs.com

Re: [custom-elements] :unresolved and :psych

into the system (tighten the feedback loop, right). -- Brian Kardell :: @briankardell :: hitchjs.com

Re: [Bug 24823] New: [ServiceWorker]: MAY NOT is not defined in RFC 2119

On Feb 26, 2014 1:01 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * bugzi...@jessica.w3.org wrote: The section Worker Script Caching uses the term MAY NOT, which is not defined in RFC 2119. I'm assuming this is intended to be MUST NOT or maybe SHOULD NOT. If an agent MAY $x then it also

Re: [HTML Imports]: Sync, async, -ish?

-element-pseudoclass -- Brian Kardell :: @briankardell :: hitchjs.com

Re: [HTML Imports]: Sync, async, -ish?

On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald jaffathec...@gmail.comwrote: :unresolved { display: none; } plus lazyload ( https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload) would allow devs to create the non-blocking behaviour. But this is the

Re: [HTML Imports]: Sync, async, -ish?

in the tree at parse - I dont think that is DOMContentLoaded, but hopefully you take my point. If we could agree that that solution works, we could then have a cage match to decide on a good name :) On 29 January 2014 09:19, Brian Kardell bkard...@gmail.com wrote: On Wed, Jan 29, 2014 at 12:09

Re: [webcomponents] Auto-creating shadow DOM for custom elements

As an alternate suggestion, and one that might dodge the subclassing issues, perhaps createShadowRoot could take an optional template argument and clone it automatically. Then this: this._root = this.createShadowRoot(); this._root.appendChild(template.content.cloneNode());

Re: [custom elements] Improving the name of document.register()

, at 10:09 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 13, 2013 at 2:29 AM, Brian Kardell bkard...@gmail.com wrote: On Dec 11, 2013 11:48 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 11, 2013, at 6:46 PM, Dominic Cooney domin...@google.com wrote: ... El 11/12/2013

Re: [custom elements] Improving the name of document.register()

On Dec 11, 2013 11:48 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 11, 2013, at 6:46 PM, Dominic Cooney domin...@google.com wrote: On Thu, Dec 12, 2013 at 5:17 AM, pira...@gmail.com pira...@gmail.com wrote: I have seen registerProtocolHandler() and it's being discused

Re: [custom elements] Improving the name of document.register()

is the only kind of element you could register, custom seems redundant - similarly - it isn't registerCustomProtocolHandler(). .registerElement is reasonably short and, IMO, adds the descriptiveness that Ted is looking for? -- Brian Kardell :: @briankardell :: hitchjs.com

Re: [webcomponents] HTML Imports

I've been putting off a response on this, but I have some things to add... The topic on this thread was originally HTML Imports - it seems like some of the concerns expressed extend beyond imports and are a little wider ranging. I am cross posting this comment to public-next...@w3.org as I think

Re: [HTML Imports]: what scope to run in

On Nov 19, 2013 2:22 AM, Ryosuke Niwa rn...@apple.com wrote: On Nov 19, 2013, at 2:10 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Mon, Nov 18, 2013 at 8:26 PM, Ryosuke Niwa rn...@apple.com wrote: We share the concern Jonas expressed here as I've repeatedly mentioned on another

Re: [HTML Imports]: Sync, async, -ish?

Mixed response here... I love the idea of making HTML imports *not* block rendering as the default behavior In terms of custom elements, this creates as a standard, the dreaded FOUC problem about which a whole different group of people will be blogging and tweeting... Right? I don't know that

Re: should mutation observers be able to observe work done by the html parser

was therw ever agreement on this old topic? http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0618.htmlwhether by de facto implementation or spec agreements? I am not seeing anything in the draft but maybe i am missing it...

Re: Making selectors first-class citizens

On Mon, Sep 16, 2013 at 2:51 PM, Ryosuke Niwa rn...@apple.com wrote: On Sep 13, 2013, at 8:26 PM, Brian Kardell bkard...@gmail.com wrote: On Sep 13, 2013 4:38 PM, Ryosuke Niwa rn...@apple.com wrote: On Sep 11, 2013, at 11:54 AM, Francois Remy r...@adobe.com wrote: For the record

Re: Making selectors first-class citizens

On Sep 16, 2013 3:46 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Sep 16, 2013 at 12:03 PM, Brian Kardell bkard...@gmail.com wrote: I think the responses/questions are getting confused. I'm not sure about others, but my position is actually not that complicated: This feature has

Re: Making selectors first-class citizens

On Mon, Sep 16, 2013 at 5:43 PM, Scott González scott.gonza...@gmail.comwrote: On Mon, Sep 16, 2013 at 5:33 PM, Brian Kardell bkard...@gmail.com wrote: I think Francois shared a github search with shows almost 15,500 uses expecting matchesSelector. As is generally the case, that GitHub

Re: Making selectors first-class citizens

On Mon, Sep 16, 2013 at 4:29 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Sep 16, 2013 at 1:05 PM, Brian Kardell bkard...@gmail.com wrote: If they didn't support down-level browsers at all, then they're already broken for a lot of users, so making them broken for a few more

Re: Making selectors first-class citizens

On Sep 14, 2013 6:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Sep 14, 2013 at 4:26 AM, Brian Kardell bkard...@gmail.com wrote: I am not really sure why you feel this way - this piece of the draft is tremendously stable, and interoperable as anything else. The decision to make

Re: Making selectors first-class citizens

On Sep 13, 2013 4:38 PM, Ryosuke Niwa rn...@apple.com wrote: On Sep 11, 2013, at 11:54 AM, Francois Remy r...@adobe.com wrote: For the record, I'm equally concerned about renaming `matchesSelector` into `matches`. A lot of code now rely on a prefixed or unprefixed version of

Re: Making selectors first-class citizens

On Sep 12, 2013 2:16 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: FWD'ing to put my reply back on list (and to others)... On Sep 11, 2013 6:35 AM, Anne van Kesteren ann...@annevk.nl wrote: As far as I can tell Element.prototype.matches() is not deployed yet. Should we instead make

Re: Making selectors first-class citizens

On Sep 11, 2013 9:34 AM, Anne van Kesteren ann...@annevk.nl wrote: As far as I can tell Element.prototype.matches() is not deployed yet. Should we instead make selectors first-class citizens, just like regular expressions, and have this: var sel = new Selectors(i love selectors,

Re: Making selectors first-class citizens

On Sep 11, 2013 11:11 AM, James Graham ja...@hoppipolla.co.uk wrote: On 11/09/13 15:50, Brian Kardell wrote: Yes, to be clear, that is what i meant. If it is in a draft and widely/compatibly implemented and deployed in released browsers not behind a flag - people are using it. If people

Re: Making selectors first-class citizens

On Wed, Sep 11, 2013 at 12:26 PM, Brian Kardell bkard...@gmail.com wrote: On Sep 11, 2013 11:11 AM, James Graham ja...@hoppipolla.co.uk wrote: On 11/09/13 15:50, Brian Kardell wrote: Yes, to be clear, that is what i meant. If it is in a draft and widely/compatibly implemented

Re: Making selectors first-class citizens

On Sep 11, 2013 12:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/11/13 12:26 PM, Brian Kardell wrote: If something with the same name but different signature or functionality goes out unprefixed, things will break. Why is this, exactly? Is code assuming that mozFoo, webkitFoo and foo

Re: Making selectors first-class citizens

On Sep 11, 2013 10:04 AM, Robin Berjon ro...@w3.org wrote: On 11/09/2013 15:56 , Anne van Kesteren wrote: On Wed, Sep 11, 2013 at 2:52 PM, Brian Kardell bkard...@gmail.com wrote: I like the idea, but matches has been in release builds for a long time, right? Hitch uses it. !DOCTYPE

Re: [webcomponents]: The Shadow Cat in the Hat Edition

On Sep 9, 2013 9:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Sep 9, 2013 at 6:20 PM, Scott Miles sjmi...@google.com wrote: I'd greatly prefer to stick with the current plan of having to mark things to be exposed explicitly, Fwiw, we tried that and got in the weeds right

Re: element Needs A Beauty Nap

to help lead the charge on asking those questions and helping to offer potentially competing answers -- there need be no rush to standardize at the high level at this point IMO. -- Brian Kardell :: @briankardell :: hitchjs.com

Re: jar protocol

Would it be possible (not suggesting this would be the common story) to reference a zipped asset directly via the full url, sans a link tag?

Re: jar protocol

Can you hash out a little bit more how this would work? I'm assuming you mean something like: img src='/bundle.zip/img/dahut.jpg' Meh, sorta - but I was missing some context on the mitigation strategies - thanks for filling me in offline. Still, same kinda idea, could you add an attribute

Re: jar protocol

they are smart enough to deal with that already. -- Robin Berjon - http://berjon.com/ - @robinberjon -- Brian Kardell :: @briankardell :: hitchjs.com

Re: URL comparison

+ the public-nextweb list... On Wed, May 1, 2013 at 9:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Apr 28, 2013 at 12:56 PM, Brian Kardell bkard...@gmail.com wrote: We created a prollyfill for this about a year ago (called :-link-local instead of :local-link for forward

Re: URL comparison

On Apr 25, 2013 1:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Apr 25, 2013 at 4:34 AM, Anne van Kesteren ann...@annevk.nl wrote: Background reading: http://dev.w3.org/csswg/selectors/#local-pseudo and http://url.spec.whatwg.org/ :local-link() seems like a special case API

Re: [webcomponents]: Of weird script elements and Benadryl

Can Scott or Daniel or someone explain the challenge with creating a normal constructor that has been mentioned a few times (Scott mentioned has-a). I get the feeling that several people are playing catch up on that challenge and the implications that are causing worry. Until people have some

Re: [webcomponents]: Of weird script elements and Benadryl

On Apr 13, 2013 8:57 PM, Daniel Buchner dan...@mozilla.com wrote: @Rick - if we generated a constructor that was in scope when the script was executed, there is no need for rebinding 'this'. I'd gladly ditch the rebinding in favor of sane, default, generated constructors. I think we need

Re: [webcomponents]: Re-imagining shadow root as Element

On Mon, Mar 18, 2013 at 5:05 PM, Scott Miles sjmi...@google.com wrote: I'm already on the record with A, but I have a question about 'lossiness'. With my web developer hat on, I wonder why I can't say: div id=foo shadowroot shadow stuff /shadowroot light stuff /div and

Re: [webcomponents]: Re-imagining shadow root as Element

On Apr 10, 2013 1:24 PM, Scott Miles sjmi...@google.com wrote: So, what you quoted are thoughts I already deprecated mysefl in this thread. :) If you read a bit further, see that I realized that shadow-root is really part of the 'outer html' of the node and not the inner html. Yeah sorry,

Re: [webcomponents]: de-duping in HTMLImports

) not parsed twice. But these features are not in specification, and are not trivial as design decisions. WDYT? Scott For what it is worth, I think I might have opened a bug on this already (long ago) - but it would have been mixed in with a larger 'how to load them'... -- Brian Kardell

Re: [webcomponents]: Naming the Baby

On Mar 28, 2013 11:45 AM, Dimitri Glazkov dglaz...@google.com wrote: So. : rel type: import spec name: 1) HTML Imports 2) Web Imports :DG Makes sense to me!

Re: [webcomponents]: Naming the Baby

On Mar 27, 2013 2:27 PM, Scott Miles sjmi...@google.com wrote: The problem I'm trying to get at, is that while a 'custom element' has a chance of meeting your 1-6 criterion, the thing on the other end of link rel='to-be-named'... has no such qualifications. As designed, the target of this link

Re: [webcomponents]: Naming the Baby

On Mar 25, 2013 3:03 PM, Dimitri Glazkov dglaz...@google.com wrote: Hello folks! It seems that we've had a bit of informal feedback on the Web Components as the name for the link rel=component spec (cc'd some of the feedbackers). So... these malcontents are suggesting that Web Components

Re: [webcomponents]: First stab at the Web Components spec

On Mar 18, 2013 10:48 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 18, 2013 at 7:35 AM, Karl Dubost k...@la-grange.net wrote: Le 7 mars 2013 à 18:25, Dimitri Glazkov a écrit : Here's a first rough draft of the Web Components spec:

Re: [webcomponents]: What callbacks do custom elements need?

On Mon, Mar 11, 2013 at 1:16 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/11/13 3:44 PM, Daniel Buchner wrote: Just to be clear, these are callbacks (right?), meaning synchronous executions on one specific node. That is a far cry from the old issues with mutation events and nightmarish

Re: [webcomponents]: What callbacks do custom elements need?

Is it very difficult to provide here is an attribute I'm watching + a callback? Most things require us to write switches and things and receive overly broad notifications which aren't great for performance or for code legibility IMO. Just curious. -- Brian Kardell :: @briankardell

Re: [webcomponents]: What callbacks do custom elements need?

Sorry I clicked send accidentally there... I meant to mention that I think this is sort of the intent of attributeFilter in mutation observers On Mon, Mar 11, 2013 at 5:59 PM, Brian Kardell bkard...@gmail.com wrote: Is it very difficult to provide here is an attribute I'm watching

Re: [webcomponents]: What callbacks do custom elements need?

On Mar 11, 2013 9:03 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/11/13 8:59 PM, Brian Kardell wrote: Is it very difficult to provide here is an attribute I'm watching + a callback? It's not super-difficult but it adds more complication to already-complicated code One big question

Re: Feedback and questions on shadow DOM and web components

Brian Kardell :: @bkardell :: hitchjs.com On Nov 13, 2012 9:34 AM, Angelina Fabbro angelinafab...@gmail.com wrote: Hello public-webapps, I'm Angelina, and I've been very interested in shadow DOM and web components for some time now. So much so that I've tried to teach people about them several

Re: [webcomponents] More backward-compatible templates

The reason is because all of the things that you do in every template system (iteration, conditionals, etc) are also intended to be template. It kinda messes with the mind to get used to that idea, even for me I occasionally need reminding... http://memegenerator.net/instance/29459456 Brian

[Web-storage] subdomains / cooperation and limits

I have searched the archives and been unable to resolve this to a great answer and I just want to make sure that my understanding is correct lest I have to unwind things later as someone has recently made me second guess what I thought was a logical understanding of things. Essentially,

Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!

On Aug 21, 2012 4:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org wrote: Meh. I think this loses most of the CSS is so much more convenient benefits. It's mainly the fact that you don't have to worry about whether the nodes

Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 21, 2012 at 1:30 PM, Brian Kardell bkard...@gmail.com wrote: On Aug 21, 2012 4:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org wrote: Meh. I

Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!

On Aug 21, 2012 5:40 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai o...@chromium.org wrote: On a somewhat unrelated note, could we somehow also incorporate jquery style live event handlers here? See previous www-dom discussion about this: . I

  1   2   >