On Tue, 17 Apr 2007 22:37:16 +0200, Jordan OSETE
<[EMAIL PROTECTED]> wrote:
PS: is it OK to post suggestions on the message board (at
http://forums.whatwg.org/) instead of the mailing lists?
Yes.
Or maybe less people would read it?
Discussions in the forums can always be forwarded to th
Stefan Haustein wrote :
Hi Jordan,
in my opinion, preserving the path for re-use does not buy much: Path
construction at this level is just appending a few coordinates and
meta-information to an array. Since there is no knowledge about future
transformations, one needs to keep the original coord
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
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 fix
Le 2007-04-17 à 13:05, Kristof Zelechovski a écrit :
Methinks we could easily overcome the semantic problems with the
element if we renamed it to .
The problem I described is not about the meaning of , it's
about structuring its content to accomodate various uses. In what way
changing t
Methinks we could easily overcome the semantic problems with the
element if we renamed it to .
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michel Fortin
Sent: Tuesday, April 17, 2007 6:54 PM
To: Elliotte Harold
Cc: WHAT working group
Subject: Re
Le 2007-04-08 à 14:42, Elliotte Harold a écrit :
Sounds a little redundant with ol (ordered list).
It is indeed a little redundant with , although it is more
specific in the same sense than is more specific than .
Also sounds needlessly confusing and hard to explain.
Having written the
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.
Here'
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
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
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, A
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
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.
13 matches
Mail list logo
