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 lo

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 can > define easily new standa

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 on the core HTML el

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 us from ever adding a

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 RFC 7230 all HTTP recipients “MUST be able to parse >> > the >> > chunked trans

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 > the preferred sty

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 has some Range-li

Re: Indexed DB + Promises

On Wed, Sep 30, 2015 at 11:07 AM, Kyle Huey wrote: > On Wed, Sep 30, 2015 at 10:50 AM, Tab Atkins Jr. wrote: >> 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 pref

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 that > perspective,

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] substantially predates the >

Re: PSA: publish WD of "WebIDL Level 1"

On Fri, Aug 7, 2015 at 9:23 AM, Travis Leithead 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 alternatives! In particular, you can

Re: PSA: publish WD of "WebIDL Level 1"

On Thu, Jul 30, 2015 at 7:29 AM, Arthur Barstow 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 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 corner-cas

Re: Writing spec algorithms in ES6?

On Thu, Jun 11, 2015 at 1:41 PM, Boris Zbarsky 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 code the

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 from

Re: [webcomponents] How about let's go with slots?

On Fri, May 15, 2015 at 4:58 PM, Scott Miles wrote: > Polymer really wants Shadow DOM natively, and we think the `slot` proposal > can work, so maybe let's avoid blocking on design of an imperative API > (which we still should make in the long run). How does it work for redistribution, and the ot

Re: :host pseudo-class

On Tue, May 5, 2015 at 10:56 PM, Anne van Kesteren wrote: > On Tue, May 5, 2015 at 8:39 PM, Tab Atkins Jr. 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 >> l

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

On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa wrote: >> On May 4, 2015, at 10:20 PM, Anne van Kesteren wrote: >> >>> On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn wrote: >>> We can solve this >>> problem by running the distribution code in a separate scripting context >>> with a restricted (dis

Re: :host pseudo-class

On Mon, May 4, 2015 at 9:52 PM, Jonas Sicking wrote: > On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron 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 model of a pseudo-class is t

Re: :host pseudo-class

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

Re: :host pseudo-class

On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren wrote: > On Fri, May 1, 2015 at 7:39 AM, Elliott Sprehn 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 >> connected to another element

Re: :host pseudo-class

On Thu, Apr 30, 2015 at 2:27 AM, Anne van Kesteren wrote: > On Mon, Apr 27, 2015 at 11:14 PM, Tab Atkins Jr. 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 not

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

On Wed, Apr 29, 2015 at 4:47 PM, Ryosuke Niwa wrote: >> On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. wrote: >> On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov wrote: >>> On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa wrote: >>>> One thing that worries me about t

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

On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov wrote: > On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa 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 >> without us having thoroughl

Re: Directory Upload Proposal

On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon 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 uploads. > >

Re: =[xhr]

On Tue, Apr 28, 2015 at 7:51 AM, Ken Nelson 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 an override password

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

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

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

On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa wrote: >> On Apr 27, 2015, at 3:15 PM, Steve Orvell 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 explain the two declarative

Re: :host pseudo-class

On Sat, Apr 25, 2015 at 9:32 AM, Anne van Kesteren 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 that since e.g.

Re: Proposal for changes to manage Shadow DOM content distribution

On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa 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 > DEFINITELY NOT

Re: Proposal for changes to manage Shadow DOM content distribution

On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky 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 base class inser

Re: Proposal for changes to manage Shadow DOM content distribution

On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa wrote: > On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. wrote: >> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa wrote: >>> On Apr 22, 2015, at 8:52 AM, Domenic Denicola wrote: >>>> Between content-slot-specified sl

Re: Proposal for changes to manage Shadow DOM content distribution

On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa wrote: >> On Apr 22, 2015, at 8:52 AM, Domenic Denicola 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 reinvented a micro-langua

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: PSA: publishing new WD of File API on April 21

On Wed, Apr 15, 2015 at 3:00 PM, Arthur Barstow wrote: > On 4/15/15 5:56 PM, Tab Atkins Jr. wrote: >> >> On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow >> wrote: >>> >>> <https://w3c.github.io/FileAPI/TR.html> >> >> Note that this ver

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

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow wrote: > Hi All, > > A new Working Draft publication of File API is planned for April 21 using > the following version as the basis: > > Note that this version appears to be based off the file in the CVS rep

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

On Wed, Apr 15, 2015 at 12:54 PM, Martin Thomson wrote: > On 15 April 2015 at 07:26, Arthur Barstow wrote: >>> * This spec is now using Github >> >> >> That repo is actually . > > > Since the most obvious github.io link is currentl

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

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow wrote: > * This spec is now using Github and the ED > is . PRs are welcome and > encouraged. (I think it would be useful if this spec used ReSpec and if > anyone can help w

Re: template namespace attribute proposal

On Wed, Mar 18, 2015 at 2:06 PM, Ryosuke Niwa wrote: > On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. wrote: >> Karl Dubost said: >>> The intersection seems to be: >>> ['a', 'style', 'script', 'track', 'title', 'canva

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', 'fon

Re: template namespace attribute proposal

On Fri, Mar 13, 2015 at 2:09 PM, Jonas Sicking wrote: > Unless the SVG WG is willing to drop support for > . 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, with the CDATA parts on thei

Re: template namespace attribute proposal

On Fri, Mar 13, 2015 at 1:48 PM, Jonas Sicking wrote: > On Fri, Mar 13, 2015 at 1:16 PM, Tab Atkins Jr. wrote: >> On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren wrote: >>> On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh wrote: >>>> What are your thoughts on

Re: template namespace attribute proposal

On Fri, Mar 13, 2015 at 1:27 PM, Benjamin Lesh 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 we've failed t

Re: template namespace attribute proposal

On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren wrote: > On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh 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. table elements are > special-ca

Re: Standardising canvas-driven background images

On Fri, Feb 20, 2015 at 1:50 PM, Matthew Robb wrote: > On Fri, Feb 20, 2015 at 2:25 PM, Tab Atkins Jr. > 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 are: http:/

Re: Standardising canvas-driven background images

On Fri, Feb 20, 2015 at 7:51 AM, Ashley Gullen 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 > http://updates.html5rocks.com/2012/12/Canvas-driven-backgro

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

On Thu, Feb 12, 2015 at 1:45 PM, Marc Fawzi 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 so far, miraculo

Re: Are web components *seriously* not namespaced?

On Fri, Feb 6, 2015 at 8:12 AM, Kurt Cagle 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 Balisage > or an

Re: Are web components *seriously* not namespaced?

On Fri, Feb 6, 2015 at 12:48 AM, Glen 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 different fo

Re: Minimum viable custom elements

On Fri, Feb 6, 2015 at 2:13 AM, Chris Bateman wrote: > ** Bonus issue - I didn't know this, but Chrome doesn't upgrade when you add > the is= attribute to an element that's already been created. Ember builds up > its templates into document fragments - so the input failed to upgrade in > Chrome. T

Re: Are web components *seriously* not namespaced?

On Thu, Feb 5, 2015 at 3:57 PM, Benjamin Goering 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 all day. They

Re: Are web components *seriously* not namespaced?

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

Re: Are web components *seriously* not namespaced?

On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle 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 registries will,

Re: Shadow tree style isolation primitive

On Thu, Feb 5, 2015 at 11:03 AM, Olli Pettay 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 whol

Re: Shadow tree style isolation primitive

On Thu, Feb 5, 2015 at 10:56 AM, Ryosuke Niwa wrote: >> On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. wrote: >> On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay wrote: >>> Why do we need shadow DOM (or something similar) at all if we expose it >>> easily to the outside

Re: Shadow tree style isolation primitive

On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay 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 used a

Re: Shadow tree style isolation primitive

On Wed, Feb 4, 2015 at 11:36 PM, Olli Pettay 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 they're doing and

Re: Are web components *seriously* not namespaced?

On Thu, Feb 5, 2015 at 8:31 AM, Glen 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" > namespacing. Prefix

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 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 practically

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 12:27 PM, Ryosuke Niwa wrote: >> On Jan 15, 2015, at 11:47 AM, Brian Kardell 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 which thread? Could you g

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 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 selections >

Re: Shadow tree style isolation primitive

On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa wrote: >> On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. 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. I

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 wrote: > On Jan 12, 2015, at 4:59 PM, Tab Atkins Jr. wrote: >> On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa wrote: >>> On Jan 12

Re: Shadow tree style isolation primitive

On Mon, Jan 12, 2015 at 4:45 PM, Ryosuke Niwa wrote: > I understand your use case but please also understand that some authors > don't want to write a few dozen lines of JavaScript to create a shadow DOM, > and hundreds of lines of code or load a framework to decoratively isolate > CSS rules in th

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 wrote: > On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr. wrote: >> ? I didn't mention DOM APIs. I'm referring back to the example you're >> replying to - if

Re: Shadow tree style isolation primitive

On Mon, Jan 12, 2015 at 3:51 PM, Ryosuke Niwa wrote: >> On Jan 12, 2015, at 2:41 PM, Tab Atkins Jr. wrote: >> On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa wrote: >>>> On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. wrote: >>>> Let's assume we did it, thou

Re: Shadow tree style isolation primitive

On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa wrote: >> On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. 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 >> "i

Re: Shadow tree style isolation primitive

On Fri, Jan 9, 2015 at 5:40 AM, Anne van Kesteren 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 necessarily u

Re: Custom element design with ES6 classes and Element constructors

On Mon, Jan 12, 2015 at 5:16 AM, Anne van Kesteren wrote: > On Sun, Jan 11, 2015 at 9:13 PM, Domenic Denicola 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 > tell to maintain a sane

Re: Shadow tree style isolation primitive

On Fri, Jan 9, 2015 at 8:08 AM, Dimitri Glazkov 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: > > https://docs.google.com/d

Re: Broken links

On Sun, Nov 30, 2014 at 4:28 AM, Jakub Mareda 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: > > http://dev.w3.org/2006/webapi/clipops/clipops.html#h2_apis-from-other-specifications > >

Re: Help with WebIDL v1?

On Mon, Dec 1, 2014 at 12:57 PM, Travis Leithead 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 additions, improvements, and bug fi

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

On Sat, Nov 8, 2014 at 5:43 AM, Domenic Denicola 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 >> . > > I think it would

Re: [Imports]: Styleshet cascading order clarification

On Mon, Nov 3, 2014 at 7:28 AM, Gabor Krizsanits 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 an already > over-

Re: Push API and Service Workers

On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry 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 to a local > dat

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

On Fri, Oct 17, 2014 at 6:05 PM, Domenic Denicola 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 > source material. That

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

On Thu, Sep 4, 2014 at 5:43 AM, Arthur Barstow 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 the more minim

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard 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 telling people

Re: =[xhr]

On Wed, Sep 3, 2014 at 8:34 AM, Brendan Eich wrote: > David Rajchenbach-Teller wrote: >> Clearly, it would require big changes, although compiling to return >> Promise and using Task.js + yield at call sites would probably be much >> simpler than CPS conversion. > > All call sites, every last Java

Re: XMLHttpRequest: uppercasing method names

On Tue, Aug 12, 2014 at 6:26 AM, Anne van Kesteren 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 the HT

Re: =[xhr]

On Aug 1, 2014 8:49 AM, 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. So far you have not described

Re: =[xhr]

On Aug 1, 2014 8:39 AM, 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. That is exactly the desired

Re: =[xhr]

On Aug 1, 2014 8:16 AM, 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 (this is the most desirable outcom

Re: =[xhr]

On Tue, Jul 29, 2014 at 1:41 PM, 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 end > user's experience." > >

Re: =[xhr]

On Wed, Jul 23, 2014 at 4:49 PM, Paul bellamy 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 > document envi

Re: =[xhr]

On Sat, Jul 12, 2014 at 8:57 AM, Robert Hanson 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 for the async a

Re: WebIDL Spec Status

On Wed, Jul 2, 2014 at 11:10 AM, Domenic Denicola wrote: > From: Ian Hickson > I was going to link to the 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. That's for consistency with the messages use

Re: WebIDL Spec Status

On Wed, Jul 2, 2014 at 9:46 AM, Ryosuke Niwa 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. We > could

Re: Fallout of non-encapsulated shadow trees

On Tue, Jul 1, 2014 at 6:13 PM, Brendan Eich 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 propos

Re: publish new WD of Shadow DOM on June 12

On Fri, Jun 6, 2014 at 3:14 PM, Domenic Denicola 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 issue to Bikeshed

Re: Fetch API

On Sun, Jun 1, 2014 at 2:19 PM, Domenic Denicola 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 &qu

Re: Fetch API

On Sat, May 31, 2014 at 11:06 PM, Domenic Denicola 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 RedirectResponse. What invaria

Re: Fetch API

On Thu, May 29, 2014 at 8:10 AM, Tobie Langel wrote: > On Thu, May 29, 2014 at 4:58 PM, Marcos wrote: >> >> >> > enum RequestMode { "same-origin", "tainted cross-origin", "CORS", >> > "CORS-with-forced-preflight" }; >> >> I think these are badly named (even though they use the names used in HTML

Re: Last Call for "CSS Font Loading Module Level 3"

On Tue, May 27, 2014 at 3:47 PM, Jonas Sicking wrote: > On Tue, May 27, 2014 at 12:14 PM, Tab Atkins Jr. wrote: >> On Tue, May 27, 2014 at 11:44 AM, Jonas Sicking wrote: >>> On Tue, May 27, 2014 at 10:41 AM, Tab Atkins Jr. >>> wrote: >>>>> Separately,

Re: Last Call for "CSS Font Loading Module Level 3"

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

Re: Last Call for "CSS Font Loading Module Level 3"

On Tue, May 27, 2014 at 1:22 AM, Jonas Sicking 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 already saying

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

On Tue, May 20, 2014 at 8:41 PM, Axel Dahmen wrote: > I got redirected here from a HTML5 discussion on an '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 consider to re-evaluate

Re: [push-api] Identifying registrations

On Tue, May 13, 2014 at 1:08 AM, Martin Thomson wrote: > The push API currently identifies a registration with a tuple: > > interface PushRegistration { > readonlyattribute DOMString pushEndpoint; > readonlyattribute DOMString pushRegistrationId; > }; > > It looks like both are use

Re: RE: It doesn't make sense to use [MapClass] for the CacheList interface

[random interjection] On Sun, May 11, 2014 at 9:41 PM, Domenic Denicola wrote: > Part of the issue is might be that you are seeing things in terms of > TypeScript, instead of in terms of JavaScript. In JavaScript, those generic > type parameters are meaningless, and the entire idea of a "interf

  1   2   3   4   5   >