Re: [whatwg] Autoplaying media elements not in a document

[David Singer]

OK, you are right.  If a script wants to annoy me, it can.  And boy, do some 
web designers not know how annoying that can be :-(

On Oct 18, 2010, at 16:59 , Robert O'Callahan wrote:

> On Tue, Oct 19, 2010 at 12:57 PM, David Singer  wrote:
> isn't autoplaying a media element over which the user may well have no 
> control (unless the page offers a script to control it), inappropriate?
>  
> Maybe, but elements not in a document can only be created by script in the 
> first place. If script wants to have a disconnected autoplay element, why not 
> let it? If it wants to be annoying it can just call play().
> 
> Rob
> -- 
> "Now the Bereans were of more noble character than the Thessalonians, for 
> they received the message with great eagerness and examined the Scriptures 
> every day to see if what Paul said was true." [Acts 17:11]

David Singer
Multimedia and Software Standards, Apple Inc.

Re: [whatwg] Autoplaying media elements not in a document

[Robert O'Callahan]

On Tue, Oct 19, 2010 at 12:57 PM, David Singer  wrote:

> isn't autoplaying a media element over which the user may well have no
> control (unless the page offers a script to control it), inappropriate?
>

Maybe, but elements not in a document can only be created by script in the
first place. If script wants to have a disconnected autoplay element, why
not let it? If it wants to be annoying it can just call play().

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]

Re: [whatwg] Autoplaying media elements not in a document

[David Singer]

isn't autoplaying a media element over which the user may well have no control 
(unless the page offers a script to control it), inappropriate?

David Singer
Multimedia and Software Standards, Apple Inc.

Re: [whatwg] Exposing filenames in DataTransfer

[Robert O'Callahan]

On Tue, Oct 19, 2010 at 9:59 AM, Daniel Cheng  wrote:

> However, this leads to issues like file system paths being exposed through
> properties like "x-special/gnome-icon-list" or even "text/plain". What is
> the expected behavior here? Mirroring the native dragging clipboard allows
> for a much richer interaction with the system, but I'm not sure if we need
> to go out of our way to try to scrub all paths from the drag. After all, if
> you're dropping the file on the page, you're already exposing the contents
> of the file, which are probably much more interesting than just the path.
> Thoughts?


The path can expose interesting metadata, such as the local username (useful
for dictionary attacks!), the names of file servers, names of projects, etc.
Obviously the filename can expose some too, but hopefully the user's more
aware of that.

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]

Re: [whatwg] Exposing filenames in DataTransfer

[Daniel Cheng]

Sorry, I'm using "properties" as a generic term for different types of data
that might be set in a drag. A lot of file managers try to be helpful and
populate alternative metadata for a file. Some of this metadata contains
file system paths. If the web dragging clipboard mirrors the native dragging
clipboard, then the metadata will be visible to web apps. In this example,
if you were on Linux with my patch, you could call
event.dataTransfer.getData("x-special/gnome-icon-list") while handling a
drop and the returned string would contain the file system path.

Daniel

On Mon, Oct 18, 2010 at 14:12, Tab Atkins Jr.  wrote:

> On Mon, Oct 18, 2010 at 1:59 PM, Daniel Cheng  wrote:
> > However, this leads to issues like file system paths being exposed
> through
> > properties like "x-special/gnome-icon-list" or even "text/plain". What is
> > the expected behavior here? Mirroring the native dragging clipboard
> allows
> > for a much richer interaction with the system, but I'm not sure if we
> need
> > to go out of our way to try to scrub all paths from the drag. After all,
> if
> > you're dropping the file on the page, you're already exposing the
> contents
> > of the file, which are probably much more interesting than just the path.
>
> Could you provide some more detail?  I have no idea what you mean by
> "However, this leads to issues like file system paths being exposed
> through properties like "x-special/gnome-icon-list" or even
> "text/plain"."  Those aren't properties, nor do they expose
> file-system paths.
>
> Do you perhaps mean that they expose generally the origin of the file,
> such that you know if you see "x-special/gnome-icon-list" that the
> file is probably coming from wherever gnome stores that kind of file?
>
> ~TJ
>

Re: [whatwg] Exposing filenames in DataTransfer

[Tab Atkins Jr.]

On Mon, Oct 18, 2010 at 1:59 PM, Daniel Cheng  wrote:
> However, this leads to issues like file system paths being exposed through
> properties like "x-special/gnome-icon-list" or even "text/plain". What is
> the expected behavior here? Mirroring the native dragging clipboard allows
> for a much richer interaction with the system, but I'm not sure if we need
> to go out of our way to try to scrub all paths from the drag. After all, if
> you're dropping the file on the page, you're already exposing the contents
> of the file, which are probably much more interesting than just the path.

Could you provide some more detail?  I have no idea what you mean by
"However, this leads to issues like file system paths being exposed
through properties like "x-special/gnome-icon-list" or even
"text/plain"."  Those aren't properties, nor do they expose
file-system paths.

Do you perhaps mean that they expose generally the origin of the file,
such that you know if you see "x-special/gnome-icon-list" that the
file is probably coming from wherever gnome stores that kind of file?

~TJ

[whatwg] Exposing filenames in DataTransfer

[Daniel Cheng]

I've been working on better support of arbitrary MIME types in WebKit for
some time, and I had some implementation questions. In the past, UAs seem to
have gone out of their way to make sure full filesystem paths aren't exposed
to the Javascript (e.g. in the file input control). When I did the work for
WebKit, I implemented the web dragging clipboard as a simple reflection of
the native dragging clipboard.

However, this leads to issues like file system paths being exposed through
properties like "x-special/gnome-icon-list" or even "text/plain". What is
the expected behavior here? Mirroring the native dragging clipboard allows
for a much richer interaction with the system, but I'm not sure if we need
to go out of our way to try to scrub all paths from the drag. After all, if
you're dropping the file on the page, you're already exposing the contents
of the file, which are probably much more interesting than just the path.
Thoughts?

Daniel

Re: [whatwg] Inline Web Worker

[Drew Wilson]

I believe it's a security feature.

Imagine that you download foo.html into your C:/ - according to the logic
below, script running in foo.html should be able to read *any file on your
C:/ drive*. That seems scary to me.

FWIW, chrome allows passing the --allow-file-access-from-files command line
flag to make it easier for developers to work locally without running an
HTTP server.

-atw

On Sat, Oct 16, 2010 at 8:19 AM, Samuel Ytterbrink wrote:

> Good news. :D
>
> But then i got another problem, why is not
> "file:///some_directory_where_the_html_are/" not the same domain as
> "file:///some_directory_where_the_html_are/child_directory_with_ajax_stuff/".
> I understand if it was not okay to go closer to root when ajax,
> "file:///where_all_secrete_stuff_are/" or "/../../".
>
> You see i wonder why i need a web-server to try some things. And I'm sure
> that there are more developers than me that thinks that local single page
> Ajaxs applications have a  future. One thing that could probably solve this
> is if the File API will support folders. Then the user could select the
> files for the program...
>
> /Samuel Ytterbrink
>
> 2010/10/16 Simon Pieters 
>
> On Sat, 16 Oct 2010 03:12:38 +0200, Jonas Sicking 
>> wrote:
>>
>>  Allowing both blob URLs and data URLs for workers sounds like a great
>>> idea.
>>>
>>
>> FWIW, Opera supports data URLs for Worker (but not SharedWorker since it
>> could be used to cross the same-origin policy if two pages opened a
>> SharedWorker with the same data URL -- this could be solved while still
>> supporting data URLs but we decided to just drop it for now).
>>
>> --
>> Simon Pieters
>> Opera Software
>>
>
>

Re: [whatwg] Question regarding event: in server-sent events

[Nicholas Zakas]

Just for my own understanding, what you're saying is:

1) Any event name in the stream must be a valid event name in that it must not 
have spaces, special characters, etc. (The wording in the spec made me think 
that it must be an event name that is listed in the DOM Events spec, such as 
click.)

2) When you define an custom event name, this still fires the message event 
with event.type set to the custom event name.

Are those correct?

-Nicholas
 
__
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."
-Original Message-
From: Anne van Kesteren [mailto:ann...@opera.com] 
Sent: Friday, October 15, 2010 11:42 AM
To: wha...@whatwg.org; Nicholas Zakas
Subject: Re: [whatwg] Question regarding event: in server-sent events

On Fri, 15 Oct 2010 20:34:14 +0200, Nicholas Zakas   
wrote:
> In reading through the spec, it looks like this is legal in the event  
> stream:
>
> event: foo
> data: bar
>
> And then processed as:
>
>>> If the event name buffer is not the empty string but is also not a  
>>> valid event type name, as defined by the DOM Events specification, set  
>>> the data  buffer and the event name buffer to the empty string and  
>>> abort these steps.
>
> If I'm reading this correctly, an event name of "foo" would fail this  
> step in the process and not cause a message event to be fired. However,  
> if the event name were for example "click", then this would be okay and  
> the following step would be taken:

"foo" is a valid event type name. This would only fail when  
Event.initEvent(event name buffer, ...) fails. It seems per the current  
draft of DOM Events that will be never so maybe this ought to be reworded  
some. But then DOM Events is not done yet so...


> 3)   Assuming I've understood the current spec correctly, what is  
> the use case for named events?

To make dispatching to different parts of the code easier. Without having  
to create some kind of logic that parses the data first.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] rendering WebSRT cue parts in use for subtitling songs

[Tab Atkins Jr.]

On Sat, Oct 16, 2010 at 4:18 PM, Silvia Pfeiffer
 wrote:
> I would expect a style of rendering where all words are first
> displayed in ordinary display and e.g. painted in a different color as
> the time reaches them. Something like:
>
> ::cue {
>  color: black;
> }
>
> // this is in-valid as per spec right now
> ::cue timestamp {
>  color: red;
> }
>
> But FAIK we don't currently have a means to address the
> timestamp-activated parts within a cue through CSS. How should that be
> done?

http://www.whatwg.org/specs/web-apps/current-work/complete/rendering.html#the-'::cue-part'-pseudo-element

::cue {
  color: black;
}

::cue-part(past) {
  color: red;
}

~TJ

Re: [whatwg] rendering WebSRT cue parts in use for subtitling songs

[Diogo Resende]

Maybe the browser could simulate :hover (or :focus) for those words so
it would be easy to style it.

-- 
Diogo


On Sun, 2010-10-17 at 10:18 +1100, Silvia Pfeiffer wrote:
> I've just looked into using WebSRT for subtitling songs where I'm also
> using it to provide more detailed timing on the individual words
> within the cue. This can obviously used for Karaoke-style display, but
> is also very educational for learning the lyrics to a song or even for
> a deaf person to follow along and get a feeling for the rhythm of a
> piece of music.
> 
> I've come up with the following example markup, which I believe is
> correct according to the spec.
> 
> 1
> 00:00:10,000 --> 00:00:12,210
> <00:00:10,035>Chocolate <00:00:11,000>Rain
> 
> 2
> 00:00:12,210 --> 00:00:15,910
> <00:00:13,250>Some <00:00:13,500>stay <00:00:13,750>dry
> <00:00:14,25>and <00:00:14,50>others <00:00:15,00>feel
> <00:00:15,25>the <00:00:15,50>pain
> 
> 3
> 00:00:15,910 --> 00:00:15,920
> <00:00:16,000>Chocolate <00:00:16,500>Rain
> <00:00:13,250>Some <00:00:13,500>stay <00:00:13,750>dry
> <00:00:14,25>and <00:00:14,50>others <00:00:15,00>feel
> <00:00:15,25>the <00:00:15,50>pain
> 
> 4
> 00:00:15,920 --> 00:00:18,000
> <00:00:16,000>Chocolate <00:00:16,500>Rain
> 
> 5
> 00:00:18,000 --> 00:00:21,170
> <00:00:18,250>A <00:00:18,500>baby <00:00:19,000>born
> <00:00:19,250>will <00:00:19,500>die <00:00:19,750>before
> <00:00:20,500>the <00:00:20,750>sin
> 
> 6
> 00:00:21,180 --> 00:00:23,000
> <00:00:21,200>Chocolate <00:00:21,500>Rain
> 
> 
> My question now is: how can I apply CSS to this and render the words.
> I would expect a style of rendering where all words are first
> displayed in ordinary display and e.g. painted in a different color as
> the time reaches them. Something like:
> 
> ::cue {
>   color: black;
> }
> 
> // this is in-valid as per spec right now
> ::cue timestamp {
>   color: red;
> }
> 
> But FAIK we don't currently have a means to address the
> timestamp-activated parts within a cue through CSS. How should that be
> done?
> 
> Cheers,
> Silvia.

Re: [whatwg] Autoplaying media elements not in a document

[Philip Jägenstedt]

On Mon, 18 Oct 2010 01:01:00 +0200, Chris Pearce   
wrote:



  In the description of the media ready states for HAVE_ENOUGH_DATA [1],
the spec says:


If the autoplaying flag

is true, and the |paused
|
attribute is true, and the media element

has an |autoplay
|
attribute specified, and the media element

is in a |Document
|
whose browsing context

did not have the sandboxed automatic features browsing context flag

set when the |Document
|
was created, then the user agent may also set the |paused
|
attribute to false, queue a task

to fire a simple event

named |play
|,
and queue a task

to fire a simple event

named |playing
|.


This means that we'll will only autoplay if a media element is in a
document. Why do we prevent media elements not in a document from
autoplaying? We allow audio from a media element not in a document to
play, why not allow autoplay to work while not in a document too?

I note that Firefox, Chrome, Safari and Opera all autoplay when a media
element is not in a document. It looks like IE9 Beta never autoplays
unless the media element is hard coded in the HTML file with an autoplay
attribute; IE9 doesn't seem to honour autoplay set from script.

Unless there's a good reason not to, and since most browsers have
implemented autoplay when not in a document anyway, perhaps we should
update the spec to match the implemented behaviour?


Regards,
Chris Pearce.

[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-have_enough_data


Subversion is too slow to say exactly when, but "and the media element is  
in a Document whose browsing context did not have the sandboxed automatic  
features browsing context flag set when the Document was created" was  
added to the spec quite recently, after Opera implemented autoplay anyway.


Assuming the change in behavior was accidental, the spec should instead  
say "and the media element is not in a Document whose browsing context had  
the sandboxed automatic features browsing context flag set when the  
Document was created".


--
Philip Jägenstedt
Core Developer
Opera Software