Re: [whatwg] Video proposals
Also sprach Robert Brodrecht: Quality, size, etc. have all been goals of the Theora project, so it's not really fair to say that they haven't been considered. There is no technical reason why Theora shouldn't be specified as a baseline format. I think you took that out of context. I wasn't making a judgement about Theora. I'm sure it will get the job done as a baseline codec. I was simply saying that the WHAT WG mailing list discussion went something like: We ought to use an open codec! and someone said, Theora is open! It wasn't quite like that. Opera's experimental build, which was demoed the day the proposal went to the WHAT WG, had support for the video element and a native Theora decoder. Some conscious thinking went into picking Theora in the first place. http://my.opera.com/saito/blog/show.dml/787937 http://coolastory.blogspot.com/2007/03/sv-web-builders-event-world-premier-of.html http://www.youtube.com/watch?v=hUqC1URVytk http://www.youtube.com/watch?v=tKXomOLraXg http://www.flickr.com/photos/biao/406571288/ http://www.flickr.com/photos/mimizone/406561638/ -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Video proposals
Vladimir Vukicevic wrote: If providing content in non-Theora formats is important, the client should list the supported video formats in the Accept header, and the server can send back the right thing. [snip] Though as has been pointed out by someone else earlier in the thread, the MIME types are attached to the container formats rather than the codecs. Seeing video/quicktime doesn't tell you what codec is used inside, and likewise video/x-msvideo. Perhaps something like an Accept-codec: header (though preferably something more generic than that) is needed: Accept-codec: audio/mp3, video/theora, audio/vorbis
[whatwg] video element feedback
Thanks for all the feedback on video. There were several topics discussed. I'll cover the three most important ones first. ON THE CODEC: A number of people put forth many arguments for and against all kinds of codecs. However, very little of the feedback introduced any information that wasn't taken into account when I first drafted the proposal. The spec can't require MPEG4 or other proprietary or patent-encumbered formats or suites of formats, because of the patent situation. Unless someone is willing to do the work and pay for licenses, or get MPEG-LA and/or similar groups to waive their rights for implementations of this spec, we can't require them, as it would require certain implementors to either expose themselves to known legal risks, or be non-conformant. This doesn't stop anyone from implementing such formats if they so desire, of course. The spec doesn't require Dirac or any of the other freely implementable codecs and container formats other than Ogg, because requiring more than one would reduce the likelihood of any being implemented, and of those available, the Ogg family is more widely recognised and is arguably more mature. The spec doesn't prohibit any codec from being implemented, because doing so would be an exercise in futility -- specifications are supposed to foster interoperability, not block innovation. After all, it is from extensions to specs that most of the HTML5 features were derived. ON NATIVE UI: A large portion of the feedback concerned the way that the current spec doesn't have any features for native browser-provided UI. I completely agree that on the long term this is something we need to offer. However, we musn't bite off more than we can chew. There are several sets of use cases, some of which require browser-provided UI, and some of which need just video playback under the control of the author. If we want to have this implemented well, we need to focus the browser vendors' concentration on specific features. Since it is easier to implement first an API then a native UI, rather than first a native UI and then an API, the API has to come first. Similarly, because authors can make a UI with an API but can't sanely make an API with a native UI, providing an API provides authors with more options. If LiveJournal on YouTube or some other site wanted to allow authors to embed video without requiring the authors to have to deal with JavaScript, they could create a page that contained just the video and video playback UI, with the video URI being taken out of the query parameters of the page, and then could give people markup that embedded the video using an iframe, as in: iframe src=http://video.example.com/video.html?src=http://example.net/v193;/iframe This would be a safe mechanism, and would be relatively easy to set up. (It doesn't even require server-side support.) ON HANDLING OTHER MEDIA FORMATS: A lot of feedback concerned the necessity of introducing an element specifically for video in the first place. We could use object for this, adding multiple APIs to object for each kind of media file, defining the semantics for changing from one to the other, for content-negotiation, for disambiguating similar media types that have overlapping but not identical APIs, and so forth. However, the browser vendors would hate us. Browser vendors have repeatedly and loudly stated that overloading elements leads to implementation difficulties, resulting in poor interoperability, edge cases with strange behaviour, security bugs, and the works. Good examples of this in existing HTML browsers are object and input, both of which have had huge interoperability problems over the years, and both of which still have big issues. When it takes more than 10 years to get an element implemented well in every single browser that has tried to implement it, you have to look at why that is, and you have to learn from the mistake. In this case, the mistake is adding too much functionality to one element. Similarly, for backwards-compatibility reasons, adding anything to object is a nightmare. We'd have to carefully examine every addition to make sure it didn't clash with existing content, for instance. Furthermore, overloading an element with various APIs results in difficulties for authors. An author dealing with audio doesn't want to think about aspect ratios, and an author dealing with video doesn't want to think about plugin parameters. This doesn't mean we have to specify everything as its own element. There are media types that it doesn't make sense to support with a specific element (at least not yet); we don't want to have six dozen elements with each type having its own set of features (and bugs). We _do_ have a generic element, object, which does work for generic inclusion. It doesn't support media-specific features (like the Video API) but it works as a stop-gap until the media in question is important enough
Re: [whatwg] video element feedback
I do fully understand the points you make below, but I am not sure I fully subscribe to the logic. embed is in HTML5 specifically for plugins. However, for embed, object, iframe, and video, the spec doesn't require that UAs implement the features using plugins or using native code. For example, Mozilla natively supports SVG in embed (it doesn't require a plugin). Similarly, you could see video be implemented as a special-case plugin. That's an implementation detail and doesn't really affect the spec. I think we have then arrived at tags-for-everything. (imgvideoaudioembediframe cover everything do they not?) However, I think if object is so widely derided by everyone, than I think it needs to be depreciated sooner rather than later. On 20 Mar 2007, at 09:25, Ian Hickson wrote: Similarly, for backwards-compatibility reasons, adding anything to object is a nightmare. We'd have to carefully examine every addition to make sure it didn't clash with existing content, for instance. Furthermore, overloading an element with various APIs results in difficulties for authors. An author dealing with audio doesn't want to think about aspect ratios, and an author dealing with video doesn't want to think about plugin parameters. This doesn't mean we have to specify everything as its own element. There are media types that it doesn't make sense to support with a specific element (at least not yet); we don't want to have six dozen elements with each type having its own set of features (and bugs). We _do_ have a generic element, object, which does work for generic inclusion. It doesn't support media-specific features (like the Video API) but it works as a stop-gap until the media in question is important enough to deserve special treatment, if that happens.
[whatwg] window.opener and security
Hi, when a new window or tab is opened by a page it normally has a window.opener property that points to the window object of the original tab. This happens whether the new window is opened by a JavaScript calling window.open or by a link or form with target attribute set. If an origin check fails when comparing the locations of the old window and the popup, the normal cross-domain security policies apply. This means that popup contents from a different site will not be allowed to call methods or manipulate the DOM of the opener. However, this cross-domain security policy has one exception: the popup may set the location of its opener. This has phishing potential, particularly for webmail where opening external links in a new window is a very common use case. Hence I think it would be a good idea to let a site opt-out and specify that the popup should not have a window.opener property. For example, one could extend the features argument of window.open: window.open(url, name, 'openerproperty=0'); Thoughts? References: http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem -- Hallvord R. M. Steen
Re: [whatwg] window.opener and security
window.opener should be read-only and attempting to write to it should throw an exception. This is a similar issue to window.history, in certain browsers you can write to this with js. It has no effect, but does persist across domains. The webkit team decided to just throw an exception if a write to window.history was detected. I don't know if it ever got implemented, or even if any of the other browser vendors addressed it. On 20 Mar 2007, at 11:40, Hallvord R M Steen wrote: Hi, when a new window or tab is opened by a page it normally has a window.opener property that points to the window object of the original tab. This happens whether the new window is opened by a JavaScript calling window.open or by a link or form with target attribute set. If an origin check fails when comparing the locations of the old window and the popup, the normal cross-domain security policies apply. This means that popup contents from a different site will not be allowed to call methods or manipulate the DOM of the opener. However, this cross-domain security policy has one exception: the popup may set the location of its opener. This has phishing potential, particularly for webmail where opening external links in a new window is a very common use case. Hence I think it would be a good idea to let a site opt-out and specify that the popup should not have a window.opener property. For example, one could extend the features argument of window.open: window.open(url, name, 'openerproperty=0'); Thoughts? References: http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and- security-an-unfixable-problem -- Hallvord R. M. Steen
Re: [whatwg] window.opener and security
2007/3/20, Gareth Hay [EMAIL PROTECTED]: window.opener should be read-only and attempting to write to it should throw an exception. It was possible to set window.opener in IE, alas, I do not remember which version :( But it has been fixed, AFAIK. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] window.opener and security
On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote: window.opener should be read-only and attempting to write to it should throw an exception. I don't really see why setting opener would be dangerous, so I disagree that it should throw. Anyway, that is a different issue. What I'm talking about is the built-in behaviour - the browser itself sets window.opener in all popups, and there is currently no way to open a popup that is prevented from changing the location of its opener. (An exception is Opera applying a stricter security policy if the opener is an https page so in this case popup can't set location of its opener, but I'm not sure if the other UAs do this.) This is a similar issue to window.history, in certain browsers you can write to this with js. It has no effect, but does persist across domains. The webkit team decided to just throw an exception if a write to window.history was detected. I don't know if it ever got implemented, or even if any of the other browser vendors addressed it. On 20 Mar 2007, at 11:40, Hallvord R M Steen wrote: Hi, when a new window or tab is opened by a page it normally has a window.opener property that points to the window object of the original tab. This happens whether the new window is opened by a JavaScript calling window.open or by a link or form with target attribute set. If an origin check fails when comparing the locations of the old window and the popup, the normal cross-domain security policies apply. This means that popup contents from a different site will not be allowed to call methods or manipulate the DOM of the opener. However, this cross-domain security policy has one exception: the popup may set the location of its opener. This has phishing potential, particularly for webmail where opening external links in a new window is a very common use case. Hence I think it would be a good idea to let a site opt-out and specify that the popup should not have a window.opener property. For example, one could extend the features argument of window.open: window.open(url, name, 'openerproperty=0'); Thoughts? References: http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and- security-an-unfixable-problem -- Hallvord R. M. Steen -- Hallvord R. M. Steen
Re: [whatwg] window.opener and security
Well, window.opener is conceptually a link from child to parent. Can you give a valid use-case for adoption of the child to another parent? On 20 Mar 2007, at 13:00, Hallvord R M Steen wrote: On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote: window.opener should be read-only and attempting to write to it should throw an exception. I don't really see why setting opener would be dangerous, so I disagree that it should throw. Anyway, that is a different issue. What I'm talking about is the built-in behaviour - the browser itself sets window.opener in all popups, and there is currently no way to open a popup that is prevented from changing the location of its opener. (An exception is Opera applying a stricter security policy if the opener is an https page so in this case popup can't set location of its opener, but I'm not sure if the other UAs do this.)
Re: [whatwg] window.opener and security
On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote:
Well, window.opener is conceptually a link from child to parent.
Can you give a valid use-case for adoption of the child to another
parent?
Again: We are off-topic. This isn't what I'm trying to discuss in this thread.
However, here are two use cases for you:
1) I don't want the next page to mess with opener:
window.opener=null;
location.href='http://some-untrusted-location/';
(basically what sites should do today to work around the phishing
potential issue, but AFAIK none do.)
2) I have contents in an IFRAME that I want to talk directly to MY opener:
document.getElementsByTagName('iframe')[0].contentWindow.opener=self.opener;
What are your exploit cases where setting .opener is so dangerous
that it should throw? Note that making it throw also means being
backwards incompatible with
var opener='Once upon a time, ';
which might be far-fetched but certainly will exist somewhere if
browsers haven't thrown exceptions so far.
Now if you have time I'd like some comments on the proposal
window.open(url,name, 'openerproperty=0');
;)
On 20 Mar 2007, at 13:00, Hallvord R M Steen wrote:
On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote:
window.opener should be read-only and attempting to write to it
should throw an exception.
I don't really see why setting opener would be dangerous, so I
disagree that it should throw. Anyway, that is a different issue. What
I'm talking about is the built-in behaviour - the browser itself sets
window.opener in all popups, and there is currently no way to open a
popup that is prevented from changing the location of its opener.
(An exception is Opera applying a stricter security policy if the
opener is an https page so in this case popup can't set location of
its opener, but I'm not sure if the other UAs do this.)
--
Hallvord R. M. Steen
Re: [whatwg] window.opener and security
On 3/20/07, Hallvord R M Steen [EMAIL PROTECTED] wrote: http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem I believe you'll find that Gmail does not have this problem, because when it uses window.open, it opens a gmail page which then triggers a server side redirect, and that destroys the window.opener link. IOW, AFAIU it's a solved problem. It's probably safe to assume it isn't patented.
Re: [whatwg] window.opener and security
Well, I don't think it is off-topic.
You are trying to justify writing to a property I think should be
read-only.
I am asking you why you think this should be possible.
Anyway, for use case 1 - If you are worried about phishing attacks,
you should be using some sort of
onunload handler trapping to null window.opener. Then you can be sure
it won't be absued by anyone, even
if the user leaves your site by typing in a new uri.
For case 2, you have an iframe in a popup wanting to communicate with
the opener?
what is wrong with window.opener.opener ?
I personally think that as soon as the domain changes the UA should
null window.opener, but if it doesn't you can work around it as I
said, and I think you have a non-existent problem in case 2.
*back to topic*
I don't think you need this property, you are free to send null to
the child window's opener as things are now, and I would argue for
making the property read-only in any future spec anyway, making the
UA responsible for security.
Gareth
On 20 Mar 2007, at 13:21, Hallvord R M Steen wrote:
On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote:
Well, window.opener is conceptually a link from child to parent.
Can you give a valid use-case for adoption of the child to another
parent?
Again: We are off-topic. This isn't what I'm trying to discuss in
this thread.
However, here are two use cases for you:
1) I don't want the next page to mess with opener:
window.opener=null;
location.href='http://some-untrusted-location/';
(basically what sites should do today to work around the phishing
potential issue, but AFAIK none do.)
2) I have contents in an IFRAME that I want to talk directly to MY
opener:
document.getElementsByTagName('iframe')
[0].contentWindow.opener=self.opener;
What are your exploit cases where setting .opener is so dangerous
that it should throw? Note that making it throw also means being
backwards incompatible with
var opener='Once upon a time, ';
which might be far-fetched but certainly will exist somewhere if
browsers haven't thrown exceptions so far.
Now if you have time I'd like some comments on the proposal
window.open(url,name, 'openerproperty=0');
;)
On 20 Mar 2007, at 13:00, Hallvord R M Steen wrote:
On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote:
window.opener should be read-only and attempting to write to it
should throw an exception.
I don't really see why setting opener would be dangerous, so I
disagree that it should throw. Anyway, that is a different
issue. What
I'm talking about is the built-in behaviour - the browser itself
sets
window.opener in all popups, and there is currently no way to
open a
popup that is prevented from changing the location of its opener.
(An exception is Opera applying a stricter security policy if the
opener is an https page so in this case popup can't set location of
its opener, but I'm not sure if the other UAs do this.)
--
Hallvord R. M. Steen
Re: [whatwg] window.opener and security
On 20/03/07, timeless [EMAIL PROTECTED] wrote: On 3/20/07, Hallvord R M Steen [EMAIL PROTECTED] wrote: http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem I believe you'll find that Gmail does not have this problem, because when it uses window.open, it opens a gmail page which then triggers a server side redirect, and that destroys the window.opener link. This is incorrect. window.opener survives the redirect and still points to the opener window. javascript: void(window.open( 'http://hallvord.com/temp/redir.php')) -- Hallvord R. M. Steen
Re: [whatwg] window.opener and security
On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote: Anyway, for use case 1 - If you are worried about phishing attacks, you should be using some sort of onunload handler trapping to null window.opener. Yet you are arguing that it should be impossible to set window.opener. If you had your way that unload handler would simply throw an exception... I will not follow up this discussion further because it is not relevant for the proposed window.open extension. I still think it would be useful to allow a page to open a popup without a window.opener property to protect itself from malicious address modification. -- Hallvord R. M. Steen
Re: [whatwg] window.opener and security
2007/3/20, Hallvord R M Steen [EMAIL PROTECTED]:
On 20/03/07, timeless [EMAIL PROTECTED] wrote:
On 3/20/07, Hallvord R M Steen [EMAIL PROTECTED] wrote:
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem
I believe you'll find that Gmail does not have this problem, because
when it uses window.open, it opens a gmail page which then triggers a
server side redirect, and that destroys the window.opener link.
This is incorrect. window.opener survives the redirect and still
points to the opener window.
javascript: void(window.open( 'http://hallvord.com/temp/redir.php'))
I don't know what GMail is doing, but I think a
window.open('','_self') would destroy the original window.opener.
Regards,
Martijn
Re: [whatwg] video element feedback
Ian Hickson wrote:
On Sun, 18 Mar 2007, Anne van Kesteren wrote:
I just played some more with our internal implementation (Opera's) and
noticed that our pause() really is like togglePause() in the HTML5
Having pause() always pause is better because it means that you're not
likely to end up in state where the UI says one thing but the UA does
another (especially when you combine this with UA-provided UI).
Agreed.
I only included togglePause() because Flash supports it and some people asked for
it; I'm not convinced we should keep it.
I'm in favour of dropping it. It's an unnecessary API for browsers to
support. It adds nothing that can't be done with play()/pause() and an
if statement.
if (video.state == HTMLVideoElement.PAUSED) {
video.play();
} else {
video.pause();
}
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] window.opener and security
I think you are deliberately missing the point now... On 20 Mar 2007, at 14:50, Hallvord R M Steen wrote: On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote: Anyway, for use case 1 - If you are worried about phishing attacks, you should be using some sort of onunload handler trapping to null window.opener. Yet you are arguing that it should be impossible to set window.opener. If you had your way that unload handler would simply throw an exception... As was clearly stated, I showed a workaround and then suggested it should be up to the UA to handle this situation. It is not helpful to deliberately misunderstand points, and quote them out of context. I suggest you re-read my mail. I will not follow up this discussion further because it is not relevant for the proposed window.open extension. I still think it would be useful to allow a page to open a popup without a window.opener property to protect itself from malicious address modification. I also clearly stated on topic why I don't think this is required. So that you didn't miss the point again, (deliberately or not) 1) Either it is your responsibility to handle the nulling of the property *or* 2) It is the UA's. I personally think the UA should handle it (as stated previously) **BUT** if they do not, you *ARE* responsible for programming correctly and using an unload to null the property when someone navigates away. **AND** you seem to want this extension to cure a problem, that is also cured by window.opener.opener Gareth
Re: [whatwg] window.opener and security
It would appear that at least the WebKit team agree about the window.opener being read-only. It has resisted all attempts by me to null it or re-assign it, and as soon as the domains no longer match exceptions are thrown. From a security point of view I think this is sufficient to prevent your phishing example.
Re: [whatwg] video element feedback
Lachlan Hunt wrote: Ian Hickson wrote: I only included togglePause() because Flash supports it and some people asked for it; I'm not convinced we should keep it. I'm in favour of dropping it. +1. Jeff Cutsinger
Re: [whatwg] video element feedback
On 3/20/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sat, 17 Mar 2007, Shadow2531 wrote:
Video content must be rendered inside the element's playback area such
that the video content is shown centered in the playback area at the
largest possible size that fits completely within it, with the video
content's aspect ratio being preserved. Thus, if the aspect ratio of the
playback area does not match the aspect ratio of the video, the video
will be shown letterboxed.
So, that also means that scaletofit in my examples is implied by that?
Yes.
Thanks.
So, if one used video src=200x200.ogg style=width: 800px; height:
800px;/video , there'd be no way to make the video display at 200
x 200 because it would always scale?
If so, if one wanted to simulate the look I'm describing, would one
have to do the following for example?
figure style=width: 800px; height: 800px; background: #000;
video src=200x200.ogg style=width: 200px; height: 200px;/video
/figure
(Just want to be sure.)
On Fri, 16 Mar 2007, Shadow2531 wrote:
A video might be split into separate files (chapters). A playlist is
needed to provide consecutive playback without user interaction and to
provide view of your choices. If you've ever watched episodes in parts
on youtube, you might see why this is important.
Does YouTube support this? I thought YouTube didn't support this, which
would suggest it's not a high priority...
For youtube, if you play a show that's split up into parts, after the
first part is finished, the flash will *sometimes* display a link to
the next part that you can click on. However, because it's not
automatic, it's not as friendly (depending on the desire of the user).
But, when the next part is not provided at all, it's really
unfriendly.
So, you are correct. Youtube does not do playlists to the extent I was
referring.
Given the low priority for them and the note about JS being required,
a JS simulation of playlists will do.
However, what if JS is turned off and you want to do playlists?
If JS is turned off, applications won't work. :-) Just like when you turn
JS off and try to use Google Calendar, or turn off Flash and try to use
YouTube. In v2 we can add UI features to handle this, though, such as:
True. Without a default UI and or support for params that provide
initial state, with JS off, the video won't do anything.
.loop, .startpos
loop = false | true
autostart = true | false
startpos = 0 | specified pos
Could you elaborate on the use cases for these?
video src=VideoIWasWatching.ogg
param name=startpos value=value gotten from cookie where I left off
at
/video
If the data has to be gotten from a cookie, wouldn't a JS seek() not be
better? You'll need JS to save the position anyway.
This is another case where I assumed the video element would be usable
without JS. Anyway, the cookie value written out by a php script was
just one example. The saved position could be gotten other ways.
video src=AwesomeMusicVideo.ogg
param name=loop value=true
/video
Wouldn't the decision of whether to loop or not be a user decision? UAs
can provide a loop option as a checkable item on a context menu. I'd hate
to go to a site and have a video keep looping.
I'm thinking more along the lines of a local HTML page that embeds a
local video (one of your favorites for example) where when you load
the page (via a bookmark or a panel for example), it automatically
starts and is set to loop (because you authored it that way).
This is also another use case for playlists. One might create a local
Opera video player panel, which like winamp, foobar, vlc etc., would
support playlists. (Many have already used OBJECT and plugins for
that.)
In the cases where you just want to play the video, it seems odd to
require JS to do it (not saying it's difficult). However, one can get
used to that. When Audio() was added, JS being a requirement was a
given because there was no element to go along with it.
Page where a user is expecting a video to play.
video src=file.ogg
param name=autostart value=true
/video
We got a bunch of feedback from people saying never autoplay!. :-)
Again, the spec allows users to control this now.
Because it's abused by many. Not allowing it would probably be a good deterrent.
So, this is all that is needed to do autostart?
window.onload = function() {
document.getElementsByTagName(video)[0].play();
};
However, if JS is needed for the video element to function at all, then
the video element needs to fall back if JS is turned off.
Interesting point.
Yes, since JS is required, if JS is off, the browser should display
the alternate content.
You can do this with JS, of course (and that's the
preferred way; hide the fallback when you have JS).
Are you saying that with JS on, the fallback content will be displayed
in addition to the video and you have to use JS to hide the fallback
content like the following?
window.onload = function() {
var
Re: [whatwg] window.opener and security
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem
javascript: void(window.open( 'http://hallvord.com/temp/redir.php'))
I don't know what GMail is doing, but I think a
window.open('','_self') would destroy the original window.opener.
That's a nice idea. It works in Firefox but fails in IE and Opera.
--
Hallvord R. M. Steen
Re: [whatwg] window.opener and security
1) Either it is your responsibility to handle the nulling of the property *or* 2) It is the UA's. The UA can not do this. It would break legacy pages by resetting window.opener if content comes from a different server. I personally think the UA should handle it (as stated previously) **BUT** if they do not, you *ARE* responsible for programming correctly and using an unload to null the property when someone navigates away. Wouldn't it then be cleaner to be able to tell the UA in advance that the window should not have an .opener property? **AND** you seem to want this extension to cure a problem, that is also cured by window.opener.opener You mean window.top.opener . No, that issue is in no way related to the suggested extension. -- Hallvord R. M. Steen
Re: [whatwg] video element feedback
On Tue, 20 Mar 2007 16:18:16 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
However, if JS is needed for the video element to function at all,
then
the video element needs to fall back if JS is turned off.
Interesting point.
Yes, since JS is required, if JS is off, the browser should display
the alternate content.
Disagreed. You can still start the video with the context menu or from the
separate window mode or full screen, or whatever (non-inline) UI the
browser provides. Also, as soon as browsers have implemented what is
currently specced, it is expected that declarative features for a native
UI will be added, so then it should *not* fall back with JS off. Making it
fall back for v1 but not for v2 would just cause interoperability problems.
You would have to script the fallback, as everything else with v1. ;-)
You can do this with JS, of course (and that's the
preferred way; hide the fallback when you have JS).
Are you saying that with JS on, the fallback content will be displayed
in addition to the video and you have to use JS to hide the fallback
content like the following?
window.onload = function() {
var x = document.getElementsByTagName(video)[0];
x.play();
x.innerHTML = ;
};
That wouldn't help, as without JS you wouldn't access the fallback
content. You could do this:
p id=videofallbackfallback/p
script
var video = document.createElement(video);
video.src = foo.ogg;
var fallback = document.getElementById(videofallback);
var parent = fallback.parentNode;
var pos = fallback.nextSibling;
video.appendChild(fallback);
parent.insertBefore(video, pos);
/script
BTW, this would be a lot simpler to do if the src= attribute was made
optional:
videopfallback/p/video
script
document.getElementsByTagName(video)[0].src = foo.ogg;
/script
I think this should be allowed. Without the src attribute, the video
element could represent a placeholder where a video might have been
relevant (e.g. if scripting was enabled).
--
Simon Pieters
Re: [whatwg] window.opener and security
On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote: As was clearly stated, I showed a workaround and then suggested it should be up to the UA to handle this situation. It is not helpful to deliberately misunderstand points, and quote them out of context. I suggest you re-read my mail. You showed a workaround for a different problem than that which Hallvord initially tried to solve. The original problem is that browsers allow cross domain setting of windowobject.location. Whether windowobject in this case comes from window.opener isn't really relevant, except that it provides a method of getting a windowobject reference. Hallvord's solution is a workaround - it addresses the ability to get that windowobject reference, even though it doesn't address the core problem. On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote: 1) Either it is your responsibility to handle the nulling of the property *or* 2) It is the UA's. I personally think the UA should handle it (as stated previously) **BUT** if they do not, you *ARE* responsible for programming correctly and using an unload to null the property when someone navigates away. I do agree about the responsibility side here. It's just doesn't address the core problem at all. **AND** you seem to want this extension to cure a problem, that is also cured by window.opener.opener No. He just gave a counterexample to your suggestion, a use case your solution would have broken. It wasn't relevant for his original proposal. Some thing I would like to add here, is that your solution doesn't do anything to solve the actual l problem case. Even if window.opener would be read only, that is just a reference to a window object. Even if that property would be read only you could still write to the location property of the window object it references. For your solution to work the read only attribute would have to cascade to all properties, something defying the nature of JavaScript. A much better solution, in my opinion, would be to make the location object safe from cross domain attacks by making it only writable from same domain, or if the document does not have a domain yet. (window.open without address) I do think this would break some sites, however. Hallvord's solution of allowing sites to disable the window.opener property and thereby preventing the writing to window.opener.location does solve the problem for that particular window object, as an opt-in security measure. The main problem I see with this approach is that if people aren't nulling the window.opener property already I don't think they would opt in for another alternative method of doing it. Actually fixing cross domain writing to the location object would. -- David liorean Andersson
Re: [whatwg] window.opener and security
On 20 Mar 2007, at 15:45, Hallvord R M Steen wrote:
1) Either it is your responsibility to handle the nulling of the
property *or*
2) It is the UA's.
The UA can not do this. It would break legacy pages by resetting
window.opener if content comes from a different server.
If this is a security point, which I take from the subject
window.opener and security it is, there is no problem with a UA
breaking an implementation that relied on insecurity.
I can't think of a single reason that when a user navigates to
another domain, you would want that domain to access your
window.opener, so the UA clearly could do this.
I personally think the UA should handle it (as stated previously)
**BUT** if they do not, you *ARE* responsible for programming
correctly and using an unload to null the property when someone
navigates away.
Wouldn't it then be cleaner to be able to tell the UA in advance that
the window should not have an .opener property?
Isn't this about security?
There is no security risk allowing your own window to access .opener.
When you switch domains, the UA either nulls it, or as is the current
case, on WebKit at least, it throws exceptions when you try to access
it.
I don't see the need for this property at all.
**AND** you seem to want this extension to cure a problem, that is
also cured by window.opener.opener
You mean window.top.opener . No, that issue is in no way related to
the suggested extension.
i didn't mean window.top.opener
document.getElementsByTagName('iframe')
[0].contentWindow.opener=self.opener;
Re: [whatwg] window.opener and security
I was clearly mislead by the window.opener and security title then On 20 Mar 2007, at 15:51, liorean wrote: On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote: As was clearly stated, I showed a workaround and then suggested it should be up to the UA to handle this situation. It is not helpful to deliberately misunderstand points, and quote them out of context. I suggest you re-read my mail. You showed a workaround for a different problem than that which Hallvord initially tried to solve. The original problem is that browsers allow cross domain setting of windowobject.location. Whether windowobject in this case comes from window.opener isn't really relevant, except that it provides a method of getting a windowobject reference. Hallvord's solution is a workaround - it addresses the ability to get that windowobject reference, even though it doesn't address the core problem. On 20/03/07, Gareth Hay [EMAIL PROTECTED] wrote: 1) Either it is your responsibility to handle the nulling of the property *or* 2) It is the UA's. I personally think the UA should handle it (as stated previously) **BUT** if they do not, you *ARE* responsible for programming correctly and using an unload to null the property when someone navigates away. I do agree about the responsibility side here. It's just doesn't address the core problem at all. **AND** you seem to want this extension to cure a problem, that is also cured by window.opener.opener No. He just gave a counterexample to your suggestion, a use case your solution would have broken. It wasn't relevant for his original proposal. Some thing I would like to add here, is that your solution doesn't do anything to solve the actual l problem case. Even if window.opener would be read only, that is just a reference to a window object. Even if that property would be read only you could still write to the location property of the window object it references. For your solution to work the read only attribute would have to cascade to all properties, something defying the nature of JavaScript. A much better solution, in my opinion, would be to make the location object safe from cross domain attacks by making it only writable from same domain, or if the document does not have a domain yet. (window.open without address) I do think this would break some sites, however. Hallvord's solution of allowing sites to disable the window.opener property and thereby preventing the writing to window.opener.location does solve the problem for that particular window object, as an opt-in security measure. The main problem I see with this approach is that if people aren't nulling the window.opener property already I don't think they would opt in for another alternative method of doing it. Actually fixing cross domain writing to the location object would. -- David liorean Andersson
Re: [whatwg] window.opener and security
1) Either it is your responsibility to handle the nulling of the property *or* 2) It is the UA's. The UA can not do this. It would break legacy pages by resetting window.opener if content comes from a different server. If this is a security point, which I take from the subject window.opener and security it is, there is no problem with a UA breaking an implementation that relied on insecurity. Breaking *any* website is a problem. Yes, security is important. But this is a problem with a clear and limited (ab)use case - mainly webmails - and we can add a feature giving those relatively few webmail sites some easy-to-use opt-in security. I can't think of a single reason that when a user navigates to another domain, you would want that domain to access your window.opener, so the UA clearly could do this. If the primary domain is www.example.com and the other domain is help.example.com the UA clearly should allow them to communicate by request. Believe me, nulling window.opener if origin check fails will break MANY sites. And now I'm going to shut up. Really :) -- Hallvord R. M. Steen
Re: [whatwg] window.opener and security
2007/3/20, liorean: Some thing I would like to add here, is that your solution doesn't do anything to solve the actual l problem case. Even if window.opener would be read only, that is just a reference to a window object. Even if that property would be read only you could still write to the location property of the window object it references. For your solution to work the read only attribute would have to cascade to all properties, something defying the nature of JavaScript. I'm not so sure. And this would be similar to a node being read-only in the DOM (see the NO_MODIFICATION_ALLOWED_ERR DOMException in http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-258A00AF) A much better solution, in my opinion, would be to make the location object safe from cross domain attacks by making it only writable from same domain, or if the document does not have a domain yet. (window.open without address) I do think this would break some sites, however. Yep, e.g. redirecting to a mirror-site. But this is a very interesting idea (similar to XMLHttpRequest not allowing cross-domain requests; you'd just need a page on the same level to issue redirects at the HTTP-level to word-around that new limitation; and this is a really sane work-around IMO). I would personally combine both suggestions: window.opener, window.top and other windowobject accessors return readonly objects when called from a page within a different domain; and within the page, constrain window.location setting (imagine someone hacks Google and adds a window.location=XXX in Google Analytics script). -- Thomas Broyer
Re: [whatwg] video element feedback
On 3/20/07, Simon Pieters [EMAIL PROTECTED] wrote:
On Tue, 20 Mar 2007 16:18:16 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
However, if JS is needed for the video element to function at all,
then
the video element needs to fall back if JS is turned off.
Interesting point.
Yes, since JS is required, if JS is off, the browser should display
the alternate content.
Disagreed. You can still start the video with the context menu or from the
separate window mode or full screen, or whatever (non-inline) UI the
browser provides. Also, as soon as browsers have implemented what is
currently specced, it is expected that declarative features for a native
UI will be added, so then it should *not* fall back with JS off. Making it
fall back for v1 but not for v2 would just cause interoperability problems.
You would have to script the fallback, as everything else with v1. ;-)
:) Understood.
You can do this with JS, of course (and that's the
preferred way; hide the fallback when you have JS).
Are you saying that with JS on, the fallback content will be displayed
in addition to the video and you have to use JS to hide the fallback
content like the following?
window.onload = function() {
var x = document.getElementsByTagName(video)[0];
x.play();
x.innerHTML = ;
};
That wouldn't help, as without JS you wouldn't access the fallback
content. You could do this:
p id=videofallbackfallback/p
script
var video = document.createElement(video);
video.src = foo.ogg;
var fallback = document.getElementById(videofallback);
var parent = fallback.parentNode;
var pos = fallback.nextSibling;
video.appendChild(fallback);
parent.insertBefore(video, pos);
/script
BTW, this would be a lot simpler to do if the src= attribute was made
optional:
videopfallback/p/video
script
document.getElementsByTagName(video)[0].src = foo.ogg;
/script
I think this should be allowed. Without the src attribute, the video
element could represent a placeholder where a video might have been
relevant (e.g. if scripting was enabled).
I see what you're saying. If the video object is still going to start
up without JS on, then you have to omit src or just do src= so it
falls back. Then, if JS is on, you can set the file so the alternate
content hides and the video object initializes.
Or, just create the element with JS and add it where you want.
--
burnout426
Re: [whatwg] window.opener and security
If the primary domain is www.example.com and the other domain is help.example.com the UA clearly should allow them to communicate by request. Believe me, nulling window.opener if origin check fails will break MANY sites. This is not the point I am making, and I feel we are not understanding one another. I don't think I understand you, and you don't understand me. I have personally written many applications which use window.open windows, iframes, and such, and have *never* needed to 'spoof' the browser into re-assigning a window. The *potential* for security breach is if cross-domain scripting is allowed, after a user has left your site. If the UA nulls window.opener at that point, then it won't break anything. How many 3rd party websites are designed to run in a popup from another domain? As I said, the WebKit folks seem to think my idea of read-only was a good one. Breaking *any* website is a problem. Yes, security is important. But this is a problem with a clear and limited (ab)use case - mainly webmails - and we can add a feature giving those relatively few webmail sites some easy-to-use opt-in security. I disagree, Apache security fixes are rolled out, and the developer is expected to cope, PHP roll out security fixes, and the developer has to cope. If the problem here is that a webmail vendor will not adjust his code to work in a secure environment, then I am astounded. If this post really isn't about security, then I think you need to address the subject and actually detail what it is about.
Re: [whatwg] video element feedback
Ian Hickson wrote: A large portion of the feedback concerned the way that the current spec doesn't have any features for native browser-provided UI. I completely agree that on the long term this is something we need to offer. However, we musn't bite off more than we can chew. There are several sets of use cases, some of which require browser-provided UI, and some of which need just video playback under the control of the author. If we want to have this implemented well, we need to focus the browser vendors' concentration on specific features. Since it is easier to implement first an API then a native UI, rather than first a native UI and then an API, the API has to come first. Similarly, because authors can make a UI with an API but can't sanely make an API with a native UI, providing an API provides authors with more options. If LiveJournal on YouTube or some other site wanted to allow authors to embed video without requiring the authors to have to deal with JavaScript, they could create a page that contained just the video and video playback UI, with the video URI being taken out of the query parameters of the page, and then could give people markup that embedded the video using an iframe, as in: iframe src=http://video.example.com/video.html?src=http://example.net/v193;/iframe This would be a safe mechanism, and would be relatively easy to set up. (It doesn't even require server-side support.) I must disagree with the focus on the comparatively complicated case (video as part of a web application) vs. the more obvious case of I just want to embed a video in my web page. If I want to embed an image in my page or blog, I just upload it somewhere and write: img src=pretty.png If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Currently I do not routinely post video in my blog nor on any of my web pages because it is non-trivial to offer it in a portable manner. Your proposed solution is still too much work for the casual author: unless some other website is prepared to help me, I have to not only upload the video but also prepare a second page containing some script and markup to implement a user-interface. (And incidentally, LiveJournal doesn't allow iframes to be used either. I'm not sure if that's a LiveJournal peculiarity or a common thing in hosted weblog systems.) Please reconsider what you are focusing on as the simple case. I'd argue that these services like Google Video and YouTube have come about largely *because* embedding video on a web page is such a pain right now. If it were just a matter of uploading the video somewhere and linking to it, authors would be able to do this themselves in most cases without the assistance of sites like YouTube, much as right now most authors don't need a website to help them present static images. I won't disagree that specifying a full user interface to be provided along with the video element is a non-trivial task, but providing just a simple UI with a play/pause button and nothing else would, I expect, pacify most people after native UI for now. Browser vendors would be free to innovate their provided UIs much as Internet Explorer and Mozilla have with their image toolbars. I maintain, therefore, that the following two things should be catered for by the spec in addition to what's already there: * By default, browsers are expected to provide at minimum a play/pause toggle button which does not interfere with the size of the movie. (This implies that it must be some kind of overlay, ensuring that the size given by the page author is the size that the video will actually play.) * An attribute is provided to disable the default buttons so that apps providing their own branded UI don't end up with confusing interfaces. I'd be interested to hear what is so difficult about the above. Browsers already do much more complicated things than this.
[whatwg] video element feedback
On Tue, 20 Mar 2007, Gareth Hay wrote:
I do fully understand the points you make below, but I am not sure I fully
subscribe to the logic.
embed is in HTML5 specifically for plugins.
However, for embed, object, iframe, and video, the spec
doesn't require that UAs implement the features using plugins or using
native code. For example, Mozilla natively supports SVG in embed (it
doesn't require a plugin). Similarly, you could see video be
implemented as a special-case plugin. That's an implementation detail
and doesn't really affect the spec.
I think we have then arrived at tags-for-everything.
(imgvideoaudioembediframe cover everything do they not?)
Oh no, there are many more types of media that exist or can exist. 3d,
smell, animation, tactile... some media don't exist in digital form
yet, but they will in due course; others exist in niche markets but may
become more popular... some simply haven't been thought of yet.
However, I think if object is so widely derided by everyone, than I
think it needs to be depreciated sooner rather than later.
I have seriously considered doing this. Unfortunately I don't think we can
actually do it given the large amount of legacy content, e.g. tutorials
for how to embed flash which encourage use of object.
On Wed, 21 Mar 2007, Lachlan Hunt wrote:
I only included togglePause() because Flash supports it and some
people asked for it; I'm not convinced we should keep it.
I'm in favour of dropping it. It's an unnecessary API for browsers to
support. It adds nothing that can't be done with play()/pause() and an
if statement.
if (video.state == HTMLVideoElement.PAUSED) {
video.play();
} else {
video.pause();
}
On Tue, 20 Mar 2007, Jeff Cutsinger wrote:
+1.
I've commented it out for now. Let's see how many people complain.
On Tue, 20 Mar 2007, Shadow2531 wrote:
So, if one used video src=200x200.ogg style=width: 800px; height:
800px;/video , there'd be no way to make the video display at 200 x
200 because it would always scale?
Currently, correct.
If so, if one wanted to simulate the look I'm describing, would one have
to do the following for example?
figure style=width: 800px; height: 800px; background: #000;
video src=200x200.ogg style=width: 200px; height: 200px;/video
/figure
(Just want to be sure.)
Yeah, you could do that.
I'm thinking more along the lines of a local HTML page that embeds a
local video (one of your favorites for example) where when you load the
page (via a bookmark or a panel for example), it automatically starts
and is set to loop (because you authored it that way).
Well for local content we don't need to worry about interoperability
(since the user makes it for himself on his user agent), so user agents
are free to add vendor extensions to do this, or the user could use JS, or
the user could do something that doesn't involve HTML at all, that's not
really our problem.
So, this is all that is needed to do autostart?
window.onload = function() {
document.getElementsByTagName(video)[0].play();
};
That will do it, yes, assuming the user agent doesn't block it (the spec
allows that, under use control).
However, if JS is needed for the video element to function at all,
then the video element needs to fall back if JS is turned off.
Interesting point.
Yes, since JS is required, if JS is off, the browser should display the
alternate content.
You can do this with JS, of course (and that's the preferred way; hide
the fallback when you have JS).
Are you saying that with JS on, the fallback content will be displayed
in addition to the video and you have to use JS to hide the fallback
content like the following?
window.onload = function() {
var x = document.getElementsByTagName(video)[0];
x.play();
x.innerHTML = ;
};
No, I meant something like:
section id=video
pYou need JavaScript turned on to do video./p
/section
script
// clear the fallback
var v = document.getElementById('video');
while (v.hasChildNodes) v.removeChild(v.firstChild);
// get the data to play
var src = 'video.ogg';
// create the UI
default xml namespace = http://www.w3.org/1999/xhtml;;
var ui = div
pvideo src={src}/video/p
p
input type=button value=Play onclick=vPlay()/
input type=button value=Pause onclick=vPause()/
/p
/div;
var video = ui..video.domNode();
function vPlay() { video.play() }
function vPause() { video.pause() }
v.appendChild(ui.domNode());
// start playback
video.play();
/script
Or, probably better:
section id=no-js-warning
pYou need JavaScript turned on to do video./p
/section
section id=video
pvideo src=video.ogg/p
p
input type=button value=Play onclick=vPlay()/
input
Re: [whatwg] video element feedback
Ian Hickson wrote: I don't think such metadata attributes would help. They would just be ignored by most authors and incorrectly set by many others. I absolutely agree, but this is opt-in metadata so the first flaw (ignored by most authors) is by design. Such authors are precisely the sort of authors who cannot be trusted to produce accessible content or rate content correctly. The alt attribute is often incorrectly set by many authors, but on balance it's still better than no alt attribute. If most deliberately accessible content is labelled as such, then that would be an improvement on the current situation, since the number of false positives would be vastly reduced. It's true that such attributes might cause some unlabelled accessible content to be ignored, but such content is perhaps at an even /higher/ risk of being ignored when people with differing abilities dismiss entire technologies as inaccessible wholesale. Having said that, such flags might be good material for some sort of complex microformat. Obviously a preferable solution would be for everyone to create accessible content using open technologies in the first place, and we must do everything we can to encourage and enable that. But falling short of such revolutions, can anyone suggest an alternative way of limiting the disillusion caused by inaccessible downloads? What would happen if the video element actually contained audio elements for the audio, audiodescription elements for the audio descriptions, caption elements for the captions, and subtitle elements for the subtitles? Would it be technologically possible for HTML elements to act as containers in that way? Alternatively (thinking of XSPF playlists), what if video's src attribute pointed to an XML (or text/html-esque) file which contained these separate elements? It would be a powerful way of building a level of transparent accessibility into the system, without requiring users to download and play high-bandwidth content to find out if it has the features they need. -- Benjamin Hawkes-Lewis
Re: [whatwg] video element feedback
Ian Hickson wrote: However, I think if object is so widely derided by everyone, than I think it needs to be depreciated sooner rather than later. I have seriously considered doing this. Unfortunately I don't think we can actually do it given the large amount of legacy content, e.g. tutorials for how to embed flash which encourage use of object. In the unlikely event that object be in any way discouraged, can we ensure we allow element level fallback content for img (or some replacement element) as opposed to the alt attributes we're currently lumbered with and the longdesc attribute that WHATWG has done away with? Browsers should see if a video is unsupported and show the fallback message, which would contain a link to download the appropriate software. For example, video src=example.wmv This is a Windows Media Video file, but you need to download such-and-such to display it in your browser. /video The fallback isn't done that way in the spec today because that kind of fallback has been a source of bugs in browsers when it comes to other features (e.g. object); however, the spec provides the information to the script, though 'error' events, so you can achieve the same effect. Error events are in any case preferable, so that text alternatives can be separated from download suggestions. -- Benjamin Hawkes-Lewis
Re: [whatwg] video element feedback
Also sprach Martin Atkins: If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Right. I think I agree with you. Perhaps we can encourage implementors to add a simplistic UI in case none has been specified? On the right-click menu or somewhere where it doesn't take up space? -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] require img dimensions to be correct?
I sometimes enjoy the ability to clone images that have no src or no width or no style. I certainly like to vary the height and width attributes via setAttribute, and I might like, in the future, to be able to attach an animate tag (ala SMIL) to the height or width attribute of an img. If I had to do this through CSS, it would be a minor setback. img src=hoopla height=50 width=40 alt=oscillating image of hoopla animate attributeName=width values=10;100;10 dur=4s repeatCount=indefinite /img DD - Original Message - From: Dean Edridge [EMAIL PROTECTED] To: Gareth Hay [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Sander Tekelenburg [EMAIL PROTECTED]; Benjamin West [EMAIL PROTECTED] Sent: Friday, March 16, 2007 8:14 PM Subject: Re: [whatwg] require img dimensions to be correct? Gareth Hay wrote: If i'm not mistaken, the idea of separation of content and style means you can use your own css, or even none at all, and still have the ability to view the content. If a page is dependent on the css, then, although in a separate file, it is fundamentally not separate at all, and we might as well just shove the css into the same html file anyway. Gareth On 16 Mar 2007, at 20:27, Benjamin West wrote: On 3/16/07, Dean Edridge [EMAIL PROTECTED] wrote: Firstly, the chance of someone not being able to access the CSS for a web page is I'm guessing, pretty slim. img style=height: 50px; width: 50px; / Why is accessing CSS a problem? -Ben West --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.11/723 - Release Date: 15/03/2007 11:27 a.m. I never proposed that a web page should be dependant on CSS, nor did I say that there shouldn't be a separation of content and style. Quite the opposite. I said that if there is no CSS available for an img tag, the browser should just display the image the best it can(and they do this quite well already, in my experience). And that this very rare occasion of CSS failure does not warrant the mandatory requirement of in-line styling of the img tag. Dean Edridge
Re: [whatwg] video fallback behaviour (was: Re: video element feedback)
Simon Pieters said: Oh. I thought video fallback would work pretty much like object fallback, but I see that's not the case. When I think about it it makes sense; video is pretty much like iframe, it never falls back in UAs that support it. Oh, damn it. I thought it'd work like object, too. I'm not sure I like the only-fallback-if-no-support idea. I'm getting the feeling that there won't be one common video format among the browsers. I think not having fallback to nested video elements to get at other formats would ultimately be a bad thing. When PNG support sucked in IE6, I just didn't use alpha PNGs and opted for some other format. If there is no shared format, the only ways to support multiple video formats for multiple browsers would be: 1. Just have two video elements on screen (bad). 2. Swap the src with JavaScript (won't work if JS is off). 3. Delegate content on the server based on http-accept [?] (best of the three, but not very fun). 4. Maybe conditional comments if IE is the oddball (we'll see, but I don't like this option much either). Any thoughts on this or did I miss something? -- Robert http://robertdot.org
Re: [whatwg] video element feedback
Håkon Wium Lie: Also sprach Martin Atkins: If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Right. I think I agree with you. Perhaps we can encourage implementors to add a simplistic UI in case none has been specified? On the right-click menu or somewhere where it doesn't take up space? Maybe it is a stupid idea, but is something like the following imaginable to make a XHTML5 browser display inline video with a basic UI without the need for scripting? form method=MEDIA video src=pretty.ogg/ button type=play/ /form
[whatwg] video? img? css?
I'm curious why people feel that adding another element is the way to go. Why do people not want to use img? Afraid of object extension craziness? I'd like to see us have the ability to do video in both img and in CSS places (background: url(foo.mpg) -- we're supposed to be separating presentation right??) If we're to support those we will need similar controls for video. I've seen various requests over the last few years for people wanting similar video controls for animated images. If we have to add these to img already then do we really need a seperate video element? stuart
Re: [whatwg] video element feedback
Actually that sounds like a splendid idea to me. although I am not sure about using the form tag. what about something like? video src='some_file.ogg' button type='rewind' / button type='playpause' / button type='stop' / button type='fastforward' / /video On 3/20/07, Christoph Päper [EMAIL PROTECTED] wrote: Håkon Wium Lie: Also sprach Martin Atkins: If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Right. I think I agree with you. Perhaps we can encourage implementors to add a simplistic UI in case none has been specified? On the right-click menu or somewhere where it doesn't take up space? Maybe it is a stupid idea, but is something like the following imaginable to make a XHTML5 browser display inline video with a basic UI without the need for scripting? form method=MEDIA video src=pretty.ogg/ button type=play/ /form -- [EMAIL PROTECTED] http://www.tuesdaybegins.com
Re: [whatwg] video element feedback
Christoph Päper said: Maybe it is a stupid idea, but is something like the following imaginable to make a XHTML5 browser display inline video with a basic UI without the need for scripting? form method=MEDIA video src=pretty.ogg/ button type=play/ /form I was somewhat concerned with the script-only controls. Your's is a neat approach if you wanted a custom, scriptless UI for the element and I think it may be a good idea to have scriptless UI controls. I don't know what people would say about the form as extra code on the minimalistic video. That said, if the video controls are built in via a fade-in menu like iTunes video or (if they must) via a right-click menu, I think I could live without scriptless UI controls. They'd be nice, though. -- Robert http://robertdot.org
Re: [whatwg] video element feedback
On 20 Mar 2007, at 21:50, Benjamin Hawkes-Lewis wrote: Ian Hickson wrote: However, I think if object is so widely derided by everyone, than I think it needs to be depreciated sooner rather than later. I have seriously considered doing this. Unfortunately I don't think we can actually do it given the large amount of legacy content, e.g. tutorials for how to embed flash which encourage use of object. In the unlikely event that object be in any way discouraged, can we ensure we allow element level fallback content for img (or some replacement element) as opposed to the alt attributes we're currently lumbered with and the longdesc attribute that WHATWG has done away with? I asked for the resurrection of HTML+'s imagefallback/image element last month. The reasons I cited were exactly the same as the reasons being given now in favour of the video element, however I was told (paraphrasing) Why bother, you can just use object and That would break existing implementations (though no such implementations were cited). So again, I ask for an image element to replace img. Benefits include: • As video would cater for video/* MIME types, image would cater for image/* • The alt and longdesc attributes can be part of the fallback content, allowing markup. • You don't have to provide a type attribute and match on: object [type^=image/] • and more… - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element proposal
Once upon a time Maik Merten shaped the electrons to say... Well, I guess everybody here will hate me for proposing it... and I think it's ugly... but well... video Perhaps a verbose description of what can be seen here? novideo D'oh, your browser is outdated... let's embed an object here /novideo /video Just as we have been able to do object embed /embed /object To support legacy UAs which don't handle object, why not: video object /object /video Just as with object, the specification would have the UA stop at the outer-most container it can render. (I know IE6 failed to do this.) -MZ -- URL:mailto:megazoneatmegazone.org Gweep, Discordian, Author, Engineer, me. A little nonsense now and then, is relished by the wisest men 508-852-2171 URL:http://www.megazone.org/ URL:http://www.eyrie-productions.com/ Eris
Re: [whatwg] Resurrection of HTML+'s image (was: video element feedback)
On Wed, 21 Mar 2007 00:42:24 +0100, Nicholas Shanks [EMAIL PROTECTED] wrote: I asked for the resurrection of HTML+'s imagefallback/image element last month. The reasons I cited were exactly the same as the reasons being given now in favour of the video element, however I was told (paraphrasing) Why bother, you can just use object and That would break existing implementations (though no such implementations were cited). Existing implementations include at least: * Internet Explorer * Firefox * Opera * Safari The image start tag is parsed as if it were img, so you would get both the image and the fallback with HTML+ markup. Existing content rely on this behaviour, which is why it was added to the Parsing spec (see A start tag whose tag name is image, and see comment in source). -- Simon Pieters
Re: [whatwg] require img dimensions to be correct?
On 17 Mar 2007, at 23:28, Andrew Fedoniouk wrote: I think that in most cases will be better if we could package complex pages into zip envelopes and deliver them in the whole. That would be real solution of jumps. And img width=... height=... is a palliative. I have an open bug with Safari requesting support for the multipart/ mixed Content-Type. This would provide the ziped content you request (and you can use a Transfer-Encoding to compress it before sending) I have a demo page at http://web.nickshanks.com/browsers/safari/ multipart correct rendering at http://web.nickshanks.com/browsers/safari/ multipart2 - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Resurrection of HTML+'s image (was: video element feedback)
On 21 Mar 2007, at 00:27, Simon Pieters wrote: I asked for the resurrection of HTML+'s imagefallback/image element last month. I was told that would break existing implementations Existing implementations include at least: * Internet Explorer * Firefox * Opera * Safari The image start tag is parsed as if it were img, so you would get both the image and the fallback with HTML+ markup. Existing content rely on this behaviour, which is why it was added to the Parsing spec (see A start tag whose tag name is image, and see comment in source). So what's the problem? Content with a doctype of !DOCTYPE html or !DOCTYPE htmlplus is treated correctly, and content without a doctype is handled in quirks mode, where the UA can look for /image and if found in a suitable place, treat the start tag as image, or if not found, treat the start tag as img. Any content using image in strict mode with another HTML doctype is broken anyway, so it doesn't really matter how that looks. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Resurrection of HTML+'s image (was: video element feedback)
On Wed, 21 Mar 2007 02:07:17 +0100, Nicholas Shanks [EMAIL PROTECTED] wrote: So what's the problem? Content with a doctype of !DOCTYPE html or !DOCTYPE htmlplus is treated correctly, and content without a doctype is handled in quirks mode, where the UA can look for /image and if found in a suitable place, treat the start tag as image, or if not found, treat the start tag as img. Any content using image in strict mode with another HTML doctype is broken anyway, so it doesn't really matter how that looks. Oh yes, lets upgrade DOCTYPE sniffing to the 20th century. Fricking awesome. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Resurrection of HTML+'s image
Hi Anne, Oh yes, lets upgrade DOCTYPE sniffing to the 20th century. Fricking awesome. 21st century -- or to put it another way, discworld let's drag DOCTYPE kicking and screaming into the century of the fruitbat /discworld Michael -- Print XML with Prince! http://www.princexml.com
Re: [whatwg] video element feedback
On 21/03/07, Robert Brodrecht [EMAIL PROTECTED] wrote: Christoph Päper said: Maybe it is a stupid idea, but is something like the following imaginable to make a XHTML5 browser display inline video with a basic UI without the need for scripting? form method=MEDIA video src=pretty.ogg/ button type=play/ /form I was somewhat concerned with the script-only controls. Your's is a neat approach if you wanted a custom, scriptless UI for the element and I think it may be a good idea to have scriptless UI controls. I don't know what people would say about the form as extra code on the minimalistic video. That said, if the video controls are built in via a fade-in menu like iTunes video or (if they must) via a right-click menu, I think I could live without scriptless UI controls. They'd be nice, though. Hmm. I'd prefer to not add an artificial method on the form element. Instead I'd prefer something like this: button type=play for=idref_to_videoplay/button button type=pause for=idref_to_videopause/button button type=stop for=idref_to_videostop/button progress type=played for=idref_to_video/progress progress type=buffered for=idref_to_video/progress Where the buttons automatically without scripting do the equivalent of the API function with the same name, and where the progress elements gets it's value from the video as it plays/gets buffered. -- David liorean Andersson
Re: [whatwg] window.opener and security
On 20/03/07, Thomas Broyer [EMAIL PROTECTED] wrote: 2007/3/20, liorean: Some thing I would like to add here, is that your solution doesn't do anything to solve the actual l problem case. Even if window.opener would be read only, that is just a reference to a window object. Even if that property would be read only you could still write to the location property of the window object it references. For your solution to work the read only attribute would have to cascade to all properties, something defying the nature of JavaScript. I'm not so sure. And this would be similar to a node being read-only in the DOM (see the NO_MODIFICATION_ALLOWED_ERR DOMException in http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-258A00AF) In the case of writing to windowobject.location, yes. Then it would work just like that, because just like the DOM exception you talk about, the cross domain security checks lay in a deeper layer than JavaScript. However, consider an access to foo.bar.baz. JavaScript will first access the first variable foo it can find in the current scope. When found, it will access the first bar property it can find in the prototype chain of the object referenced by that variable. And finally, it will access the first baz it can find in the prototype chain of the object referenced by that property. In other words, the access to baz will operate on an object already extracted from the bar property of an already extracted object from the foo variable. All of these accesses only operate on one object, how that object was originally gotten to has already been forgotten when that access takes place. Similarly, for window.opener.location=http://phishing.exampe.net/evil; 1. Access the window variable in current scope chain. 2. Set the working object to the value of that variable. 3. Access the opener property of the working object. 4. Set the working object to the value of that property. 5. Set the location property of that object to the string http://phishing.exampe.net/evil; In this, the setting of location happens on a window object. JavaScript has no memory of how it got that window object, so JavaScript itself cannot treat it specifically depending on how that was. However, the implementation of the property getters/setters in this example can themselves apply security checks and/or give a wrapped object with security restrictions. That's where the solution to this fix belongs. A much better solution, in my opinion, would be to make the location object safe from cross domain attacks by making it only writable from same domain, or if the document does not have a domain yet. (window.open without address) I do think this would break some sites, however. Yep, e.g. redirecting to a mirror-site. But this is a very interesting idea (similar to XMLHttpRequest not allowing cross-domain requests; you'd just need a page on the same level to issue redirects at the HTTP-level to word-around that new limitation; and this is a really sane work-around IMO). I would personally combine both suggestions: window.opener, window.top and other windowobject accessors return readonly objects when called from a page within a different domain; and within the page, constrain window.location setting (imagine someone hacks Google and adds a window.location=XXX in Google Analytics script). Or, they don't actually access window objects. They return security restriction wrapper objects for those window objects, and these give similar security restriction wrapped objects (recursively for arbitrary depth) to all JavaScript instances not being contained in their window object. This way the read/write access can be dynamically changed depending on any security restriction factor. It incurs a slight cost for all cross frame/window scripting (compared to scripts contained in the same window object), but I would think some mechanism like this is already in place in browsers, at least for some specific objects. -- David liorean Andersson
[whatwg] comments section 1
I started reviewing the whole html 5 spec and will send my comments, section by section, on the fly, to this list. Hoping you'll find it useful... 1.3.3 backwards-compatibility is retained This could appear earlier in the spec, for instance in the abstract. Think journalists, press and tech news coverage. 1.4. The single fact that HTML v5 needs to use a 1999 namespace already used by earlier versions of the language indicates that namespaces are a rather bad solution to the problems they're trying to solve... Conclusion : follow that path and imagine something better. 1.4. any Node with node type 3 or 4 Please don't put a numerical value here but Node.TEXT_NODE and Node.CDATA_SECTION_NODE /Daniel
Re: [whatwg] comments section 1
Daniel Glazman wrote: Subject: [whatwg] comments section 1 FYI, section numbers are subject to change (they have done several times over the spec's development). It would be more useful if you used the section title. It will make it less confusing if they change between now and the time Hixie gets to your feedback. 1.4. The single fact that HTML v5 needs to use a 1999 namespace already used by earlier versions of the language indicates that namespaces are a rather bad solution to the problems they're trying to solve... Conclusion : follow that path and imagine something better. That's the W3C's fault for for putting a date in the namespace URI, instead of something more sensible like they have now done for XBL2 [1]. That is not one of the problems with namespaces in general, only a problem with that URI. But we can't change the XHTML namespace without breaking backwards compatibility, so we're stuck with it. [1] http://www.w3.org/ns/xbl -- Lachlan Hunt http://lachy.id.au/
[whatwg] Drop tabindex=
Hi, I think tabindex= has a number of problems: 1) Lacking a feature to scope tabindexes into local contexts, which I proposed[1] a while back, makes the feature rather useless for its intended purpose (which, AIUI, was to provide a means for the author to suggest a different tab order than the natural one, because he was using, say, form controls in a table where the navigation should go down through the columns rather than row for row). 2) Using tabindex=0 or -1 to indicate whether an element can have focus is arguably bogus IMHO. Whether something is focusable depends on the UA or the device. I don't see any reason why apps would use span tabindex=0 onclick onkeypress instead of just using links, form controls, or contenteditable= (depending on what you're doing). (If you'd do this because form controls are hard to style, then HTML isn't the place to address that problem.) 3) The tab order should be up to the user. In Opera you can navigate in any direction you want using e.g. Shift+arrows, allowing you to freely navigate in tables for instance. The author shouldn't have any say about the tab order other than the source order. From what I've seen, most authors who use tabindex use it out of a cargo cultish habit thinking it would aid accessibility because some outdated accessibility guidelines told them so. The result mostly being reducing keyboard usability by distorting the tab order, because the elements with tabindex receive focus before anything else on the page. These authors don't realise how tabindex actually works, but they feel good about having added it because they comply with the accessibility guidelines, yet they don't know that it in fact screws up the tab order because they don't browse with the keyboard. It was pointed out on IRC that there might be valid use-cases for #2, e.g. making a canvas focusable for games with keyboard controls. Then that's ok with me, I don't have strong opinions on this either way, I just think existing elements should be used where possible instead of reinventing links or checkboxes with span tabindex or similar. However, for positive values of tabindex, I only see problems. The source order should be a powerful enough mechanism for authors to suggest a tab order of elements. I would love to see browsers treat all positive values for tabindex as equivalent to 0 (i.e., just make it focusable but don't change the tab order). I would also like to propose that positive values for tabindex be disallowed in HTML5 documents. I don't think it's a good idea to add a scoped tabindex feature (trying to address #1) as I proposed before. [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-August/007228.html Regards, -- Simon Pieters
Re: [whatwg] Drop tabindex=
Simon Pieters writes: The tab order should be up to the user. In Opera you can navigate in any direction you want using e.g. Shift+arrows, allowing you to freely navigate in tables for instance. The author shouldn't have any say about the tab order other than the source order. In a table, I think I agree. The user should know how to get around via UI conventions. In more abstract structures, the author may be able to provide useful hints through tab order. DD
Re: [whatwg] comments section 1
On 21/03/2007 04:10, Lachlan Hunt wrote: FYI, section numbers are subject to change (they have done several times over the spec's development). It would be more useful if you used the section title. It will make it less confusing if they change between now and the time Hixie gets to your feedback. Sure, no problem. Thanks for the hint. 1.4. The single fact that HTML v5 needs to use a 1999 namespace already used by earlier versions of the language indicates that namespaces are a rather bad solution to the problems they're trying to solve... Conclusion : follow that path and imagine something better. That's the W3C's fault for for putting a date in the namespace URI, instead of something more sensible like they have now done for XBL2 [1]. I never said the contrary :-) That is not one of the problems with namespaces in general, only a problem with that URI. But we can't change the XHTML namespace without breaking backwards compatibility, so we're stuck with it. Again, never said the contrary. Being stuck with the xhtml namespace for html 5 does not mean you cannot imagine another solution for other markup languages... /Daniel
Re: [whatwg] Drop tabindex=
On Mar 20, 2007, at 8:16 PM, Simon Pieters wrote: Hi, I think tabindex= has a number of problems: 1) Lacking a feature to scope tabindexes into local contexts, which I proposed[1] a while back, makes the feature rather useless for its intended purpose (which, AIUI, was to provide a means for the author to suggest a different tab order than the natural one, because he was using, say, form controls in a table where the navigation should go down through the columns rather than row for row). Sounds like such a feature could be useful, but it would be tricky to make it compatible with older UAs. 2) Using tabindex=0 or -1 to indicate whether an element can have focus is arguably bogus IMHO. Whether something is focusable depends on the UA or the device. I don't see any reason why apps would use span tabindex=0 onclick onkeypress instead of just using links, form controls, or contenteditable= (depending on what you're doing). (If you'd do this because form controls are hard to style, then HTML isn't the place to address that problem.) I disagree with this. Arbitrary elements accepting keyboard input (which is what focus is about) is just as important as arbitrary elements receiving mouse input. You even cited one of my examples below: consider a game implemented with canvas that uses keyboard controls. Obviously you want to be able to make canvas focusable in such cases. There are many analogous use cases, consider building compound controls with XBL that want to have their own keyboard navigation. I don't think there is any need to limit what elements can get keyboard input 3) The tab order should be up to the user. In Opera you can navigate in any direction you want using e.g. Shift+arrows, allowing you to freely navigate in tables for instance. The author shouldn't have any say about the tab order other than the source order. Shift+arrows are a completely separate issue from tab order. From what I've seen, most authors who use tabindex use it out of a cargo cultish habit thinking it would aid accessibility because some outdated accessibility guidelines told them so. The result mostly being reducing keyboard usability by distorting the tab order, because the elements with tabindex receive focus before anything else on the page. These authors don't realise how tabindex actually works, but they feel good about having added it because they comply with the accessibility guidelines, yet they don't know that it in fact screws up the tab order because they don't browse with the keyboard. This sounds like something to be fixed in the relevant accessibility guidelines. HTML5 can also recommend not adding these attributes gratuitously. It was pointed out on IRC that there might be valid use-cases for #2, e.g. making a canvas focusable for games with keyboard controls. Then that's ok with me, I don't have strong opinions on this either way, I just think existing elements should be used where possible instead of reinventing links or checkboxes with span tabindex or similar. I agree that existing elements should be used when possible, but sometimes none of the small set of elements that is focusable by default is suitable. Note that UAs do not even agree on what elements are focusable by default. In Safari, links and input type=button controls are not in the tab order, for instance, to match Macintosh UI conventions. However, for positive values of tabindex, I only see problems. The source order should be a powerful enough mechanism for authors to suggest a tab order of elements. Document order is insufficient in the presence of positioning, or the column vs. row example you cited. I would love to see browsers treat all positive values for tabindex as equivalent to 0 (i.e., just make it focusable but don't change the tab order). I would also like to propose that positive values for tabindex be disallowed in HTML5 documents. I don't think it's a good idea to add a scoped tabindex feature (trying to address #1) as I proposed before. [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-August/ 007228.html Regards, -- Simon Pieters
Re: [whatwg] comments section 1
Daniel Glazman wrote: On 21/03/2007 04:10, Lachlan Hunt wrote: ... But we can't change the XHTML namespace without breaking backwards compatibility, so we're stuck with it. Again, never said the contrary. Being stuck with the xhtml namespace for html 5 does not mean you cannot imagine another solution for other markup languages... That's fine for other markup languages, but we're discussing (X)HTML. So I guess I don't really understand the relevance of your initial comment. Is there something you want the spec to say about the issue? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Resurrection of HTML+'s image (was: video element feedback)
Anne van Kesteren wrote: Oh yes, lets upgrade DOCTYPE sniffing to the 20th century. Fricking awesome. My uneducated guess is UAs will inevitably continue to doctype sniff no matter what WCAG do, if only because they have existing code that does this and the web has tonnes of CSS that relies on it. But if we want to avoid defining new behaviour for /img and /image parsing, how about replacing it with pict, picture, graphic, or im? Or, how about getting more specific? bitmap [e.g. image/gif of an icon] diagram [e.g. image/svg of a map] photo [e.g. image/jpeg of a cat] Would that help search engines, I wonder? -- Benjamin Hawkes-Lewis
