[whatwg] Paragraphs in blockquotes
Hi We recently received an email from one of our readers on html5doctor.com that went like this: Hi, in HTML 4.0 Strict XHTML 1.0 Strict, text inside a blockquote element is required to be nested inside another block-level element, e.g. p. In HTML5 that requirement seems to have been relaxed, as the following element validates successfully: blockquoteThis is a blockquote./blockquote The HTML5 spec uses the p element in the usage examples, but does not mention whether it is required. Can you please confirm if this requirement has now been deprecated? We tested the below which successfully validated: !doctype html meta charset=utf-8 titleblockquote test/title blockquoteTiger tiger burning bright/blockquote So the question is, are block level elements required in blockquotes or can the p's be removed from the examples in the spec? Regards Rich -- Twitter: http://twitter.com/rich_clark http://html5doctor.com http://html5gallery.com
Re: [whatwg] Paragraphs in blockquotes
Hello. On Tue, May 11, 2010 at 5:06 PM, Richard Clark he...@richclarkdesign.com wrote: Hi We recently received an email from one of our readers on html5doctor.com that went like this: Hi, in HTML 4.0 Strict XHTML 1.0 Strict, text inside a blockquote element is required to be nested inside another block-level element, e.g. p. In HTML5 that requirement seems to have been relaxed, as the following element validates successfully: blockquoteThis is a blockquote./blockquote The HTML5 spec uses the p element in the usage examples, but does not mention whether it is required. Can you please confirm if this requirement has now been deprecated? We tested the below which successfully validated: !doctype html meta charset=utf-8 titleblockquote test/title blockquoteTiger tiger burning bright/blockquote So the question is, are block level elements required in blockquotes or can the p's be removed from the examples in the spec? Regards Rich -- Twitter: http://twitter.com/rich_clark http://html5doctor.com http://html5gallery.com blockquote can take any flow content, which is defined as: Most elements that are used in the body of documents and applications are categorized as flow content. a abbr address area (if it is a descendant of a map element) article aside audio b bdo blockquote br button canvas cite code command datalist del details dfn div dl em embed fieldset figure footer form h1 h2 h3 h4 h5 h6 header hgroup hr i iframe img input ins kbd keygen label link (if the itemprop attribute is present) map mark math menu meta (if the itemprop attribute is present) meter nav noscript object ol output p pre progress q ruby samp script section select small span strong style (if the scoped attribute is present) sub sup svg table textarea time ul var video wbr text http://www.whatwg.org/html5#flow-content So in HTML5 blockquote doesn't require inline contents to be nested inside another block elements (you may know but that was acceptable too in HTML4 Transitional). Regards, -- Masataka Yakura myakura@gmail.com
[whatwg] New File attributes creationDate, modificationDate and size
Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file There doesn't appear to be anyway of retrieving creation date, modification date or size of the file. Could I suggest adding attributes creationDate, modificationDate and size to provide this information? For a use case; we're working an a student coursework submission system, where they'll be able to drag and drop files. It would be useful to show the student details of the file they're uploading (for example, modification date is useful to confirm they're uploading the most recent version). We do actually see a fairly large number of mis-uploads with the existing upload system, and are hoping exposing more information during the upload (rather than once the file is received) will help.
Re: [whatwg] Paragraphs in blockquotes
On Tue, 11 May 2010 09:06:11 +0100 Richard Clark he...@richclarkdesign.com wrote: In HTML5 that requirement seems to have been relaxed, as the following element validates successfully: blockquoteThis is a blockquote./blockquote The HTML5 spec uses the p element in the usage examples, but does not mention whether it is required. Can you please confirm if this requirement has now been deprecated? The content model for blockquote is Flow content. Flow content includes text. So, the text as a child of blockquote is valid. The spec says that a run of phrasing content (in this case, it is the text.) is a paragraph. http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#paragraph So, the examples below have same semantics. blockquoteThis is a blockquote./blockquote blockquotepThis is a blockquote./p/blockquote The former is valid, but, of course, authers are encouraged the latter much more. Regards Futomi -- Futomi Hatano http://www.html5.jp/ http://www.futomi.com/ http://twitter.com/futomi
Re: [whatwg] Need document.available_fonts() call
Le 11/05/10 06:25, Ian Hickson a écrit : document.available_fonts() or document.local_font_list() will be very useful. Whether this would be useful or not I'm not sure, but in either case, that's a features for the CSSOM, not HTML. I recommend bringing this up on the CSS list (www-st...@w3.org). H. Probably not. It's really a system/OS API. I'm Cc:ing Robin Berjon here. Please note there's a rather strong privacy issue here. I don't want a web page to be able - without my prior consent - to query the list of fonts available in my system. /Daniel
[whatwg] Audio Panning - Bump
Hello, A Google search on the discussion list returns the unanswered question from Keith Bauer (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024340.html) below. I'm working on an application which has two separate channels of sound panned fully left and right in a stereo audio file. The application is for language learners and it would be very useful to set the audio pan position fully left or right to effectively mute one speaker. As the draft spec stands the only solution that presents itself is to split the stereo file into two and load two audio elements in the HTML. I haven't tried this yet but I suspect it will be a headache. Any chance of reviving panning? Keith Bauer onesadcookie at gmail.com Sat Dec 5 17:19:59 PST 2009 It looks in the current draft spec as if audio is not pannable, and from Googling it looks like this was at one point considered, but I can't find an explanation as to what happened between then and now. Obviously panning is problematic for stereo audio, but with Canvas and WebGL making browser games more possible, having the ability to pan at least mono audio seems like a worthwhile addition. Or is WebGL to be followed shortly by WebAL ;) -Keith [see also - http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/010231.html] -- Eoin Kilfeather Digital Media Centre Dublin Institute of Technology
Re: [whatwg] Need document.available_fonts() call
Please note there's a rather strong privacy issue here. I don't want a web page to be able - without my prior consent - to query the list of fonts available in my system. You already have this problem if a website were to create a list of elements with a list of different fonts and use Javascript to determine which font is being displayed. [1] I'm not advocating opening another hole just because one already exists - I'm just pointing this out. [1] http://www.lalit.org/lab/javascript-css-font-detect
Re: [whatwg] Need document.available_fonts() call
On Tue, 2010-05-11 at 12:32 +0300, Eitan Adler wrote: Please note there's a rather strong privacy issue here. I don't want a web page to be able - without my prior consent - to query the list of fonts available in my system. You already have this problem if a website were to create a list of elements with a list of different fonts and use Javascript to determine which font is being displayed. [1] I'm not advocating opening another hole just because one already exists - I'm just pointing this out. [1] http://www.lalit.org/lab/javascript-css-font-detect It's not as clear cut as you make it sound. That script works on the basis that the glyphs within a font have different widths compared to the same glyph of another font. What happens when two fonts have exactly the same dimensions for their glyphs? The script will register a false positive. As such, I don't think its a security flaw or anything to overly worry about. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Need document.available_fonts() call
Le 11/05/10 13:28, Ashley Sheridan a écrit : It's not as clear cut as you make it sound. That script works on the basis that the glyphs within a font have different widths compared to the same glyph of another font. What happens when two fonts have exactly the same dimensions for their glyphs? The script will register a false positive. As such, I don't think its a security flaw or anything to overly worry about. Another detection technique based on the computed style of the 'font-family' property would work much better. /Daniel
Re: [whatwg] Need document.available_fonts() call
On 5/11/10 7:47 AM, Daniel Glazman wrote: Another detection technique based on the computed style of the 'font-family' property would work much better. Uh... the computed value of font-family is just the specified value (CSS 2.1 section 15.3). So no, you can't detect _used_ font-family values based on the computed value in this case. -Boris
Re: [whatwg] Need document.available_fonts() call
On Tue, 2010-05-11 at 09:33 -0400, Boris Zbarsky wrote: On 5/11/10 7:47 AM, Daniel Glazman wrote: Another detection technique based on the computed style of the 'font-family' property would work much better. Uh... the computed value of font-family is just the specified value (CSS 2.1 section 15.3). So no, you can't detect _used_ font-family values based on the computed value in this case. -Boris Is there really much of a need for this though? CSS as it stands has support for a list of fonts to be specified for an element, and a browser can go through them until it finds one that is installed. The only argument I've seen is that various fonts are obviously different sizes, and so falling back to a different font might look best if the font-size also changed with it. However, I don't think it's such a great idea for fonts to be used as a layout tool. The layout should be fluid enough for minor font differences. This is not forgetting that the font a designer specifies for a page might be completely overridden by a user for a variety of reasons (larger fonts for someone with a visual disability, colour changes for someone with dyslexia, etc) Lastly, if a designer really needs to specify the exact font used on a page, then CSS3 has an area for embedded fonts (which are supported in various forms on the major browsers) Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] meta=encrypt tag is needed
Juuso Hukkanen wrote: Mikko Rantalainen wrote: Are you trying to suggest an user agent implementation of something similar to this: http://angel.net/~nic/passwdlet.html ? Thanks Mikko for linking to those passsalt generator tools. In truth, I was asking to figure out if that's what you're aiming for. If I've understood correctly, this is the feature that you think should be implemented. I'm afraid that such system would not be safe and would not give all the protection you're looking for. Basically if you have a function f(x) = sha256(domain + userpassword) in reality you just have a SHA256 of userpassword with a custom IV (initialization vector). A more secure hashing method would be along the lines f2(x) = sha256(sha256(userpassword) + domain) where the output of sha256 is hex in ascii and + is string concatenating operator. This would effectively prevent use of rainbow tables contrary to f(x) above. However, it wouldn't still be safe to use the same password for multiple sites because the attack could be implemented offline against the salted hash. If one has possession of database of salted hashes, figuring out a single password is roughly equivalent processing to figuring out (almost) all of the passwords. The complexity of processing is only dependent on the length and complexity of user's password (and if it's something in a dictionary, it's way too simple here). Notice that the salting method described and implemented in URL above is safe only if it's not too widely used, or if the master password is complex enough for offline brute force attack. As such, it's not suitable for common implementation in user agents. Notice that it does not matter if the hash algorithm is md5 or sha1 or whatever. The problem is that the user's master password is the only secret and that's almost always too weak secret for brute force offline attack. PASSSALT: ^^ Attributes: meta encrypt = Identification tag for html 5.01 content for 5.01 conforming UAs If something like this will be ever implemented, it should definitely be a form input specific attribute, not a single meta element for the whole page. passsalt=no|domainname ^^^ 1) no = UAs should send passwords unsalted (e.g. for the sake of compatibility) 2) yes = (default value, 5.01 conforming UAs will salt passwords using domain name) 3) domainname = domain(+TLD), if site wants hashes salted using it's current or some another domain name How about just a simple extension to input type=password field instead? Let's add a new attribute 'salt' with the following definition: If 'salt' is defined for input element of type 'password', it will be used as a string domain in the f2() function above. The output of that function will be transferred as form data instead of real password. This has all the security of your proposed scheme (because there's no safety against MitM attack, there's no point to try to include any external information into the hash -- including the domain name). The server may use domain name as the salt or any random string it prefers. If server uses the same salt every time, it does not ever need to know the actual password. On the other hand, using the same salt makes the database more vulnerable to offline attack if the database is ever leaked. However, the server must be coded to accept BOTH salted password and plain text password to support existing user agents. It could be specified that entire ascii/UTF-8 (identical) hex encoded sha256 output must be used as the form value. The length of inputted password would then be a pretty good indicator of salted and hashed password. Why passsalt in html5.xx specification ^^ 1) multi-use of same passwords is a growing security problem. A successfull stealing single sites unencrypted real person names + passwords can lead to thousands of ID theft cases. It is not safe to use the same password on multiple sites, hashed or not. The only safe method is to use random password for every site and use (real, not obfuscated) encrypted local storage for real passwords. I do understand that the secure scheme is hard to implement if you're using multiple devices to access the service. In addition, it's not usable or safe on untrusted devices (but neither is any other scheme). Allowing a scheme suggested here would allow something slightly better than the current situation but it should be said plain and clear in the spec that this is not a replacement for real security. 2) Voluntary salting of passwords has failed even on reputable sites. The server must have knowledge of real password to use powerful salt (that is, the salt is not shared) 3) Forcing the passwords salted is one solution. But the UA needs to know if it should send password salted or unsalted. Situation where one UA would send salted password and another unsalted is unacceptable Why do you think so? If the server knows only salted
Re: [whatwg] Need document.available_fonts() call
On 5/11/10 9:39 AM, Ashley Sheridan wrote: Is there really much of a need for this though? Good question. What _is_ the use case here, exactly? The only argument I've seen is that various fonts are obviously different sizes, and so falling back to a different font might look best if the font-size also changed with it. Sure, and CSS has provisions for this. See http://www.w3.org/TR/css3-fonts/#relative-sizing-the-font-size-adjust-pro (also present in CSS2; removed from CSS2.1 due to poor UA support as far as I can tell, but the right solution to this problem). -Boris
Re: [whatwg] Need document.available_fonts() call
On Tue, 11 May 2010 16:08:01 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 5/11/10 9:39 AM, Ashley Sheridan wrote: Is there really much of a need for this though? Good question. What _is_ the use case here, exactly? E.g. allowing the user to select a font in a text editing or drawing application. However, for portability it would probably be better if these were limited to fonts already on the Web. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Need document.available_fonts() call
On Tue, 2010-05-11 at 16:14 +0200, Anne van Kesteren wrote: On Tue, 11 May 2010 16:08:01 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 5/11/10 9:39 AM, Ashley Sheridan wrote: Is there really much of a need for this though? Good question. What _is_ the use case here, exactly? E.g. allowing the user to select a font in a text editing or drawing application. However, for portability it would probably be better if these were limited to fonts already on the Web. I agree, portability dictates that they should stick to the few common fonts, or we end up with the same situation I've had countless times where someone sent an MSWord file with all the bullets as some character from the Wingdings font then wonder why people complain that all their bullets are letters. Embedding the font isn't feasible in this case because you really can't trust the end-user to observe the legal aspects of the fonts they have on their system. The designer of a font may not have given user rights to distribute the font in a document that is publically available like this. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Need document.available_fonts() call
On Tue, 11 May 2010 16:26:43 +0200, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Tue, 2010-05-11 at 16:14 +0200, Anne van Kesteren wrote: On Tue, 11 May 2010 16:08:01 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 5/11/10 9:39 AM, Ashley Sheridan wrote: Is there really much of a need for this though? Good question. What _is_ the use case here, exactly? E.g. allowing the user to select a font in a text editing or drawing application. However, for portability it would probably be better if these were limited to fonts already on the Web. I agree, portability dictates that they should stick to the few common fonts, or we end up with the same situation I've had countless times where someone sent an MSWord file with all the bullets as some character from the Wingdings font then wonder why people complain that all their bullets are letters. Embedding the font isn't feasible in this case because you really can't trust the end-user to observe the legal aspects of the fonts they have on their system. The designer of a font may not have given user rights to distribute the font in a document that is publically available like this. I've suggested this back in 2007 http://lists.w3.org/Archives/Public/public-webapi/2007Jul/0021.html Regarding filtering which fonts, do note that a web page is not the only place where web standards and APIs are used. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] New File attributes creationDate, modificationDate and size
On May 11, 2010, at 3:43 AM, J Ross Nicoll wrote: Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file There doesn't appear to be anyway of retrieving creation date, modification date or size of the file. Could I suggest adding attributes creationDate, modificationDate and size to provide this information? For a use case; we're working an a student coursework submission system, where they'll be able to drag and drop files. It would be useful to show the student details of the file they're uploading (for example, modification date is useful to confirm they're uploading the most recent version). We do actually see a fairly large number of mis-uploads with the existing upload system, and are hoping exposing more information during the upload (rather than once the file is received) will help. I was just going to ask the same question. My use case is for a progress bar. As I parse a file, it would be nice to have a progress bar based upon the file size and how much has been parsed.
Re: [whatwg] Need document.available_fonts() call
On May 11, 2010, at 9:26 AM, Ashley Sheridan wrote: On Tue, 2010-05-11 at 16:14 +0200, Anne van Kesteren wrote: On Tue, 11 May 2010 16:08:01 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 5/11/10 9:39 AM, Ashley Sheridan wrote: Is there really much of a need for this though? Good question. What _is_ the use case here, exactly? E.g. allowing the user to select a font in a text editing or drawing application. However, for portability it would probably be better if these were limited to fonts already on the Web. I agree, portability dictates that they should stick to the few common fonts, or we end up with the same situation I've had countless times where someone sent an MSWord file with all the bullets as some character from the Wingdings font then wonder why people complain that all their bullets are letters. Embedding the font isn't feasible in this case because you really can't trust the end-user to observe the legal aspects of the fonts they have on their system. The designer of a font may not have given user rights to distribute the font in a document that is publically available like this. Well, my take is just the opposite. Portability should dictate only if the user wants portability. I don't believe we confine what colors can be picked based upon what is portable. People, users, authors, etc learn over time. We are seeing with HTML5 and all of its capabilities a real working platform for almost anything. I'm sure there will be ten times as many beasts created from it as beauties but I don't see that as a reason to constrain the possibilities. pedz
Re: [whatwg] getElementById
On May 10, 2010, at 10:54 PM, Garrett Smith wrote:
On Mon, May 10, 2010 at 8:28 PM, Perry Smith pedz...@gmail.com wrote:
snip
So, how about this?
As part of HTMLElement, have a defined bucket, maybe call it elementObject
which is defined to be a native ECMAScript object. If X denotes a
particular DOM element, then X.elementObject is defined to return the same
native ECMAScript object each time. More details could be added perhaps to
define how the object is created (i.e. which prototype to use, etc). I'm
thinking making it the same as {}.
WebIDL could require DOM objects to be implemented as native ECMAScript
objects.
To me, the host objects and the fact that they are mostly unspecified seems
rather critical and limiting. The getUserData seems terribly awkward and I
guess it suffers from portability issues as well.
Is WebIDL the best place to address this?
Thanks,
pedz
Re: [whatwg] New File attributes creationDate, modificationDate and size
On 5/11/10 11:43 AM, J Ross Nicoll wrote: Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file Note, discussion about FileAPI should happen in WebApps WG mailing list. There doesn't appear to be anyway of retrieving creation date, modification date or size of the file. You can get the size from Blob. And File extends Blob. -Olli Could I suggest adding attributes creationDate, modificationDate and size to provide this information? For a use case; we're working an a student coursework submission system, where they'll be able to drag and drop files. It would be useful to show the student details of the file they're uploading (for example, modification date is useful to confirm they're uploading the most recent version). We do actually see a fairly large number of mis-uploads with the existing upload system, and are hoping exposing more information during the upload (rather than once the file is received) will help.
[whatwg] Image resize API proposal
I'm working with David Levin, and based on the feedback received regarding
offscreen canvas, the proposal has been changed to address more specific
scenarios. The main use case was resizing images, so we are proposing an
asynchronous image resizing API. If you are curious about how we arrived at
our API below, take a look at the appendix to view the alternatives we
considered.
Let us know what you think. Thanks!
Sterling
Use Cases:
Begin with a user giving a local image file to a webpage. Then:
1. In real-time chat, quickly give other users a thumbnail view of the image
file.
2. Or, limit the size of an image file before uploading it to a web server.
Proposed Solution:
We propose adding image.getBlob. getBlob will be an instance function of the
javascript Image object which asynchronously gets a blob of the image,
resized to the given width and height, encoded into jpeg or png. The
function declaration will be:
getBlob(mimeType /* req */, width /* req */, height /* req */, successEvent
/* req */, errorEvent /* op */, qualityLevel /* op */, preserveAspectRatio
/* op */, rotateExif /* op */);
The blob will be passed as an argument to the success callback function, or
upon error, error data will be passed into the error callback function as an
argument. Quality level should be between 0.0 and 1.0, and any value outside
of that range will be reverted to the default, 0.85. If MIME type does not
equal image/jpeg, then quality level is ignored. If null (or a negative
value) is passed in for the width or height, then the function will use the
source's measurement for that dimension. Default values for
preserveAspectRatio and rotateExif are true.
All EXIF metadata will be retained except for any saved thumbnails, and the
EXIF rotation property will be appropriately modified.
Security:
If the image source is of a different origin than the script context, then
getBlob raises a SECURITY_ERR exception.
Sample Code:
// url contains location of an image file
Image i = new Image();
i.src = url;
var successEvt = function (newBlob) { myDiv.innerHTML += img src=' +
newBlob.url + ' /; };
var errEvt = function (err) { alert(err); };
i.getBlob(image/jpeg, 300, 350, successEvt, errEvt, .55);
// Image will retain aspect ratio and correct for EXIF rotation. If the
source image was 700x700,
// the blob will represent a new image that is 300x300.
That's all!Appendix: Alternatives considered
For reference, we've also included a list of other designs that we thought
of along with the reasons why they were dropped
Creating a new object for resizing
Summary of approach:
[NamedConstructor=ImageResizer(),
NamedConstructor=ImageResizer(blob, onsuccess),
NamedConstructor=ImageResizer(blob, onsuccess, onerror),
NamedConstructor=ImageResizer(blob, onsuccess, onerror, type),
NamedConstructor=ImageResizer(blob, onsuccess, onerror, type, width,
height)]
interface ImageResizer {
void start(); // starts resize operation
void abort(); // aborts operation
attribute Blob blob;
attribute DOMString type; // default image/png
attribute unsigned long width;
attribute unsigned long height;
attribute float qualityLevel; // default 1.0, must be 0.0 to 1.0, else
reverts to default
readonly attribute unsigned short started; // default 0
attribute Function onsuccess;
attribute Function onerror;
};
Why it wasn't chosen:
Creating an entirely new object for this task made the task seem more
complicated and involved than necessary, and this problem could be solved
via modifications to the Image object.
Returning a SizelessBlob immediately from a method on image
Summary of approach:
var streamingBlob = image.toStreamingBlob(mimeType /* req */, width /* req
*/, height /* req */, qualityLevel /* op */, preserveAspectRatio /* op */,
rotateExif /* op */);
New Blob Interfaces:
interface SizelessBlob {
// moved from Blob
readonly attribute DOMString type;
readonly attribute DOMString url; // whatever name -- URL, urn, URN, etc.
}
interface StreamingBlob : SizelessBlob {
// at most one of the following functions will be called for a single
FutureBlob
attribute Function onblobready;
attribute Function onerror;
readyonly attribute blob; // throws an exception if accessed before
onblobready is called.
}
interface Blob : SizelessBlob {
readonly attribute unsigned long long size;
Blob slice(in long long start,
in long long length); // raises DOMException
};
Why it wasn't chosen:
- the disconnect of the error from the thing that caused it making
failures hard to understand (e.g. An image load may fail but that may not be
detected until the xhr is done using the resized image.)
- the issues that result from passing a SizelessBlob, which has a
reference to a loading image, to another document and closing the original
document (thus killing the image loader)
- introduction of multiple blobs which may be confusing to developers
- the need to change all existing specs to use SizelessBlob
Re: [whatwg] New File attributes creationDate, modificationDate and size
On Tue, May 11, 2010 at 4:43 AM, J Ross Nicoll j...@jrn.me.uk wrote: Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file There doesn't appear to be anyway of retrieving creation date, modification date or size of the file. Could I suggest adding attributes creationDate, modificationDate and size to provide this information? Note that not all filesystems the server might be using keep creation date, and there are different granularities for modification date. -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] New File attributes creationDate, modificationDate and size
On Tue, May 11, 2010 at 11:31 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 5/11/10 11:43 AM, J Ross Nicoll wrote: Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file Note, discussion about FileAPI should happen in WebApps WG mailing list. There doesn't appear to be anyway of retrieving creation date, modification date or size of the file. You can get the size from Blob. And File extends Blob. Indeed. A progress bar is implementable using the features already specced in File and FileReader. As for the creationDate and modificationDate, this seems ok to me. I'm as always somewhat concerned about privacy, but I think on the whole it would be ok. / Jonas
Re: [whatwg] Need document.available_fonts() call
On Tue, May 11, 2010 at 11:09 AM, Perry Smith pedz...@gmail.com wrote: Well, my take is just the opposite. Portability should dictate only if the user wants portability. I don't believe we confine what colors can be picked based upon what is portable. Actually... some machines can display colors with rgb values outside of the [0,255] range. But CSS clamps you to that range because it's portable. ~TJ
Re: [whatwg] Need document.available_fonts() call
On 5/11/10 4:59 PM, Tab Atkins Jr. wrote: On Tue, May 11, 2010 at 11:09 AM, Perry Smithpedz...@gmail.com wrote: Well, my take is just the opposite. Portability should dictate only if the user wants portability. I don't believe we confine what colors can be picked based upon what is portable. Actually... some machines can display colors with rgb values outside of the [0,255] range. But CSS clamps you to that range because it's portable. CSS clamps to [0,255]? Since when? http://www.w3.org/TR/css3-color/#rgb-color says: Values outside the device gamut should be clipped or mapped into the gamut when the gamut is known: the red, green, and blue values must be changed to fall within the range supported by the device. User agents may perform higher quality mapping of colors from one gamut to another. This specification does not define precise clipping behavior. ... Other devices, such as printers, have different gamuts than sRGB; some colors outside the 0..255 sRGB range will be representable (inside the device gamut), while other colors inside the 0..255 sRGB range will be outside the device gamut and will thus be mapped. There is then an example that says that on an sRGB device rgb(300,0,0) will be the same as rgb(255,0,0)... but on a non-sRGB device they may well not be. -Boris
Re: [whatwg] Need document.available_fonts() call
On May 11, 2010, at 3:59 PM, Tab Atkins Jr. wrote: On Tue, May 11, 2010 at 11:09 AM, Perry Smith pedz...@gmail.com wrote: Well, my take is just the opposite. Portability should dictate only if the user wants portability. I don't believe we confine what colors can be picked based upon what is portable. Actually... some machines can display colors with rgb values outside of the [0,255] range. But CSS clamps you to that range because it's portable. True, CSS restricts the color space to sRGB. But CSS allows for 16 bit colors. That is more what I was referring to. The older machines can not display such subtleties so wise authors choose to confine their color choices but we are still allowed to pick the other colors. Drifting off the topic a bit, has anyone suggested introducing the Lab color space to CSS and HTML? It is a very nice for some applications. pedz
Re: [whatwg] Need document.available_fonts() call
On Tue, May 11, 2010 at 2:30 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/11/10 4:59 PM, Tab Atkins Jr. wrote: On Tue, May 11, 2010 at 11:09 AM, Perry Smithpedz...@gmail.com wrote: Well, my take is just the opposite. Portability should dictate only if the user wants portability. I don't believe we confine what colors can be picked based upon what is portable. Actually... some machines can display colors with rgb values outside of the [0,255] range. But CSS clamps you to that range because it's portable. CSS clamps to [0,255]? Since when? http://www.w3.org/TR/css3-color/#rgb-color says: Values outside the device gamut should be clipped or mapped into the gamut when the gamut is known: the red, green, and blue values must be changed to fall within the range supported by the device. User agents may perform higher quality mapping of colors from one gamut to another. This specification does not define precise clipping behavior. ... Other devices, such as printers, have different gamuts than sRGB; some colors outside the 0..255 sRGB range will be representable (inside the device gamut), while other colors inside the 0..255 sRGB range will be outside the device gamut and will thus be mapped. There is then an example that says that on an sRGB device rgb(300,0,0) will be the same as rgb(255,0,0)... but on a non-sRGB device they may well not be. This is why I should read more closely, dammit. ~TJ
Re: [whatwg] [ogg-dev] HTML5 audio tag
Yeah, the track attribute of the media fragments specification that Ralph links will in theory allow to just download the track-related data. But it still requires implementation - either in the browser, which will somehow need to identify which bytes belong to which track and just request those byte ranges that are relevant, or on the server, which will only deliver the relevant bytes when asked for the audio track only. None of this is implemented yet. In fact, the discovery of which bytes in a Ogg stream belong to which track is a challenge. I am not sure whether the new Skeleton Index format might actually allow for that... Cheers, Silvia. On Wed, May 12, 2010 at 3:32 AM, Frank Barchard fbarch...@google.com wrote: FWIW chromium does client side range requests that in theory would request only the audio. But. the ogg demux reads the other tracks and discards them. A use case I've heard is listening to music videos and discard the video... bit of a bandwidth waste. On Tue, May 11, 2010 at 10:17 AM, Ralph Giles gi...@thaumas.net wrote: On 11 May 2010 04:24, narendra sisodiya narendra.sisod...@gmail.com wrote: It will be very good if HTML5 API specify this. I mean, Say, If we use audio tag , then It must stream only audio part of the file irrespective of the fact that the src field contains a video file. I don't think that's a practical option, since the server must manipulate the file to return an audio-only subset of the data for there to be any bandwidth advantage. That's not something that the HTML5 specification, which documents browser behaviour, can describe. Note that it's completely possible to use a server-size module or script to do this, using a query url in the HTML5 media element's src attribute. It's just part of a custom server config rather than the HTML5 API. The Media Fragments Working Group at the W3C is currently working on a standardized syntax for this. See http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/ if you're interested. FWIW, -r ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev
Re: [whatwg] [ogg-dev] HTML5 audio tag
In order to do this you'd need to know /in advance/ exactly which Ogg pages were audio and which were video so you could choose to only download the vorbis pages. The upcoming Ogg Skeleton index does not index pages at a high enough granularity to facilitate this. It could, but then the index would be a lot bigger. I also wonder if the time/server overhead of setting up new HTTP byte-range request for each ~4KB Ogg vorbis page wouldn't make this worth while. Especially over a high latency connection. You'd be best to oggz-rip the streams you want out in advance and serving them statically, as Conrad suggested. It's /impossible/ to determine in advance which byte ranges to download in order to download only one stream. You simply don't know which stream a page belongs to or what size it is until you've downloaded the page. Chris P. On 12/05/2010 11:18 a.m., Silvia Pfeiffer wrote: Yeah, the track attribute of the media fragments specification that Ralph links will in theory allow to just download the track-related data. But it still requires implementation - either in the browser, which will somehow need to identify which bytes belong to which track and just request those byte ranges that are relevant, or on the server, which will only deliver the relevant bytes when asked for the audio track only. None of this is implemented yet. In fact, the discovery of which bytes in a Ogg stream belong to which track is a challenge. I am not sure whether the new Skeleton Index format might actually allow for that... Cheers, Silvia. On Wed, May 12, 2010 at 3:32 AM, Frank Barchardfbarch...@google.com wrote: FWIW chromium does client side range requests that in theory would request only the audio. But. the ogg demux reads the other tracks and discards them. A use case I've heard is listening to music videos and discard the video... bit of a bandwidth waste. On Tue, May 11, 2010 at 10:17 AM, Ralph Gilesgi...@thaumas.net wrote: On 11 May 2010 04:24, narendra sisodiyanarendra.sisod...@gmail.com wrote: It will be very good if HTML5 API specify this. I mean, Say, If we use audio tag , then It must stream only audio part of the file irrespective of the fact that the src field contains a video file. I don't think that's a practical option, since the server must manipulate the file to return an audio-only subset of the data for there to be any bandwidth advantage. That's not something that the HTML5 specification, which documents browser behaviour, can describe. Note that it's completely possible to use a server-size module or script to do this, using a query url in the HTML5 media element's src attribute. It's just part of a custom server config rather than the HTML5 API. The Media Fragments Working Group at the W3C is currently working on a standardized syntax for this. See http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/ if you're interested. FWIW, -r ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev
Re: [whatwg] [ogg-dev] HTML5 audio tag
I've heard it is easier with MP4 to do byte-range requests for a track only. Thanks for clarifying that index won't have any of this information! Indeed, providing an audio file on the server is the simplest solution to this (follow the KISS-principle :). Cheers, Silvia. On Wed, May 12, 2010 at 10:19 AM, Chris Pearce ch...@pearce.org.nz wrote: In order to do this you'd need to know in advance exactly which Ogg pages were audio and which were video so you could choose to only download the vorbis pages. The upcoming Ogg Skeleton index does not index pages at a high enough granularity to facilitate this. It could, but then the index would be a lot bigger. I also wonder if the time/server overhead of setting up new HTTP byte-range request for each ~4KB Ogg vorbis page wouldn't make this worth while. Especially over a high latency connection. You'd be best to oggz-rip the streams you want out in advance and serving them statically, as Conrad suggested. It's impossible to determine in advance which byte ranges to download in order to download only one stream. You simply don't know which stream a page belongs to or what size it is until you've downloaded the page. Chris P. On 12/05/2010 11:18 a.m., Silvia Pfeiffer wrote: Yeah, the track attribute of the media fragments specification that Ralph links will in theory allow to just download the track-related data. But it still requires implementation - either in the browser, which will somehow need to identify which bytes belong to which track and just request those byte ranges that are relevant, or on the server, which will only deliver the relevant bytes when asked for the audio track only. None of this is implemented yet. In fact, the discovery of which bytes in a Ogg stream belong to which track is a challenge. I am not sure whether the new Skeleton Index format might actually allow for that... Cheers, Silvia. On Wed, May 12, 2010 at 3:32 AM, Frank Barchard fbarch...@google.com wrote: FWIW chromium does client side range requests that in theory would request only the audio. But. the ogg demux reads the other tracks and discards them. A use case I've heard is listening to music videos and discard the video... bit of a bandwidth waste. On Tue, May 11, 2010 at 10:17 AM, Ralph Giles gi...@thaumas.net wrote: On 11 May 2010 04:24, narendra sisodiya narendra.sisod...@gmail.com wrote: It will be very good if HTML5 API specify this. I mean, Say, If we use audio tag , then It must stream only audio part of the file irrespective of the fact that the src field contains a video file. I don't think that's a practical option, since the server must manipulate the file to return an audio-only subset of the data for there to be any bandwidth advantage. That's not something that the HTML5 specification, which documents browser behaviour, can describe. Note that it's completely possible to use a server-size module or script to do this, using a query url in the HTML5 media element's src attribute. It's just part of a custom server config rather than the HTML5 API. The Media Fragments Working Group at the W3C is currently working on a standardized syntax for this. See http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/ if you're interested. FWIW, -r ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev
Re: [whatwg] Need document.available_fonts() call
On 2010-05-11, Boris Zbarsky bzbar...@mit.edu wrote: On 5/11/10 9:39 AM, Ashley Sheridan wrote: Is there really much of a need for this though? Good question. What _is_ the use case here, exactly? How about cloud computing? Gimp or CorelDraw like applications. There are already bitmap and vector editors in html5 using javascript. A user should be allowed to make use of the large amount of fonts site on his hard disk. Especially desktop publishing applications. Legal embeding of font is not a specific problem to cloud computing. Desktop applications had that problem since day one. So it is not like suddenly this is a problem. Just solve it like it's always been, through legal system. I think that HTML5 aims more than just web browsering anymore. There are much broader vision ahead.
Re: [whatwg] New File attributes creationDate, modificationDate and size
It would be good if we can also get the same at server side when user upload a file using form with file controls ie, like the suggestion at https://bugzilla.mozilla.org/show_bug.cgi?id=549253 (it works even with javascript disabled) Also remember modificationDate can be a time before creationDate on windows. This is because modificationDate get copied when you copy a file, hence it almost shows modificationDate of the actual content. creationDate on other hand is file creation time on the folder/directory and when you copy a file to a new directory, it will be showing the coping time. PS, for JS option there is mozilla bug 390776
