On Thu, 26 Aug 2010 02:28:49 +0200, Chris Double
chris.dou...@double.co.nz wrote:
On Thu, Aug 26, 2010 at 5:25 AM, Eric Carlson eric.carl...@apple.com
wrote:
FWIW, I agree with Silvia that a new file extension and MIME type make
sense.
I also think that a new file extension and MIME type is
Ian Hickson:
On Wed, 4 Aug 2010, Thomas Koetter wrote:
What strikes me though is that according to the spec The br element
represents a line break. A *line* break is presentational in nature.
The break is structural, but restricting it to a certain presentation of
that break lacks the
On 25 August 2010 12:50, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/24/10 7:09 PM, Ben Lerner wrote:
The history navigation analogy is a good one: pages presumably already
have to handle the pageshow event to deal with being revived from the
history, and the browser already needs to know
On 8/26/10 3:23 AM, James May wrote:
Couldn't the iframe be kept alive, but remain associated with it's
parent browsing context until (if) it was re-parented / inserted into a
different document. (does this match what other elements in the DOM
behave in terms of event handlers when they are
On 8/26/10 3:23 AM, James May wrote:
Couldn't the iframe be kept alive, but remain associated with it's
parent browsing context until (if) it was re-parented / inserted into a
different document. (does this match what other elements in the DOM
behave in terms of event handlers when they are
Silvia Pfeiffer wrote:
You misunderstand my intent. I am by no means suggesting that no
WebSRT
content is treated as SRT by any application. All I am asking for is a
different file extension and a different mime type and possibly a
magic
identifier such that *authoring* applications (and
On 25.08.2010, at 23:46, Aryeh Gregor wrote:
These cases can be secured without any new features in browsers (by escaping
whitespace using numeric entities):
function htmlescape($str) {
return preg_replace('/[\s\']/e','.ord($0).;',$str);
}
That doesn't work in script for
Am 26.08.10 01:41, schrieb Adam Barth:
On Wed, Aug 25, 2010 at 1:55 PM, Ian Hicksoni...@hixie.ch wrote:
On Wed, 25 Aug 2010, Adam Barth wrote:
HTML should support Base64-encoded entities to make it easier for
authors to include untrusted content in their documents without
risking XSS.
Seems
On Thu, 26 Aug 2010 09:58:29 +0200, Henri Sivonen hsivo...@iki.fi wrote:
Silvia Pfeiffer wrote:
You misunderstand my intent. I am by no means suggesting that no
WebSRT
content is treated as SRT by any application. All I am asking for is a
different file extension and a different mime type and
Why wouldn't it always be a superior solution for all parties to do
the
following:
1) Make sure WebSRT never requires processing that'd require
rendering
a substantial body of legacy .srt content in a broken way. (This
would
require supporting non-UTF-8 encodings by sniffing as
On 25.08.2010 22:50, Adam Barth wrote:
== Summary ==
...
Not convinced. There's already one way to escape these things, and this
is supported in all UAs.
I don't see how adding another mechanism will help those who can't use
the first one properly. For instance, people unable to escape ,
On Wed, 25 Aug 2010 17:40:08 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
At this point, what is your recommendation? The following ideas have
been
on the table:
* Change the file extension to something other than .srt.
I don't have an opinion, browsers ignore the file
On Thu, 26 Aug 2010 11:52:26 +0200, Henri Sivonen hsivo...@iki.fi wrote:
Why wouldn't it always be a superior solution for all parties to do
the
following:
1) Make sure WebSRT never requires processing that'd require
rendering
a substantial body of legacy .srt content in a broken way.
On Wed, Aug 25, 2010 at 7:00 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
It would, however, be good to have an indication where HTML would like to
see it going. Would it be better for a media fragment URI for images such as
http://example.com/picture.png#xywh=160,120,320,240 to
On Thu, Aug 26, 2010 at 9:01 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Wed, Aug 25, 2010 at 7:00 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
It would, however, be good to have an indication where HTML would like to
see it going. Would it be better for a media fragment URI
On 26 August 2010 17:27, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/26/10 3:23 AM, James May wrote:
Couldn't the iframe be kept alive, but remain associated with it's
parent browsing context until (if) it was re-parented / inserted into a
different document. (does this match what other
On Thu, 5 Aug 2010, Bjartur Thorlacius wrote:
On Tue, 18 May 2010, bjartur wrote:
First of all I think we should use a rel=embed href=uri-ref
instead of source.
What problem would this solve?
It would tell UAs that don't implement HTML 5 that the value of @href is
an URI.
On 2010-08-26 13:58:24, Julian Reschke wrote:
Not convinced. There's already one way to escape these things, and this
is supported in all UAs.
Totally agree. If a web author isn't sufficiently experienced to
remember to call an HTML-encoding function, there is no reason to
believe they'll
On Fri, 6 Aug 2010, Aryeh Gregor wrote:
On Fri, Aug 6, 2010 at 3:01 PM, Ian Hickson i...@hixie.ch wrote:
I'm happy to make more of them limited, especially new attributes or ones
that were already that way, but I'd rather not change the default as that
can have unexpected effects (e.g. some
On 8/26/10 11:58 AM, James May wrote:
I thought I just suggested that?
Everything works normally (as if it was still attached) until it is
reattached, when the situation is re-evaluated.
That could fall afoul of security checks that assume that an iframe with
a non-null parent is in fact a
What should the baseURL and referrer be for a @srcdoc nested browsing
context? If I follow the base URL behavior for about:blank it will
just be inherited from the creator document. That seems like the right
thing to do, so I think section 2.5.1 should be modified to read:
If fallback base url is
On Thu, Aug 26, 2010 at 5:58 AM, Julian Reschke julian.resc...@gmx.de wrote:
Not convinced. There's already one way to escape these things, and this is
supported in all UAs.
Adam gave two examples of cases where htmlspecialchars() is
insufficient, even if authors do use it. This proposal is
Good afternoon,
I am wondering if public discussion has been had over the concept of
introducing a dialog element into html5.
Normally a modal dialog is created using scripting and CSS to restrict focus
and activity within the modal segment of the DOM and to style the modal
section of the DOM
On 26.08.2010 22:10, Aryeh Gregor wrote:
On Thu, Aug 26, 2010 at 5:58 AM, Julian Reschkejulian.resc...@gmx.de wrote:
Not convinced. There's already one way to escape these things, and this is
supported in all UAs.
Adam gave two examples of cases where htmlspecialchars() is
insufficient, even
On 8/26/10 4:10 PM, Aryeh Gregor wrote:
On Thu, Aug 26, 2010 at 5:58 AM, Julian Reschkejulian.resc...@gmx.de wrote:
Not convinced. There's already one way to escape these things, and this is
supported in all UAs.
Adam gave two examples of cases where htmlspecialchars() is
insufficient, even
On 26.08.2010 22:10, Aryeh Gregor wrote:
On Thu, Aug 26, 2010 at 5:58 AM, Julian Reschkejulian.resc...@gmx.de wrote:
Not convinced. There's already one way to escape these things, and this is
supported in all UAs.
Adam gave two examples of cases where htmlspecialchars() is
insufficient, even
On Thu, Aug 26, 2010 at 4:20 PM, Julian Reschke julian.resc...@gmx.de wrote:
I have to admit that I'm not sure what's special about script here. Are
you saying that it's insufficient to escape all characters that have a
special meaning there?
data:text/html,!doctype html
Hi E.J.,
I've actually been working with some other people on the Chromium team
for what we were calling a topmost window that could be used for
modal dialogs. After some feedback, it's been suggested that we try to
turn this into a more generic dialog element.
I haven't yet incorporated that
On Thu, Aug 26, 2010 at 2:00 PM, Ian Hickson i...@hixie.ch wrote:
* marquee.direction
What do browsers do for this one?
Seems like they don't limit it to known values, at least Firefox/Opera/Chrome.
* meta.httpEquiv
I'm pretty sure browsers don't treat this as limited to only known values.
On Thu, 26 Aug 2010 21:56:12 +0100, Aryeh Gregor
simetrical+...@gmail.com wrote:
Suppose I have some arbitrary blob of trusted JavaScript, and I want
to output it as an inline script in text/html. How do I escape it so
that it executes as intended -- in particular, given that it might
contain
On Wed, 25 Aug 2010 22:52:42 +0100, Kornel Lesiński kor...@geekhood.net
wrote:
script
elmt.innerHTML = 'Hi there ?php echo htmlspecialchars($name) ?.';
/script
These cases can be secured without any new features in browsers (by
escaping whitespace using numeric entities):
I realized I
On Thu, 26 Aug 2010 22:30:00 +0200, Julian Reschke julian.resc...@gmx.de
wrote:
I now get the point about the additional problems in script, but I fail
to see how the proposal addresses this, unless expanding these entities
is suppose to happen *after* parsing the script.
If you have
On 08/26/2010 10:56 PM, Aryeh Gregor wrote:
I don't know of any general-purpose way to have
/string in a string literal (or anywhere else),
The simple approach is to use JavaScript string literal escapes:
`\x3C/script`.
A JSON encoder may offer the option to avoid HTML-special characters
2010/8/26 Kornel Lesiński kor...@geekhood.net:
On Wed, 25 Aug 2010 22:52:42 +0100, Kornel Lesiński kor...@geekhood.net
wrote:
script
elmt.innerHTML = 'Hi there ?php echo htmlspecialchars($name) ?.';
/script
These cases can be secured without any new features in browsers (by
escaping
On 26.08.2010, at 23:28, Adam Barth wrote:
script
elmt.innerHTML = 'Hi there ?php echo htmlspecialchars($name) ?.';
/script
These cases can be secured without any new features in browsers (by
escaping whitespace using numeric entities):
I realized I was wrong about this one. It won't
On Wed, Aug 25, 2010 at 6:37 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/25/10 7:41 PM, Adam Barth wrote:
2) Decoding base64 results in binary data. We'll need to convert that
data to characters in order to deal with it in the DOM. We use always
use UTF8 for that transformation,
On 8/26/10 6:45 PM, Adam Barth wrote:
Note that this issue means that using atob or btoa for dealing with this is
a huge pain if non-ASCII chars are involved, since those take and return
byte arrays masquerading as JS strings, not actual Unicode strings.
I'm slightly confused how that works.
On 8/25/2010 2:02 PM, Ian Hickson wrote:
On Mon, 2 Aug 2010, Charles Pritchard wrote:
[ UAs can useinput type=file to let the user enter remote URLs ]
When a user through selection, click+drag or manual entry of a URL
should the browser still submit an Origin request header? It seems that
On 27 August 2010 05:02, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/26/10 11:58 AM, James May wrote:
I thought I just suggested that?
Everything works normally (as if it was still attached) until it is
reattached, when the situation is re-evaluated.
That could fall afoul of security
On Thu, Aug 26, 2010 at 5:24 PM, Charles Pritchard ch...@jumis.com wrote:
On 8/25/2010 2:02 PM, Ian Hickson wrote:
On Mon, 2 Aug 2010, Charles Pritchard wrote:
[ UAs can useinput type=file to let the user enter remote URLs ]
When a user through selection, click+drag or manual entry of a
On 8/26/10 10:33 PM, James May wrote:
Could the iframe be hoisted to the top level of its parent browsing context?
Not sure what you mean.
When no references remain in either the DOM or script?
if an |iframe
On 8/26/2010 7:53 PM, Jonas Sicking wrote:
On Thu, Aug 26, 2010 at 5:24 PM, Charles Pritchardch...@jumis.com wrote:
Chrome has gone ahead with their setData proposal, enhancing the
event.dataTransfer
object so that users may drag a file from within the browser onto their
desktop.
I would
42 matches
Mail list logo
