Re: Streams and Blobs
On Sat, Mar 9, 2013 at 8:03 AM, Glenn Maynard gl...@zewt.org wrote: On Fri, Mar 8, 2013 at 10:40 PM, Jonas Sicking jo...@sicking.cc wrote: - You could set up an async XHR in one worker, then read it synchronously with XHR in another worker. This means the first worker could block the second worker at will, eg. by running a blocking operation during an onprogress event, to prevent returning to the event loop. I'm sure we don't want to allow that (at least without careful thought, eg. the synchronous messaging idea). This is a good point. We probably shouldn't allow sync XHR in workers either to accept or produce Stream objects. Now you can't stream synchronously, and now XHR suddenly cares about whether an object URL comes from a Stream instead of being protocol-agnostic (meaning black-box APIs that take a URL won't working with them either). This is adding weird restrictions to work around problems with the design. Indeed, returning a Stream from a sync XHR in workers would be fine. And in that case you should do that as soon as the headers data has been successfully parsed. With the supply-the-stream-and-it's-done model, XHR follows the same model it normally does: you start a request, XHR does some work, and onload is fired once the result is ready for you to use. This is not correct. All of .response, .responseText and .responseXML are often available much before that. Nope. The only time any of these is available (per spec) before the DONE state is in responseType = text, making that the exception. All the rest are only available in DONE. The most common pattern with XHR is to call send(), then wait for onload (or one of the other redundant events fired at that time), which this approach follows. I was wrong about .responseXML. But I'm correct about .response and .responseText. With the runs-for-the-duration-of-the-stream model, when is the .response available? Ideally as soon as .send() is called. If that causes problem then maybe as soon as we enter readystate 3. You need to know the MIME type to create a Stream, so you can't create it until you've received headers. That seems to depend on how we define Stream. But if we define it as having a known mimetype then indeed readystate 3 is what we'll have to wait for. / Jonas
Re: [shadow-dom] Counters and list item counting
A kind reminder this question still requires an answer. I'd like to know if it's OK to implement lists to act as shown in the first rendering of the example (i.e counting doesn't cross upper-boundary encapsulation). Thanks, Andrei. On Mar 7, 2013, at 11:43 AM, Andrei Bucur abu...@adobe.com wrote: Hello, I want to clarify a certain situation: ol liA/li li id=host ShadowRoot liX/li liY/li ShadowRoot /li liC/li /ol How is this case supposed to be rendered? 1. A 2. 1. X 2. Y 3. C or 1. A 2,3. X 4. Y 5. C Basically, do we want the shadow root to become the counting root for the lis inside the shadow or we let them go through the upper boundary and use the ol instead? I would vote for the first rendering as it seems to better respect the shadow encapsulation. If so, it also means we need to prevent the propagation of the type, reversed etc. attributes of the parent ol to the shadow lis, right? Thanks, Andrei. On Feb 19, 2013, at 9:20 PM, Elliott Sprehn espr...@gmail.com wrote: 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 li /ol /x-widget inside x-widget: div content select=li:last-child /div What's the count on that projected list item? This also raises questions of how counters interact with shadows. Should counters work on the project DOM or the original DOM? We're leaning towards the original DOM since otherwise counters become difficult to work with when they're reprojected deeper and deeper down a component hierarchy. - E
Re: Streams and Blobs
On Mon, Mar 11, 2013 at 3:03 AM, Jonas Sicking jo...@sicking.cc wrote: Indeed, returning a Stream from a sync XHR in workers would be fine. And in that case you should do that as soon as the headers data has been successfully parsed. You seem to be saying that synchronous XHR would return at LOADING, then keep working in the background to feed the Stream. This would be very inconsistent. Synchronous XHR returns to the caller when it enters the DONE state, and once it does, its work is finished. Also, returning to the original point: threads could block each other, threads could deadlock each other, and a thread could deadlock with itself. With the supply-the-stream-and-it's-done model, XHR follows the same model it normally does: you start a request, XHR does some work, and onload is fired once the result is ready for you to use. I was wrong about .responseXML. But I'm correct about .response and .responseText. That's just one of five modes (text vs. arraybuffer, blob, document, json). So, I think it's reasonable to say that providing the result at onload isn't inconsistent with XHR's model; only text mode is inconsistent, if anything. (I don't really think text mode is deeply inconsistent, either, but that's a bit of a tangent...) That seems to depend on how we define Stream. But if we define it as having a known mimetype then indeed readystate 3 is what we'll have to wait for. The current spec does define it that way, at least, which makes sense for parity with Blob. (By the way, let's refer to states by name, so I don't have to check the spec each time to remember what 3 means, and so we don't encourage people to use those magic constants in their code.) -- Glenn Maynard
[Bug 16834] FileList in input.files (multiple attribute)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16834 Robin Berjon ro...@w3.org changed: What|Removed |Added CC||public-webapps@w3.org Component|HTML5 spec |File API Assignee|ro...@w3.org|a...@mozilla.com Product|HTML WG |WebAppsWG QA Contact|public-html-bugzi...@w3.org |public-webapps-bugzilla@w3. ||org --- Comment #3 from Robin Berjon ro...@w3.org --- This is not something for the HTML specification to change, FileList is defined by the File API specification (http://dev.w3.org/2006/webapi/FileAPI/#dfn-filelist). But don't worry — I'm moving your bug there so that it can be processed by the right people, this is a good bug. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Moving Clipboard API spec forward
Siterer Hallvord Reiar Michaelsen Steen hallv...@opera.com: It would be nice to understand what needs to be done to get the spec to Last Call. I've checked in some changes. I guess we're getting there.. Plan: * Find a way to test the clipboard-content-that-embeds-other-clipboard-content scenario (do any other types of software even place such content on the clipboard?) and make sure the spec is sane. In practise, this is mainly about HTML content that embeds IMG not linking to a file:// or web URL. Not done yet. Does anyone on this list know details of software that places complex payloads on the clipboard? For example, if you in a text editor makes a selection that includes an image, then copy - how is the image described in the HTML part put on the clipboard? Does it matter if image is loaded from a URL / from file / pasted? * Clarify the intention that document.execCommand() can be used to trigger real paste / copy actions (with due limitations for security and privacy reasons) - I think the spec fails to state this clearly enough Clarified, hope it's clear. * Remove the cross-origin HTML paste sanitization algorithm and all references to it (lacks implementation) Killed. * Calling setData() without calling preventDefault() has no effect, even if there is no selection - the default action is to do nothing - this is a rather silly gotcha.. It would be more user/dev-friendly if setData() or other manipulation automatically prevented the default action of copy.. As this is already implemented I don't think we can change it although I'd like to. * Consider if more MIME types need to be mandatory, resolve the other issues noted in the spec. Issues resolved or postphoned. -Hallvord
Re: [webcomponents]: First stab at the Web Components spec
On Fri, Mar 8, 2013 at 6:53 PM, Dimitri Glazkov dglaz...@google.com wrote: That's not the problem, that's a feature :) Think of it as a template tag for documents. I'd think that author expectations would be different given how external CSS resources work, but maybe. As for the API, do we really want that to be a synchronous API? That seems future-hostile for two reasons: we want to do more in parallel (Servo) and we definitely do not want cross-origin to be synchronous in this manner I think. Maybe it's better if we provide message port access between the Document objects? And if this is mostly for applying components to documents, maybe we should not expose API for that so that it the declarative way can be optimized. -- http://annevankesteren.nl/
Re: security model of Web Components, etc. - joint work with WebAppSec?
On Sat, Mar 9, 2013 at 4:36 AM, Arthur Barstow art.bars...@nokia.comwrote: [ Apology for top-posting and continuing the cross-posting ] Hi Brad, Thanks, yes earlier security review and feedback would be good. My preference is to use public-webapps (solely) for all discussions related to Web Components (WC). Re discussing security and WC f2f, I added a joint meeting between these two groups as a potential agenda topic for WebApps' April 25-26 f2f meeting [1] but I did not allocate a specific day+time slot because it could be a bit premature right now. That said, if you, or Dimitri, or other WC people have a specific day+time you would prefer, please speak up and note we intend to meet all day on the 25th but only until noon on the 26th. (Of course we can cancel the joint meeting if it turns out there is no need to meet.) I am happy to help facilitate this. Please let me know how I can help. :DG
Re: [webcomponents]: What callbacks do custom elements need?
Ready/created, inserted, removed, and attributeChanged are the minimum must-havs for developers - we heavily rely on each one of these callbacks in the components we've developed thus far. The usefulness of this API is neutered without these hooks - they're table stakes, plain and simple. Jonas, how are non-bubbling callbacks so crushing? Are we honestly designing for the dev who decides to ignore all the best practices, tutorials, evangelist demos, etc and run a crushing loop every time an attribute value changes despite the obvious idiocy of their actions? This is not an API that will be widely used by every Bobby Tables and Samantha Script Kitty on the block - let's not design API features and 99%-case ergonomics for a phantom developer persona that is a fringe-at-best factor. On Fri, Mar 8, 2013 at 10:49 AM, Jonas Sicking jo...@sicking.cc wrote: On Mar 6, 2013 2:07 PM, Dimitri Glazkov dglaz...@google.com wrote: Here are all the callbacks that we could think of: * readyCallback (artist formerly known as create) -- called when the element is instantiated with generated constructor, createElement/NS or shortly after it was instantiated and placed in a tree during parser tree construction * attributeChangedCallback -- synchronously called when an attribute of an element is added, removed, or modified This will have many of the same problems that mutation events had. I believe we want to really stay away from synchronous. So yes, this looks dangerous and crazy :-) / Jonas
Re: [webcomponents]: What callbacks do custom elements need?
Just to be clear, these are callbacks (right?), meaning synchronous executions on one specific node. That is a far cry from the old issues with mutation events and nightmarish bubbling scenarios. Come on folks, let's be pragmatic and honest, there are far worse events in use today, and the web is still alive and kicking: mousemove, mouseover, mouseout, resize, etc. Most/all of these kinds of existing, perf-intensive events bubble and are fired with far more frequency than attribute changes on a node - further, devs can always debounce the calls if they please. Devs probably don't care if these things are fired sync, as long as when they do fire, they fire once and the value/changes aren't stale. Honestly, ready/created, inserted, and removed wouldn't be an issue if they map to micro tasks, right? (as long as the final callback is not stale). If attribute change callbacks are your worry, Brian Kardell mentioned something sensible, give people a way to whitelist just the ones that they want to watch for - assuming that is faster than simply telling devs to use basic if/switch logic inside the callback. There are many options here, let's not have an API-degrading, whopper freakout over a nascent concern of a fringe perf issue that is, to a large extent, self-mitigating/healing. (devs generally don't want to have slow crappy apps - built-in incentives to not suck are usually the best kind) Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Mon, Mar 11, 2013 at 11:55 AM, Daniel Buchner dan...@mozilla.com wrote: Ready/created, inserted, removed, and attributeChanged are the minimum must-havs for developers - we heavily rely on each one of these callbacks in the components we've developed thus far. The usefulness of this API is neutered without these hooks - they're table stakes, plain and simple. Jonas, how are non-bubbling callbacks so crushing? Are we honestly designing for the dev who decides to ignore all the best practices, tutorials, evangelist demos, etc and run a crushing loop every time an attribute value changes despite the obvious idiocy of their actions? This is not an API that will be widely used by every Bobby Tables and Samantha Script Kitty on the block - let's not design API features and 99%-case ergonomics for a phantom developer persona that is a fringe-at-best factor. On Fri, Mar 8, 2013 at 10:49 AM, Jonas Sicking jo...@sicking.cc wrote: On Mar 6, 2013 2:07 PM, Dimitri Glazkov dglaz...@google.com wrote: Here are all the callbacks that we could think of: * readyCallback (artist formerly known as create) -- called when the element is instantiated with generated constructor, createElement/NS or shortly after it was instantiated and placed in a tree during parser tree construction * attributeChangedCallback -- synchronously called when an attribute of an element is added, removed, or modified This will have many of the same problems that mutation events had. I believe we want to really stay away from synchronous. So yes, this looks dangerous and crazy :-) / Jonas
Re: [shadow-dom] Counters and list item counting
On Thu, Mar 7, 2013 at 1:43 AM, Andrei Bucur abu...@adobe.com wrote: Hello, I want to clarify a certain situation: ol liA/li li id=host ShadowRoot liX/li liY/li ShadowRoot /li liC/li /ol How is this case supposed to be rendered? 1. A 2. 1. X 2. Y 3. C or 1. A 2,3. X 4. Y 5. C Basically, do we want the shadow root to become the counting root for the lis inside the shadow or we let them go through the upper boundary and use the ol instead? I would vote for the first rendering as it seems to better respect the shadow encapsulation. If so, it also means we need to prevent the propagation of the type, reversed etc. attributes of the parent ol to the shadow lis, right? Hm, either rendering is consistent with what we've already answered. I think I'm with you, saying that the shadow root is also a root for counter scopes. I'd like Elliot to comment before I commit to anything, though, as he knows more about WebKit's counter implementation. ~TJ
Re: [webcomponents]: First stab at the Web Components spec
On Mon, Mar 11, 2013 at 10:14 AM, Anne van Kesteren ann...@annevk.nlwrote: On Fri, Mar 8, 2013 at 6:53 PM, Dimitri Glazkov dglaz...@google.com wrote: That's not the problem, that's a feature :) Think of it as a template tag for documents. I'd think that author expectations would be different given how external CSS resources work, but maybe. As for the API, do we really want that to be a synchronous API? That seems future-hostile for two reasons: we want to do more in parallel (Servo) and we definitely do not want cross-origin to be synchronous in this manner I think. Maybe it's better if we provide message port access between the Document objects? And if this is mostly for applying components to documents, maybe we should not expose API for that so that it the declarative way can be optimized. The resources will only block script (just like CSS: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21218), so there's definitely opportunity for parallelism. I am not sure how the message port thing will work. a) It sounds icky from developer ergonomics perspective and b) making sub-resources not block on script sort of ruins my plan for integrating element registration. If there's no blocking script, I have no assurances that the elements in subresources are registered before script starts running, which means that we'll have to do something like element upgrade, which I worked pretty hard to remove :) :DG
Re: [webcomponents]: What callbacks do custom elements need?
On 3/11/13 3:44 PM, Daniel Buchner wrote: Just to be clear, these are callbacks (right?), meaning synchronous executions on one specific node. That is a far cry from the old issues with mutation events and nightmarish bubbling scenarios. Where does bubbling come in? The issue with _synchronous_ (truly synchronous, as opposed to end of microtask or whatnot) callbacks is that they are required to fire in the middle of DOM mutation while the DOM is in an inconsistent state of some sort. This has nothing to do with bubbling and everything to do with what happens when you append a node somewhere while it already has a parent and it has a removed callback that totally rearranges the DOM in the middle of your append. Come on folks, let's be pragmatic and honest, there are far worse events in use today, and the web is still alive and kicking: mousemove, mouseover, mouseout, resize, etc. Most/all of these kinds of existing, perf-intensive events bubble and are fired with far more frequency than attribute changes on a node - further, devs can always debounce the calls if they please. resize firing frequency is throttled in browsers. mousemove/over/out firing frequency is throttled in browsers. For example, last I checked Chrome will only fire mousemove at about 60Hz. But the issues with synchronous callbacks are not about performance, last I checked, so I'm not sure why you're setting up this strawman. Or are people arguing something here based on performance considerations that I missed? Devs probably don't care if these things are fired sync, Good, because they aren't. as long as when they do fire, they fire once and the value/changes aren't stale. Not sure what you mean here. Honestly, ready/created, inserted, and removed wouldn't be an issue if they map to micro tasks, right? Running script at end of microtask is generally fine by me, since it doesn't have the issues that running script sync does. If attribute change callbacks are your worry, Brian Kardell mentioned something sensible, give people a way to whitelist just the ones that they want to watch for - assuming that is faster than simply telling devs to use basic if/switch logic inside the callback. It's almost certainly faster but may not be worth the machinery, depending on how much this is actually going to be used in practice. There are many options here, let's not have an API-degrading, whopper freakout over a nascent concern of a fringe perf issue that is, to a large extent, self-mitigating/healing. (devs generally don't want to have slow crappy apps - built-in incentives to not suck are usually the best kind) You and I seem to have different opinions on whether people care about their code being a resource hog... Note that the typical culprits for not caring are not apps, though. -Boris
Re: [webcomponents]: What callbacks do custom elements need?
On Mon, Mar 11, 2013 at 1:16 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/11/13 3:44 PM, Daniel Buchner wrote: Just to be clear, these are callbacks (right?), meaning synchronous executions on one specific node. That is a far cry from the old issues with mutation events and nightmarish bubbling scenarios. Where does bubbling come in? The issue with _synchronous_ (truly synchronous, as opposed to end of microtask or whatnot) callbacks is that they are required to fire in the middle of DOM mutation while the DOM is in an inconsistent state of some sort. This has nothing to do with bubbling and everything to do with what happens when you append a node somewhere while it already has a parent and it has a removed callback that totally rearranges the DOM in the middle of your append. So does it actually need to be sync at that leve? I'm not sure why it does really. Can someone explain just for my own clarity? -Brian
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 sufficient here? * insertedCallback -- asynchronously called when an element is added to document tree (TBD: is this called when parser is constructing the tree?) Again, why is this not doable with mutation observers? 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 available (like stepUp). MutationObservers are not sufficient because childList mutations are about children, but you want to observe when *yourself* is added or removed from the Document tree. There's also no inserted into document and removed from document mutation records, and since ShadowRoot has no host property there's also no way to walk up to the root to find out if you're actually in the document. (Dimtiri should fix this... I hope). The ready callback should probably also be synchronous (but at least it happens in script invocation of the new operator, or after tree building), since you want your widget to be usable immediately. - E
Re: [webcomponents]: What callbacks do custom elements need?
Just to be clear, these are callbacks (right?), meaning synchronous executions on one specific node. That is a far cry from the old issues with mutation events and nightmarish bubbling scenarios. Where does bubbling come in? - I thought the concern was over the same issues that plagued mutation *events*, namely perf-crushing event bubbling sparked by frequent DOM changes. But the issues with synchronous callbacks are not about performance, last I checked, so I'm not sure why you're setting up this strawman. Or are people arguing something here based on performance considerations that I missed? - I wasn't aware of setting up such a strawman, I honestly thought the issue was perf. I thought this because Jonas said this: This will have many of the same problems that mutation events had. I believe we want to really stay away from synchronous. So yes, this looks dangerous and crazy - as long as when they do fire, they fire once and the value/changes aren't stale. Not sure what you mean here. - I mean, that it doesn't matter if you make all the callbacks fire at the end of a micro task, as long as you're not reporting old, irrelevant changes to the developer - for instance: if an attribute foo changes 3 times before the micro task is finished, the browser should resolve the mutation record set to only fire one callback for the last fresh occurrence of the mutation/action in question. Honestly, ready/created, inserted, and removed wouldn't be an issue if they map to micro tasks, right? Running script at end of microtask is generally fine by me, since it doesn't have the issues that running script sync does. - Great, so what's the problem here? Are we officially in violent agreement? :) - If attribute change callbacks are your worry, Brian Kardell mentioned something sensible, give people a way to whitelist just the ones that they want to watch for - assuming that is faster than simply telling devs to use basic if/switch logic inside the callback. It's almost certainly faster but may not be worth the machinery, depending on how much this is actually going to be used in practice. - these four basic callbacks/mutations are essential to custom element/component development - they will be used frequently, in our experience thus far. - There are many options here, let's not have an API-degrading, whopper freakout over a nascent concern of a fringe perf issue that is, to a large extent, self-mitigating/healing. (devs generally don't want to have slow crappy apps - built-in incentives to not suck are usually the best kind) You and I seem to have different opinions on whether people care about their code being a resource hog... Note that the typical culprits for not caring are not apps, though. - The target and actual audience is probably not going to be noobs/beginners, this is a pretty complex API - it appears you agree: the typical culprits for not caring are not apps. - Daniel
Re: [webcomponents]: First stab at the Web Components spec
On Fri, Mar 8, 2013 at 1:47 PM, Robert Ginda rgi...@chromium.org wrote: rel=include ? And Inclusions as the name? Or HTML Inclusions? This could work. Any objections or better names? Rob might just win this one. :DG
Re: [webcomponents]: What callbacks do custom elements need?
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 available (like stepUp). Actually, I disagree. Attribute changes need not be assessed syncronously, as long as they are evaluated before critical points, such as before paint (think requestAnimationFrame timing). Can you provide a common, real-world example of where queued timing would not work? Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Mon, Mar 11, 2013 at 2:18 PM, Elliott Sprehn espr...@gmail.com wrote: 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 sufficient here? * insertedCallback -- asynchronously called when an element is added to document tree (TBD: is this called when parser is constructing the tree?) Again, why is this not doable with mutation observers? 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 available (like stepUp). MutationObservers are not sufficient because childList mutations are about children, but you want to observe when *yourself* is added or removed from the Document tree. There's also no inserted into document and removed from document mutation records, and since ShadowRoot has no host property there's also no way to walk up to the root to find out if you're actually in the document. (Dimtiri should fix this... I hope). The ready callback should probably also be synchronous (but at least it happens in script invocation of the new operator, or after tree building), since you want your widget to be usable immediately. - E
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 available (like stepUp). Actually, I disagree. Attribute changes need not be assessed syncronously, as long as they are evaluated before critical points, such as before paint (think requestAnimationFrame timing). Can you provide a common, real-world example of where queued timing would not work? Yes, I already gave one. Where you go from input type=text to input type=range and then stepUp() suddenly starts working. I guess we could force people to use properties here, but that doesn't model how the platform itself works. An even more common example is iframe src. Setting a different @src value synchronously navigates the frame. Also inserting an iframe into the page synchronously loads an about:blank document. Neither of theses cases are explained by the end-of-microtask behavior you're describing. - E
Re: [webcomponents]: First stab at the Web Components spec
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 easily apply to a stylesheet as a Web component, and may limit the usefulness of the term if/when future rel values are introduced. (p.s. I'm new to this list and haven't read through all the previous discussions on Web components. Feel free to disregard this comment if I'm rehashing old topics) On Mon, Mar 11, 2013 at 2:28 PM, Dimitri Glazkov dglaz...@google.comwrote: On Fri, Mar 8, 2013 at 1:47 PM, Robert Ginda rgi...@chromium.org wrote: rel=include ? And Inclusions as the name? Or HTML Inclusions? This could work. Any objections or better names? Rob might just win this one. :DG
Re: [webcomponents]: What callbacks do custom elements need?
I am certainly aware of existing elements that have synchronous actions triggered as a result of attribute changes. Are you specifically worried about cases where you inherit from an existing element using the is= syntax and require immediate notification of an attribute change because you want to modify or prevent the way the native element behaves in response to native attribute changes? In retrospect, that is a valid point. Is this an instance of an important use-case/requirement colliding with a hard constraint? Can someone with more expertise on the platform side explain the options we have in addressing the case Elliot presents? Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Mon, Mar 11, 2013 at 2:42 PM, Elliott Sprehn espr...@gmail.com wrote: On Mon, Mar 11, 2013 at 2:32 PM, Daniel Buchner dan...@mozilla.comwrote: 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 available (like stepUp). Actually, I disagree. Attribute changes need not be assessed syncronously, as long as they are evaluated before critical points, such as before paint (think requestAnimationFrame timing). Can you provide a common, real-world example of where queued timing would not work? Yes, I already gave one. Where you go from input type=text to input type=range and then stepUp() suddenly starts working. I guess we could force people to use properties here, but that doesn't model how the platform itself works. An even more common example is iframe src. Setting a different @src value synchronously navigates the frame. Also inserting an iframe into the page synchronously loads an about:blank document. Neither of theses cases are explained by the end-of-microtask behavior you're describing. - E
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 easily apply to a stylesheet as a Web component, and may limit the usefulness of the term if/when future rel values are introduced. (p.s. I'm new to this list and haven't read through all the previous discussions on Web components. Feel free to disregard this comment if I'm rehashing old topics) +1, I like rel=component, document or include doesn't make sense. - E
[webcomponents]: Making link rel=components produce DocumentFragments
Hi folks! Just had a quick discussion with Elliott and he suggested that instead of building full-blown Documents, the link rel=components just make DocumentFragments, just like template does. Looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-document-object and the bunch of APIs that will never be useful on a document without a browsing context, I think it's a pretty good idea. It should make also components more lightweight. The only problem is that now I have to figure out how to specify this without just flat-out stealing, err... I mean reusing, large swaths of HTML5 spec. But I'll take this one for the team. :DG
Re: [webcomponents]: First stab at the Web Components spec
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 proposal. For this reason, when it was rel=components (plural) there was no problem for me. Having said all that, I'm not particularly up in arms about this issue. The name will bend to the object in the fullness of time. :) S On Mon, Mar 11, 2013 at 3:35 PM, Elliott Sprehn espr...@gmail.com wrote: 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 easily apply to a stylesheet as a Web component, and may limit the usefulness of the term if/when future rel values are introduced. (p.s. I'm new to this list and haven't read through all the previous discussions on Web components. Feel free to disregard this comment if I'm rehashing old topics) +1, I like rel=component, document or include doesn't make sense. - E
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 proposal. For this reason, when it was rel=components (plural) there was no problem for me. Having said all that, I'm not particularly up in arms about this issue. The name will bend to the object in the fullness of time. :) I guess that doesn't bother me because rel=stylesheet isn't just one stylesheet either, you can @import lots of them down there. :) Similarly when I think of a component I don't think of one custom widget, I think of lots of logically related bundled things. - E
Re: [webcomponents]: What callbacks do custom elements need?
On 3/11/13 4:39 PM, Brian Kardell wrote: So does it actually need to be sync at that leve? I'm not sure why it does really. I'm not sure why it does either, honestly... -Boris
Re: [webcomponents]: What callbacks do custom elements need?
On 3/11/13 5:18 PM, Elliott Sprehn 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 available (like stepUp). Hmm. That's a good point. We should rope in Jonas and Olli on this bit. As long as it's ok to call attributeChanged right before the return from the attribute mutator, this seems to be a reasonable thing to me. -Boris
Re: [webcomponents]: What callbacks do custom elements need?
On 3/11/13 5:27 PM, Daniel Buchner wrote: - I thought the concern was over the same issues that plagued mutation/events/, namely perf-crushing event bubbling sparked by frequent DOM changes. The #1 issue with mutation events is that they insanely complicated implementation and specification because they ran script at all sorts of weird times. The #2 issue with mutation events was that they involved firing events and that's an expensive process (not related to bubbling) and that the events insisted on having all sorts of data about the mutation, so the data had to be saved before the mutation, which was slow. I had assumed that #2 is a non-issue here because we can just not expose too much information in the notification and we can make it trivial to detect quickly and reliably whether the call needs to happen at all (which was not possible with events). Given that, my main concern is with #1 above. It's almost certainly faster but may not be worth the machinery, depending on how much this is actually going to be used in practice. - these four basic callbacks/mutations are essential to custom element/component development - they will be used frequently, in our experience thus far. When you say frequently do you mean 90% of nodes will have listeners for these callbacks or 1% of nodes on 90% of pages will have listeners for these callbacks? Or more to the point, what fraction of attribute mutations will be impacted by whatever performance hit there is from this? I am assuming it will be low, but if it's not then we may need the extra machinery to reduce that fraction. - The target and actual audience is probably not going to be noobs/beginners I didn't say anything about beginners. I said people who don't care are usually not creating what they think of as apps. For example, news sites are notorious performance badness culprits. And I doubt cnn.com was created by noobs. -Boris
Re: [webcomponents]: What callbacks do custom elements need?
Is it very difficult to provide here is an attribute I'm watching + a callback? Most things require us to write switches and things and receive overly broad notifications which aren't great for performance or for code legibility IMO. Just curious. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [webcomponents]: What callbacks do custom elements need?
Sorry I clicked send accidentally there... I meant to mention that I think this is sort of the intent of attributeFilter in mutation observers On Mon, Mar 11, 2013 at 5:59 PM, Brian Kardell bkard...@gmail.com wrote: Is it very difficult to provide here is an attribute I'm watching + a callback? Most things require us to write switches and things and receive overly broad notifications which aren't great for performance or for code legibility IMO. Just curious. -- Brian Kardell :: @briankardell :: hitchjs.com -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [webcomponents]: What callbacks do custom elements need?
On 3/11/13 8:59 PM, Brian Kardell wrote: Is it very difficult to provide here is an attribute I'm watching + a callback? It's not super-difficult but it adds more complication to already-complicated code One big question is whether in practice the attribute that will be changing is one that the consumer cares about or not. If it's the former, it makes somewhat more sense to put the checking of which attribute in the consumer. -Boris
Re: [webcomponents]: What callbacks do custom elements need?
On Mar 11, 2013 9:03 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/11/13 8:59 PM, Brian Kardell wrote: Is it very difficult to provide here is an attribute I'm watching + a callback? It's not super-difficult but it adds more complication to already-complicated code One big question is whether in practice the attribute that will be changing is one that the consumer cares about or not. If it's the former, it makes somewhat more sense to put the checking of which attribute in the consumer. -Boris Daniel can confirm but in all of the stuff i have seen and played with so far it is...you want a changing a component attribute to have some effect. Internally you would use mutation observers i think.
