Re: [whatwg] menu and friends
On Wed, Jan 9, 2013 at 10:17 PM, Ian Hickson i...@hixie.ch wrote: Optimising for the short-term shim author's experience rather than the long-term HTML authoring experience seems backwards to me. After input from a couple of other Gecko developers, I withdraw my objection to menuitem being void. As for command behavior in the parser, all major browsers have shipped releases with command as void, so we won't be able to reliably introduce a non-void element called command in the future anyway. Therefore, I don't see value in removing the voidness of command from parsing or serialization. The element doesn't exist, so there's no value in having it. We can easily introduce a non-void command in ten years if we need to, since by then the current parsers will be gone. Even if we accept, for the sake of the argument, that the current parsers will be gone in 10 years, it is incorrect to consider only parsers. Considering serializers is also relevant. The voidness of command has already propagated to various places—including serializer specs like http://www.w3.org/TR/xslt-xquery-serialization-30/ . (No doubt the XSLT folks will be super-happy when we tell them that the list of void elements has changed again.) At any point of the future, it is more likely that picking a new element name for a newly-minted non-void element will cause less (maybe only an epsilon less but still less) hassle than trying to re-introduce command as non-void. Why behave as if finite-length strings were in short supply? Why not treat command as a burned name just like legend and pick something different the next time you need something of the same theme when interpreted as an English word? What makes an element exist for you? Evidently, basefont and bgsound exist enough to get special parsing and serialization treatment. Is multiple interoperable parsing and serialization implementations not enough of existence and you want to see deployment in existing content, too? Did you measure the non-deployment of command on the Web or are we just assuming it hasn't been used in the wild? Even if only a few authors have put command in head, changing parsing to make command break out of head is bad. What do we really gain except for test case churn, makework in code and potential breakage from changing command as opposed to treating it as a used-up identifier and minting a new identifier in the future if a non-void element with a command-like name is needed in the future? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus
On Fri, Jan 11, 2013 at 10:00 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 11 Jan 2013, Henri Sivonen wrote: I understand that supporting XML alongside HTML is mainly a burden for browser vendors and I understand that XML currently doesn't get much love from browser vendors. Not just browser vendors. Authors rarely if ever use XML for HTML either. When you say use XML, do you mean serving content using an XML content type? I'm talking about serving text/html but using XML machinery to generate it (with a text/html-aware serializer at the end of the process). Still, I think that as long as browsers to support XHTML, we'd be worse off with the DOM-and-above parts of the HTML and XML implementations diverging. Sure, but if on the long term, or even medium term, they don't continue to support XHTML, this is no longer a problem. But if they do continue to support XHTML, introducing divergence will be a problem and, moreover, a problem that may become unfixable. (That we were able to converge on the namespace was narrow enough a success. It broke Facebook!) Anyway, I'm not suggesting that they diverge beyond the syntax (which is already a lost cause). All I've concretely proposed is syntax for binding Web components in text/html; I haven't described how this should be represented in the DOM, for instance. If we define foo/bar as being a text/html syntactic shorthand for foo xml:component=bar, or foo xmlcomponent=bar, in much the same way as we say that svg is a shorthand for svg xmlns=http://www.w3.org/2000/svg;, then the DOM remains the same for both syntaxes, and (as far as I can tell) we're fine. I didn't realize you were suggesting that HTML parsers in browsers turned bar/foo into bar xml:component=foo in the DOM. How is xml:component=foo better than is=foo? Why not bar foo=, which is what bar/foo parses into now? (I can think of some reasons against, but I'd like to hear your reasons.) The idea to stick a slash into the local name of an element in order to bind Web Components is much worse. I don't propose to change the element's local name. select/map has tagName select in my proposal. Oh. That was not at all clear. Please, let's not make that mistake. What do you propose to resolve this problem then? Let's focus on the requirements before proposing solutions. Some of the constraints are: - The binding has to be done at element creation time - The binding has to be immutable during element lifetime - The syntax must not make authors think the binding is mutable (hence why the select is=map proposal was abandoned) “Was abandoned”? Already “abandoned”? Really? How does xml:component=map suggest mutability less than is=map? Would it be terrible to make attempts to mutate the 'is' attribute throw thereby teaching authors who actually try to mutate it that it's not mutable? - The syntax must be as terse as possible - The syntax has to convey the element's public semantics (a specified HTML tag name) in the document markup, for legacy UAs and future non-supporting UAs like spiders. - It must be possible to generate the syntax using a serializer that exposes (only) the SAX2 ContentHandler interface to an XML system and generates text/html in response to calls to the methods of the ContentHandler interface and the XML system may enforce the calls to ContentHandler representing a well-formed XML document (i.e. would produce a well-formed XML doc if fed into an XML serializer). The syntax must round-trip if the piece of software feeding the serializer is an HTML parser that produces SAX2 output in a way that's consistent with the way the parsing spec produces DOM output. (This is a concrete way to express “must be producable with Infoset-oriented systems without having a different Infoset mapping than the one implied by the DOM mapping in browsers”. As noted, dealing with template already bends this requirement but in a reasonably straightforward way.) - It must be possible to generate the syntax with XSLT. (Remember, we already have !DOCTYPE html SYSTEM about:legacy-compat, because this is important enough a case.) Adding these requirements to your list of requirements may make the union of requirements internally contradictory. However, I think we should have a proper discussion of how to reconcile contradictory requirements instead of just conveniently trimming the list of requirements to fit your proposed solution. (For example, it could be that one of my requirements turns out to be more important than one of yours.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Canvas 2D memory management
On 11.01.13 18:41, Rik Cabanier caban...@gmail.com wrote: On Wed, Jan 9, 2013 at 8:00 AM, Ashley Gullen ash...@scirra.com wrote: Some developers are starting to design large scale games using our HTML5 game engine, and we're finding we're running in to memory management issues. Consider a device with 50mb of texture memory available. A game might contain 100mb of texture assets, but only use a maximum of 30mb of them at a time (e.g. if there are three levels each using 30mb of different assets, and a menu that uses 10mb of assets). This game ought to fit in memory at all times, but if a user agent is not smart about how image loading is handled, it could run out of memory. We have a WebGL renderer which solves this by explicitly creating and deleting textures as necessary when switching levels, which guarantees that memory is managed efficiently. It also has the additional benefit that all necessary textures are pre-loaded, so there's no janking during the game as the first drawImage() of a particular asset in the level uploads a texture. I would like to suggest memory management features for the canvas 2D rendering context. By explicitly pre-loading images and releasing them at the end of the level we can guarantee that devices will not run out of memory, as well as making gameplay smoother. Some ideas: 1) add new functions to the canvas 2D context, such as: ctx.load(image): cache an image in memory so it can be immediately drawn when drawImage() is first used Is this what you're looking for: http://www.whatwg.org/specs/web-apps/current-work/#imagebitmap Very interesting! I wasn't aware of this part of the spec. Sounds like this could become extremely useful. Looking forward to play with an implementation to see if it fixes our issues. ctx.unload(image): release the image from memory Releasing all reference to ImageBitmap should release it from memory. Are you looking for a scheme that does not involve garbage collection? Some of you concerns with memory management could be addressed with WeakMaps. Basically, you can put all your images in a WeakMap and during the draw cycle, you pull them out and use them. If they're no longer there, it meant that the garbage collector has kicked in to free up memory and you need to reload (which will unfortunately cause a jank). I'm unsure how smart the garbage collector is because you probably want the items in the WeakMaps to be deleted last. 2) we can drawImage() every image on startup to force lazy-loading browsers to load everything that will be used, but there's still no way to indicate which images should be released at the end of a level. This could be left for the browser to determine (perhaps releasing by least-recently-used), but perhaps this should be required in the specification? 3) leave current behavior as it is and suggest WebGL for this type of application My preference is option 1, but I don't know if this works for all use cases and will work nicely with implementations. Any thoughts? Ashley Gullen Scirra.com
[whatwg] AllowSeamless feedback
Hi whatwg, I recently became aware of the proposal to add AllowSeamless attribute that will permit cross-origin seamless iframes ( http://wiki.whatwg.org/wiki/AllowSeamless). We are currently working on a new security policy in Chrome, which will separate each site into its own renderer process. More information can be found at http://www.chromium.org/developers/design-documents/site-isolation. One of the requirements of this model is that cross-origin iframes will be rendered in a separate process from the main document. Since seamless iframes are currently allowed only if they are same-origin, this works fine. If we move to a mode where seamless iframes are allowed for cross-origin pages, it makes our isolation model very difficult to implement correctly. An example would be input events, which according to our reading of the spec for seamless should cross the iframe boundary. This means that we have to maintain synchronous model for event capture/bubble phases across multiple processes, which is prone to either deadlocks or environment inconsistency. Based on the existing security concerns listed in the proposal and the fact that it might prevent a useful new security architecture in browsers, I would suggest this not be added to the web platform. Thank you, Nasko Oskov
Re: [whatwg] AllowSeamless feedback
On Tue, Jan 15, 2013 at 12:39 AM, Nasko Oskov na...@chromium.org wrote: Based on the existing security concerns listed in the proposal and the fact that it might prevent a useful new security architecture in browsers, I would suggest this not be added to the web platform. FWIW, I think that limitation is known. (At least I cannot remember the last time someone actually proposed new API surface requiring synchronous access between two cross-origin Window objects.) iframe seamless could still be useful however cross-origin, even without cross-boundary events. -- http://annevankesteren.nl/
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Jan 9, 2013 11:59 PM, Adam Barth w...@adambarth.com wrote: To gather this information, I grepped the WebKit IDL files for CheckSecurity. Here's what I learned: [snip] I see no mention of document.domain handling in your description. How do you handle the case when script from one Window grabs a Node from another Window and then the document of one of the two Windows change its document.domain property? Also, in another email you mentioned that you had managed to implement the security restrictions on the Window object as a white-list rather than a black list by marking some interfaces as needs same-origin checks and then listing the functions that don't need it. Does this mean that you mark all interfaces that are implemented by the Window and Location objects as needs security checks? Including EventTarget? / Jonas
Re: [whatwg] Forms-related feedback
On Jan 8, 2013 1:47 AM, Ian Hickson i...@hixie.ch wrote: [1] The only difference between Chrome's spin buttons behaviour and our proposal is that when value is the empty string, it is setting value to 0 and continue to the next steps (unless the 0 is below the minimal allowed value and n 0, in that case value=min). It might be interesting to specify something better than do nothing if value=. I'm open to doing that too; what would you preference be? Maybe if value isn't valid, we could have it changed to the step base or |min + (max - min)/2| and exit the steps if stepDown() or stepUp() is called. (I think even if stepDown(hugeNumber) is called, we should still just set the value and do nothing else.) I would tend to prefer step base mostly because it would know set it to the default value if there is a default value. However, I think step base is quite a bad solution for some types. Maybe we could use the default value if there is such a concept for the type or the step base otherwise? It's probably simple enough for authors to check valueAsNumber is not NaN and then have them set it to the value they want as the default, if they're calling the stepUp/stepDown methods. I've left this as throwing if the value isn't a number. *All* behavior of stepUp/stepDown is easy enough for authors to work around to cover cases where they don't agree with the spec. But if they have to, I don't see why they wouldn't simply not use stepUp/stepDown and implement whatever functionality that they want. The functionality that these functions provide is very little. So if they don't solve the authors use case exactly I think its easier for them in almost all cases to simply write their own implementation. Especially if you take into account the time and effort involved in looking up how the function works. So if we are going to have these functions at all, I think it should be possible to simply make the implementation of a button as simple as: button onclick=elem.stepUp()... button onclick=elem.stepDown()... And that this should in all cases produce good UI in as many cases as possible, and should never throw any exceptions. If we can't fulfill those use cases and requirement, then I think we might as well remove these functions. / Jonas
Re: [whatwg] Forms-related feedback
On Jan 8, 2013 1:47 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 27 Nov 2012, Mikko Rantalainen wrote: Ian Hickson, 2012-11-22 07:15 (Europe/Helsinki): On Wed, 21 Nov 2012, Mounir Lamouri wrote: Then, maybe a better naming could be datetime-utc? I think that would mislead authors into thinking that the UI that users will see is one that asks for a UTC time. That kind of UI is the worst UI for this kind of feature, so that would be misleading. I'd suggest datetime-absolute because the other variant is floating or relative (to local politically decided time which may vary depending on future political decisions). We could rename datetime to datetime-absolute and leave datetime-local as named, but I'm not really convinced that's much better than what we have now. I think it more common for people to interact mainly with people in their own timezone. I.e. most time when talking about dates and times people don't me nation what timezone is involved and rely on contest to provide that information. This applies both professionally, since most people work at single-timezone companies, or at least single-timezone departments, as well as privately, since most people interact with friends and family mainly in the same timezone. So in most contexts when people think about a point in time, they do so for a specific timezone. When that is not the case, this is something that people are aware of. When I interact with friends/family/coworkers where the timezone is not obvious this is quite clear. And in these cases I'm aware that I need to specify timezone. I think that the same applies to developers. So I would imagine that when a developer sees datetime that does not include a timezone. Likewise, when a developer wants to ask the user for a point in time which does include a timezone, that they would remember to ask for that explicitly. Additionally, in many cases even when timezones are involved do UIs not ask for the timezone as part of the date/time picker. When looking for airplane tickets the timezone is assumed to be that of the departing location when talking about departing time, and that of the arrival destination when talking about arriving time. When renting a car, the same thing applies, even if the car is picked up and returned in different timezones. Even the calendar app that's on my device (the built-in calendar app for Android 4.2) does not ask for timezone as part of the date/time picker. Instead a separate control is used where the user can choose what timezone the separately entered date/time is. This makes a lot of sense since timezones are easy to forget about and so having explicit and separate UI makes things more unlikely that the user will forget to enter the information. This is actually required for repeating events since it's important to know which timezone the user picked. I.e. there are two values entered by the user: the date/time and the timezone. So first off I'm not convinced that the common case for date/time entry will include entering a timezone. That might be the case in the technology industry, but is likely not elsewhere. Second, I'm not convinced that even if the common case includes timezone entry, that this means that the intuitive behavior for a datetime input type is to include UI for timezone entry. Third, I think that even in many cases where timezones are involved, that the better UI is to have timezone entry separate from from the date/time picker. I'm not advocating that having a timezone aware date/time picker is a bad idea. But I don't think it should be the default behavior. It might not even make it into the 80% set of use cases. So at least we should make datetime refer to a timezone-agnostic picker. And then use datetime-global or datetime-absolute or some such as a timezone aware picker. / Jonas
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Mon, Jan 14, 2013 at 5:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Jan 9, 2013 11:59 PM, Adam Barth w...@adambarth.com wrote: To gather this information, I grepped the WebKit IDL files for CheckSecurity. Here's what I learned: [snip] I see no mention of document.domain handling in your description. Yeah, document.domain is no fun. :) How do you handle the case when script from one Window grabs a Node from another Window and then the document of one of the two Windows change its document.domain property? There isn't any code in WebKit that does anything special in this situation. Because there are no access checks for Node, the script can continue to use the Node interface as before. Also, in another email you mentioned that you had managed to implement the security restrictions on the Window object as a white-list rather than a black list by marking some interfaces as needs same-origin checks and then listing the functions that don't need it. Correct. Does this mean that you mark all interfaces that are implemented by the Window and Location objects as needs security checks? Including EventTarget? In WebKit, neither Location nor Window implement any other interfaces. Adam
