Re: [whatwg] Web Documents off the Web (was Web Archives)
2007/4/17, Jon Barnett: The main gripe about [MHTML] was that binary data is base64 encoded, which adds size to the file in the end. And which is a wrong assumption. Binary data can be sent with Content-Transfer-Encoding: binary. zipping the final MHTML file could help with size. I hope you're talking about GZip or BZip2, not application/zip… -- Thomas Broyer
Re: [whatwg] Web Documents off the Web (was Web Archives)
On 4/17/07, Thomas Broyer [EMAIL PROTECTED] wrote: 2007/4/17, Jon Barnett: The main gripe about [MHTML] was that binary data is base64 encoded, which adds size to the file in the end. And which is a wrong assumption. Binary data can be sent with Content-Transfer-Encoding: binary. True. The problem is the current browser support for .mht and support for generating/loading .mht files with binary attachments. That could possibly be fixed though. -- Michael
[whatwg] web-apps/current-work/#datetime-parser
Step 25 If sign is negative, then shouldn't timezoneminutes also be negated? Step 27 Shouldn't that be SUBTRACTING timezonehours hours and timezoneminutes minutes? My current time is 2007-04-17T05:28:33-04:00 The timezone is -4 hours from UTC. To convert to UTC I need to add 4 hours. - Sam Ruby
Re: [whatwg] Web Documents off the Web (was Web Archives)
The method for reading Web pages off line is subscription, not downloading. Your browser should support subscription. Enable it for your favorite pages and you are done. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Haustein Sent: Monday, April 16, 2007 11:39 PM To: Tyler Keating Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Web Documents off the Web (was Web Archives) Hi Tyler, I like the idea very much, for instance for having a copy of the CSS spec on my laptop without the need of an Internet connection while commuting - When I save a page with Safari, Firefox cannot read it. - When saving stuff with Firefox, I have to deal with both, the HTML file and the resource folder - It would be easy to write a nice wget-like utility that creates a single file. - A zip based format is still usable for browsers that do not support it, one would just needs to unpack the file. Best regards, Stefan Haustein
Re: [whatwg] Web Documents off the Web (was Web Archives)
On 4/17/07, Thomas Broyer [EMAIL PROTECTED] wrote: I hope you're talking about GZip or BZip2, not application/zip… Doesn't matter to me - I just figure some sort of compression would help, and it would probably help if that compression was supported by browsers, so gzip sounds right. The problem is the current browser support for .mht and support for generating/loading .mht files with binary attachments. Which appears to be halfway there in the major browsers. The method for reading Web pages off line is subscription, not downloading. Your browser should support subscription. Enable it for your favorite pages and you are done. Maybe in your browser, but not store on disk apart from your browser, and not to transfer to someone else (via email, web download, p2p) as a self-contained document (e.g. a powerpoint-style presentation) .mht looks good because it can retain original URLs of online resources, it's fairly human readable and debuggable, and it already has a standard and some support. An HTML document can reference its external parts (images, css) via either cid: URIs or the original HTTP URL as long as all the right Content-Location headers are present. a single compressed file (.zip?) looks good because of the size and how easily it can be unpacked and used with a browser that doesn't natively support the single compressed file. I don't know what URI scheme an HTML document would use to reference images and CSS. The only other thing I can think of is an HTML document that uses data: URIs to reference its external parts (e.g. a CSS file) which also use data URIs to reference their external parts (e.g. background images). What place does HTML5 have in specifying one of these options as a standard archive format? Any? A non-normative section on archives?
[whatwg] HTTP's Referer and Set-Cookie2 headers
May I suggest that you also allow the DOM referrer attribute to match a HTTP Referrer header if one is present, and fall back to the Referer header otherwise. This provides for HTML 5 compliant UAs to be forwards compatible with a potential future HTTP spec that fixes the typo. Also, the DOM cookie attribute discussion should mention the HTTP Set- Cookie2 header. Don't know what it should say though. http://www.whatwg.org/specs/web-apps/current-work/#resource - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Sequential List Proposal
Le 2007-04-17 à 13:05, Kristof Zelechovski a écrit : Methinks we could easily overcome the semantic problems with the dialogue element if we renamed it to transcript. The problem I described is not about the meaning of dialog, it's about structuring its content to accomodate various uses. In what way changing the name of dialog to transcript would solve the problem? I'm puzzeled. Maybe you meant changing the name would make it easier to excluse all the cases were you need to include extra information beside the speakers and the words they have said. But wouldn't not addressing the problems as a solution make the exercice pretty useless? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] HTTP's Referer and Set-Cookie2 headers
Nicholas Shanks wrote: May I suggest that you also allow the DOM referrer attribute to match a HTTP Referrer header if one is present, and fall back to the Referer header otherwise. This provides for HTML 5 compliant UAs to be forwards compatible with a potential future HTTP spec that fixes the typo. I think it would be the responsibility of that hypothetical future HTTP spec to describe backwards-compatibility requirements. Having everything that depends on HTTP have language about handling a possible future extension of HTTP that doesn't even exist is likely to result in lots of conflicting requirements. Or is there actually a new version of HTTP under discussion somewhere that I've missed?
Re: [whatwg] HTTP's Referer and Set-Cookie2 headers
Martin Atkins schrieb: ... I think it would be the responsibility of that hypothetical future HTTP spec to describe backwards-compatibility requirements. Having everything that depends on HTTP have language about handling a possible future extension of HTTP that doesn't even exist is likely to result in lots of conflicting requirements. Or is there actually a new version of HTTP under discussion somewhere that I've missed? ... There is indeed a revision of HTTP/1.1 under discussion (see HTTP mailing list http://lists.w3.org/Archives/Public/ietf-http-wg/, issues list http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/ and draft http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html), but the spelling of referer so far hasn't made it onto the issues list (and I doubt it will) :-). Best regards, Julian
