Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
Marc Fawzi wrote: This guy here is bypassing the DOM and using WebGL for user interfaces https://github.com/onejs/onejs He even has a demo, with no event handling other than arrow keys at this point, and as the author admits ugly graphics, but with projects like React-Canvas (forget the React part, focus on Canvas UIs) and attempts like these it looks like the way of the future is to relegate the DOM to old boring business apps and throw more creative energy at things like WebGL UIToolKit (the idea that guy is pursuing) I know Rik and keep in touch. OneJS is the kind of over-the-top work (not changing the DOM in-situ) that I recommended previously, in addition to incremental Web evolution. So once again, I'm not sure we disagree, but I am pretty sure your posts are misdirected to this list. Philosophizing about backward compatibility painting the Web into corners that kill it don't really move anything forward here. There is a gap to fill with respect to the GPU, which WebGL-based toolkits won't bridge. I think Rik would agree that we can't replace the web with raw JS+WebGL. Meanwhile, since the first iPhone, the major engines have all offloaded parts of their CSS rendering to the GPU (ideally with a big shared texture memory, bigger than the display viewport), in order to use a separate thread from the main UI event loop thread, for 60fps touch response. Of course the CPUs (multicore + SIMD) need to be used, so we don't want to marry a paritcular processing unit, or (worse) one GPU microarchitecture. Standards and even languages/toolkits (one.js is young) need to mature and abstract enough over hardware variation to be worth their weight -- but not so much they collapse like all the big OOP skycastles of the Java UI toolkit era have. The more we can do with incremental standards to expose this OMTC/A CPU+GPU-based computation in first class ways on the Web, the less anyone will have to make a old wolf or new tiger decision between Web and non-Web approaches. One concrete example: custom view scrolling. See http://robert.ocallahan.org/2014/07/implementing-scroll-animations-using.html If we can focus on these sorts of proposals and not thread-safe DOM or will-backward-compat-kill-the-Web imponderables, we'll get somewhere better, sooner. /be P.S. Meanwhile, are we done (for now) with deprecate-sync-XHR angst, and no browser actually plans to remove it? Not directed at Marc, rather my cc: list browser buddies. :-P
Re: Base Template (Was Re: Minimum viable custom elements)
Ryosuke, Jan, It might be useful for you two folks to work through Jan's Shadow DOM composition/inheritance insight (use cases?) together and see how they could be resolved without having multiple shadow roots per element. I would love to take advantage of all the work you both have done thinking about this problem separately. :DG On Thu, Feb 12, 2015 at 9:46 AM, Ryosuke Niwa rn...@apple.com wrote: On Feb 12, 2015, at 4:50 AM, Steve Faulkner faulkner.st...@gmail.com wrote: On 12 February 2015 at 10:58, Anne van Kesteren ann...@annevk.nl wrote: which is a very different problem from what you want to solve, no? The problem I think needs solving for minimum viable custom elements is reducing reliance on bolt-on accessibility. From the example provided http://janmiksovsky.github.io/base-template/ it appears that in this instance it does achieve that end. I don't know whether this will extend to other UI controls or whether it is a practical solution, which is why I brought it to the list for discussion. Again, this proposal or subclassing problem is nothing to do with custom elements but all do with shadow DOM. Ironically, I've pointed out the exact same problem explained in this page last April and proposed to change the way shadow DOM works to solve it: https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html - R. Niwa
Re: Minimum viable custom elements
On Thu, Feb 12, 2015 at 11:33 AM, Steve Faulkner faulkner.st...@gmail.com wrote: this turned up today: A possible solution for web component subclasses https://github.com/JanMiksovsky/base-template#a-possible-solution-for-web-component-subclasses needs people who actually understand this stuff to critique ;-) Well, it starts by saying [I]s it possible to define HTML custom element subclasses that can fill in base class insertion points? which is a very different problem from what you want to solve, no? Under limitations it says As written, this technique cannot be used to subclass standard HTML elements. which makes that even more clear. -- https://annevankesteren.nl/
Re: Minimum viable custom elements
this turned up today: A possible solution for web component subclasses https://github.com/JanMiksovsky/base-template#a-possible-solution-for-web-component-subclasses needs people who actually understand this stuff to critique ;-) -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 14 January 2015 at 14:45, Anne van Kesteren ann...@annevk.nl wrote: I've been trying to think of the smallest setup that adds value, can get broad agreement, and is therefore hopefully interoperable fast. * ES6-style class syntax to declare the imperative constructor. * No subclassing of normal elements for now. * registerElement() to enable declarative syntax and createElement(). * Parsing of declarative syntax invokes the registered constructor synchronously. * Existing lifecycle callbacks plus those agreed (copying, adopting). Notably this does not address upgrading. I think we can defer upgrading as it can be implemented in script fairly easily. You await for the imperative constructors to load and DOMContentLoaded at which point you traverse the tree and invoke replace() on those elements you want to upgrade. Ideally at some point we find a declarative solution for this, perhaps something like HTML modules, but shipping a v1 of custom elements in multiple browsers should not have to wait for that. It also does not address subclassing normal elements. Again, while that seems desirable the current ideas are not attractive long term solutions. Punting on it in order to ship a v1 available everywhere seems preferable. -- https://annevankesteren.nl/
Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
On 12/02/15 03:45, Marc Fawzi wrote: this backward compatibility stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones this has worked so far, miraculously and not without overhead, but I can only assume that it's at the cost of growing complexity in the browser codebase. I'm sure you have to manage a ton of code that has to do with old features and old ideas... how long can this be sustained? forever? what is the point in time where the business of retaining backward compatibility becomes a huge nightmare? As a side-note, the original thread is a good illustration of what happens whenever browser vendors attempt to deprecate features that are clearly broken by design. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature
Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
On Thu, Feb 12, 2015 at 4:45 AM, Marc Fawzi marc.fa...@gmail.com wrote: how long can this be sustained? forever? what is the point in time where the business of retaining backward compatibility becomes a huge nightmare? It already is, but there's no way out. This is true everywhere in computing. Look closely at almost any protocol, API, language, etc. that dates back 20 years or more and has evolved a lot since then, and you'll see tons of cruft that just causes headaches but can't be eliminated. Like the fact that Internet traffic is largely in 1500-byte packets because that's the maximum size you could have on ancient shared cables without ambiguity in the case of collision. Or that e-mail is mostly sent in plaintext, with no authentication of authorship, because that's what made sense in the 80s (or whatever). Or how almost all web traffic winds up going over TCP, which performs horribly on all kinds of modern usage patterns. For that matter, I'm typing this with a keyboard layout that was designed well over a century ago to meet the needs of mechanical typewriters, but it became standard, so now everyone uses it due to inertia. This is all horrible, but that's life.
[Bug 28008] New: [Shadow] Should Events that are Always Stopped include destination insertion points?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28008 Bug ID: 28008 Summary: [Shadow] Should Events that are Always Stopped include destination insertion points? Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: kojii...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org 5.1 Events that are Always Stopped[1] states that: The following events must always be stopped at the root node of the node tree While by following the algorithm in the event path calculation algorithm in 5.2 Event Paths[2], it includes the destination insertion points of CURRENT. Either the wording of 5.1 or the algorithm need to change. [1] http://w3c.github.io/webcomponents/spec/shadow/#events-that-are-always-stopped [2] http://w3c.github.io/webcomponents/spec/shadow/#dfn-event-path-calculation-algorithm -- You are receiving this mail because: You are on the CC list for the bug.
RfC: Manifest for web application; review deadline March 5
[ Bcc: public-webappsec, www-style, public-privacy, public-sysapps, public-digipub-ig, public-pfwg, public-web-mobile, www-international, chairs^1, public-review-announce; Reply-to: public-webapps ] This is a Request for Comments (RfC) for WebApp's Manifest for web application specification: http://www.w3.org/TR/2015/WD-appmanifest-20150212/ This specification defines a JSON-based manifest that provides developers with a centralized place to put metadata associated with a web application. This Working Draft is intended to meet the wide review requirements as defined in the 2014 Process Document. The deadline for comments is 5 March 2015 and all comments should be sent to the public-webapps @ w3.org mail list [Archive] with a Subject: prefix of [manifest]. The next anticipated publication of this specification is a Candidate Recommendation. (See [CR-Plan] for the specification's Candidate Recommendation status.) WebApps welcomes review and comments from all individuals and/or groups and we explicitly ask the following groups to review the document and to submit comments: WebAppSec, CSS WG (in particular, the display mode media feature), PING, SysApps, Digital Publishing IG, WAI (PF, User Agent, Authoring Tools), and I18N WG. In addition to substantive comments, to help us get a sense of how much review the document receives, we also welcome data about silent reviews, f.ex. I reviewed section N.N and have no comments. -Thanks, AB ^1 RfC is the new LCWD TransAnn [CR-Plan] https://github.com/w3c/manifest/issues/308 [Archive] https://lists.w3.org/Archives/Public/public-webapps/
Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
Aryeh Gregor wrote: This is all horrible, but that's life. Indeed, nature is nasty. Search for sacculina carcini life cycle for but one example. The Web and the Internet are evolving systems with some parallels and analogies to biological evolution. See http://www.cc.gatech.edu/~dovrolis/ for more on this, if you are interested. Nothing like _Sacculina_ yet, luckily! /be
Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
Brendan Eich wrote: over-the-top work Apologies if this overloaded trope is confusing without more context -- it could mean wildly excessive, or doing what soldiers in trenches did in WWI when the whistle blew (see https://www.youtube.com/watch?v=fssPqRWx9U0 :-/), but I meant build on top of JS and the DOM (even WebGL requires a bit of DOM for the canvas bit). /be
Re: Minimum viable custom elements
On 12 February 2015 at 10:58, Anne van Kesteren ann...@annevk.nl wrote: which is a very different problem from what you want to solve, no? The problem I think needs solving for minimum viable custom elements is reducing reliance on bolt-on accessibility. From the example provided http://janmiksovsky.github.io/base-template/ it appears that in this instance it does achieve that end. I don't know whether this will extend to other UI controls or whether it is a practical solution, which is why I brought it to the list for discussion. -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
Legacy problems Across the computing industry, we spend enormous amounts of money and effort on keeping older, legacy systems running. The examples range from huge and costly to small and merely annoying: planes circle around in holding patterns burning precious fuel because air traffic control can't keep up on systems that are less powerful than a smartphone; WiFi networks don't reach their top speeds because an original 802.11(no letter), 2Mbps system *could* show up—you never know. So when engineers dream, we dream of leaving all of yesterday's technology behind and starting from scratch. But such clean breaks are rarely possible. For instance, the original 10 megabit Ethernet specification allows for 1500-byte packets. Filling up 10Mbps takes about 830 of those 1500-byte packets. Then Fast Ethernet came along, which was 100Mbps, but the packet size remained the same so that 100Mbps ethernet gear could be hooked up to 10Mbps ethernet equipment without compatibility issues. Fast Ethernet needs 8300 packets per second to fill up the pipe. Gigabit Ethernet needs 83,000 and 10 Gigabit Ethernet needs *almost a million packets per second* (well, 830,000). For each faster Ethernet standard, the switch vendors need to pull out even more stops to process an increasingly outrageous numbers of packets per second, running the CAMs that store the forwarding tables at insane speeds that demand huge amounts of power. The need to connect antique NE2000 cards meant sticking to 1500 bytes for Fast Ethernet, and then the need to talk to those rusty Fast Ethernet cards meant sticking to 1500 bytes for Gigabit Ethernet, and so on. At each point, the next step makes sense, but* the entire journey ends up looking irrational.* Source: http://arstechnica.com/business/2010/09/there-is-no-plan-b-why-the-ipv4-to-ipv6-transition-will-be-ugly/ This guy here is bypassing the DOM and using WebGL for user interfaces https://github.com/onejs/onejs He even has a demo, with no event handling other than arrow keys at this point, and as the author admits ugly graphics, but with projects like React-Canvas (forget the React part, focus on Canvas UIs) and attempts like these it looks like the way of the future is to relegate the DOM to old boring business apps and throw more creative energy at things like WebGL UIToolKit (the idea that guy is pursuing) On Thu, Feb 12, 2015 at 3:46 AM, Aryeh Gregor a...@aryeh.name wrote: On Thu, Feb 12, 2015 at 4:45 AM, Marc Fawzi marc.fa...@gmail.com wrote: how long can this be sustained? forever? what is the point in time where the business of retaining backward compatibility becomes a huge nightmare? It already is, but there's no way out. This is true everywhere in computing. Look closely at almost any protocol, API, language, etc. that dates back 20 years or more and has evolved a lot since then, and you'll see tons of cruft that just causes headaches but can't be eliminated. Like the fact that Internet traffic is largely in 1500-byte packets because that's the maximum size you could have on ancient shared cables without ambiguity in the case of collision. Or that e-mail is mostly sent in plaintext, with no authentication of authorship, because that's what made sense in the 80s (or whatever). Or how almost all web traffic winds up going over TCP, which performs horribly on all kinds of modern usage patterns. For that matter, I'm typing this with a keyboard layout that was designed well over a century ago to meet the needs of mechanical typewriters, but it became standard, so now everyone uses it due to inertia. This is all horrible, but that's life.
RE: [Unbearable] IETF seeking feedback on proposed Token Binding Working Group
Hi Anne, This is part of a starting point proposal for the new working group; we expect the documents to change. It's a great time to suggest revisions; please feel free to suggest your text. I've put the initial I-Ds on github for easier editing: https://github.com/TokenBinding/Internet-Drafts Cheers, Andrei -Original Message- From: Unbearable [mailto:unbearable-boun...@ietf.org] On Behalf Of Anne van Kesteren Sent: Wednesday, February 11, 2015 4:19 AM To: Arthur Barstow Cc: public-webapps; unbeara...@ietf.org; WebAppSec WG Subject: Re: [Unbearable] IETF seeking feedback on proposed Token Binding Working Group On Wed, Feb 11, 2015 at 1:10 PM, Arthur Barstow art.bars...@gmail.com wrote: WebApps - please note the draft spec includes a new XHR property withRefererTokenBindingID https://tools.ietf.org/html/draft-balfanz-https-token-binding-00#section-3.4. If anyone has feedback about the proposal, please send it to the unbearable @ ietf.org list. However, comments related to the XHR aspect should be Cc/Bcc to public-webapps. Relatively recently we decided not to extend XMLHttpRequest further and prioritize fetch(). Can we expect a more concrete proposal to revise either or is this it? One problem with this proposal is that it does not use the Sec-* convention for headers so the header can be spoofed... -- https://annevankesteren.nl/ ___ Unbearable mailing list unbeara...@ietf.org https://www.ietf.org/mailman/listinfo/unbearable
Base Template (Was Re: Minimum viable custom elements)
On Feb 12, 2015, at 4:50 AM, Steve Faulkner faulkner.st...@gmail.com wrote: On 12 February 2015 at 10:58, Anne van Kesteren ann...@annevk.nl mailto:ann...@annevk.nl wrote: which is a very different problem from what you want to solve, no? The problem I think needs solving for minimum viable custom elements is reducing reliance on bolt-on accessibility. From the example provided http://janmiksovsky.github.io/base-template/ http://janmiksovsky.github.io/base-template/ it appears that in this instance it does achieve that end. I don't know whether this will extend to other UI controls or whether it is a practical solution, which is why I brought it to the list for discussion. Again, this proposal or subclassing problem is nothing to do with custom elements but all do with shadow DOM. Ironically, I've pointed out the exact same problem explained in this page last April and proposed to change the way shadow DOM works to solve it: https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html - R. Niwa
