[whatwg] Remove addCueRange/removeCueRanges
Hi, We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary. -- Philip Jägenstedt Opera Software
Re: [whatwg] Remove addCueRange/removeCueRanges
I agree with this assessment. Please note that at this stage this is my personal opinion, since I haven't discussed it with other Mozilla developers yet. Regards, Silvia. On Thu, Aug 13, 2009 at 6:31 PM, Philip Jägenstedtphil...@opera.com wrote: Hi, We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary. -- Philip Jägenstedt Opera Software
Re: [whatwg] the cite element
Erik Vorhes writes: So the definition of cite in HTML5 should currently be title of work or something that could be construed as a title where one doesn't exist in the explicit sense of 'title.' But not people's names, even if they're the citation, because using cite for citations is silly. Hi Erik. Rather than start with the cite element and think how you can use it, I find it easier to understand t'other way round: When writing text you sometimes want some words to be presented differently (typically in italics), to convey some information to readers. If the semantic you wish the italicized text to convey is that it's the title of a published work, then cite is the appropriate HTML element to use for this. (When word processing many folks simply use italics, meaning titles are marked up the same as, say, emphasis. This precludes later changing the house style in a way which distinguishes them, and from having voice output use different voice variants for each.) If you wish the graphical presentation of such titles to be something other than italic (underlined perhaps, or in a different colour, or in normal text but surrounded by quote marks) then you can achieve that with CSS. But the semantic is still there in the document, so can still be conveyed to all readers and listeners, regardless of their environment and user-agents. For words that you wish to have no distinct presentation from the surrounding text -- words that readers don't need calling out to them as being in any way 'special' -- simply don't mark them up. As Ian has pointed out, the above is technically non-conforming with what the HTML 4 spec claims. But it's how I've been using cite for years, since it makes sense and has a use. Other proposed definitions of cite may more closely correspond to the English word cite, but the set of phrases they would denote do not seem to be a useful set of things to lump together; they do not match any set of things which are typically conveyed to readers in a particular way (for example by typographical conventions). While HTML 5's definition of cite is a useful thing to have an element for, the name 'cite' is not a great choice to label that. However the element already exists; its previous definition has overlap with the useful definition; and its default display in existing browsers is the common typographic style for the useful definition (which gives weight to the idea that the HTML 5 definition is actually what at least some people intended in the first place, or have already been using it as). So tweaking the definition to be more useful seems better than inventing a new element with a better name. Smylers
Re: [whatwg] Make quoted attributes a conformance criteria
On Tue, 4 Aug 2009, Henri Sivonen wrote: On Aug 3, 2009, at 05:45, Ian Hickson wrote: Instead of preventing anyone from not using quote marks, I would instead recommend asking your validator vendor to offer you an option to require quote marks and warn you when you have forgotten them. There's a usability cost and a QA cost to adding optional features to a validator, which is why I try to resist requests to add more configuration and optional features to Validator.nu. We need more validators, so that authors can pick the one they want. I'm not saying validator.nu should be the one to support this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Installed Apps
On Tue, 4 Aug 2009, Drew Wilson wrote: On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson i...@hixie.ch wrote: It seems like a direct solution to these would be to have a way for Web pages to expose a service that clients could subscribe to, which could send up database updates and notifications. That way, no script runs on the client, but the server can still update the client whenever needed. Yeah, this is an interesting idea, although I'm envisioning apps that support offline use requiring what amounts to a sync process with app-specific conflict resolution, etc - I think this would be difficult to support with this kind of general platform. But, agreed, this is better than nothing - at the very least, an application could use it to sync down changes to a staging area for later resolution once the app itself starts up. Ok. I think this is the direction we should look in to address this use case then. I haven't specced anything yet, but I've noted it as a feature we should look at. If anyone wants to experiment in this space, that would be great. Sure, although I'd say that persistent storage is addressed by the Web Storage and Web Database features. Shared state is also addressed, but that's not the primary goal. If I have a tree of objects that I'd like to share between two pages, telling me to serialize it into name/value string pairs, write it into Web Storage, and then have the remote side read it out is not a satisfying (or performant) solution. Web Storage supports structured data now. Yeah, I'm somewhat leery of the canned RSS-feed-style solution to notifications (our vision for notifications is that they are scriptable and more interactive than just a dumb text + icon). A system that displays rich/scripted content on server demand rather than on user demand is a massive security nightmare. It turns a scripting security bug and an XSS bug into an instant malware deployment vector. Additionally, any server-side-feed-based solution has the implication that it won't work for offline apps. If I am using a web calendar, I want my event notifications regardless of whether I'm online or offline (the event may have been added while I'm offline and never synced to the server at all). I think on the long term we may wish to consider adding a feature to queue up POSTs for when the UA finds it is back online. That would address a number of problems, including this one. On Tue, 4 Aug 2009, Jeremy Orlow wrote: The idea of tying the notification spec to a particular brand of storage seems like a bad idea...especially at this point in time. We can make this work with all of the mechanisms pretty easily. On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson i...@hixie.ch wrote: I'm not sure XMPP is the protocol I would jump to, but it's certainly an option, yes. What don't you like about XMPP? It's far too complex for people to write and deploy an XMPP server on a whim. Like HTTP, it requires people to use off-the-shelf software instead of allowing them to experiment with their own code. This leads to software monocultures, and prevents easy experimentation. On Tue, 4 Aug 2009, Dmitry Titov wrote: What about the shared context with DOM access idea which, even w/o persistency, seems to resolve some issues for apps like GMail? Like a shared worker, but with access to DOM. I don't think that such a mechanism will work well given multicore processors, multiprocess UAs, and the way that gadgets end up connecting domains all over the place. 2. It does rely on 'cooperative' pages to be opened in the same process but this is easy to implement. I mean, you can't 'guarantee' it (a page from another domain may have iframe pointing to the app and it will be in a diff. process) but any reasonable app can be easily structured in a way to get its views (pages) into a single process. I think this is understating the disadvantages of this model, and overestimating the ease with which one can make it work. 3. It would help to provide fast (meaning sub-100ms, interactively fast) UI responses necessary for the seamless operations. Persistent data storage and parsing/generating HTML (including loading all the code necessary to do that from the 'pure data') will always present challenge for sub-100ms UI actions - even in native apps it is a challenge today. Here is a typical use case: You compose a message in GMial window. Halfway through you decide to peek into another mail thread for more information. You click 'tear-off' button to disconnect the compose window so you can see other mail threads. Today, this opens a new window and starts loading XXX Kb of script into it. You see the progress indicator for a few seconds. This script is needed to be able to go to server and generate a proper UI from the response, as well as have all the 'controller' logic when user starts to interact with such UI. With
Re: [whatwg] Fullscreenable and Mouselockable attributes
On Tue, 4 Aug 2009, Henry Bridge wrote: With the video tag and web games gaining traction, it seems like there should be a way for apps to provide fullscreen and better control schemes to users. Of course, spoofing and clickjacking are major concerns, but I liked Alpha Omega's suggestion a few weeks ago [1] to specify a fullscreenable attribute to certain elements that hint to the UA that the object would be appropriate to consider for fullscreen. Similarly, for content that uses relative mouse motion or requires great precision (like a first-person view), it would be useful to have a mouselockable attribute; upon a UA defined interaction, the mouse would be locked within the particular element and report relative mouse events until the user disengages the lock. I can imagine a variety of ways browsers could expose these features: overloading F11 to gray out all portions of page except those are fullscreenable; pressing F11 repeatedly to cycle through elements; having a right click option on fullscreenable elements, automatic hover borders etc. I think this would be an interesting idea. I think experimentation with a UI for this would be a good way to find out if it is feasible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Installed Apps
Ian Hickson wrote: On Tue, 4 Aug 2009, Drew Wilson wrote: Sure, although I'd say that persistent storage is addressed by the Web Storage and Web Database features. Shared state is also addressed, but that's not the primary goal. If I have a tree of objects that I'd like to share between two pages, telling me to serialize it into name/value string pairs, write it into Web Storage, and then have the remote side read it out is not a satisfying (or performant) solution. Web Storage supports structured data now. I'm assuming that you refer to the concept of structured clone now added to http://dev.w3.org/html5/webstorage/. This certainly makes life easier for certain scenarios, but I don't think it fully addresses Drew's use case. The problem is that to change the tiniest thing in the object graph, you will have to get a complete copy of the data out from the storage provider, apply the change, and then let it be copied (cloned) back into storage again. With Drew's large mailbox + categories example I think this will be too inefficient. Also, it cannot be divided into chunks stored under individual keys as that breaks object pointers. Maybe I'm mistaken, but I think Drew wanted handling of live objects, where each window gets access to the same concrete objects (possibly protected by private proxy objects) so the graph can be walked without cloning. Drew: are you thinking that the same object graph also makes up the data cache between sessions? If not, then persistence is not a must-have for this use case so the area of ideas could well expand outside webstorage. (Minor note: the Introduction still says that structured data needs to be handled manually: To store structured data in a storage area, you must first convert it to a string.) Best regards Mike Wilson
Re: [whatwg] the cite element
On Thu, Aug 13, 2009 at 4:59 AM, Smylerssmyl...@stripey.com wrote: As Ian has pointed out, the above is technically non-conforming with what the HTML 4 spec claims. But it's how I've been using cite for years, since it makes sense and has a use. I defy you to show me in the HTML 4.01 specification where something like the following is nonconforming: pI like to read nonfiction, such as citeJohn Adams/cite, but I had more time for that when I was a professional academic./p Erik
Re: [whatwg] Remove addCueRange/removeCueRanges
Hi, please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. AFAIK, when dropping support for 'start' and 'end' attributes it was noted on this list that cue ranges would provide a replacement to dynamically select, say, a 3-second range from a 1-hour audio source. So, if cue ranges will indeed be dropped, could browser vendors and standards people consider putting 'start' and 'end' back in, just like Safari had it for a while (albeit buggy)? Actually, out of curiousity: could gapless concatenation of several audio objects be added as well, e.g. audioObject1.append(audioObject2) or even audioObject.join([audioObject1,audioObject2,...,audioObjectN) Just my 2c. --Markus Philip Jägenstedt wrote: Hi, We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary.
Re: [whatwg] Remove addCueRange/removeCueRanges
On Thu, 13 Aug 2009 14:34:55 +0200, Dr. Markus Walther walt...@svox.com wrote: Hi, please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. AFAIK, when dropping support for 'start' and 'end' attributes it was noted on this list that cue ranges would provide a replacement to dynamically select, say, a 3-second range from a 1-hour audio source. So, if cue ranges will indeed be dropped, could browser vendors and standards people consider putting 'start' and 'end' back in, just like Safari had it for a while (albeit buggy)? The .start/.end properties were dropped in favor of media fragments, which the Media Fragments Working Group is producing a spec for. It will be something like http://www.example.com/movie.mov#t=12.33,21.16 See http://www.w3.org/2008/01/media-fragments-wg.html and http://www.w3.org/2008/WebVideo/Fragments/wiki/Syntax#Examples Actually, out of curiousity: could gapless concatenation of several audio objects be added as well, e.g. audioObject1.append(audioObject2) or even audioObject.join([audioObject1,audioObject2,...,audioObjectN) There has been much discussion about audio canvas API:s and I trust this could fit into that scope. View source at http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video and search for v2 and you'll find some of these ideas. -- Philip Jägenstedt Opera Software
Re: [whatwg] the cite element
On Thu, Aug 13, 2009 at 2:26 PM, Erik Vorhese...@textivism.com wrote: On Thu, Aug 13, 2009 at 4:59 AM, Smylerssmyl...@stripey.com wrote: As Ian has pointed out, the above is technically non-conforming with what the HTML 4 spec claims. But it's how I've been using cite for years, since it makes sense and has a use. I defy you to show me in the HTML 4.01 specification where something like the following is nonconforming: pI like to read nonfiction, such as citeJohn Adams/cite, but I had more time for that when I was a professional academic./p Erik I don't think John Adams is a name of a person in this context. It is a group of works. Remco
Re: [whatwg] the cite element
On Thu, Aug 13, 2009 at 4:59 AM, Smylerssmyl...@stripey.com wrote: For words that you wish to have no distinct presentation from the surrounding text -- words that readers don't need calling out to them as being in any way 'special' -- simply don't mark them up. Interesting point. Should the HTML5 specification explicitly admonish against using microformats, microdata, RDFa, and the like?
Re: [whatwg] the cite element
Erik Vorhes writes: On Thu, Aug 13, 2009 at 4:59 AM, Smylerssmyl...@stripey.com wrote: As Ian has pointed out, the above is technically non-conforming with what the HTML 4 spec claims. But it's how I've been using cite for years, since it makes sense and has a use. I defy you to show me in the HTML 4.01 specification where something like the following is nonconforming: By the above I was refering to my previous paragraphs -- in which I'd just described my use of cite. I am admitting that _my_ definition isn't permitted by HTML 4. I am _not_ claiming that your definition isn't allowed in HTML 4; I'm claiming that the HTML 4 definition, including things like marking up names, isn't particularly useful. For this example: pI like to read nonfiction, such as citeJohn Adams/cite, but I had more time for that when I was a professional academic./p How do you want that to be rendered? The conventional presentation would be for John Adams simply to be rendered in exactly the same way as the surrounding text, with the reader being given no information at all that those words are in some way special. Smylers
Re: [whatwg] Spec comments, sections 3.1-4.7
Tab Atkins Jr. writes: On Wed, Aug 12, 2009 at 7:43 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: I haven't noticed many progress bars on the web You see them a lot more in the indeterminate form, as a 'spinner' image or the like. ... I suspect, though, that there are a lot of places you currently don't see a progress bar solely because it's a bit of a pain to do. Many shopping sites have indicators of how far you are through the buying process (Step 2 of 4), and online surveys often have progress bars indicating the position in the survey. Typically these are static to the page (as in, making progress and seeing the indicator move involves submitting a form and displaying the next page in the sequence), but so far as I can see from the spec progress can be used in these situations; it isn't restricted to use on a single page where it is updated dynamically. Smylers
Re: [whatwg] Issues with Web Sockets API
13.08.2009, в 4:42, Ian Hickson написал(а): A note explaining that the close event will be dispatched at server's discretion (or on subsequent connection timeout), potentially long time after close() is called, would likely make the intention clearer. It won't be long after the close(). Why not? My understanding is that it can take arbitrary amount of time - the server can choose not to close its side of connection for years, and to send data over it. - WBR, Alexey Proskuryakov
Re: [whatwg] the cite element
Erik Vorhes writes: On Thu, Aug 13, 2009 at 4:59 AM, Smylerssmyl...@stripey.com wrote: For words that you wish to have no distinct presentation from the surrounding text -- words that readers don't need calling out to them as being in any way 'special' -- simply don't mark them up. Interesting point. Should the HTML5 specification explicitly admonish against using microformats, microdata, RDFa, and the like? Possibly I stated the above too strongly. In general invisible metadata doesn't have a great history; the most successful systems involving machine-parsed web pages seem to involve machines parsing the human visible parts of pages rather than things like meta keywords. But I didn't actually mean to go so far as to say these should never be used. If somebody can do something useful with names marked up as metadata then that's a reason for marking it up in some way. But HTML 5 doesn't need a specific element for that; there's the generic microdata syntax. If marking up people's names when citing them becomes really common then a future version of the spec could mint an element for that (like happened with time, a common metadata pattern). But there still wouldn't be a call for an element which sometimes indicates its contents should be displayed to the reader in a way which indicates they are the title of a work and sometimes indicates its a person's name. Smylers
[whatwg] size limits on web databases
From http://dev.w3.org/html5/webdatabase/: The openDatabase() method on the Window and WorkerUtils interfaces must return a newly constructed Database object that represents the database requested. The spec does not make it clear what the UA on an extremely resource-constrained device (e.g. a mobile phone) should do if the requested size database size cannot be satisfied. Some implementations return a null Database object if something has gone wrong in the openDatabase() call but (at least to me) the spec does not seem to permit this and simply returning null does not particularly help an application adapt gracefully to the availability of only a small database. Consequently, I would hope that this could be improved in some fashion. Three possible modifications to the spec occur to me. From the viewpoint of webdatabase developer, I prefer (1), could work with (2) and would greatly dislike (3). Is this reasonable? 1. Retain the existing def'n of openDatabase but add a property on interface Database: unsigned long minimumCapacity; which returns the amount of storage that the UA guarantees to be present in the database at the time of opening. The UA should try to set minimumCapacity so that QUOTA_ERR will be extremely unlikely if the database client code never writes more than minimumCapacity bytes to the database. 2. A language change: The user agent may raise a SECURITY_ERR exception instead of returning a Database object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to open databases). to something like this: The user agent must raise a SECURITY_ERR exception instead of returning a Database object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to open databases) or the estimatedSize of the database cannot currently be satisfied (e.g. the UA is running from a read-only volume or the estimatedSize exceeds the free space on the volume.) 3. An alternative language change: The openDatabase() method on the Window and WorkerUtils interfaces must return a newly constructed Database object that represents the database requested. to The openDatabase() method on the Window and WorkerUtils interfaces must return a newly constructed Database object that represents the database requested or null if openDatabase call has failed. Rob. -- Rob Kroeger rjkro...@liqui.org http://www.liqui.org
Re: [whatwg] Remove addCueRange/removeCueRanges
At 10:31 +0200 13/08/09, Philip Jägenstedt wrote: Hi, We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary. We reluctantly agree. We suggested a re-think a year ago, and though that got some support, it didn't get the editor's support. We do not have an implementation of the current spec., and don't expect to. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015284.html We do think the functionality is important, and are saddened to agree with this proposal, however. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Installed Apps
On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson i...@hixie.ch wrote: Additionally, any server-side-feed-based solution has the implication that it won't work for offline apps. If I am using a web calendar, I want my event notifications regardless of whether I'm online or offline (the event may have been added while I'm offline and never synced to the server at all). I think on the long term we may wish to consider adding a feature to queue up POSTs for when the UA finds it is back online. That would address a number of problems, including this one. It seems like conflict resolution will be more difficult when it can only happen at the server side. In addition, it seems like there'd be more efficient means of syncing rather than many small messages. We don't have to talk about this now since there isn't even a proposal yet, but I'm doubtful this will be a good solution to the problem. On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson i...@hixie.ch wrote: I'm not sure XMPP is the protocol I would jump to, but it's certainly an option, yes. What don't you like about XMPP? It's far too complex for people to write and deploy an XMPP server on a whim. Like HTTP, it requires people to use off-the-shelf software instead of allowing them to experiment with their own code. This leads to software monocultures, and prevents easy experimentation. I guess we'll see how the WebSocket protocol works out. I definitely see both pros and cons to this approach.
Re: [whatwg] Spec comments, sections 3.1-4.7
On Thu, 13 Aug 2009 19:34:47 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: I'd think that the author in this use-case is not likely to be happy using an unstyle-able progress element and getting some kind of unknown appearance that might clash with their color scheme or such. You seem to base most of your argument on that progress will not be stylable. I think the idea is that it will be stylable though. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Installed Apps
On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson i...@hixie.ch wrote: Sure, although I'd say that persistent storage is addressed by the Web Storage and Web Database features. Shared state is also addressed, but that's not the primary goal. If I have a tree of objects that I'd like to share between two pages, telling me to serialize it into name/value string pairs, write it into Web Storage, and then have the remote side read it out is not a satisfying (or performant) solution. Web Storage supports structured data now. Yeah, the fact that the UA will automatically jsonify my (cycle-free) data structures does not really make this a great solution, for many of the reasons Mike Wilson mentioned. That said, once you've architected your application around having only asynchronous access to your data structures, there are lots of tools available in HTML5 to do sharing (use WebStorage as you describe, push all data access through a SharedWorker, keep duplicate copies of data structures in each page and update them via DB or SharedWorker messages, etc). A system that displays rich/scripted content on server demand rather than on user demand is a massive security nightmare. It turns a scripting security bug and an XSS bug into an instant malware deployment vector. Another name for a system that displays rich/scripted content on server demand is an open web page :) The only difference is the user has UI to close a web page when he's done interacting with it, while the UI to enable/disable notifications from a domain is probably less obvious. Scriptable notifications are a use case that none of these proposals currently satisfy. I understand the security concerns. I just don't (yet :) share the general belief that they are insurmountable which is why I want to continue experimenting in this area. Additionally, any server-side-feed-based solution has the implication that it won't work for offline apps. If I am using a web calendar, I want my event notifications regardless of whether I'm online or offline (the event may have been added while I'm offline and never synced to the server at all). I think on the long term we may wish to consider adding a feature to queue up POSTs for when the UA finds it is back online. That would address a number of problems, including this one. I'll just note that to get a narrow subset of the behavior that simple background scripting would provide (static notifications and static data synchronization without client-side reconciliation), we're having to have: 1) A server-controlled push notification stream, as well as infrastructure for applications to insert/remove notifications into the stream for offline use. 2) Some kind of server database push-sync protocol. 3) Some kind of queued up posts feature (with assumedly yet more infrastructure to deal with errors/return values from these delayed POSTs). What you really want for #2/#3 is a general-purpose sync protocol, but I don't see how you do it without some form of client-side conflict resolution. I hope that people understand why application scripting seems like a more attractive, general-purpose solution. I'm unable to muster much enthusiasm for a set of convoluted server-and-client-side mechanisms that cover such a narrow set of use cases without any way for client applications to customize this behavior through scripting. I really don't feel right allowing script to run like that. Why can't the server send the data to the client in a near-final form and let the script figure it out when the user finally opens the app? What if there are things the application wants to do to act upon this data immediately (add items to the notification stream, for example)? What you're saying is we need to push all of this functionality up to the server, then provide a very narrow set of APIs (essentially, static notifications) that the server can use to act on that functionality. What other use cases are there? Those were the ones given. We're very much use-case-driven here. I won't claim to understand all of the potential use cases yet, but I have a preference for general-purpose solutions rather than solutions that narrowly target a set of specific use cases, although I recognize that more general-purpose solutions have commensurate security implications. I'd like to just experiment with background scripting/scriptable notifications in a way that people find acceptable (either without persistence, or using extensions for persistence), see how applications actually use them, then continue this conversation. People are certainly welcome to do parallel experimentation with other approaches such as the ones you've outlined above. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Installed Apps
On Thu, Aug 13, 2009 at 5:13 AM, Mike Wilson mike...@hotmail.com wrote: Maybe I'm mistaken, but I think Drew wanted handling of live objects, where each window gets access to the same concrete objects (possibly protected by private proxy objects) so the graph can be walked without cloning. To be honest, I'm not really a good spokesperson for this issue, as most of my thinking has been around shared workers which have all the same drawbacks for data sharing that WebStorage has. I was just saying that I understand the problem that the shared context is trying to address. I personally think that part of the problem can be overcome using the existing tools, although with more effort on the app side than a simple shared context solution. Drew: are you thinking that the same object graph also makes up the data cache between sessions? If not, then persistence is not a must-have for this use case so the area of ideas could well expand outside webstorage. I think ideally serialization would happen only when data needs to be persisted. If I have a data structure that I want to share with other open windows, I shouldn't have to persist it to accomplish this, and I certainly shouldn't have to re-serialize it every time I want to make a minor change. But, again, I'm just speaking in the abstract - the folks proposing shared context (Dmitry) should probably chime in here as they've thought about this problem much more than I have. -atw
Re: [whatwg] Spec comments, sections 3.1-4.7
On Thu, Aug 13, 2009 at 4:00 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: On Thu, Aug 13, 2009 at 2:11 PM, Anne van Kesterenann...@opera.com wrote: You seem to base most of your argument on that progress will not be stylable. I think the idea is that it will be stylable though. Yes, I guess I got sort of sidetracked. I assume the idea is that it will be styleable eventually, but I don't see how it would work with existing CSS properties, so I'd assume it would take significant implementation effort and not happen very soon. I don't think it will be used very widely or usefully until it becomes styleable. Beyond that, the use-cases just seem very narrow compared to other elements invented in HTML 5. The number of progress bars needed on the web is pretty modest, and the gains from marking them up semantically don't seem to be large. For some particular types of progress bars, progress gives better accessibility than any straightforward existing possibility I can think of, but a) authors concerned about accessibility could usually add some kind of text without any trouble, and b) the progress of some activity is rarely critical information in web apps, so if you're missing it you usually won't be missing much anyway. Well, it's a default widget in jQuery UI. I think that makes a good case for it being common enough that it'll see use. (For reference, the other default widgets are a datepicker and slider, which are new input types, a styleable dialog box, and then accordion and tab displays (which were hit by some proposals between Brad Kemper and I on the CSS list a while back).) ~TJ
Re: [whatwg] HTML5 History Management
On Wed, 5 Aug 2009, Nathan Hammond wrote:
With regards to pushState not triggering a hashchange event, I like it,
but I do want to be absolutely sure that all implementers get this
right. So, could we clarify this in the spec? Right now I think that the
spec could be read where since it adjusts the document's current address
it might should cause a hashchange event. Providing this specific
example would do the trick.
Done.
Related, is window.location.hash = newhash; supposed to trigger a hashchange
event? (Is this specified? I couldn't find it.) I do believe it does in IE8,
but I don't have IE8 available to me at this moment to check.
Yes, and yes, it is specified. It triggers a navigation, which eventually
gets around to the part that fires hashchange.
2. Specify a method to allow access to the history stack. (At least
readable within the context of same-origin, possibly mutable.)
This would allow for understanding on the client side of a user's
path through the site, even after navigating away from the page. If
this is not implemented the absolute first thing I will be
implementing is a method to track this information, a rather large
duplication of effort for something that could easily be made
available. This would involve a something like currentstate = {
_previous: currentstate, title: window.title, newval: true }; plus a
form-based storage mechanism to repopulate state in case the user
exits on a page which they manually changed the hash to get to
(which would not have access to the data object upon revisiting
later since there wouldn't be one stored with that history state).
I'm aware of the privacy ramifications, but at the same time, I'm
going to be exposing those exact same concerns with the above
method.
It turns out to be quite complex to expose this in the API currently,
because the History object exposes a mix of all the various frames at
once, and you can get to the History object of cross-origin frames,
and there's some other legacy baggage here also (e.g. history.length).
Since it's not entirely clear what the use case is, and since you can
do it to some extent already using onload, onhashchange, and
onpopstate, I'd rather just let authors reimplement this themselves at
this point, and maybe revisit this in a future version.
Complexity. Bah! (Then again, you don't have to tell me.) The use case I
find is pretty simple: in the event that there are two separate ways to
get to a specific page in the app I need to know how the person got
there. Or this could be used to provide content tailored specifically to
that user based upon their history (whether suggestions, ads, or help
text). Really though, this point is far less critical (as it is easy
enough to handle in client code) and does greatly increase the
complexity for getting all implementers on board. If this *isn't*
implemented however, the point below becomes more critical for being
able to successfully track state in client code...
I don't really understand the scenario under which those use cases would
be relevant. Can you show an example of someone doing something like this
now?
3. Specify a method to modify the current history state without adding a
new history point.
Assuming you don't mind causing the page to reload, you can use
history.replace(). I'm not sure what it would mean to replace the history
state without changing the Document or anything, though.
This would alleviate the need for the (incredibly brittle) form-based
storage mechanism I describe above.
Can you use sessionStorage for this?
I should have stated this one with a goal: the ability to ensure that
the popstate event always fires with a full understanding of the
(app/page) state when navigating through history. This would be lost
when a user manually changes the hash. With that as my goal,
history.replace does not achieve what I am trying to accomplish. Neither
does pushState without a URL as that still registers a new history
point.
All the information about the state really should be in the URL, such that
the state of the app after the user manually changes the hash, and the
state of the app after the user returns to a point in the history where he
had manually changed the hash, really should be the same. I don't think we
should encourage cases where the same URL can correspond to multiple
states, which this would encourage.
4. Specify additional properties on the hashchange event.
Lots of possible useful information with the number one most
important being the new hash that triggered the event to prevent
race conditions reading window.location.hash. Other fun things that
are a bit more pie in the sky: the previous hash and knowledge of
how it was triggered (manually? pushState? window.location.hash = ?
window.location.href = ?).
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, Aug 14, 2009 at 3:31 AM, David Singersin...@apple.com wrote: At 10:31 +0200 13/08/09, Philip Jägenstedt wrote: Hi, We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary. We reluctantly agree. We suggested a re-think a year ago, and though that got some support, it didn't get the editor's support. We do not have an implementation of the current spec., and don't expect to. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015284.html We do think the functionality is important, and are saddened to agree with this proposal, however. I am actually hoping that we could attach callbacks to time-aligned text segments which makes the whole approach to cue ranges more generic. Hopefully I will have a demo of this within the next few weeks, so we can discuss further. Regards, Silvia.
Re: [whatwg] AppCache online whitelist wildcard bypasses restriction on scheme
On Wed, 5 Aug 2009, Jenn Braithwaite (�~C��~E��~K~R) wrote: In the AppCache section of the HTML5 spec, the new wildcard value '*' for the online whitelist section allows one to 'whitelist all' regardless of scheme. However, the spec requires a URL in the online whitelist section to have the same scheme as the manifest URL. Seems like the new wildcard feature has created a mismatch in whether the scheme should be restricted. Should the scheme restriction be consistent regardless of wildcard value vs explicitly listed URL? I've changed the model to so that any resourcs that aren't in the same scheme are automatically in the online whitelist, whether * is specified or not. I think the scheme restrictions were always intended to work this way (i.e. always intended as a way to make it impossible to cache mailto: URIs, and things like that, and always intended to not block cross-scheme networking), but it seems it was only half-baked before. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Remove addCueRange/removeCueRanges
Hi Markus, 2009/8/13 Dr. Markus Walther walt...@svox.com: please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. Not quite. You can always use the video.currentTime property in a javascript to directly jump to a time offset in a video. And in your javascript you can check this property until it arrives at your determined end time. So, there is a way to do this even now. I agree that this is rather crude and not integrated, which is why I am working on a callback addition to the itext specification. However, the situation is not as bad as you may think. Also, I don't think keeping the cueRange specification in the spec will change the current situation with browser vendors not implementing it. So, your needs won't be satisfied no matter whether it says or not. We could decide to keep the cueRange proposal in the spec as a reminder that there is still a problem to be solved. However, since we have removed such reminders elsewhere in the spec (e.g. the need for a baseline codec), it doesn't seem to make much sense to me to keep it as a reminder. Just my 2c. :-) Cheers, Silvia.
Re: [whatwg] Section 1.4: Editorial: Avoid passive voice
On Wed, 5 Aug 2009, Elliotte Rusty Harold wrote: Section 1.4 currently states: Work on HTML 5 originally started in late 2003, as a proof of concept to show that it was possible to extend HTML 4's forms to provide many of the features that XForms 1.0 introduced, without requiring browsers to implement rendering engines that were incompatible with existing HTML Web pages. At this early stage, while the draft was already publicly available, and input was already being solicited from all sources, the specification was only under Opera Software's copyright. In early 2004, some of the principles that underlie this effort, as well as an early draft proposal covering just forms-related features, were presented to the W3C jointly by Mozilla and Opera at a workshop discussing the future of Web Applications on the Web. The proposal was rejected on the grounds that the proposal conflicted with the previously chosen direction for the Web's evolution. Active voice would be more forceful and possibly more accurate here. The choice of the passive voice was intentional here, to avoid making this paragraph about who was involved, but instead keeping it about the work. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Editorial, section 1.5
On Wed, 5 Aug 2009, Elliotte Rusty Harold wrote: I suggest simply deleting It must be admitted that many aspects of HTML appear at first glance to be nonsensical and inconsistent. I would disagree with nonsensical, and in any case this sentence adds nothing to the text. However if this sentence is retained, at least deleted It must be admitted that in favor of simply Many aspects of HTML appear at first glance to be nonsensical and inconsistent or better yet Many aspects of HTML appear at first glance to be inconsistent or even Many aspects of HTML are inconsistent. If any part of this sentence is retained, it should be combined with the following paragraph. In fact, the first 3 paragraphs could likely be combined. Could you elaborate on your reasoning? At first blush, the current text seems better than what you are suggesting, but maybe I am missing something. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Editorial section 1.5.1 serialising
On Wed, 5 Aug 2009, Elliotte Rusty Harold wrote: completely serialising the execution of all scripts. -- serializing (i.e. use the American spelling used throughout the rest of the document.) Thanks. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] object behavior
On Thu, 6 Aug 2009, Andrew Oakley wrote: The rules in the HTML5 spec for which plugin to load for an object do not seem to be followed by any browser, and in some cases are different to behavior that is common to Opera, Webkit and Gecko (I haven't tested with IE due to its lack of nsplugin support). Most notably HTML5 says that the Content-Type header is used in preference to the type attribute, whereas the browsers seem to honour the attribute in preference to the header. (If the spec is changed to match the browsers behaviour then the conditions on when to load a new plugin also need to be changed.) HTML5 also seems to prefer the type attribute on scripts rather than the Content-Type header. Detaching and reattaching a object from the document seems to make the browsers destroy the object and then recreate it. Presumably this means that the DOM objects also change depending on whether or not an object is attached to the document (haven't confirmed that this is the case). Changing the attributes on an object that is attached to the document doesn't seem to work - Webkit does nothing, Opera seems to stop scripting (presumably some kind of error), Firefox reloads the plugin in some cases (even if its not the right one anymore). Removing an object from the document (browsers destroy plugin object), changing the attributes and reattaching it to the document (browser creates plugin object) seems to work fairly reliably across browsers. In effect it seems that browsers use the attributes that were on the object when it was attached to the document, and do not respond to changes in the attributes. The test cases I used are available at http://ado.is-a-geek.net/~andrew/pluginstest.tar.bz2 (sorry they are somewhat linux based due to the platform specific plugins). In summary I have a few questions related to objects: - Should the type attribute take precedence over the Content-Type header? No, I believe what the spec says here is the preferred behaviour. Unless this is incompatible with legacy content, we should try to move towards this behaviour. - Should objects exist all the time whether they are attached to the document or not? Assuming you mean the plugins, as opposed to the elements themselves, then the way the spec is written, the plugin instantiates regardless of whether it is in the document or not. - Should changing the attributes change the plugin, or should we just use the attributes when the object was attached to the document? I'm pretty sure that for compatibility with legacy content, only the type, data, and classid attributes would cause the plugin to be restarted if changed. On Thu, 6 Aug 2009, Boris Zbarsky wrote: The exact Gecko behavior is the following. 1) If the header type is application/octet-stream and the type attribute was set to something that parsed as a MIME type, use the type attribute's type. 2) If the type attribute was set to something that parsed as a MIME type, and if that type would be handled by a plug-in (that is, we have a plug-in to handle it, and have no other method for handling it), then use the type attribute's type instead of the header type. 3) In all other cases the header type is used. Step 2 above isn't what the spec says. The rest is, more or less. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Section 1.7 abstract language
On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote: This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language. The phrase abstract language concerns me. It's not clear to me that a language can be abstract, nor is it clear to me what this phrase refers to, especially since it seems to be distinguished from the concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification. Perhaps there's some sort of abstract data model or information model here; but I don't believe that the word language is appropriate to describe this. Language as normally understood is a collection of actual words or symbols, written or spoken. It is not a collection of abstract concepts, at least not in any definition of the term I was able to find. http://www.google.com/search?hl=ensafe=offq=define%3Alanguageaq=foq=aqi=g10 What term would you recommend rather than language that is more understandable than data model or information model? Would vocabulary be ok? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5: compatible with all legacy Web browsers
On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote: Section 1.7: The first such concrete syntax is HTML5. This is the format recommended for most authors. It is compatible with all legacy Web browsers. I challenge the claim that HTML5 is compatible with *all* legacy Web browsers. I can produce valid HTML 4 documents today that are not compatible with *all* legacy Web browsers. I suggest this be weakened to something like is compatible with most Web browsers still in active use today. Changed all to most. On Fri, 7 Aug 2009, Simon Pieters wrote: I guess the following is an example of a valid HTML5 document that is incompatible with legacy Web browsers: !doctype html title/title svgscript//svg pHello world/p It's certainly possible to use the language in a way that is incompatible with legacy UAs. On Fri, 7 Aug 2009, Aryeh Gregor wrote: I think the meaning of compatible with all existing browsers here is that HTML 5 does not *require* authors to break compatibility with any existing browser. Exactly. Clearer wording might be like, HTML5 pages can be written to be compatible with all legacy Web browsers. Of course, all legacy Web browsers does need to be construed to exclude Netscape Navigator 3 and such. If you really want to be picky, it could be all legacy Web browsers that still see significant use. I think just saying the language is compatible is probably clear enough. On Fri, 7 Aug 2009, Erik Vorhes wrote: I agree completely with your interpretation of the phrase. HTML5 is intended to enhance the web without breaking it, so noting (or even emphasizing) how it's backwards-compatible is important and useful. But the phrase should be clarified along similar lines to what you've articulated. Maybe: HTML5 can be written in such a way that it is compatible with all browsers made after X date? I don't think most people reading this are really going to be confused either way on this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Section 1.7 abstract language
On Thu, Aug 13, 2009 at 10:10 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote: This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language. The phrase abstract language concerns me. It's not clear to me that a language can be abstract, nor is it clear to me what this phrase refers to, especially since it seems to be distinguished from the concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification. Perhaps there's some sort of abstract data model or information model here; but I don't believe that the word language is appropriate to describe this. Language as normally understood is a collection of actual words or symbols, written or spoken. It is not a collection of abstract concepts, at least not in any definition of the term I was able to find. http://www.google.com/search?hl=ensafe=offq=define%3Alanguageaq=foq=aqi=g10 What term would you recommend rather than language that is more understandable than data model or information model? Would vocabulary be ok? -- Ian Hickson Pardon me for interjecting myself into your exchange. Rather than changing the word language, how about changing the the word abstract instead... ...to an adjective such as prescriptive or normative... in order to describe the usage of the word language more purposefully ? Just a thought. -- -- -- -- ô¿ô¬ K e V i N /¯\
Re: [whatwg] Section 1.7 editorial
On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote: The first such concrete syntax is HTML5. This is the format recommended for most authors. It is compatible with all legacy Web browsers. If a document is transmitted with the MIME type text/html, then it will be processed as an HTML5 document by Web browsers. The second concrete syntax uses XML, and is known as XHTML5. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is processed by an XML processor by Web browsers, and treated as an XHTML5 document. The last sentence is awkward. I think making it more parallel with the previous paragraph would help. I.e. If a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it will be processed as an XHTML5 document by Web browsers. I've tried improving the paragraph. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Editorial: 1.9 DOCTYPE HTML
On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote: Section 1.9 uses this DOCTYPE twice: !DOCTYPE HTML Unless the intention is to demonstrate case-insensisitivity, which doesn't seem to be the case since that's not otherwise mentioned in this section, I think this should be: !DOCTYPE html as section 4.2 of the FAQ recommends. On Thu, 6 Aug 2009, Tab Atkins Jr. wrote: Ian has said before that he purposely writes examples in multiple styles just to ensure that the spec isn't construed as defining a single 'correct' style through them. Tab is correct, but to encourage the lowercase variant I've changed some of the examples to have the earlier section use lowercase text. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 2.1.1 (they are in the per-element partition)
On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote: I suggest deleting the parenthetical remark (they are in the per-element partition). I'm not sure what this term means. I've never encountered either partition or per-element partition in an XML namespace context before. It was a term from the first XMLNS spec: http://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-breakdown It's been removed, though, so I removed the parenthetical. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 Script Tag
On Thu, 6 Aug 2009, Cready, James wrote: Is there any good reason why a script tag with the src attribute specified can�t be self-closing? No elements in text/html can be self-closing. In the case of script in particular, allowing it would be a compatibility problem at best and a security risk at worst due to differing handling in legacy UAs. On Thu, 6 Aug 2009, Cready, James wrote: I'm also curious as to why you're even allowed to specify an external src on a script tag. At this point, because that's what pages depend on and what browsers do. It was years too late to change that before we started HTML5. On Thu, 6 Aug 2009, Aryeh Gregor wrote: This logic says we shouldn't remove existing features that current websites depend on, but it doesn't prevent us from introducing new features to improve consistency in the long term. Authors shouldn't use the features (e.g., src= on style) as long as there are some browsers that don't support them, of course, but eventually they should be usable. It wouldn't really allow you to do anything you couldn't do already, but the same is true for plenty of HTML 5 features. Generally speaking I think we should avoid making the platform have too many redundant features, however illogical some of them might be. On Thu, 6 Aug 2009, Greg Houston wrote: This makes sense to me as well. Last week a user of my framework posted to the forums asking for help. The JavaScript was not loading, and it turned out he was trying to self-close the script tags in the header. So for at least some percentage of people the intuited expectation is that the script tag can be self-closing like the link tag. I agree that some people expect this. I don't think that making it work with exactly one element and dependent on the presence of an attribute is the way to improve this situation, however. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 2.2 editorial
On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote: Applications and tools that process HTML and XHTML documents for reasons other than to either render the documents or check them for conformance should act in accordance to the semantics of the documents that they process. 2.2 editorial in accordance to -- in accordance with Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 2.2 Performant
On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote: In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant. Yech. The recently coined word performant just grates on my ears; and I'm not the only one as a Google search will show: http://www.google.com/search?ie=UTF-8oe=UTF-8q=performant It's language evolution at work: http://en.wiktionary.org/wiki/performant Perhaps we could replace it with efficient or some other word or phrase? Efficient is more about efficient use of resources rather than about the performance of the solution. A solution might be very efficient but very slow. I guess we could use fast, but it seems rather pessimistic to call even the most naive implementation of the algorithms in the spec slow, given that we're talking about performing millions of operations per second here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Section 4.10.4.1.4 and Section 9.1.2.6
In section 4.10.4.1.4 URL state, the text reads: The input element represents a control for editing a single absolute URL given in the element's value. If the is mutable, the user agent should allow the user to change the URL represented by its value. I believe that last line should read: If the input element is mutable, ... -- ALSO, in section 9.1.2.6 Restrictions on the contents of raw text and RCDATA elements there is text that reads: An escaping text span end is a part of text that consists of the three character sequence -- (U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN) whose U+003E GREATER-THAN SIGN (). The part that reads ... whose U+003E GREATER-THAN SIGN () seems incomplete, out of place or unclear. -- -- -- -- ô¿ô¬ K e V i N /¯\
Re: [whatwg] Possible typo in application cache section
On Thu, 6 Aug 2009, Darin Adler wrote: 6.9.4, paragraph 7 says, �applications caches never include fragment identifiers� and I think this should just be �application caches�. Fixed, thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Section 4.10.4.1.4 and Section 9.1.2.6
On Fri, 14 Aug 2009, Kevin Benson wrote: In section 4.10.4.1.4 URL state, the text reads: The input element represents a control for editing a single absolute URL given in the element's value. If the is mutable, the user agent should allow the user to change the URL represented by its value. I believe that last line should read: If the input element is mutable, ... Oops. Thanks. Fixed. ALSO, in section 9.1.2.6 Restrictions on the contents of raw text and RCDATA elements there is text that reads: An escaping text span end is a part of text that consists of the three character sequence -- (U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN) whose U+003E GREATER-THAN SIGN (). The part that reads ... whose U+003E GREATER-THAN SIGN () seems incomplete, out of place or unclear. Fixed, thanks. I've no idea how the first error came to be or what I originally was going to say in the dangling clause in the second. :-) Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
