Re: [whatwg] Offline Web Apps
On Thu, 13 Sep 2007 11:22:59 +0200, Robert O'Callahan [EMAIL PROTECTED] wrote: On 9/11/07, Dimitri Glazkov [EMAIL PROTECTED] wrote: Since, AFAIK, the fragment identifier is not passed onto the server by the UA, I can't see how an application could be designed with proper noscript degradation and reliance frament ids for query communication. Besides, using query parameters is much more natural for HTML: forms with method=get are the way to build it. Those are good points that I should have thought of :-). I'm not sure I understand the query parameter use case. If you have a web page foo.cgi?page=x wouldn't that page also be simply the offline page? What exactly is the scenario in some more detail? (Note that with history.pushState() you can set the URI of the current page so the fragment identifier bookmarking argument is no longer very relevant.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Offline Web Apps
On Thu, 13 Sep 2007 18:21:21 +0200, Dimitri Glazkov [EMAIL PROTECTED] wrote: I would've loved it if Google Reader had a distinct URL for each click I make on the page, and I am sure Google Reader devs would've loved it too. Except they also would've loved not having to worry about the browser/scripting context change. You seem to have missed what I pointed out earlier: http://www.whatwg.org/specs/web-apps/current-work/#pushstate This allows applications to make distinct URIs while keeping all the other benefits. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] SQL API error handling
Hi, The SQL API doesn't seem to define how to deal with errors, such as: * Bogus SQL statements * SQL statements that are not supported for security reasons * SQL statements that are not supported because they don't make sense * SQL statements that fail to return anything * Database that is not available for some reason * Database that is full I think it should also be a bit more clear on how the user agent constructs the SQL statement. Cheers, -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Offline Web Apps
On Sat, 22 Sep 2007 01:07:23 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: It would be nice if this was designed to handle the possibility of multiple file selection (which I think Web Forms 2 enables). It does actually. There's a fileList attribute on HTMLInputElement that returns a FileList. It'd be possible to extend this to avoid bringing these files into memory. We'd just need globalStorage (or something like it) to accept/return nsIDOMFile objects, and a way for XHR to send them. Sounds reasonable. I'd love to see a rough cut at a spec for this. XMLHttpRequest level 2 supports sending ByteArray. So you could do something like the following maybe: xhr.send(file.bytes) Although if HTML5 gains a native File object I suppose support for that could be added as well if there's any benefit. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] [wf2] :read-write pseudoclass description issue
Quoting Rikkert Koppes [EMAIL PROTECTED]: [...] A disabled control can still match this pseudo-class; the states are orthogonal. I believe the term orthogonal is incorrect here. :read-write is orthogonal to :disabled. That's correct. -- Anne van Kesteren http://www.opera.com/ http://annevankesteren.nl/
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
On Thu, 27 Sep 2007 00:53:51 +0200, Vladimir Vukicevic [EMAIL PROTECTED] wrote: Yeah, we do the same thing on drawImage/putImageData that we do no fill/stroke (because in the underlying code they're all implemented using paths, and there's just one path :). So, like I said, we can certainly fix it, and it sounds like that would be the best way to go. Cool! I suppose that leaves the issue about revisiting throwing exception for certain members? Are there any member where it does make to throw an exception? If we decide not to throw an exception something has to be decided for Infinity -Infinity and NaN for all of those. I don't have a strong opinion on it either way, although I would prefer it to be decided quickly so we have some time to propagate the changes in time for Opera 9.5. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Radio controls shared with multiple forms
On Tue, 19 Dec 2006 17:18:48 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: The draft should probably be more explicit about: input type=radio name=A form=form1 input type=radio name=A form=form1 form2 checked input type=radio name=A form=form2 Assuming form1 and form2 both exist selecting the first control will unset the controls associated with form2 in Opera's current implementation. Our preferred solution is that in case of radio controls only the first entry in the form= attribute counts. If that happens we'll update our implementation in due course. This problem is also present for required checkboxes: input type=checkbox name=a form=b c required input type=checkbox name=a form=c -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Video, Closed Captions, and Audio Description Tracks
On Tue, 09 Oct 2007 18:03:41 +0200, Maik Merten [EMAIL PROTECTED] wrote: http://www.w3.org/TR/2006/CR-ttaf1-dfxp-20061116/ Actually I wonder if it wouldn't make sense to have an attribute for media elements specifying a URI for a file containing Timed Text. These externally stored (not embedded in a media file) captions would be codec-agnostic and could be used to reuse the very same set of captions for e.g. differently encoded media (Ogg, MPEG, Generic-Codec-Of-The-Season, ...). This would be problematic when downloading the video for offline use or further distribution. This is also different from how this currently works for DVDs, iPod, and the like as far as I can tell. It also makes authoring more complicated in the cases where someone hands a video to you as you'd have to separate the closed caption stream from it first and point to it as a separate resource. As a side note I like the idea of captions which are more than just the usual stream text. Imagine a newsreel with timed Would you like to know more? links. Given that HTML5 is usually viewed in browsers that implement at least a non-empty subset of HTML I imagine it should be possible for the browser to layer something div-equivalent over the media elements supporting captioning and pipe the HTML captions into it (with caution, imagine a caption itself recursively embedding a video). I think the cue points feature is designed to do that. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] database full error (was: Re: executeSql API is synchronous)
On Fri, 12 Oct 2007 20:46:52 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Certainly that would be reasonable. I have added it. People should let me know if they want me to remove or add error codes, by the way. I think there should be an error code for the database being full. For some platforms there's not much storage space available and knowing whether or not there's some space left is useful. So you can decide to only store the critical data for instance. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] SQL API and database metadata at creation
On Thu, 25 Oct 2007 06:58:40 +0200, Brady Eidson [EMAIL PROTECTED] wrote: LOL - are you SURE you didn't change that sometime between when I first read it and when I copied the passage into an email and obviously didn't re-read it? ;) http://html5.org/tools/web-apps-tracker?from=1093to=1094 -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] SVG extensions to canvas
Hi, (Please reply to either HTML or WHATWG list.) For Opera 9.5 beta we implemented some experimental extensions to canvas involving SVGSvgElement. SVGSvgElement is supported as image argument to both drawImage and createPattern. (An HTMLImageElement pointing to an SVG element is also supported, but that seems natural if you support SVG from img.) For drawImage the pixel size of the SVG is determined as follows: 1. The image size parameters passed to drawImage 2. The intrinsic size of the SVG image 3. 300 x 150 For createPattern it is as follows: 1. The intrinsic size of the SVG image 2. 300 x 150 (It would be nice if createPattern was extended to allow height/width arguments as well.) The intrinsic size of the SVG image is the specified size with percentages resolved against 300 x 150, and sizes depending on the font-size resolved against the computed font-size of the SVGSvgElement (will be the browser default most of the time). The SVG image is always rendered at time 0 for animated images. Drawing an SVG image currently marks the canvas context as unsafe so toDataURL() and getImageData() throw. We expect to make this story a bit nicer at some point. Cheers, -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] SQL API and changeVersion() with no callbacks
On Sat, 27 Oct 2007 00:23:57 +0200, Ian Hickson [EMAIL PROTECTED] wrote: I suppose the same could be said about executeSql(). Well... I can certainly see people queuing up a bunch of requests and dealing with the errors at the end in the transaction error handler. I am open to requiring that that have an explicit null though. Who do other people think? There at least some feedback from the developer community that they'd like to see optional arguments: http://www.dustindiaz.com/dom-interfaces-suck/ -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] SVG extensions to canvas
On Sat, 27 Oct 2007 15:44:39 +0200, Vlad Alexander (xhtml.com) [EMAIL PROTECTED] wrote: Any application that does a thumbnail preview of an SVG image must scale the image. If it's okay to scale images for thumbnail previews, why is it not okay for scaling inside the IMG or OBJECT element? I think I understand what behavior you desire. However, it's not entirely clear to me that what Opera is wrong given that your example has an intrinsic width of a 100% (which is overridden with 300px if I understand all the algorithms correctly; I probably don't). I think that's one of the reasons it's simply gets clipped instead of scaled. (And clipping is a feature too, keep that in mind.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] textarea pattern
The way newlines are handled for textarea maxlength should also apply to textarea pattern to keep things consistent. That is, lines are CRLF delimited. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] several messages about a way to disable referer headers for links
On Sat, 03 Nov 2007 18:27:50 +0100, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: Dnia 03-11-2007, sob o godzinie 08:42 +, Ian Hickson napisał(a): Ok, I've added a rel value similar to nofollow called noreferer that does this. While we are unable correct the spelling of referer, we certainly need not duplicate it for noreferrer. There must be some end to this self-humiliation. I think it's way better to stay consistent. Especially as the feature affects the Referer (sic) header. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] BIG Element
On Sun, 04 Nov 2007 13:06:39 -0500, Matthew Paul Thomas
[EMAIL PROTECTED] wrote:
We're getting off-topic here, but ... That wouldn't deitalicize
citei, emi, icite, idfn, iem, or ivar, when it
should. As the levels of nesting increased, the number of permutations
of these elements would explode. And it's not reasonable to expect any
author who uses someblockelement {font-style: italic;} to remember to
also define someblockelement cite, someblockelement dfn,
someblockelement em, someblockelement i, someblockelement var
{font-style: normal}.
Going a bit more off-topic, there are people working on solving this
issue: http://lists.w3.org/Archives/Public/www-style/2007May/0030.html
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
[whatwg] address markup (was: Re: time and meter elements)
On Tue, 11 Dec 2007 11:03:17 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 13 Feb 2007, Matthew Raymond wrote: A name element may have some uses, such as providing a hook for adding people to your contact list: | address | nameJohn Hopkins/namebr | Phone: (359) 555-1701 | /address Notwithstanding what I consider misuse of br in that example, I would encourage people to use hCard to mark up a name instead of us introducing an element for the purpose. How would you mark that up instead? address (currently) doesn't allow block-level descendents. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] clientWidth and innerWidth
On Wed, 19 Dec 2007 23:04:09 +0100, ddailey [EMAIL PROTECTED] wrote: I was revisiting some old scripts I had written for determining the size of the browser window (or things inside it) -- using clientWidth for IE and innerWidth for Netscape / other. Like many scripts written for the good old days, measuring seems to have changed as well. Mark Wilton-Jones provides this rather frightening analysis http://www.howtocreate.co.uk/tutorials/javascript/browserwindow of the behavior of Opera, IE, and FF (various versions of each) in and out of quirks mode. A quick text scan of the editor's draft of HTML5 at http://www.w3.org/html/wg/html5/ reveals no mention of either clientWidth or innerWidth, so I'm wondering where this might be handled if not in HTML itself? Apologies if this has been discussed ad nauseum before; I may have been napping. The CSS WG is working on this: http://dev.w3.org/csswg/cssom-view/ Discussion should take place on [EMAIL PROTECTED] The draft will be published as a W3C First Public Working Draft soonish, though this may be after new year given the holidays and such. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Suggestion: API for accessing cookies (document.cookies)
On Fri, 28 Dec 2007 18:13:38 +0100, Christian Schmidt [EMAIL PROTECTED] wrote: What do you think of this? I think that globalStorage and sessionStorage obviate the need for cookies. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Revised Plan for Server-sent DOM events
On Sat, 05 Jan 2008 07:51:29 +0100, Henry Mason [EMAIL PROTECTED] wrote: There's recently been some talk about completely removing HTML 5 section 6.2, Server-sent DOM events. I propose that rather than remove, we revise. I agree that we should keep it. - Continued problems of the 2 connection limit on HTTP server scalability Is there any realistic solution to this other than to use separate domains and have cross-domain working? I propose that we remove support for non-message events; that is, allow only events with MessageEvent interface. This will make implementations easier, as UAs will only need to parse the Bubbles, Cancelable, and data fields. Opera also supports the Event and Target fields. I think we'd be fine if the latter is removed, but the former is really useful as you can then have separate handlers to deal with the incoming data. (That they all implement the same MessageEvent interface is fine.) The critically cool part, however, is that since MessageEvents store their domain and URI origin, it will be safe to allow for cross-domain messaging through this server-sent events. Section 6.1 already uses this system for this very purpose. Opera has already implemented it and it has been in WebKit's trunk for about a week. WebKit is implementing cross-document messaging? Cool! The removal of the same-origin restriction actually makes this interface dramatically more useful for developers. It provides a capability (messaging with a foreign host) which is not already available to XMLHttpRequest-using applications. It also makes it easier web developers to more easily offload the long-running HTTP connections needed for event streams to separate servers. This aides in application scalability and circumvents potential problems with the 2 HTTP connection limit. This change would make server-sent events easier to implement for both UA implementers and web application developers and would make the developers more likely to use it. This does have the disadvantage that you always share your data with everyone where you can restrict that with Access Control. Especially for authenticated services this might be problematic. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Minor addition/rewording for canvas section
On Sun, 13 Jan 2008 14:13:52 +0100, Oliver Hunt [EMAIL PROTECTED] wrote: I did wonder about why other origins could read anything myself, so you're not alone -- it just seemed especially odd to allow images to be written safely but not ImageData. ImageData is always safe as you create it yourself. The specification should also mention that drawing img src=data:image/png,... on the canvas is safe so that you can actually roundtrip data through the server. The SVG case here is slightly more complex so maybe it's better to have a definition of a safe HTMLImageElement. I'm as yet unsure whether a separate origin should be able to write -- i have nothing to back this up with but it seems that you could potentially right to a canvas from a separate domain to make the canvas look like something it wasn't -- but i'm not familiar enough with the other origin related policies in html5 to be able to say anything meaningful. Cross-document messaging only allows passing through strings. I only noticed this as i was looking at the ImageData portion of the spec just now :D Would be nice if you guys implemented it :-) I assume there was a reason that reading from the canvas from another origin is ever allowed, but I can't think of what it might be -- any thoughts/recollections from others would be well received :D I don't think this is possible. The security model is pretty simple. HTMLImageElement is either safe or unsafe. HTMLCanvasElement is also either safe (default) or unsafe. CanvasPattern is, again, either safe or unsafe. Once you draw an unsafe HTMLImageElement, HTMLCanvasElement, or CanvasPattern on an HTMLCanvasElement you mark the HTMLCanvasElement as unsafe. The toDataURL() and getImageData() functions throw for an unsafe HTMLCanvasElement. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Shadows
On Tue, 15 Jan 2008 08:51:07 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 17 May 2007, Martijn wrote: Is how to render shadows defined here? http://www.whatwg.org/specs/web-apps/current-work/#shadows0 So with that piece of text it is clear how to render shadows in canvas? I agree that it is a bit vague, but do you have any specific suggestions as to what it should say exactly? I'm not sure what to write. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-June/011799.html -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] How to use SVG in HTML5?
On Thu, 24 Jan 2008 05:41:58 +0100, Eli Naeher [EMAIL PROTECTED] wrote: Could you elaborate on these barriers? I would really like to see inline SVG. http://annevankesteren.nl/2007/10/svg-html has a high-level overview. The main problem is how the HTML parser as defined by the HTML5 specification needs to be modified and what set of limitations do we impose on the syntax. I also notice that 3.3.3.6 mentions something related: Elements that are from namespaces other than the HTML namespace and that convey content but not metadata, are embedded content for the purposes of the content models defined in this specification. (For example, MathML, or SVG.) Is this section out-of-date? Or does it refer only to elements which have been loaded into the DOM by some means other than being included in the source (e.g. in accordance with 4.8.2, Page load processing model for XML files)? HTML 5 defines processing of HTML5, XHTML5, and documents created using DOM methods. Only the latter two can contain elements from other namespaces at this point. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] More random comments on the putImageData definition
On Fri, 25 Jan 2008 23:57:56 +0100, Oliver Hunt [EMAIL PROTECTED] wrote: Another thing that we need is some way to determine what the device pixel-css pixel ratio is. Currently there's isn't even a real way to tell that it's 1:1 -- you would have do do a fillRect(width-1, height-1, 1, 1),; then getImageData(width-1, height-1, 1, 1) and see if they match. Conceivably you could do this multiple times to estimate the ratio, but it would be non-trivial. You can determine this by checking the height and width attributes on the ImageData object. If you get a 2x2 region and ImageData.width and .height return 4 you know there's a factor two scaling happening between canvas pixels and device pixels. What the factor is between canvas pixels and CSS pixels isn't really relevant (and easy to determine). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] More random comments on the putImageData definition
On Fri, 25 Jan 2008 23:56:28 +0100, Maciej Stachowiak [EMAIL PROTECTED] wrote: getImageData/putImageData will definitely cause problems for high-DPI displays in the future that are driven with a scale factor where CSS pixels are not device pixels. The question is whether it's better for some content to fail and other content to work (if it checks the returned width/height), or for all content to lose resolution relative to what the display is capable of. Note that we already have a difference between canvas pixels and CSS pixels. One could easily do this for high definition displays: canvas height=1000 width=1000 style=height:100px;width:100px (Might be a bit much.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Some video questions
On Sun, 27 Jan 2008 23:06:53 +0100, Charles [EMAIL PROTECTED] wrote: Apologies in advance if I've missed these details in the specification. The video element supports width and height. Does this include the additional area needed (if necessary) by the controls? It strikes me that it shouldn't, since it would be odd for the video width and height to change when non-video decorators are shown/hidden. They do affect that area as far as I can tell. They give the height and width of the video player. I don't see a standard controls height and width, which is fine, but will there be read-only attributes for the width, height and position for controls? There are readonly attributes to get the height and width of the video. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Referer header sent with a ping?
On Fri, 01 Feb 2008 02:03:01 +0100, Darin Fisher [EMAIL PROTECTED] wrote: I suppose that X-Ping-From/To should be striped (like Referer) when one of those values is HTTPS and the ping attribute is non-HTTPS? Given that HTML5 is now on standards track lets make it Ping-From and Ping-To. Provisionally registering headers is pretty simple and when HTML5 finally becomes a W3C Recommendation we can move them to the permanent registry. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] canvas and ImageData
On Sun, 03 Feb 2008 10:43:10 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Fri, 25 Jan 2008, Oliver Hunt wrote: Another thing that we need is some way to determine what the device pixel-css pixel ratio is. Currently there's isn't even a real way to tell that it's 1:1 -- you would have do do a fillRect(width-1, height-1, 1, 1),; then getImageData(width-1, height-1, 1, 1) and see if they match. Conceivably you could do this multiple times to estimate the ratio, but it would be non-trivial. Why would you need that data? The moment people start using getImageData() as storage mechanism (which they will if browsers do not fix their data: image origin stuff) you'll have a problem with this if the application is accessed through different devices that have different ratios. I suspect though that given that Firefox has a 1:1 ratio sites will simply rely on that... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] createImageData - new ImageData() ?
Why not give the object a constructor? I think that's cleaner. Also, Opera already supports that :-) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] createImageData - new ImageData() ?
On Sun, 03 Feb 2008 12:20:54 +0100, Oliver Hunt [EMAIL PROTECTED] wrote: On Feb 3, 2008, at 2:38 AM, Anne van Kesteren wrote: Why not give the object a constructor? I think that's cleaner. Also, Opera already supports that :-) The biggest problem is that you would have to define the behaviour in a fairly counterintuitive way new ImageData(400, 400) would not necessarily result in an ImageData object with width=400, height=400 as a system with a non-1:1 css to device pixel ratio. How is this a non-issue for createImageData()? The moment people start using getImageData() as storage mechanism (which they will if browsers do not fix their data: image origin stuff) you'll have a problem with this if the application is accessed through different devices that have different ratios. I suspect though that given that Firefox has a 1:1 ratio sites will simply rely on that... Part of my commentary was on a misunderstanding of the spec sorry :( That said, what do you mean by using getImageData as a storage mechanism? If you have some kind of painting application and to store the result of the painting so that the user can edit it in another session every now and then you do getImageData() on the whole canvas and export the data to some database through XMLHttpRequest so when the visitor comes back he doesn't have to start all over again. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] SQL storage and onunload
On Fri, 08 Feb 2008 18:24:58 +0100, Brady Eidson [EMAIL PROTECTED] wrote: As far as the unload handler question, what are the semantics for XHR? I think the user leaving the page is the same as aborting the download. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] createImageData - new ImageData() ?
On Sun, 10 Feb 2008 10:21:34 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Sun, 3 Feb 2008, Anne van Kesteren wrote: Why not give the object a constructor? I think that's cleaner. Also, Opera already supports that :-) The relationship between the height and width arguments and the height and width of the ImageData structure returned can vary on a per-canvas basis. That would mean that passing ImageData around between two canvas elements doesn't always work as expected. I think that's highly undesirable. Is there any implementation where we know this will the case? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] SQL storage and onunload
On Sat, 09 Feb 2008 22:06:39 +0100, Alexey Proskuryakov [EMAIL PROTECTED] wrote: On Feb 9, 2008, at 12:58 PM, Anne van Kesteren wrote: As far as the unload handler question, what are the semantics for XHR? I think the user leaving the page is the same as aborting the download. I've seen servers (e.g. Google) use XHR in onunload to track usage statistics. Sounds like a reasonable use case (really, is there a better way?). How do you determine when you can end the process? It also seems kind of icky that the window is already closed (as far as the end user is concerned), but that code is still executing on behalf of it. Could be that I misunderstood something though. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] canvas and ImageData
On Sun, 10 Feb 2008 22:52:33 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Sun, 3 Feb 2008, Anne van Kesteren wrote: The moment people start using getImageData() as storage mechanism (which they will if browsers do not fix their data: image origin stuff) you'll have a problem So you want to change the spec and get browsers to implement something to work around a problem with browsers implementing something else in the spec? :-) Heh, no. I was just pointing out an issue. (getImageData()/putImageData() does work better for roundtripping today than toDataURL().) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] reply() extension to postMessage()
Hi, Given that everyone is now updating their postMessage() code anyway, I wonder if it's possible to quickly make another minor tweak. The proposal is to remove the source attribute from MessageEvent and replace it with a reply() method. The semantics of the reply() are probably best described in terms of equivalence. That is, e.reply(message) is equivalent to e.source.postMessage(message, e.origin) except that the latter won't work anymore when reply() is added. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] reply() extension to postMessage()
On Thu, 14 Feb 2008 17:30:15 +0100, Aaron Boodman [EMAIL PROTECTED] wrote:
If we're going to add reply, I would like to easily be able to get
replies to a specific message. So extend postMessage to accept a
callback, and then either have reply() call this callback. Like this:
// sender:
someWindow.postMessage(hello!, function(response) {
alert(got response: + response);
});
// receiver
window.addEventListener(message, function(e) {
alert(got message: + e.message);
e.reply(good day);
});
You really want reply() to have that callback too (for longer
conversations) and at that point it starts getting icky.
I came up with another idea to address the issue you mention. We let
postMessage() return a UUID and give MessageEvent an id attribute. When
postMessage() is invoked a UUID is generated and returned. This same UUID
is set on the event that is dispatched. When reply is invoked on that
event object it creates an event that again has the same UUID. Both
parties can have multiple conversations that way by checking the UUID of
the message.
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: [whatwg] drawImage with non-existent images
On Mon, 18 Feb 2008 03:24:45 +0100, Jeff Walden [EMAIL PROTECTED] wrote: If the image argument is an HTMLImageElement object whose complete attribute is false, then the implementation must raise an INVALID_STATE_ERR exception. This is all well and good in the case where the image being drawn has the same origin as the document where the canvas resides, but if the two have different origins, this makes it possible to determine the existence of an image on a foreign server. This is already possible using the error and load events and the complete attribute on img. There's no new risk here. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] HTML 5: The l (line) element
On Tue, 19 Feb 2008 11:22:32 +0100, Christoph Päper [EMAIL PROTECTED] wrote: We could also consider to reuse |br| for this purpose and thus make it magic, i.e. it is empty by default and works like it has always done, but if /br is encountered it turns the preceding br... (but not br.../) on the same nesting level from an empty into a start tag. Actually, we can't. /br is a br start tag because of legacy. I don't see why l is so compelling by the way. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Workers in HTML5
On Tue, 19 Feb 2008 22:46:44 +0100, Scott Hess [EMAIL PROTECTED] wrote: It seems to me that this is an area where if you give an inch, the developer wants another inch. If you have something called window, then you're just moving things around - instead of saying Where is my window?, developers get to say Why can't my window do X? Since this is all new ground, it might be more reasonable to define the set of things you want to have in your worker context, and then contrive to add those things to your UI context. That way you're explaining what is there, rather than excusing what is not there. [Anvil labeled Legacy Interfaces lands on Scott's head.] Given that most people don't know the difference between the Window and the global object and the global worker object will already contain a bunch of APIs identical to those on the Window object it seems to me that giving the object and interface a different name doesn't really help. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for a link attribute to replace a href
[... global attribute for links ...] We have a FAQ entry on this -- quite common -- request: http://wiki.whatwg.org/wiki/FAQ#Does_HTML5_support_href_on_any_element_like_XHTML_2.0.3F Hope that helps! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] @Irrelevant [was: Re: Thoughts on HTML 5]
On Fri, 29 Feb 2008 18:54:08 +0100, Nicholas C. Zakas [EMAIL PROTECTED] wrote: If the true purpose of the irrelevant attribute is to aid in accessibility, then I think the name is completely wrong. The term irrelevant is confusing because, as I stated before, why would anyone include content in a page that is irrelevant? What you really need is a way to say this is relevant only for non-visual UA's. Perhaps a better attribute name would be nonvisual? The attribute, as explained in the specification (maybe it's not clear enough?) is intended for dynamic applications where you already have sections in the page for several steps, but only one of those sections is currently relevant. The rest is marked irrelevant until the user completes some action. This is a totally different case from the one you seem to be worried about. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Issues concerning the base element and xml:base
On Sat, 01 Mar 2008 13:29:41 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: Personally it's something I would be very reluctant to do. It would add a whole lot of code for basically no benefit for web developers. I have never heard of anyone that actually desired changing the base uri for all or parts of a page dynamically. Note that the new base URI would only take effect once you actually did something with a potentially affected object. For instance, img would not start loading a new image if the base URI changes. img.src = img.getAttribute(src) could start loading a new resource however if the base URI changed since the initial load. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Issues concerning the base element and xml:base
On Sun, 02 Mar 2008 22:50:09 +0100, Maciej Stachowiak [EMAIL PROTECTED] wrote: Moving nodes between documents is not allowed by the DOM. Technically you are supposed to use importNode, which makes a copy. Firefox currently allows it in some cases, and Safari does too in a possibly different subset of cases for compatibility with the Firefox behavior on some enterprise web apps. It is also not a common practice, so far as I know. Given fixes to one or two key apps that are popular in intranet deployment, this extension could probably be removed. It's at least common enough for Firefox 3 not to fix its behavior (which is fine by me, the restriction on moving nodes doesn't make much sense). I'd expect it to be used with XMLHttpRequest for instance. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Preventing nested click() calls
On Mon, 10 Mar 2008 19:49:21 +0100, Antti Koivisto [EMAIL PROTECTED] wrote: WebKit, Firefox and IE all implement a protection mechanism against re- entering click() on the same element: input type=checkbox onclick=this.click() Opera had the same restriction. We now limit it at 50 or so... I think we're fine either way though. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Tree construction: parse error and plaintext
On Wed, 12 Mar 2008 16:53:52 +0100, Thomas Broyer [EMAIL PROTECTED] wrote: In the in body insertion mode, shouldn't the eod-of-file token case have a special handling of if the current node is a plaintext element and not generate a parse error in this case? The current behavior is that if you use plaintext, you'll have a parse error at EOF. Is this intended? Yes: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-January/009113.html -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Images preprocessing
On Mon, 31 Mar 2008 08:44:54 -0700, Filip Likavcan [EMAIL PROTECTED] wrote: I was thinking about some preprocessing of images before they are uploaded to server. Typical example is unexperienced user who wants to upload whole set of photos from birthday party. Every photo has unnecessary huge proportions and will be resized immediately after upload. What if UA could be asked to resize images before upload thus saves banwidth, server resources, upload time, etc.? With the undefined extensions to input type=file Web authors will be able to make this happen using said undefined extensions to the input type=file control and canvas. (The extensions basically give you access to the file contents.) They will have to write the processing script themselves. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Video
On Thu, 03 Apr 2008 19:21:42 +0200, Charles [EMAIL PROTECTED] wrote: With all due respect: the mission of the WWW Corporation is to create standards, not to create situations. Not to speak for Robert, but I'm guessing that his point is that the W3C isn't creating a standard here. Note that this isn't a W3C list, but a WHATWG list. They are distinct entities. My understanding is that the goal is to bless some combination of existing video, audio and container format standards. Correct. We're not planning on creating yet another video format. (The kind of video you make with camcorders, to be clear, given that animation in HTML has come up elsewhere.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Video
On Thu, 03 Apr 2008 20:07:50 +0200, Charles [EMAIL PROTECTED] wrote: With all due respect: the mission of the WWW Corporation is to create standards, not to create situations. Not to speak for Robert, but I'm guessing that his point is that the W3C isn't creating a standard here. Note that this isn't a W3C list, but a WHATWG list. They are distinct entities. Of course, I was simply referencing Chris' mention of the WWW Corporation. No offense meant. Oh, none taken. I just though I'd point that out as occasionally I see blogs linking to the WHATWG saying it's the W3C. And while there's considerable overlap between the two communities they're not the same thing. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Request: window.postMessage should be async
On Fri, 04 Apr 2008 23:04:30 +0200, Eric Seidel [EMAIL PROTECTED] wrote: Anyway, I'm not the foremost expert here, but I was reading HTML5 last week and encountered this sync postMessage() requirement, which seemed like a bad idea. It doesn't make sense to change this given that all synthesized event dispatching is synchronous. I don't think postMessage() should be different. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Request: window.postMessage should be async
On Sat, 05 Apr 2008 00:03:58 +0200, Aaron Boodman [EMAIL PROTECTED] wrote: On Fri, Apr 4, 2008 at 2:39 PM, Anne van Kesteren [EMAIL PROTECTED] wrote: It doesn't make sense to change this given that all synthesized event dispatching is synchronous. I don't think postMessage() should be different. It seems a little different to me. PostMesasge events are fired in another frame that the caller can't even see into. What difference does it make to the caller whether postMessage is synchronous or not? This does not have to be any different for cross-frame events. The only difference is that cross-frame synthesized events don't work cross-origin. Furthermore, if we're going to add the ability for the conversation to go back and forth, to me it gets strange. You need to the asynchronous coding for that case anyway. (Unless both parties know what they're going to say.) If you call postMessage() on a frame, and it returns the favor, you receive the reply before your call to postMessage() even returns. To me, the current shape of the API (and even the name 'post message') implies that this is an asynchronous system and that postMessage() returns immediately, queuing a message to be delivered to the other window. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Listing element
On Sat, 05 Apr 2008 16:37:42 +0200, Christoph Päper [EMAIL PROTECTED] wrote: The |listing| element is currently not defined in HTML5, but its parsing is said to be the same as for |pre|. Will |listing| be included some day or will it be left out, because |code| nested in |pre| provides the same semantics already? It will not be conforming for authors to use it. The parsing section simply has mention of some elements authors will not be allowed to use, such as plaintext and listing, because user agents need to handle them for Web compatibility. There is a note to that effect in the specification. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Request: window.postMessage should be async
On Sun, 06 Apr 2008 11:41:20 +0200, Peter Kasting [EMAIL PROTECTED] wrote: Here's another problem an async API would automatically address: https://bugzilla.mozilla.org/show_bug.cgi?id=416912 FWIW, Opera is ok either way. I personally think it doesn't make much sense for this to be different from synthesized events and also given that non-same origin windows that can access each other already have to be in sync (as mentioned in this thread), but we're good either way. (Our initial implementation when postMessage was still on Document was in fact asynchronous and that it is now synchronous was more a side effect of the moving process than something intentional.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Request: Canvas Tag CSS
On Sun, 06 Apr 2008 10:49:01 +0200, Greg Houston [EMAIL PROTECTED] wrote: Having worked with the canvas tag quite a bit now, I've found that it is a bit awkward that the canvas tag is not taking advantage of CSS. If you are changing your site design, perhaps you want to change the colors used in your line graphs as well. So you make the changes in your CSS for the majority of your elements, which is rather painless, and then for the canvas tag you then have to start digging through the JavaScript to make your changes. Since canvas uses the color production from CSS why does a global search and replace through JavaScript files and CSS files not suffice? Alternatively, you could use getComputedStyle() to get the color values from your CSS file. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Request: Canvas Tag CSS
On Tue, 08 Apr 2008 18:44:31 +0200, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: If users need to be able to restyle content in order to see it, how would this work with Canvas? Should UAs provide daltonization functionality for Canvas content, for example? http://www.vischeck.com/daltonize/ As far as that goes I don't think you should classify canvas any different from a scripted img. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] More Storage clarification
On Fri, 11 Apr 2008 01:01:46 +0200, Brady Eidson [EMAIL PROTECTED] wrote: In 4.10.5, the description of the properties on the StorageEvent object mentions ...its newValue attribute set to the new value of the key in question, or null if the key was removed... So a web author can assume that when handling a StorageEvent whose newValue property is null that the event was the result of a removeItem(), and the key is no longer in the list. However in 4.10.2 in the discussion of setItem(), there is no mention that null is not an allowed value. Something like sessionStorage.setItem(key, null) is not forbidden, therefore it is allowed, and it would result in a StorageEvent with a null newValue. To resolve this case, I propose that we specify that the value in a key/value pair cannot be set to null. I see two clean ways to specify this: 1 - Throw an exception when setItem() is called with a null value. 2 - Specify setItem(key, null) to have the exact same effects as removeItem(key). I prefer #2. Thoughts? Euhm, setItem() takes two strings. Therefore I'd expect null, undefined, etc. to be stringified. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] img element: downloading a resource
On Fri, 11 Apr 2008 02:03:45 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 7 Nov 2006, Anne van Kesteren wrote: The definition of downloading a resource must be clear that even if the resource does not need to be downloaded (because it has been cached or something) the load event still needs to be dispatched (or the error event, in case it contains errors). Isn't this an HTTP issue? I suppose you could call it that. The main issue is that people are confused with the current wording and assume it either doesn't cover cached images or that in case of images being cached the text does not apply. (The Opera browser has for some time not dispatched those events because of incorrect assumptions.) So a generic note somewhere that downloading can refer to retrieving it over the network or reading it from the cache, etc. would be good. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Supporting MathML and SVG in text/html, and related topics
On Wed, 16 Apr 2008 18:36:49 +0200, William F Hammond [EMAIL PROTECTED] wrote: About 7 years ago there was argument in these circles about whether correct xhtml+mathml could be served as text/html. As we all know, a clear boundary was drawn, presumably because it was onerous for browsers to sniff incoming content and then decide how to parse. Actually, it was not the browsers: http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html As things have evolved, we now know that browsers do, in fact, perform a lot of triage. See, for example, Mozilla's DOCTYPE sniffing, http://developer.mozilla.org/en/docs/Mozilla's_DOCTYPE_sniffing That's a very limited set of differences which mostly affect page layout. Especially since we are speaking about dual serialization of the same DOM and since there is relatively little use of application/xhtml+xml (and some significant user agents do not support it), might it not be worthwhile to re-examine the question of serving standards-compliant xhtml or xhtml+(mathml|svg) serialized document instances as either text/html or application/xhtml+xml? In other words, why not be able to serve both serializations as text/html? What obstacles to this exist? The Web. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Supporting MathML and SVG in text/html, and related topics
On Wed, 16 Apr 2008 22:01:49 +0200, William F Hammond [EMAIL PROTECTED] wrote: Anne van Kesteren [EMAIL PROTECTED] writes: The Web. Really!?! Yes, see for instance: http://lists.w3.org/Archives/Public/public-html/2007Aug/1248.html It's time for user agents to stop supporting bogus document preambles. Please keep the discussion realistic. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Question about the PICS label in HTML5
On Thu, 17 Apr 2008 11:06:46 +0200, Dan Brickley [EMAIL PROTECTED] wrote: http://wiki.whatwg.org/wiki/RelExtensions Erm, 'For the Status section to be changed to Accepted, the proposed keyword must have been through the Microformats process, and been approved by the Microformats community. ' Is that really so? That's the current proposal. I personally think a W3C Recommendation backing it should be enough as well. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Element borders as resizable handles
On Sun, 20 Apr 2008 08:40:20 +0200, Greg Houston [EMAIL PROTECTED] wrote: Again, I realize this may not be feasible, but thought I would throw the idea out there. Is this what you're looking for: http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resize ? While on the topic of borders, it would also be nice if there was a CSS property for their alignment, outside as is the current default, and inside. Pushing my luck, I would like to see the same options for the strokes in the canvas element with the addition of center which is the current default. CSS border-align: inside; border-align: outside; Canvas ctx.strokeAlign = center ctx.strokeAlign = inside ctx.strokeAlign = outside Center, inside, and outside are the labels used for this in Adobe Illustrator. This seems partially off-topic for this list and I'm not sure what this means. Is this what you're looking for: http://www.w3.org/TR/css3-background/#the-background-origin ? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Element borders as resizable handles
On Sun, 20 Apr 2008 14:58:35 +0200, Greg Houston [EMAIL PROTECTED] wrote: http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resize This fulfills the basic idea, though the spec seems to leave the resize mechanism up to the imaginations of the UAs. All it says is that the resize mechanism is not a scrollbar. Using the element borders might be one option for a resize mechanism. I imagine the CSS3 authors may have felt it out of their scope to try to define a resize mechanism since it is a UI element. Though my particular idea may or may not be a good one, it does beg the question as to whether or not there should be HTML elements that can be used for such things and that developers can then style and customize themselves rather than being stuck with the various UA implementations that may or may not work well with specific web application designs. Also, due to the vagueness of the specification the implementations could vary quite wildy from one browser to another. Do the resize mechanisms go on the inside of the element, on the outside, centered on the edge? What shape are they, circles, squares, rectangles? Are they as tall or wide as the element or are they just little icons centered on each edge and at the corners? If the element that is being resized has rounded corners does the UI still look good? Are they simple in design or are they shaded and intricate? Are they visible at all, or does the cursor merely change when the mouse is over them? As a designer and developer these are things I would like to have some control over. If you want full control you probably have to implement it yourself. Regarding a couple of the new UI elements in HTML5, it is not clear to me from the spec if the meter and progress elements are purely UA designed elements or if the developer has control over their styling. You can probably style them using XBL in due course. They are similar to form controls as far as I can tell. With the HTML5 drag and drop, can you specify a handle for the dragged element(s) or are the dragged element(s) always their own handle(drag mechanism)? I'm not sure what you mean here. No, though after looking at these links the non-canvas part does indeed appear to be more in the realm of the CSS3 spec. Where HTML ends and CSS begins can be a little fuzzy for me. Regardless, to clarify, if you have a div that is 100x100 pixels and you add a 5px border, you will now have an element with dimensions of 105x105px. This is because the border is aligned to the outside of the element. If you animate the size of the border the element will grow and shrink in size. If the border were added on the inside the element will remain 100x100px wide regardless of the border size, but the content size would shrink and expand. Oh, you want 'box-sizing': http://www.w3.org/TR/2004/CR-css3-ui-20040511/#box-sizing (This property has several UA implementations already. Some with a prefix only, admittedly.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] A suggestion, if postMessage becomes async
On Wed, 23 Apr 2008 02:38:05 +0200, Jeff Walden [EMAIL PROTECTED] wrote: Make the targetOrigin argument non-optional. * would mean don't care while anything else would specify an origin (or result in a syntax error). If this is done, it's no longer possible to have time-of-check/time-of-use issues (in the async case) without the web developer explicitly choosing to do so. This change shouldn't be any more than 5-10 lines, and fixing existing testcases to adjust for this change is straightforward. How is omitting the argument any less explicit than providing a * as argument? I would prefer we keep that part of the API as is. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Are unfocusable elements focusable with tabIndex=-1.
On Tue, 22 Apr 2008 22:35:39 +0200, Aaron Leventhal [EMAIL PROTECTED] wrote: I checked with Opera and they also do tabindex=-1 makes anything focusable. So the spec is out of line with implementations. Note that for http://tc.labs.opera.com/html/global-attributes/tabindex/004.htm implementations do differ. I think it would make sense for Firefox and Opera (and Safari) to align with Internet Explorer and ignore the tabindex attribute when it has an invalid value specified. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] DOM Storage feedback
On Mon, 28 Apr 2008 23:14:03 +0200, Brady Eidson [EMAIL PROTECTED] wrote: I would like to make sure that my understanding is correct here, since you expressed doubt. Anne was asserting that since the interface for setItem() specifies a DOMString as the input, anything you pass it will be stringified. Therefore passing it the null value would be stringified to null. This is what you currently see in all the major browsers with window.alert(null), for example, which is also specified as a DOMString input parameter. Therefore a call to setItem(foo, null); becomes, in effect, setItem(foo, null); Is this correct? If so, the spec is fine as-is, and removeItem() is the only way to remove an individual item. This was what I was suggesting, yes. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] link rel=icon width=
On Sun, 04 May 2008 02:38:03 +0200, Ernest Cline [EMAIL PROTECTED] wrote: Perhaps, but it means adding attributes to link elements that will only be needed for a single link type. If the use case for these attributes is strong enough to add special purpose attributes for use with only link rel=icon then I dare say that it is strong enough to have a special purpose icon element so as to keep user agents from having to deal with nonsense such as link rel=stylesheet height=32 width=32 icon would not be backwards compatible. In some user agents (at least Opera and Firefox) that would imply a body element for instance. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for a link attribute to replace a href
On Fri, 30 May 2008 17:12:12 +0200, Tab Atkins Jr. [EMAIL PROTECTED] wrote: As far as I can tell a block-level a is already supported just fine, as you *can* wrap block-level content in an a and have it work as expected right now, and CSSing an a into display:block works wonderfully. It *appears* that only the standard disallows this at the moment - the actual browsers handle it just fine. This is probably more a question of whether we should allow this in HTML then whether or not we can allow this in browsers as browsers pretty much have to support this anyway. I personally think we should allow this for cases as demonstrated by this site: http://noorderlicht.vpro.nl/ (Disclaimer: I have worked on that site three years ago.) (I agree that a global href= attribute would not be very feasible given all the other attributes a has.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for a link attribute to replace a href
On Sat, 31 May 2008 04:20:10 +0200, Ernest Cline [EMAIL PROTECTED] wrote: What about adding a third non-metadata hyperlink element, say anchor, which would be a flow content element with flow content allowed in it? This would seem to cover the use cases presented, while preserving a as being phrasing content only. The only issue I see if this were added, is whether it would be better to have the ismap attribute of img only work with a or to have it work with the new element as well. The a element can already do this and it would be backwards compatible. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for a link attribute to replace a href
On Mon, 02 Jun 2008 05:26:40 +0200, Ernest Cline [EMAIL PROTECTED] wrote: The a element can already do this and it would be backwards compatible. Backwards compatible with some user agents but not with the specs. Sure, but anchor is not backwards compatible with specs or user agents. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Context help in Web Forms
On Tue, 03 Jun 2008 20:51:39 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: I don't like the idea of trying to encode the datatypes of data-* attributes in a validator-sensitive way. What datatypes would a validator support for data-* attributes? The HTML5 datatype library used by Validator.nu already contains 41 datatypes, but people will likely want to have others. The whole point of data-* is to provide a place where a validator doesn't go without authors having to abuse e.g. title which is a freeform but exposed to humans. I agree. The foreseeable problem with data-* is, of course, that microformat-like activity will happen there instead of going through the trouble of getting unprefixed validator-sensitive attributes minted with community review in the WHATWG and the HTML WG. That'd be wrong as data-* does not allow implementation by UAs... Having said that, if we don't make it clear what the idea is that might end up happening in practice here and there. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Bad CSS on the multipage version
On Wed, 04 Jun 2008 12:25:28 +0200, Křištof Želechovski [EMAIL PROTECTED] wrote: Regarding your page at the URL http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html #the-embed: The following declaration is bad and wrong: Is: margin-top: -2.5em Should be: margin-top: -2.5ex Wrong: A horizontal unit is applied to a vertical measure Bad: Element headings (level 4) are invisible (obscured underneath the following content). Please fix ASAP. I don't see that problem. Also, em is just a shorthand for the font-size of the current element (or parent element if you specify it on font-size), it's different from the traditional em unit in that respect. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Bad CSS on the multipage version
On Wed, 04 Jun 2008 12:39:31 +0200, Křištof Želechovski [EMAIL PROTECTED] wrote: Well, whatever the EM stands for, the rule hides the headings from viewing in Internet Explorer, whereas the rule with EX makes them reappear. It sounds like a bug in your browser. Did you test other browsers with your suggested replacement rule? I'd expect that to not work. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Issues concerning the base element and xml:base
On Sat, 07 Jun 2008 13:55:11 +0200, Smylers [EMAIL PROTECTED] wrote: So it sounds like supporting it isn't necessary, and putting effort into supporting it is a distraction. Well, we want to prevent that at some point an important site will start relying on the specifics of xml:base handling in a particular browser while we can still make the handling something sane we can all agree on. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video background color
On Fri, 13 Jun 2008 13:42:28 +0200, Philip Jägenstedt [EMAIL PROTECTED]
wrote:
On Fri, 2008-06-13 at 09:26 +, Ian Hickson wrote:
It's not impossible; first black would render 300x150, then the poster
The spec says: Areas of the element's playback area that do not contain
the video represent nothing.
What does this mean? Black is customary for video, but leaving the
region transparent (thus falling back to css background color) is
another option. Which is better?
Maybe a default style sheet entry like
video { background-color:#000 }
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: [whatwg] comment on autofocus attribute from Web Forms 2.0 spec
On Mon, 16 Jun 2008 21:17:18 +0200, Adele Peterson [EMAIL PROTECTED] wrote: In HTML5, focus() and blur() are now defined on HTMLElement instead of being restricted to specific form elements. In Web Forms 2.0, the autofocus attribute is defined for any form control (except hidden and output controls). It seems like it would make more sense to allow autofocus to be on any HTMLElement, and have it follow the same focusable rules that focus() follows. I thought about this a bit as well, but I'm not really sure what the use case would be. You typically see the effect happening for input type=text. Would this be used by contenteditable-enabled controls? Custom controls? If we go down this route, I think we should add the disabled attribute as a global attribute as well. Internet Explorer already has it and it makes sense together with contenteditable and tabindex. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Restricting style inheritance
On Tue, 17 Jun 2008 12:43:32 +0200, Frode Børli [EMAIL PROTECTED] wrote: I am unsure if this applies to HTML (or rather CSS). From the archives I see that Dean Edwards proposed some reset/reset element that was supposed to reset styles to the page default style. I have another proposal div style='inherit: nothing'/div That would be CSS. I suggest you subscribe to the [EMAIL PROTECTED] mailing list and give your feedback there. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Sandboxing to accommodate user generated content.
On Tue, 17 Jun 2008 06:09:55 +0200, Frode Børli [EMAIL PROTECTED] wrote: Hi! I am a new member of this mailing list, and I wish to contribute with a couple of specific requirements that I believe should be discussed and perhaps implemented in the final specification. I am unsure if this is the correct place to post my ideas (or if my ideas are even new), but if it is not, then I am sure somebody will instruct me. :) One person told me that the specification was finished and no new features would be added from now on - but hopefully that is not true. That is actually true. However, sandboxing has been proposed in the past and is therefore still considered in scope. (Unless of course we decide it's out of scope, but given the sandboxing features already in the specification, I expect that to be not the case.) One solution: htmlareaUser generated content/htmlarea As you note this solution has significant issues. Besides inserting /htmlarea it would also allow execution of scripts in legacy user agents and is therefore not really backwards compatible. I believe the idea to deal with this is to add another attribute to iframe, besides sandbox= and seamless= we already have for sandboxing. This attribute, doc=, would take a string of markup where you would only need to escape the quotation character used (so either ' or ). The fallback for legacy user agents would be the src= attribute. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Javascript API to query supported codecs for video and audio
On Wed, 18 Jun 2008 12:01:13 +0200, [EMAIL PROTECTED] wrote: as it looks like there will not be a common base codec any time soon, there is a need to be able to detect the supported codecs in javascript. are there any plans to provide such an interface or is this already possible? Why is that needed? The elements provide a way to link to multiple codecs of which the user agent will then make a choice. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for cross domain security framework
On Mon, 23 Jun 2008 09:34:27 +0200, Frode Børli [EMAIL PROTECTED] wrote: [...] I'd suggest looking into the work the W3C has been doing on this for the past two years: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ http://dev.w3.org/2006/waf/access-control/ -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for cross domain security framework
On Mon, 23 Jun 2008 14:18:22 +0200, Frode Børli [EMAIL PROTECTED] wrote: Hi! Thank you for pointing to that document. I quickly scanned trough it but I have a small problem with the specification: does it require web servers to check the Origin header? What happens with older web applications that do not check this header? It's not strictly required, but highly recommended. Older Web applications wouldn't opt-in and would therefore be as vulnerable as they are today. Anyway, this is the wrong list to debate that specification. You want [EMAIL PROTECTED] -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] same-origin versus same origin
http://www.w3.org/html/wg/html5/ has some usage of same-origin while it seems that the intention is for it to be all same origin. I'd prefer if it was all same origin (apart from tokens, of course) as that's what I/I'll use in XLMHttpRequest et al. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] URL and Document
http://www.w3.org/html/wg/html5/#url says that URL is always associated with a Document. What does that mean for the second argument of postMessage? Or for the value of Websocket-Origin? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] keygen element
Hi, On Wed, 09 Jul 2008 14:19:09 +0200, Lars [EMAIL PROTECTED] wrote: Is there any hope for this element? What information does which people want to make this an HTML5 standard? It seems we have similar interests :-) I haven't gotten around to doing it, but what needs to be done is having a vast set of test cases that demonstrate how this feature is implemented today. Ideally from those testcases we can write up a proposal that can then be incorporated into HTML5. I believe this is all that is blocking the inclusion of this feature at this point. (Though it might also be delayed slightly because Web Forms 2.0 is not integrated yet, but that might happen soon.) Kind regards, -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Should enter be mapped to click?
On Mon, 14 Jul 2008 11:03:23 +0200, Aaron Leventhal [EMAIL PROTECTED] wrote: Now that tabindex can be used on any element to make it focusable, it makes sense that it should be possible to trigger a click on those elements with the keyboard. Opera maps Enter to click. As far as I know, other browsers only do that for a few elements likea. What do people think? Should it be spec'd? Yes :angel: Seriously though, I think it makes sense that focusable elements have activation behavior and that you can trigger that by both the keyboard and mouse. At least the spec should say what elements map enter to click now. Except for perhapstextarea and a few form controls, I don't see why some should and others not, though. Maybe it should be a blacklist? I'm not sure it should go further then suggesting Enter to be the key for performing form submission, etc. After all, there's a lot of clients out there without an Enter key. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Scroll events + bubbling?
On Mon, 14 Jul 2008 20:36:12 +0200, Brady Eidson [EMAIL PROTECTED] wrote: From the current spec: onscroll - Must be invoked whenever a scroll event is targeted at or bubbles through the element. Yet IE and Firefox don't, and WebKit is currently considering matching them for compatibility... it seems that folks agree scroll events shouldn't bubble. Can we update the spec to match this? onscroll is just an event listener just like the other on* attributes are. They do not define how events are dispatched and whether these are bubbling, cancable, et cetera. (I haven't tested this but it might very well be that if you dispatch a custom bubbling event named scroll the onscroll attribute of an ancestor element, of the element on which you dispatch it, might very well trigger.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] keygen element
On Mon, 14 Jul 2008 13:12:35 +0200, Lars [EMAIL PROTECTED] wrote: I have written a little text now which have some documentation and info about this attribute. Where should I send this, and to whom? And does anyone have any info I can add to the txt? It seems like a good start, however, it currently does not say too much on what the browser has to do. The document explains authors how they can make use of it. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080714/07ea5534/attachment.txt For instance, does the browser actually check the Content-Type of the form submission response? How does it parse the response? How does the browser need to sign subsequent requests? (Now I see you need Apache configuration for various things this feature seems quite a bit more complicated than I anticipated. I knew it was important to support it, but never actually played with it so far.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Should enter be mapped to click?
On Tue, 15 Jul 2008 09:50:25 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 14 Jul 2008, Aaron Leventhal wrote: Now that tabindex can be used on any element to make it focusable, it makes sense that it should be possible to trigger a click on those elements with the keyboard. Opera maps Enter to click. As far as I know, other browsers only do that for a few elements likea. What do people think? Should it be spec'd? 3.4.1.7. Interactive content, paragraph 3: | When activation is performed via some method other than clicking the | pointing device, the default action of the event that triggers the | activation must, instead of being activating the element directly, be to | fire a click event on the same element. Last I checked that doesn't say each focusable element actually gets activation behavior as well. Here's an example: div tabindex=0 onclick=alert(0)TEST/div The specification states that only certain elements are interactive content, not everything that's focusable. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] pushState
On Sun, 03 Aug 2008 22:47:24 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Personally I think keeping the URL is fine. We can never entirely prevent pages from having bugs. But instead encourage the safe transitions, and always use safe-looking transitions in examples in the spec. FWIW, I think the URL argument is the best part of this feature. I don't want to lose it! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Ghosts from the past and the semantic Web
On Thu, 28 Aug 2008 14:00:09 +0200, Russell Leggett [EMAIL PROTECTED] wrote: I actually think that using custom microformat-like conventions with classes or tags is really not as robust a solution as what is being attempted with RDFa (I honestly did not know much about RDFa before this conversation). However, while people keep suggesting classes, I have yet to hear anyone suggest the data- attributes. Maybe it was said or implied elsewhere, but it seems like a good fit here. Instead of requiring the addition of about or property attributes, just use data-about or data-property. It may not be ideal, but it fits with the existing spec. Actually, data- attributes are not intended for this purpose. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] TH scope=TBODY
On Thu, 28 Aug 2008 21:51:35 +0200, Andy Mabbett [EMAIL PROTECTED] wrote: Hello, I can imagine instances where it would make sense to allow: TH scope=TBODY (or =THEAD/ TFOOT, for that matter) before I expand on that, has anyone made similar suggestions previously, or done any related work (I have searched, without success)? Or does scope=ROWGROUP cover that? rowgroup does indeed cover that scenario. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] RDFa statement consistency
On Thu, 28 Aug 2008 23:29:22 +0200, Ben Adida [EMAIL PROTECTED] wrote: Kristof Zelechovski wrote: HTML5 is too crucial as a technology to allow arbitrary experimentation. Arbitrary? Plus, consider the risk to HTML5: nothing. Browsers don't need to do anything (except make the attributes available in the DOM, which they would probably do anyways.) This is just about what validates and what doesn't. FWIW, when considering language complexity, just considering whether it impacts user agents seems naïve. Eg, it impacts people reading the specification, people writing documentation, people writing books, etc. Adding attributes is certainly not without cost even if browsers have to do nothing at all. (Also, given examples such as Ubiquity, the idea is that it actually does impact user agents in nontrivial ways long term.) The idea and premise of RDF is sort of attractive (people being able to do their own thing, unified data model, etc), though I agree with others that the complexity (lengthy URIs, qname/curie cruft) is an issue. Especially given the copy paste authors you want to enable this for, down the road. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] RDFa statement consistency
On Thu, 28 Aug 2008 23:55:07 +0200, Ben Adida [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: FWIW, when considering language complexity, just considering whether it impacts user agents seems naïve. Eg, it impacts people reading the specification, people writing documentation, people writing books, etc. Fair enough. Doesn't SQL in the browser affect all of those things by at least an order of magnitude more? Which SQL spec, given that no SQL engine perfectly abides by any of the SQL standards? What kind of transaction support and locking? SQL actually doesn't affect the HTML5 language, but it's a certainly a complex feature. I don't really think it makes sense to compare that feature to RDF though... (Because as far as I can tell we're not talking about adding an RDF triple store to browsers.) Adding attributes is certainly not without cost even if browsers have to do nothing at all. The cost is small when we've already written a lot of the documentation and specs for how this would work (in XHTML, but it's all DOM-based.) No, it makes the language more complex. That's a significant cost. (Also, given examples such as Ubiquity, the idea is that it actually does impact user agents in nontrivial ways long term.) Ubiquity is a plug-in. The user-agents themselves don't have to support those features directly, at least not now. not now was my point, indeed. The SQL-in-the-browser spec affects user-agents quite a bit more, since they actually *have* to provide SQL capabilities, otherwise they're not conformant. Yes, though again, that's a totally different feature. Supporting (dynamic) CSS layout probably costs us a lot more, yet having that doesn't imply we should simply add support for everything that is less complex. The idea and premise of RDF is sort of attractive (people being able to do their own thing, unified data model, etc), I'm glad this point is coming across. though I agree with others that the complexity (lengthy URIs, qname/curie cruft) is an issue. Especially given the copy paste authors you want to enable this for, down the road. I'm confused. CopyPaste is meant to abstract out the complexity for simple web publishers. The point is that the Web author would most likely forget the namespace indirection: html xmnls:foo=bar ... p property=foo:baz ... /p Anyway, I wasn't planning on completely diving into this permathread. Have fun! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] RDFa uses CURIEs, not QNames
On Fri, 29 Aug 2008 07:08:37 +0200, Manu Sporny [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: The idea and premise of RDF is sort of attractive (people being able to do their own thing, unified data model, etc), though I agree with others that the complexity (lengthy URIs, ***qname***/curie cruft) is an issue. We do not use QName's in RDFa - there is not QName/CURIE cruft! We went to great lengths to avoid QNames, please take the time to understand why (it's because of the cruft that you complain about): As far as I can tell they both have the same (subset of) problems. They create a level of indirection and require keeping namespace prefix declarations around. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] A slightly different use-case for shared workers
On Fri, 29 Aug 2008 16:20:21 +0200, Cameron McCormack [EMAIL PROTECTED] wrote: Robert O'Callahan: Why not just open new window and move the playing audio element from the old window into the new window? You might need to call play() on it again in the new window, but you shouldn't lose your place in the stream. Why shouldn’t that throw a WRONG_DOCUMENT_ERR? Because browsers knowingly violate the DOM and we now plan on updating the DOM specification to match the arguably more sane behavior of not throwing (and simply modifying ownerDocument). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] List of differences between whatwg and w3c spec?
On Thu, 11 Sep 2008 21:38:52 +0200, Aaron Swartz [EMAIL PROTECTED] wrote: I notice there are specs for HTML5 dated today at: http://www.whatwg.org/specs/web-apps/current-work/ http://www.w3.org/html/wg/html5/ diff -u shows a lot of difference, but most are cosmetic. (I gather they're there because Hixie disagrees with some W3C pubrules but can't get them changed.) Is there any page that lists the substantive differences? Presumably the generation of the drafts is automated; is the source file for the drafts published? The header is one of these (W3C, WHATWG): http://www.whatwg.org/specs/web-apps/current-work/header-w3c http://www.whatwg.org/specs/web-apps/current-work/header-whatwg This file is then appended to those headers: http://www.whatwg.org/specs/web-apps/current-work/source Then they are processed through a tool that is not accessible to the general public. (gsnedders is working on a tool that does the same, is completely open, and open source.) The output is then the two links you showed above. (Nobody mentioned the specifics so I thought I'd give another reply to this e-mail.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] defining new HTTP headers
On Thu, 25 Sep 2008 10:36:01 +0200, Julian Reschke [EMAIL PROTECTED] wrote: As far as I can tell, you are speaking of a new header. This can be defined in an IETF document, in a W3C document, and in other places. You just need to register it with IANA, and expert review (hopefully) will happen. Not really :/ http://www.ietf.org/mail-archive/web/ietf-message-headers/current/index.html What's true is that you can't require existing HTTP/1.1 clients to send it with every POST request (did anybody seriously suggest that?). The suggestion was for POST requests the browser makes based on Web APIs (e.g., XMLHttpRequest, form, etc.). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] defining new HTTP headers
On Thu, 25 Sep 2008 11:07:54 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: ... What's true is that you can't require existing HTTP/1.1 clients to send it with every POST request (did anybody seriously suggest that?). The suggestion was for POST requests the browser makes based on Web APIs (e.g., XMLHttpRequest, form, etc.). OK, so that sounds like syntax and semantics of Origin should be defined in a separate spec, and then XmlHttpRequest and HTML5 can make a normative requirement (for their scenarios) about when it needs to be supplied. That's the way it is... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] defining new HTTP headers
On Thu, 25 Sep 2008 11:16:06 +0200, Julian Reschke [EMAIL PROTECTED] wrote: So what's the spec defining Origin? I thought it was XmlHttpRequest(2)? Access Control for Cross-Site Requests. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] defining new HTTP headers
On Thu, 25 Sep 2008 11:28:21 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: http://www.ietf.org/mail-archive/web/ietf-message-headers/current/index.html So, is there a case where IANA registration was attempted and expert review did *not* happen? This e-mail from January 27 never got a reply: http://www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00085.html Several changes to the specification have since then be made, including changing header names again, but that happened in August. Between January and August nobody got back to me. I'm not really inclined to get the Provisional Message Header Field Registry fixed at this point. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] defining new HTTP headers
On Thu, 25 Sep 2008 12:04:46 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: This e-mail from January 27 never got a reply: http://www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00085.html Several changes to the specification have since then be made, including changing header names again, but that happened in August. Between January and August nobody got back to me. I'm not really inclined to get the Provisional Message Header Field Registry fixed at this point. Nobody is expected to get back to you. I didn't know that. As far as I can tell, you are supposed to email IANA: http://tools.ietf.org/html/rfc3864#section-4.3: Send a copy of the template to the designated email discussion list [33] [34]. Allow a reasonable period - at least 2 weeks - for discussion and comments, then send the template to IANA at the designated email address [35]. IANA will publish the template information if the requested name and the specification document meet the criteria noted in Section 4.1 and Section 4.2.2, unless the IESG or their designated expert have requested that it not be published (see Section 4.4). IESG's designated expert should confirm to IANA that the registration criteria have been satisfied. Did you? No, I was awaiting a reply. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, 25 Sep 2008 22:17:00 +0200, Collin Jackson [EMAIL PROTECTED] wrote: 6) New cookie attribute: The httpOnly cookie flag allows sites to put restrictions on how a cookie can be accessed. We could allow a new flag to be specified in the Set-Cookie header that is designed to prevent CSRF and UI redress attacks. If a cookie is set with a sameOrigin flag, we could prevent that cookie from being sent on HTTP requests that are initiated by other origins, or were made by frames with ancestors of other origins. In a CSRF or UI redress attack scenario, it will appear as though the user is not logged in, and thus the HTTP request will be unable to affect the user's account. This flag could potentially use the cookie concept of same origin rather than the HTML5 concept of same origin: ignore port, ignore scheme unless secure flag is set, domain attribute can be used to relax domain comparison. Pros: - Only need to change one line of code where the login cookie is set, entire site is protected Cons: - Opt-in (sites remain vulnerable unless action is taken) - Would need to test this to make sure it doesn't break legacy browser cookie handling (Adam and I got this idea from someone else, but we don't remember who it was.) Probably somewhere on the public-webapps or public-webapi list in context of cross-domain XMLHttpRequest. Anyway, this wouldn't work for login based on HTTP authentication or based on IP address or something. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
