[DOM4] Mutation algorithm imposed order on document children

I'm working on places where Webkit doesn't follow the DOM4 mutation algorithm and one of the bugs is not throwing an exception when a doctype node is inserted after an element in a document (or other permutations of the same situation). https://bugs.webkit.org/show_bug.cgi?id=88682

Re: [DOM4] Mutation algorithm imposed order on document children

Okay, I'll use that one. Both the editors draft and the referenced one are same in this respect though. On Tue, Jun 12, 2012 at 5:15 AM, Arthur Barstow art.bars...@nokia.comwrote: Elliott, All - please use the www-...@w3.org list for DOM4 discussions

Re: [DOM4] Mutation algorithm imposed order on document children

On Mon, Jun 11, 2012 at 9:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/11/12 7:39 PM, Elliott Sprehn wrote: After discussing this with some other contributors there were questions on why we're enforcing the order of the document child nodes. Because otherwise serialization

Re: Browser Payments API proposal

I'm not sure this is a problem worth solving in the platform. In 5-10 years I doubt we'll be typing our card numbers into pages. You'll tap your phone to your laptop or use some kind of payment service like paypal/wallet/etc. There's so many security/privacy issues with exposing your payment

Re: [selectors-api] Consider backporting find() behavior to querySelector()

On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: ... This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors

Re: [webcomponents] HTML Parsing and the template element

Silly question but why not specify the template element as if it's contents were PCDATA, and the document fragment is the value. Then this whole thing isn't really any different than a textarea. On Tue, Jun 26, 2012 at 8:25 AM, Rafael Weinstein rafa...@google.comwrote: I think I'm not

Re: [webcomponents] HTML Parsing and the template element

these two changes. On Tue, Jun 26, 2012 at 1:19 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn espr...@gmail.com wrote: Silly question but why not specify the template element as if it's contents were PCDATA, and the document fragment

Re: [webcomponents] HTML Parsing and the template element

On Fri, Jun 15, 2012 at 4:04 AM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Jun 14, 2012 at 11:48 PM, Ian Hickson i...@hixie.ch wrote: Does anyone object to me adding template, content, and shadow to the HTML parser spec next week? I don't object to adding them if they create normal

Re: Making template play nice with XML and tags-and-text

On Sun, Aug 5, 2012 at 7:00 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, Jul 18, 2012 at 11:35 PM, Adam Barth w...@adambarth.com wrote: On Wed, Jul 18, 2012 at 11:29 AM, Adam Klein ad...@chromium.org wrote: On Wed, Jul 18, 2012 at 9:19 AM, Adam Barth w...@adambarth.com wrote:

Re: Should MutationObservers be able to observe work done by the HTML parser?

On Mon, Sep 3, 2012 at 8:45 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 3, 2012 at 1:24 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 30, 2012 at 2:18 PM, Jonas Sicking jo...@sicking.cc wrote: ... ... But I'm also not very worried about small differences in

Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like

I'm for 1) , having a constructor with side effects is confusing and inconsistent with the platform (and other languages). On Wed, Nov 7, 2012 at 10:36 AM, Dimitri Glazkov dglaz...@google.comwrote: Folks, Throughout the year-long (whoa!) history of the Shadow DOM spec, various people

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

Traversable shadows are a requirement for a number of things like: - Generic page level libraries and polyfills that need to transform DOM nodes - Generic event handling libraries (ex. Pointer events) - Creating screenshots of the page by rendering every node to a canvas (ex. Google Feedback) -

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Thu, Nov 1, 2012 at 6:43 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: ... For example, being able to re-render the page manually via DOM inspection and custom canvas painting code. Google Feedback does this,

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Thu, Nov 8, 2012 at 8:13 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/8/12 1:45 AM, Elliott Sprehn wrote: That means that I doubt you'll get widgets being broken as Boris suggests because people aren't going to accidentally modify the inside of your widget. The problems start when

Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like

The real sugar I think is in the dictionary version of addShadowRoot: root = element.addShadowRoot({ applyAuthorSheets: false, resetStyleInheritance: true }) On Thu, Nov 8, 2012 at 9:49 AM, Dimitri Glazkov dglaz...@google.com wrote: Sure. Here's a simple example without getting into

Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like

much more difficult to address objectively. :DG On Thu, Nov 8, 2012 at 9:54 AM, Elliott Sprehn espr...@google.com wrote: The real sugar I think is in the dictionary version of addShadowRoot: root = element.addShadowRoot({ applyAuthorSheets: false, resetStyleInheritance: true

Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like

think that createShadowRoot is the right name even though create methods have a lot of bad history in the DOM APIs. On Thu, Nov 8, 2012 at 1:01 PM, Elliott Sprehn espr...@google.com wrote: True, though that's actually one character longer, probably two with normal formatting ;P new

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Wed, Nov 28, 2012 at 2:51 PM, Maciej Stachowiak m...@apple.com wrote: Does this support the previously discussed mechanism of allowing either public or private components? I'm not able to tell from the referenced sections. Can you explain the use case for wanting private shadows that are

[shadow-dom] Counters and list item counting

Currently in Webkit list item counting is done on the render tree, but we are looking at making it use the DOM instead so that ordered lists work properly in regions. This raises an interesting question about if they should use the composed shadow tree, or the original tree. ex. x-widget ol li

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

On Wed, Mar 6, 2013 at 2:05 PM, Dimitri Glazkov dglaz...@google.com wrote: ... * insertedCallback -- asynchronously called when an element is added to document tree (TBD: is this called when parser is constructing the tree?) * removedCallback -- asynchronously called when an element is

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Thu, Mar 7, 2013 at 9:55 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: ... I do not mean to sound cocky here, but I'd really like to know how many people here are used to languages that can separate internals and externals, because if you are simply not used to it, you simply

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

On Wed, Mar 6, 2013 at 5:36 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/6/13 5:05 PM, Dimitri Glazkov wrote: * attributeChangedCallback -- synchronously called when an attribute of an element is added, removed, or modified Synchronously in what sense? Why are mutation observers not

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

On Mon, Mar 11, 2013 at 2:32 PM, Daniel Buchner dan...@mozilla.com wrote: inserted and removed can probably be end of micro task, but attributeChanged definitely needs to be synchronous to model the behavior of input type where changing it from X to Y has an immediate effect on the APIs

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

On Mon, Mar 11, 2013 at 2:45 PM, Philip Walton phi...@philipwalton.comwrote: Personally, I had no objection to rel=component. It's similar in usage to rel=stylesheet in the fact that it's descriptive of what you're linking to. On the other hand, rel=include is very broad. It could just as

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

On Mon, Mar 11, 2013 at 4:39 PM, Scott Miles sjmi...@google.com wrote: My issue is that the target of this link will not in general be an atomic thing like a 'component' or a 'module'. It's a carrier for resources and links to other resources. IMO this is one of the great strengths of this

Re: [webcomponents]: Making link rel=components produce DocumentFragments

On Sat, Mar 16, 2013 at 2:29 PM, Dimitri Glazkov dglaz...@google.comwrote: On Thu, Mar 14, 2013 at 8:09 PM, Dominic Cooney domin...@google.comwrote: On Fri, Mar 15, 2013 at 9:43 AM, Dimitri Glazkov dglaz...@google.comwrote: Here's one scenario where keeping components Documents might be a

Re: [webcomponents]: Making link rel=components produce DocumentFragments

On Mon, Mar 18, 2013 at 9:19 AM, Dimitri Glazkov dglaz...@google.comwrote: On Sun, Mar 17, 2013 at 1:46 PM, Elliott Sprehn espr...@gmail.com wrote: I'd rather like it if the spec said the component document is a document that's always in standards mode and has no children

Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

On Mon, Mar 18, 2013 at 4:48 AM, Dominic Cooney domin...@chromium.orgwrote: ... I think the offset{Parent, Top, Left} properties should be adjusted. This means that in the above example, b.offsetParent would be body and b.offsetLeft would be silently adjusted to accumulate an offset of 10px

Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

On Mon, Mar 25, 2013 at 2:48 AM, Dominic Cooney domin...@chromium.orgwrote: On Sun, Mar 24, 2013 at 3:50 PM, Elliott Sprehn espr...@gmail.com wrote: On Mon, Mar 18, 2013 at 4:48 AM, Dominic Cooney domin...@chromium.orgwrote: ... I think the offset{Parent, Top, Left} properties should

Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

On Wed, Mar 27, 2013 at 2:02 PM, Boris Zbarsky bzbar...@mit.edu wrote: Scott Miles wrote: This is a thorny problem, but my initial reaction is that you threaded the needle appropriately. I don't see how we avoid some lossiness in this situation. Note that if you're using

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

I'm not sure this makes sense to use futures exclusively. As a library author you want to know when the page transitions into full screen mode even if you didn't invoke the requestFullScreen call. Futures are also not extensible. With an event we could always tack on more information in the

Re: [editing] Comments on WebKit addRange implementation

On Fri, Apr 5, 2013 at 4:48 PM, Nathan Vander Wilt nate-li...@calftrail.com wrote: The comments on https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#dom-selection-addrange say Chrome 15 dev seems to ignore addRange() if there's already a range. In case it's helpful, I wanted to

Re: [dom-futures] Making ProgressFuture use real events

On Wed, Apr 3, 2013 at 11:45 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Apr 3, 2013 at 10:43 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The ProgressFuture strawman at https://github.com/slightlyoff/DOMFuture/blob/master/ProgressFuture.idl augments a future with an analog of

Re: InedxedDB events : misconception?

On Mon, Apr 22, 2013 at 12:32 PM, Alec Flett alecfl...@chromium.org wrote: On Mon, Apr 22, 2013 at 9:56 AM, Michaël Rouges michael.rou...@gmail.comwrote: Hum ... thank you for this answer, but ... Are you sure there is no possibility that the application is completed before adding

[webcomponents]: Allowing text children of ShadowRoot is a bad time

Direct text children of ShadowRoot are full of sadness: 1) You can't call getComputedStyle on them since that's only allowed for Elements, and the old trick of parentNode doesn't work since that's a ShadowRoot. ShadowRoot doesn't expose a host property so I can't get outside to find the host

Re: [webcomponents]: Allowing text children of ShadowRoot is a bad time

for them to behave the same as well. shadowRoot.appendChild(new Text()) should probably throw an exception. On Wed, Oct 9, 2013 at 2:46 AM, Elliott Sprehn espr...@gmail.com wrote: Direct text children of ShadowRoot are full of sadness: 1) You can't call getComputedStyle on them since that's

Re: [webcomponents]: Allowing text children of ShadowRoot is a bad time

On Thu, Oct 24, 2013 at 1:29 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thursday, October 24, 2013, Dimitri Glazkov wrote: Woke up in the middle of the night and realized that throwing breaks ShadowRoot.innerHTML (or we'll have to add new rules to hoist/drop text nodes in parsing),

Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax

On Mon, Nov 11, 2013 at 1:33 AM, Ryosuke Niwa rn...@apple.com wrote: [...] we’re open to creating a proxy/fake element subclass which is not visible in the global scope and identical to HTMLKnownElement in its prototype chain in the host document as well. Can you clarify why it can't be

Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax

On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote: [...] - Script in the import is executed in the context of the window that contains the importingdocument. So window.document refers to the main page document. This has two useful corollaries: - functions

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

On Tue, Dec 3, 2013 at 2:22 PM, Bryan McQuade bmcqu...@google.com wrote: Second question: should *rendering* of page content block on the load of link rel=import Steve Souders wrote another nice post about this topic:

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

On Thu, Dec 5, 2013 at 5:37 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, Given that many important/natural use cases of custom elements involve shadow DOM, can we add a flag to auto-create shadow DOM for custom elements? In particular, can we add template as the third argument to

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

this as +Elliott Sprehn, or Leave a comment as Elliott. - E

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Tue, Dec 10, 2013 at 8:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/10/13 10:34 AM, Anne van Kesteren wrote: E.g. the dialog's close() method won't work as defined right now on a subclass of

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

On Fri, Dec 13, 2013 at 1:16 AM, Maciej Stachowiak m...@apple.com wrote: On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote: ... If the shadow root is optionally automatically generated, it should probably be passed to the createdCallback (or constructor) rather than made

Re: [webcomponents]: Allowing text children of ShadowRoot is a bad time

On Tue, Oct 29, 2013 at 4:20 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Oct 29, 2013 at 7:34 AM, Simon Pieters sim...@opera.com wrote: On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kesteren ann...@annevk.nl wrote: We are considering not throwing in XML. Only on getting

Re: [webcomponents]: Allowing text children of ShadowRoot is a bad time

On Tue, Jan 7, 2014 at 2:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Jan 7, 2014 at 2:42 PM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Oct 29, 2013 at 4:20 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Oct 29, 2013 at 7:34 AM, Simon Pieters sim...@opera.com

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

On Fri, Feb 14, 2014 at 5:17 PM, Alex Russell slightly...@google.comwrote: On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa rn...@apple.com wrote: [...] We all agree it's not a security boundary and you can go through great lengths to get into the ShadowRoot if you really wanted, all we've

Re: do not deprecate synchronous XMLHttpRequest

On Tuesday, February 10, 2015, Marc Fawzi marc.fa...@gmail.com wrote: Here is a really bad idea: Launch an async xhr and monitor its readyState in a while loop and don't exit the loop till it has finished. Easier than writing charged emails. Less drain on the soul This won't work, state

Re: do not deprecate synchronous XMLHttpRequest

to synchronously observe an XHR. On Tue, Feb 10, 2015 at 9:44 AM, Elliott Sprehn espr...@chromium.org javascript:_e(%7B%7D,'cvml','espr...@chromium.org'); wrote: On Tuesday, February 10, 2015, Marc Fawzi marc.fa...@gmail.com javascript:_e(%7B%7D,'cvml','marc.fa...@gmail.com'); wrote

Re: Custom element design with ES6 classes and Element constructors

On Thursday, January 15, 2015, Domenic Denicola d...@domenic.me wrote: Just to clarify, this argument for symbols is not dependent on modules. Restated, the comparison is between: ```js class MyButton extends HTMLElement { createdCallback() {} } ``` vs. ```js class MyButton extends

Re: Custom element design with ES6 classes and Element constructors

On Tuesday, January 27, 2015, Domenic Denicola d...@domenic.me wrote: It does. If a framework says “use clonedCallback and we will implementing cloning for you,” we cannot add a clonedCallback with our own semantics. Whereas, if a framework says “use [Framework.cloned] and we will implement

Re: Minimum viable custom elements

On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell bkard...@gmail.com wrote: On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson bru...@opera.com wrote: On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com wrote: I think being able to extend existing elements has potential value to

Re: Standardising canvas-driven background images

On Fri, Feb 20, 2015 at 11:08 AM, Matthew Robb matthewwr...@gmail.com wrote: I can atest that this feature helped me to dramatically reduce the drag on http://arena.net. The section header backgrounds are using canvas elements to avoid touching the DOM during scroll events. Can you give an

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

On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead travis.leith...@microsoft.com wrote: 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(),

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

On Thu, Mar 26, 2015 at 1:38 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 26, 2015, at 1:23 PM, Travis Leithead travis.leith...@microsoft.com wrote: You make a series of excellent points. In the sense that you have a new set of nodes to manage holistically, then having some sort of

Re: Exposing structured clone as an API?

The way many browsers implement this isn't going to be particularly fast. It serializes the objects to a byte sequence so it can be transferred to another thread or process and then inflates the objects on the other side. Have you benchmarked this? I think you're better off just writing your own

Re: JSON imports?

in the http header? Otherwise when it's fetched, the file is going to be downloaded again? What if you don't have control over the json file's http header? On Apr 18, 2015, at 10:12 AM, Elliott Sprehn espr...@chromium.org wrote: link rel=prefetch does that for you. On Apr 17, 2015 7:08 PM

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

A distribute callback means running script any time we update distribution, which is inside the style update phase (or event path computation phase, ...) which is not a location we can run script. We could run script in another scripting context like is being considered for custom layout and paint

Re: Exposing structured clone as an API?

On Apr 24, 2015 3:16 PM, Joshua Bell jsb...@google.com wrote: It seems like the OP's intent is just to deep-copy an object. Something like the OP's tweet... or this, which we use in some tests: function structuredClone(o) { return new Promise(function(resolve) { var mc = new

Re: Why is querySelector much slower?

Live node lists make all dom mutation slower, so while it might look faster in your benchmark it's actually slower elsewhere (ex. appendChild). Do you have a real application where you see querySelector as the bottleneck? On Apr 27, 2015 5:32 PM, Glen Huang curvedm...@gmail.com wrote: I wonder

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

On Thu, Apr 30, 2015 at 8:57 PM, Ryosuke Niwa rn...@apple.com wrote: ... The return value of (2) is the same in either case. There is no observable difference. No interop issue. Please file a bug for the spec with a concrete example if you can find a observable difference due to the

Re: :host pseudo-class

On Thu, Apr 30, 2015 at 10:25 PM, Anne van Kesteren ann...@annevk.nl wrote: ... My problem is not with the ability to address the host element, but by addressing it through a pseudo-class, which has so far only been used for matching elements in the tree that have a particular internal

Re: Why is querySelector much slower?

On Mon, Apr 27, 2015 at 11:13 PM, Glen Huang curvedm...@gmail.com wrote: On second thought, if the list returned by getElementsByClass() is lazy populated as Boris says, it shouldn't be a problem. The list is only updated when you access that list again. The invalidation is what makes your

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

On Thu, Apr 30, 2015 at 6:22 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Apr 30, 2015 at 3:05 PM, Hayato Ito hay...@chromium.org wrote: That's the exactly intended behavior in the current spec. The timing of distribution is not observable. Right, but you can synchronously observe

Re: Custom Elements: insert/remove callbacks

On Thu, May 7, 2015 at 10:44 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn espr...@chromium.org wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node insertionPoint) Node#removedFrom(Node

Re: Custom Elements: insert/remove callbacks

On Thu, May 7, 2015 at 10:24 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 7, 2015 at 10:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: In Gecko, yes. The set of hooks Gecko builtin elements have today is, effectively: 1) This element used to not have a parent and now does.

Re: Shadow DOM: state of the distribution API

The 3 proposal is what the houdini effort is already researching for custom style/layout/paint. I don't think it's acceptable to make all usage of Shadow DOM break when used with libraries that read layout information today, ie. offsetTop must work. I also don't think it's acceptable to introduce

Re: Custom Elements: is=

Removing this breaks several use cases of which there's no alternative currently: https://chromium.googlesource.com/infra/infra/+/master/appengine/chromium_rietveld/new_static/common/cr-action.html

Re: Custom Elements: is=

On Fri, May 8, 2015 at 12:56 PM, Travis Leithead travis.leith...@microsoft.com wrote: 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

Re: Custom Elements: insert/remove callbacks

On May 9, 2015 9:41 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/8/15 1:42 AM, Elliott Sprehn wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node

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

On Wed, May 6, 2015 at 11:08 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 7, 2015 at 6:02 AM, Hayato Ito hay...@chromium.org wrote: I'm saying: - Composed tree is related with CSS. - Node distribution should be considered as a part of style concept. Right, I think Ryosuke

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

I'd like this API to stay simple for v1 and support only named slots and not tag names. I believe we can explain what details does with the imperative API in v2. On Mon, May 18, 2015 at 5:11 PM, Justin Fagnani justinfagn...@google.com wrote: On Mon, May 18, 2015 at 4:58 PM, Philip Walton

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

On Mon, May 18, 2015 at 6:34 PM, Domenic Denicola d...@domenic.me wrote: From: Justin Fagnani [mailto:justinfagn...@google.com] They're not equivalent, because any element can have the right content-slot value, but with tag names, only one (or maybe N) names would be supported. Hmm, I

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

On Mon, May 18, 2015 at 6:24 PM, Justin Fagnani justinfagn...@google.com wrote: On Mon, May 18, 2015 at 6:13 PM, Domenic Denicola d...@domenic.me wrote: In case it wasn't clear, named slots vs. tag names is purely a bikeshed color (but an important one, in the syntax is UI sense). None of

Re: [Imports] Considering imperative HTML imports?

On Wed, Apr 15, 2015 at 9:37 PM, Travis Leithead travis.leith...@microsoft.com wrote: Was an imperative form of HTML imports already considered? E.g., the following springs to mind: PromiseDocument importDocument(DOMString url); I was thinking about Worker’s importScripts(DOMString…

Re: Privileged context features and JavaScript

It's preferable not to do that for us because you can then create a static heap snapshot at compile time and memcpy to start JS contexts faster. On Apr 17, 2015 12:03 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/17/15 2:52 AM, Boris Zbarsky wrote: If that preference is toggled, we in fact

Re: JSON imports?

link rel=prefetch does that for you. On Apr 17, 2015 7:08 PM, Glen Huang curvedm...@gmail.com wrote: One benefit is that browsers can start downloading it asap, instead of waiting util the fetch code is executed (which could itself be in a separate file). On Apr 18, 2015, at 8:41 AM, Elliott

Re: JSON imports?

On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang curvedm...@gmail.com wrote: Basic feature like this shouldn't rely on a custom solution. However, it does mean that if browsers implement this, it's easily polyfillable. What does this get you over fetch() ? Imports run scripts and enforce ordering

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

On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola d...@domenic.me wrote: From: Elliott Sprehn [mailto:espr...@chromium.org] Given the widget ui-collapsible that expects a ui-collapsible-header in the content model, with slots I can write: ui-collapsible my-header-v1 slot=ui

Re: Clipboard API: remove dangerous formats from mandatory data types

On Thu, Jun 11, 2015 at 10:51 AM, Wez w...@google.com wrote: Hallvord, The proposal isn't to remove support for copying/pasting images, but to restrict web content from placing compressed image data in one of these formats on the clipboard directly - there's no issue with content pasting

Re: Writing spec algorithms in ES6?

I've seen this in some specs, and I found the JS code quite difficult to understand. There's so much subtle behavior you can do, and it's easy to be too fancy. In the example in the color spec, why does undefined become 0 but not null? Also the properties are actually doubles so there's missing

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

On Wed, Jul 1, 2015 at 12:08 AM, Hayato Ito hay...@chromium.org wrote: ::before and ::after are basically *siblings* of the shadow host, That's not a correct sentence. ::before and ::after shouldn't be a siblings of the shadow host. I just wanted to say that #2 is the desired behavior.

Re: Shadow DOM and SVG use elements

On Fri, Oct 23, 2015 at 12:42 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > 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

Custom elements backing swap proposal

I've been thinking about ways to make custom elements violate the consistency principle less often and had a pretty awesome idea recently. Unfortunately I won't be at TPAC, but I'd like to discuss this idea in person. Can we setup a custom element discussion later in the year? The current

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

On Fri, Nov 6, 2015 at 5:12 PM, Domenic Denicola wrote: > In general I would be cautious about this kind of API. Events are not > expected to have side effects, and adding listeners should not cause an > (observable) action. See e.g. >

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

How does this work with shadow dom? Range is not very friendly to that. On Oct 6, 2015 4:35 PM, "Frederick Hirsch" wrote: > This is a call for consensus (CfC) to publish a First Public Working Draft > (FPWD) of FindText API; deadline 14 October (1 week) > > This FindText API

Re: Meeting date, january

Great, lets do the 25th then. :) On Wed, Dec 2, 2015 at 1:09 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > 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

Re: Meeting date, january

CSSWG and Houdini are in Sydney starting on the 30th, which means I couldn't go to both which is unfortunate. I'd prefer the 25th. :) On Wed, Nov 25, 2015 at 5:54 PM, Chaals McCathie Nevile < cha...@yandex-team.ru> wrote: > Hi, > > it appears that there are some people may not be able to attend

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

Can you give a code example of how this happens? On Feb 24, 2016 8:30 PM, "Ryosuke Niwa" wrote: > > > On Feb 23, 2016, at 1:16 AM, Anne van Kesteren wrote: > > > > On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa wrote: > >> Hi, > >> > >> We

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn <espr...@chromium.org> > wrote: > > > > > > > > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa <rn...@apple.com> wrote: &

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn <espr...@chromium.org> > wrote: > > > > Can you give a code example of how this happens? > > For example, execCommand('Delete') wou

RE: [XHR]

Can we get an idl definition too? You shouldn't need to read the algorithm to know the return types. On Mar 17, 2016 12:09 PM, "Domenic Denicola" wrote: > From: Gomer Thomas [mailto:go...@gomert-consulting.com] > > > I looked at the Streams specification, and it seems pretty