Re: [whatwg] Font metrics
On Sat, 03 Apr 2010 17:23:39 +0300, Greg Brown gkbr...@mac.com wrote: OK, that makes sense. Thanks for the info. However, a extra readonly attribute float height to the TextMetrics interface should be fairly trivial to implement for browser vendors and would greatly help web developers layout text in Canvas. On Apr 2, 2010, at 5:39 PM, Ian Hickson wrote: On Fri, 2 Apr 2010, Greg Brown wrote: In reviewing the current draft API for the canvas element (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html), I noticed that there is no support for obtaining font metrics such as ascent, descent, leading, and bounding box. It seems like the most recent discussion regarding font metrics took place a couple of years ago: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014706.html But even that thread refers to discussions from 2006. I would personally like to see support for these values added to the API. Is this something that could be considered for the final spec? What are the major obstacles to providing such support? I would think that this information could be easily obtained using the underlying graphics API, but maybe I am missing something. It's something we'll probably add in due course, but for now we're waiting for the existing canvas API stuff to be implemented properly. We can't add too much stuff at once, because if we do the browser vendors get so far behind that they end up either rushing to catch up (leading to more bugs), or skipping parts in order to get the rest done right (leading to parts of the spec being ignored). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Mathieu 'p01' Henri \ Opera Software JavaScript Developer \ Core ExtApps
[whatwg] Forms feedback
On Thu, 21 Jan 2010, NARUSE, Yui wrote:
In 4.10.19.4 URL-encoded form data, The
application/x-www-form-urlencoded encoding algorithm,
it says:
For each character in the entry's name and value, apply the following
subsubsteps:
If the character isn't in the range U+0020, U+002A, U+002D, U+002E,
U+0030 to U+0039, U+0041 to U+005A, U+005F, U+0061 to U+007A then
replace the character with a string formed as follows: Start with the
empty string, and then, taking each byte of the character when
expressed in the selected character encoding in turn, append to the
string a U+0025 PERCENT SIGN character (%) followed by two characters
in the ranges U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) and
U+0041 LATIN CAPITAL LETTER A to U+0046 LATIN CAPITAL LETTER F
representing the hexadecimal value of the byte (zero-padded if
necessary).
If the character is a U+0020 SPACE character, replace it with a single
U+002B PLUS SIGN character (+).
This means, U+9670, encoded as �x89�x41 in Shift_JIS, must be encoded
as %89%41, and shouldn't be %89A?
Either is fine (they mean the same thing). I've changed the spec to be
closer to what browsers do though, thanks.
On Thu, 21 Jan 2010, Aryeh Gregor wrote:
MediaWiki currently uses a search-suggest feature based on lots of
JavaScript that's used to calculate all sorts of widths and heights to
painstakingly construct an absolutely-positioned div, and reimplement
standard dropdown navigation controls on top of that. It works pretty
well (go to en.wikipedia.org and start typing a query to see --
implementation at
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/mwsuggest.js?view=markup),
but it's a horrible hack and doesn't integrate perfectly with the
system. When I found out Opera implements datalist, thanks to the
helpful spec annotations, I tried rewriting mwsuggest.js to use
datalist where supported.
My primary feedback here is that a simpler JS API would *really* be
nice. In this kind of situation, typically you receive some JSON or
whatnot from the server, so you have a JavaScript array that you want
to use for suggestions. The code to make a given list the suggest
source for an input is something like:
var datalist = document.getElementById( 'arbitrary-id' );
if ( datalist == null ) {
datalist = document.createElement( 'datalist' );
datalist.id = 'arbitrary-id';
document.body.appendChild( datalist );
} else {
datalist.innerHTML = '';
}
input.setAttribute( 'list', 'arbitrary-id' );
while ( var i = 0; i suggestions.length; i++ ) {
var option = document.createElement( 'option' );
option.value = suggestions[i];
datalist.appendChild( option );
}
This is all quite awkward. It was pointed out on IRC that there are
legitimate use-cases for declarative datalists (e.g.,
http://html5.lachy.id.au/), but I'd expect JS-constructed datalists to
be a much bigger use-case. I can think of several sites off the top
of my head that use absolutely-positioned divs to provide search
suggestions to users, but none that do so statically. So I think a
better API is needed -- preferably just
input.suggest = suggestions;
or similar. The details aren't particularly important, but the
current API is really cumbersome when used from JS.
To be fair a lot of the above is redundant with just having the datalist
in the document ahead of time. All you really need is to set the contents
of the datalist element's contents each time; this need not be more than
one line if what you send from the server is a string of HTML representing
the option elements.
I agree that it would be nice to have a non-DOM way of doing this also,
though, from a performance point of view if nothing else. However, as
Aryeh says:
On Thu, 21 Jan 2010, Aryeh Gregor wrote:
It's also worth noting that datalist currently seems to be conceived
as a combobox, while search suggestions deserve totally different UI.
Opera's UI is suitable to search suggestions, but WebKit's proposed UI
is inappropriate for them:
http://docs.google.com/View?id=dch3zh37_0cf8kc8c4
There's a little drop-down arrow you have to click to get the list,
which is unexpected for search suggestions. If a separate suggest IDL
attribute were added, UAs could provide different UI for that and
datalist.
...it would probably make more sense to wait until the current stuff is
implemented, and then add a separate addition for suggest UI and API.
On Mon, 25 Jan 2010, TAMURA, Kent wrote:
On setting, if the valueAsNumber attribute does not apply, as defined
for the input element's type attribute's current state, then throw an
INVALID_STATE_ERR exception. Otherwise, if the valueAsDate attribute
applies, run the algorithm to convert a Date object to a string
defined for that state, passing it a Date object whose time value is
the new value, and set the value of the
Re: [whatwg] Will you consider about RFC 4329?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ian Hickson i...@hixie.ch wrote: On Mon, 5 Apr 2010, Swampert wrote: In your HTML5 draft standard, the default value for type attribute in script element is text/javascript. While according to RFC 4329, the MIME type text/javascript is obsolete, the proper MIME type for JavaScript is application/javascript or application/ecmascript. The type everyone uses is text/javascript. What's the point of using application/javascript? What problem does it solve? I believe this has to do with character encoding issues and is the same reason that application/xml is preferred over text/xml. MIME types in the text/* set apparently have a default encoding of US-ASCII which I can imagine may throw up conflicts in some situations given that the primary and generally accepted encoding for XML and HTML documents (and increasingly other applications in general) is Unicode based. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREIAAYFAku6/5EACgkQA5dpS+2BZawJzgD/Vh5NYeOT2j0hKIiW59vVKzIG mqhFmUbFhz2PsFFUUB4A/Asxy2C4HiBIp8FfoZ1Elz+4jTr7Ehhv1xSGKe8Xwl5k =1FdY -END PGP SIGNATURE-
Re: [whatwg] Proposal for secure key-value data stores
Sorry for misunderstanding your original suggestion. On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas nza...@yahoo-inc.comwrote: I certainly can't argue against a focus on JS crypto. :) What I'd like to do is eliminate what I believe will be a repeated pattern for developers in the future. It would be really nice if, in addition to having access to crypto functions, there was an area where I could stick data that would get encrypted automatically (and of course, where I could be sure the data would be eliminated after a set amount of time). It seems to me that Dirk is right that crypto in the browser is a more general problem and that a general crypto API would be much more valuable than creating new APIs with similar/duplicate functionality + crypto. Optimizing for repeated patterns probably should wait until we see what patterns are actually common. :-) My proposal is less about encryption and more about providing better control over how data is stored and for how long. Can you provide some concrete use cases for expiration of content? They'd probably have to be pretty dramatic to warrant creating yet another storage mechanism. Maybe this can somehow be integrated into IndexedDB? There's very little chance of it being a v1 feature, but maybe we could make sure it's possible to add in future versions. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto: whatwg-boun...@lists.whatwg.org] On Behalf Of Dirk Pranke Sent: Tuesday, March 30, 2010 3:09 PM To: Nicholas Zakas Cc: whatwg@lists.whatwg.org; Jeremy Orlow Subject: Re: [whatwg] Proposal for secure key-value data stores On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Yes, that's precisely what I'm talking about. It seems to me that this will end up being a pretty common pattern (encrypting/decrypting data stored locally). The idea behind letting the key to be defined by the developer is to allow any usage that developers deem appropriate for the situation. For example, one might want to only use a server-generated key to access the data, in which case this data won't be available offline but will be used to supplement the online behavior. Another might determine the key based on some information in a cookie, which is less secure but does allow offline access while also ensuring that if the cookie changes or is deleted, the data remains secure. The idea behind the expiration date is to allow developers to be sure the data won't stay around on disk indefinitely. Think about the Internet café use case where people are repeatedly logging in and out - we don't want everyone's data living on that computer for however many years it's in use. One way or another, I think JavaScript crypto is going to be important in the next few years. Perhaps we should instead focus on a set of JS Crypto APIs, since that is largely orthogonal to the storage APIs? -- Dirk
Re: [whatwg] Forms feedback
On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson i...@hixie.ch wrote:
Well you currently can do this by using the onbeforeprint and onafterprint
hooks, though that's not exactly pretty. Hopefully it will also be
possible with media-specific CSS, though that depends on how details
ends up working in CSS. If this proves to not be enough, we'll have to add
something to support it; however, I'd like to wait until this is more
widely deployed (so we get more experience) before changing this.
I believe the CSS for details can be nothing more than:
details:not(open) :not(summary) {
display: none;
}
(Plus general default styling of details and summary, of course.)
On Mon, 22 Mar 2010, bgy wrote:
On webkit based browser, we can see a little cross used to reset the
field, it's useful, but in some ajax based application, it could be
useful to be able to handle this event, to dispatch the event to any
controller and reset results.
Use case:
Highlight a given text in webpage.
Input search is likely to be used since the highlight functionnality
will search through the webpage and highlight all matched patterns. In a
server side solution, the problem is likely to be inexistant, but if we
use a plain javascript option, it'll be usefull to handle the reset
event to remove the highlighting from the page in browser impletementing
this functionnality.
What are your thoughts about this ?
I don't really understand the proposal or the use case. Can you elaborate?
The proposal is to mandate that input type=search expose some sort
of clear widget in itself, which fires an appropriate event when the
user activates it.
His use-case was doing an in-page text search+highlight in javascript,
and wanting to know when he can just yank all the highlighting.
On Thu, 1 Apr 2010, John Gregg wrote:
For context, Ian Fette started a thread about uploading directories of
files in December:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024455.html
At that time, it was thought that directory upload could be implemented
by a UA in response to a input type=file multiple tag using
different UI only, and modifying the FileAPI spec to allow path
information in the form
input.files[0].name=1.jpg
input.files[0].path=a
input.files[1].name=2.jpg
input.files[1].path=a/b
input.files[2].name=3.jpg
input.files[2].path=a/c
I've started developing a prototype of this in WebKit/Chromium. Based
on what I've encountered so far, I would like to propose adding
directory upload functionality using an explicit new 'directory'
attribute on the file input element.
The existing behavior of input type=file multiple would not change,
but when processing input type=file directory, the UA would display
a directory selection UI and store the path information, and *not* allow
individual files to be selected. It would allow multiple files to have
the same leaf name (.name attribute), as long as the paths were
different. The path attributes would include the name of the chosen
directory
This would be preferable for several reasons:
- Most built-in file system UI on major platforms (Windows/Mac/Linux)
have distinct dialogs for choosing files and choosing directories.
Allowing the UA to use these directly makes sense rather than creating
hybrids.
- Avoiding leaf name conflicts in a directory tree is not feasible in
many applications -- asking a user to ensure unique photo names in a
large set of albums before uploading would fail to meet that use case.
Therefore HTML documents should know in advance whether the path
information will be relevant in the eventual storage of the files.
Sites currently using input type=file multiple would have
compatibility problems with an implementation which allowed conflicting
file names along different paths.
What are your thoughts about adding the 'directory' attribute?
What is the advantage over an input type=file multiple control? It seems
like it would be more backwards compatible to just make this a UI switch
-- let the user chose whether he's uploading a file, many files, or a
directory of files. That's also more backwards-compatible.
The advantages are precisely what was listed in the email - a proper
directory uploader with path information for the files (either baked
into the filename or available separately) allows you to:
1. Easily accept multiple files with the same name, as long as they're
in different directories (this restriction is already enforced in all
major OSes)
2. Maintain the directory structure the user uploaded, for example a
pictures directory with folders for vacation and wedding photos
separate.
3. Expose the most appropriate UI to the user - in most file selection
dialogs you are *unable* to select a folder itself. In the few that
allow it, it is often difficult to discover the functionality. OSes
do provide a proper directory picker, though, which is much more clear
about what it does.
~TJ
Re: [whatwg] HTMLCollection and HTMLAllCollection suggestion
On Apr 5, 2010, at 1:04 PM, David Flanagan wrote: Perry Smith wrote: On Apr 3, 2010, at 11:58 PM, David Flanagan wrote: Perry Smith wrote: HTMLCollection has a namedItem method that returns either null or one object. [1] HTMLAllCollection has a namedItem method that returns either null, one object, or a collection of objects. [2] I'm a Rails freak and one of the things that they do which I love is foo returns an item and foos returns a list of items. The unconscious benefit of this I believe is huge. My suggestion is to have namedItem always return either null or 1 object. And have namedItem*s* always return a collection. We can debate whether it is better to return null or an empty collection. I prefer the latter myself. Then I can always feed it to an iterator. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmlcollection-0 [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmlallcollection-0 Perry, But no one actually invokes namedItem()--they just use a regular property access expression on an HTMLAllCollection. namedItem() is left over from the strange days when the W3C was specifying Java APIs for working with XML instead of JavaScript APIs for HTML! Hmm. I was wondering. The pop up boxes on the side did not have any icons in them so I thought no one had implemented them. Can you give me an example of regular property access expression on an HTMLAllCollection ? I can't figure out what you are referring to. Thanks, Perry Perry, I think the only HTMLAllCollection is the deprecated document.all. By regular property access expression, I mean something like: document.all.foo or document.all[foo] instead of: document.all.namedItem(foo) I'm confused by the spec at this point. The title for section 13 is obsolete features but then 13.3 is Requirements and indeed 13.3.4 has features not yet implemented but considered deprecated by David (who I assume knows what he is talking about). I test a little bit in firefox and document.all doesn't work. So I look and see that Firefox is developing it. Is the HTMLAllCollection coming or going? Sorry for the confusion. Perry
Re: [whatwg] Forms feedback
On Tue, 06 Apr 2010 17:32:49 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson i...@hixie.ch wrote:
Well you currently can do this by using the onbeforeprint and
onafterprint
hooks, though that's not exactly pretty. Hopefully it will also be
possible with media-specific CSS, though that depends on how details
ends up working in CSS. If this proves to not be enough, we'll have to
add
something to support it; however, I'd like to wait until this is more
widely deployed (so we get more experience) before changing this.
I believe the CSS for details can be nothing more than:
details:not(open) :not(summary) {
display: none;
}
(Plus general default styling of details and summary, of course.)
That does not work well for text nodes. (Also, you meant [open], i.e.
including braces.)
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Forms feedback
On Tue, Apr 6, 2010 at 9:55 AM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 06 Apr 2010 17:32:49 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson i...@hixie.ch wrote:
Well you currently can do this by using the onbeforeprint and
onafterprint
hooks, though that's not exactly pretty. Hopefully it will also be
possible with media-specific CSS, though that depends on how details
ends up working in CSS. If this proves to not be enough, we'll have to
add
something to support it; however, I'd like to wait until this is more
widely deployed (so we get more experience) before changing this.
I believe the CSS for details can be nothing more than:
details:not(open) :not(summary) {
display: none;
}
(Plus general default styling of details and summary, of course.)
That does not work well for text nodes. (Also, you meant [open], i.e.
including braces.)
Indeed it doesn't, and indeed I did.
~TJ
Re: [whatwg] Will you consider about RFC 4329?
On Tue, 6 Apr 2010, James Kerr wrote: Ian Hickson i...@hixie.ch wrote: On Mon, 5 Apr 2010, Swampert wrote: In your HTML5 draft standard, the default value for type attribute in script element is text/javascript. While according to RFC 4329, the MIME type text/javascript is obsolete, the proper MIME type for JavaScript is application/javascript or application/ecmascript. The type everyone uses is text/javascript. What's the point of using application/javascript? What problem does it solve? I believe this has to do with character encoding issues and is the same reason that application/xml is preferred over text/xml. MIME types in the text/* set apparently have a default encoding of US-ASCII which I can imagine may throw up conflicts in some situations given that the primary and generally accepted encoding for XML and HTML documents (and increasingly other applications in general) is Unicode based. On Tue, 6 Apr 2010, Anne van Kesteren wrote: In theory this is correct. In practice nobody follows this outdated default encoding requirement. What Anne said. In practice, text/* doesn't default to anything, it works just like application/* -- it's different for each subtype. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Will you consider about RFC 4329?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Apologies, I've just noticed that I accidentally sent a couple of further posts directly to Anne instead of to the mailing list. I include them and Anne's response here for the benefit of the list discussion... - On Tue, 06 Apr 2010 12:40:48 +0200, James Kerr lo...@l0x.in wrote: Perusing the script element spec (the last I knew, HTML5 had negated the type attribute entirely), I'm left wondering... Why does there have to be a default type at all? Isn't that the purpose of the HTTP content-type header of the file referenced in the src attribute? (The same applies for the object element - it can have a type attribute, but doesn't need one) I don't see the point, unless it's purely there as meta-data, in which case a default is unnecessary...? Euhm, inline scripts? As a side note, the uptake of application/javascript will likely increase from this point onwards, as the recently released IE9 preview supports its use where previous versions did not (the biggest sticking point of adoption as far as I know). Taking this into consideration, and the fact that ∙ it will be the first version of that browser with HTML5 features ∙ application/javascript is the official MIME type (however little difference it actually makes in reality) would suggest no real reason not to go with it? Authoring material, author mindset, backwards compatibility, etc? RFCs can be fixed. - -- Anne van Kesteren http://annevankesteren.nl/ - On Tue, 06 Apr 2010 14:28:48 +0200, James Kerr lo...@l0x.in wrote: Anne van Kesteren wrote: Euhm, inline scripts? OK, but what I was getting at was also : doesn't each browser only support one scripting language? JScript on IE and Javascript on the others. Meaning there is no actual choice to be made and each browser will interpret the contents of a script with the language it supports... Not if the type attribute specifies something we do not support, but I agree that the default can be any type that matches JavaScript in theory as it is not exposed. - -- Anne van Kesteren http://annevankesteren.nl/ - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREIAAYFAku7bSgACgkQA5dpS+2BZayhlQEAgzPWWdRG57ovLP8h/KWIh6ca TZiImBSzvvt0wAXZb+gA/RjO3FrG7QkdBCsdLX+POskYlC7EZTMiNQFyVDtK4G22 =zzEp -END PGP SIGNATURE-
Re: [whatwg] HTMLCollection and HTMLAllCollection suggestion
On 4/6/10 12:17 PM, Perry Smith wrote: I'm confused by the spec at this point. The title for section 13 is obsolete features but then 13.3 is Requirements Right. Just because a feature is obsolete doesn't mean that UAs aren't required to implement it in a particular way. I test a little bit in firefox and document.all doesn't work. Sure it does: data:text/html,bodyscriptalert(document.all.length);/script Or were you testing in standards mode or something? Is the HTMLAllCollection coming or going? Neither. It's here; no one is planning to add new features to it, web pages are discouraged from using it. -Boris
Re: [whatwg] HTMLCollection and HTMLAllCollection suggestion
On Apr 6, 2010, at 12:24 PM, Boris Zbarsky wrote: On 4/6/10 12:17 PM, Perry Smith wrote: I'm confused by the spec at this point. The title for section 13 is obsolete features but then 13.3 is Requirements Right. Just because a feature is obsolete doesn't mean that UAs aren't required to implement it in a particular way. I test a little bit in firefox and document.all doesn't work. Sure it does: data:text/html,bodyscriptalert(document.all.length);/script Or were you testing in standards mode or something? Gack! probably. document.compatMode returns CSS1Compat so I'm in no- quirks-mode which is probably what you mean by standards mode. I'm then using Firebug to poke at things interactively from the console. Is the HTMLAllCollection coming or going? Neither. It's here; no one is planning to add new features to it, web pages are discouraged from using it. Ok... sorry if I've wasted peoples time. Perry
Re: [whatwg] HTMLCollection and HTMLAllCollection suggestion
On 4/6/10 1:37 PM, Perry Smith wrote: Gack! probably. document.compatMode returns CSS1Compat so I'm in no-quirks-mode which is probably what you mean by standards mode. Yep. -Boris
Re: [whatwg] Forms feedback
On Tue, Apr 6, 2010 at 8:32 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson i...@hixie.ch wrote:
Well you currently can do this by using the onbeforeprint and onafterprint
hooks, though that's not exactly pretty. Hopefully it will also be
possible with media-specific CSS, though that depends on how details
ends up working in CSS. If this proves to not be enough, we'll have to add
something to support it; however, I'd like to wait until this is more
widely deployed (so we get more experience) before changing this.
I believe the CSS for details can be nothing more than:
details:not(open) :not(summary) {
display: none;
}
This doesn't hide text nodes that are direct children of details. For example:
details
summarySummary goes here/summary
Details that should be hidden are here
/details
/ Jonas
Re: [whatwg] Directory upload via input type=file directory
What about drag-drop? I should be able to drag a directory, a file, or a list of files onto an input, no? If not, how is this distinction shown to users? How will it be clear to users when they can do one or the other? Ojan On Thu, Apr 1, 2010 at 3:53 PM, John Gregg john...@google.com wrote: For context, Ian Fette started a thread about uploading directories of files in December: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024455.html At that time, it was thought that directory upload could be implemented by a UA in response to a input type=file multiple tag using different UI only, and modifying the FileAPI spec to allow path information in the form input.files[0].name=1.jpg input.files[0].path=a input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c I've started developing a prototype of this in WebKit/Chromium. Based on what I've encountered so far, I would like to propose adding directory upload functionality using an explicit new 'directory' attribute on the file input element. The existing behavior of input type=file multiple would not change, but when processing input type=file directory, the UA would display a directory selection UI and store the path information, and *not* allow individual files to be selected. It would allow multiple files to have the same leaf name (.name attribute), as long as the paths were different. The path attributes would include the name of the chosen directory This would be preferable for several reasons: - Most built-in file system UI on major platforms (Windows/Mac/Linux) have distinct dialogs for choosing files and choosing directories. Allowing the UA to use these directly makes sense rather than creating hybrids. - Avoiding leaf name conflicts in a directory tree is not feasible in many applications -- asking a user to ensure unique photo names in a large set of albums before uploading would fail to meet that use case. Therefore HTML documents should know in advance whether the path information will be relevant in the eventual storage of the files. Sites currently using input type=file multiple would have compatibility problems with an implementation which allowed conflicting file names along different paths. What are your thoughts about adding the 'directory' attribute? Thanks, -John
Re: [whatwg] Directory upload via input type=file directory
That's a fair question, but how is it clear today whether an input can accept multiple files vs. a single file using drag-and-drop? Currently if I drag multiple files onto an input that doesn't have 'multiple', I get only the first one. (In Chrome.) Some good default text from the UA, like Choose folder... instead of Choose file..., would go far to solve that, I think. -John On Tue, Apr 6, 2010 at 12:38 PM, Ojan Vafai o...@chromium.org wrote: What about drag-drop? I should be able to drag a directory, a file, or a list of files onto an input, no? If not, how is this distinction shown to users? How will it be clear to users when they can do one or the other? Ojan On Thu, Apr 1, 2010 at 3:53 PM, John Gregg john...@google.com wrote: For context, Ian Fette started a thread about uploading directories of files in December: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024455.html At that time, it was thought that directory upload could be implemented by a UA in response to a input type=file multiple tag using different UI only, and modifying the FileAPI spec to allow path information in the form input.files[0].name=1.jpg input.files[0].path=a input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c I've started developing a prototype of this in WebKit/Chromium. Based on what I've encountered so far, I would like to propose adding directory upload functionality using an explicit new 'directory' attribute on the file input element. The existing behavior of input type=file multiple would not change, but when processing input type=file directory, the UA would display a directory selection UI and store the path information, and *not* allow individual files to be selected. It would allow multiple files to have the same leaf name (.name attribute), as long as the paths were different. The path attributes would include the name of the chosen directory This would be preferable for several reasons: - Most built-in file system UI on major platforms (Windows/Mac/Linux) have distinct dialogs for choosing files and choosing directories. Allowing the UA to use these directly makes sense rather than creating hybrids. - Avoiding leaf name conflicts in a directory tree is not feasible in many applications -- asking a user to ensure unique photo names in a large set of albums before uploading would fail to meet that use case. Therefore HTML documents should know in advance whether the path information will be relevant in the eventual storage of the files. Sites currently using input type=file multiple would have compatibility problems with an implementation which allowed conflicting file names along different paths. What are your thoughts about adding the 'directory' attribute? Thanks, -John
Re: [whatwg] Directory upload via input type=file directory
In cases where we're having users upload content, we definitely wouldn't want to block them uploading individual files, while also allowing them to upload directories. I would be tempted to make name the fully qualified path to the file (so it remains unique), and add a third filename attribute that is the name of the file in the directory for applications that need it? On Thu, Apr 1, 2010 at 3:53 PM, John Gregg john...@google.com wrote: For context, Ian Fette started a thread about uploading directories of files in December: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024455.html At that time, it was thought that directory upload could be implemented by a UA in response to a input type=file multiple tag using different UI only, and modifying the FileAPI spec to allow path information in the form input.files[0].name=1.jpg input.files[0].path=a input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c I've started developing a prototype of this in WebKit/Chromium. Based on what I've encountered so far, I would like to propose adding directory upload functionality using an explicit new 'directory' attribute on the file input element. The existing behavior of input type=file multiple would not change, but when processing input type=file directory, the UA would display a directory selection UI and store the path information, and not allow individual files to be selected. It would allow multiple files to have the same leaf name (.name attribute), as long as the paths were different. The path attributes would include the name of the chosen directory This would be preferable for several reasons: - Most built-in file system UI on major platforms (Windows/Mac/Linux) have distinct dialogs for choosing files and choosing directories. Allowing the UA to use these directly makes sense rather than creating hybrids. - Avoiding leaf name conflicts in a directory tree is not feasible in many applications -- asking a user to ensure unique photo names in a large set of albums before uploading would fail to meet that use case. Therefore HTML documents should know in advance whether the path information will be relevant in the eventual storage of the files. Sites currently using input type=file multiple would have compatibility problems with an implementation which allowed conflicting file names along different paths. What are your thoughts about adding the 'directory' attribute? Thanks, -John
[whatwg] Changing punctuation value of input element in telephone state
Hi, For input element in telephone state [1] specs say User agents may change the punctuation of values that the user enters. I do not really get it. What is the idea ? [1] http://dev.w3.org/html5/spec/forms.html#telephone-state Thanks, -- Mounir
Re: [whatwg] Directory upload via input type=file directory
It's unfortunate that users need to distinguish between single and multiple file inputs. That's not something we can change at this point. The web started with single file inputs. We can avoid adding a third type of file input they need to understand though. Also, what should happen if you drag files and folders onto a multiple or directory input? Just drop the ones that are of the wrong type? I cannot imagine users making sense of that. It's not clear to me from your original email what issues you encountered during implementation that led to this proposal. Is it just the leaf name conflict issue? I agree that's a problem, but maybe there's a different solution to that? Ojan On Tue, Apr 6, 2010 at 12:53 PM, John Gregg john...@google.com wrote: That's a fair question, but how is it clear today whether an input can accept multiple files vs. a single file using drag-and-drop? Currently if I drag multiple files onto an input that doesn't have 'multiple', I get only the first one. (In Chrome.) Some good default text from the UA, like Choose folder... instead of Choose file..., would go far to solve that, I think. -John On Tue, Apr 6, 2010 at 12:38 PM, Ojan Vafai o...@chromium.org wrote: What about drag-drop? I should be able to drag a directory, a file, or a list of files onto an input, no? If not, how is this distinction shown to users? How will it be clear to users when they can do one or the other? Ojan On Thu, Apr 1, 2010 at 3:53 PM, John Gregg john...@google.com wrote: For context, Ian Fette started a thread about uploading directories of files in December: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024455.html At that time, it was thought that directory upload could be implemented by a UA in response to a input type=file multiple tag using different UI only, and modifying the FileAPI spec to allow path information in the form input.files[0].name=1.jpg input.files[0].path=a input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c I've started developing a prototype of this in WebKit/Chromium. Based on what I've encountered so far, I would like to propose adding directory upload functionality using an explicit new 'directory' attribute on the file input element. The existing behavior of input type=file multiple would not change, but when processing input type=file directory, the UA would display a directory selection UI and store the path information, and *not* allow individual files to be selected. It would allow multiple files to have the same leaf name (.name attribute), as long as the paths were different. The path attributes would include the name of the chosen directory This would be preferable for several reasons: - Most built-in file system UI on major platforms (Windows/Mac/Linux) have distinct dialogs for choosing files and choosing directories. Allowing the UA to use these directly makes sense rather than creating hybrids. - Avoiding leaf name conflicts in a directory tree is not feasible in many applications -- asking a user to ensure unique photo names in a large set of albums before uploading would fail to meet that use case. Therefore HTML documents should know in advance whether the path information will be relevant in the eventual storage of the files. Sites currently using input type=file multiple would have compatibility problems with an implementation which allowed conflicting file names along different paths. What are your thoughts about adding the 'directory' attribute? Thanks, -John
Re: [whatwg] Changing punctuation value of input element in telephone state
On Tue, 2010-04-06 at 23:12 +0200, Mounir Lamouri wrote: Hi, For input element in telephone state [1] specs say User agents may change the punctuation of values that the user enters. I do not really get it. What is the idea ? [1] http://dev.w3.org/html5/spec/forms.html#telephone-state Thanks, -- Mounir I would assume that to mean that if a user enters a number with hyphens to separate the different parts of the number (area code, state code, country code, etc) then the UA could strip those out or re-format the string? Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Directory upload via input type=file directory
The most relevant issue is that in Windows/Mac/Linux, there are no system dialogs that let the user select either a folder or a file. They each have separate choose a file and choose a folder dialogs. I think the logical reason for that is that when selecting a file, clicking a directory means to enter that directory and select from its files, not to choose that directory as the result of selection. Thus we would force UAs to reinvent file-picker interfaces in order to deal with an input element that allows both folders and files. -John On Tue, Apr 6, 2010 at 2:18 PM, Ojan Vafai o...@chromium.org wrote: It's unfortunate that users need to distinguish between single and multiple file inputs. That's not something we can change at this point. The web started with single file inputs. We can avoid adding a third type of file input they need to understand though. Also, what should happen if you drag files and folders onto a multiple or directory input? Just drop the ones that are of the wrong type? I cannot imagine users making sense of that. It's not clear to me from your original email what issues you encountered during implementation that led to this proposal. Is it just the leaf name conflict issue? I agree that's a problem, but maybe there's a different solution to that? Ojan On Tue, Apr 6, 2010 at 12:53 PM, John Gregg john...@google.com wrote: That's a fair question, but how is it clear today whether an input can accept multiple files vs. a single file using drag-and-drop? Currently if I drag multiple files onto an input that doesn't have 'multiple', I get only the first one. (In Chrome.) Some good default text from the UA, like Choose folder... instead of Choose file..., would go far to solve that, I think. -John On Tue, Apr 6, 2010 at 12:38 PM, Ojan Vafai o...@chromium.org wrote: What about drag-drop? I should be able to drag a directory, a file, or a list of files onto an input, no? If not, how is this distinction shown to users? How will it be clear to users when they can do one or the other? Ojan On Thu, Apr 1, 2010 at 3:53 PM, John Gregg john...@google.com wrote: For context, Ian Fette started a thread about uploading directories of files in December: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024455.html At that time, it was thought that directory upload could be implemented by a UA in response to a input type=file multiple tag using different UI only, and modifying the FileAPI spec to allow path information in the form input.files[0].name=1.jpg input.files[0].path=a input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c I've started developing a prototype of this in WebKit/Chromium. Based on what I've encountered so far, I would like to propose adding directory upload functionality using an explicit new 'directory' attribute on the file input element. The existing behavior of input type=file multiple would not change, but when processing input type=file directory, the UA would display a directory selection UI and store the path information, and *not* allow individual files to be selected. It would allow multiple files to have the same leaf name (.name attribute), as long as the paths were different. The path attributes would include the name of the chosen directory This would be preferable for several reasons: - Most built-in file system UI on major platforms (Windows/Mac/Linux) have distinct dialogs for choosing files and choosing directories. Allowing the UA to use these directly makes sense rather than creating hybrids. - Avoiding leaf name conflicts in a directory tree is not feasible in many applications -- asking a user to ensure unique photo names in a large set of albums before uploading would fail to meet that use case. Therefore HTML documents should know in advance whether the path information will be relevant in the eventual storage of the files. Sites currently using input type=file multiple would have compatibility problems with an implementation which allowed conflicting file names along different paths. What are your thoughts about adding the 'directory' attribute? Thanks, -John
Re: [whatwg] Directory upload via input type=file directory
On Tue, 2010-04-06 at 14:28 -0700, John Gregg wrote: The most relevant issue is that in Windows/Mac/Linux, there are no system dialogs that let the user select either a folder or a file. They each have separate choose a file and choose a folder dialogs. I think the logical reason for that is that when selecting a file, clicking a directory means to enter that directory and select from its files, not to choose that directory as the result of selection. Thus we would force UAs to reinvent file-picker interfaces in order to deal with an input element that allows both folders and files. -John On Tue, Apr 6, 2010 at 2:18 PM, Ojan Vafai o...@chromium.org wrote: It's unfortunate that users need to distinguish between single and multiple file inputs. That's not something we can change at this point. The web started with single file inputs. We can avoid adding a third type of file input they need to understand though. Also, what should happen if you drag files and folders onto a multiple or directory input? Just drop the ones that are of the wrong type? I cannot imagine users making sense of that. It's not clear to me from your original email what issues you encountered during implementation that led to this proposal. Is it just the leaf name conflict issue? I agree that's a problem, but maybe there's a different solution to that? Ojan On Tue, Apr 6, 2010 at 12:53 PM, John Gregg john...@google.com wrote: That's a fair question, but how is it clear today whether an input can accept multiple files vs. a single file using drag-and-drop? Currently if I drag multiple files onto an input that doesn't have 'multiple', I get only the first one. (In Chrome.) Some good default text from the UA, like Choose folder... instead of Choose file..., would go far to solve that, I think. -John On Tue, Apr 6, 2010 at 12:38 PM, Ojan Vafai o...@chromium.org wrote: What about drag-drop? I should be able to drag a directory, a file, or a list of files onto an input, no? If not, how is this distinction shown to users? How will it be clear to users when they can do one or the other? Ojan On Thu, Apr 1, 2010 at 3:53 PM, John Gregg john...@google.com wrote: For context, Ian Fette started a thread about uploading directories of files in December: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024455.html At that time, it was thought that directory upload could be implemented by a UA in response to a input type=file multiple tag using different UI only, and modifying the FileAPI spec to allow path information in the form input.files[0].name=1.jpg input.files[0].path=a input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c I've started developing a prototype of this in WebKit/Chromium. Based on what I've encountered so far, I would like to propose adding directory upload functionality using an explicit new 'directory' attribute on the file input element.
Re: [whatwg] Changing punctuation value of input element in telephone state
On Tue, 6 Apr 2010, Mounir Lamouri wrote: For input element in telephone state [1] specs say User agents may change the punctuation of values that the user enters. I do not really get it. What is the idea ? For example, if I enter 1 650 253-, the user agent is allowed to change that to +1 (650) 253 or 1650253 or +1 (650) 253-. This is because such reformatting is common practice in telephone number entry fields. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing punctuation value of input element in telephone state
On 04/07/2010 12:37 AM, Ian Hickson wrote: On Tue, 6 Apr 2010, Mounir Lamouri wrote: For input element in telephone state [1] specs say User agents may change the punctuation of values that the user enters. I do not really get it. What is the idea ? For example, if I enter 1 650 253-, the user agent is allowed to change that to +1 (650) 253 or 1650253 or +1 (650) 253-. This is because such reformatting is common practice in telephone number entry fields. I understand this is common but as the UA is allowed to behave a certain way, it is going to be really hard for the webpages to check the telephone numbers validity. With the example you gave, for one entry, three different values have been generated. In my opinion, this is the contrary of the spirit of no type-mismatch constraint validation. -- Mounir
Re: [whatwg] Changing punctuation value of input element in telephone state
On Wed, 7 Apr 2010, Mounir Lamouri wrote: On 04/07/2010 12:37 AM, Ian Hickson wrote: On Tue, 6 Apr 2010, Mounir Lamouri wrote: For input element in telephone state [1] specs say User agents may change the punctuation of values that the user enters. I do not really get it. What is the idea ? For example, if I enter 1 650 253-, the user agent is allowed to change that to +1 (650) 253 or 1650253 or +1 (650) 253-. This is because such reformatting is common practice in telephone number entry fields. I understand this is common but as the UA is allowed to behave a certain way, it is going to be really hard for the webpages to check the telephone numbers validity. With the example you gave, for one entry, three different values have been generated. In my opinion, this is the contrary of the spirit of no type-mismatch constraint validation. Well the alternative is to not have the user agent change the value at all, in which case you still have to do server-side canonicalisation, so I don't think it really makes any difference. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing punctuation value of input element in telephone state
On 04/07/2010 12:55 AM, Ian Hickson wrote: On Wed, 7 Apr 2010, Mounir Lamouri wrote: On 04/07/2010 12:37 AM, Ian Hickson wrote: On Tue, 6 Apr 2010, Mounir Lamouri wrote: For input element in telephone state [1] specs say User agents may change the punctuation of values that the user enters. I do not really get it. What is the idea ? For example, if I enter 1 650 253-, the user agent is allowed to change that to +1 (650) 253 or 1650253 or +1 (650) 253-. This is because such reformatting is common practice in telephone number entry fields. I understand this is common but as the UA is allowed to behave a certain way, it is going to be really hard for the webpages to check the telephone numbers validity. With the example you gave, for one entry, three different values have been generated. In my opinion, this is the contrary of the spirit of no type-mismatch constraint validation. Well the alternative is to not have the user agent change the value at all, in which case you still have to do server-side canonicalisation, so I don't think it really makes any difference. If the UA is not changing the value, we are sure at least webpage authors can easily specify how they want the telephone number to be formatted and check it with pattern attribute (or use setCustomValidity()). I've opened bug 9439 about this issue. -- Mounir
Re: [whatwg] Changing punctuation value of input element in telephone state
Hello fellas, I agree with Mounir. Thing is UA is allowed to do that, but without clear rules, this can be a mess. If for date and time, where we have a lot of formats and standards for internationalization, how can UA specify and be no type mismatch, if we do not have any standard about phone numbers? I mean, american format differs a lot from brazilian, which differs a lot from indian, which differs from... you got it. But it would be great if this kind of data becomes part of i18n packages, meaning that any user, with a UA tunned to its native language can input that, and let it do the job, like for date and time. However, not like date, which is a fixed number, phones can vary a lot from one region to region in length, and prefixes. I think this is open to UA devs and RFC writers to take care, but I am not sure if these statements will be useful someday at all due this lack of pattern among regions. -- Hugs, Davis.
Re: [whatwg] Changing punctuation value of input element in telephone state
On Wed, 7 Apr 2010, Mounir Lamouri wrote: Well the alternative is to not have the user agent change the value at all, in which case you still have to do server-side canonicalisation, so I don't think it really makes any difference. If the UA is not changing the value, we are sure at least webpage authors can easily specify how they want the telephone number to be formatted and check it with pattern attribute (or use setCustomValidity()). If the author is doing the formatting, it's really not much better than a type=text field. The reason to have type=tel is to allow the UA to do that part of the work. I've opened bug 9439 about this issue. Right-o. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing punctuation value of input element in telephone state
On Tue, 6 Apr 2010, Davis Peixoto wrote: Thing is UA is allowed to do that, but without clear rules, this can be a mess. If for date and time, where we have a lot of formats and standards for internationalization, how can UA specify and be no type mismatch, if we do not have any standard about phone numbers? I mean, american format differs a lot from brazilian, which differs a lot from indian, which differs from... you got it. But it would be great if this kind of data becomes part of i18n packages, meaning that any user, with a UA tunned to its native language can input that, and let it do the job, like for date and time. However, not like date, which is a fixed number, phones can vary a lot from one region to region in length, and prefixes. I think this is open to UA devs and RFC writers to take care, but I am not sure if these statements will be useful someday at all due this lack of pattern among regions. If there was a true standard, then the spec would refer to that, but as you say, it's very varied in practice. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing punctuation value of input element in telephone state
On 04/07/2010 01:08 AM, Ian Hickson wrote: On Wed, 7 Apr 2010, Mounir Lamouri wrote: Well the alternative is to not have the user agent change the value at all, in which case you still have to do server-side canonicalisation, so I don't think it really makes any difference. If the UA is not changing the value, we are sure at least webpage authors can easily specify how they want the telephone number to be formatted and check it with pattern attribute (or use setCustomValidity()). If the author is doing the formatting, it's really not much better than a type=text field. The reason to have type=tel is to allow the UA to do that part of the work. As Davis said, there are too many phone numbers format out there so we can't let the UA do a formatting because it will be a bad one in most of the cases. For example, in France, we use 2-digit blocks but in the US people write 3-digit or 4-digit blocks. Maybe the telephone type can be like the search one and be here only for styling ? -- Mounir
Re: [whatwg] Changing punctuation value of input element in telephone state
On Tue, Apr 6, 2010 at 4:13 PM, Mounir Lamouri mounir.lamo...@gmail.com wrote: As Davis said, there are too many phone numbers format out there so we can't let the UA do a formatting because it will be a bad one in most of the cases. For example, in France, we use 2-digit blocks but in the US people write 3-digit or 4-digit blocks. Maybe the telephone type can be like the search one and be here only for styling ? Mobile phones seem to get by ok with restyling the phone numbers you type into them. If you want to emulate that in your app (or conversely, if you want to create a phone UI in HTML5), you'll need the freedom to restyle the phone number in that way. Of course, I'm from the US, and don't know if someone from another country is annoyed at all the US-centric phone-number formatting their phone is automatically doing. ~TJ
Re: [whatwg] Changing punctuation value of input element in telephone state
On 04/07/2010 01:18 AM, Tab Atkins Jr. wrote: On Tue, Apr 6, 2010 at 4:13 PM, Mounir Lamouri mounir.lamo...@gmail.com wrote: As Davis said, there are too many phone numbers format out there so we can't let the UA do a formatting because it will be a bad one in most of the cases. For example, in France, we use 2-digit blocks but in the US people write 3-digit or 4-digit blocks. Maybe the telephone type can be like the search one and be here only for styling ? Mobile phones seem to get by ok with restyling the phone numbers you type into them. If you want to emulate that in your app (or conversely, if you want to create a phone UI in HTML5), you'll need the freedom to restyle the phone number in that way. Of course, I'm from the US, and don't know if someone from another country is annoyed at all the US-centric phone-number formatting their phone is automatically doing. When I was using MacOS X, I hated how the contact application was restyling my phone numbers. By the way, it lets me think about something: the telephone state can still be used for autocomplete with phones from contacts. -- Mounir
Re: [whatwg] Changing punctuation value of input element in telephone state
On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson i...@hixie.ch wrote: If there was a true standard, then the spec would refer to that, but as you say, it's very varied in practice. There is quite a standard, even if an implicit one: (almost) no punctuation. Have you ever dialed a ( or a - when phoning someone? In essence, phone numbers are sequences of digits, and punctuation is only used as a convenience to enhance readability. There are two exceptions to this: + and letters are used as replacement for numbers (the plus sign for the international call code, the letters for specific digits to enable creating branded numbers easier to memorize). Maybe I'm being too hasty with this idea but, since machines don't really need the same readability aids as humans do, I'd suggest that the UA simply removes everything other than + and alphanumeric characters (and obviously adds nothing) when sending the field. I don't care too much about what they do upon rendering the introduced value (and I think it's probably fine if the browser adds some formatting based on its own or the system's regional settings). The server is only left with replacing letters and +; plus any application-specific usage of the value itself (which, by then, will be a string of digits; assumedly representing the sequence of digits to dial). Other than that, the only safe alternative would be to leave the values untouched, so the page can say what it wants, the user honor it, and the server get it as expected; or gracefully degrade to an error message that actually points to the user error (rather than an error introduced by an UA trying to be out-smart the user). For sites that are ready to sanitize values from a specific locale; but which are accessed through an UA with different settings (ie: on a public place while abroad), the UA adding locale-specific stuff to a phone value is very likely to render whole forms unusables. Regards, Eduard Pascual
Re: [whatwg] Changing punctuation value of input element in telephone state
When I was using MacOS X, I hated how the contact application was restyling my phone numbers. By the way, it lets me think about something: the telephone state can still be used for autocomplete with phones from contacts. -- Mounir Good one, Mounir. Tab, this does not means only formatting, but the input length will differ too much. Uruguay for example, has only 6 digits number, 8 with international leading code. Brazil has 9 or 10, depending on the region, plus 2 with international leading code. That's the point. But as I said, when we have some standard for it (I doubt of this, but let's suppose it), we can put this inside locales configuration. This is a nice idea. Anyway, backend programmer will still need to sanitize this input somehow. Yeah, I do not see much light for this matter. -- Hugs, Davis.
Re: [whatwg] Changing punctuation value of input element in telephone state
On Wed, 2010-04-07 at 01:28 +0200, Eduard Pascual wrote: On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson i...@hixie.ch wrote: If there was a true standard, then the spec would refer to that, but as you say, it's very varied in practice. There is quite a standard, even if an implicit one: (almost) no punctuation. Have you ever dialed a ( or a - when phoning someone? In essence, phone numbers are sequences of digits, and punctuation is only used as a convenience to enhance readability. There are two exceptions to this: + and letters are used as replacement for numbers (the plus sign for the international call code, the letters for specific digits to enable creating branded numbers easier to memorize). Maybe I'm being too hasty with this idea but, since machines don't really need the same readability aids as humans do, I'd suggest that the UA simply removes everything other than + and alphanumeric characters (and obviously adds nothing) when sending the field. I don't care too much about what they do upon rendering the introduced value (and I think it's probably fine if the browser adds some formatting based on its own or the system's regional settings). The server is only left with replacing letters and +; plus any application-specific usage of the value itself (which, by then, will be a string of digits; assumedly representing the sequence of digits to dial). Other than that, the only safe alternative would be to leave the values untouched, so the page can say what it wants, the user honor it, and the server get it as expected; or gracefully degrade to an error message that actually points to the user error (rather than an error introduced by an UA trying to be out-smart the user). For sites that are ready to sanitize values from a specific locale; but which are accessed through an UA with different settings (ie: on a public place while abroad), the UA adding locale-specific stuff to a phone value is very likely to render whole forms unusables. Regards, Eduard Pascual Phone numbers can also validly include pause characters too. I remember back in the day saving such a number to quickly dial into my voicemail, rather than having to dial in, wait for the automated voice, press a digit, wait for some more robot speaking, press another number, etc. Also, not entirely sure, but would asterisks (*) and hashes (#) be included too? I was just going on what digits exist on a standard phone keypad. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Changing punctuation value of input element in telephone state
Other than that, the only safe alternative would be to leave the values untouched, so the page can say what it wants, the user honor it, and the server get it as expected; or gracefully degrade to an error message that actually points to the user error (rather than an error introduced by an UA trying to be out-smart the user). This goes in the opposite direction from the initial idea of creating a interface that intend to avoid type mismatches, unfortunately. For sites that are ready to sanitize values from a specific locale; but which are accessed through an UA with different settings (ie: on a public place while abroad), the UA adding locale-specific stuff to a phone value is very likely to render whole forms unusables. I just mentioned another drawback. -- Hugs, Davis.
Re: [whatwg] Changing punctuation value of input element in telephone state
0-9, *, #, p, w http://www.wikihow.com/Add-Pauses-to-a-Phone-Number recognizing the difference between a 'P' and a 'p' (or a 'W' and a 'w') is moderately painful.
Re: [whatwg] using postMessage() to send to a newly-created window
Sorry for the delay in replying ... On Thu, Mar 25, 2010 at 1:31 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 21 Dec 2009, Dirk Pranke wrote: In the course of testing something today, I attempted to create a window and immediately post a message to it, and was surprised that it didn't seem to work. E.g.: var w = window.open(http://x;); w.postMessage(hello, world, *); w never got the message - this seemed to be consistent across Safari, Chrome, and FF (all I had installed on my Mac at the time, so apologies to Opera, IE, and anyone else I've left out). It got the message, it just got it when the window's document was about:blank and before the scripts in that window were ready to receive any messages. Is this supposed to work? If not, is there a reliable way for the the source to know when it is safe to send a message to the target? If it's same-origin, the simplest solution is to wait for onload. If it's cross-origin, there is by design no mechanism to expose when the page is ready short of the other site announcing it (by sending a message to its opener, in this case). If this isn't supposed to work, can we state this explicitly in the spec? Where would you like it mentioned and what would you like it to say? How about putting some text at the end of Section 9.2.3, Posting Messages that says something like: Note that messages are not guaranteed to be delivered reliably under all circumstances. User agents are allowed to not deliver messages if the details of their implementation may make this difficult or impossible to do safely and securely. For example, if a new child window is created and then a message is immediately posted to it, that message may not get delivered, even if the child window belongs to the same origin. A rationale for this may me that it would require the user agent to queue the message across creation of a new event loop, leading to all sorts of unpredictable timing issues. I'm not particularly happy with the wording here, but it gets the point across. Of course, putting in text like this would naturally lead the reader to wonder under what conditions messages *are* guaranteed to be delivered reliably. Which is, I think, a valid question I don't know the answer to. Is it safe to say that messages are delivered reliably if the destination window belongs to the specified targetOrigin and the destination window is fully loaded? What if a navigation event is triggered on the destination window? -- Dirk
Re: [whatwg] Changing punctuation value of input element in telephone state
On Wed, Apr 7, 2010 at 1:31 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Wed, 2010-04-07 at 01:28 +0200, Eduard Pascual wrote: On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson i...@hixie.ch wrote: If there was a true standard, then the spec would refer to that, but as you say, it's very varied in practice. There is quite a standard, even if an implicit one: (almost) no punctuation. Have you ever dialed a ( or a - when phoning someone? In essence, phone numbers are sequences of digits, and punctuation is only used as a convenience to enhance readability. There are two exceptions to this: + and letters are used as replacement for numbers (the plus sign for the international call code, the letters for specific digits to enable creating branded numbers easier to memorize). Maybe I'm being too hasty with this idea but, since machines don't really need the same readability aids as humans do, I'd suggest that the UA simply removes everything other than + and alphanumeric characters (and obviously adds nothing) when sending the field. I don't care too much about what they do upon rendering the introduced value (and I think it's probably fine if the browser adds some formatting based on its own or the system's regional settings). The server is only left with replacing letters and +; plus any application-specific usage of the value itself (which, by then, will be a string of digits; assumedly representing the sequence of digits to dial). Other than that, the only safe alternative would be to leave the values untouched, so the page can say what it wants, the user honor it, and the server get it as expected; or gracefully degrade to an error message that actually points to the user error (rather than an error introduced by an UA trying to be out-smart the user). For sites that are ready to sanitize values from a specific locale; but which are accessed through an UA with different settings (ie: on a public place while abroad), the UA adding locale-specific stuff to a phone value is very likely to render whole forms unusables. Regards, Eduard Pascual Phone numbers can also validly include pause characters too. I remember back in the day saving such a number to quickly dial into my voicemail, rather than having to dial in, wait for the automated voice, press a digit, wait for some more robot speaking, press another number, etc. Also, not entirely sure, but would asterisks (*) and hashes (#) be included too? I was just going on what digits exist on a standard phone keypad. So it seems that I was indeed too hasty with my proposal. Let me put aside the specifics and focus on the idea: - Issue: there is no explicit standard to represent phone numbers that works on a world-wide scale. - Fact: there is an implicit standard that defines what a phone does (where does it call) depending on which sequence of keys is pressed. - Idea: given the need for a standard, and the lack of an explicit one, use the implicit one that can actually work. I was hasty and provided an incomplete definition of that implicit standard; but I'm quite convinced a correct definition can be produced with a bit of research and effort. On Wed, Apr 7, 2010 at 1:48 AM, Davis Peixoto davis.peix...@gmail.com wrote: Other than that, the only safe alternative would be to leave the values untouched, so the page can say what it wants, the user honor it, and the server get it as expected; or gracefully degrade to an error message that actually points to the user error (rather than an error introduced by an UA trying to be out-smart the user). This goes in the opposite direction from the initial idea of creating a interface that intend to avoid type mismatches, unfortunately. Actually, it doesn't. It just goes nowhere from the starting point (pre-HTML5, phones are inputed as raw text, which provides no phone-specific interface). Current HTML5 approach, however, does go in that opposite direction, since allowing UAs to add whatever they wish is nowhere near to avoid the mismatches, and it's even guaranteed to trigger them when the UA fails to second-guess what the page expects. The most obvious scenario I could come up with is that of a user using a foreign computer (I quite know what I'm speaking about here, I have struggled so many times with Irish keyboards to get a 'ñ' through ^^' ); for example: the user may be attempting to input a Spaniard number in a Spaniard site, and the UA might be trying to enforce Irish phone-number conventions: this may break even if the site itself is up for the battle and attempts to remove all the extraneous characters, since it could quite make sense to prepend a '0' to an Irish number (not very advisable for an UA to do that, but possible since it may be needed to dial an extra '0' on some situations). Also, things will definitely break if the site expects Spaniard formatting (just some spaces, and perhaps a bracket pair) but the UA enforces a different
Re: [whatwg] Changing punctuation value of input element in telephone state
The goal of fool-proofing phone fields is a quite noble one but, let's be honest: it's quite near to an utopia. Any solution that may cause valid inputs to break is definitely bad. If fixing wrong inputs risks valid ones to break, we are not only not solving the problem, but we are moving it somewhere it doesn't make sense: if you had to choose between wrong inputs breaking or good inputs breaking, is there any sane reason to chose the later? This is what I was saying. It is noble, but utopic (Yeah, you put it better in words). But now I realized: UA handling of type=tel is just a possibility, not a mandatory feature. Thus, I think even it is documented in somewhere in HTML 5 spec, it won't be used/implemented at all due to all the drawbacks we were discussing about in this thread. -- Hugs, Davis
Re: [whatwg] Changing punctuation value of input element in telephone state
On 07/04/2010, at 9:21 AM, Mounir Lamouri wrote: When I was using MacOS X, I hated how the contact application was restyling my phone numbers. I'm surprised this was an issue; the Mac OS X Address Book contains a dedicated preferences screen to allow you to define custom formatting rules if they don't automatically behave as you'd like. In fact, my suggestion to the entire list was to fall back on the OS-native Address Book's settings for formatting phone numbers, since that is a setting that is certainly going to be the same for a given user between his or her address book and web browser. When it comes to applying formatting, the OS X Address Book (apparently) does it as follows: 1. Don't apply any format while the field has keyboard focus (least surprise) 2. When the field loses focus, the OS checks the number of digits in the input and compares that to the formats defined in the preferences. If no format is defined for that number of digits, don't change the input at all. 3. If (at least one) format exists for the number of digits entered, apply the format to the input In practice there are two things I feel the OS X Address Book does unexpectedly: 1. I would suggest that if the user enters his or her input including spaces and/or parentheses, those should be maintained (perhaps this is deliberate to allow the pasting/data detection of arbitrary formatted content into the field, but in practice it means I can't override a format for a single number) 2. If two formats are defined for the same number of digits, only the first is applied (in eastern Australia, there are two conventions for 10-digit phone numbers; landlines are defined as, for example, ## whereas mobiles are in the format ### ###). If I define each of those formats as custom formats, only the first in the list is applied for 10-digit numbers (even if I enter the number precisely following the other format). To work around that issue, I have to define the format as 04## ### ###, which works in Australia but might be too restrictive for some other cultures. Cheers, Kit Grose User Experience + Tech Director, iQmultimedia (02) 4260 7946 k...@iqmultimedia.com.au iqmultimedia.com.au
Re: [whatwg] some thoughts on sandboxed IFRAMEs
On Thu, 4 Feb 2010, Tab Atkins Jr. wrote: On Thu, Feb 4, 2010 at 5:12 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 25 Jan 2010, Tab Atkins Jr. wrote: Adam Barth rightfully points out that this only stops certain classes of data exfiltration attacks, and so probably isn't worthwhile as a solution to that matter. However, I think this would also be very useful for general comments, to prevent, for example, shock trolls from putting goatse images in your comment threads. It would also prevent video and audio embeds from working. However, it would still allow the site owner to allow particular files to be embedded with img, audio, or video, if they just host them on their own origin and set allow-same-origin in the sandbox flags. This is already a relatively normal practice, but it's accomplished through attempts at filtering. Note that this would also prevent resource embeds using data urls, as they have a unique origin. It seems like if you want to control what markup is shown, the way to do that is to to parse the input and remove the elements you want to block. Just blocking off-domain images is a pretty poor way of blocking images if that's what you want to do. Consider that the commentor could just use table and td bgcolor to embed an image if that's what he wants to do. Heh, if someone goes to the trouble of constructing a pixelmap out of a table, they deserve to have it up until I find it and delete it. Note as well that this sort of thing wouldn't be stopped by the suggested parse and sanitize method either, unless you just want to strip *all* tables. And pretty much all other HTML (using div/span with display:table-* would accomplish the same thing, or just putting explicit heights/widths on them to make the 'cells' line up.) Indeed. If you want to block any of these things, you're much better off doing real filtering rather than relying on coarse feature blocking or cross-site blocking in the sandboxing feature, IMHO. On many large sites, users can upload images to one part of the site -- those wouldn't be blocked either. That's the point - one wouldn't want those blocked (or if one did, one could indeed filter all images out). They can perhaps be more subject to moderation (submit the image, and have to wait for it to be approved before you can use it), or just be a built-in set of images that you're allowed to use, like the large sets of smilies that most forums have. This use case is seeming very obscure for a first version of the feature. Are there sites that try to do this today? Sorry, the title is unclear - I mainly intend this as preventing audio autoplay and the like. Any sort of action that could be both annoying and would take place without the user's consent. This is inherently ill-defined, which may be a problem, but it could be tightened up to say precisely which features should be shut down. It might need to be revised as new features get added, though. Yeah, maybe we should do this. Are there any other than autoplay, autofocus, meta refresh, and script? That's all I can think of from a quick scan of the list of elements. I've blocked those. Are there other reasonable improvements that could be made to iframe sandbox to make it more suitable for wrapping things such as blog comments? Ideally, production-level sites with relatively normal requirements should be able to use *solely* iframe sandbox to protect their users from untrusted content. (Though, of course, it would be only a part of the site's defenses until the userbase with non-supporting browsers drops low enough to ignore.) Do others believe this is an achievable goal, or conversely believe it is not? sandbox= is only meant as an extra defence-in-depth, it's really not meant as a self-contained comprehensive security mechanism. Eh, once we can rely on it being implemented, it seems like it *could* be a fairly self-contained security mechanism. At the very least, it could shut down the most worrying of attacks, and allow manual moderation to take care of the rest. Filling in a last few holes would finish this out. You're always going to need things like the text/html-sandboxed type, etc, as far as I can tell. Shelley Powers states that she disallows SVG in the comments on her blog because of the risk of someone DOSing her users by writing highly resource-intensive SVG. This could be fixed in a general sense by having the ability to opt into very strict resource limits per iframe - it the limit is exceeded, the browser would simply bail and end processing in that iframe. I'm not certain how practical this is from an engineering standpoint, however. There's no need to set precise limits on this - each browser should understand the platform it's running on well enough to know what an 'appropriate' resource
