Re: File API: File's name property

2013-09-06 Thread Anne van Kesteren
On Wed, Sep 4, 2013 at 11:45 PM, Glenn Maynard gl...@zewt.org wrote:
 On Tue, Sep 3, 2013 at 12:04 PM, Anne van Kesteren ann...@annevk.nl wrote:
 The problem is that once you put it through the URL parser it'll
 become /. And I suspect given directory APIs and such it'll go
 through that layer at some point.

 I don't follow.  Backslashes in filenames are escaped in URLs
 (http://zewt.org/~glenn/test%5Cfile), like all the other things that require
 escaping.

If the raw input to the URL parser includes a backslash, it'll be
treated as a forward slash. I am not really expecting people to use
encodeURI or such utilities.


 Well, my suggestion was rawName and name (which would have loss of
 information), per the current zip archive API design.

 Having a separate field is fine.  This is specific to ZIPs, so it feels like
 it belongs in a ZipFile subclass, not File itself.

Is it? There's no other file systems where the file names are
effectively byte sequences? If that's the case, maybe that's fine.


 We definitely wouldn't
 want raw bytes from filenames being filled in from user filesystems (eg.
 Shift-JIS filenames in Linux),

The question is whether you can have something random without
associated encoding. If there's an encoding it's easy to put lipstick
on a pig.


 and Windows filenames aren't even bytes
 (they're natively UTF-16).

Right, that would end up as a utf-8 byte sequence in File.rawName and
File.name would do the right thing with that.


 There's an API too.

 It might be better to wait until we have a filesystem API, then piggyback on
 that...

Yeah, I wondered about that. It depends on whether we want to expose
directories or just treat a zip archive as an ordered map of
path/resource pairs.


-- 
http://annevankesteren.nl/



[Webmessaging] .ports on MessageEvent objects should probably not be an IDL array

2013-09-06 Thread Boris Zbarsky
This is implementor feedback on 
http://www.w3.org/TR/webmessaging/#event-definitions


See https://www.w3.org/Bugs/Public/show_bug.cgi?id=23176

Note that there is no coverage of the behavior here in the test suite, 
apparently, so Blink's implementation doesn't match what the spec 
currently has at all, and doesn't so much match sanity.  For example, this:


  var a = new MessageChannel();
  var b = new MessageEvent('message', { ports: [a.port1, a.port2] });
  alert(b.ports == b.ports);

alerts false in Blink.  I can't check in IE because in IE10 the 
MessageEvent constructor throws when called as above and in IE9 there is 
no MessageChannel.


In any case, this section of the spec needs fixing and tests...

-Boris



[Bug 23138] Make type a ByteString

2013-09-06 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23138

Arun a...@mozilla.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: File API: File's name property

2013-09-06 Thread Arun Ranganathan

On Sep 6, 2013, at 11:42 AM, Anne van Kesteren wrote:

 On Wed, Sep 4, 2013 at 11:45 PM, Glenn Maynard gl...@zewt.org wrote:
 On Tue, Sep 3, 2013 at 12:04 PM, Anne van Kesteren ann...@annevk.nl wrote:
 The problem is that once you put it through the URL parser it'll
 become /. And I suspect given directory APIs and such it'll go
 through that layer at some point.
 
 I don't follow.  Backslashes in filenames are escaped in URLs
 (http://zewt.org/~glenn/test%5Cfile), like all the other things that require
 escaping.
 
 If the raw input to the URL parser includes a backslash, it'll be
 treated as a forward slash. I am not really expecting people to use
 encodeURI or such utilities.


I think it may be ok to restrict / and \.  I don't think we lose too much 
here by not allowing historically directory delimiting characters in file 
names.

The question is what to do with a /  or a \.   I'm inclined to say UAs 
should treat those as U+FFFD.

 
 Well, my suggestion was rawName and name (which would have loss of
 information), per the current zip archive API design.
 
 Having a separate field is fine.  This is specific to ZIPs, so it feels like
 it belongs in a ZipFile subclass, not File itself.
 
 Is it? There's no other file systems where the file names are
 effectively byte sequences? If that's the case, maybe that's fine.


Well…. 

Some file systems don't store names as unrestricted byte sequences (older 
Windows), but GNU systems usually do.  Some byte sequences are not valid names. 
Conversely, names of existing files may not be representable as byte sequences 
(and sometimes there are two representations -- e.g. Amèlie.txt will either use 
00e9 or 0065 0031 for the è  -- both are Unicode equivalents, but are different 
byte sequences). Some file systems perform Unicode canonicalization on file 
names, which is more or less what I think the Web should do.

I think we run only a small risk of information loss, but I DO think that File 
name should be an [EnforceUTF16] DOMString.  That way, we have the best shot at 
byte sequences based on the underlying characterization.

Summary: I'll punt on File.rawName till a rainier day than today, but I will 
restrict / and \ since they are historically directory separators.  I know 
that there are OTHER characters that we can also restrict, but these two are 
the big ones and get us some 80-20 sanitization :)

Glenn said:

 It might be better to wait until we have a filesystem API, then piggyback on
 that...

+1.

-- A*

Re: File API: File's name property

2013-09-06 Thread Anne van Kesteren
On Fri, Sep 6, 2013 at 4:42 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Sep 4, 2013 at 11:45 PM, Glenn Maynard gl...@zewt.org wrote:
 It might be better to wait until we have a filesystem API, then piggyback on
 that...

 Yeah, I wondered about that. It depends on whether we want to expose
 directories or just treat a zip archive as an ordered map of
 path/resource pairs.

Actually, given that zip paths are byte sequences, that would not work
anyway. The alternative might be to always map it to code points
somehow via requiring an encoding to be specified and just deal with
the losses, but that doesn't seem general purpose enough.


-- 
http://annevankesteren.nl/



[Bug 22228] Clarification of timeout attribute late overrides

2013-09-06 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=8

Anne ann...@annevk.nl changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Anne ann...@annevk.nl ---
Seems clear enough, especially with the note.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: File API: File's name property

2013-09-06 Thread Glenn Maynard
On Fri, Sep 6, 2013 at 10:42 AM, Anne van Kesteren ann...@annevk.nlwrote:

 If the raw input to the URL parser includes a backslash, it'll be
 treated as a forward slash. I am not really expecting people to use
 encodeURI or such utilities.


People who don't will have a bug, but all this is doing is preemptively
adding the bug, not preventing it, and forcing it on unrelated features
(HTMLInputElement.files).  Don't the ZIP URL proposals require some
characters or other to be escaped anyway (at least of the ones that support
navigation)?

It's far too late to try to keep people from having to escape things in
URLs.

  Having a separate field is fine.  This is specific to ZIPs, so it feels
 like
  it belongs in a ZipFile subclass, not File itself.

 Is it? There's no other file systems where the file names are
 effectively byte sequences? If that's the case, maybe that's fine.


There are lots of them.  I meant that it seems like wanting to expose raw
bytes is specific to ZIPs.  I hope we wouldn't expose the user's local
filesystem locale to the Web.  Depending on the user's locale causes some
of the more obnoxious bugs the platform has, we should be fighting to kill
it, not add more of it.


   We definitely wouldn't
  want raw bytes from filenames being filled in from user filesystems (eg.
  Shift-JIS filenames in Linux),

 The question is whether you can have something random without
 associated encoding. If there's an encoding it's easy to put lipstick
 on a pig.


You can have filenames in Linux that are in a different encoding than
expected.  I don't know why you'd want to expose that to the web, though.


   There's an API too.
 
  It might be better to wait until we have a filesystem API, then
 piggyback on
  that...

 Yeah, I wondered about that. It depends on whether we want to expose
 directories or just treat a zip archive as an ordered map of
 path/resource pairs.


I've found being able to work with a directory or a ZIP in the same way to
be useful in the past, too.


On Fri, Sep 6, 2013 at 12:08 PM, Anne van Kesteren ann...@annevk.nl wrote:

 Actually, given that zip paths are byte sequences, that would not work
 anyway. The alternative might be to always map it to code points
 somehow via requiring an encoding to be specified and just deal with
 the losses, but that doesn't seem general purpose enough.


Taking an arbitrary use case: showing the user a list of files inside a
ZIP, and letting him pick one to be extracted.  Exposing raw filenames is
one way to make this work: you iterate over Files in the ZIP, pull out the
File.name for display to the user and stash the File.rawName so you can
look up the File later.  Once the user picks a file from the list, you call
zip.getFileByRawName(stashedRawName) with the associated rawName to
retrieve the selected file.

But, that doesn't just work.  I assume the API will have a
getFileByName(DOMString filename)-like method as well as a rawName
method, and people will be much more likely to ignore byRawName and only
use byName.  The developer has to be careful to store the rawName and only
look up files using raw names if he wants broken filenames to work.

An alternative solution: as you iterate over Files to create a list to
display to the user, stash the File as well (instead of the rawName),
associated with each list entry.  When the user selects a file, you just
use the File you already have, and never pass the filename back to the
API.  This would also take special effort by developers, but no more than
the rawName solution, and it avoids exposing raw filenames entirely.

For ZIP URLs, it seems like linking inside a legacy ZIP (rather than a ZIP
of icons or whatever that you just created to link to) would be uncommon.
(Also, if you think people won't escape backslashes, they definitely won't
escape garbage filenames with a special byte-escape mechanism...)  Are
there likely use cases here?


On Fri, Sep 6, 2013 at 1:04 PM, Arun Ranganathan a...@mozilla.com wrote:

 I think it may be ok to restrict / and \.  I don't think we lose too
 much here by not allowing historically directory delimiting characters in
 file names.


\ is a valid character in real filenames.  This would break selecting
filenames with backslashes in them with HTMLInputElement, which works fine
today.

-- 
Glenn Maynard


Scoped absolute paths in querySelector/All

2013-09-06 Thread Brett Zamir
I am wondering whether thought has been given to allowing selectors 
beginning with  for use with querySelector/All such as:


  .sharedClass

Sometimes one wishes to resolve a precise hierarchy but relative to the 
current element. Currently, to do so with precision, one must either 
specify a path starting from the document root, a unique ID, or use 
other scripting methods.


Having such an option would provide the same convenience for precise 
access as XPath or to a lesser extent, as JSON, allow.


The following document illustrates the concern--in this case, where we 
are trying to get only the second span relative to #div1 but without 
needing to specify or be aware of the whole document hierarchy:


!DOCTYPE htmlhtmlheadmeta charset=utf-8 //headbody

div id=div1
span class=sharedClassFirst/span
div
span class=sharedClassSecond/span
/div
/div

script

  var s = document.querySelector('#div1');

  // The following gets both spans instead of the one directly inside 
that we want

  var relativeSelector = s.querySelectorAll('.sharedClass');
  alert(relativeSelector.length); // 2

  // The following gets the desired span, but required us to specify 
the full path or redundantly express the path to our parent again

  var absoluteSelector = s.querySelectorAll('#div1  .sharedClass');
  alert(absoluteSelector[0].textContent); // First

/script/body/html

(Although the use case would be far less common, a path might also begin 
with  when run against documents to allow usage with XML documents 
where a path was desired relative to the root but without committing to 
a specific root element.)


It would also be nice to be able to modify the element or 
elements--e.g., if there were a removeSelector(sel) analogue to the 
ability to use delete obj.prop.prop2 on a JSON object, a 
replaceSelector(sel, el) convenience method, etc..


Best,
Brett



Re: Scoped absolute paths in querySelector/All

2013-09-06 Thread Boris Zbarsky

On 9/6/13 9:13 PM, Brett Zamir wrote:

I am wondering whether thought has been given to allowing selectors
beginning with  for use with querySelector/All


There have, as have selectors like :scope  .sharedClass.  Gecko had 
an implementation of the :scope version of this at one point, but people 
couldn't make up their mind as to what they want here, so we removed it 
again until it's clearer what the API will actually look like.


-Boris



Re: Scoped absolute paths in querySelector/All

2013-09-06 Thread Tab Atkins Jr.
On Fri, Sep 6, 2013 at 6:13 PM, Brett Zamir bret...@gmail.com wrote:
 I am wondering whether thought has been given to allowing selectors
 beginning with  for use with querySelector/All such as:

   .sharedClass

 Sometimes one wishes to resolve a precise hierarchy but relative to the
 current element. Currently, to do so with precision, one must either specify
 a path starting from the document root, a unique ID, or use other scripting
 methods.

Selectors API 2 provides this ability through the .find() and
.findAll() functions:
http://dev.w3.org/2006/webapi/selectors-api2/#findelements-relative.

 (Although the use case would be far less common, a path might also begin
 with  when run against documents to allow usage with XML documents where
 a path was desired relative to the root but without committing to a specific
 root element.)

That's what the :root pseudoclass is for, by the way:
http://dev.w3.org/csswg/selectors/#the-root-pseudo

 It would also be nice to be able to modify the element or elements--e.g., if
 there were a removeSelector(sel) analogue to the ability to use delete
 obj.prop.prop2 on a JSON object, a replaceSelector(sel, el) convenience
 method, etc..

I don't understand what this would do, from your description.

~TJ