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.
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
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
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
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
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
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/
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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**
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
58 matches
Mail list logo
