Quick update on WebIDL "Level 1"

While editing work continues on the "second edition" of WebIDL here: http://heycam.github.io/webidl/, we have been fine-tuning the "Level 1" CR snapshot [1] to replace and supersede the 2012 version [2]. The "Level 1" editors are making final tweaks to the draft and tests, and hope to be ready

RE: Republish Pointer Lock as CR

+1 in favor of supporting a republishing as CR. -Original Message- From: Léonie Watson [mailto:t...@tink.uk] Sent: Monday, June 13, 2016 9:13 AM To: 'public-webapps WG' Subject: CFC: Republish Pointer Lock as CR Hello WP, This is a Call For Consensus (CFC) to request that W3C republish

RE: Publish as W3C Notes

Publish as note and Incubate +1 -Original Message- From: Léonie Watson [mailto:t...@tink.uk] Sent: Tuesday, April 26, 2016 11:06 AM To: public-webapps@w3.org Subject: CFC: Publish as W3C Notes Hello, At the AC meeting in March 2016 the WP co-chairs indicated that the following two spec

RE: Alex Danilo introduction

Welcome, and nice to have you with us! From: adan...@google.com [mailto:adan...@google.com] On Behalf Of Alex Danilo Sent: Monday, March 21, 2016 9:56 PM To: public-weba...@w3c.org Subject: Alex Danilo introduction Hi All, My name is Alex Danilo and I've joined the Web Platform Working Group. I

RE: Can we land heycam's WebIDL tests as-is and address review comments following?

Yves and I have been reviewing these tests and revising them according to recent WebIDL changes and we think they may be ready to be integrated. The updates are in a PR on heycams page. Let’s not integrate heycam’s original PR until our update is done first please… From: Simon Pieters

RE: Meeting date, january

25th works for me. -Original Message- From: Domenic Denicola [mailto:d...@domenic.me] Sent: Tuesday, December 1, 2015 8:32 AM To: Chaals McCathie Nevile ; 'public-webapps WG' ; Léonie Watson Cc: Anne van Kesteren Subject: RE: Meeting date, january From: Chaals McCathie Nevile [mailto:

RE: Callback when an event handler has been added to a custom element

Interesting. Alternatively, you can add .onwhatever handlers, as well as define your own overload of addEventListener (which will be called instead of the EventTarget.addEventListener method). That way you can capture all attempts at setting events on your element. -Original Message- Fr

RE: [Web Components] proposing a f2f...

I would prefer a late January date so as to allow me to arrange travel. Otherwise, I’m happy to attend remotely anytime. From: Dimitri Glazkov [mailto:dglaz...@google.com] Sent: Thursday, October 29, 2015 2:52 AM To: Olli Pettay Cc: Chaals McCathie Nevile ; public-webapps WG Subject: Re: [Web

RE: Shadow DOM and SVG use elements

Well, since SVG 'use' is mostly about replicating the composed tree anyway, it seems that is should probably render the composed tree--e.g., this seems natural, because use would "replicate" the host element, which would then render it's shadow DOM. The interactivity behaviors associated with th

RE: ISSUE-187: Https://github.com/w3c/uievents/issues/20

I closed this--it was opened by accident. -Original Message- From: Web Applications Working Group Issue Tracker [mailto:sysbot+trac...@w3.org] Sent: Tuesday, October 6, 2015 5:26 PM To: public-webapps@w3.org Subject: ISSUE-187: Https://github.com/w3c/uievents/issues/20 ISSUE-187: Https:

RE: Tests for new shadow DOM API

Why not deprecate/remove the existing tests in the current folder structure? Presumably we can replace them with new tests that are aligned with the recent spec changes? If the existing tests really aren't relevant anymore, I don't see a reason to keep them around. From: rn...@apple.com [mailt

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

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. From: Anne van Kesteren Sent: Friday, August 7, 2015 5:55 AM To: Art

RE: alternate view on constructors for custom elements

From: Domenic Denicola [mailto:d...@domenic.me] > >From: Travis Leithead [mailto:travis.leith...@microsoft.com] > >> Something magical happens here. The use of super() is supposed to call the >> constructor of the HTMLElement class—but that’s not a normal JS class. It >

alternate view on constructors for custom elements

OK, after reading Dominic's proposal [1], I'm a little confused. I thought that I understood how constructors should work, but there's some magic going on that I can't follow... I'm sure you folks can help. ``` class CustomElement extends HTMLElement { constructor() { super(); } } S

[WebIDL] T[] migration

Hey folks, Now that WebIDL has added FrozenArray<> and dropped T[], it's time to switch over! On the other hand, there are a number of specs that have already gone to Rec that used the old syntax. Recommendations: *HTML5 *Web Messaging Other references: *CSS OM *

RE: The key custom elements question: custom constructors?

I've discussed this issue with some of Edge's key parser developers. From a technical ground, we do not have a problem with stopping the parser to callout to author code in order to run a constructor, either during parsing or cloning. For example, in parsing, I would expect that the callout happ

RE: [ime-api] [blink-dev] Removing IME API code from Blink

in IE. -Original Message- From: Travis Leithead Sent: Thursday, June 18, 2015 11:49 AM To: 'Arthur Barstow'; Ryosuke Niwa Cc: public-webapps Subject: RE: [ime-api] [blink-dev] Removing IME API code from Blink I've posted the notice on the editor's draft as suggested be

RE: Async Image -> ImageData conversion

...@scirra.com] On Behalf Of Ashley Gullen Sent: Wednesday, June 17, 2015 2:06 PM To: Travis Leithead Cc: public-webapps@w3.org Subject: Re: Async Image -> ImageData conversion That seems like a good start. I suppose there should be a putImageDataAsync counterpart too? Then we can do: Blob -> Image via

RE: [ime-api] [blink-dev] Removing IME API code from Blink

s API (prefixed, in IE11 & Edge), but the API only lights up when you use built-in Microsoft IMEs (not 3rd party IMEs at the moment :( ). -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: Thursday, June 11, 2015 3:42 AM To: Travis Leithead; Ryosuke Niwa

RE: Async Image -> ImageData conversion

I think solving at least the first-order problem of extracting data from the Canvas async is do-able. Something like: Promise getImageDataAsync(x,y,w,h); seems sensible to add ☺ From: a...@scirra.com [mailto:a...@scirra.com] On Behalf Of Ashley Gullen Sent: Wednesday, June 17, 2015 10:00 AM To

Re: Custom Elements: is=""

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

RE: [ime-api] [blink-dev] Removing IME API code from Blink

ure. It's still something I'd like to see moved forward, I just don't believe I have the time to move it substantially forward at the present moment :) -Original Message- From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Wednesday, May 27, 2015 7:00 PM To: Travis Leithead Cc:

RE: [ime-api] Fwd: [blink-dev] Removing IME API code from Blink

I believed the use-cases for avoiding UI clashes between site-driven auto-complete lists and IME auto-complete boxes is still a valid use case, and I think the spec is still valid to try to push to recommendation. However, I'd also like to follow up on usage of the ms- prefixed API so that I can

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

This works for me too. And I like the proposed new bikeshed-ed names Anne suggests below. -Original Message- From: Anne van Kesteren [mailto:ann...@annevk.nl] Sent: Wednesday, May 20, 2015 9:10 PM To: Dimitri Glazkov Cc: Scott Miles; Ryosuke Niwa; Edward O'Connor; Travis Lei

RE: Shadow DOM: state of the distribution API

I wonder if there is some sort of imperative-declarative model that we could adopt here? I mean, allow script to specify the distribution logic, but do it with a static model. After all, what is being asked for is a relatively simple mapping from candidate node to content distribution point. I’

RE: Custom Elements: is=""

[mailto:justinfagn...@google.com] Sent: Friday, May 8, 2015 1:06 PM To: Travis Leithead Cc: Ryosuke Niwa; Anne van Kesteren; WebApps WG Subject: Re: Custom Elements: is="" If I'm understanding your proposal correctly, wouldn't this limit any document to have a single subclass per

RE: Custom Elements: is=""

The 'is' attribute is only a declarative marker; it's the indicator that the native element has a [potential] custom prototype and hierarchy, right? I don't mean to drudge up past history and decisions already laid to rest, but if subclassing native elements is a good compromise until we get to

RE: [components] Isolated Imports and Foreign Custom Elements

7;m not sure to what extent your two-way membrane proxy would handle this case... -Original Message- From: Maciej Stachowiak [mailto:m...@apple.com] Sent: Friday, May 1, 2015 2:57 PM To: Travis Leithead Cc: Anne van Kesteren; WebApps WG Subject: Re: [components] Isolated Imports and F

RE: [components] Isolated Imports and Foreign Custom Elements

If you take a look at [1], we extend the custom elements registration mechanism so that the constructor is still available in the hosting global, yet the implementation is defined in the isolated environment. An approach to solving this might address another concern I have... I've been thinking

RE: Directory Upload Proposal

>> Aaron opened an issue for this on GitHub [1] and I agree that it is a >> problem and we should definitely rename it to something else! One option >> might be to change dir to directory, but we would need a different name for >> directory (the attribute that gets back the virtual root holding

RE: Directory Upload Proposal

>> Second, rather than adding a .directory attribute, I think that we should >> simply add any selected directories to the .files list. My experience is >> that having a direct mapping between what the user does, and what we expose >> to the webpage, generally results in less developer confusion

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

Nice work folks, and thanks for writing this up so quickly! Anne's Gist captured exactly what I was thinking this would look like. One nit: it would be nice if the callback could be registered from _inside_ the shadowRoot, but I couldn't come up with a satisfactory way to do that without adding

Web Components Viewpoint from the Microsoft Guy

Like Mozilla and Apple [1] [2], I would also like to briefly lay out my viewpoint on Web Components in advance of the face-to-face meeting. I love the work that has been done thus far on the web components specs, and while Microsoft has not yet begun development of these features [3] I know they

RE: Proposal for changes to manage Shadow DOM content distribution

I like that the light-side DOM elements must opt-in to being redistributed. While appearing at first like a hindrance, it does ensure that elements can't be arbitrarily re-distributed without their consent. If you imagine allowing redistribution into a cross-origin shadow dom, then it becomes so

RE: [Imports] Considering imperative HTML imports?

Hmmm. Well, regardless, this is tracked here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319, so I'll add a few comments to that bug. -Original Message- From: Anne van Kesteren [mailto:ann...@annevk.nl] Sent: Thursday, April 16, 2015 12:54 PM To: Travis Leithead Cc: Boris Zb

RE: [Imports] Considering imperative HTML imports?

4/16/15 12:37 AM, Travis Leithead wrote: > Was an imperative form of HTML imports already considered? E.g., the > following springs to mind: > >Promise importDocument(DOMString url); How is this different from a promise-ified version of XHR, exactly? (Not that there's an

[Imports] Considering imperative HTML imports?

Was an imperative form of HTML imports already considered? E.g., the following springs to mind: Promise importDocument(DOMString url); I was thinking about Worker's importScripts(DOMString... urls), and the above seems like a nice related corollary.

RE: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

Microsoft supports publishing this. Thanks to all involved! - Subject:CfC: publish Proposed Recommendation of Web Messaging; deadline March 28 Date: Sat, 21 Mar 2015 08:51:45 -0400 From: Arthur Barstow To: public-webapps As previously mentioned on [p-w], the test result

RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

something that makes sense? From: Elliott Sprehn [mailto:espr...@chromium.org] Sent: Thursday, March 26, 2015 12:59 PM To: Travis Leithead Cc: Justin Fagnani; Dimitri Glazkov (dglaz...@google.com); Arron Eicholz; Anne van Kesteren (ann...@annevk.nl); Ryosuke Niwa; WebApps WG Subject: Re: [Shadow] Q

RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

>From: Daniel Freedman [mailto:dfre...@google.com] >How would you style these "shadow" children? Would the main document CSS >styles affect these children? I don’t know :-) Let's assume that main document CSS styles wouldn't affect them, as that seems to be a fundamental requirement for shadow

RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

> From: Justin Fagnani [mailto:justinfagn...@google.com] >> Elements expose this “shadow node list” via APIs that are very similar to >> existing node list management, e.g., appendShadowChild(), >> insertShadowBefore(), >> removeShadowChild(), replaceShadowChild(), shadowChildren[], >> shadowC

RE: [Shadow] URL-based shadows?

>From: Anne van Kesteren [mailto:ann...@annevk.nl] > >Depending on the changes we make based on > https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits > >this might already be the case. Also, I believe currently the Web >Components polyfill makes some assumptions about all of We

[Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

Hi folks, Today's ShadowDOM model is designed around only adding shadow roots to element in the 'light side'. I assume this is intentional, but was hoping someone could describe why this design was chosen? Or said another way, if there was an imperative API to _remove_ a shadow DOM, would that

RE: [Shadow] URL-based shadows?

>Ryosuke Niwa [mailto:rn...@apple.com] wrote: > >> Travis wrote: >> 2.&4. I keep running into trouble when thinking about a declarative model >> for web components because declarative models are based on persistent >> objects in the DOM, and those persistent objects are fully mutable. In other >

Re: [Shadow] URL-based shadows?

Yes, loading components via imports today is "use at your own risk" since you pull that content directly into your trust boundary. At least with

RE: [Shadow] URL-based shadows?

y necessary for the cross-origin use case. [1] https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Wednesday, March 18, 2015 2:26 PM To: Travis Leithead Cc: Dimitri Glazkov (dglaz...@google.com); WebApps WG; Anne van Kesteren (a

RE: [Shadow] URL-based shadows?

I think ‘Worker’ threw me off at first ☺. My original use case was to make the current model of loading components more “local”, as AFAIK, these components can only presently be loaded by code you trust, e.g., via some script library somewhere imported via a

Re: [Shadow] URL-based shadows?

nchronously loading a shadow dom as work today (without a URL) may be largely unaffected. ____ From: Dimitri Glazkov Sent: Friday, March 13, 2015 10:44 AM To: Travis Leithead Cc: WebApps WG; Anne van Kesteren (ann...@annevk.nl); Arron Eicholz; Elliott Sprehn Subject: Re:

[Shadow] URL-based shadows?

Dimitri et al., Has the idea of loading/parsing a Shadow DOM directly from a URL been discussed already? (e.g., a sort-of "micro-import" or an import that parses its document directly into the ShadowRoot container?) I'm curious to know if there's some obvious flaw that I'm missing. element.

RE: template namespace attribute proposal

I would also prefer to enable this to work without any extra annotation. So much of the rest of how SVG/MathML are handled in HTML is seamless by design. From: ad...@google.com [mailto:ad...@google.com] On Behalf Of Adam Klein Sent: Thursday, March 12, 2015 11:17 AM To: Benjamin Lesh Cc: WebApps

[UIEvents] telecon minutes 10 March 2015

https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html status of the editor's draft garykac: we hadn't moved locale and getKeyboardState into D3E because they required more spec work. ... we also knew that keyboard locale was underspecified. ... there was one other thing... See t

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

Marc, I'd first mention that I am keenly interested in improving the state-of-the-art in DOM (I'm driving the project to update IE's 20-year-old DOM as my day job.) I've also done a lot of thinking about thread-safe DOM designs, and would be happy to chat with you more in depth about some ideas

[DOM3Events/UIEvents] Minutes from 10 Feb 2015 teleconference

Contents * Topics * Bug 27991 * Bug 27990 * Summary of Action Items

[DOM3Events/UIEvents] Minutes from 27 Jan 2015 teleconference

Minutes logged at: http://www.w3.org/2015/01/28-webapps-minutes.html Previous minutes: https://www.w3.org/2008/webapps/wiki/Bi-weekly_meetings Travis: Hi garykac: Hi, masayuki: Hello Travis is having trouble with IRC. He's working on a fix right now. Oh, I see. We have a few things to fo

[D3E/UIEvents] Transferring related Bugzilla bugs to github issues

Hi Ben/Gary, Per the discussion in our recent telecon, here is a list of the bugs currently active in the DOM3 Events component on bugzilla, that you should consider migrating into your github issue tracking system: 26612 WebAppsW DOM3 Eve

RE: Help with WebIDL v1?

> From: Sam Ruby [mailto:ru...@intertwingly.net] > > Another way to phrase this question: what would the CR exit criteria be for > such a WebIDL v1? The reason why I bring this up is that if they are too low > to be meaningful, that brings into the question whether or not this exercise > is meani

RE: Help with WebIDL v1?

next steps are for moving this v1 forward. If there are bug fixes and improvements that need to go back to v1, than I'm volunteering to help get that work done. -Original Message- From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] Sent: Monday, December 1, 2014 1:36 PM To: Travis Lei

Help with WebIDL v1?

Yves, 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! -Travis

RE: CfC: publish WG Note of UI Events; deadline November 14

To clarify: are you asking to rename "DOM Level 3 Events" to "UI Events"? Perhaps a fresh name would help get that spec done faster :) Gary what do you think? -Original Message- From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren Sent: Frid

RE: [minutes] 2014-Oct-28 f2f meeting in Santa Clara, CA

For folks involved in the URL discussion; please review my scribed notes to make sure they are accurate--I had someone point out that I may have swapped a "W3C" for a "WHATWG" (or vice-versa) a couple of times which was accidental. Thanks! -Original Message- From: Arthur Barstow [mailto

RE: innerText spec

There was interest in the room at TPAC at making this a new unique spec deliverable under webapps. Ryosuke: See also: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145 -Original Message- From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Tuesday, September 16, 2014 7:28 PM To: Ms2ger;

RE: WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note

>From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf >Of Anne van Kesteren >On Mon, Oct 27, 2014 at 8:06 PM, Travis Leithead > wrote: >> We should have a plan for the bugzilla component (there are some good >> "future" bugs logged th

RE: WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note

We should have a plan for the bugzilla component (there are some good "future" bugs logged there). Would the bugzilla component stay open? Would we need to move the bugs to D3E otherwise? (We can mark them future, or something to distinguish them.) -Original Message- From: Web Applicati

RE: [DOM-Level-3-Events] Synthetic mouse events triggering default action

-Original Message- From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren > On Wed, Oct 15, 2014 at 2:40 AM, Bogdan Brinza wrote: >> http://www.w3.org/TR/DOM-Level-3-Events/#trusted-events > >That text is utterly broken as we've discussed several

RE: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'})))

y, June 10, 2014 3:00 AM To: Travis Leithead; Web Applications Working Group WG (public-webapps@w3.org) Subject: Re: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'}))) Thanks, any way to track/be notified when this will be available? Reg

RE: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'})))

[mailto:vitteayme...@gmail.com] Sent: Tuesday, June 10, 2014 3:00 AM To: Travis Leithead; Web Applications Working Group WG (public-webapps@w3.org) Subject: Re: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'}))) Thanks, any way to track/be not

RE: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'})))

Vitte [mailto:vitteayme...@gmail.com] Sent: Friday, June 6, 2014 6:25 AM To: Web Applications Working Group WG (public-webapps@w3.org) Cc: Travis Leithead Subject: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'}))) Why IE(11) does not allow thi

RE: contentEditable=minimal

DOM L3 does require implementations to fire composition event for dead-key combinations, so insofar as the (Alt-`) combo results in a dead key for accent-grave (and other dead key combos mentioned below), the composition events should (or are supposed to) fire as a result. -Original Message

RE: [editing] CommandEvent and contentEditable=minimal Explainer

Be careful with having events fire before the DOM is updated—at a minimum you’ll want to consider whether you will allow dangerous situations like the legacy MutationEvents could cause (start a change -> pre-change notification -> make another change -> pre-change notification … unexpected thing

RE: Composition events (was: contentEditable=minimal)

+Gary/Masayuki who can help with deciphering DOM L3 Events :-) -Original Message- From: Robin Berjon [mailto:ro...@w3.org] Sent: Tuesday, May 27, 2014 2:15 AM To: Ben Peters; Jonas Sicking Cc: public-webapps@w3.org Subject: Composition events (was: contentEditable=minimal) On 27/05/2014

RE: contentEditable=minimal

+Gary and Masayuki --This seems very related to the discussion we are having regarding when to fire "beforeinput". "beforeinput" might be duplicating some of the use-cases that the insertText command event might be supporting. -Original Message- From: Robin Berjon [mailto:ro...@w3.org]

RE: [April2014Meeting] Seeking status and plans from Editors not attending meeting; deadline April 9

AM To: Hallvord Steen; Travis Leithead; "Gary Kacmarcik (Кошмарчик)"; Eric Uhrhane; Ted Mielczarek; Scott Graham; Vincent Scheib; Kinuko Yasuda; Bryan Sullivan; EDUARDO FULLEA CARRERA Cc: public-webapps Subject: [April2014Meeting] Seeking status and plans from Editors not attending meet

RE: [Custom Elements] attributeChanged not sufficient?

As a point of information, IE supports an "elementresize" event in order to support this scenario. It's not great because it puts a lot of implementation requirements on our layout engine, but it's one potential approach to addressing this scenario. (Note, the event is prefixed in our implement

RE: [Dom-Parsing] LC1 Comments Addressed for DOM Parsing and Serialization

> From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf > Of Anne van Kesteren >> On Thu, Mar 27, 2014 at 10:09 PM, Travis Leithead >> wrote: >> My goal is to have these additional bugs resolved by the time of the >> face-to-face WebApps mee

[Dom-Parsing] LC1 Comments Addressed for DOM Parsing and Serialization

By way of general information, the Last Call Comments [1] collected from the DOM Parsing and Serialization W3C spec have now been addressed in the latest editor's draft. [2] In the course of working on those bugs, additional bugs were found and filed [3]. My goal is to have these additional bu

On starting WebWorkers with blob: URLs...

Seems like our specs are getting a little behind implementations. In IE11 we are finding that several new sites, notably those using WebGL content, have a dependency on starting web workers with a Blob URL. As I understand it: The W3C Web Workers spec (CR stage) forbids use of the data and [impl

RE: "Officially" deprecating main-thread synchronous XHR?

As I understand it, that is one of the scenarios covered by the recently proposed Beacon API: http://www.w3.org/TR/beacon/ Sent from my Windows Phone From: Scott González Sent: 2/7/2014 9:33 AM To: Anne van Kesteren Cc: Jonas Sicking; Domenic Denicola; o...@petta

DOM P&S: Disposition of Comments Doc Prepared

Hey folks, with the completion of the Last Call period for DOM Parsing and Serialization (last month on January 7th), I've collected all the technical comments that came in during that time in a disposition of comments document: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/LC1_comments.htm Ple

RE: Refactoring SharedWorkers out of Web Workers W3C spec

Thanks James. I'll wait till the broken tests are fixed to re-review the IE results. From: James Graham Sent: 12/16/2013 9:55 AM To: public-webapps@w3.org Subject: Re: Refactoring SharedWorkers out of Web Workers W3C spec On 16/12/13 16:43, Arthur Barstow wrote: >

RE: Refactoring SharedWorkers out of Web Workers W3C spec

From: Arthur Barstow [mailto:art.bars...@nokia.com] > wrote: > Travis - would you please add results for IE? Done. Note: IE's implementation generates a Syntax Error on 'new Worker("#")' which causes a huge chunk of these tests to fail, where otherwise, I think we would be passing them if we co

Refactoring SharedWorkers out of Web Workers W3C spec

During TPAC 2013 in Shenzhen, I took an action item [1][2] to remove Shared Workers from the W3C Web Workers spec [3] in order for the spec to pass the first of the two stated CR exit criteria in the spec itself. It is my intention to start this work soon. My question for the group-should I tra

RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

there may be a separate concern with the references though. I don't currently make a reference to DOM L3 Core for CDATASection or internalSubset. Should I be? -Travis From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Wed, Nov 27, 2013 at 5:22 PM, Travis Leithead wrote: >

RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23936 to track this LC comment :-) -Original Message- From: Travis Leithead Sent: Wednesday, November 27, 2013 9:23 AM To: 'Arthur Barstow'; Anne van Kesteren Cc: public-webapps Subject: RE: CfC: publish LCWD of DOM P

RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

Fair enough. By the way, I don't see the reference to DOM L2 Core in the Editor's draft (there's a reference to it in the source code, but not in the rendered HTML). I did end up talking about the (historical) internalSubset property of the Doctype object for serialization--since browsers will

RE: publish LCWD of DOM Parsing and Serialization; deadline November 25

Resolved it today. Took one more change to the ED draft to update the SOTD, Acknowledgements section, and document headers. -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Tuesday, November 26, 2013 5:46 AM To: Travis Leithead Cc: Webapps WG Subject: Re

RE: publish LCWD of DOM Parsing and Serialization; deadline November 25

I've finished the major updates. Today's ED draft at: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html should be ready to use as the baseline for the Last Call CfC. Thanks, Travis -Original Message----- From: Travis Leithead Sent: Monday, November 18, 2013 11:26 AM To:

RE: publish LCWD of DOM Parsing and Serialization; deadline November 25

If possible, I'd like to delay this CfC, for a week--I have some major updates to the ED in-flight, and I want to make sure we base the CfC on the right ED content :-) Hopefully this is workable to the group. Thanks! - From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, Novem

Request for publication: DOM L3 Events & UI Events

The editors of the DOM Level 3 Events specification have reached a milestone where we believe most of the major open issues are now resolved in the editor's draft, and we would like to issue a call to publish an updated *working draft* of the spec for wider review. (It has also been quite a whil

RE: Shadow DOM and Fallback contents for images

From: Jonas Sicking [mailto:jo...@sicking.cc] > Though I'd also be interested to hear how other implementations feel about > the Gecko solution of allowing selection to be comprised of multiple DOM > Ranges. Seems totally reasonable; only problem is that pretty much all content on the web ass

RE: [uievents] Seeking status and plans

mailto:art.bars...@nokia.com] Sent: Wednesday, October 2, 2013 9:32 AM To: "Gary Kacmarcik (Кошмарчик)"; Travis Leithead Cc: public-webapps Subject: [uievents] Seeking status and plans Hi Gary, Travis, If any of the data for the UI Events spec in [PubStatus] is not accurate, please provide c

RE: [D3E] Seeking status and plan

27;ll know more in the next couple of weeks. Thanks! -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Wednesday, October 2, 2013 9:29 AM To: Travis Leithead; "Gary Kacmarcik (Кошмарчик)" Cc: public-webapps Subject: [D3E] Seeking status and plan Hi

[DOM3Events] telco minutes published

Gary, Masayuki, Kochi, et al., The minutes for our teleconference have been posted to the wiki [1] (along with previous meeting minutes). Thanks everyone for another successful call. As stated, I hope we can get the draft read for publication before TPAC! [1] http://www.w3.org/2008/webapps/wiki

RE: inputmode attribute

Even though our proposal has the combined list, we don’t have a strong opinion about whether this should all be in one attribute or in two. Primarily, our concern was to add the values are that currently not present in the spec, such as full/half width, hiragana/katakana, etc. From: Takayoshi

RE: [webidl] Add a [Maplike] tag?

Would you mind posting to public-script-coord? This sounds like a good addition to WebIDL. -Original Message- From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] Sent: Wednesday, May 29, 2013 3:24 PM To: public-webapps Subject: [webidl] Add a [Maplike] tag? I want to convert the interfac

RE: [editing] nested contenteditable

day, May 28, 2013 6:36 AM To: public-webapps@w3.org<mailto:public-webapps@w3.org>; ro...@w3.org<mailto:ro...@w3.org>; Alex Mogilevsky; Travis Leithead; a...@aryeh.name<mailto:a...@aryeh.name>; yo...@chromium.org<mailto:yo...@chromium.org> Subject: [editing] nested contentedit

RE: Overlap between StreamReader and FileReader

> From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] > On Thu, May 16, 2013 at 6:31 PM, Travis Leithead > wrote: > > Since we have Streams implemented to some degree, I'd love to hear > suggestions to improve it relative to IO. Anne can you summarize the

RE: Overlap between StreamReader and FileReader

> From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] > > On Thu, May 16, 2013 at 5:58 PM, Takeshi Yoshino > wrote: > > StreamReader proposed in the Streams API spec is almost the same as > > FileReader. By adding the maxSize argument to the readAs methods (new > > methods or just

WebApps DOM3 Events Wiki page

Hey folks, I just posted the raw minutes to the DOM 3 Events wiki page: http://www.w3.org/2008/webapps/wiki/DOM3Events http://www.w3.org/2008/webapps/wiki/Bi-weekly_meetings The page itself is a derelict from ages past, and I haven’t made much of an effort to clean it up, but it does have a new

RE: Proposal for a DOM L3 Events Telecon

arčík (Кошмарчик) Cc: Travis Leithead; public-webapps; www-dom Subject: Re: Proposal for a DOM L3 Events Telecon On Tue, 07 May 2013 23:07:28 +0200, Gary Kačmarčík (Кошмарчик) wrote: > On Tue, May 7, 2013 at 1:39 AM, Masayuki Nakano > wrote: > >> Hello, sorry for the big delay due to

RE: [WebIDL] Bugs - which are for 1.0 and which are for Second Edition?

Works for me! -Original Message- From: Cameron McCormack [mailto:c...@mcc.id.au] Sent: Sunday, May 05, 2013 12:39 AM To: Travis Leithead Cc: public-webapps Subject: Re: [WebIDL] Bugs - which are for 1.0 and which are for Second Edition? Travis Leithead wrote: > There's 50 some-

  1   2   3   >