Re: Model-driven Views
On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: What do you think? - Is this something you'd like to be implemented in the browsers, Yes. and if yes, why? What would be the reasons to not just use script libraries (like your prototype). FAQ item also coming for this. Having heard Rafael's spiel for this previously, I believe there are some things that templating engines want to do, which are hard to do efficiently and conveniently using the existing Web platform. However, I think it would be better to add primitives to the Web platform that could be used by the many templating libraries that already exist, at least as a first step: - There is a lot of code built using many of the existing templating solutions. If we provide primitives that let those libraries become more efficient, that is a greater immediate payoff than creating a new templating system, where Web apps would have to be rewritten to take advantage. - It seems somewhat hubristic to assume that a newly invented templating library is so superior to all the already existing solutions that we should encode its particular design choices into the Web platform immediately. - This new templating library doesn't have enough real apps built on it yet to know if it is a good solution to author problems. - Creating APIs is best done incrementally. API is forever, on the Web. - Looking at the history of querySelector(), I come to the following conclusion: when there are already a lot of library-based solutions to a problem, the best approach is to provide technology that can be used inside those libraries to improve them; this is more valuable than creating an API with a primary goal of direct use. querySelector gets used a lot more via popular JavaScript libraries than directly, and should have paid more attention to that use case in the first place. Perhaps there are novel arguments that will dissuade me from this line of thinking, but these are my tentative thoughts. Regards, Maciej
Re: Model-driven Views
On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: What do you think? - Is this something you'd like to be implemented in the browsers, Yes. and if yes, why? What would be the reasons to not just use script libraries (like your prototype). FAQ item also coming for this. Having heard Rafael's spiel for this previously, I believe there are some things that templating engines want to do, which are hard to do efficiently and conveniently using the existing Web platform. However, I think it would be better to add primitives to the Web platform that could be used by the many templating libraries that already exist, at least as a first step: - There is a lot of code built using many of the existing templating solutions. If we provide primitives that let those libraries become more efficient, that is a greater immediate payoff than creating a new templating system, where Web apps would have to be rewritten to take advantage. - It seems somewhat hubristic to assume that a newly invented templating library is so superior to all the already existing solutions that we should encode its particular design choices into the Web platform immediately. - This new templating library doesn't have enough real apps built on it yet to know if it is a good solution to author problems. - Creating APIs is best done incrementally. API is forever, on the Web. - Looking at the history of querySelector(), I come to the following conclusion: when there are already a lot of library-based solutions to a problem, the best approach is to provide technology that can be used inside those libraries to improve them; this is more valuable than creating an API with a primary goal of direct use. querySelector gets used a lot more via popular JavaScript libraries than directly, and should have paid more attention to that use case in the first place. Perhaps there are novel arguments that will dissuade me from this line of thinking, but these are my tentative thoughts. I agree with much of this. However it's hard to judge without a bit more meat on it. Do you have any ideas for what such primitives would look like? / Jonas
Re: Model-driven Views
On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote: On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: What do you think? - Is this something you'd like to be implemented in the browsers, Yes. and if yes, why? What would be the reasons to not just use script libraries (like your prototype). FAQ item also coming for this. Having heard Rafael's spiel for this previously, I believe there are some things that templating engines want to do, which are hard to do efficiently and conveniently using the existing Web platform. However, I think it would be better to add primitives to the Web platform that could be used by the many templating libraries that already exist, at least as a first step: - There is a lot of code built using many of the existing templating solutions. If we provide primitives that let those libraries become more efficient, that is a greater immediate payoff than creating a new templating system, where Web apps would have to be rewritten to take advantage. - It seems somewhat hubristic to assume that a newly invented templating library is so superior to all the already existing solutions that we should encode its particular design choices into the Web platform immediately. - This new templating library doesn't have enough real apps built on it yet to know if it is a good solution to author problems. - Creating APIs is best done incrementally. API is forever, on the Web. - Looking at the history of querySelector(), I come to the following conclusion: when there are already a lot of library-based solutions to a problem, the best approach is to provide technology that can be used inside those libraries to improve them; this is more valuable than creating an API with a primary goal of direct use. querySelector gets used a lot more via popular JavaScript libraries than directly, and should have paid more attention to that use case in the first place. Perhaps there are novel arguments that will dissuade me from this line of thinking, but these are my tentative thoughts. I agree with much of this. However it's hard to judge without a bit more meat on it. Do you have any ideas for what such primitives would look like? That's best discussed in the context of Rafael explaining what limitations prevent his proposal from working as well as it could purely as a JS library. The one specific thing I recall from a previous discussion of this proposal is that a way is needed to have a section of the DOM that is inactive - doesn't execute scripts, load anything, play media, etc - so that your template pattern can form a DOM but does not have side effects until the template is instantiated. This specific concept has already been discussed on the list, and it seems like it would be very much reusable for other DOM-based templating systems, if it wasn't tied to a specific model of template instantiation and updates. Regards, Maciej
Re: [widgets] Widget Updates tests?
Scott Wilson wrote: Right, I've done some basic work on the tests in Apache Wookie - most of them seem to work OK so far; I need to do interactive testing next - I've tested processing the update element in config.xml and acquiring and validating the UDD, but not actually processing the updates. However there are some issues I've found so far: Test ta-preparation1-8 This fails to parse as a valid widget as the XML isn't well-formed Test ta-processing2-3 I get a content type of text/html when getting the UDD Test ta-processing2-7 I get an error of the UDD XML not being well-formed Test ta-processing2-9 I get a content type of text/html when getting the UDD All the above tests have been fixed. Test ta-processing2-16 We throw a UDD parse exception when a UDD has a relative URL for the src attribute, but the test seems to assume you just silently fail to update the widget? The processing in this case was underspecified in the spec. I've updated the specification to allow for relative URLs to be included in the 'src' attribute. The resolution system for relative URL src attributes to absolute valid IRIs has also been included in the spec (i.e. resolve relative URLs relative to the UDDs IRI). Relative URLs are not allowed in the update-description element of a widget's config.xml. We've therefore replaced ta-processing2-16 test with a test to check that the resolution of src attribute relative URLs is working correctly. Test ta-processing2-19 I get a content type of text/html when getting the UDD Test ta-processing2-20 I get a content type of text/html when getting the UDD These tests have been fixed. HTH, Rich
Re: Model-driven Views
On 04/28/2011 12:02 PM, Maciej Stachowiak wrote: On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: What do you think? - Is this something you'd like to be implemented in the browsers, Yes. and if yes, why? What would be the reasons to not just use script libraries (like your prototype). FAQ item also coming for this. Having heard Rafael's spiel for this previously, I believe there are some things that templating engines want to do, which are hard to do efficiently and conveniently using the existing Web platform. However, I think it would be better to add primitives to the Web platform that could be used by the many templating libraries that already exist, at least as a first step: - There is a lot of code built using many of the existing templating solutions. If we provide primitives that let those libraries become more efficient, that is a greater immediate payoff than creating a new templating system, where Web apps would have to be rewritten to take advantage. - It seems somewhat hubristic to assume that a newly invented templating library is so superior to all the already existing solutions that we should encode its particular design choices into the Web platform immediately. - This new templating library doesn't have enough real apps built on it yet to know if it is a good solution to author problems. - Creating APIs is best done incrementally. API is forever, on the Web. - Looking at the history of querySelector(), I come to the following conclusion: when there are already a lot of library-based solutions to a problem, the best approach is to provide technology that can be used inside those libraries to improve them; this is more valuable than creating an API with a primary goal of direct use. querySelector gets used a lot more via popular JavaScript libraries than directly, and should have paid more attention to that use case in the first place. Perhaps there are novel arguments that will dissuade me from this line of thinking, but these are my tentative thoughts. I agree with you; better to add primitives which allow creating script libraries. -Olli Regards, Maciej
Re: Model-driven Views
On Tue, Apr 26, 2011 at 7:32 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Apr 25, 2011 at 9:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/22/11 8:35 PM, Rafael Weinstein wrote: Myself and a few other chromium folks have been working on a design for a formalized separation between View and Model in the browser, with needs of web applications being the primary motivator. Our ideas are implemented as an experimental Javascript library: https://code.google.com/p/mdv/ and the basic design is described here: http://mdv.googlecode.com/svn/trunk/docs/design_intro.html. The interesting thing to me is that the DOM is what's meant to be the model originally, as far as I can tell, with the CSS presentation being the view I guess we ended up with too much view leakage through the model so we're adding another layer of model, eh? There's always multiple layers of model in any non-trivial system. ^_^ In this case, the original DOM as model is valid in the sense of the page as a more-or-less static document, where it's the canonical source of information. With an app, though, the data canonically lives in Javascript, with the DOM being relegated to being used to display the data and allow user interaction. MDV is one possibility for making this relationship cleaner and simpler. Right. DOM-as-model works here in the sense that if you consider existing DOM elements to be participants in a hidden (un-exposed, non-extensible) model, then this is simply a way of using the DOM hierarchy to make that other model axis available, extensible, and pluggable. MDV still needs a little help in the areas where existing HTML is strongest as a model (relationship to forms, etc.), but it's already close enough that the value properties of form elements make sense when bound. Teasing out how conjoined things have become in HTML/DOM has been difficult so far, not least of all because DOM fails to make clear how attributes, properties, and serialization are meant to behave WRT the model of some chunk of markup/DOM. Regards
Re: Model-driven Views
On Thu, Apr 28, 2011 at 12:09 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote: On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: What do you think? - Is this something you'd like to be implemented in the browsers, Yes. and if yes, why? What would be the reasons to not just use script libraries (like your prototype). FAQ item also coming for this. Having heard Rafael's spiel for this previously, I believe there are some things that templating engines want to do, which are hard to do efficiently and conveniently using the existing Web platform. However, I think it would be better to add primitives to the Web platform that could be used by the many templating libraries that already exist, at least as a first step: - There is a lot of code built using many of the existing templating solutions. If we provide primitives that let those libraries become more efficient, that is a greater immediate payoff than creating a new templating system, where Web apps would have to be rewritten to take advantage. - It seems somewhat hubristic to assume that a newly invented templating library is so superior to all the already existing solutions that we should encode its particular design choices into the Web platform immediately. - This new templating library doesn't have enough real apps built on it yet to know if it is a good solution to author problems. - Creating APIs is best done incrementally. API is forever, on the Web. - Looking at the history of querySelector(), I come to the following conclusion: when there are already a lot of library-based solutions to a problem, the best approach is to provide technology that can be used inside those libraries to improve them; this is more valuable than creating an API with a primary goal of direct use. querySelector gets used a lot more via popular JavaScript libraries than directly, and should have paid more attention to that use case in the first place. Perhaps there are novel arguments that will dissuade me from this line of thinking, but these are my tentative thoughts. I agree with much of this. However it's hard to judge without a bit more meat on it. Do you have any ideas for what such primitives would look like? That's best discussed in the context of Rafael explaining what limitations prevent his proposal from working as well as it could purely as a JS library. The goal for this work is explicitly *not* to leave things to libraries -- I'd like for that not to creep into the discussion as an assumption or a pre-req. Libraries are expensive, slow, and lead to a tower-of-babel problem. On the other hand, good layering and the ability to explain current behavior in terms of fewer, smaller primitives is desirable, if only to allow libraries to play whatever role they need to when the high-level MDV system doesn't meet some particular need. The one specific thing I recall from a previous discussion of this proposal is that a way is needed to have a section of the DOM that is inactive - doesn't execute scripts, load anything, play media, etc - so that your template pattern can form a DOM but does not have side effects until the template is instantiated. Right. The contents of the template element are in that inactive state. This specific concept has already been discussed on the list, and it seems like it would be very much reusable for other DOM-based templating systems, if it wasn't tied to a specific model of template instantiation and updates. Having it be a separately addressable primitive sounds like a good thing...perhaps as some new Element type?
Re: [widgets] Widget Updates tests?
On 28 Apr 2011, at 12:19, Rich Tibbett wrote: Scott Wilson wrote: Right, I've done some basic work on the tests in Apache Wookie - most of them seem to work OK so far; I need to do interactive testing next - I've tested processing the update element in config.xml and acquiring and validating the UDD, but not actually processing the updates. However there are some issues I've found so far: Test ta-preparation1-8 This fails to parse as a valid widget as the XML isn't well-formed Test ta-processing2-3 I get a content type of text/html when getting the UDD Test ta-processing2-7 I get an error of the UDD XML not being well-formed Test ta-processing2-9 I get a content type of text/html when getting the UDD All the above tests have been fixed. Great, thanks! Test ta-processing2-16 We throw a UDD parse exception when a UDD has a relative URL for the src attribute, but the test seems to assume you just silently fail to update the widget? The processing in this case was underspecified in the spec. I've updated the specification to allow for relative URLs to be included in the 'src' attribute. The resolution system for relative URL src attributes to absolute valid IRIs has also been included in the spec (i.e. resolve relative URLs relative to the UDDs IRI). Relative URLs are not allowed in the update-description element of a widget's config.xml. We've therefore replaced ta-processing2-16 test with a test to check that the resolution of src attribute relative URLs is working correctly. Makes sense. Test ta-processing2-19 I get a content type of text/html when getting the UDD Test ta-processing2-20 I get a content type of text/html when getting the UDD These tests have been fixed. HTH, Rich Its a big help, thanks. One more thing, the widget at: http://people.opera.com/harig/wupdres/resources/pass.wgt ... isn't valid as its not well formed - there should be ? at end of line 1. S
Re: Model-driven Views
On 04/28/2011 04:46 AM, Rafael Weinstein wrote: Would be good to know what are the use cases you had in mind. I'm never sure if I'm using the term use case correctly =-). Our primary motivator is the needs of web applications, And what are those needs? It is hard to judge the proposal if it is not known what kinds of problems it is trying to solve ;) -Olli
Re: [widgets] Widget Updates tests?
On Thu, 28 Apr 2011 14:57:20 +0200, Scott Wilson scott.bradley.wil...@gmail.com wrote: One more thing, the widget at: http://people.opera.com/harig/wupdres/resources/pass.wgt ... isn't valid as its not well formed - there should be ? at end of line 1. Fixed. -- Hari Kumar G Quality Assurance Opera Software
Re: [widgets] Widget Updates tests?
On 28 Apr 2011, at 14:11, Hari Kumar G wrote: On Thu, 28 Apr 2011 14:57:20 +0200, Scott Wilson scott.bradley.wil...@gmail.com wrote: ... One more thing, the widget at: http://people.opera.com/harig/wupdres/resources/pass.wgt ... isn't valid as its not well formed - there should be ? at end of line 1. Fixed. Fantastic - thanks. Just one more thing... Test ta-processing2-14, Tests that update-info element's src attribute need to be valid, else it is ignored. The widget is not updated or replaced. However, the value to fail with is fail.wgt which ought to be interpreted as a relative URL, in which case the expected result would be to turn this into: http://people.opera.com/harig/wupdres/resources/fail.wgt Which is valid. So, the test needs to have a different value to be an invalid src attribute. S -- Hari Kumar G Quality Assurance Opera Software
[eventsource] Processing comments from the 10-Mar-2011 LCWD
Hixie, All, April 21 was the comment deadline for the March 10 LCWD of the Server-Sent Events spec [SSE-LC]. Since that LC was published, I noted 1 set of comments and 1 new bug: * CfC: server-sent-events; 15-Apr-2011; Ian Clelland http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0247.html * Bug 12411 - in dispatch the event, step 3, looks like Otherwise is bogus and should be removed.; 3-Apr-2011; contribu...@whatwg.org http://www.w3.org/Bugs/Public/show_bug.cgi?id=12411 SSE Bugs 11835 and 11836 are in the Assigned and New states, respectively. These two bugs were mentioned in a pre-LC thread started on 12-Feb-2011. Hixie provided feedback [Hixie] and no one suggested addressing them before the LC was published. Some changeshave been made to the spec since the LC was published [SSE-ED] and they appear to all be minor non-normative editorial changes. The Process Document defines the requirements for processing LC comments [LC] and the WG's main requirement is to respond to all comments. No one has responded to Ian Clelland's comments and Bug-12411 is still in the New state with no responses since it was submitted. (Anne mentioned a test suite on Feb 25 [SSE-TS].) -ArtB [SSE-LC] http://www.w3.org/TR/2011/WD-eventsource-20110310/ [SSE-ED] http://dev.w3.org/cvsweb/html5/eventsource/Overview.html [SSE-TS] http://tc.labs.opera.com/apis/EventSource/ [LC] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call [Hixie] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0541.html
[workers] Processing comments from 10-Mar-2011 LCWD
Hixie, All, April 21 was the comment deadline for the March 10 LCWD of the Web Workers spec [WW-LC]. Since that LC was published, I noted 2 set of comments and 2 new bugs: * Adrian Bateman; 9-Mar-2011 http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0877.html * Travis Leithead; 20-Apr-2011 http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0269.html * Bug-12067; Jonas Sicking; 14-Feb-2011 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12067 * Bug-12340; Olli Pettay; 19-Mar-2011 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12340 Hixie - what normative changes have been made in the ED [WW-ED] (since the LC was published) that would affect an implementation based on the March 10 LC? The Process Document defines the requirements for processing LC comments [LC] and the WG's main requirement is to respond to all comments. It appears there is no agreed conclusion to the two comments nor to Bug-12067 and there were no responses to Bug-12340. -ArtB [WW-LC] http://www.w3.org/TR/2011/WD-workers-20110310/ [WW-ED] http://dev.w3.org/html5/workers/ [LC]http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
Re: [workers] Processing comments from 10-Mar-2011 LCWD
On Thu, 28 Apr 2011, Arthur Barstow wrote: Hixie - what normative changes have been made in the ED [WW-ED] (since the LC was published) that would affect an implementation based on the March 10 LC? No idea, I don't track changes at the level of individual W3C specs for these technologies. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[webstorage] Plan to address open Bugs?
All, What is the plan to address the following Web Storage bugs: 1. Bug-12111; spec for Storage object getItem(key) method does not match implementation behavior http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 2. Bug-12272; Improve section on DNS spoofing attacks to address user attacks http://www.w3.org/Bugs/Public/show_bug.cgi?id=12272 3. Bug-12090; It would be nice to have one Storage object that you could place wherever you want. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12090 Which of these must be addressed before the WG considers the spec LC-ready? Original Message Subject:Re: [webstorage] Moving Web Storage back to Last Call WD Date: Fri, 18 Feb 2011 00:19:51 +0900 From: ext Michael[tm] Smith m...@w3.org To: Ian Hickson i...@hixie.ch CC: Arthur Barstow art.bars...@nokia.com, Tab Atkins Jr. jackalm...@gmail.com, public-webapps public-webapps@w3.org Ian Hicksoni...@hixie.ch, 2011-02-14 10:13 +: On Sat, 12 Feb 2011, Arthur Barstow wrote: What high priority work must be done such that this spec is ready to be re-published as a new Last Call Working draft? Tab, do you know of anything that is blocking redoing an LC? (Personally I'm fine with it going to REC yesterday, so...) Bugzilla shows no open bugs for this spec I just now raised a new one: spec for Storage object getItem(key) method does not match implementation behavior http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 -- Michael[tm] Smith http://people.w3.org/mike
Re: [webstorage] Plan to address open Bugs?
On Thu, 28 Apr 2011, Arthur Barstow wrote: What is the plan to address the following Web Storage bugs: 1. Bug-12111; spec for Storage object getItem(key) method does not match implementation behavior http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 2. Bug-12272; Improve section on DNS spoofing attacks to address user attacks http://www.w3.org/Bugs/Public/show_bug.cgi?id=12272 3. Bug-12090; It would be nice to have one Storage object that you could place wherever you want. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12090 My plan is to address them in the order of they appear on this bug list: http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=long_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=exactemail1=ian%40hixie.chemailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Last+Changedfield0-0-0=nooptype0-0-0=noopvalue0-0-0= In recent weeks I've been focusing on multitrack video and video conferencing, but I have now returned to just going through feedback. A precise ETA depends mostly on how many interrupts I get dealing with politics in the HTML WG. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webstorage] Plan to address open Bugs?
Well, I guess the good news is that (at the time of this writing), there aren't 355 bugs ;). All - Inputs and proposals for these bugs are encouraged! On Apr/28/2011 2:33 PM, ext Ian Hickson wrote: On Thu, 28 Apr 2011, Arthur Barstow wrote: What is the plan to address the following Web Storage bugs: 1. Bug-12111; spec for Storage object getItem(key) method does not match implementation behavior http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 2. Bug-12272; Improve section on DNS spoofing attacks to address user attacks http://www.w3.org/Bugs/Public/show_bug.cgi?id=12272 3. Bug-12090; It would be nice to have one Storage object that you could place wherever you want. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12090 My plan is to address them in the order of they appear on this bug list: http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=long_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=exactemail1=ian%40hixie.chemailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Last+Changedfield0-0-0=nooptype0-0-0=noopvalue0-0-0= In recent weeks I've been focusing on multitrack video and video conferencing, but I have now returned to just going through feedback. A precise ETA depends mostly on how many interrupts I get dealing with politics in the HTML WG.
Server-Sent Event types
I am a newcomer to the Server-Sent Events spec, so my apologies if I am covering old ground. While I can understand that Server-Sent Events may be intending to start off simple, I wonder whether there is some reason a formal mechanism was not adopted to at least allow the specification of event types. I think such a convention would have a number of important benefits. Of course, one can already simulate event types: 1) One could exclusively alter the data itself to embed such types, but this pushes more responsibility for parsing the response data to the user (and will increase the amount of data needing to be transferred, both for the need to always respecify for each message the type in the data stream, as well as for the need of a particular client to receive all types of data even if it didn't register itself for receiving that type). And that parsing of types would not end up becoming familiarly uniform for users of libraries, and would not be conducive to extensibility; if someone wished to add new events later on, old client-side code might need to be rewritten. 2) One could instead simulate event types by supplying a different URL or a URL with different parameters, but with the disadvantage that multiple requests would presumably need to be established for each parameter combination--adding unnecessary connections and an inability to handle different types within the same response handler. Moreover, without a specific REST type of convention for event types, there again would be no familiarly uniform way to specify event types, preventing a clear and easy way to add new event types. It would seem to me that the specification could still be kept simple, while still offering safer and more convenient flexibility for the future, if something like the following were followed: 1) The EventSource object could be optionally supplied with a particular query string parameter (e.g., sse-type= or sse-types=) (if not also as a key-value object second argument). If no other types were added, the data stream itself would not need to encode type, although a type property could still be set on the event object (see below). This would allow a common convention, regularizing client-side and server-side library creation, and in the case where only a single type were specified, avoids the need for extra data to be added to the stream to indicate type. 2) For cases where the application did wish to share a connection for different types, an analogue to addEventListener could make it possible for the client to notify the server to add more types to the stream while reusing the same connection (though this would require some additional mechanism, such as a different REST parameter like add-sse-type= if not adding to a two-way stream). A type property could then be made available on the response event object to allow the user to be able to conveniently filter the types depending on the response and the state of the client application, without the need for hackish and non-uniform parsing of response data. 3) Custom event types should be indicated by some unique mechanism (e.g., requiring unrecognized types to be preceded by x-) so that if the specification were to be expanded upon in the future to support official protocols, they could do so without impacting existing code. However, when no type is supplied, this could also be assumed to be a custom event, but without any namespace. This would allow the specification to be backwards-compatible. It seems to me that the above suggestions would not add an undue amount of complexity (and avoid or postpone any commitment to defining specific event types), while also providing a better framework for manageable extensibility into the future. Best wishes, Brett
Server-Side Events encoded in JSON
user to parse the response text, why not simply allow each event to be a JSON-encoded object of some kind (boolean, number, string, array, object). Then the event.data could be an object which was already conveniently accessible to JavaScript consumers. Presumably server-side libraries would handle the work of doing the encoding, but the average client-side consumer should, in my opinion, not need to be concerned with implementation details, except to become familiar with the specific JSON response types being sent by the server-side code/library. Although this would add encoding responsibilities to the server and decoding responsibilities to the browser, I think it ought to avoid the need for the client code to be concerned with ugly implementation details such as the need to parse strings. A convention might also be used in the stream (e.g., error: followed by a JSON object) to trigger errors, allowing the normal responses to be simple strings or the like, while offering a means to distinguish them from error messages sent by the server (e.g., to indicate that a data source was no longer available). The event object could add an error property which could be checked (or, if types were allowed as per my previous post, it could set the event type to the reserved string error). Brett
Global variables and id lookup for elements
Hey folks, Context: http://krijnhoetmer.nl/irc-logs/whatwg/20110428#l-707 Current browsers disagree about how to handle div id=x/divscriptvar x;/script. Webkit browsers leave x pointing to the div, whereas IE, Firefox and Opera make x undefined [1]. (There is content that depends on x being undefined, but I don't have any links handy right now.) My reading of the relevant specs (es5 section 10, WebIDL 4.5.3, HTML 6.2.4) supports the Webkit behavior. To summarize, a property x is defined on the global object pointing to the element before the script block, and when the script block is parsed for variable declarations there's already an x defined and therefore the variable is not initialized to undefined. I therefore propose a spec change is in order. jgraham summarized the wanted behavior neatly as id lookup should happen after all other property resolution. Conceptually I think this is like saying that the global environment actually has an outer environment, and this outer environment contains the properties for element lookups (which are currently defined on the global object). Another proposal was to say that properties for element lookup are special and should get overwritten in 10.8.c. Other, better options may also exist. Open question: Should this be defined directly in HTML, or should WebIDL define it and let HTML annotate Window to enable the necessary exceptional behavior? My initial take was that since both id lookup and window=global is defined in HTML it would fit best there, but it also makes sense to contain finicky DOM-ES interactions to WebIDL. [1] http://code.google.com/p/chromium/issues/detail?id=80591 -- Magnus Kristiansen Don't worry; the Universe IS out to get you.
Re: Global variables and id lookup for elements
On 4/28/11 4:31 PM, Magnus Kristiansen wrote: Current browsers disagree about how to handle div id=x/divscriptvar x;/script. Webkit browsers leave x pointing to the div, whereas IE, Firefox and Opera make x undefined [1]. (There is content that depends on x being undefined, but I don't have any links handy right now.) My reading of the relevant specs (es5 section 10, WebIDL 4.5.3, HTML 6.2.4) supports the Webkit behavior. To summarize, a property x is defined on the global object pointing to the element before the script block, and when the script block is parsed for variable declarations there's already an x defined and therefore the variable is not initialized to undefined. I therefore propose a spec change is in order. I believe this is correct. For what it's worth, I discussed this with Cameron recently, and he felt that this is something that should just be defined as a one-off in the spec defining Window, not in WebIDL itself. That is, Window should not be using a name getter. jgraham summarized the wanted behavior neatly as id lookup should happen after all other property resolution. Conceptually I think this is like saying that the global environment actually has an outer environment, and this outer environment contains the properties for element lookups (which are currently defined on the global object). Another proposal was to say that properties for element lookup are special and should get overwritten in 10.8.c. Other, better options may also exist. For what it's worth, the way Gecko implements this is by inserting an object into the prototype chain of the Window that handles these property gets. This means that |var| (which defines a prop on the Window itself) will always shadow the named props, which is the behavior you observe. There's some complexity due to the fact that the properties should only exist on that prototype if they're not anywhere else on the proto chain, but that's already there in the non-OverrideBuiltins name getter case. Open question: Should this be defined directly in HTML, or should WebIDL define it and let HTML annotate Window to enable the necessary exceptional behavior? I think I agree with Cameron that it should be defined in HTML (or whatever spec defines Window). My initial take was that since both id lookup and window=global is defined in HTML it would fit best there, but it also makes sense to contain finicky DOM-ES interactions to WebIDL. Reusable ones, yes. I don't think anyone is proposing this behavior for any other object, so it wouldn't be reusable anyway. -Boris
Re: Global variables and id lookup for elements
Boris Zbarsky:
For what it's worth, the way Gecko implements this is by inserting
an object into the prototype chain of the Window that handles these
property gets. This means that |var| (which defines a prop on the
Window itself) will always shadow the named props, which is the
behavior you observe.
If we solve the problem in this way, with an extra object in the
prototype chain, then this could be defined in HTML without any special
prose.
[NoInterfaceObject]
interface WindowNames {
getter any (in DOMString name);
};
interface Window : WindowNames {
...
};
--
Cameron McCormack ≝ http://mcc.id.au/
Re: Server-Sent Event types
On Wed, Apr 27, 2011 at 11:26 PM, Brett Zamir bret...@gmail.com wrote: I am a newcomer to the Server-Sent Events spec, so my apologies if I am covering old ground. While I can understand that Server-Sent Events may be intending to start off simple, I wonder whether there is some reason a formal mechanism was not adopted to at least allow the specification of event types. I think such a convention would have a number of important benefits. After reading the entire email, I still can't tell what you mean by 'event types'. I can only assume that you mean something like what the spec already allows by having the author send an event: foo line, which makes the next batch of data be dispatched as a foo event instead of a message event. Is this what you're attempting to do? ~TJ
Re: Global variables and id lookup for elements
On 4/28/11, Boris Zbarsky bzbar...@mit.edu wrote: For what it's worth, the way Gecko implements this is by inserting an object into the prototype chain of the Window that handles these property gets. This means that |var| (which defines a prop on the Window itself) will always shadow the named props, which is the behavior you observe. That is correct. Because it is available in quirks mode only, GlobalScopePolluter addresses legacy code designed to run in IE without burdening other scripts with the problematic complexities it causes. -- Garrett
Re: Model-driven Views
On 4/28/11, Olli Pettay olli.pet...@helsinki.fi wrote: On 04/28/2011 04:46 AM, Rafael Weinstein wrote: Would be good to know what are the use cases you had in mind. I'm never sure if I'm using the term use case correctly =-). Our primary motivator is the needs of web applications, And what are those needs? It is hard to judge the proposal if it is not known what kinds of problems it is trying to solve ;) Create HTML content that gets refreshed, using JSON? Load chunks of samely structured content on-demand. Sample app I made for bittorrent when applying for a job: http://dhtmlkitchen.com/tmp/bittorrent/ (waste of time, that was). For example of content that gets refreshed, a table refresh widget would update the data in the HTML TABLE by fetchng JSON. Content that is loaded on-demand but reused in a template could be a product-info panel or a tooltip. Each panel is tied to an actuator and is shown with unique data, but it is created from a template that has essentially the same structure.
