Re: [whatwg] [media] startOffsetTime, also add startTime?
Thanks for the spec changes, startDate is now in a state where I'd be happy to implement it! More comments inline: On Tue, 03 Apr 2012 02:21:43 +0200, Ian Hickson i...@hixie.ch wrote: On Fri, 9 Mar 2012, Philip Jägenstedt wrote: On Thu, 08 Mar 2012 19:16:40 +0100, Ian Hickson i...@hixie.ch wrote: On Thu, 8 Mar 2012, Philip Jägenstedt wrote: I really don't know what startOffsetTime is intended for. AFAICT it's a piece of metadata that you could just as well provide out-of-band, but for convenience it is exposed via the DOM API. I think it could be handy to have and would like to implement it, but I don't understand if it's any different from other metadata like producer or location of a video. The startOffsetTime is useful for controllers who want to display a controller with real times, e.g. like TiVo's DVR UI, even when the underlying media resource has some more or less arbitrary timeline. e.g. if a TV station starts broadcasting on some Friday at 2pm, that would be its zero time for its timeline, but eight months later, a user joining that stream doesn't care that the stream is 21 megaseconds old -- they just want to see 14:20 as the time that corresponds to what was streaming at 2:20pm. This makes sense, and the new spec example makes it clearer. It could also do with a good example. The spec says: If the media resource specifies an explicit start time and date, then that time and date should be considered the zero point in the media timeline; the timeline offset will be the time and date, exposed using the startOffsetTime attribute. I interpret this as a date at currentTime=0 in the spec's definition of currentTime Right. and currentTime=-initialTime (unless media fragments are used) in the Opera/Firefox definition of currentTime. Not sure what this means. In current Opera and Firefox the timeline is always normalized to start at 0, so the time that corresponds to 0 in the original timeline would be at a negative currentTime. We will have to change this at the same time as implementing startDate, since otherwise everything will be a mess... Finally, what about initialTime? It can be set to a non-zero value at two points in the spec: Establish the media timeline for the purposes of the current playback position, the earliest possible position, and the initial playback position, based on the media data. If either the media resource or the address of the current media resource indicate a particular start time, then set the initial playback position to that time and Does any format expose something like this in-band? I don't know of any that do and how to implement this, so the only thing that remains is exposing the start time of media fragments. This seems rather useless to me, so unless someone has already implemented initialTime and explain what it means, I suggest dropping it from the spec. The address of the current media resource can indicate a particular start time if you implement media fragments. Yes, but why do we need to expose that in the DOM API, what is the use case? Allows controllers to trivially implement UI to jump back to where the stream started, while still showing the full seekable range. Unless I'm missing something, initialTime is just the initial value of currentTime, so this is already easy. Also, if media fragments are not used, just setting currentTime=0 will clamp and seek to the earliest position. However, I've never actually seen such UI for video, do you have a real world example? It seems to me like this is a 1% use case that is already easy to solve and that it's not worth adding an API to go from easy to trivial. On Tue, 13 Mar 2012, Philip Jägenstedt wrote: In the absence of an explicit timeline, the zero time on the media timeline should correspond to the first frame of the media resource. For static audio and video files this is generally trivial. For streaming resources, if the user agent will be able to seek to an earlier point than the first frame originally provided by the server, then the zero time should correspond to the earliest seekable time of the media resource; otherwise, it should correspond to the first frame received from the server (the point in the media resource at which the user agent began receiving the stream). There are multiple problems here, and I think it's responsible for some of the confusion. * What is an explicit timeline? For example, does an Ogg stream that starts with a non-zero timestamp have an explicit timeline? If there's a timestamp in the resource, then yes, it has an explicit timeline. That seems self-evident, but if you can think of a way that I could clarify this, I would be happy to do so. An example of a video resource without an explicit timeline would be a multipart/x-replace JPEG stream. There, the time between the frames is determined by the server's transmission rate, and the data itself has no timing information.
Re: [whatwg] Readiness of script-created documents
On Mon, Apr 2, 2012 at 11:29 AM, Jonas Sicking jo...@sicking.cc wrote: Everyone returning the same thing isn't the only goal. First of all what's the purpose of all browsers doing the same thing if that same thing isn't useful? No one is worse off and stuff works even if an author somewhere relies on a crazy edge case behavior. Second, you are assuming that people are actually aware of this edge case and account for it. Here it seems just as likely to me that generic code paths would result in buggy pages given IEs behavior, and correct behavior given the specs behavior. Third, if no-one is hitting this edge case, which also seems quite plausible here, then it having a while longer without interoperability won't really matter what we do and doing the most useful thing seems like the best long-term goal. On the other hand, for cases no one is hitting, it's probably not worthwhile to spend time trying to get the behavior to change from what was initially introduced. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Default encoding to UTF-8?
On Wed, Jan 4, 2012 at 12:34 AM, Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no wrote: I mean the performance impact of reloading the page or, alternatively, the loss of incremental rendering.) A solution that would border on reasonable would be decoding as US-ASCII up to the first non-ASCII byte Thus possibly prescan of more than 1024 bytes? I didn't mean a prescan. I meant proceeding with the real parse and switching decoders in midstream. This would have the complication of also having to change the encoding the document object reports to JavaScript in some cases. and then deciding between UTF-8 and the locale-specific legacy encoding by examining the first non-ASCII byte and up to 3 bytes after it to see if they form a valid UTF-8 byte sequence. Except for the specifics, that sounds like more or less the idea I tried to state. May be it could be made into a bug in Mozilla? It's not clear that this is actually worth implementing or spending time on its this stage. However, there is one thing that should be added: The parser should default to UTF-8 even if it does not detect any UTF-8-ish non-ASCII. That would break form submissions. But trying to gain more statistical confidence about UTF-8ness than that would be bad for performance (either due to stalling stream processing or due to reloading). So here you say tthat it is better to start to present early, and eventually reload [I think] if during the presentation the encoding choice shows itself to be wrong, than it would be to investigate too much and be absolutely certain before starting to present the page. I didn't intend to suggest reloading. Adding autodetection wouldn't actually force authors to use UTF-8, so the problem Faruk stated at the start of the thread (authors not using UTF-8 throughout systems that process user input) wouldn't be solved. If we take that logic to its end, then it would not make sense for the validator to display an error when a page contains a form without being UTF-8 encoded, either. Because, after all, the backend/whatever could be non-UTF-8 based. The only way to solve that problem on those systems, would be to send form content as character entities. (However, then too the form based page should still be UTF-8 in the first place, in order to be able to take any content.) Presumably, when an author reacts to an error message, (s)he not only fixes the page but also the back end. When a browser makes encoding guesses, it obviously cannot fix the back end. [ Original letter continued: ] Apart from UTF-16, Chrome seems quite aggressive w.r.t. encoding detection. So it might still be an competitive advantage. It would be interesting to know what exactly Chrome does. Maybe someone who knows the code could enlighten us? +1 (But their approach looks similar to the 'border on sane' approach you presented. Except that they seek to detect also non-UTF-8.) I'm slightly disappointed but not surprised that this thread hasn't gained a message explaining what Chrome does exactly. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] [media] startOffsetTime, also add startTime?
On Tue, 3 Apr 2012, Philip Jägenstedt wrote: It could also do with a good example. The spec says: If the media resource specifies an explicit start time and date, then that time and date should be considered the zero point in the media timeline; the timeline offset will be the time and date, exposed using the startOffsetTime attribute. I interpret this as [...] currentTime=-initialTime (unless media fragments are used) in the Opera/Firefox definition of currentTime. Not sure what this means. In current Opera and Firefox the timeline is always normalized to start at 0, so the time that corresponds to 0 in the original timeline would be at a negative currentTime. I still don't really understand what you mean by start here. The idea is that all the times are unsigned, though. So if there's any way to seek to one of these times that are before what you're calling the start, then yeah, it'll be a mess, because the naive approach of simply drawing a seek bar from 0 to duration (rather than seekable.start(0) to duration) will fail. We will have to change this at the same time as implementing startDate, since otherwise everything will be a mess... So long as startDate gives the Date at media timeline's 0 point, it doesn't really matter exactly what the media timeline is. Finally, what about initialTime? [...] Yes, but why do we need to expose that in the DOM API, what is the use case? Allows controllers to trivially implement UI to jump back to where the stream started, while still showing the full seekable range. Unless I'm missing something, initialTime is just the initial value of currentTime, so this is already easy. Only if the controller is around when the video is created. Don't forget that one of the design principles of this API is that you should be able to hook up a controller at any time and have it be able to provide a fully-fledged controller. Also, if media fragments are not used, just setting currentTime=0 will clamp and seek to the earliest position. However, I've never actually seen such UI for video, do you have a real world example? It seems to me like this is a 1% use case that is already easy to solve and that it's not worth adding an API to go from easy to trivial. Yeah, that's probably fair. I've removed initialTime. An example of a video resource without an explicit timeline would be a multipart/x-replace JPEG stream. There, the time between the frames is determined by the server's transmission rate, and the data itself has no timing information. AFAIK, no browser supports any format for video that does not have timestamps. I don't think there's any practical need to say how to handle this until some implementor actually wants to do it, but if you really want to I would have been less confused if the lack of explicit timeline were portrayed as an exception, using something like multipart/x-replace as an example. I've made this more explicit using some notes. BTW, browsers do support formats that do not have explicit timelines or even explicit timings. Animated GIFs only have inter-frame timings, there's no explicit timeline. (A frame's position is implied by the number of delays that come before it.) And the usual way of sending MJPEG streams, namely multipart/x-mixed-replace, has no explicit timings whatsoever. video is designed such that these formats could be supported with the media API. * Why does the spec differentiate between static and streaming resources at all? If you receive the entire file, there's no complication with respect to streaming to a point before the first rendered frame. The distinction is not intended to be normatively detectable, it's only intended to distinguish the easy case from the harder case. Again, if you think there's some way I could clarify that, please let me know. I've removed the confusing bit about static resources vs streaming resources, so hopefully this will be clearer now. IIUC, the spec is trying to handle resources that have no timestamps, are not (known to be) finite and where the user agent will be able to seek to an earlier point than the first frame originally provided by the server, i.e. with server-side seeking. Do such resources actually exist? I don't see how they could, because how could the server seek without some concept of timestamps? You could seek to them using frame numbers. I'm not aware of such a format currently. I've added a note to that effect to the spec. All in all, simply demanding that all formats used have a timeline mapping seems like a good way to deal with this, for now at least. There are formats supported by browsers that do not have timelines. I don't think we should exclude those ab initio. Just covering all the bases in the spec doesn't mean we require anything of browsers, but it does mean that if a browser wants to
Re: [whatwg] Default encoding to UTF-8?
On Tue, 03 Apr 2012 13:59:25 +0200, Henri Sivonen hsivo...@iki.fi wrote: On Wed, Jan 4, 2012 at 12:34 AM, Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no wrote: A solution that would border on reasonable would be decoding as US-ASCII up to the first non-ASCII byte Thus possibly prescan of more than 1024 bytes? I didn't mean a prescan. I meant proceeding with the real parse and switching decoders in midstream. This would have the complication of also having to change the encoding the document object reports to JavaScript in some cases. On IRC (#whatwg) zcorpan pointed out this would break URLs where entities are used to encode non-ASCII code points in the query component. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Tue, Feb 21, 2012 at 7:36 PM, Boris Zbarsky bzbar...@mit.edu wrote: Not offhand. Again, it's been a while since I looked into this, but at the time this was being implemented in Gecko we carefully made the two-input-no-submit case not submit. I thought that was for good reason, but reskimming the bugs now I can't find the reason. It's been over 10 years, so the details are a bit hazy in my mind. :( Ten years later it's still giving me headaches, when I try to do a trivial two-input login form without a browser submit button, and find that every obvious way of hiding the submit button breaks implicit submit in one browser or another. Do I really need to stick the submit button in an overflow: hidden, 0x0 div? I know I found a less ugly workaround for this the last time I hit this... -- Glenn Maynard
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 4/3/12 5:14 PM, Glenn Maynard wrote: Ten years later it's still giving me headaches, when I try to do a trivial two-input login form without a browser submit button, and find that every obvious way of hiding the submit button breaks implicit submit in one browser or another. Do I really need to stick the submit button in an overflow: hidden, 0x0 div? I know I found a less ugly workaround for this the last time I hit this... Well, the fact that display:none makes it not submit is clearly a browser bug in the browsers it happens in. The only question is whether just not having a button at all should also submit. -Boris
Re: [whatwg] Proposal: location.parentOrigin
Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Rather than introduce topOrigin, we might be better off with alternative (1) below, making location.origin visible to descendant frames. Adam On Mon, Mar 26, 2012 at 5:09 PM, Adam Barth w...@adambarth.com wrote: == Proposal == For nested browsing contexts, expose the origin of the parent browsing context via location.parentOrigin. (For non-nested browsing context, the property would null.) == Use Case == Some widgets want to behave differently depending on the context in which they are embedded. For example, a payment widget might want to send the user to a confirmation page for most web sites but might be confortable with a more streamlined user experience when embedded on a whitelist of sites with which they have a contractual relationship. Note: There is also some connection with the use cases for X-Frame-Options and frame-ancestors. Those mechanisms address uses cases where document do not wish to be displayed in unfriendly contexts at all. This mechanism addresses use cases where widgets wish to always be displayed but wish to behave differently in different contexts. == Alternative == 1) We could make location.origin visible to across origins to child frames. This approach is somewhat more aesthetic and also lets a document query the origin of all of its containing browsing contexts. However, we don't want to expose location.origin in general because that could let an attacker learn about where redirects lead by creating an iframe and reading back it's location.origin. Exposing location.origin to child frames only mitigates this issue but would require a somewhat tricky ad-hoc security check. For that reason, it seems better to expose the origin of the parent on the child's location object directly, where the property would have a normal security check. 2) The widget provider could use a different URL for the two different versions of the widget. The widget with the streamlined experience would then use X-Frame-Options to prevent itself from being displayed in hostile environments. There are a couple of disadvantages to this alternative: a) X-Frame-Options (and frame-ancestors) require the widget to declare upfront the contexts in which it is willing to be embedded. For a payment widget that might be used by many hundreds or thousands of web sites, that's somewhat impractical. b) Each complication in the instructions for embedding the widget is costly to the widget provider because fewer developers will use the widget. For example, the widget provider might want to make it extremely easy to embed the contract-free version of the widget and then make the sales process for the streamlined use experience not require any technical changes on the part of the embedder. 3) The widget could use postMessage to communicate with the embedder and to establish the origin of the embedder. However, this requires running code in the embedder that knows how to respond to the messages appropriately. If the widget provider supplies the code, then the embedder needs to trust the widget provider to run code in its origin, which is undesirable. If the embedder provides the code, then that greatly increases the complexity of embedding the widget (see 2(b) for a related discussion). == Risks == There is some risk that exposing this information might leak information from the parent to the child iframe. For example, if the parent document's origin (e.g., it's host name) contains sensitive information, that information might be leaked to documents it chooses to display in frames. While possible, this risk seems fairly remote. Adam
[whatwg] Fullscreen changes to support dialog
So based on our discussions on IRC and in person earlier today, I think the following additions to the Fullscreen specification would provide the necessary infrastructure to support dialog: - Add a new stacking layer to the CSS 2.1 Appendix E layering model, after the current layer 10. Let's call this new layer the top layer. This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. An element in this layer is rendered in the CSS model as an atomic unit that is a sibling to the root element; overflow, opacity, masks, clips, etc, of ancestor elements do not affect it. Outlines must be rendered in their non-layer-10 position if they are specified on an element with an ancestor-or-self that is in such a stack. An element in this layer that has an ancestor-or-self that is display:none does not get rendered. The 'position' property for elements in one of these stacks computes to 'absolute', 'fixed', or 'center' if that is its specifed value, and to 'absolute' if the specified value is anything else. The containing block for such an element is the initial containing block, same as for the root element. The static position for left, right, and top are zero, unless overridden by another specification. (The dialog spec will override the static position for top.) - Define an algorithm to push an element onto the top layer, which adds a given element to this element's browsing context's viewport's stack, if the element is in a document. - Define an algorithm to yank an element from the top layer, which removes the given element from the stack it is in. When an element is removed from a document, it must be yanked from the top layer. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) Fullscreen then defines that when you make an element fullscreen, it's pushed onto the top layer, and when an element is unfullscreened, it's yanked from the top layer. The user emergency escape UI yanks all fullscreened elements from the top layer (but leaves any other elements in it; we wouldn't want dialogs to disappear when exiting full screen mode). If this works, then I'll use this for dialog. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [media] startOffsetTime, also add startTime?
On Tue, Apr 3, 2012 at 9:28 PM, Philip Jägenstedt phil...@opera.com wrote: AFAIK, no browser supports any format for video that does not have timestamps. I have patches being reviewed that add support for using MediaStreams as video sources. These do not have timestamps. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] Fullscreen changes to support dialog
This seems reasonable to me. On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson i...@hixie.ch wrote: This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. Is each element in this stack treated as having its own stacking context? I assume so, but you'd better say so. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) It's probably more work to make all non-background properties inapplicable than it would be to simply treat it like ::before/::after generated content. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] Fullscreen changes to support dialog
On Tue, Apr 3, 2012 at 5:29 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson i...@hixie.ch wrote: This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. Is each element in this stack treated as having its own stacking context? I assume so, but you'd better say so. Yes, definitely. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) It's probably more work to make all non-background properties inapplicable than it would be to simply treat it like ::before/::after generated content. Strongly agreed. For one, it's annoying to restrict things. For two, it's badly-defined what background properties are - it's possible for properties that aren't prefixed with background- to affect backgrounds (for example, image-resolution). For three, this assumes that we have thought of all possible things that can be applied by non-background properties, including properties not yet dreamed up, and decided that they're all useless. Unless there's a good reason to restrict something, keep it unrestricted. ~TJ
Re: [whatwg] Proposal: location.parentOrigin
On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) The use case is the same as in the previous email, specifically: ---8--- Some widgets want to behave differently depending on the context in which they are embedded. For example, a payment widget might want to send the user to a confirmation page for most web sites but might be confortable with a more streamlined user experience when embedded on a whitelist of sites with which they have a contractual relationship. ---8--- The payment widget might care about all of its ancestors. For example, suppose the payment operator has a relationship with store.example.com. They might wish to fall back to using a confirmation page if store.example.com is embedded as a frame in another web site (e.g., pintrest). Why don't they just ask the parent frame for their parent's origin, since they trust them? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen changes to support dialog
On Tue, 3 Apr 2012, Ojan Vafai wrote: On Tue, Apr 3, 2012 at 4:14 PM, Ian Hickson i...@hixie.ch wrote: Fullscreen then defines that when you make an element fullscreen, it's pushed onto the top layer, and when an element is unfullscreened, it's yanked from the top layer. The user emergency escape UI yanks all fullscreened elements from the top layer (but leaves any other elements in it; we wouldn't want dialogs to disappear when exiting full screen mode). Escape usually calls cancel on dialogs, no? Seems to me that if you have a dialog open, esc should cancel the dialog, otherwise it should yank all fullscreened elements. Yes, indeed. I didn't mean to specifically refer to the escape key, so much as the generic escape me out of fullscreen mode because I might be being spoofed emergency escape UI. That could just be a button that appears when you hover over the top-right of the screen, for instance. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen changes to support dialog
On Wed, 4 Apr 2012, Robert O'Callahan wrote: On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson i...@hixie.ch wrote: This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. Is each element in this stack treated as having its own stacking context? I assume so, but you'd better say so. Right, each one would be its own atomic stacking context much like a 'position:absolute' box normally is today. I agree this should be explicit in the Fullscreen spec. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) It's probably more work to make all non-background properties inapplicable than it would be to simply treat it like ::before/::after generated content. Either is fine by me. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) The use case is the same as in the previous email, specifically: ---8--- Some widgets want to behave differently depending on the context in which they are embedded. For example, a payment widget might want to send the user to a confirmation page for most web sites but might be confortable with a more streamlined user experience when embedded on a whitelist of sites with which they have a contractual relationship. ---8--- The payment widget might care about all of its ancestors. For example, suppose the payment operator has a relationship with store.example.com. They might wish to fall back to using a confirmation page if store.example.com is embedded as a frame in another web site (e.g., pintrest). Why don't they just ask the parent frame for their parent's origin, since they trust them? From my original email: ---8--- 3) The widget could use postMessage to communicate with the embedder and to establish the origin of the embedder. However, this requires running code in the embedder that knows how to respond to the messages appropriately. If the widget provider supplies the code, then the embedder needs to trust the widget provider to run code in its origin, which is undesirable. If the embedder provides the code, then that greatly increases the complexity of embedding the widget (see 2(b) for a related discussion). ---8--- Adam
Re: [whatwg] Client side value for language preference
On 02/04/2012 09:45, Steve Axthelm wrote: On 2012-03-30 Henri Sivonen hsivo...@iki.fi wrote: Is there a reason to believe that this client-side solution would be used significantly considering that the HTTP header has not been used that much? Don't know about significantly, but I recently used the HTTP headers for a group of support pages that had many localizations and would have really liked to have been able to handle the entire logic for that on the front-end. I would love it, if more sites would use these headers. As someone else pointed out, some web servers make it very easy. I would support an equivalent client-side query. The current favourite algorithm among servers seems to be to serve a language based on their perception of your current location. There are so many reasons why this causes them to serve the wrong language, it is beyond my understanding why so many sites do it. As a native English speaker living in Japan, I suffer from it every day. The HTTP headers provide a much better mechanism. Regards -Mark
Re: [whatwg] Readiness of script-created documents
On Tue, Apr 3, 2012 at 4:39 AM, Henri Sivonen hsivo...@iki.fi wrote: On Mon, Apr 2, 2012 at 11:29 AM, Jonas Sicking jo...@sicking.cc wrote: Everyone returning the same thing isn't the only goal. First of all what's the purpose of all browsers doing the same thing if that same thing isn't useful? No one is worse off and stuff works even if an author somewhere relies on a crazy edge case behavior. I think we should aim higher than that for the web platform. / Jonas
