Re: [whatwg] A tag for measurements / quantity?
Aryeh Gregor wrote: It's not very hard to auto-convert units without semantic markup. I'd think it would be pretty easy to write a browser extension that read through a site's HTML and converted the units without author support. This would have the major advantage of not relying on authors knowing how to mark up their document correctly, so it would work in all cases instead of in probably a small minority. Has anyone written such an extension? There is an extension: http://converter.mozdev.org/ Judging from the documentation it seems to work rather well with trivial cases. But there are a number of situations where semantic information could aid conversion. For example Finnish has a rather complex morphology which makes automatic conversion tricky. The units will not be parseable from the text without parsing the language grammar. An example: Lisää 1 teelusikallinen sokeria 2 desilitraan vettä. Add 1 teaspoon of sugar to 2 deciliters of water. The roots of the words are 'teelusikka' and 'desilitra'. But it's still quite possible authors would not use semantic markup even if it was available. Additionally there are localization issues, things like decimal separators and such. It might well be such a tag would end up being used so little that automatic conversion would be the only viable option anyway. Regards, Max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Global Script proposal.
Jeremy Orlow wrote: Btw, I thought I'd just point out that the proposal mentions this case: From the proposal text: All pages connected to the same Global Script should run on the same thread, in the same process. Since this is not always technically possible, it should be legal (and not break the applications) for there to be duplicate global script contexts within a UA. I'm glad this came up, however, since now it's more clear why such language is necessary. Ah, right I misread that part. I interpreted the second half of it (after technically possible) as other threading models were possible. Now, as I understand it, two pages sharing a GlobalScript MUST share a single thread, or otherwise MUST use a different/duplicate GlobalScript instance. On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilson mike...@hotmail.com wrote: With this stated, I'd like to throw out a question on what do you want the most - max performance in 100% of cases, but redundant GlobalScript contexts, or max performance in most cases and singular GlobalScript contexts? I don't think any UA is realistically going to do this for v1. But sure, the door should be left open for in the future. (The initial proposal allows for both, btw.) That's exactly my point, the door should be open for these kind of improvements. But to allow both, I think the proposal text has to be adjusted somewhat, as interpretations (like mine) will otherwise risk assuming that different threads/processes MUST imply having different GlobalScript context instances. Best regards Mike
Re: [whatwg] Proposed changes to the History API
Justin Lebar wrote: [...] Notably unsupported by this API is support for pages altering their saved state. For instance, a page might want to save a text box's edit history to implement a fancy undo. [...] We'd probably want to fire PopState on all loads and history navigations, since any document might have a state to pop Right, this is exactly my thoughts on the API as well, as we started discussing recently, see: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022087.html | Though, when taking a more thorough look at what is | spec:ed, it seems these use cases are indeed not supported, | due to state update limitations and how events are ordered. Currently, the design with an immutable state object and the PopEvent and HashChange events triggering at somewhat insufficient timings, makes it hard to build the things I'm thinking about. IMO you need: - an event each time you're *leaving* a history entry (in addition to HashChange triggered when entering one) - allow updating existing state entries - shift the whole state entry model so that state entries belong to history entries, and are not logically inserted between them (this is actually a very important distinction) I'm hoping Ian will come back with the use cases he has in mind, as I am as of yet not clear on what he wants, or does not want, to support with the pushState model. Best regards Mike Wilson
Re: [whatwg] A tag for measurements / quantity?
Max wrote: Having used the web for the past 15 years I've always felt that it's a shame when you run into a page with a set of measurements and those can't be interpreted automatically in a sensible fashion. Especially with the fact that there are both imperial and metric units still around in this day and age. There is currently some work going on around measurements over on the microformats wiki: http://microformats.org/wiki/measure If you could share any ideas you have on the brainstorming page, that would be most welcome: http://microformats.org/wiki/measure-brainstorming ...and if you have any examples of markup in the wild, that would be great: http://microformats.org/wiki/measure-examples Hixie asked: I don't really understand the use case here. What problem would this be solving? The problem statement on the microformats wiki page reads: Measures (e.g. weights, sizes, temperatures) occur frequently on the Web, they are constituted of a value a unit-measure and, in scientific and technical contexts, an experimental uncertainty. These 3 elements should be marked-up consistently across websites so that they can be easily identified and acted upon (export, compute, convert) in collaborative distributed applications. Unit-measures differ from locale to locale (e.g. Fahrenheit vs. Celsius, pound versus Kilogram), making comparison and matching of offerings difficult. The measurement microformat will enable unambiguous description of physical quantities and thus provide a solid ground for data sharing and automation in many areas. Max wrote: Personally, the obvious use case for me is recipes. ... With the large majority of humanity doing cooking one could argue that this would be genuinely useful. Then again, it's quite possible no one would ever use this, and it would just end up cluttering the spec. I agree that there is a genuine use case and I also agree that the spec doesn't need to be cluttered with a solution that use case. I think that measurement in general (and recipes in particular) are best solved by microformats and/or microdata. By the way, there is a draft recipe microformat in the works and, once again, your input would be very welcome: http://microformats.org/wiki/hRecipe Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Global Script proposal.
This looks interesting.
Dmitry Titov wrote:
A web page will be able to create a Global Script and connect to it, as in
this example:
var context = new GlobalScript(); // perhaps 'webkitGlobalScript' as
experimental feature?
context.onload = function () {...}
context.onerror = function () {...}
context.load('foo.js');
Presumably this script is being loaded asynchronously, hence the
callbacks. But since the GlobalScript() constructor returns the
global object, probably doesn't make sense to attach the handlers
directly there, but actually on the load request somehow. And
presumably you'd be able to load multiple .js files. This will be
interesting, as the .js files presumably will get interpreted in an
arbitrary order - we'll be inventing some new idioms (not a problem,
just an observation).
Is this then really the only API exposed? A constructor and a js
loader? (+1, less is more)
I guess I'm wondering if there will be some desire to have pages opt-in
to this support, signaling this through an additional API, or like the
app-cache's manifest attribute on the html element, something in the
DOM; doesn't seem like we should drag the DOM in here, just mentioned it
because I was reminded of the way the opt-in works there.
Or perhaps these GlobalScripts - should really be called GlobalObjects
or GlobalContexts maybe; SharedScope? - could be named, by passing a
string on the constructor? Would there be value in having multiple
named scopes available? In the current scenario with a no-arg
constructor, what happens when I invoke it again? If it should return
the same object, then don't use a constructor, use a plain old function
- SharedScope.getCurrent().
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] A tag for measurements / quantity?
Jeremy Keith wrote: Unit-measures differ from locale to locale (e.g. Fahrenheit vs. Celsius, pound versus Kilogram), making comparison and matching of offerings difficult. There's more variation than that: (imperial) gallon v. (US) gallon. Cases like that really make it hard to deal with. Then you have varying names in different languages, disagreement about what kilobyte means, and so much more… Sounds like a whirlwind of fun. -- Geoffrey Sneddon — Opera Software http://gsnedders.com/ http://www.opera.com/
[whatwg] Text areas with pattern attributes?
I'm drifting into writing code for the pattern attribute on text fields again, and I wondered: if text inputs can have pattern attribute for regular expression matching, why not text area elements? The HTML 5 spec says: The textarea element represents a multiline plain text edit control for the element's raw value.. It might make some sense to include support for pattern validation on text areas. On the other hand, text areas could be a lot larger than standard text inputs. (There's no maxlength attribute for text areas in HTML 4.01, but there is in HTML 5.) I did a quick search on the mailing list, and I didn't see any indication this issue had been raised before. Alex -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
Re: [whatwg] Text areas with pattern attributes?
Alex Vincent wrote: I'm drifting into writing code for the pattern attribute on text fields again, and I wondered: if text inputs can have pattern attribute for regular expression matching, why not text area elements? What's the use-case for it? Textareas are almost always for such large amounts of input that they are almost always free-form text. Why allow the pattern attribute? -- Geoffrey Sneddon — Opera Software http://gsnedders.com/ http://www.opera.com/
Re: [whatwg] Text areas with pattern attributes?
On Wed, Aug 19, 2009 at 11:32 AM, Geoffrey Sneddongsned...@opera.com wrote: What's the use-case for it? Textareas are almost always for such large amounts of input that they are almost always free-form text. Why allow the pattern attribute? You could impose a minimum character length for posts -- that's common on forums. Or ban certain words or phrases. As always, presumably you'd have server-side enforcement too.
Re: [whatwg] Global Script proposal.
On Wed, Aug 19, 2009 at 10:48 AM, Dmitry Titov dim...@google.com wrote:
On Wed, Aug 19, 2009 at 7:37 AM, Patrick Mueller
pmue...@muellerware.orgwrote:
var context = new GlobalScript(); // perhaps 'webkitGlobalScript' as
experimental feature?
context.onload = function () {...}
context.onerror = function () {...}
context.load('foo.js');
Presumably this script is being loaded asynchronously, hence the
callbacks. But since the GlobalScript() constructor returns the global
object, probably doesn't make sense to attach the handlers directly there,
but actually on the load request somehow.
Good point. Alternative variant to construction/connection to this object
could be something like this:
window.createGlobalScript('name', 'foo.js', function(context) {..},
function(status) {..});
where the name and url pair play the same role as on SharedWorker, and 2
callbacks: one delivers load status/errors, another comes with resolved
context when it's ready. One benefit of this is that 'context' does not have
to expose the 'external' API on it and it is always functional once it's
returned. The syntax in the proposal was motivated by commonality with other
APIs, like XHR or window.open - however I agree this doesn't fit 100% either
of them...
fyi: There's a seperate thread questioning the utility of the 'name'
parameter in the SharedWorker API. However the debate ends, it would
probably be good to identify shared-workers / global-scripts in a similar
fashion.
I guess I'm wondering if there will be some desire to have pages opt-in to
this support, signaling this through an additional API, or like the
app-cache's manifest attribute on the html element, something in the DOM;
doesn't seem like we should drag the DOM in here, just mentioned it because
I was reminded of the way the opt-in works there.
I don't follow the opt-in desirement? If a page wishes to utilize the
GlobalScript feature, it calls the API provided to do so.
It is a good idea indeed to have some sort of static opt-in information,
maybe via a feature of app-cache - which could hint the UA to load
participating pages (of the same application) into the same process so they
could share Global Script. It is still impossible (and probably not
important) to guarantee a singularity of the Global Script (as in case of
cross-domain iframes) but it'd be a good optimization for a multi-process
UA.
I understand the desire for early warning that a page *may* want to utilized
a GlobalScript. A 'hint' could be useful to a multi-process UA. It's not
clear to me that this is what Patrick was referring to... Patrick?
And I'll just throw out there that a 'hint' in an custom HTTP header of the
page's response would be the earliest warning we could get without static
config info present in the UA. I know Ian doesn't like relying on
out-of-band HTTP things for the HTML5 spec... just sayin...
Dmitry
Re: [whatwg] SharedWorkers and the name parameter
On Tue, Aug 18, 2009 at 8:26 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 18, 2009 at 7:53 PM, Drew Wilsonatwil...@google.com wrote: An alternative would be to make the name parameter optional, where omitting the name would create an unnamed worker that is identified/shared only by its url. So pages would only specify the name in cases where they actually want to have multiple instances of a shared worker. -atw This seems like a very good idea. Makes a lot of sense that if two shared workers have the same uri, you are probably going to interact with it the same way everywhere. Only in less common cases do you need to instantiate different workers for the same url, in which case you can use the name parameter. This sounds reasonable to me. / Jonas
Re: [whatwg] Text areas with pattern attributes?
On Wed, Aug 19, 2009 at 8:32 AM, Geoffrey Sneddongsned...@opera.com wrote: Alex Vincent wrote: I'm drifting into writing code for the pattern attribute on text fields again, and I wondered: if text inputs can have pattern attribute for regular expression matching, why not text area elements? What's the use-case for it? Textareas are almost always for such large amounts of input that they are almost always free-form text. Why allow the pattern attribute? A similar argument was made against putting the placeholder attribute on textarea, until someone found a page where it was used. I think in general it makes very little sense to say that textareas are different from input type=text. Technically the only difference is that one is multiline and the other is not. So it seems like anything that makes sense in input type=text makes sense in textarea. So for the pattern attribute, a use case would be on a site that accepts US addresses (for example a store that only ships within the US), the site could use a textarea together with a pattern that matches US addresses. / Jonas
Re: [whatwg] Global Script proposal.
Patrick Mueller wrote: Or perhaps these GlobalScripts - should really be called GlobalObjects or GlobalContexts maybe; SharedScope? I like Shared as this is the term used in SharedWorkers to identify something that can be shared between multiple pages. SharedContext? Best regards Mike
Re: [whatwg] Text areas with pattern attributes?
2009/8/19 Jonas Sicking jo...@sicking.cc: So for the pattern attribute, a use case would be on a site that accepts US addresses (for example a store that only ships within the US), the site could use a textarea together with a pattern that matches US addresses. That would be a most unusual scenario IMO: I've never encountered such a format. Postal addresses are usually quite structured, I guess nobody would impose a pattern on a single giant address (textarea), instead multiple form elements (input) could be used together to compose a postal address, even to provide a finer grain check on user's data. My two cents. -- Bye, Michelangelo
Re: [whatwg] Text areas with pattern attributes?
On Wed, Aug 19, 2009 at 2:38 PM, Jonas Sickingjo...@sicking.cc wrote: So for the pattern attribute, a use case would be on a site that accepts US addresses (for example a store that only ships within the US), the site could use a textarea together with a pattern that matches US addresses. It's also pretty common to enter multiple email addresses or tracking numbers or URLs one-per-line for batch operations on sites, and they would benefit from having client-side validation of such patterns. Mike
Re: [whatwg] Global Script proposal.
Michael Nordman wrote: I understand the desire for early warning that a page *may* want to utilized a GlobalScript. A 'hint' could be useful to a multi-process UA. It's not clear to me that this is what Patrick was referring to... Patrick? I wasn't thinking as a hint for the browser, but that's of course a good idea. I was thinking security. Are there cases where I specifically would NOT want to share? If so, the only alternative is to guarantee that no code you ever load will ever try. It would be safer to allow an author to indicate this page must not be shared. Guess that's more of an opt-out. And I don't have a use case for I don't want to share, nor could I claim that even if they didn't want to, it would be unsafe if they did anyway (ie, it might be safe even if they didn't want to share). Just thinking aloud. -- Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal.
Dmitry Titov wrote: The return value from a constructor is the Global Script's global scope object. It can be used to directly access functions and variables defined in global scope of the Global Script. While this global scope does not have 'window' or 'document' and does not have visual page associated with it, the local storage, database, timers and XHR are exposed to it, and it can build up DOM for the connected pages using their 'document' object. This turns out to be fairly similar to the serverJS concept of modules. I could see how you might want to use it this way, to get script code loaded into it's own sandbox, and allow the client of the module to name the object as they see fit. This would require the use of a name when you create it, so as to allow multiple to be created, and to allow other sharers to find those objects. This also allows folks to programmatically load JS code without having to resort to XHR/eval or adding script nodes to the DOM. Big plus, because those scripts will then be associated with an honest-to-gods name, which will show up in debuggers. And is obviously cleaner than the other techniques. The list of interfaces exposed in the global scope of the Global Script is similar to that of Shared Worker, except message-passing interface. It could also include events fired when a page connects/disconnects to it and before it is terminated. Can I create additional GlobalScript's from within an existing GlobalScript? The load() method is very similar to the worker loadScript() (or whatever) function. Perhaps we should combine them into one API, that allows sync or async in a worker, but only allows async in a GlobalScript. Or at least advises against use of sync. -- Patrick Mueller - http://muellerware.org
[whatwg] Web Encodings
Today every browser implements their own encoding label matching algorithm, supports their own list of encodings, their own list of encoding label aliases, and everything sort of works, but not really. HTML5 solves part of this problem by defining exactly how to identify an encoding label alias in a text/html stream. It also defines which encoding label matching algorithm to use, UTS22, but we found out that this is incompatible with (existing) sites that specify EUC_JP at the HTTP level and actually want to be decoded per UTF-8 according to a meta in the text/html stream. This works fine if you have a strict encoding label matching algorithm, but with UTS22, EUC_JP and EUC-JP become the same thing, while only the latter is the actual encoding label. Another problem HTML5 does not solve is giving a definitive list of encodings clients have to implement to be compatible with a large body of Web content. This means new clients will have to reverse engineer that list from existing clients which I think is bad. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Global Script proposal.
On Wed, Aug 19, 2009 at 1:34 PM, Patrick Mueller pmue...@muellerware.orgwrote: Dmitry Titov wrote: The return value from a constructor is the Global Script's global scope object. It can be used to directly access functions and variables defined in global scope of the Global Script. While this global scope does not have 'window' or 'document' and does not have visual page associated with it, the local storage, database, timers and XHR are exposed to it, and it can build up DOM for the connected pages using their 'document' object. This turns out to be fairly similar to the serverJS concept of modules. I could see how you might want to use it this way, to get script code loaded into it's own sandbox, and allow the client of the module to name the object as they see fit. This would require the use of a name when you create it, so as to allow multiple to be created, and to allow other sharers to find those objects. This also allows folks to programmatically load JS code without having to resort to XHR/eval or adding script nodes to the DOM. Big plus, because those scripts will then be associated with an honest-to-gods name, which will show up in debuggers. And is obviously cleaner than the other techniques. The list of interfaces exposed in the global scope of the Global Script is similar to that of Shared Worker, except message-passing interface. It could also include events fired when a page connects/disconnects to it and before it is terminated. Can I create additional GlobalScript's from within an existing GlobalScript? That's a good question... (just having fun... oh the tangled web we weave;) I'm not sure any has thought thru the implications of that, but it's an interesting idea. * An obvious complication is life-cycle management. If GlobalScriptA attaches to GlobalScriptB, when no 'pages' are attached to either, they should be eligible for destruction. * Also about tangled webs... what if A attaches to B, and B attaches to A The load() method is very similar to the worker loadScript() (or whatever) function. Perhaps we should combine them into one API, that allows sync or async in a worker, but only allows async in a GlobalScript. Or at least advises against use of sync. -- Patrick Mueller - http://muellerware.org
Re: [whatwg] Web Encodings
On Wed, 19 Aug 2009 22:47:57 +0200, Anne van Kesteren ann...@opera.com wrote: Today every browser implements their own encoding label matching algorithm, supports their own list of encodings, their own list of encoding label aliases, and everything sort of works, but not really. HTML5 solves part of this problem by defining exactly how to identify an encoding label alias in a text/html stream. It also defines which encoding label matching algorithm to use, UTS22, but we found out that this is incompatible with (existing) sites that specify EUC_JP at the HTTP level and actually want to be decoded per UTF-8 according to a meta in the text/html stream. This works fine if you have a strict encoding label matching algorithm, but with UTS22, EUC_JP and EUC-JP become the same thing, while only the latter is the actual encoding label. Another problem HTML5 does not solve is giving a definitive list of encodings clients have to implement to be compatible with a large body of Web content. This means new clients will have to reverse engineer that list from existing clients which I think is bad. To continue, I'd like to request help with documenting which encodings and encoding label aliases and matching rules are supported by each browser so we can figure out what the rules should be. So far I have documented what Opera supports here: http://wiki.whatwg.org/wiki/Web_Encodings I've also done research into the matching algorithm here: http://dump.testsuite.org/2009/encoding-matching/ So far I found that Internet Explorer and Firefox are the most strict when it comes to matching and most compatible with deployed content (not entirely unexpected). So it's very likely that a final document describing the algorithm should be based on these browsers. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] FYI: How to write a spec document.
I just ran into a short but sweet document that I found helpful but that I had never seen mentioned on this list: http://wiki.whatwg.org/wiki/How_to_write_a_spec I figured there was enough of a chance that someone else would find it helpful or others would have information to contribute that it was worth mentioning here. That's all. :-) J
Re: [whatwg] Proposed changes to the History API
On Tue, Aug 18, 2009 at 5:04 PM, Justin Lebar justin.le...@gmail.comwrote: I'm in the process of implementing the HTML5 History API (History.pushState(), History.clearState(), and the PopState event) in Firefox. I'd like to discuss whether the API might benefit from some changes. To my knowledge, no other browser implements this API, so I'm assuming we have freedom to make large alterations to it. My basic proposal is that History.pushState() be split into a function for creating new history entries and functions or a property for getting/setting an object associated with that entry. In its current form, the History API allows us to identify session history entries by way of an arbitrary object, which we pass as the first argument to pushState() and which we receive as part of the PopState event when that history entry is activated. If the page gets a null popstate, it's supposed to use the URL to decide what state to display. Notably unsupported by this API is support for pages altering their saved state. For instance, a page might want to save a text box's edit history to implement a fancy undo. It could store the edit history in a cookie or in the session storage, but then if we loaded the page twice in the same tab, those two instances would step on each other when we went back and forth between them. The page could just store its state in variables in the document, but then it would loose that state when the browser crashed or was closed, or when the browser decided to kick the document out of the history. I think this page would be better served by a History.setStateObject() function, which does exactly what the page wants in a simple fashion. We'd still keep the history-entry-creating functionality of History.pushState() in a new History function (I'll call it createNewEntry(), but it probably needs a better name), which takes a title and URL, as pushState() does now. The API might be more intuitive if we had a History.stateObject propery, but I'm concerned that then we'd be promising the page that we'll keep around literally any objects it wants, including DOM objects. In fact, I'd be happy restricting the state object to being a string. If a page wants to store an object, it can convert it to JSON, or it can store a GUID as its state string and index into the session storage. I really like this idea except for this one part: What's the problem with allowing DOM objects to be stored? Even if it can't be open-ended, maybe we can allow any data that can be serialized to be stored there? Just from my playing around with local storage, I've found the requirement of serializing everything to a string fairly annoying. I understand why it's necessary there (even with session storage, there are use cases where you'd need to serialize it to disk) but here it seems like everything can just stay in memory...right? Btw, storing a GUID and using session storage really isn't useful since session storage itself only stores strings. Pages could retrieve the state object just as they do now, in a PopState event, although we'd probably want to change the name of the event. We'd probably want to fire PopState on all loads and history navigations, since any document might have a state to pop, and even those documents which didn't call setStateObject() might store state in their URI which they need to restore when their history entry is activated. Last, I'm not sure that we need the History.clearState() function. It's confusing (why do we end up at the last entry for the current document instead of staying at the current entry?) and I haven't been able to come up with a compelling use case. I think the main benefit of these changes is added simplicity. There's a right and wrong way to use pushState, and setState/createNewEntry doesn't require such rules. But additionally, these changes allow pages flexibility to do things we haven't yet thought of. I don't know what those things might be, but I suspect they may be pretty cool. :) -Justin
Re: [whatwg] Proposed changes to the History API
On Tue, Aug 18, 2009 at 5:04 PM, Justin Lebarjustin.le...@gmail.com wrote: I'm in the process of implementing the HTML5 History API (History.pushState(), History.clearState(), and the PopState event) in Firefox. I'd like to discuss whether the API might benefit from some changes. To my knowledge, no other browser implements this API, so I'm assuming we have freedom to make large alterations to it. My basic proposal is that History.pushState() be split into a function for creating new history entries and functions or a property for getting/setting an object associated with that entry. In its current form, the History API allows us to identify session history entries by way of an arbitrary object, which we pass as the first argument to pushState() and which we receive as part of the PopState event when that history entry is activated. If the page gets a null popstate, it's supposed to use the URL to decide what state to display. Notably unsupported by this API is support for pages altering their saved state. For instance, a page might want to save a text box's edit history to implement a fancy undo. It could store the edit history in a cookie or in the session storage, but then if we loaded the page twice in the same tab, those two instances would step on each other when we went back and forth between them. The page could just store its state in variables in the document, but then it would loose that state when the browser crashed or was closed, or when the browser decided to kick the document out of the history. I think this page would be better served by a History.setStateObject() function, which does exactly what the page wants in a simple fashion. We'd still keep the history-entry-creating functionality of History.pushState() in a new History function (I'll call it createNewEntry(), but it probably needs a better name), which takes a title and URL, as pushState() does now. The API might be more intuitive if we had a History.stateObject propery, but I'm concerned that then we'd be promising the page that we'll keep around literally any objects it wants, including DOM objects. In fact, I'd be happy restricting the state object to being a string. If a page wants to store an object, it can convert it to JSON, or it can store a GUID as its state string and index into the session storage. Pages could retrieve the state object just as they do now, in a PopState event, although we'd probably want to change the name of the event. We'd probably want to fire PopState on all loads and history navigations, since any document might have a state to pop, and even those documents which didn't call setStateObject() might store state in their URI which they need to restore when their history entry is activated. Last, I'm not sure that we need the History.clearState() function. It's confusing (why do we end up at the last entry for the current document instead of staying at the current entry?) and I haven't been able to come up with a compelling use case. I think the main benefit of these changes is added simplicity. There's a right and wrong way to use pushState, and setState/createNewEntry doesn't require such rules. But additionally, these changes allow pages flexibility to do things we haven't yet thought of. I don't know what those things might be, but I suspect they may be pretty cool. :) I agree with Justin (unsurprisingly since we've been doing a fair amount of discussing on the subject). In general when I've been thinking about how to use this API i've had a hard time wrapping my head around the intended way to use it. It wasn't until I started thinking of it in the following way that it made sense: There's two aspects to the API: 1. The ability navigate the user to a new URI without forcing the UA to load a new page. So for example instead of using fragment-identifier hacks, actually change the uri. So for example gmail uses URIs like: https://mail.google.com/mail/?#inbox https://mail.google.com/mail/?#label/personal https://mail.google.com/mail/?#label/whatwg https://mail.google.com/mail/?#label/whatwg/13b4711edac9c1e2 it would be better if you could actually navigate between https://mail.google.com/mail/inbox https://mail.google.com/mail/label/personal https://mail.google.com/mail/label/whatwg https://mail.google.com/mail/label/whatwg/13b4711edac9c1e2 and then use the fragment identifier for what it was intended. 2. The ability to create several session history entries for the same page which the user can navigate between, and use some type of state object to disambiguate between these states. For example in our bug database we allow users to look at attachments, as well as comment on attachments. When starting to comment on an attachment the page changes from displaying the attachment, to displaying a textarea pre-populated with the contents of the attachment such that you can add comments to it. It would be nice
[whatwg] Web Socket Default Ports Confusing?
Hi, as per http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-35 , in web socket handshake, a client omits the port number if it is 80/443 while a server omits it if it is 81/815. Isn't this confusing? I guess the client side behavior mimics HTTP and hence hard to be changed. How about changing the server side behavior such that port number is always explicitly stated regardless of the value? (Behavior is still inconsistent but less confusing, IMHO.) 4. Client-side requirements 4.1. Handshake 6. Send the following bytes: 48 6f 73 74 3a 20 Send the /host/ value, converted to ASCII lowercase, and encoded as US-ASCII. If /secure/ is false, and /port/ is not 80, or if /secure/ is true, and /port/ is not 443, then send an 0x3a byte (:) followed by the value of /port/, expressed as a base-ten integer, encoded as US-ASCII. ... 5. Server-side requirements 5.1. Minimal handshake NOTE: Do not include the port if it is the default port for Web Socket protocol connections of the type in question (81 for unencrypted connections and 815 for encrypted connections). Yuzo
Re: [whatwg] Global Script proposal.
Michael Nordman wrote:
On Wed, Aug 19, 2009 at 1:34 PM, Patrick Mueller pmue...@muellerware.orgwrote:
Can I create additional GlobalScript's from within an existing
GlobalScript?
That's a good question...
(just having fun... oh the tangled web we weave;)
I'm not sure any has thought thru the implications of that, but it's an
interesting idea.
* An obvious complication is life-cycle management. If GlobalScriptA
attaches to GlobalScriptB, when no 'pages' are attached to either, they
should be eligible for destruction.
* Also about tangled webs... what if A attaches to B, and B attaches to A
For completeness, folks interested in this proposal should probably
check out the serverJS Securable Module stuff:
https://wiki.mozilla.org/ServerJS/Modules/SecurableModules
There are similarities, and differences:
- In serverJS, modules are identified with a JavaScript resource,
presumably a single one. In Shared Scopes (what I'm going to call
Global Script from here on in), modules are identified with just a name
and code is loaded through a different path. I like the Shared Scopes
version better, more flexible.
- In serverJS, module loading may need to be done in a careful order so
that pre-req modules are loaded before the modules that pre-req them
(ie, require() them). That's because there is code running while the
module is being defined. If we end up having all the shared scopes
available via their name in every shared scope and page that are
attached to each other, I don't think there's a problem. Creating a new
scope is atomic operation, no user-land code runs as a result. No doubt
folks will be writing guarded code to ensure they only load scripts into
a SharedScope once, since the code loading is now a separate issue.
Again, I like the Shared Scopes approach better.
- In serverJS, a module does not export it's global variable to the
client. Instead, when the module code is run, the object which will
eventually be returned from require() is set to the variable exports
in the module code. In Shared Scopes, this additional level of
indirection is not available; global variables set in code run in the
context of the SharedScope are the properties of the object returned
from the SharedScope accessor. In this case, I prefer the serverJS
style. It makes it clear in the module code what you actually want the
client to have access to. It also lets you hide private variables
inside your own global environment, which is visible to no one. The
same way variables are typically hidden in a function closure today.
Imagine, maybe you won't have da funky function wrappers anymore!
(function(){
... my code here
})();
The load() method is very similar to the worker loadScript() (or whatever)
function. Perhaps we should combine them into one API, that allows sync or
async in a worker, but only allows async in a GlobalScript. Or at least
advises against use of sync.
I think the API I was thinking of with workers is
importScripts(url,url,urls). It seems crazy to have different ways to
do basically the same thing, whether you're in a worker or not. There
should probably be one API to load and run a script, that could be
used sync or async (user controlled just like XHR), with callbacks etc.
Time to work on some examples. This would relatively easy to prototype
in something like Rhino (or my nitro_pie python wrapper for
JavaScriptCore), at least API wise, so we could see what the user-land
code would look like, and see it run.
--
Patrick Mueller - http://muellerware.org
