On Tue, 12 Jun 2007 00:36:06 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
Anyway, I've defined (to some extent) the processing of type= and
language=. I'm not really sure exactly what more to say. If we get into
much more detail, we'll start having to define the difference between
JS1.0, 1.1,
On 6/12/07, Chris Prince [EMAIL PROTECTED] wrote:
what's the use case for remove
Without it, once you put a given URL in the ResourceStore, it would be
served from there forever. Also, remember that the ResourceStore
doesn't auto-update URL contents like the ManagedResourceStore does.
On 6/12/07, Aaron Boodman (Google) [EMAIL PROTECTED] wrote:
On 6/11/07, Robert O'Callahan [EMAIL PROTECTED] wrote:
Chris Prince wrote:
How do you do that when an ambiguity is discovered during a manifest
update?
That's a good point, i think all we could do there is throw into the
On Sat, 9 Jun 2007, Kristof Zelechovski wrote:
On Fri, 14 Apr 2006, Henri Sivonen wrote:
I think i18n political correctness has no place in attributes. I
think they should be ASCII only with the XML notion of whitespace.
I agree and believe the spec already requires this.
That
Attribute names are limited to ASCII, attribute values are not.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Tuesday, June 12, 2007 9:54 PM
To: Kristof Zelechovski
Cc: 'Henri Sivonen'; 'whatwg List'
Subject: Re: [whatwg] Steps
On Tue, 12 Jun 2007, Kristof Zelechovski wrote:
Attribute names are limited to ASCII, attribute values are not.
Neither are limited to ASCII. I don't understand. The discussion was
concerning the numeric search algorithms for progress bars, not attribute
names. What exactly are you requesting
Attribute names are not and cannot be localized because they are for the
software and not for the human reader. That means they are limited to ASCII
whether the standard is specific about that or not.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
On Tue, 12 Jun 2007, Kristof Zelechovski wrote:
Attribute names are not and cannot be localized because they are for the
software and not for the human reader. That means they are limited to
ASCII whether the standard is specific about that or not.
Ok... So the spec doesn't have to change?
The specification enumerates all accepted element attributes. Neither of
them transgresses ASCII boundaries. Since it can be directly inferred from
the text, the explicit statement about that
http://www.whatwg.org/specs/web-apps/current-work/#attributes0 technically
is not needed, although it
On Tue, 12 Jun 2007, Anne van Kesteren wrote:
Hmm. I hope this will be defined by someone at some point. Well, at
least the version switches that are important for interoparability.
Me too. If you have an editor who has the time to work this out, the
WebAPI WG is probably the best place for
On Tue, 12 Jun 2007, Kristof Zelechovski wrote:
The specification enumerates all accepted element attributes. Neither of
them transgresses ASCII boundaries. Since it can be directly inferred from
the text, the explicit statement about that
I realised that IE7 and Opera dropped the href attribute when using the
markup a href. So I decided to test whether this happened to other
attributes as well.
The test takes a while to run. 001.htm doesn't work in Opera, and
001-opera.htm doesn't work in IE7. In Firefox you'll get the
On Tue, 12 Jun 2007 22:28:52 +0200, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
The specification enumerates all accepted element attributes. Neither of
them transgresses ASCII boundaries. Since it can be directly inferred
from
the text, the explicit statement about that
On 6/13/07, Simon Pieters [EMAIL PROTECTED] wrote:
I realised that IE7 and Opera dropped the href attribute when using the
markup a href. So I decided to test whether this happened to other
attributes as well.
The test takes a while to run. 001.htm doesn't work in Opera, and
001-opera.htm
14 matches
Mail list logo
