Re: [whatwg] need a way to set output format from StreamRecorder
On Thu, Nov 25, 2010 at 6:37 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Silvia Pfeiffer silviapfeiff...@gmail.com schrieb am Thu, 25 Nov 2010 14:05:18 +1100: Can the decision for a file format be taken completely separately from the codec decision for the audio or video element, I wonder? I believe the royalties for encoders are usually higher than the royalties for decoders (where royalties apply, that is: with proprietary standards). Also, I doubt that any self-respecting entities opposed to the implementation of decoders for certain royalty-free A/V formats would include the corresponding encoders — the risk being that more content would be created in formats that their own browsers could not render. Naturally a browser that doesn't decode MPEG-4 would not implement MPEG-4 encoding. Apple probably already pay the max royalties for MPEG-4, so they probably won't worry about MPEG-4 encoding support in Safari. Also, implementing WebM or Ogg Theora encoding is just as royalty-free as decoding them, so Mozilla, Opera and Google wouldn't need to worry there. So, the browsers would implement support for those codecs for which they already implement decoding support - maybe with the exception of Chrome which decode MPEG-4, but may not want to encode it, since it might mean extra royalties. It would be nice if we could all, say, encode WebM, but I don't see that happening. Cheers, Silvia.
[whatwg] Session Management
Hi Subscribers, I am not sure if I am at the right mailing list for this. But I was wondering if it would be beneficial to have some kind of session control feature in the Web Applications spec. Currently the spec defines sessionStorage which I think is a great. It allows me to stop using cookies and maintaining session state completely in the browser. However I am still faced with the fact that there is no way to clear the HTTP authentication credentials cache. I prefer to use HTTP authentication mostly as it is build-in anyways and has richer features then pure form-based authentication. The only problem is that you can't clear credentials when a session is terminated. So I am wondering whether some kind of session control that is somewhat broader then just clearing sessionStorage could be included into the standard. Personally I would imagine such a API existing out of just two functions: a start and a terminate function. After an session has started all credentials cached for HTTP authentication and everything stored in sessionStorage and all cookies without explicit expiration created, would all be destroyed when the terminate function is called or when the user navigates away from the origin in the top-browser context. Using such a method would give a web application developer just the right amount of control and would allow the implementation of a logout button that actually works. Currently it is possible the clean out sessionStorage and destroy cookies but not to clear cached credentials for HTTP authentication. Possibly the start function could also accept a path argument to specify just a sub area of the origin on which the session is valid. This would allow more fine-grained control. Please note that the session would be specific to the top-browser context. Also HTTP authentication credentials belonging to the current session should not be limited to just credentials cached for the top-browser context origin but all credentials cached. This should also be the case for sessionStorage and cookies without expiration specified. As for backwards-compatibility since the feature requires a developer to call a function to make use of it. It would not impact current web applications and thus would be fully backwards-compatible. A developer must already know about the feature to use it. So I would expect that such a consideration would not be an obstacle. I would be interested to know if such a feature would be worth considering. Looking forward to comments and possibly a discussion. Regards, Dave Kok
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, Nov 25, 2010 at 3:30 AM, Nils Dagsson Moskopp 1. Can we deprecate alert(), confirm(), prompt() ? If sites rely on them, it is not possible to deprecate them. That is why I asked to deprecate, but not obsolete.. However, I melieve browsers are making these dialogs tab-modal. Yes I know but still there are problems https://bugzilla.mozilla.org/show_bug.cgi?id=613800#c1 (I assume that will be fixed) But see also https://bugzilla.mozilla.org/show_bug.cgi?id=391834 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. “Do you want to save your complicated mashup?” For that we dont need alert/confirm/prompt. Return value in onbeforeunload will take care of it You may want to also look Jesse Ruderman suggestion on that https://bugzilla.mozilla.org/show_bug.cgi?id=578828 3. also if we are keeping them, can we add an optional parameter for a timeout milliseconds to self dismiss the modal prompt. Why would you need that? This is especially useful with alert() In a software application there is no need to have prompt to the user if the application is not planning to do any branching after user response. When we have alert(), it dont give user any choice other than pressing OK Hence it not possible to code any branching statement after result of user action. (with exception Press OK after you insert DVD to the drive ) So only use for alert() I see is not make a delay, that use case can be improved if web programmer can provide a default time out. On Thu, Nov 25, 2010 at 3:41 AM, a...@ashleysheridan.co.uk a...@ashleysheridan.co.uk wrote: Modal dialogues have a very special purpose, which works consistently across various browsers in that we can program in with javascript some very specific responses. What would happen if someone came to your site with a speech/Braille browser? How would they know your pretty js lib built That is a valid point. But how many good sites use alert/confirm/prompt for every thing. So all those case speech/Braille browser have problem to deal with. If we want use that feature the web site need to code their site for speech/Braille browser. If that is the case we could achieve same thing with HTML.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On 11/25/2010 08:30 AM, ext Nils Dagsson Moskopp wrote: Bijubijumaill...@gmail.com schrieb am Thu, 25 Nov 2010 02:29:31 1. Can we deprecate alert(), confirm(), prompt() ? At present many web2.0 js libs are providing alternate [and cool looking] methods to achieve use cases where we need to use alert(), confirm(), prompt(). So do we need those modal dialogs any longer? If sites rely on them, it is not possible to deprecate them. The specification deprecates some elements that use to be widely used (the elements font, big, center, etc). Deprecating is only a recommendation for authors to not use the feature. I would personally welcome a better alternative to alert(), confirm(), prompt(). Something explicitly page modal and not pseudo-blocking Javascript. Although in my opinion, it would not make sense to deprecate without a good alternative for modal dialogs. cheers, Benjamin
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, Nov 25, 2010 at 8:26 AM, Benjamin Poulain Although in my opinion, it would not make sense to deprecate without a good alternative for modal dialogs. But how many good sites use it. Only place in GMail is when user try to send mail with no text in Subject or Body field. Which they will be able to rewrite with the same way they do for blank To/cc/bcc address field.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
Am 25.11.2010 13:21 schrieb Biju: On Thu, Nov 25, 2010 at 3:41 AM, a...@ashleysheridan.co.uk a...@ashleysheridan.co.uk wrote: Modal dialogues have a very special purpose, which works consistently across various browsers in that we can program in with javascript some very specific responses. What would happen if someone came to your site with a speech/Braille browser? How would they know your pretty js lib built That is a valid point. But how many good sites use alert/confirm/prompt for every thing. So all those case speech/Braille browser have problem to deal with. If we want use that feature the web site need to code their site for speech/Braille browser. If that is the case we could achieve same thing with HTML. Maybe, instead of your original suggestion, it might be worth thinking about making alert()/confirm()/prompt() dialogs styleable via CSS? Then those fancy JS lib dialogs would get obsolete, and we had the favour of both nice look and support for the special purposes of those dialogs.
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
Am 24.11.2010 um 23:59 schrieb Charles Pritchard: There is evidence that it will enhance usability for programmers who use it properly. Focus. -Charles Do you mean functionality rather than usability? As I understand this, an author of a web page has neither control of nor knowledge about the status of the browser's zoom function (yet). And I don't think you can enhance usability of something that doesn't exist. What you desire seems to be a change of functionality. I am aware of two different existing types of zoom functions: (1) Zoom functions implemented by web page authors, e.g. at OpenStreetMaps and other geo services. Even if they don't use canvas, the same is also possible with canvas. Web page authors already have complete control and knowledge about this kind of zoom function and its status. (2) The browsers' build-in zoom function, which web page authors have no control or information about. I'm happy about both these solutions and their separation. As a web page author I can create the zooming experience that I consider best for my users. And my users can use it. But as a user I can also use my browser's zoom function which simply makes things bigger without the web page author interfering or knowing. It works the same way for every web page I apply it to. (1) and (2) serve different purposes. For example, there's a big difference between zooming into a map with its author provided zoom feature – which usually leads to *more* details about the central part of the map – and zooming the map with the browser's build-in function – this makes the focused details bigger, usually reducing the total amount of information displayed on the screen (by cutting the non-central parts of the map *without* adding new information). I am convinced that giving the web page author the power to interfere with option (2) in addition to her/him already having the power to create almost any zooming experiences she/he likes with strategy (1) would be hardly beneficial to users. Even if used with best intentions by authors, it will disturb enough users' desired experience, as it reduces user controlled functionality. It turns a function that the user expects to work for every webpage the same into something that does not. It would make option (2) become just another author controlled option (1.b). Regards, Martin
Re: [whatwg] Javascript: URLs as element attributes
On Tue, 16 Nov 2010 02:15:45 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Aug 2010, Boris Zbarsky wrote: For what it's worth, as I see it there are three possible behaviors for a javascript: URI (whether in an attribute value or elsewhere): 1) Don't run the script. 2) Run the script, but in a sandbox. 3) Run the script against some Window object (which one?) Defining which of these happens in which case would be good. Again, Gecko's behavior is #2 by default (in all sorts of situations; basically anywhere you can dereference a URI), with exceptions made to do #3 in some cases. That's what the spec says currently. I've recently had reason to dabble with inline javascript: URLs in Opera, trying to figure out what the interoperability constraints are. Opera's current behavior is to execute javascript: URLs except for in the context of img, embed, applet and any inline loads from CSS. Before I was aware of this thread, I went through the different kinds of contexts where we do allow javascript: to execute, comparing to other browsers. The results: video poster=javascript:... only executed by Opera script src=javascript:... only executed by Opera bgsound src=javascript:... only executed by Opera object data=javascript:... only executed by Opera and Firefox (I haven't looked at iframe, as we don't treat that as an inline load in the same way as the above.) Based on this, unless there are corner-cases I've missed, it seems unlikely that there's a large body of web content that depends on inline javascript: URLs executing. My current plan is to try completely blocking javascript: URLs in the contexts mentioned above. This seems to be the simplest to implement and the fastest way to reach interoperability. The alternative is to start executing javascript: URLs in more contexts, which, even if sandboxed, doesn't seem particularly useful. I'll keep you posted if there are any compatibility issues that come up with this. Assuming (boldly) there is not, would there be support from other browsers to move in this direction and change the spec to match? (It seems that IE and WebKit are already basically already doing what I'm advocating.) -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, Nov 25, 2010 at 1:45 PM, Markus Ernst derer...@gmx.ch wrote: Maybe, instead of your original suggestion, it might be worth thinking about making alert()/confirm()/prompt() dialogs styleable via CSS? Then those fancy JS lib dialogs would get obsolete, and we had the favour of both nice look and support for the special purposes of those dialogs. Hear, hear. I really like those dialogs, they are very easy and nice to use. However, Internet Explorer doesn't support prompt(), which is incredible irritating and infuriating. So I had to implement one of those js-libs instead, and tell you what? That was NOT a nice experience, I tried many different ones, none were as easy and to-the-point as just the nice prompt(). -- Beste helsing, Odin Hørthe Omdal odin.om...@gmail.com http://velmont.no
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, Nov 25, 2010 at 8:45 AM, Markus Ernst Maybe, instead of your original suggestion, it might be worth thinking about making alert()/confirm()/prompt() dialogs styleable via CSS? Then those fancy JS lib dialogs would get obsolete, and we had the favour of both nice look and support for the special purposes of those dialogs. The request I put is NOT about whether you can make it PRETTY looking or not. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On 25.11.2010 15:55, Biju wrote: The request I put is NOT about whether you can make it PRETTY looking or not. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction. Well, you just said it: Bug 59314! That alert()s, prompt()s and confirm()s are window-modal is only an implementation issue: Some years ago browsers implemented these prompts the most convenient way: By opening a native modal dialog. But right now broswer vendors realize that this isn't really the best solution - because of DOS attacks and simply because it doesn't make any sense. And as you already mentioned: Firefox landed tab-modal dialogs a few days ago. Opera already had them. Other browsers will follow. So, what is your issue?
Re: [whatwg] Clarification request on Server-Sent Events Last-Event-ID
On Fri, 12 Nov 2010 23:53:51 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: Just a quick question about the Last-Event-ID header. The spec currently says: If the event source's last event ID string is not the empty string, then a Last-Event-ID HTTP header must be included with the request, whose value is the value of the event source's last event ID string, encoded as UTF-8. Consider the following scenario: a connection is established and one of the events has an id of foo, so the last event ID of the event source is now foo. The connection drops and on reconnect, the header Last-Event-ID: foo is sent per the spec. The next stream of events coming through do not have any IDs. The connection is dropped again. The question is whether or not Last-Event-ID: foo should be sent a second time? Technically, it is the last event ID of the event source, and the spec never mentions resetting the last event ID outside of an empty id field in the stream. WebKit and Opera both match the specification here. I have added a testcase for this behavior: http://tc.labs.opera.com/apis/EventSource/format-field-id-2.htm You can get the source code for the tests here: http://tc.labs.opera.com/svn If you want to contribute more tests following this style. Let me know! -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] whatwg Digest, Vol 80, Issue 47
On 11/25/2010 8:19 AM, whatwg-requ...@lists.whatwg.org wrote: Message: 3 Date: Thu, 25 Nov 2010 14:18:49 +0100 From: Martin Janeckewhatwg@kaor.in To: whatwgwhatwg@lists.whatwg.org Subject: Re: [whatwg] Processing the zoom level - MS extensions to window.screen Message-ID:cb2e4340-4a65-41de-bca9-3e02084ff...@kaor.in Content-Type: text/plain; charset=windows-1252 Am 24.11.2010 um 23:59 schrieb Charles Pritchard: There is evidence that it will enhance usability for programmers who use it properly. Focus. -Charles Do you mean functionality rather than usability? As I understand this, an author of a web page has neither control of nor knowledge about the status of the browser's zoom function (yet). And I don't think you can enhance usability of something that doesn't exist. What you desire seems to be a change of functionality. It would enhance usability for the users; by exposing functionality to the programmers. I am aware of two different existing types of zoom functions: (1) Zoom functions implemented by web page authors, e.g. at OpenStreetMaps and other geo services. Even if they don't use canvas, the same is also possible with canvas. Web page authors already have complete control and knowledge about this kind of zoom function and its status. SVG-style pan and zoom is completely irrelevant to the browser zoom semantics I'm bringing up. That said, they're very much available in the SVG specs. (2) The browsers' build-in zoom function, which web page authors have no control or information about. They have information about it, in many browsers, and they receive events related to window.innerWidth and innerHeight. I'm happy about both these solutions and their separation. As a web page author I can create the zooming experience that I consider best for my users. And my users can use it. But as a user I can also use my browser's zoom function which simply makes things bigger without the web page author interfering or knowing. It works the same way for every web page I apply it to. (1) and (2) serve different purposes. Author knows, most just don't use it. Yes, they serve different purposes: your example doesn't take into account any of the use cases I've put forward. For example, there's a big difference between zooming into a map with its author provided zoom feature ? which usually leads to*more* details about the central part of the map ? and zooming the map with the browser's build-in function ? this makes the focused details bigger, usually reducing the total amount of information displayed on the screen (by cutting the non-central parts of the map*without* adding new information). I am convinced that giving the web page author the power to interfere with option (2) in addition to her/him already having the power to create almost any zooming experiences she/he likes with strategy (1) would be hardly beneficial to users. Even if used with best intentions by authors, it will disturb enough users' desired experience, as it reduces user controlled functionality. It turns a function that the user expects to work for every webpage the same into something that does not. It would make option (2) become just another author controlled option (1.b). Authors have that ability if they create a UA extension; and I like the separation as well. Once again, you, as many in the list, have taken a very simple use case, and generalized it into a straw man argument. If you'd stick to my use case, instead of coming up with imaginary problems, I think we might have a discussion on merits. I've not asked for a single semantic of zoom to be altered. I've stated quite clearly, repeatedly, that I need to control the pixel depth of bitmap data, so that zoom does not result in an unnecessarily blurry image. 1. blurry image != good. 2. Sharp image good. 3. Sharp image != disturbed users. Please, could we stop with the generalizations. I would like to focus squarely on facts, and technology, not on the fallibility of the masses. If a web author wants to abuse existing apis, through any reason, they're perfectly able to do that. Consider authors who use massive amounts of image tags instead of proper CSS... Or ones who use iframes and popups unnecessarily... Their poor decisions should not restrict the rest of us to the lowest common denominator. This information is already exposed on mobile phones, its already exposed in IE: you're imagining scenarios that don't match existing reality. I've gotten the impression on this list that you all would rather have not had the scripting environment available at all to web authors. It's a false premise: given even the most complete of CSS+SVG profiles, web authors are free to make their content inaccessible. And their audience, or their customers, are free to complain that they should fix it. This is the free market. I am coming here, to this list, to state very plainly, that I have an
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
Am 25.11.2010 17:12 schrieb Nikita Popov: On 25.11.2010 15:55, Biju wrote: The request I put is NOT about whether you can make it PRETTY looking or not. Sorry, that was how I understood point 1 your initial message. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction. Well, you just said it: Bug 59314! That alert()s, prompt()s and confirm()s are window-modal is only an implementation issue: Some years ago browsers implemented these prompts the most convenient way: By opening a native modal dialog. But right now broswer vendors realize that this isn't really the best solution - because of DOS attacks and simply because it doesn't make any sense. And as you already mentioned: Firefox landed tab-modal dialogs a few days ago. Opera already had them. Opera even provided a Stop executing scripts checkbox in the alert() dialog for years already, which made it my preferred browser for debugging my scripts (handy if you have forgotten an i++ in a loop, and placed an alert() inside).
Re: [whatwg] Server-Sent Events parsing issue
On Thu, 14 Oct 2010 14:23:41 +0200, ATSUSHI TAKAYAMA taka.atsu...@googlemail.com wrote: On Wed, Oct 13, 2010 at 10:00 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 12 Oct 2010 06:41:59 +0200, ATSUSHI TAKAYAMA taka.atsu...@googlemail.com wrote: It's a minor error in the spec in the Server-Sent Events spec. http://dev.w3.org/html5/eventsource/#event-stream-interpretation When processing a line with only data:, the data buffer will be the empty string and the LF character added at the process the field stage. When dispatching the event, the first step If the data buffer is an empty string, set the data buffer and the event name buffer to the empty string and abort these steps. does not apply here (since we have the LF character, which will be removed in the step 2). So it does fire a MessageEvent with an empty string as the data property. I think the steps 1 and 2 of the dispatching should be the other way round. Why would we not want to dispatch an event where data is the empty string in this case? I do not think this is an error. (Although admittedly I once thought it was.) Well, in that case the example should be re-written: = http://dev.w3.org/html5/eventsource/#event-stream-interpretation The following stream fires just one event: data data data data: The first and last blocks do nothing, since they do not contain any actual data (the data buffer remains at the empty string, and so nothing gets dispatched). The middle block fires an event with the data set to a single newline character. Maybe you are right and the specification is wrong (and the example is correct). http://tc.labs.opera.com/apis/EventSource/format-field-data.htm (this is written against the example; passes in Opera, fails in WebKit) I don't really mind which way we go here I think. = up to here It's slightly out of topic, but what's the idea behind making a line without a semicolon make the whole line the field? The 3 out of 4 possible field names, event, id and retry make no sense without the value. Also data line without any message seems useless to me, and even if you do want it without a message data: does the job. Maybe this should be tightened up indeed. I can update the test suite either way. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Server-Sent Events parsing issue
On Thu, Nov 25, 2010 at 11:55 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 14 Oct 2010 14:23:41 +0200, ATSUSHI TAKAYAMA taka.atsu...@googlemail.com wrote: On Wed, Oct 13, 2010 at 10:00 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 12 Oct 2010 06:41:59 +0200, ATSUSHI TAKAYAMA taka.atsu...@googlemail.com wrote: It's a minor error in the spec in the Server-Sent Events spec. http://dev.w3.org/html5/eventsource/#event-stream-interpretation When processing a line with only data:, the data buffer will be the empty string and the LF character added at the process the field stage. When dispatching the event, the first step If the data buffer is an empty string, set the data buffer and the event name buffer to the empty string and abort these steps. does not apply here (since we have the LF character, which will be removed in the step 2). So it does fire a MessageEvent with an empty string as the data property. I think the steps 1 and 2 of the dispatching should be the other way round. Why would we not want to dispatch an event where data is the empty string in this case? I do not think this is an error. (Although admittedly I once thought it was.) Well, in that case the example should be re-written: = http://dev.w3.org/html5/eventsource/#event-stream-interpretation The following stream fires just one event: data data data data: The first and last blocks do nothing, since they do not contain any actual data (the data buffer remains at the empty string, and so nothing gets dispatched). The middle block fires an event with the data set to a single newline character. Maybe you are right and the specification is wrong (and the example is correct). http://tc.labs.opera.com/apis/EventSource/format-field-data.htm (this is written against the example; passes in Opera, fails in WebKit) I don't really mind which way we go here I think. = up to here It's slightly out of topic, but what's the idea behind making a line without a semicolon make the whole line the field? The 3 out of 4 possible field names, event, id and retry make no sense without the value. Also data line without any message seems useless to me, and even if you do want it without a message data: does the job. Maybe this should be tightened up indeed. I can update the test suite either way. -- Anne van Kesteren http://annevankesteren.nl/ I would say the simpler the rule is, the better. So a line without colon should be ignored. Also for the example in the spec; -a single data: line followed by an empty line should fire a message event with an empty string data, and -two data: lines followed by an empty line should fire a message event with an LF as data (push every line followed by an LF, then remove the last LF and fire it) A TAKAYAMA
Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?
On Tue, 23 Nov 2010 23:09:40 +0100, Philip Taylor excors+wha...@gmail.com wrote: On Tue, Nov 23, 2010 at 8:43 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Right now, canvas gradients interpolate their colors in non-premultiplied space; that is, the raw values of r, g, b, and a are interpolated independently. This has the unfortunate effect that colors darken as they transition to transparent, as transparent is defined as rgba(0,0,0,0), a transparent black. Under this scheme, the color halfway between yellow and transparent is rgba(127,127,0,.5), a partially-transparent dark yellow, rather than rgba(255,255,0,.5).* If you define the gradient as interpolating from solid yellow to transparent black, I'd expect that it *should* be semi-transparent blackish-yellow in the middle. If you want it to be pure yellow, don't use a keyword which is explicitly specified as transparent black - define the gradient from rgba(255,255,0,1) to rgba(255,255,0,0) instead. Then you'll get rgba(255,255,0,0.5) in the middle. The rest of the platform has switched to using premultiplied colors for interpolation, because they react better in cases like this**. CSS transitions and CSS gradients now explicitly use premultiplied colors, and SVG ends up interpolating similarly (they don't quite have the same problem - they track opacity separate from color, so transitioning from color:yellow;opacity:1 to color:yellow;opacity:0 gives you color:yellow;opacity:.5 in the middle, which is the moral equivalent of rgba(255,255,0,.5)). That sounds like SVG gradients *can't* be using premultiplied colours. A transition from color:yellow;opacity:1 to color:black;opacity:0 will have rgba(127,127,0,0.5) in the middle, and it's impossible to get that if you are using premultiplied colours. You'd have to have A=1 at the start and A=0 at the end, so (with premultiplied colour) the end would be interpreted as rgba(0,0,0,0), so you'd get the same as interpolating to color:yellow;opacity:0 (i.e. rgba(255,255,0,0.5) in the middle), which is not what SVG does. http://www.w3.org/TR/SVGTiny12/painting.html#Gradients says explicitly its behaviour is the non-premultiplied behaviour we currently get with canvas. (gradient from fully transparent red, via partly transparent dark yellow, to fully opaque lime - the RGB components of fully transparent colours are preserved.) Maybe CSS should have originally used the keyword transparentblack instead of transparent (though the distinction didn't matter before gradients existed) - changing the gradient algorithm solely to work more intuitively when people happen to use that one particular incorrectly-named keyword seems backwards, and a mistake in CSS. (Perhaps CSS gradients could avoid this problem by overriding the meaning of the transparent keyword, so that instead of rgba(0,0,0,0) it means A=0 with the mean RGB of the adjacent colour stops. That would let it work as people naturally expect when they use that keyword, and they can use the rgba() syntax if they really want transparent black or transparent yellow or transparent red etc.) The people at Opera responsible for the graphics layer agree with Philip's point of view. They also pointed out we do support rgba() in SVG. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Server-Sent Events parsing issue
On Thu, 25 Nov 2010 18:21:35 +0100, ATSUSHI TAKAYAMA taka.atsu...@googlemail.com wrote: I would say the simpler the rule is, the better. So a line without colon should be ignored. Also for the example in the spec; -a single data: line followed by an empty line should fire a message event with an empty string data, and -two data: lines followed by an empty line should fire a message event with an LF as data (push every line followed by an LF, then remove the last LF and fire it) That works for me. Hixie? People from WebKit? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] whatwg Digest, Vol 80, Issue 47 | previously: Processing the zoom level - MS extensions to window.screen
Am 25.11.2010 um 17:41 schrieb Charles Pritchard: (2) The browsers' build-in zoom function, which web page authors have no control or information about. They have information about it, in many browsers, and they receive events related to window.innerWidth and innerHeight. Well, an author cannot conclude safely from these changes that the browser's zoom function has been used, can he? Once again, you, as many in the list, have taken a very simple use case, and generalized it into a straw man argument. It's not a straw man argument if the problems discussed actually follow from your proposal – even if your wish is very different from creating these problems. I don't think people doubt your good intentions. I'm not saying you want to disturb users or misuse the browser's zoom function for something different from what it is intended for. I'm against those consequences of your proposal which you do not intend yourself. Am I wrong and these problems cannot occur? Then it's a straw man argument. Otherwise it's not. 1. blurry image != good. 2. Sharp image good. 3. Sharp image != disturbed users. Actually, some visually impaired users are disturbed by sharp contrasts. I have a friend who is. It's something with the cornea being uneven, leading him to see multiple images of the same object which blend together better if contrasts are less sharp. Of course this isn't the general case and I agree that the majority of people will prefer sharp images to blurry ones. But I wanted to give this example anyway because it demonstrates that even with the best intentions and perfect skills, interfering with the user's client functions causes always trouble to some users. Minorities with impediments can adapt to a world that challenges them by using adequate tools. Here: their browser (settings). But this fails if web page authors react on changed settings of special tools (e.g. the user client's zoom function) by dynamically changing the displayed result to stay as what the author considers the best version. If you'd stick to my use case, instead of coming up with imaginary problems, I think we might have a discussion on merits. I've not asked for a single semantic of zoom to be altered. I've stated quite clearly, repeatedly, that I need to control the pixel depth of bitmap data, so that zoom does not result in an unnecessarily blurry image. I understand that your goal is having zoomed images to be as sharp as a non-zoomed image would be and I think that most of the criticism is not directed against this goal but against your proposed solution to the problem. So, maybe we can see if there's an alternative approach to your goal? Sorry, I don't have a good one at hand, but I wonder whether there might be a solution along the lines of script/noscript and img-src/img-alt: Offering alternatives and letting the user's client choose what is best. If a web author wants to abuse existing apis, through any reason, they're perfectly able to do that. Still it is better to have an API that is less likely to be abused than one that is prone to abuse and unintended misuse. Just my two cents Martin
Re: [whatwg] whatwg Digest, Vol 80, Issue 47 | previously: Processing the zoom level - MS extensions to window.screen
On 11/25/10 11:26 AM, Martin Janecke wrote: Am 25.11.2010 um 17:41 schrieb Charles Pritchard: (2) The browsers' build-in zoom function, which web page authors have no control or information about. They have information about it, in many browsers, and they receive events related to window.innerWidth and innerHeight. Well, an author cannot conclude safely from these changes that the browser's zoom function has been used, can he? No, not safely: thus my attention on the issue. Once again, you, as many in the list, have taken a very simple use case, and generalized it into a straw man argument. It's not a straw man argument if the problems discussed actually follow from your proposal – even if your wish is very different from creating these problems. I don't think people doubt your good intentions. I'm not saying you want to disturb users or misuse the browser's zoom function for something different from what it is intended for. I'm against those consequences of your proposal which you do not intend yourself. Am I wrong and these problems cannot occur? Then it's a straw man argument. Otherwise it's not. Using CSS Pixel information to control the zoom of a mapping application would not work very well: there's no method for the author to send a zoom event, so they could not map any of their controls to alter the zoom level, and the zoom level controls of the UA are typically limited to a few zoom levels, again making it unlikely to be useful. Many problems can occur in a scripting environment. 1. blurry image != good. 2. Sharp image good. 3. Sharp image != disturbed users. Actually, some visually impaired users are disturbed by sharp contrasts. I have a friend who is. It's something with the cornea being uneven, leading him to see multiple images of the same object which blend together better if contrasts are less sharp. Of course this isn't the general case and I agree that the majority of people will prefer sharp images to blurry ones. But I wanted to give this example anyway because it demonstrates that even with the best intentions and perfect skills, interfering with the user's client functions causes always trouble to some users. Minorities with impediments can adapt to a world that challenges them by using adequate tools. Here: their browser (settings). But this fails if web page authors react on changed settings of special tools (e.g. the user client's zoom function) by dynamically changing the displayed result to stay as what the author considers the best version. Thanks for sharing an example about sharp-contrasts. I'll be certain to mention it to accessibility groups in the future. It does seem like a use case which would be handled by the operating system (not the UA / website). Yes, the best intentions can lead to unintended results. Still, authors are living, thinking, conscious beings. They're not machines. They are able to receive feedback on their applications and make adjustments for their user-base. The fact that something can be abused is certainly something to consider, but it should not shut-down consideration of the matter. At this point, the matter has been shut-down on the Mozilla end, on the single concern that the information may be misused. To me, that's not the way to lead. If you'd stick to my use case, instead of coming up with imaginary problems, I think we might have a discussion on merits. I've not asked for a single semantic of zoom to be altered. I've stated quite clearly, repeatedly, that I need to control the pixel depth of bitmap data, so that zoom does not result in an unnecessarily blurry image. I understand that your goal is having zoomed images to be as sharp as a non-zoomed image would be and I think that most of the criticism is not directed against this goal but against your proposed solution to the problem. So, maybe we can see if there's an alternative approach to your goal? Sorry, I don't have a good one at hand, but I wonder whether there might be a solution along the lines of script/noscript and img-src/img-alt: Offering alternatives and letting the user's client choose what is best. CSS options are already implemented. They do not offer control to the scripting environment. The criticism is against unknown masses of incompetents, not the proposal. It's levied against the concern that others may not use the information properly. It's not levied against exposing the proposed information. There are some criticisms about how much information is necessary ( such as, do we need an X and Y metric ) So to say again. We have alternatives. They're deficient for the use case. They're also overly verbose -- in that they can not be scripted and so may require a lot of redundancy -- which is one of the primary reasons for using scripting with CSS, instead of a pure-CSS solution. If we could move forward on this issue, we could be talking
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, Nov 25, 2010 at 1:29 AM, Biju bijumaill...@gmail.com wrote: 1. Can we deprecate alert(), confirm(), prompt() ? At present many web2.0 js libs are providing alternate [and cool looking] methods to achieve use cases where we need to use alert(), confirm(), prompt(). So do we need those modal dialogs any longer? It's a very basic feature, necessary even for Hello World-type coding in JavaScript. We shouldn't require authors to use libraries to get this functionality. 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. This is a browser implementation issue. Browsers should allow users to suppress modal dialogs, and should make them tab-modal instead of window-modal. They're in the process of doing this -- no spec change is needed, and a spec change will not speed the process. 3. also if we are keeping them, can we add an optional parameter for a timeout milliseconds to self dismiss the modal prompt. You mean the author should be able to add a parameter saying dismiss this alert() after 10 seconds if the user hasn't clicked? That's a bad idea. What if I opened the tab in the background, or had another window active, or was just off getting coffee when the dialog popped up? I'd never see it. We shouldn't make it easy for authors to do this.
Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?
On 11/25/10 1:59 PM, Anne van Kesteren wrote: They also pointed out we do support rgba() in SVG. The point is that the resulting behavior is not defined by the SVG spec. You could blow up the user's computer when using an rgba() color in SVG, and that would be as spec-compliant as anything else... -Boris
[whatwg] Reserving XRI and URN in registerProtocolHandler
I'd like to propose reserving two protocols for use with navigator.registerProtocolHandler: urn and xri (or possibly xriNN where NN is a version number). See http://en.wikipedia.org/wiki/Extensible_Resource_Identifier for info on XRI (basically allows the equivalents of URN but with a user-defined namespace and without needing ICANN/IANA approval). Although it was rejected earlier, I don't see that there is any other way for sites to create their own categorization or other behavior mechanisms in a way which is well-namespaced, does not rely on waiting for official approval, and has the benefits of working with the HTML5 specification as already designed. URN is something which I think also deserves to be reserved, if not all IANA protocols. As I see it, the only way for a site to innovate safely in avoiding conflicts for non-IANA protocols is to use XRI (assuming especially if it can be officially reserved). And all of this would be enhanced, in my view, if my earlier proposal for defaultURIs and alternateURIs attributes on a/ could be accepted as well: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20066.html in that it makes it much more likely that people would actually use any of these protocols. thank you, Brett
Re: [whatwg] Reserving XRI and URN in registerProtocolHandler
My apologies, I realized that there might be a modification needed to the HTML5 design of registerProtocolHandler, in that URN and XRI are better designed to work, in many cases, with registration to a specific namespace. For example, one application might only wish to handle urn:earthquakes or xri:http://example.com/myProtocols/someProtocol which hopefully registerProtocolHandler could be expanded to allow such specification without interfering with other URN/XRI protocol handlers which attempted to handle a different namespace. thanks, Brett On 11/26/2010 12:20 PM, Brett Zamir wrote: I'd like to propose reserving two protocols for use with navigator.registerProtocolHandler: urn and xri (or possibly xriNN where NN is a version number). See http://en.wikipedia.org/wiki/Extensible_Resource_Identifier for info on XRI (basically allows the equivalents of URN but with a user-defined namespace and without needing ICANN/IANA approval). Although it was rejected earlier, I don't see that there is any other way for sites to create their own categorization or other behavior mechanisms in a way which is well-namespaced, does not rely on waiting for official approval, and has the benefits of working with the HTML5 specification as already designed. URN is something which I think also deserves to be reserved, if not all IANA protocols. As I see it, the only way for a site to innovate safely in avoiding conflicts for non-IANA protocols is to use XRI (assuming especially if it can be officially reserved). And all of this would be enhanced, in my view, if my earlier proposal for defaultURIs and alternateURIs attributes on a/ could be accepted as well: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20066.html in that it makes it much more likely that people would actually use any of these protocols. thank you, Brett
