[whatwg] Removing the need for separate feeds
One of the use cases I collected from the e-mails sent in over the past few months was the following: USE CASE: Remove the need for feeds to restate the content of HTML pages (i.e. replace Atom with HTML). SCENARIOS: * Paul maintains a blog and wishes to write his blog in such a way that tools can pick up his blog post tags, authors, titles, and his blogroll directly from his blog, so that he does not need to maintain a parallel version of his data in a structured format. In other words, his HTML blog should be usable as its own structured feed. REQUIREMENTS: * Parsing rules should be unambiguous. * Should not require changes to HTML5 parsing rules. I've attempted a first cut at the above here: http://www.whatwg.org/specs/web-apps/current-work/#atom It doesn't collect the blogroll or the blog post tags yet, mostly because I'm not sure how to do that. Any suggestions of improvements are naturally welcome. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Removing the need for separate feeds
On May 22, 2009, at 09:01, Ian Hickson wrote: USE CASE: Remove the need for feeds to restate the content of HTML pages (i.e. replace Atom with HTML). Did you do some kind of Is this Good for the Web? analysis on this one? That is, do things get better if there's yet another feed format? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[whatwg] Use cases for which I haven't been able to find solutions
The remaining use cases I collected from the e-mails sent in over the past few months were the following: USE CASE: Web browsers should be able to help users find information related to the items discussed by the page that they are looking at. SCENARIOS: * Finding more information about a movie when looking at a page about the movie, when the page contains detailed data about the movie. * For example, where the movie is playing locally. * For example, what your friends thought of it. * Exposing music samples on a page so that a user can listen to all the samples. * Students and teachers should be able to discover each other -- both within an institution and across institutions -- via their blogging. * David can use the data in a web page to generate a custom browser UI for calling a phone number using our cellphone without using brittle screen-scraping. REQUIREMENTS: * Should be discoverable, because otherwise users will not use it, and thus users won't be helped. * Should be consistently available, because if it only works on some pages, users will not use it (see, for instance, the rel=next story). * Should be bootstrapable (rel=next failed because UAs didn't expose it because authors didn't use it because UAs didn't expose it). * Parsing rules should be unambiguous. * Should not require changes to HTML5 parsing rules. USE CASE: Finding distributed comments on audio and video media. SCENARIOS: * Sam has posted a video tutorial on how to grow tomatoes on his video blog. Jane uses the tutorial and would like to leave feedback to others that view the video regarding certain parts of the video she found most helpful. Since Sam has comments disabled on his blog, his users cannot comment on the particular sections of the video other than linking to it from their blog and entering the information there. Jane uses a video player that aggregates all the comments about the video found on the Web, and displays them as subtitles while she watches the video. REQUIREMENTS: * It shouldn't be possible for Jane to be exposed to spam comments. * The comment-aggregating video player shouldn't need to crawl the entire Web for each user independently. * Parsing rules should be unambiguous. * Should not require changes to HTML5 parsing rules. USE CASE: Search engines and other site categorisation and aggregation engines should be able to determine the contents of pages with more accuracy than today. SCENARIOS: * Students and teachers should be able to discover each other -- both within an institution and across institutions -- via their blogging. * A blogger wishes to categorise his posts such that he can see them in the context of other posts on the same topic, including posts by unrelated authors (i.e. not via a pre-agreed tag or identifier, nor via a single dedicated and preconfigured aggregator). * A user whose grandfather is called Napoleon wishes to ask Google the question Who is Napoleon, and get as his answer a page describing his grandfather. * A user wants to ask about Napoleon but, instead of getting an answer, wants the search engine to ask him which Napoleon he wants to know about. REQUIREMENTS: * Should not disadvantage pages that are more useful to the user but that have not made any effort to help the search engine. * Should not be more susceptible to spamming than today's markup. * Parsing rules should be unambiguous. * Should not require changes to HTML5 parsing rules. USE CASE: Allow users to price-check digital media (music, TV shows, etc) and purchase such content without having to go through a special website or application to acquire it, and without particular retailers being selected by the content's producer or publisher. SCENARIOS: * Joe wants to sell his music, but he doesn't want to sell it through a specific retailer, he wants to allow the user to pick a retailer. So he forgoes the chance of an affiliate fee, negotiates to have his music available in all retail stores that his users might prefer, and then puts a generic link on his page that identifies the product but doesn't identifier a retailer. Kyle, a fan, visits his page, clicks the link, and Amazon charges his credit card and puts the music into his Amazon album downloader. Leo instead clicks on the link and is automatically charged by Apple, and finds later that the music is in his iTunes library. * Manu wants to go to Joe's website but check the price of the offered music against the various retailers that sell it, without going to those retailers' sites, so that he can pick the
Re: [whatwg] Removing the need for separate feeds
On Fri, 22 May 2009, Henri Sivonen wrote: On May 22, 2009, at 09:01, Ian Hickson wrote: USE CASE: Remove the need for feeds to restate the content of HTML pages (i.e. replace Atom with HTML). Did you do some kind of Is this Good for the Web? analysis on this one? That is, do things get better if there's yet another feed format? As far as I can tell, things get better if the feed format and the default output format are the same, yes. Generally, redundant information has tended to lead to problems. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Removing the need for separate feeds
On 22/5/09 09:21, Ian Hickson wrote: On Fri, 22 May 2009, Henri Sivonen wrote: On May 22, 2009, at 09:01, Ian Hickson wrote: USE CASE: Remove the need for feeds to restate the content of HTML pages (i.e. replace Atom with HTML). Did you do some kind of Is this Good for the Web? analysis on this one? That is, do things get better if there's yet another feed format? As far as I can tell, things get better if the feed format and the default output format are the same, yes. Generally, redundant information has tended to lead to problems. Would this include having a mechanism (microdata? xml islands?) that preserves extension markup from Atom feeds? eg. see http://www.ibm.com/developerworks/xml/library/x-extatom1/ cheers, Dan
Re: [whatwg] Removing the need for separate feeds
On 22/05/2009 08:21, Ian Hickson i...@hixie.ch wrote: As far as I can tell, things get better if the feed format and the default output format are the same, yes. Generally, redundant information has tended to lead to problems. Can you point to examples of this in relation to the use of feeds in particular? This feels a lot like jumping the shark and solving a problem that has already been solved at one end (syndicating content) and doesn't exist at the other (syndicated content being out of sync with the HTML version). Regards, Adrian Sutton __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Removing the need for separate feeds
On 22/05/2009 08:21, Ian Hickson i...@hixie.ch wrote: As far as I can tell, things get better if the feed format and the default output format are the same, yes. Generally, redundant information has tended to lead to problems. Can you point to examples of this in relation to the use of feeds in particular? This feels a lot like jumping the shark and solving a problem that has already been solved at one end (syndicating content) and doesn't exist at the other (syndicated content being out of sync with the HTML version). Regards, Adrian Sutton __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Removing the need for separate feeds
On Fri, May 22, 2009 at 9:21 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 22 May 2009, Henri Sivonen wrote: On May 22, 2009, at 09:01, Ian Hickson wrote: USE CASE: Remove the need for feeds to restate the content of HTML pages (i.e. replace Atom with HTML). Did you do some kind of Is this Good for the Web? analysis on this one? That is, do things get better if there's yet another feed format? As far as I can tell, things get better if the feed format and the default output format are the same, yes. Generally, redundant information has tended to lead to problems. IMO, feeds are the exception to confirm the rule. While redundant *source* information easily leads to problems, for what I have seen the sites using feeds tend to be almost always dynamic: both the HTML pages and the feeds are generated via server scripts from the *same set of source data*, normally from a database. This is especially true for blogs, and any other CMS-based site, since CMSs normally rely a lot on databases and server-side scripting. So on these cases we don't actually have redundant information, but just multiple ways to retrieve the same information. For manually authored pages and feeds things would be different; but are there really a significant ammount of such cases out there? I can't say I have seen the entire web (who can?), but among what I have seen, I have never encountered any hand authored feed, except for code examples and similar experimental stuff. Regards, Eduard Pascual
Re: [whatwg] Removing the need for separate feeds
Adrian Sutton writes: On 22/05/2009 08:21, Ian Hickson i...@hixie.ch wrote: As far as I can tell, things get better if the feed format and the default output format are the same, yes. Generally, redundant information has tended to lead to problems. Can you point to examples of this in relation to the use of feeds in particular? I can't find examples right now, but I have encountered various problems along these lines in the past, including: * The feed suddenly becomes empty. * A new blog has a 'feed' link, but it never works. * A blog's feed URL changes, but doesn't redirect. * A feed is misformatted in a way which causes it to be ignored. * The content of a feed is misformatted, such that in a feed reader its display is mangled, such as HTML tags and entities showing, or spaces having been squeezed out from around tags such that linked words don't have spaces around them. * The content of a feed has certain critical information, such as an image, stripped from it, such that it makes no sense, or has a different meaning from the full post. * The content of a feed has certain critical mark-up stripped from it, such as sup around exponents in a mathematical expression rendering 36 where 3 to the power of 6 was intended. In all cases the HTML version of the blog had correctly displaying and updating content; only the feed was affected by the issues. This usually left the author unaware of the problem, as they don't subscribe to their own blog. Eduard Pascual writes: sites using feeds tend to be almost always dynamic: both the HTML pages and the feeds are generated via server scripts from the *same set of source data*, I believe that to be true for at least most of the above cases I encountered. However that obviously wasn't sufficient to avoid the problems. For manually authored pages and feeds things would be different; but are there really a significant ammount of such cases out there? Not many. But that's quite possibly because of the effort involved in doing so. The algorithm in the HTML 5 spec would allow some categories of handcrafted pages to gain feeds for free. I've often encountered webpages which I wished had feeds but don't. It's possible that an algorithm such as this would encourage more pages to do so. Smylers
Re: [whatwg] Removing the need for separate feeds
Eduard Pascual wrote: For manually authored pages and feeds things would be different; but are there really a significant ammount of such cases out there? I can't say I have seen the entire web (who can?), but among what I have seen, I have never encountered any hand authored feed, except for code examples and similar experimental stuff. Surely this proves the need for a way of extracting feeds from HTML? You never see manually written feeds because people can't be bothered to manually write feeds. So the people who manually author HTML simply don't bother providing feeds at all. If an HTML page can *be* a feed, this allows manually authored HTML pages to be subscribed to in feed readers. -- Toby Inkster m...@tobyinkster.co.uk
Re: [whatwg] Removing the need for separate feeds
On 22/05/2009 11:36, Toby Inkster m...@tobyinkster.co.uk wrote: Surely this proves the need for a way of extracting feeds from HTML? You never see manually written feeds because people can't be bothered to manually write feeds. So the people who manually author HTML simply don't bother providing feeds at all. If an HTML page can *be* a feed, this allows manually authored HTML pages to be subscribed to in feed readers. For this to make sense, these people would also be manually adding new entries to the top of the page and dropping old ones off the bottom all by hand. Feeds aren't used for checking for updates to a page - they're used to check for updates for a site (or section of a site). There are very few cases where every item in a feed corresponds to the same page, even where the entries may be aggregated into a single index page. Even people who really want to edit pages in plain text editors tend to use a system like Bloxsom to build those into an overall site, and generate the feeds. Can anyone point to examples where the content is entirely hand crafted and a feed would actually make sense? Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Removing the need for separate feeds
I also wonder if feeds being accessible in HTML might give rise, as with stylesheets and scripts contained in the head (convenient as those can be too), to excessive bandwidth, as agents repeatedly request updates to a whole HTML page containing a lot of other data. (If we had external entities working though, that might be different for XHTML at least, as the file could be included easily as well as reside in its own independently discoverable location (via link/)...) Brett
Re: [whatwg] Removing the need for separate feeds
On 22/5/09 12:36, Toby Inkster wrote: Eduard Pascual wrote: For manually authored pages and feeds things would be different; but are there really a significant ammount of such cases out there? I can't say I have seen the entire web (who can?), but among what I have seen, I have never encountered any hand authored feed, except for code examples and similar experimental stuff. Surely this proves the need for a way of extracting feeds from HTML? You never see manually written feeds because people can't be bothered to manually write feeds. So the people who manually author HTML simply don't bother providing feeds at all. If an HTML page can *be* a feed, this allows manually authored HTML pages to be subscribed to in feed readers. FWIW the W3C homepage works this way since ~2000, http://www.w3.org/2000/08/w3c-synd/ cheers, Dan
Re: [whatwg] Removing the need for separate feeds
On Fri, May 22, 2009 at 11:45 AM, Adrian Sutton adrian.sut...@ephox.com wrote: [...] Can anyone point to examples where the content is entirely hand crafted and a feed would actually make sense? Perhaps a page like http://philip.html5.org/data.html - people might want to subscribe in their feed reader to see all the exciting updates, and the markup is all hand-written. It's not at all like a blog, but maybe it's data that could be usefully represented with Atom. Currently the markup looks like: ol lia href=http://philip.html5.org/data/abbr-acronym.txt;codeabbr/code, codeacronym/code titles and contents./a !-- 2008-02-03 -- lia href=http://philip.html5.org/data/spaced-uris.txt;URIs containing spaces./a !-- 2008-02-02 -- ... /ol If I understand the spec correctly, I would have to write something like: ol li article pubdate=2008-02-03T00:00:00Z h1a href=http://philip.html5.org/data/abbr-acronym.txt; rel=bookmarkcodeabbr/code, codeacronym/code titles and contents./a/h1 /article li article pubdate=2008-02-02T00:00:00Z h1a href=http://philip.html5.org/data/spaced-uris.txt; rel=bookmarkURIs containing spaces./a/h1 /article ... /ol and then it would hopefully work. -- Philip Taylor exc...@gmail.com
Re: [whatwg] Removing the need for separate feeds
On 22/05/2009 13:32, Philip Taylor excors+wha...@gmail.com wrote: Perhaps a page like http://philip.html5.org/data.html - people might want to subscribe in their feed reader to see all the exciting updates, and the markup is all hand-written. It's not at all like a blog, but maybe it's data that could be usefully represented with Atom. There are four articles on that page - do they really update often enough to warrant anything more than just adding plain If-Modified support to feedreaders and displaying the whole page when it changes? Given the arguments for justifying the cost of additional attributes I've seen go by on this list, this is probably the weakest I've seen and somehow it made it into the draft. HTML 5 doesn't need to solve every possible problem, nor should it try to. Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Removing the need for separate feeds
On 22/05/2009 13:32, Philip Taylor excors+wha...@gmail.com wrote: Perhaps a page like http://philip.html5.org/data.html - people might want to subscribe in their feed reader to see all the exciting updates, and the markup is all hand-written. It's not at all like a blog, but maybe it's data that could be usefully represented with Atom. There are four articles on that page - do they really update often enough to warrant anything more than just adding plain If-Modified support to feedreaders and displaying the whole page when it changes? Given the arguments for justifying the cost of additional attributes I've seen go by on this list, this is probably the weakest I've seen and somehow it made it into the draft. HTML 5 doesn't need to solve every possible problem, nor should it try to. Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Removing the need for separate feeds
On Fri, May 22, 2009 at 2:02 PM, Adrian Sutton adrian.sut...@ephox.com wrote: On 22/05/2009 13:32, Philip Taylor excors+wha...@gmail.com wrote: Perhaps a page like http://philip.html5.org/data.html - people might want to subscribe in their feed reader to see all the exciting updates, and the markup is all hand-written. It's not at all like a blog, but maybe it's data that could be usefully represented with Atom. There are four articles on that page - do they really update often enough to warrant anything more than just adding plain If-Modified support to feedreaders and displaying the whole page when it changes? The way I see it, there are 24 articles on the page (grouped into four categories), each published independently at separate times. There would be about a hundred if I kept that index up to date. But I'm not sure this is a very compelling example, and I can't think of any other cases where I'd possibly want to publish non-database-backed data as both HTML and Atom. -- Philip Taylor exc...@gmail.com
[whatwg] page refresh and resubmitting POST state
I can see some usefulness for adding a couple of subjects to the HTML5 spec: - how browsers should handle page refresh, in particular for pages received through POST (= do you want to resubmit?) - potentially add constructs to help users avoid the above resubmit question (this could f ex be through providing some support for PRG = Post-Redirect-Get, or other) Does this seem interesting? Best regards Mike Wilson
Re: [whatwg] A Selector-based metadata proposal (was: Annotating structured data that HTML has no semantics for)
On Fri, 2009-05-22 at 12:26 +0200, Eduard Pascual wrote: Are you calling the DOM Consistency Principle a theoretical or aesthetic argument? Certainly not -- DOM consistency is a great idea. But given that the HTML5 spec defines how the DOM is built, there's a very simple solution to that -- HTML5 could simply mandate that: html xmlns:foo=http://foo.example.com/; generates an identical DOM representation in both XHTML5 and HTML5. What's the problem with that? In existing implementations, there are differences, sure. But for the most part, those differences are pretty small and obscure, and don't actually effect real world code very much. e.g. the following code seems to work fine in Opera, Firefox and Midori (a Webkit browser): http://buzzword.org.uk/2009/dom.html http://buzzword.org.uk/2009/dom.xhtml The files are byte-for-byte identical (indeed, on disk, one is just a symlink to the other). -- Toby Inkster m...@tobyinkster.co.uk
Re: [whatwg] on bibtex-in-html5
Just to put a fine point on this ... On Thu, May 21, 2009 at 12:11 PM, Bruce D'Arcus bdar...@gmail.com wrote: ... Or consider the user or developer who can't figure out how to represent their data in bibtex-in-html5 because its designers simply didn't consider it. In that case, people go elsewhere, or invent their own solutions. .. a zotero forum post from earlier today: http://forums.zotero.org/discussion/7138/export-patent-information-as-bibtex So, user has a patent item stored in their database. When they go to export it to bibtex, much of the data gets lost. I probably wasn't clear enough in my list posts, but I'd prefer that the bibtex stuff be removed entirely from the spec. It'd be fine, however, if it was in a non-normative document apart from the spec. I'd also prefer that microdata itself be removed in favor of RDFa, but I proposed an alternative approach given the way this has gone so far (namely that this effort seems a fait accompli). Bruce
Re: [whatwg] A Selector-based metadata proposal
On Fri, 22 May 2009 16:44:32 +0200, Toby Inkster m...@tobyinkster.co.uk wrote:
On Fri, 2009-05-22 at 12:26 +0200, Eduard Pascual wrote:
Are you calling the DOM Consistency Principle a theoretical or
aesthetic argument?
Certainly not -- DOM consistency is a great idea. But given that the
HTML5 spec defines how the DOM is built, there's a very simple solution
to that -- HTML5 could simply mandate that:
html xmlns:foo=http://foo.example.com/;
generates an identical DOM representation in both XHTML5 and HTML5.
What's the problem with that?
People doing e.g.
[xmlns\:foo] { ... }
in CSS and expecting it to function.
ECMAScript libraries doing
var x = getAttributeNS(, xmlns:foo)
and expecting it to function.
* It's not clear how common either scenario is.
* There are probably more ways to exploit the difference besides what I listed.
* It might make people think that foo:bar style elements would work. (I
believe we're reasonably sure this would break things.)
* It might make people think that x foo:bar= style attributes would work.
(I believe we're reasonably sure this would break things too.)
* ...
(Not sure what this has to do with Selectors by the way.)
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] A Selector-based metadata proposal (was: Annotating structured data that HTML has no semantics for)
On May 22, 2009, at 17:44, Toby Inkster wrote: But given that the HTML5 spec defines how the DOM is built, there's a very simple solution to that -- HTML5 could simply mandate that: html xmlns:foo=http://foo.example.com/; generates an identical DOM representation in both XHTML5 and HTML5. What's the problem with that? 1) It's a difference from how browsers behave now. It's a flaw in RDFa that it opens the question whether text/html parsing needs to change. 2) Finding out whether the change to parsing is harmless for existing content requires shipping a mass-market browser with the parsing change. 3) It would require the HTML parser to look inside the attribute name buffer instead of treating it as an opaque string, which would add code complexity. 4) If if you changed this in text/html parsing, next CURIEs would be Selector-unfriendly... CURIEs aren't a good match for the platform. But for the most part, those differences are pretty small and obscure, and don't actually effect real world code very much. e.g. the following code seems to work fine in Opera, Firefox and Midori (a Webkit browser): http://buzzword.org.uk/2009/dom.html http://buzzword.org.uk/2009/dom.xhtml You are using a Namespace-unaware API. The internal APIs of Gecko and WebKit as well as various non-browser XML frameworks are Namespace-aware. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] page refresh and resubmitting POST state
On Fri, May 22, 2009 at 7:06 AM, Mike Wilson mike...@hotmail.com wrote: - potentially add constructs to help users avoid the above resubmit question (this could f ex be through providing some support for PRG = Post-Redirect-Get, or other) This is already supported. If you use a 302 or 303 redirect in response to a POST this will redirect to a uri that the UA then GETs. Refresing that page will simply result in a new GET to the second uri. Example: product.html contains a form method=POST action=addToCart.cgi. addToCart.cgi processes the parameters received from the POST request and replies with a 302 response with Location: displayCart.cgi. displayCart.cgi lists what is in the shopping cart. The result of this is that once the user submits the form on product.html, the UA will make a POST request to addToCart.cgi, then make a GET request to displayCart.cgi and display the result of that page. If the user refreshes the UA will again make a GET request to displayCart.cgi and display the result. / Jonas
Re: [whatwg] page refresh and resubmitting POST state
Thanks for expanding on my previous mail, Jonas, but I was assuming that everyone on this list was aware of the PRG pattern and its existing support in browsers. With current technology there are limitations to the usefulness of PRG (f ex in multi-window/tab scenarios), so I am asking if it is within HTML5's scope to explore improved or alternative solutions to the resubmit problem. Best regards Mike Jonas Sicking wrote: On Fri, May 22, 2009 at 7:06 AM, Mike Wilson mike...@hotmail.com wrote: - potentially add constructs to help users avoid the above resubmit question (this could f ex be through providing some support for PRG = Post-Redirect-Get, or other) This is already supported. If you use a 302 or 303 redirect in response to a POST this will redirect to a uri that the UA then GETs. Refresing that page will simply result in a new GET to the second uri. Example: product.html contains a form method=POST action=addToCart.cgi. addToCart.cgi processes the parameters received from the POST request and replies with a 302 response with Location: displayCart.cgi. displayCart.cgi lists what is in the shopping cart. The result of this is that once the user submits the form on product.html, the UA will make a POST request to addToCart.cgi, then make a GET request to displayCart.cgi and display the result of that page. If the user refreshes the UA will again make a GET request to displayCart.cgi and display the result. / Jonas
Re: [whatwg] page refresh and resubmitting POST state
On Fri, 22 May 2009 21:48:28 +0100, Mike Wilson mike...@hotmail.com wrote: Thanks for expanding on my previous mail, Jonas, but I was assuming that everyone on this list was aware of the PRG pattern and its existing support in browsers. With current technology there are limitations to the usefulness of PRG (f ex in multi-window/tab scenarios), so I am asking if it is within HTML5's scope to explore improved or alternative solutions to the resubmit problem. As far as I understand the resubmit problem is just sign of poor implementation that violates SHOULD NOT in the HTTP RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 This problem can be elegantly solved within existing standards: Opera simply goes back in history without resubmitting forms, and resubmits only when user clicks standard Reload button (or F5, etc.) -- regards, Kornel Lesinski
Re: [whatwg] Removing the need for separate feeds
On Fri, 22 May 2009 09:41:43 +0100, Eduard Pascual herenva...@gmail.com wrote: For manually authored pages and feeds things would be different; but are there really a significant ammount of such cases out there? I can't say I have seen the entire web (who can?), but among what I have seen, I have never encountered any hand authored feed, except for code examples and similar experimental stuff. I maintain hand-authored Atom feeds on few websites. It's not a problem if feeds are updated rarely. On websites without CMS copyingpasting few tags once a month feels like less work than moving website to a CMS or writing XSLT :) Despite that I'm not excited about Ian's proposal. In these scenarios I often want content of the feed to be different than content of the page, e.g. feed says I've added article about Foo., but page has Newest articles: Foo, Bar, Baz. -- regards, Kornel Lesinski
[whatwg] Overriding functions in DOM Storage
What is the behavior of the following supposed to be?
window.sessionStorage.removeItem = function(x) { alert(Wait, this works?);
};
window.sessionStorage.removeItem('blah');
alert(typeof window.sessionStorage.removeItem);
Safari shows 2 alerts, and the second one says 'function'.
IE8 says object doesn't support this property or method if line 2 isn't
commented out. It returns type string when it is.
Mozilla also won't run if line 2 is there, but it returns type object for
line 3.
It seems to me that if IE8's behavior is correct, those parameters should be
marked as read-only since overriding them could only be used to shoot
yourself in the foot.
If Safari's implementation is correct (and it's good for the implementations
to be overridable), then I believe there needs to be some safe way to make
.clear() usable again. (Otherwise, once you override removeItem() and
clear(), there's not really any way to recover.) The spec would also need
to make it clear that removeItem, setItem, etc are special and should not
be serialized to disk.
Apologies if this is clear in the spec and I somehow missed it. But, if
not, I think a clarification might be necessary.
J
Re: [whatwg] Removing the need for separate feeds
On Fri, 22 May 2009 07:01:51 +0100, Ian Hickson i...@hixie.ch wrote: It doesn't collect the blogroll or the blog post tags yet, mostly because I'm not sure how to do that. Any suggestions of improvements are naturally welcome. There's hAtom that solves this problem already, and appears to have been proliferated by popular blogging software: http://search.yahoo.com/search?p=searchmonkeyid%3Acom.yahoo.page.uf.hatom but I doubt that many users take advantage of it. Almost all of these pages have standard feeds as well (and all of them can provide them via hAtom2Atom proxy). Maybe a better approach would be to extend hAtom or define extraction in terms of hAtom? (e.g. make div class=hentry and article interchangeable?) For each article element article that does not have an ancestor article element That excludes possibility of syndicating article's comments from markup like this: body article post articlecomment/article articlecomment/article /article /body Feed with only single entry post or post comment comment would not be useful. OTOH it may be useful to include all nested comments in a single feed: articlecomment articlecomment reply/article /article Another problem is that algorithm cannot create summary. Perhaps summary could be assumed if there's alternate link and article doesn't contain more than one header? Or has entire contents wrapped in blockquote? I haven't noticed any way to exclude articles from the feed (except hack articlearticle.../article/article). I may have news that's not important enough to justify notification of all subscribers. Are trackbacks and tweets appropriate for article? I might want to show them on my page, but wouldn't want to repost them in my feeds. -- regards, Kornel Lesinski
Re: [whatwg] Overriding functions in DOM Storage
On May 22, 2009, at 5:41 PM, Jeremy Orlow wrote:
What is the behavior of the following supposed to be?
window.sessionStorage.removeItem = function(x) { alert(Wait, this
works?); };
window.sessionStorage.removeItem('blah');
alert(typeof window.sessionStorage.removeItem);
Safari shows 2 alerts, and the second one says 'function'.
IE8 says object doesn't support this property or method if line 2
isn't commented out. It returns type string when it is.
Mozilla also won't run if line 2 is there, but it returns type
object for line 3.
It seems to me that if IE8's behavior is correct, those parameters
should be marked as read-only since overriding them could only be
used to shoot yourself in the foot.
If Safari's implementation is correct (and it's good for the
implementations to be overridable), then I believe there needs to be
some safe way to make .clear() usable again. (Otherwise, once you
override removeItem() and clear(), there's not really any way to
recover.) The spec would also need to make it clear that
removeItem, setItem, etc are special and should not be serialized to
disk.
Apologies if this is clear in the spec and I somehow missed it.
But, if not, I think a clarification might be necessary.
DOM methods are normally overridable. That would make the Safari
behavior correct. If we want the behavior to be different in this
case, then the spec should spell that out. Perhaps part of the issue
here is that the definition of the [NameSetter] extended attribute in
Web IDL doesn't make clear whether or not name setter behavior takes
precedence over setting existing predefined attributes or methods.
Regards,
Maciej
