[whatwg] Verbosio 'template DOM' - breaking the rules for a reason
Over the last six months, I've quietly toiled away at an alternate DOM implementation for my Verbosio editing project. (Verbosio is a project for building a prototype XML editor, with XML languages supported as Firefox-like add-ons.) I would have preferred to use Mozilla's native DOM or a pre-existing DOM implementation like domjs or envjs, but unfortunately I felt that these would not meet my requirements - shadow content adjacent to the owning content, XML entity support and undo history management. I also felt that I could not at the time easily adapt any of them to my needs. (I'm aware of work ongoing in shadow content and undo history, but these specifications and implementations aren't mature yet.) So, being the mad scientist that I am, I built my own "template DOM" from scratch. It's nowhere near compliance with the DOM Living Standard ( http://dom.spec.whatwg.org/ ), nor do I intend it to be. I'll be using my template DOM in parallel with the Mozilla DOM - the former only for managing XML templates and XML entity references in Verbosio, the latter for rendering those templates and for ordinary DOM work. In particular, I've started a few wiki documents on my project's website where I explain what's supported, what's not supported, and why: https://sourceforge.net/p/verbosio/templates/wiki/DOM/ https://sourceforge.net/p/verbosio/templates/wiki/Infrastructure/ https://sourceforge.net/p/verbosio/templates/wiki/Build/ Currently, my Jasmine testing framework reports over 900 tests - most of which I'm certain the current DOM test suites already cover. The remaining tests are specific to my implementation and would likely not apply to other existing DOM implementations. In terms of merging my own work or ideas with other DOM implementations and specifications - I'm certainly willing to consider it, but I need this template DOM to work in my Verbosio editing project first. I'm posting to this mailing list primarily as a heads-up, to show where I'm going in the short term and perhaps to see if some of my approaches and algorithms could be useful to others in this space. The project's code is available under the Mozilla Public License version 2. Alex Vincent Hayward, CA, U.S.A. Planet Earth, Milky Way Galaxy, the Universe (roughly) -- "The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own." -- Alexander J. Vincent, June 30, 2001
Re: [whatwg] Real-time thread support for workers
On Thu, 9 Aug 2012, Jussi Kalliokoski wrote: > > On W3C AudioWG we're currently discussing the possibility of having web > workers that run in a priority/RT thread. This would be highly useful > for example to keep audio from glitching even under high CPU stress. > > Thoughts? Is there a big blocker for this that I'm not thinking about or > has it just not been discussed yet? (I tried to search for it, but > didn't find anything) I think it's impractical to give Web authors this kind of control. User agents should be able to increase the priority of threads, or notice a thread is being used for audio and start limiting its per-slice CPU but increasing the frequency of its slices, but that should be up to the UA, we can't possibly let Web authors control this, IMHO. On Thu, 9 Aug 2012, Jussi Kalliokoski wrote: > > Yes, this is something I'm worried about as well. But prior work in > native applications suggests that high priority threads are hardly ever > abused like that. Native apps and Web apps aren't comparable. Native apps that the user has decided to install also don't arbitrarily reformat the user's disk or install key loggers, but I hope you agree that we couldn't let Web authors do those things. The difference between native apps and Web apps is that users implicitly trust native app authors, and therefore are (supposed to be) careful about what software they install. However, on the Web, users do not have to be (anywhere near as) careful, and so they follow arbitrary links. Trusted sites get hijacked by hostile code, users get phished to hostile sites, trolls point users on social networks at hostile sites. Yet, when all is working as intended (i.e. modulo security bugs), the user is not at risk of their machine being taken down. If we allow sites to use 100% CPU on a realtime thread, then this changes, because untrusted hostile sites actually _can_ cause harm. The way the Web platform normally gets around this is by having the Web author describe to the UA what the author wants, declaratively, and then having the UA take care of it without running author code. This allows the UA to make sure it can't be abused, while still having good performance or security or whatnot. In the case of Web audio, the way to get sub-80ms latency would be say "when this happens (a click, a collision), do this (a change in the music, a sound effect)". This is non-trivial to specify, but wouldn't run the risk of hostile sites harming the user. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] URL: query encoding
Currently encoding the query component of a URL using the document's encoding affects all URLs with a "relative scheme" (http/ws/file/...). Should we restrict this to http/https/file so new schemes such as ws/wss and others will not be affected by this weird legacy quirk? Is that something implementors would consider following? The parsing section of http://url.spec.whatwg.org/ has this as an open issue for now. -- http://annevankesteren.nl/
Re: [whatwg] Improving autocomplete
On Fri, Oct 26, 2012 at 10:01 AM, Adam Barth wrote: > When should the UA offer to fill in the form (e.g., to select which > address they would like to use for shipping this particular order)? Presumably on page load. > In particular, Elliott wrote: > >> Authors can also display >> no forms at all to users of a browser who implements this proposal for >> one click checkout experiences which are important on mobile devices. I guess in that case it would be nice to know the user agent actually did display some UI. Are we using "cancel" elsewhere by the way? Fullscreen uses "error" as suffix for the event type. -- http://annevankesteren.nl/
Re: [whatwg] Improving autocomplete
On Fri, Oct 26, 2012 at 12:43 AM, Anne van Kesteren wrote: > On Fri, Oct 26, 2012 at 9:24 AM, Elliott Sprehn wrote: >> [...] > > I'm missing the scenario that requires such interference from a web > developer. Can't a UA just offer to autocomplete a form for me once it > finds one? (Or in other words, unless I'm missing something this seems > like a solution without a provided use case.) When should the UA offer to fill in the form (e.g., to select which address they would like to use for shipping this particular order)? In particular, Elliott wrote: > Authors can also display > no forms at all to users of a browser who implements this proposal for > one click checkout experiences which are important on mobile devices. Adam
Re: [whatwg] Improving autocomplete
On Fri, Oct 26, 2012 at 9:24 AM, Elliott Sprehn wrote: > [...] I'm missing the scenario that requires such interference from a web developer. Can't a UA just offer to autocomplete a form for me once it finds one? (Or in other words, unless I'm missing something this seems like a solution without a provided use case.) -- http://annevankesteren.nl/
Re: [whatwg] Should scrollbars move focus?
On Mon, Oct 22, 2012 at 6:28 PM, Ojan Vafai wrote: > ... > > This doesn't have to be specced, but it also doesn't really seems to be a > platform convention issue. The platforms that have scrollbars are all the > same (i.e. clicking on the scrollbar never moves focus) and no browser > fuller matches platform that convention. Gecko's behavior is most consistent > with that, except Gecko *does* move focus if you click on a textarea > scrollbar. It seems especially bad that you get a different behavior if you > click on the scrollbar of the window vs. the scrollbar of an overflow:auto > element that fills the window So what's the consensus here? Should WebKit have Gecko's behavior? Should we unify the world and make scrollbars never move focus even on ? :) - E
