Re: [whatwg] script type= and style type= parsing
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, 1.2, 1.3, 1.4, 1.5, 1.5 with E4X, 1.6, 1.6 with E4X, 1.7, 1.7 with E4X, JScript, JScript.Encode, and VBScript. At least. I'm not sure we want to go there (mostly because I have no idea what we should say). Hmm. I hope this will be defined by someone at some point. Well, at least the version switches that are important for interoparability. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Google Gears and HTML5
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. what's the use case for ... rename and copy Sometimes you want to return the contents of one real-world URL (like http://example.com/) in response to a different URL request (like http://example.com/?offline=1). The rename and copy methods let you do that. Why can't the app just request the resource from the server with the correct URI to start with? I'm a bit fuzzy on the use cases you have in mind for ResourceStores in general. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Google Gears and HTML5
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 environment, which isn't particularly useful, but would at least prevent the ambiguity. What do you mean throw into the environment? The update might occur automatically in which case I'm not sure where an exception would go. And it seems that preventing the update might lead to the app being unrecoverably stuck. * Rename/copy were motivated by a particular problem we had with an internal app that we were playing with. When you would capture files using the file upload api while offline, you would need to rename them after you found out the primary key of the entity on the server because the application would build the URIs based on these PKs. This probably could have been solved other ways on the server. I think the best way to handle file uploads (in an HTML5 context) is to provide an API that any Web app can use to directly read the contents of a file input control. That seems conceptually simple and also potentially useful to all kinds of Web apps, online and offline. I agree that having overlapping URLs is a pain with the current design. It would be nice if URLs were unique. What we found is that in many applications, URLs aren't unique. Localization is one example of this, but there are many. I think it may not be necessary to have both enable/disable *and* requiredCookie, but we probably need something. requiredCookie just removes some of the legwork of toggling a bunch of stores on and off on each login. What are the other uses? Are they all situations where the content for a given URI is stable within a given logon session? (As you would expect if cookies are sufficient to discriminate between the different contents...) I think restricting URIs to map to just one resource simplifies things a lot. Another simplification that our model has is that offline resources are never directly mutated by the client; they are always just a snapshot of server state. These two properties are very appealing... We can also safely support cross-domain offline loads (e.g. to get canonical library scripts, or looking forward to WHATWG-style messaging APIs, cross-domain communication) which I think is hard to do without the latter property. I think we can extend our model to support Gears-style consistency without JARs by adding support for manifests somehow (e.g. link rel=offline-manifest), and then requiring that all offline resources in a domain (that are used by apps in the same domain*) be updated atomically roughly the same way Gears does it. But I need to talk to Dave about it... (* Applications using cross-domain loads don't get any consistency guarantees for those loads. For example we don't want someone randomly referencing a missing file under example.com and breaking updates of example.com's own applications.) Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Steps for finding one or two numbers in a string
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 statement was not precise enough. It applies to attribute names, not to attributes as such. I don't understand, could you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Steps for finding one or two numbers in a string
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 for finding one or two numbers in a string 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 statement was not precise enough. It applies to attribute names, not to attributes as such. I don't understand, could you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Steps for finding one or two numbers in a string
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 should change? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Steps for finding one or two numbers in a string
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 Ian Hickson Sent: Tuesday, June 12, 2007 10:09 PM To: Kristof Zelechovski Cc: 'Henri Sivonen'; 'whatwg List' Subject: Re: [whatwg] Steps for finding one or two numbers in a string 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 should change? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Steps for finding one or two numbers in a string
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? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Steps for finding one or two numbers in a string
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 does no harm either. Chris -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 12, 2007 10:20 PM To: Kristof Zelechovski Cc: 'whatwg List' Subject: RE: [whatwg] Steps for finding one or two numbers in a string 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? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] script type= and style type= parsing
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 it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Steps for finding one or two numbers in a string
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 http://www.whatwg.org/specs/web-apps/current-work/#attributes0 technically is not needed, although it does no harm either. Ok. Since it does no harm and might help some readers, I'll leave it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Empty attribute syntax
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 heavy script dialog; just press continue. http://simon.html5.org/test/html/parsing/empty-attribute-syntax/ Results: IE7 drops the following attributes: a href area href input src iframe src img src Opera drops a whole lot of attributes. Here's for the a tag only: a accept charset class id onkeypress onkeydown onkeyup onclick ondblclick onmousedown onmouseup onmouseover onmousemove onmouseout onmousewheel onerror onload onresize onscroll onunload onreset onsubmit onblur onchange onfocus oninput onselect accessKey action archive autocomplete axis background char charset cite classid code codeBase codeType cols content data dateTime dynsrc encType face for headers href hreflang http-equiv label language longDesc name profile prompt rel rev rows scheme scope src standby summary target useMap value valuetype version wrap xmlns Firefox and Safari don't drop any attributes. -- Simon Pieters
[whatwg] Allowed characters in attribute names (was: Re: Steps for finding one or two numbers in a string)
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 http://www.whatwg.org/specs/web-apps/current-work/#attributes0 technically is not needed, although it does no harm either. Any (namespace-less) attribute may be specified on the embed element. -- http://www.whatwg.org/specs/web-apps/current-work/#the-embed Since attribute names that use characters outside ASCII aren't parse errors, and any attribute is allowed on the embed element, the definition of Attribute names in #writing is incorrect. I would suggest to change the definition in #writing to say that attribute names can consist of any characters except whitespace, =, , / and . Although that isn't quite right either. The parsing section allows attributes to begin with =. Given the following markup: a == Safari, Opera and Firefox drop the attribute. IE has an attribute with the name being the empty string and the value being =. The HTML5 parsing spec says that there should be an attribute with the name = and the value the empty string. The Before attribute name state part of the parsing spec might have to be revisited. -- Simon Pieters
Re: [whatwg] Empty attribute syntax
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 doesn't work in IE7. In Firefox you'll get the heavy
script dialog; just press continue.
http://simon.html5.org/test/html/parsing/empty-attribute-syntax/
Results:
IE7 drops the following attributes:
a href
area href
input src
iframe src
img src
we had someone come on irc.mozilla.org asking for help working around
img src it seems their buggy app was written to ie, so when firefox
runs, it treats img src= or maybe img src as img
src={current-html-document} which then breaks their broken app
because it's a duplicate resource request for some resource which
clearly doesn't handle the case.
I'm not absolutely certain which of img src or img src= the
person had, and I suggested adding a base href, but I do not recall
the person indicating whether it worked.
I
Opera drops a whole lot of attributes. Here's for the a tag only:
a accept charset class id onkeypress onkeydown onkeyup onclick
ondblclick onmousedown onmouseup onmouseover onmousemove onmouseout
onmousewheel onerror onload onresize onscroll onunload onreset onsubmit
onblur onchange onfocus oninput onselect accessKey action archive
autocomplete axis background char charset cite classid code codeBase
codeType cols content data dateTime dynsrc encType face for headers href
hreflang http-equiv label language longDesc name profile prompt rel rev
rows scheme scope src standby summary target useMap value valuetype
version wrap xmlns
Firefox and Safari don't drop any attributes.
