Re: [whatwg] window.status and window.defaultStatus
On 07/25/2011 05:30 AM, Bjartur Thorlacius wrote: Are JavaScript implementors willing to reimplement window.status? There are obvious security problems with drawing an author-provided string where a certain URI is expected, but could window.defaultStatus not set the name (_NET_WM_NAME or equivalent) of the script's window and window.status either override window.defaultStatus temporarily, or sent to the user, e.g. through Growl or as a Windows toast. The window name is already accessible to scripts (by modifying the text child of title through the DOM) so no new security concerns are introduced. The Growl binding might well be better by a new function, though. If you want OS-level notifications you might be interested in [1] [1] http://dev.w3.org/2006/webapi/WebNotifications/
Re: [whatwg] Physical quantities: var or i?
On Thu, 14 Apr 2011, Jukka K. Korpela wrote: Looking at the nice summary (with examples) of text-level markup at http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#usage-summary I started wondering why there is no example of markup for symbols of physical quantities. The descriptions of individual elements or their examples don't seem to say anything about this either. The main reason is that most of these symbols have Unicode characters and don't need special markup. So what markup should we use for E = mc�, given that by the applicable standards, E, M, and c should appear in italics and the other characters as normal (upright)? It sounds like you want to use these characters: U+1D438 MATHEMATICAL ITALIC CAPITAL E U+1D45A MATHEMATICAL ITALIC SMALL M U+1D450 MATHEMATICAL ITALIC SMALL C Alternatively, you can use MathML to mark up the equation. Physical quantities surely satisfy the requirement that typical typographic presentation is italicized in the following, and they are to be offset from the normal prose, but why aren't they mentioned in the fairly long list of examples then: The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name in Western texts, or some other prose whose typical typographic presentation is italicized. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-i-element (As an aside, the wording a taxonomic designation is too broad, as by biological nomenclature rules, genus and species names are to be italiced but higher taxons, e.g. family names, like Canidae, must not. Besides, e.g. an English name of a species is taxonomic too... So scientific names of organisms would be a better formulation.) Whether you want something in italics or not is more a matter for CSS than a matter for HTML. Should we consider the var element as covering physical quantities too? After all, they can be regarded as variables in a broad sense, as symbols that denote different values in different situations. However, varc/var would be odd, wouldn't it, since the symbol denotes a universal constant of nature. You can look at it as being a variable whose value is a constant of nature. I've clarified the spec to indicate that this is fine. On Thu, 14 Apr 2011, Bjartur Thorlacius wrote: Well, a constant isn't really variable any more, is it? I thought var was meant to mark up text that couldn't simply be 'copypasted' without filling in the unknowns (free variables). Defined variables (whether in source code or formulae) do not conform to that definition. So, coderm -r var$path/var/code would conform (as a reply to the question how does one remove a (potentially non-empty) directory on *nix?) as $path is undefined, but codevari/var++/code would not, as i isn't ment to be substituted. What do you base this interpretation on? On Sat, 16 Apr 2011, Jukka K. Korpela wrote: Besides, there is no implied uniform rendering for variables in the current broad meaning for var. In mathematics, variables are conventionally written in italics. But the HTML(5) notion of variable is wider: The var element represents a variable. This could be an actual variable in a mathematical expression or programming context, or it could just be a term used as a placeholder in prose. A programming language variable is something that is _not_ conventionally rendered in italics. Rather, they are usually (though for no really good reason) rendered in a monospace font, like any other expressions in computer languages. Indeed. And vectors are usually bold. This is the kind of thing I would expect to see handled using classes, e.g.: var class=vectora/var #x2A2F; var class=vectorb/var = vara/var varb/var sin vartheta;/var var class=vectorn/var Too bad there's no example of var used in programming context. The current wording suggests that it would be normal, when discussing programming, to write, say, Then we define the variable varmyFoo/var of type codefooType/code with initial value codeFoo/code - -, which really makes no sense, even if we use both var and code for myFoo. Why does it make no sense? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Page displayed during/after download (meta refresh downloads)
Þann fös 22.júl 2011 23:09, skrifaði Kornel Lesiński: 2. Allow website to show additional information about the download, while the download is taking place. And to satisfy all three cases (without breaking links), it needs to be done at HTTP level, by adding HTTP header (or multipart response? or attribute to Content-Disposition?) that causes both file download to start and a page to be displayed at the same time. Sending multiple responses in reply to a single request is generally useful, but seems hard to implement in a fashion compatible with HTTP pipelining clients. How about a JavaScript opening a new browsing context and navigating it to the additional metainformation when the user follows the link?
[whatwg] When initializing a JS URL object, do we handle the case of 0 argument?
(Referenced from Adam Barth's document: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en) The incoming arguments plainURL and baseURL are optional. The question is, when there is no argument provided, do we return an error or treat it normally, then assign the URL later? If so, which interface do we use to assign the URL? href? Thanks! Shawn Gong
Re: [whatwg] When initializing a JS URL object, do we handle the case of 0 argument?
I've made the first URL non-optional. Thanks, Adam On Mon, Jul 25, 2011 at 4:00 PM, Shawn Gong sh...@mozilla.com wrote: (Referenced from Adam Barth's document: https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en) The incoming arguments plainURL and baseURL are optional. The question is, when there is no argument provided, do we return an error or treat it normally, then assign the URL later? If so, which interface do we use to assign the URL? href? Thanks! Shawn Gong
Re: [whatwg] Proposal to extend registerProtocolHandler
Hi Ian, Here are the use cases I had in mind: 1. Allow sites to conditionally show UI to promote the advantages of registering the site as a handler. (requires isRegistered) 2. Allow sites to provide settings screens which allow users to register / deregister handlers from within the site. (requires isRegistered, and deregisterProtocolHandler) The presence of an ignored list - sites who don't have permission to use registerProtocolHandler - necessitates Michael Davidson's suggestion that isRegistered() should return a tri-state value (REGISTERED, DECLINED, NOTASKED). Otherwise sites that have been 'ignored' by a user won't be able to tell if they should show their promotional UI or not. Cheers, James On Sat, Jul 23, 2011 at 8:33 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 21 Apr 2011, James Kozianski wrote: I'd like to propose the following changes to the registerProtocolHandler spec. [...] Before I study the proposals in detail, is there a description of the kind of experience we're trying to enable here? What are the UIs we expect to see page use wih registerProtocolHandler()? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] PeerConnection, MediaStream, getUserMedia(), and other feedback
On Thu, 14 Jul 2011, Shwetank Dixit wrote: On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson i...@hixie.ch wrote: Another question is flash. As far as I have seen, there seems to be no option to specify whether the camera needs to use flash or not. Is this decision left up to the device? (If someone is making an app which is just clicking a picture of the person, then it would be nice to have the camera use flash in low light conditions). getUserMedia() returns a video stream, so it wouldn't use a flash. Wouldn't it make sense to have a provision for flash separately then? I think a lot of apps would like just a picture instead of video, and in those cases, flash would be required. Maybe a seperate provision in the spec which defines whether to use flash, and if so, for how many miliseconds. Is that doable? In response to getUserMedia()? I don't really understand how that would work. Could you elaborate? How do you envisage the API working? Maybe a concrete example would help. I'm particularly concerned about two things: preventing hostile sites from abusing a flash feature to troll the user, and preventing well-meaning but poorly designed sites from using the flash when the user doesn't want it to (e.g. when taking a photograph in an area where a flash isn't desired). On Thu, 14 Jul 2011, timeless wrote: I'd expect a web app to have no idea about device camera specifications and thus to not be able to properly specify a flash duration. I don't see how such a thing is valuable. If a user is in a movie theater, or a museum, it's quite likely they won't notice a web app is forcing a flash. Let the user control flash through a useragent only or host application only mode. I believe the hazards of exposing flash duration outweigh any benefits. The only application class I know of built using control of camera flash is flash-light, and that's both a hack and not guaranteed to be workable for all possible flash technologies. Right. On Fri, 15 Jul 2011, Shwetank Dixit wrote: Just like, just allowing the web app to use the camera as it is will not make sense, and presumably, user agents will implement a authorization by the user before the app gains access to the camera (something like 'This application requests access to the camera. Allow for now/Always Allow/Never Allow/Close' just like you do in geolocation right now) ... just like that, you could do it for flash, where the app only gains access to it if the user allows it. If that is the implementation, i do not think there would be much hazards in allowing flash access. This is quickly going to get frustrating to the user. In general, we'd rather not have any such prompts. For example, for video, well-designed browsers are likely not going to have a yes/no prompt, instead they'll just have a prompt that asks the user what camera they want to use. This is far less frustrating to the user. Apart from helping capture images/video in low light conditions, there are a few other use cases for flash such as the flash light thing you mentioned, as well as a possible S.O.S type app. I'm fine if the consensus is that the device/user agent will handle the issue of flash by showing some sort of control where the user can click between 'flash on/off/auto'. That will cover *most* of the use cases, which is recording images/video in low light conditions. If so, then it might be good to specify that somewhere in the spec just to make things a bit clearer? Ok, done. On Tue, 19 Jul 2011, Per-Erik Brodin wrote: Perhaps now that there is no longer any relation to tracks on the media elements we could also change Track to something else, maybe Component. I have had people complaining to me that Track is not really a good name here. I'm happy to change the name if there's a better one. I'm not sure Component is any better than Track though. Good. Could we still keep audio and video in separate lists though? It makes it easier to check the number of audio or video components and you can avoid loops that have to check the kind for each iteration if you only want to operate on one media type. Well in most (almost all?) cases, there'll be at most one audio track and at most one video track, which is why I didn't put them in separate lists. What use cases did you have in mind where there would be enough tracks that it would be better for them to be separate lists? I also think that it would be easier to construct new MediaStream objects from individual components rather than temporarily disabling the ones you do not want to copy to the new MediaStream object and then re-enabling them again afterwards. Re-enabling them afterwards would re-include them in the copies, too. The main use case here is temporarily disabling a video or audio track in a video conference. I don't understand how your proposal would work for that. Can you
