Re: [whatwg] Javascript: URLs as element attributes

2011-06-06 Thread Boris Zbarsky

On 6/6/11 4:45 PM, Ian Hickson wrote:

   data:text/html,


Woah, funky. (Gecko thinks the location is "javascript:''".)


Well... it sort of is.  ;)


It's defined; see the section on the  element.


I've read that section, in fact.  I couldn't make sense of what behavior
it actually called for.  Has it changed recently (last few months) to
become clearer such that rereading would be worthwhile?


Not as far as I'm aware. Could you elaborate on how it is confusing? I'm
eager to make this understandable!


I'll try reading it again and taking notes, I guess.  When I can find 
time to.  :(  The latency is killing us here.



Since Gecko seems to be alone in this weird behaviour, I haven't specced
it. I couldn't find any other effect (e.g. the input seems to always be
treated as Unicode, not converted to bytes and redecoded, regardless of
what I make it look like, including UTF-16 and UTF-8).


You can detect other effects by seeing what unescape() does in the 
resulting document, iirc.  As well as URIs including %-encoded bytes and 
so forth.  Also you can detect what charset is used for stylesheets 
included by the document that don't declare their own charset.  There 
are probably other places that use the document encoding.  Worth testing 
some of this stuff


-Boris


Re: [whatwg] Should script run if it comes from a HTML fragment?

2011-06-06 Thread Ian Hickson
On Thu, 10 Feb 2011, Henri Sivonen wrote:
> >
> > * innerHTML doesn't run scripts and they are inserted disabled.
> 
> FWIW, here's a counter-example: http://www.oele.net/innerhtmljs2.html
> 
> The above runs the script in all browsers except Firefox 4 (which 
> follows the spec). The pattern is reportedly from the 
> http://crossbrowserajax.com/ library.
> 
> However, http://www.oele.net/innerhtmljs.html doesn't run in IE9 PP7.
> 
> I'm not thrilled about adding code to support this quirky pattern at 
> this point of the release cycle (evang is being attempted), but I 
> thought I'd mention this finding even though I'm not asking for a spec 
> change (at least not yet).

Wow. That difference is absurd.

Since Gecko and WebKit both do what the spec says now, I've left the spec 
as is. I don't even know where I'd begin in terms of doing what IE does 
here.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


Re: [whatwg] Javascript: URLs as element attributes

2011-06-06 Thread Ian Hickson
On Wed, 9 Feb 2011, Boris Zbarsky wrote:
> On 2/9/11 10:12 PM, Ian Hickson wrote:
> > On Mon, 15 Nov 2010, Boris Zbarsky wrote:
> > > On 11/15/10 8:15 PM, Ian Hickson wrote:
> > > > > Gecko's currently-intended behavior is to do what [the spec]
> > > > > describes in all cases except:
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 

(Note that the spec has since changed on this; javascript: either runs in 
a browsing context that it is navigating, or it doesn't run at all.)


> > > > What does it do for those cases if it doesn't match the spec?
> > > 
> > > For  the behavior in Gecko currently is different in terms 
> > > of what the URI of the result document of javascript: is set to.
> 
> Try this:
> 
>   data:text/html, src="javascript:''">

Woah, funky. (Gecko thinks the location is "javascript:''".)


> > > Note that there is some confusion here in terms of browsing contexts 
> > > and , since does expose a Document object sometimes 
> > > (but not others) and does participate in session history sometimes, 
> > > I believe... So I'm not quite sure what behavior the spec calls for 
> > > for.
> > 
> > It's defined; see the section on the element.
> 
> I've read that section, in fact.  I couldn't make sense of what behavior 
> it actually called for.  Has it changed recently (last few months) to 
> become clearer such that rereading would be worthwhile?

Not as far as I'm aware. Could you elaborate on how it is confusing? I'm 
eager to make this understandable!


> > > At least in Gecko, the return value string is examined to see 
> > > whether all the charcode values are< 255.  If they are, then the 
> > > string is converted to a byte array by just dropping the high byte 
> > > of every char. So you can pretty easily generate image data this 
> > > way.
> > > 
> > > If any of the bytes are> 255, then the string is encoded as UTF-8 
> > > instead.
> > 
> > Hm. This currently isn't specced; the spec just assumes the return 
> > value is text/html string data and doesn't say what encoding to use. 
> > Is there a good way to test this in the context of an, where 
> > all the browsers do something with javascript:?
> 
>  src="javascript:'\u0400'">

http://junkyard.damowmow.com/466

Gecko: UTF-8 if the 'javascript:' URL includes characters >255, ISO-8859-1 
if all the input characters are <255.

WebKit seems to pick my default encoding regardless.

Opera returns "".

IE8 returns "undefined".

Since Gecko seems to be alone in this weird behaviour, I haven't specced 
it. I couldn't find any other effect (e.g. the input seems to always be 
treated as Unicode, not converted to bytes and redecoded, regardless of 
what I make it look like, including UTF-16 and UTF-8).


On Thu, 10 Feb 2011, Adam Barth wrote:
> On Tue, Nov 30, 2010 at 11:37 AM, Darin Adler  wrote:
> > In WebKit, we have treated the javascript URL scheme as a special 
> > case, with explicit code in the loader, and not handled by general 
> > purpose resource protocol machinery. Maciej Stachowiak suggested this 
> > approach, back in 2002, and one of the reasons he gave me at the time 
> > is that thought WebKit would be more likely to get the security policy 
> > right if code paths opted in to JavaScript execution rather than 
> > opting out of javascript URL scheme handling.
>
> Apologies for not reading the whole thread before replying, but the 
> design Darin describes [above] has worked well in WebKit thus far.  I'd 
> be hesitant to make JavaScript URLs work in more contexts due to the 
> risk of introducing security vulnerabilities into the engine.

That's black-box equivalent to what the spec currently requires, I believe 
(though the spec implements it more like what Boris describes:).

On Thu, 10 Feb 2011, Boris Zbarsky wrote:
> 
> For what it's worth, Gecko treats javascript: URLs as a general 
> protocol, but with tracking of where the URL came from required for the 
> script to actually execute and explicit opt-in on the caller's part 
> required to execute outside a sandbox.
> 
> This too has worked well in terms of security, for what it's worth, 
> while offering a lot more flexibility in terms of how and where 
> javascript: URIs can work.
> 
> I don't think we should gate the spec here on Webkit's implementation 
> details if we think a certain behavior is correct but hard to support in 
> Webkit


On Mon, 16 May 2011, Philip Jägenstedt wrote:
> On Sat, 14 May 2011 00:34:36 +0200, Ian Hickson  wrote:
> > On Mon, 14 Feb 2011, Philip Jägenstedt wrote:
> > > 
> > > For the record, I removed Opera's "support" (I assume it was an 
> > > unintended side-effect) for  along 
> > > with the rest at the time when I wrote my previous mail in this 
> > > thread. This intentionally doesn't match what the spec says. 
> > > (Disclaimer: this is only my opinion on something that isn't really 
> > > my area of expertise, so others at Opera might decide that the spec 
> > > is great and push in the opposite direction. It 

Re: [whatwg] "Content-Disposition" property for tags

2011-06-06 Thread Bjartur Thorlacius
On 6/6/11, Boris Zbarsky  wrote:
> My point was that there should be _a_ standardized way that sites can
> use to get consistent behavior across browsers.  Content-Disposition
> headers see like that way to me.
>
More importantly there should be an implementation defined convention
so users get consistent behavior across sites. I don't see why authors
should care so much how users identify documents internally, when the
original point (type information) is nullified by filename
sanitization crucial to security. Browser are able to deduce
descriptive and rather unique names from the title, terser ones from
the URI and allow the user to choose his own. You'll never able to
assume your suggestion will be used, anyway.


Re: [whatwg] The choice of script global object to use when the script element is moved

2011-06-06 Thread Ian Hickson
On Wed, 2 Feb 2011, Henri Sivonen wrote:
> On Feb 2, 2011, at 03:07, Ian Hickson wrote:
> 
> > I suppose we could make it so that scripts get neutered when the document 
> > that they were first associated with gets unloaded. Would that work?
> 
> We did something different.
> 
> > Proposal #1:
> 
> Proposal #4 (what Gecko now does):
> 
>  * If at the time when the parser triggers the 'run' algorithm, the owner 
> document of the script is not the same document whose active parser the 
> parser is, set the 'already executed' flag and abort the steps.
> 
>  * If at the time of a script becoming available for evaluation the owner 
> document of the script is not the same document that was the owner document 
> at the time of the 'run' algorithm, don't evaluate the script.
> 
> See https://bugzilla.mozilla.org/show_bug.cgi?id=592366

I believe this is what the spec now says (this was fixed in response to a 
bug that was filed, IIRC). Please let me know if it's still broken.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


Re: [whatwg] "Content-Disposition" property for tags

2011-06-06 Thread Eduard Pascual
On Mon, Jun 6, 2011 at 6:59 PM, Dennis Joachimsthaler  wrote:
> Yes, I was trying to refer to the verbosity. There's no html attributes
> with dashes in them as far as I know, except for "data-", which are user-
> defined. This would kind of break the convention a little. I could think
> about having "contentdispo" or some shortname like this, it would fit
> "better" to what we currently have in html.

Maybe "disposition" could work? For the HTTP header, the "content"
part indeed refers to the content of the response; but on the case of
a link, the attribute would be referring to the linked resource,
rather than the actual content of the element. So it's more accurate,
we reduce verbosity, and we get rid of the dash, all of this without
having to make the name less explicit nor relying on an arbitrary
abbreviation (ie: why "dispo" and not "disp" or "dispos"? Since there
isn't a clear boundary, it could be harder to remember; but dropping
the "content-" part seems more straight-forward).

> Again, html convention: Currently html only has one "statement" in every
> attribute, except for things like events (which is javascript) and style
> (which is also ANOTHER language: css).

Well, meta elements with a http-equiv attribute normally have a full
HTTP header (including parameters if needed) in their content
attribute, so I see no issue in taking a similar approach. After all,
HTTP _is_ another language (or protocol, to be more precise, but
protocols are still a kind of languages).

> Seems cleaner to me if we stay to the "standard" and not change the syntax
> "rules".
HTTP is also a standard. So we could stick to it. It all boils on a
choice of which standard we honor above the other. Seeing that HTTP is
an actual standard, rather than a mere convention, and we are actually
"borrowing" a feature from it, it looks like the "winner" to me.

> Please tell me if I missed anything here!
>From the top of my head, @class is defined to be a space-separated
list of class names. Sure, it is a simpler syntax, but it's still a
multiple content attribute. I think there are some more cases, but I
can't recall any right now.

Regards,
Eduard Pascual


Re: [whatwg] "Content-Disposition" property for tags

2011-06-06 Thread Dennis Joachimsthaler



Am 03.06.2011, 15:16 Uhr, schrieb Eduard Pascual :

On Fri, Jun 3, 2011 at 2:23 PM, Dennis Joachimsthaler   
wrote:

This grants the ability for any content provider to use an explicit
"Content-Disposition: inline" HTTP header to effectively block
"download links" from arbitrary sources.


True. Is it still so that some browsers ignore the "filename" part
of a content-disposition if an "inline" disposition is used?


Ok, I have never even thought about using the "filename" argument with
an explicit "inline" disposition. When I am in control of the headers,
I find it easier to "fix" the filename with 301/302 redirects, and
also have the bonus of some control about how that should be cached...
In short, I think that responding with a 2xx code _and_ attempting to
change what's essentially part of the URI through other means is a
contradiction, and thus a mistake on the best case, or some attempt to
fool the browser into doing something it shouldn't do on the worst
case.
Because of that, I'm ok with whatever way the browser decides to
handle the contradiction. You can read my position about
error-handling on my earlier post some minutes ago.


Personally, on the case I'm most concerned about ("data:" URIs used
for "Save log" and similar functionalities), there is never a "true"
disposition header; so my use cases do not push towards any of the
options. What I have just written is what I feel is the most
reasonable approach (the provider of a resource should have some
control over it above an arbitrary third party).


Data URIs would very well benefit from this attribute, in my opinion.

This would also cater to the canvas lovers. Downloading something
drawn on a canvas instantly? No problem! Download me!


Yep, these are the cases I am actually concerned about. But on these
scenarios there is no HTTP header involved, so it doesn't matter (for
them) what takes precedence.



Yes, this was only an example which just came to my mind, nothing
special.


This is still one thing that has to be settled though.

a) How do we call the attribute?


Is there any reason to _not_ call it 'content-disposition'?
Ok, there is one: verbosity. But, personally, I have no issue with
some verbosity if it helps making things blatantly explicit.
So many years of browser vendors reverse-engineering the error
handling in competing products have convinced me that being explicit
is a good thing.



Yes, I was trying to refer to the verbosity. There's no html attributes
with dashes in them as far as I know, except for "data-", which are user-
defined. This would kind of break the convention a little. I could think
about having "contentdispo" or some shortname like this, it would fit
"better" to what we currently have in html.




b) Do we include the "filename" part directly into the attribute
  or do we create a SECOND attribute just for this?

People have been posting several formats now. But I don't think we
actually have *agreed* upon one of those.


What's wrong with using the same format as HTTP? I am not too strongly
attached to that format, but I see no point in making things different
from what we already have. As a minor advantage, implementors can
reuse (or copy-paste) some few lines of parsing code instead of
writting them again, since they already parse the header when they get
it on an HTTP response.


Again, html convention: Currently html only has one "statement" in every
attribute, except for things like events (which is javascript) and style
(which is also ANOTHER language: css).

Seems cleaner to me if we stay to the "standard" and not change the syntax
"rules".

Please tell me if I missed anything here!


Regards,
Eduard Pascual


Re: [whatwg] "Content-Disposition" property for tags

2011-06-06 Thread Julian Reschke

On 2011-06-03 17:46, Bjartur Thorlacius wrote:

...

I strongly disagree.  I think browsers that use the Content-Disposition
filename for "attachment" but not "inline" are just buggy and should be
fixed.


FWIW MSIE9 seems to honor the filename hint with inline (contrary to
the test results mentioned earlier in the thread).
...


Hint: the test page has a feedback link.

That being said: I just tried 
 and IE9 
seems to ignore the filename information.


Best regards, Julian


Re: [whatwg] "Content-Disposition" property for tags

2011-06-06 Thread Boris Zbarsky

On 6/5/11 3:53 PM, Bjartur Thorlacius wrote:

On 6/5/11, Boris Zbarsky  wrote:

Why need they be? This isn't Bittorrent.

I think you completely misunderstood my mail...  the point is that
browses do NOT all use the last non-empty path component; some try to
guess a filename based on the query params, in various ways.

No, I understood - my point that it doesn't matter; browsers need not
standardize on variables yo deduce filenames from*.


My point was that there should be _a_ standardized way that sites can 
use to get consistent behavior across browsers.  Content-Disposition 
headers see like that way to me.


-Boris


[whatwg] Codecs (Re: PeerConnection feedback)

2011-06-06 Thread Harald Alvestrand

On 05/31/11 23:45, Ian Hickson wrote:

On Sat, 9 Apr 2011, James Salsman wrote:

>
>  Sorry for the top posting, but I would like to reiterate my considered
>  opinion that Speex be supported for recording.  It is the standard
>  format available from Adobe Flash recording, low bandwidth, open source
>  and unencumbered, efficient, and it is high quality for its bandwidth.

My plan with the codecs issue here is to let the implementors figure out
which codecs they want to implement, and then once there's a common set
across all the implementations, to require that. So I would recommend
petitioning the implementors if you have particular codec desires. :-)

I can't find James' original post, so this may be a new subject line - I 
just want to note that the recent WebRTC code release from Google 
contains implementations of both iLBC and iSAC codecs; we believe that 
makes them open-source, unencumbered and implemented (with all the usual 
disclaimers).


Others will have to discuss the properties that make one or the other 
best for a particular application; part of that discussion will happen 
on the public-web...@w3.org list and the rtc...@ietf.org list.


Harald



Re: [whatwg] WebVTT feedback (was Re: Video feedback)

2011-06-06 Thread Silvia Pfeiffer
On Mon, Jun 6, 2011 at 6:04 PM, Glenn Maynard  wrote:
> On Mon, Jun 6, 2011 at 3:41 AM, Silvia Pfeiffer 
> wrote:
>>
>> I don't think your example is a typical one. In my (unmeasured)
>> experience, the scrolling behaviour is much more typical.
>
> It's definitely an uncommonly complex scene to caption.  I raised it
> wondering about the quality level the format can manage in the harder
> cases.  (To be clear, this isn't something any of the popular ad hoc formats
> can do, either--this was achieved with a brittle rendering-specific hacks.)
>
> I've never seen the scrolling behavior in subtitles, though.  I think
> they're only common in live captions.

Agreed, mostly live, but also when playing back content that had live
captions. Also, we do want to support live captions here, so I think
they are relevant.


>> In fact, that example of yours is really really confusing to me. I
>> would much prefer if the text wasn't displayed on top of each other,
>> but at different locations on the screen - one to the right one to the
>> left, preferably underneath the people that speak. That is a better
>> experience. I believe that example of yours only looks that way
>> because somebody had to work around the problem that the subtitle
>> authoring format didn't allow for such explicit placement.
>
> The scene is jumping all over the place--at one point one pair is directly
> *above* the other pair in the frame.  There's no left/right speaker
> correspondance.  FWIW, I find it intuitive to read.

Even when they are above each other, you could place one on the left
at the top next to the first speaker and one on the right at the
bottom next to the other speaker.

I guess intuitions can be different. :-)


>> >> Eventually, we will want to get rid of the legacy format and just
>> >> deliver WebVTT, but they still need to display as though they came
>> >> from the original broadcast caption format for contractual reasons.
>> >
>> > I don't know what degree of sameness they expect, but as users can
>> > always
>> > override their font (implying different wrapping results, etc.), you'll
>> > never be able to guarantee that it'll look identical to the output of a
>> > more
>> > fixed format.  If captions have editing like the above, it could even
>> > result
>> > in a visible drop in quality.
>>
>> I think the opposite is true. Right now, people work around some of
>> the ways in which they really would like to render their captions
>> because the formats don't allow for example explicit placement.
>> Therefore we get poor quality captions right now. With the features
>> available, we should see better captions, not worse.
>
> Sure (most of the time), but if the contracts you refer to require that
> their content rendered with WebVTT look the same as they did in their
> original format, that won't always be possible.

Most things are actually possible - I've tried to give this a shot
with CEA-608 captions here:
http://www.w3.org/WAI/PF/HTML/wiki/Media_608_WebVTT_Conversion .
Feedback very welcome!

Cheers,
Silvia.


Re: [whatwg] WebVTT feedback (was Re: Video feedback)

2011-06-06 Thread Glenn Maynard
On Mon, Jun 6, 2011 at 3:41 AM, Silvia Pfeiffer
wrote:

> I don't think your example is a typical one. In my (unmeasured)
> experience, the scrolling behaviour is much more typical.
>

It's definitely an uncommonly complex scene to caption.  I raised it
wondering about the quality level the format can manage in the harder
cases.  (To be clear, this isn't something any of the popular ad hoc formats
can do, either--this was achieved with a brittle rendering-specific hacks.)

I've never seen the scrolling behavior in subtitles, though.  I think
they're only common in live captions.

In fact, that example of yours is really really confusing to me. I
> would much prefer if the text wasn't displayed on top of each other,
> but at different locations on the screen - one to the right one to the
> left, preferably underneath the people that speak. That is a better
> experience. I believe that example of yours only looks that way
> because somebody had to work around the problem that the subtitle
> authoring format didn't allow for such explicit placement.
>

The scene is jumping all over the place--at one point one pair is directly
*above* the other pair in the frame.  There's no left/right speaker
correspondance.  FWIW, I find it intuitive to read.

>> Eventually, we will want to get rid of the legacy format and just
> >> deliver WebVTT, but they still need to display as though they came
> >> from the original broadcast caption format for contractual reasons.
> >
> > I don't know what degree of sameness they expect, but as users can always
> > override their font (implying different wrapping results, etc.), you'll
> > never be able to guarantee that it'll look identical to the output of a
> more
> > fixed format.  If captions have editing like the above, it could even
> result
> > in a visible drop in quality.
>
> I think the opposite is true. Right now, people work around some of
> the ways in which they really would like to render their captions
> because the formats don't allow for example explicit placement.
> Therefore we get poor quality captions right now. With the features
> available, we should see better captions, not worse.
>

Sure (most of the time), but if the contracts you refer to require that
their content rendered with WebVTT look the same as they did in their
original format, that won't always be possible.

-- 
Glenn Maynard


Re: [whatwg] WebVTT feedback (was Re: Video feedback)

2011-06-06 Thread Silvia Pfeiffer
On Mon, Jun 6, 2011 at 5:30 PM, Glenn Maynard  wrote:
> On Sat, Jun 4, 2011 at 11:05 AM, Silvia Pfeiffer 
> wrote:
>>
>> If we introduced the scrolling behaviour that I described above where
>> cues that are rendered into the same location as a previous still
>> active cue push that previous cue up, we get this behaviour covered
>> too.
>
> I don't think so.  This is a scene with two simultaneous conversations; in
> order to help make the subtitles readable, they were authored to keep one
> conversation pair always on top, and the other always on the bottom.  Having
> captions move while they're already displayed wouldn't do this.  (I think
> it'd make it unreadable, actually, by adding motion into the mix.)

If you use explicit L: placement, we could turn off the scrolling behaviour.

I don't think your example is a typical one. In my (unmeasured)
experience, the scrolling behaviour is much more typical.

In fact, that example of yours is really really confusing to me. I
would much prefer if the text wasn't displayed on top of each other,
but at different locations on the screen - one to the right one to the
left, preferably underneath the people that speak. That is a better
experience. I believe that example of yours only looks that way
because somebody had to work around the problem that the subtitle
authoring format didn't allow for such explicit placement.


>> Eventually, we will want to get rid of the legacy format and just
>> deliver WebVTT, but they still need to display as though they came
>> from the original broadcast caption format for contractual reasons.
>
> I don't know what degree of sameness they expect, but as users can always
> override their font (implying different wrapping results, etc.), you'll
> never be able to guarantee that it'll look identical to the output of a more
> fixed format.  If captions have editing like the above, it could even result
> in a visible drop in quality.

I think the opposite is true. Right now, people work around some of
the ways in which they really would like to render their captions
because the formats don't allow for example explicit placement.
Therefore we get poor quality captions right now. With the features
available, we should see better captions, not worse.

Regards,
Silvia.


Re: [whatwg] WebVTT feedback (was Re: Video feedback)

2011-06-06 Thread Glenn Maynard
On Sat, Jun 4, 2011 at 11:05 AM, Silvia Pfeiffer
wrote:

> If we introduced the scrolling behaviour that I described above where
> cues that are rendered into the same location as a previous still
> active cue push that previous cue up, we get this behaviour covered
> too.
>

I don't think so.  This is a scene with two simultaneous conversations; in
order to help make the subtitles readable, they were authored to keep one
conversation pair always on top, and the other always on the bottom.  Having
captions move while they're already displayed wouldn't do this.  (I think
it'd make it unreadable, actually, by adding motion into the mix.)

Eventually, we will want to get rid of the legacy format and just
> deliver WebVTT, but they still need to display as though they came
> from the original broadcast caption format for contractual reasons.
>

I don't know what degree of sameness they expect, but as users can always
override their font (implying different wrapping results, etc.), you'll
never be able to guarantee that it'll look identical to the output of a more
fixed format.  If captions have editing like the above, it could even result
in a visible drop in quality.

-- 
Glenn Maynard