Re: Service Worker issues

> caches.open("blog - 2016-06-10 14:14:23 -0700").then(c => c.keys()) > Promise { : "pending" } Note that this test will *not* tell you whether or not c.keys() returns a promise; the .then callback is allowed to return a non-promise, and .then() always returns a promise regardless. You have to

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

On Mon, Apr 25, 2016 at 10:06 AM, Bang Seongbeom wrote: > It would be good to restrict custom element's name to start with like > 'x-' for the future standards. User-defined custom attributes; data > attributes are also restricted its name to start with 'data-' so we

Re: [Custom Elements] Not requiring hyphens in names.

On Wed, Apr 13, 2016 at 12:33 PM, /#!/JoePea wrote: > What if custom Elements simply override existing ones then? > > ```js > shadowRoot.registerElement('div', MyElement) > ``` That means we lose the lingua franca that HTML provides; two independent libraries can't ever depend

Re: [Custom Elements] Not requiring hyphens in names.

On Wed, Apr 13, 2016 at 11:12 AM, /#!/JoePea wrote: > I personally don't like this limitation. I think Custom Elements would > be better if we could create elements that have > , with the possible exception that we can't override the > native elements. This would prevent

Re: [XHR]

On Wed, Mar 16, 2016 at 5:10 AM, Jonathan Garbee wrote: > On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen > wrote: >> On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas >> wrote: >> >> > According to IETF

Re: Shadow DOM and alternate stylesheets

On Tue, Dec 8, 2015 at 4:43 AM, Rune Lillesveen wrote: > what should happen with the title attribute of style elements in Shadow DOM? > > In Blink you can currently select style elements in shadow trees based > on the alternate stylesheet name set for the document. You even set >

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers wrote: > Hi, Eliott– > > Good question. > > I don't have a great answer yet, but this is something that will need to be > worked out with Shadow DOM, not just for this spec, but for Selection API > and others, as well as to CSS, which

Re: Indexed DB + Promises

On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola wrote: > I guess part of the question is, does this add enough value, or will authors > still prefer wrapper libraries, which can afford to throw away backward > compatibility in order to avoid these ergonomic problems? From

Re: Indexed DB + Promises

On Wed, Sep 30, 2015 at 11:07 AM, Kyle Huey <m...@kylehuey.com> wrote: > On Wed, Sep 30, 2015 at 10:50 AM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: >> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola <d...@domenic.me> wrote: >>> I guess part of the que

Re: Normative references to Workers.

On Tue, Sep 15, 2015 at 10:31 AM, Mike West wrote: > The "Upgrade Insecure Requests" specification[1] references the WHATWG HTML > spec for the > "set up a worker environment settings object" algorithm[2], as the Web > Workers Candidate Recommendation from May 2012[3]

Re: PSA: publish WD of WebIDL Level 1

On Fri, Aug 7, 2015 at 9:23 AM, Travis Leithead travis.leith...@microsoft.com wrote: This is, at a minimum, incremental goodness. It's better than leaving the prior L1 published document around--which already tripped up a few folks on my team recently. I strongly +1 it. There are

Re: PSA: publish WD of WebIDL Level 1

On Thu, Jul 30, 2015 at 7:29 AM, Arthur Barstow art.bars...@gmail.com wrote: Hi All, This is heads-up re the intent to publish a Working Draft of WebIDL Level 1 (on or around August 4) using Yves' document as the basis and a new shortname of WebIDL-1:

Re: [shadow-dom] ::before/after on shadow hosts

All right, sounds pretty unanimous that #2 (current behavior) is what we should go with. I'll clarify the Scoping spec. Thanks! ~TJ

[shadow-dom] ::before/after on shadow hosts

I was recently pointed to this StackOverflow thread http://stackoverflow.com/questions/31094454/does-the-shadow-dom-replace-before-and-after/ which asks what happens to ::before and ::after on shadow hosts, as it's not clear from the specs. I had to admit that I hadn't thought of this

Re: Writing spec algorithms in ES6?

On Thu, Jun 11, 2015 at 1:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/11/15 4:32 PM, Dimitri Glazkov wrote: I noticed that the CSS Color Module Level 4 actually does this, and it seems pretty nice: http://dev.w3.org/csswg/css-color/#dom-rgbcolor-rgbcolorcolor I should note that the ES

Re: Shadow DOM spec bugs will be migrated into GitHub issues

Note for the future (to you and editors of other specs in WebApps): Before doing this kind of mass bug editting, please turn off the automatic email to public-webapps. If you can't do that yourself, Mike Smith can (at least, he's done it in the past). That prevents the mass flood of bugspam

Re: :host pseudo-class

On Tue, May 5, 2015 at 10:56 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 5, 2015 at 8:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: It's certainly no weirder, imo, than having a pseudo-element that doesn't actually live in any element's pseudo-tree, but instead just lives

Re: :host pseudo-class

On Mon, May 4, 2015 at 9:38 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 5, 2015 at 2:08 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren ann...@annevk.nl wrote: But maybe you're right and the whole pseudo-class/pseudo-element

Re: :host pseudo-class

On Mon, May 4, 2015 at 9:52 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron dba...@dbaron.org wrote: On Saturday 2015-04-25 09:32 -0700, Anne van Kesteren wrote: I don't understand why :host is a pseudo-class rather than a pseudo-element. My mental

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa rn...@apple.com wrote: On May 4, 2015, at 10:20 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org wrote: We can solve this problem by running the distribution code in a separate

Re: :host pseudo-class

On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 1, 2015 at 7:39 AM, Elliott Sprehn espr...@chromium.org wrote: That's still true if you use ::host, what is the thing on the left hand side the ::host lives on? I'm not aware of any pseudo element that's not

Re: :host pseudo-class

On Thu, Apr 30, 2015 at 2:27 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Apr 27, 2015 at 11:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Pseudo-elements are things that aren't DOM elements, but are created by Selectors for the purpose of CSS to act like elements. That's

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov dglaz...@google.com wrote: On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote: One thing that worries me about the `distribute` callback approach (a.k.a. Anne's approach) is that it bakes distribution algorithm into the platform

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Wed, Apr 29, 2015 at 4:47 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov dglaz...@google.com wrote: On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote: One

Re: Directory Upload Proposal

On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon seddon.r...@gmail.com wrote: To enable developers to build future interoperable solutions, we've drafted a proposal [4], with the helpful feedback of Mozilla and Google, that focuses strictly on providing the mechanisms necessary to enable directory

Re: =[xhr]

On Tue, Apr 28, 2015 at 7:51 AM, Ken Nelson k...@pure3interactive.com wrote: RE async: false being deprecated There's still occasionally a need for a call from client javascript back to server and wait on results. Example: an inline call from client javascript to PHP on server to authenticate

Re: :host pseudo-class

On Sat, Apr 25, 2015 at 9:32 AM, Anne van Kesteren ann...@annevk.nl wrote: I don't understand why :host is a pseudo-class rather than a pseudo-element. My mental model of a pseudo-class is that it allows you to match an element based on a boolean internal slot of that element. :host is not

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com wrote: IMO, the appeal of this proposal is that it's a small change to the current spec

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com wrote: IMO, the appeal of this proposal is that it's a small change to the current spec and avoids changing user expectations about the state of the dom and can

Re: Proposal for changes to manage Shadow DOM content distribution

On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky jan@component.kitchen wrote: Hi Tab, Thanks for your feedback! A primary motivation for proposing names instead of CSS selectors to control distribution is to enable subclassing. We think it’s important for a subclass to be able to override a

Re: Proposal for changes to manage Shadow DOM content distribution

On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa rn...@apple.com wrote: I find it decidedly relevant given I'm pointing out that attribute-specified slots Domenic mentioned isn't what you described. Since the only venue in which attribute-specified slots came up are [1], [2], and [3]. We're

Re: Proposal for changes to manage Shadow DOM content distribution

This is literally reinventing Selectors at this point. The solution to we don't think it's worth implementing *all* of Selectors is to define a subset of supported Selectors, not to define a brand new mechanism that's equivalent to selectors but with a new syntax. On Wed, Apr 22, 2015 at 10:21

Re: Proposal for changes to manage Shadow DOM content distribution

On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've

Re: Proposal for changes to manage Shadow DOM content distribution

On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content

Re: PSA: publishing new WD of File API on April 21

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote: * This spec is now using Github https://w3c.github.io/FileAPI/ and the ED is https://w3c.github.io/FileAPI/Overview.html. PRs are welcome and encouraged. (I think it would be useful if this spec used ReSpec and if

Re: PSA: publishing new WD of File API on April 21

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote: Hi All, A new Working Draft publication of File API is planned for April 21 using the following version as the basis: https://w3c.github.io/FileAPI/TR.html Note that this version appears to be based off the

Re: PSA: publishing new WD of File API on April 21

On Wed, Apr 15, 2015 at 3:00 PM, Arthur Barstow art.bars...@gmail.com wrote: On 4/15/15 5:56 PM, Tab Atkins Jr. wrote: On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote: https://w3c.github.io/FileAPI/TR.html Note that this version appears to be based off

Re: PSA: publishing new WD of File API on April 21

On Wed, Apr 15, 2015 at 12:54 PM, Martin Thomson martin.thom...@gmail.com wrote: On 15 April 2015 at 07:26, Arthur Barstow art.bars...@gmail.com wrote: * This spec is now using Github https://w3c.github.io/FileAPI/ That repo is actually https://github.com/w3c/FileAPI/. Since the most

Re: template namespace attribute proposal

On Wed, Mar 18, 2015 at 2:06 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Karl Dubost said: The intersection seems to be: ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio', 'font

Re: template namespace attribute proposal

[Sorry for the reply-chain breaking; Gmail is being super weird about your message in particular, and won't let me reply directly to it. Some bug.] Karl Dubost said: The intersection seems to be: ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio',

Re: template namespace attribute proposal

On Fri, Mar 13, 2015 at 2:09 PM, Jonas Sicking jo...@sicking.cc wrote: Unless the SVG WG is willing to drop support for script![CDATA[...]]/script. But that seems like it'd break a lot of content. Like, on the same line? Because I recall that sort of thing showing up in old HTML tutorials,

Re: template namespace attribute proposal

On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g.

Re: template namespace attribute proposal

On Fri, Mar 13, 2015 at 1:27 PM, Benjamin Lesh bl...@netflix.com wrote: I agree completely, Tab, but it's actually too late to stop forcing authors to think about namespaces, the fact I currently have to think about it is the source of this suggestion. You have to think about it today *because

Re: template namespace attribute proposal

On Fri, Mar 13, 2015 at 1:48 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Mar 13, 2015 at 1:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote

Re: Standardising canvas-driven background images

On Fri, Feb 20, 2015 at 1:50 PM, Matthew Robb matthewwr...@gmail.com wrote: On Fri, Feb 20, 2015 at 2:25 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Images level 4 If/when that spec reappears it would be great if you could reply to this thread with a link or something... Thanks! Here we

Re: Standardising canvas-driven background images

On Fri, Feb 20, 2015 at 7:51 AM, Ashley Gullen ash...@scirra.com wrote: Forgive me if I've missed past discussion on this feature but I need it so I'm wondering what the status of it is. (Ref: https://www.webkit.org/blog/176/css-canvas-drawing/ and

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

On Thu, Feb 12, 2015 at 1:45 PM, Marc Fawzi marc.fa...@gmail.com wrote: this backward compatibility stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones Yup. this has worked

Re: Are web components *seriously* not namespaced?

On Fri, Feb 6, 2015 at 8:12 AM, Kurt Cagle kurt.ca...@gmail.com wrote: Tab, I spend the vast majority of my time anymore in RDF-land, where namespaces actually make sense (I'm not going to argue on the XML use of namespaces - they are, agreed, ugly and complex). I know that when I've been at

Re: Are web components *seriously* not namespaced?

On Thu, Feb 5, 2015 at 3:57 PM, Benjamin Goering b...@livefyre.com wrote: Glad to see this. I was 'checking in' on the professional practicalities of custom elements earlier this week, and was pretty bummed when I couldn't use XHTML5 namespaces for my employer's organization. I build widgets

Re: Are web components *seriously* not namespaced?

On Thu, Feb 5, 2015 at 7:44 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Feb 5, 2015 at 2:15 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Yes, real namespacing does eventually prove necessary as the population grows. That's fine. It's something that can be added organically

Re: Are web components *seriously* not namespaced?

On Fri, Feb 6, 2015 at 12:48 AM, Glen glen...@gmail.com wrote: So in other words it *is* a case of it's good enough. Web components are quite possibly the future of the web, and yet we're implementing them to be good enough in 90% of use cases? jQuery is JavaScript which means that it's

Re: Shadow tree style isolation primitive

On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi wrote: Why do we need shadow DOM (or something similar) at all if we expose it easily to the outside world. One could even now just require that elements in components in a web page have class=component, and then .component could be

Re: Shadow tree style isolation primitive

On Thu, Feb 5, 2015 at 10:56 AM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi wrote: Why do we need shadow DOM (or something similar) at all if we expose it easily

Re: Shadow tree style isolation primitive

On Thu, Feb 5, 2015 at 11:03 AM, Olli Pettay o...@pettay.fi wrote: On 02/05/2015 01:20 AM, Tab Atkins Jr. wrote: You don't need strong isolation primitives to do a lot of good. Simple composition helpers lift an *enormous* weight off the shoulders of web devs, and make whole classes of bugs

Re: Are web components *seriously* not namespaced?

On Thu, Feb 5, 2015 at 8:31 AM, Glen glen...@gmail.com wrote: I know I'm rather late to the party, but I've been doing a lot of reading lately about web components and related technologies, and the one thing that confounds me is the fact that web components appear not to have any real

Re: Are web components *seriously* not namespaced?

On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle kurt.ca...@gmail.com wrote: I predict that sometime around 2025, we will end up redefining namespaces because the number of jQuery-like components have ballooned into the millions, the web has descended once again into a sea of interoperability, and

Re: Shadow tree style isolation primitive

On Wed, Feb 4, 2015 at 11:36 PM, Olli Pettay o...@pettay.fi wrote: Why should even !important work if the component wants to use its own colors? Because that's how !important usually works. If the author has progressed to the point of doing !important, we should assume that they know what

Re: [Selection] Support of Multiple Selection (was: Should selection.getRangeAt return a clone or a reference?)

On Sat, Jan 24, 2015 at 9:35 AM, Aryeh Gregor a...@aryeh.name wrote: It's not just that it was only implemented by one UA. It's also that even in Firefox, multiple-range selections practically never occur. The only way for a user to create them to to either Ctrl-select multiple things, which

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 12:27 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 15, 2015, at 11:47 AM, Brian Kardell bkard...@gmail.com wrote: 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? When and in

Re: [Selection] Support of Multiple Selection (was: Should selection.getRangeAt return a clone or a reference?)

On Tue, Jan 13, 2015 at 2:05 PM, Mats Palmgren m...@mozilla.com wrote: On 01/12/2015 07:59 PM, Ben Peters wrote: Multiple selection is an important feature in the future. Indeed, there are many important use cases for it. Here are some use cases that are implemented using multi-range

Re: Shadow tree style isolation primitive

On Fri, Jan 9, 2015 at 5:40 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

On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Let's assume we did it, though. We'd have to have some mechanism for defining an isolation boundary, and denoting whether rules were inside or outside

Re: Shadow tree style isolation primitive

[oof, somehow your latest response flattened all of the quotes] On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: ? I didn't mention DOM APIs. I'm referring back to the example you're replying

Re: Shadow tree style isolation primitive

On Mon, Jan 12, 2015 at 3:51 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 2:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Let's assume

Re: Shadow tree style isolation primitive

[ryosuke, your mail client keeps producing flattened replies. maybe send as plain-text, not HTML?] On Mon, Jan 12, 2015 at 5:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 4:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa rn

Re: Shadow tree style isolation primitive

On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: [ryosuke, your mail client keeps producing flattened replies. maybe send as plain-text, not HTML?] Weird. I'm not seeing that at all on my end. It's

Re: Custom element design with ES6 classes and Element constructors

On Mon, Jan 12, 2015 at 5:16 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Jan 11, 2015 at 9:13 PM, Domenic Denicola d...@domenic.me wrote: However, I don't understand how to make it work for upgraded elements at all Yes, upgrading is the problem. There's two strategies as far as I can

Re: Shadow tree style isolation primitive

On Fri, Jan 9, 2015 at 8:08 AM, Dimitri Glazkov dglaz...@google.com wrote: Here's an attempt from 2012. This approach doesn't work (the trivial plumbing mentioned in the doc is actually highly non-trivial), but maybe it will give some insights to find the right a proper solution:

Re: Help with WebIDL v1?

On Mon, Dec 1, 2014 at 12:57 PM, Travis Leithead travis.leith...@microsoft.com wrote: At TPAC, I mentioned wanting to help move along WebIDL v1 to REC. Can you enumerate the next steps, and where I might be able to help? Thanks! Is there any actual value in doing this, since v2 has many

Re: Broken links

On Sun, Nov 30, 2014 at 4:28 AM, Jakub Mareda jmar...@seznam.cz wrote: Hello, I'm investigating how to actually allow user to copy image data from web application. I have encountered broken links in the specification:

Re: CfC: publish a WG Note of Fullscreen; deadline November 14

On Sat, Nov 8, 2014 at 5:43 AM, Domenic Denicola d...@domenic.me wrote: From: Arthur Barstow [mailto:art.bars...@gmail.com] OK, so I just checked in a patch that sets the Latest Editor's Draft points to Anne's document https://dvcs.w3.org/hg/fullscreen/raw-file/default/TR.html. I think it

Re: [Imports]: Styleshet cascading order clarification

On Mon, Nov 3, 2014 at 7:28 AM, Gabor Krizsanits gkrizsan...@mozilla.com wrote: During our last meeting we all seemed to agree on that defining/implementing order for style-sheets is imports is super hard (if possible) and will bring more pain than it's worth for the web (aka. let's not make

Re: Push API and Service Workers

On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry erikco...@google.com wrote: * Push doesn't actually need SW's ability to intercept network communications on behalf of a web page. * You can imagine a push-handling SW that does all sorts of complicated processing of notifications, downloading things

Re: Questions on the future of the XHR spec, W3C snapshot

On Fri, Oct 17, 2014 at 6:05 PM, Domenic Denicola dome...@domenicdenicola.com wrote: No need to make this a vs.; we're all friends here :). FWIW previous specs which have needed to become abandoned because they were superceded by another spec have been re-published as NOTEs pointing to the

Re: [admin] Towards making ED boilerplates more useful and consistency

On Thu, Sep 4, 2014 at 5:43 AM, Arthur Barstow art.bars...@gmail.com wrote: Hi Editors, All, Speaking of ED boilerplate data ... do we want to try to get some consistency regarding boilerplate data in our EDs? We have quite a bit of variation now. For example Clipboard and others are toward

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard gl...@zewt.org wrote: My only issue is the wording: it doesn't make sense to have normative language saying you must not use this feature. This should be a non-normative note warning that this shouldn't be used, not a normative requirement

Re: XMLHttpRequest: uppercasing method names

On Tue, Aug 12, 2014 at 6:26 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

Re: =[xhr]

On Aug 1, 2014 8:16 AM, nmork_consult...@cusa.canon.com wrote: In this case, a freeze on all browser operations is desirable. The thread cannot be interrupted, and if it is interrupted (by browser closure or other such) then the transactions are immediately stopped and no update will occur

Re: =[xhr]

On Aug 1, 2014 8:39 AM, nmork_consult...@cusa.canon.com wrote: Spinner is not sufficient. All user activity must stop. They can take a coffee break if it takes too long. Browser must be frozen and locked down completely. No other options are desirable. All tabs, menus, etc. must be frozen.

Re: =[xhr]

On Aug 1, 2014 8:49 AM, nmork_consult...@cusa.canon.com wrote: Thank you for letting me know my input is not desired. All input is definitely desired, but you seem to either not fully understand what async XHR does, or are ascribing greater functionality to sync XHR than it actually possesses.

Re: =[xhr]

On Tue, Jul 29, 2014 at 1:41 PM, nmork_consult...@cusa.canon.com wrote: While debugging an intranet application using xmlHttpRequest recently, I got a message on the Firefox browser console: Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the

Re: =[xhr]

On Wed, Jul 23, 2014 at 4:49 PM, Paul bellamy p...@appl.com.au wrote: In the specification for XMLHttpRequest you posted a “warning” about using async=false which indicates that it is the intention to eventually remove this feature due to “detrimental effects to the user experience” when in a

Re: =[xhr]

On Sat, Jul 12, 2014 at 8:57 AM, Robert Hanson hans...@stolaf.edu wrote: Hello, I am the principal developer of Jmol, which has been successfully ported to JavaScript/HTML5 as JSmol. The following statement at http://xhr.spec.whatwg.org/ concerns me greatly: Developers must not pass false

Re: WebIDL Spec Status

On Wed, Jul 2, 2014 at 9:46 AM, Ryosuke Niwa rn...@apple.com wrote: There are other ways to mitigate these issues in addition to publishing every revision of a given specification. For example, spec authors could list support every historical terminology and fragmentation ever introduced.

Re: WebIDL Spec Status

On Wed, Jul 2, 2014 at 11:10 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Ian Hickson i...@hixie.ch I was going to link to the picture spec as my favorite example, but they seem to have made it less annoying (by moving it to the bottom instead of the middle), which is sad.

Re: Fallout of non-encapsulated shadow trees

On Tue, Jul 1, 2014 at 6:13 PM, Brendan Eich bren...@secure.meer.net wrote: Domenic Denicola wrote: From: Brendan Eich [mailto:bren...@secure.meer.net] That is a false idol if it means no intermediate steps that explain some but not all of the platform. Sure. But I don't think the

Re: publish new WD of Shadow DOM on June 12

On Fri, Jun 6, 2014 at 3:14 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Arthur Barstow [mailto:art.bars...@gmail.com] Could you live with those short qualifications/clarifications? Definitely; I see the concern and am glad you caught that. Yeah, sounds good. I've added an

Re: Fetch API

On Sat, May 31, 2014 at 11:06 PM, Domenic Denicola dome...@domenicdenicola.com wrote: - Named constructors scare me (I can't figure out how to make them work in JavaScript without breaking at least one of the normal invariants). I think a static factory method would make more sense for

Re: Fetch API

On Sun, Jun 1, 2014 at 2:19 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] Using NamedConstructor is identical to doing: ```js class Foo { ... } let Bar = Foo; // now I can do new Foo() or new Bar(), to the same effect

Re: Fetch API

On Thu, May 29, 2014 at 8:10 AM, Tobie Langel tobie.lan...@gmail.com wrote: On Thu, May 29, 2014 at 4:58 PM, Marcos mar...@marcosc.com wrote: enum RequestMode { same-origin, tainted cross-origin, CORS, CORS-with-forced-preflight }; I think these are badly named (even though they use the

Re: Last Call for CSS Font Loading Module Level 3

On Tue, May 27, 2014 at 1:22 AM, Jonas Sicking jo...@sicking.cc wrote: I've provided this input through a few channels already, but I don't think the user of [SetClass] here is good (and in fact I've been arguing that SetClass should be removed from WebIDL). Yes, there's an issue in the spec

Re: Last Call for CSS Font Loading Module Level 3

On Tue, May 27, 2014 at 11:44 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, May 27, 2014 at 10:41 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Separately, FontFace.loaded seems to fulfill the same purpose as FontFaceSet.ready(). I.e. both indicate that the object is done loading/parsing

Re: Last Call for CSS Font Loading Module Level 3

On Tue, May 27, 2014 at 3:47 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, May 27, 2014 at 12:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 27, 2014 at 11:44 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, May 27, 2014 at 10:41 AM, Tab Atkins Jr. jackalm...@gmail.com

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

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 Hickson suggested to publish my findings here so the Web Components team may

Re: [push-api] Identifying registrations

On Tue, May 13, 2014 at 1:08 AM, Martin Thomson martin.thom...@gmail.com wrote: The push API currently identifies a registration with a tuple: interface PushRegistration { readonlyattribute DOMString pushEndpoint; readonlyattribute DOMString pushRegistrationId; }; It looks

Re: Should events be preferably sent to the Window or the nearest object?

On Thu, Mar 20, 2014 at 8:33 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 21 Mar 2014, Mounir Lamouri wrote: I would love to gather the opinion of public-webapps on a discussion Hixie and I had for two different APIs recently: if an array |foo| can change, should the change event be fired on

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Mon, Mar 17, 2014 at 9:08 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Feb 13, 2014 at 2:34 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/13/14 5:35 AM, Anne van Kesteren wrote: Also, Type 2 can be used for built-in elements Built-in elements need Type 4. Well, Chrome does not

Re: Browser search API

On Thu, Mar 13, 2014 at 8:17 AM, Marcos Caceres w...@marcosc.com wrote: On March 12, 2014 at 7:16:53 PM, Mitar (mmi...@gmail.com) wrote: There was no reply. :-( It usually takes a bit of time for Hixie to get around to all the emails (the volume of email on the WHATWG list + other priorities

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Fri, Feb 14, 2014 at 6:12 PM, Daniel Freedman dfre...@google.com wrote: The other hand of this argument is that components that wish to lock themselves down could write: this.shadowRoot = undefined; Of course, this does would not change the outcome of the Shadow Selector spec, which is

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell slightly...@google.com wrote: Until we can agree on this, Type 2 feels like an attractive nuisance and, on reflection, one that I think we should punt to compilers like caja

  1   2   3   4   5   >