Re: [whatwg] onerror
On Sat, 17 Jan 2009 04:04:19 +0100, Jonas Sicking jo...@sicking.cc wrote: Not sure if I should be posting this to the whatwg list or the webapps list, given that the spec is in process of transitioning between the two groups. So I'm posting to both in the hope that this thread won't generate too much related traffic. So please stay on topic :) Currently the webapps spec define that the onerror property should start out as undefined, rather than other onX properties which start out as null. The reason for this is parity with the window object where the onerror property behaves the same. However there is very little parity anyway between the window onerror and the worker onerror. The former isn't a normal event handler but rather a special function that receives 3 arguments and returns a special value to suppress the error. The latter is a normal event handler which receives an error event and suppresses the error by calling .preventDefault() on the event. Further, the fact that onerror is undefined at the start is to prevent breaking existing scripts, of which there are none for workers. So I think it'd be nicer to have parity with other onX properties, than to have parity on this one aspect with window.onerror. Will you be changing Firefox for the other onX attributes then? I.e., http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A...%3Cscript%3E%20w(document.body.onclick)%20%3C%2Fscript%3E gives null in Opera 9.6+ and Internet Explorer 6, but undefined in Firefox 3.2a1pre. (Replying just to the WHATWG list as my question is only relevant to HTML5 for now.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] HTML 5 : Misconceptions Documented
Ian Hickson wrote: On Thu, 15 Jan 2009, Garrett Smith wrote: If I understand this correctly, given a FORM with an INPUT named 'b', if I change the name of that INPUT to 'a', then form.b should return the element with name=a. snip What is the reason for introducing the past names map behavior to the form? Compatibility with a legacy IE bug required (acording to Safari and Firefox devs) by legacy content. I'm impressed with the level of detail that you strive for in documenting real-world HTML :-) The idea of HTML5 is to make sure that a browser that implements all of HTML5 is compatible with legacy content. This is one of the things that legacy content requires, so the spec has to require it too. The idea is to make it so that browsers don't feel forced to add _any_ non-standard behavior (other than experimental innovations using vendor-prefixed names and stuff). That's a good thing. Still, seeing this quite non-trivial feature-bug being standardized, I see the potential for making the standard unnecessary complicated if including a lot of these legacy quirks. So I wonder what is your process for determining if a quirk should be included in HTML5 or not? Is there any listing of other quirks together with a yes/no decision whether to include them in HTML5? Also, what is the general ambition for compatibility with legacy content? Until reading this thread I personally thought HTML5's legacy compatibility revolved mainly around rendering and document validity, but now I realize it has a lot to do with script compatibility as well? And please do not take this message as criticism, these are just interesting (to me) questions that I couldn't find the answer to on the whatwg FAQ. Best regards Mike Wilson
[whatwg] Name for WHATWG Members
There seems to be some confusion about whether members of WHATWG are just people on the mailing list or are people on the oversight committee. Since it is almost never necessary to discuss the oversight committee I suggest it is worth using the common term members to mean people on the mailing list and the longer term oversight committee members to mean people in the oversight committee. This would eliminate the confusion and draw attention to the fact that it is the people on the mailing list who are responsible for the technical content of the spec (like W3C Working group members) and that the oversight committee who are responsible only for things like the charter (like W3C staff).
Re: [whatwg] Name for WHATWG Members
There seems to be some confusion about whether members of WHATWG are just people on the mailing list or are people on the oversight committee. From http://www.whatwg.org/charter Membership is by invitation only, and consists of a number of representatives from various browser manufacturers. This group, which is referred to as the members, will provide overall guidance as described in the charter above. The members currently consists of: Anne van Kesteren Brendan Eich David Baron David Hyatt Dean Edwards Håkon Wium Lie Ian Hickson Johnny Stenback Maciej Stachowiak Those are the members. Everyone on the mailing list is a mailing list subscriber. Larry -- http://larry.masinter.net
Re: [whatwg] Name for WHATWG Members
On Sat, 17 Jan 2009 16:47:55 +0100, Larry Masinter l...@acm.org wrote: Those are the members. Everyone on the mailing list is a mailing list subscriber. Yes, the suggestion was to make an editorial change to how we call members since people on the interwebs are confusing the two (members and contributors). Most likely because at the W3C a member is what the WHATWG charter refers to as contributor. As I understand the proposal, what is now called members becomes steering committee members and what is now contributors becomes members; seems like a good idea to me. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
The debate about RDFa highlights a disconnect in the decision making related to HTML5. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. An earlier email between Martin Atkins and Ian Hickson had the following: On Sun, 11 Jan 2009, Martin Atkins wrote: One problem this can solve is that an agent can, given a URL that represents a person, extract some basic profile information such as the person's name along with references to other people that person knows. This can further be applied to allow a user who provides his own URL (for example, by signing in via OpenID) to bootstrap his account from existing published data rather than having to re-enter it. So, to distill that into a list of requirements: - Allow software agents to extract profile information for a person as often exposed on social networking sites from a page that represents that person. - Allow software agents to determine who a person lists as their friends given a page that represents that person. - Allow the above to be encoded without duplicating the data in both machine-readable and human-readable forms. Is this the sort of thing you're looking for, Ian? Yes, the above is perfect. (I cut out the bits that weren't really the problem from the quote above -- the above is what I'm looking for.) The most critical part is allow a user who provides his own URL to bootstrap his account from existing published data rather than having to re-enter it. The one thing I would add would be a scenario that one would like to be able to play out, so that we can see if our solution would enable that scenario. For example: I have an account on social networking site A. I go to a new social networking site B. I want to be able to automatically add all my friends from site A to site B. There are presumably other requirements, e.g. site B must not ask the user for the user's credentials for site A (since that would train people to be susceptible to phishing attacks). Also, site A must not publish the data in a manner that allows unrelated users to obtain privacy-sensitive data about the user, for example we don't want to let other users determine relationships that the user has intentionally kept secret [1]. It's important that we have these scenarios so that we can check if the solutions we consider are actually able to solve these problems, these scenarios, within the constraints and requirements we have. It would seem that Ian agrees with a need to both a) provide a way to document complex information in a consistent, machine readable form and that b) the purpose of this data is for external consumption, rather than internal use. Where the disconnect comes in is he believes that RDF, and the web page serialization technique, RDFa, are only one of a set of possible solutions. Yet at the same time, he references how the MathML and SVG people provide sufficient use cases to justify the inclusion of both of these into HTML5. But what is MathML. What does it solve? A way to include mathematical formula into a document in a formatted manner. What is SVG? A way to embed vector graphics into a web page, in such a way that the individual elements described by the graphics can become part of the overall DOM. So, why accept that we have to use MathML in order to solve the problems of formatting mathematical formula? Why not start from scratch, and devise a new approach? So, why accept that we have to use SVG in order to solve the problems of vector graphics? Why not start from scratch, and devise a new approach? Come to think of it, I think we should also question the use of the canvas element. After all, if the problem set is that we need the ability to animate graphics in a web page using a non-proprietary technology, then wouldn't something like SVG work for this purpose? Isn't the canvas element redundant? But then, perhaps we should start over from the beginning and just create a new graphics capability from scratch, and reject both canvas and SVG. We don't reject MathML, though. Neither do we reject SVG or canvas. Or any other of a number of entities being included in HTML5, including SQL. Why? Because they have a history of use, extensive documentation as to purpose and behavior, and there are a considerable number of implementations that support the specifications. It doesn't make sense to start from scratch. It makes more sense to make use of what already works. I have to ask, then: why do we isolate RDF, and RDFa for special handling? If we can accept that SQL is a natural database query mechanism, and SVG is a natural for
Re: [whatwg] HTML 5 : Misconceptions Documented
On Sat, 17 Jan 2009 14:18:07 +0100, Mike Wilson mike...@hotmail.com wrote: Ian Hickson wrote: The idea is to make it so that browsers don't feel forced to add _any_ non-standard behavior (other than experimental innovations using vendor-prefixed names and stuff). That's a good thing. Still, seeing this quite non-trivial feature-bug being standardized, I see the potential for making the standard unnecessary complicated if including a lot of these legacy quirks. Well, the Web is unnecessarily complicated and browsers are by extension. If we want to allow new browsers to enter the market space, existing browsers to be able to compete more effectively, and be able to add extensions on top of the existing platform, specifying it and striving for convergence is the best bet we have. So I wonder what is your process for determining if a quirk should be included in HTML5 or not? Is there any listing of other quirks together with a yes/no decision whether to include them in HTML5? There is no exact list and some of the weird bits are done by other specifications. Also, what is the general ambition for compatibility with legacy content? Until reading this thread I personally thought HTML5's legacy compatibility revolved mainly around rendering and document validity, but now I realize it has a lot to do with script compatibility as well? Yes, and parsing, and interpreting weird attribute values, etc. And please do not take this message as criticism, these are just interesting (to me) questions that I couldn't find the answer to on the whatwg FAQ. Feel free to add questions there and answer questions you know the answer to. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Name for WHATWG Members
On Saturday 2009-01-17 14:46 +0100, James Graham wrote: There seems to be some confusion about whether members of WHATWG are just people on the mailing list or are people on the oversight committee. Since it is almost never necessary to discuss the oversight committee I suggest it is worth using the common term members to mean people on the mailing list and the longer term oversight committee members to mean people in the oversight committee. This would eliminate the confusion and draw attention to the fact that it is the people on the mailing list who are responsible for the technical content of the spec (like W3C Working group members) and that the oversight committee who are responsible only for things like the charter (like W3C staff). I agree that the current use of members is confusing. However, I don't like changing a term immediately from one thing to another. Then any use of that term needs to be qualified with a date. I also think that the term contributors makes it clearer that there aren't any membership requirements in order to participate. So I'd prefer to avoid the term members entirely by changing the references to members to be steering committee, oversight committee, or similar. This might lead to the section of the charter currently entitled Membership saying something like: # Participation and Oversight # # Anyone can contribute by subscribing to the mailing list. The list # of subscribers to the mailing list are termed the contributors. # # Membership in the oversight committee is by invitation only, and # consists of a number of representatives from various browser # manufacturers. This group will provide overall guidance as # described in the charter above. The members of the oversight # committee are currently: # # [...] -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] onerror
On 1/17/09, Anne van Kesteren ann...@opera.com wrote: On Sat, 17 Jan 2009 04:04:19 +0100, Jonas Sicking jo...@sicking.cc wrote: Not sure if I should be posting this to the whatwg list or the webapps list, given that the spec is in process of transitioning between the two groups. So I'm posting to both in the hope that this thread won't generate too much related traffic. So please stay on topic :) Currently the webapps spec define that the onerror property should start out as undefined, rather than other onX properties which start out as null. The reason for this is parity with the window object where the onerror property behaves the same. However there is very little parity anyway between the window onerror and the worker onerror. The former isn't a normal event handler but rather a special function that receives 3 arguments and returns a special value to suppress the error. The latter is a normal event handler which receives an error event and suppresses the error by calling .preventDefault() on the event. Further, the fact that onerror is undefined at the start is to prevent breaking existing scripts, of which there are none for workers. So I think it'd be nicer to have parity with other onX properties, than to have parity on this one aspect with window.onerror. Will you be changing Firefox for the other onX attributes then? I.e., http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A...%3Cscript%3E%20w(document.body.onclick)%20%3C%2Fscript%3E gives null in Opera 9.6+ and Internet Explorer 6, but undefined in Firefox 3.2a1pre. I'm talking about parity with other onX attributes inside workers. But I'd be fine with changing onX for other objects if all other browsers do something else, but thats orthogonal to the issue I originally brought up in this thread. / Jonas
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers shell...@burningbird.net wrote: The debate about RDFa highlights a disconnect in the decision making related to HTML5. Perhaps. Or perhaps not. I am far from an apologist for Hixie, (nor for that matter and I a strong advocate for RDF), but I offer the following question and observation. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. So, I take it that it isn't essential that RDFa information be included in the DOM? This is not rhetorical: I honestly don't know the answer to this question. So, why accept that we have to use MathML in order to solve the problems of formatting mathematical formula? Why not start from scratch, and devise a new approach? Ian explored (and answered) that here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html Key to Ian's decision was the importance of DOM integration for this vocabulary. If DOM integration is essential for RDFa, then perhaps the same principles apply. If not, perhaps some other principles may apply. - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On 17/1/09 19:27, Sam Ruby wrote: On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers shell...@burningbird.net wrote: The debate about RDFa highlights a disconnect in the decision making related to HTML5. Perhaps. Or perhaps not. I am far from an apologist for Hixie, (nor for that matter and I a strong advocate for RDF), but I offer the following question and observation. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. So, I take it that it isn't essential that RDFa information be included in the DOM? This is not rhetorical: I honestly don't know the answer to this question. Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. cheers, Dan -- http://danbri.org/
Re: [whatwg] Issues concerning the base element and xml:base
Ian Hickson ha scritto: On Fri, 16 Jan 2009, Calogero Alex Baldacchino wrote: What should happen to a linked style sheet disabled during the first casced and enabled after the base has been changed? Or if it was first enabled, than disabled before changing the base, and re-enabled after? For external resource links created with the link element, the URL is resolved when the resource is fetched, which can be delayed if the resource doesn't apply yet (e.g. because a media query doesn't yet match). This could lead to situations where different user agents had compliant behavior, unfortunately, but this is one case where I can't see how to avoid it without requiring suboptimal behavior. I understand. Perhaps, if a main (more diffused) behaviour could be isolated, it might be chosen to normalize newer UAs behaviours, while possibly breaking fewer existing pages (the same eventually behaving differently in different browsers). However, I guess this might require a convergence between HTML and CSS specifications for this purpose (it might rise an issue on consistence for @import rules, for instance, which are in CSS scope). I don't know if it may work something like establishing that a URL, in this case, is resolved any times it is explicitly set (e.g. when the document is parsed and when the href value changes), as if the resources were immediately fetched (thus, not being affected by a successive change in a base) but not constraining UAs to do so (an inline style element might be treated as an external resource being yet fetched, thus it would be about to associate it with a base URI being valid at the moment the style was created and maintained valid until the style content is explicitely changed). Though, I guess this should be somehow consistent with existing UAs and pages (or, at least, with a significant group). Anne van Kesteren ha scritto: On Fri, 16 Jan 2009 05:15:41 +0100, Ian Hickson i...@hixie.ch wrote: For external resource links created with the link element, the URL is resolved when the resource is fetched, which can be delayed if the resource doesn't apply yet (e.g. because a media query doesn't yet match). This could lead to situations where different user agents had compliant behavior, unfortunately, but this is one case where I can't see how to avoid it without requiring suboptimal behavior. You have the same scenario for inline style elements that are either in alternate state or are of a medium that currently does not apply to the document. The user agent is not required to parse those CSS blocks directly, I believe. WBR, Alex -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Innammorarsi è facile con Meetic, milioni di single si sono iscritti, si sono conosciuti e hanno riscoperto l'amore. Tutto con Meetic, prova anche tu! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8292d=17-1
Re: [whatwg] onerror
On Sat, 17 Jan 2009 19:24:56 +0100, Jonas Sicking jo...@sicking.cc wrote: I'm talking about parity with other onX attributes inside workers. But I'd be fine with changing onX for other objects if all other browsers do something else, but thats orthogonal to the issue I originally brought up in this thread. Not quite, because I'd like HTML5 onX attributes to do the same as Web Workers onX attributes. (And the same for where else there are onX attributes, e.g. XMLHttpRequest.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Dan Brickley wrote: On 17/1/09 19:27, Sam Ruby wrote: On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers shell...@burningbird.net wrote: The debate about RDFa highlights a disconnect in the decision making related to HTML5. Perhaps. Or perhaps not. I am far from an apologist for Hixie, (nor for that matter and I a strong advocate for RDF), but I offer the following question and observation. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. So, I take it that it isn't essential that RDFa information be included in the DOM? This is not rhetorical: I honestly don't know the answer to this question. Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. cheers, Dan I agree, and appreciate Dan for pointing out a specific instance of use. Apologies for not making the assertion explicit. Shelley -- http://danbri.org/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, Jan 17, 2009 at 1:33 PM, Dan Brickley dan...@danbri.org wrote: On 17/1/09 19:27, Sam Ruby wrote: On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers shell...@burningbird.net wrote: The debate about RDFa highlights a disconnect in the decision making related to HTML5. Perhaps. Or perhaps not. I am far from an apologist for Hixie, (nor for that matter and I a strong advocate for RDF), but I offer the following question and observation. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. So, I take it that it isn't essential that RDFa information be included in the DOM? This is not rhetorical: I honestly don't know the answer to this question. Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. The fact that this works anywhere at all today implies that little, if any, changes to browsers is required in order to support this. Is that a fair statement? I've not taken a look at the code, but have taken a quick glance at the output using IE8.0.7000.0 beta, Safari 3.2.1/Windows, Chrome 1.0.154.43, Opera 9.63, and Firefox 3.0.5. The page is different (as in less functional) under IE8 and Safari. Is there something that they need to do which is not already covered in the HTML5 specification in order to support this? - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, 17 Jan 2009, Sam Ruby wrote: Shelley Powers wrote: So, why accept that we have to use MathML in order to solve the problems of formatting mathematical formula? Why not start from scratch, and devise a new approach? Ian explored (and answered) that here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html Key to Ian's decision was the importance of DOM integration for this vocabulary. If DOM integration is essential for RDFa, then perhaps the same principles apply. If not, perhaps some other principles may apply. Sam's point here bears repeating, because there seems to be an impression that we took on SVG and MathML without any consideration, while RDF is getting an unfair reception. On the contrary, SVG and MathML got the same reception. For MathML, for instance, a number of options were very seriously considered, most notably LaTeX. For SVG, we considered a variety of options including VML. I would encourage people to read the e-mail Sam cited: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html It's long, but the start of it is a summary of what was considered and shows that the same process derived from use cases was used for SVG and MathML as is being used on this thread here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Sam Ruby wrote: On Sat, Jan 17, 2009 at 1:33 PM, Dan Brickley dan...@danbri.org wrote: On 17/1/09 19:27, Sam Ruby wrote: On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers shell...@burningbird.net wrote: The debate about RDFa highlights a disconnect in the decision making related to HTML5. Perhaps. Or perhaps not. I am far from an apologist for Hixie, (nor for that matter and I a strong advocate for RDF), but I offer the following question and observation. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. So, I take it that it isn't essential that RDFa information be included in the DOM? This is not rhetorical: I honestly don't know the answer to this question. Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. The fact that this works anywhere at all today implies that little, if any, changes to browsers is required in order to support this. Is that a fair statement? I've not taken a look at the code, but have taken a quick glance at the output using IE8.0.7000.0 beta, Safari 3.2.1/Windows, Chrome 1.0.154.43, Opera 9.63, and Firefox 3.0.5. The page is different (as in less functional) under IE8 and Safari. Is there something that they need to do which is not already covered in the HTML5 specification in order to support this? I would think we would have to go through the code to see what this specific instance of client-side access of the RDFa isn't working. The debugger I'm using with IE8 shows the problem is occuring in the jQuery code, not necessarily anything specific to the RDFa plugin. I know other JavaScript libraries that work with RDFa work, at least with Safari. For instance: http://www.w3.org/2006/07/SWD/RDFa/impl/js/ Since this library was vetted for IE7, would assume it would work for IE8, too. Of course, the RDFa attributes aren't incorporated into HTML5, which means their use would result in an invalid document. And of course, if they were incorporated, the issue of namespace for them would have to be addressed as namespaces were for MathML and SVG. Shelley - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 17, 2009, at 20:33, Dan Brickley wrote: Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. Does this code run the same way on both DOMs parsed from text/html and application/xhtml+xml in existing browsers without at any point branching on a condition that is a DOM difference between text/html- originated and application/xhtml+xml-originated DOMs? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Ian Hickson wrote: On Sat, 17 Jan 2009, Sam Ruby wrote: Shelley Powers wrote: So, why accept that we have to use MathML in order to solve the problems of formatting mathematical formula? Why not start from scratch, and devise a new approach? Ian explored (and answered) that here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html Key to Ian's decision was the importance of DOM integration for this vocabulary. If DOM integration is essential for RDFa, then perhaps the same principles apply. If not, perhaps some other principles may apply. Sam's point here bears repeating, because there seems to be an impression that we took on SVG and MathML without any consideration, while RDF is getting an unfair reception. On the contrary, SVG and MathML got the same reception. For MathML, for instance, a number of options were very seriously considered, most notably LaTeX. For SVG, we considered a variety of options including VML. I would encourage people to read the e-mail Sam cited: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html It's long, but the start of it is a summary of what was considered and shows that the same process derived from use cases was used for SVG and MathML as is being used on this thread here. I'm not doubting the effort that went into getting MathML and SVG accepted. I've followed the effort associated with SVG since the beginning. I'm not sure if the same procedure was also applied to the canvas object, as well as the SQL query capability. Will assume so. The point I'm making is that you set a precedent, and a good one I think: giving precedence to not invented here. In other words, to not re-invent new ways of doing something, but to look for established processes, models, et al already in place, implemented, vetted, etc, that solve specific problems. Now that you have accepted a use case, Martin's, and we've established that RDFa solves the problem associated with the use case, the issue then becomes is there another data model already as vetted, documented, implemented that would better solve the problem. I propose that RDFa is the best solution to the use case Martin supplied, and we've shown how it is not a disruptive solution to HTML5. The fact that it is based on RDF, a mature, well documented, widely used model with many different implementations is a perk. Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 17, 2009, at 21:38, Shelley Powers wrote: I'm not doubting the effort that went into getting MathML and SVG accepted. I've followed the effort associated with SVG since the beginning. I'm not sure if the same procedure was also applied to the canvas object, as well as the SQL query capability. Will assume so. Note that SVG, MathML and SQL have had different popularity trajectories in top four browser engines than RDF. SVG is going up. At the time it was included in HTML5 (only to be commented out shortly thereafter), three of the top browser engines implemented SVG for retained-mode vector graphics and their SVG support was actively being improved. (One of the top four engines implemented VML, though.) At the time MathML was included in HTML5, it was supported by Gecko with renewed investment into it as part of the Cairo migration. Also, Opera added some MathML features at that time. Thus, two of the top four engines had active MathML development going on. Further, one of the major MathML implementations is an ActiveX control for IE. When SQL was included in HTML5, Apple (in WebKit) and Google (in Gears) had decided to use SQLite for this functionality. Even though Firefox doesn't have a Web-exposed database, Firefox also already ships with embedded SQLite. At that point it would have been futile for HTML5 to go against the flow of implementations. The story of RDF is very different. Of the top four engines, only Gecko has RDF functionality. It was implemented at a time when RDF was a young W3C REC and stuff that were W3C RECs were implemented less critically than nowadays. Unlike SVG and MathML, the RDF code isn't actively developed (see hg logs). Moreover, the general direction seems to be away from using RDF data sources in Firefox internally. Meanwhile, the feed example you gave--RSS 1.0--shows how the feed spec community knowingly moved away from RDF with RSS 2.0 and Atom. Furthermore, RSS 1.0 usually isn't parsed into an RDF graph but is treated as XML instead. If RSS 1.0 is evidence, it's evidence *against* RDF. The point I'm making is that you set a precedent, and a good one I think: giving precedence to not invented here. In other words, to not re-invent new ways of doing something, but to look for established processes, models, et al already in place, implemented, vetted, etc, that solve specific problems. Now that you have accepted a use case, Martin's, and we've established that RDFa solves the problem associated with the use case, the issue then becomes is there another data model already as vetted, documented, implemented that would better solve the problem. Clearly, RDFa wasn't properly vetted--as far as the desire to deploy it in text/html goes--when the outcome was that it ended up using markup that doesn't parse into the DOM the same way in HTML and XML. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers shell...@burningbird.net wrote: I propose that RDFa is the best solution to the use case Martin supplied, and we've shown how it is not a disruptive solution to HTML5. Others may differ, but my read is that the case is a strong one. But I will caution you that a little patience is in order. SVG is not a done deal yet. I've been involved in a number of standards efforts, and I've never seen a case of proposed on a Saturday morning, decided on a Saturday afternoon. One demo is not conclusive. Now you mention that there exists a number of libraries. I think that's important. Very important. Possibly conclusive. But back to expectations. I've seen references elsewhere to Ian being booked through the end of this quarter. I may have misheard, but in any case, my point is the same: if this is awaiting something from Ian, it will be prioritized and dealt with accordingly. If, however, some of the legwork is done for Ian, this may help accelerate the effort. Even little things may help a lot. I know what I'm about to say may be unpopular, but I'll say it anyway: take a few good examples of RDFa and run them through Henri's validator. The validator will helpfully indicate exactly what areas of the spec would need to be updated in order to accommodate RDFa. The next step would be to take a look at those sections. If the update is obvious and straightforward, perhaps nothing more is required. But if not, researching into the options and making recommendations may help. - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Henri Sivonen wrote: On Jan 17, 2009, at 20:33, Dan Brickley wrote: Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. Does this code run the same way on both DOMs parsed from text/html and application/xhtml+xml in existing browsers without at any point branching on a condition that is a DOM difference between text/html-originated and application/xhtml+xml-originated DOMs? I don't want to specifically look at just the one case, since it is not working in Safari, and IE8 and is too complex to debug right at this moment. Generally, though, RDFa is based on reusing a set of attributes already existing in HTML5, and adding a few more. I would assume no differences in the DOM based on XHTML or HTML. The one issue that would occur has to do with the values assigned, not the syntax. I put together a very crude demonstration of JavaScript access of a specific RDFa attribute, about. It's temporary, but if you go to my main web page, http://realtech.burningbird.net, and look in the sidebar for the click me text, it will traverse each div element looking for an about attribute, and then pop up an alert with the value of the attribute. I would use console rather than alert, but I don't believe all browsers support console, yet. Access the page using Firefox, which is served the page as XHTML. Access it as IE8, which gets the page as HTML. You can tell the difference between my graphics are based in inline SVG, and will only show if the page is served as XHTML. So, yes, with my quick, crude demonstration, DOM access is the same in both environments. Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Henri Sivonen wrote: On Jan 17, 2009, at 21:38, Shelley Powers wrote: I'm not doubting the effort that went into getting MathML and SVG accepted. I've followed the effort associated with SVG since the beginning. I'm not sure if the same procedure was also applied to the canvas object, as well as the SQL query capability. Will assume so. Note that SVG, MathML and SQL have had different popularity trajectories in top four browser engines than RDF. SVG is going up. At the time it was included in HTML5 (only to be commented out shortly thereafter), three of the top browser engines implemented SVG for retained-mode vector graphics and their SVG support was actively being improved. (One of the top four engines implemented VML, though.) At the time MathML was included in HTML5, it was supported by Gecko with renewed investment into it as part of the Cairo migration. Also, Opera added some MathML features at that time. Thus, two of the top four engines had active MathML development going on. Further, one of the major MathML implementations is an ActiveX control for IE. When SQL was included in HTML5, Apple (in WebKit) and Google (in Gears) had decided to use SQLite for this functionality. Even though Firefox doesn't have a Web-exposed database, Firefox also already ships with embedded SQLite. At that point it would have been futile for HTML5 to go against the flow of implementations. The story of RDF is very different. Of the top four engines, only Gecko has RDF functionality. It was implemented at a time when RDF was a young W3C REC and stuff that were W3C RECs were implemented less critically than nowadays. Unlike SVG and MathML, the RDF code isn't actively developed (see hg logs). Moreover, the general direction seems to be away from using RDF data sources in Firefox internally. Now wait a second, you're changing the parameters of the requirements. Before, the criteria was based on the DOM. Now you're saying that the browsers actually have to do with something with it. Who is to say what the browsers will do with RDF in the future? In addition, is that the criteria for pages on the web -- that every element in them has to result in different behaviors in browsers, only? What about other user agents? That seems to me to be looking for RDFa sized holes and them throwing them into the criteria, specifically to trip up RDF, and hence, RDFa. Meanwhile, the feed example you gave--RSS 1.0--shows how the feed spec community knowingly moved away from RDF with RSS 2.0 and Atom. Furthermore, RSS 1.0 usually isn't parsed into an RDF graph but is treated as XML instead. If RSS 1.0 is evidence, it's evidence *against* RDF. The point I'm making is that you set a precedent, and a good one I think: giving precedence to not invented here. In other words, to not re-invent new ways of doing something, but to look for established processes, models, et al already in place, implemented, vetted, etc, that solve specific problems. Now that you have accepted a use case, Martin's, and we've established that RDFa solves the problem associated with the use case, the issue then becomes is there another data model already as vetted, documented, implemented that would better solve the problem. Clearly, RDFa wasn't properly vetted--as far as the desire to deploy it in text/html goes--when the outcome was that it ended up using markup that doesn't parse into the DOM the same way in HTML and XML. SVG and MathML were both created as XML, and hence were not vetted for text/html, either. And yet, here they are. Well, here they'll be, eventually. Come to that -- I don't think the creators of SQL actually ever expected that someday SQL queries would be initiated from HTML pages. Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Sam Ruby wrote: On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers shell...@burningbird.net wrote: I propose that RDFa is the best solution to the use case Martin supplied, and we've shown how it is not a disruptive solution to HTML5. Others may differ, but my read is that the case is a strong one. But I will caution you that a little patience is in order. SVG is not a done deal yet. I've been involved in a number of standards efforts, and I've never seen a case of proposed on a Saturday morning, decided on a Saturday afternoon. One demo is not conclusive. Now you mention that there exists a number of libraries. I think that's important. Very important. Possibly conclusive. I am patient. Look at me? I make extensive use of both SVG and RDF -- that is the mark of a patient woman. But back to expectations. I've seen references elsewhere to Ian being booked through the end of this quarter. I may have misheard, but in any case, my point is the same: if this is awaiting something from Ian, it will be prioritized and dealt with accordingly. If, however, some of the legwork is done for Ian, this may help accelerate the effort. First of all, whatever happens has to happen with either vetting by the RDF/RDFa folks, if not their active help. This is my way of saying, I'd be willing to do much of the legwork, but I want to make I don't represent RDFa incorrectly. Secondly, my finances have been caught up in the current downturn, and my first priority has to be on the hourly work and odd jobs I'm getting to keep afloat. Which means that I can't always guarantee 20+ hours a week on a task, nor can I travel. Anywhere. But if both are acceptable conditions, I'm willing to help with tasks. Even little things may help a lot. I know what I'm about to say may be unpopular, but I'll say it anyway: take a few good examples of RDFa and run them through Henri's validator. The validator will helpfully indicate exactly what areas of the spec would need to be updated in order to accommodate RDFa. The next step would be to take a look at those sections. If the update is obvious and straightforward, perhaps nothing more is required. But if not, researching into the options and making recommendations may help. Tasks including this one. Shelley - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, Jan 17, 2009 at 3:51 PM, Shelley Powers shell...@burningbird.net wrote: Sam Ruby wrote: On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers shell...@burningbird.net wrote: I propose that RDFa is the best solution to the use case Martin supplied, and we've shown how it is not a disruptive solution to HTML5. Others may differ, but my read is that the case is a strong one. But I will caution you that a little patience is in order. SVG is not a done deal yet. I've been involved in a number of standards efforts, and I've never seen a case of proposed on a Saturday morning, decided on a Saturday afternoon. One demo is not conclusive. Now you mention that there exists a number of libraries. I think that's important. Very important. Possibly conclusive. I am patient. Look at me? I make extensive use of both SVG and RDF -- that is the mark of a patient woman. But back to expectations. I've seen references elsewhere to Ian being booked through the end of this quarter. I may have misheard, but in any case, my point is the same: if this is awaiting something from Ian, it will be prioritized and dealt with accordingly. If, however, some of the legwork is done for Ian, this may help accelerate the effort. First of all, whatever happens has to happen with either vetting by the RDF/RDFa folks, if not their active help. This is my way of saying, I'd be willing to do much of the legwork, but I want to make I don't represent RDFa incorrectly. Secondly, my finances have been caught up in the current downturn, and my first priority has to be on the hourly work and odd jobs I'm getting to keep afloat. Which means that I can't always guarantee 20+ hours a week on a task, nor can I travel. Anywhere. But if both are acceptable conditions, I'm willing to help with tasks. I don't see any of that as being a problem. Even little things may help a lot. I know what I'm about to say may be unpopular, but I'll say it anyway: take a few good examples of RDFa and run them through Henri's validator. The validator will helpfully indicate exactly what areas of the spec would need to be updated in order to accommodate RDFa. The next step would be to take a look at those sections. If the update is obvious and straightforward, perhaps nothing more is required. But if not, researching into the options and making recommendations may help. Tasks including this one. Excellent. Well, all except for the downturn thing, but you know what I mean. In order to prevent any misunderstandings: it is not for me to assign work. In fact, nobody here is in such a position. People simply note things that need to be done, and do the ones that interest them, at the pace at which they are able. And communicate copiously. If you need help in vetting, I am given to understand that there is a small pocket of RDF enthusiasm in the W3C. :-P Shelley - Sam Ruby
Re: [whatwg] onerror
On 1/17/09, Anne van Kesteren ann...@opera.com wrote: On Sat, 17 Jan 2009 19:24:56 +0100, Jonas Sicking jo...@sicking.cc wrote: I'm talking about parity with other onX attributes inside workers. But I'd be fine with changing onX for other objects if all other browsers do something else, but thats orthogonal to the issue I originally brought up in this thread. Not quite, because I'd like HTML5 onX attributes to do the same as Web Workers onX attributes. (And the same for where else there are onX attributes, e.g. XMLHttpRequest.) Thats fine, but I think we are going to make some exceptions on the window object due I the risk of collisions with global variables. We do that with many other things than onX properties. / Jonas
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Saturday 2009-01-17 22:25 +0200, Henri Sivonen wrote: The story of RDF is very different. Of the top four engines, only Gecko has RDF functionality. It was implemented at a time when RDF was a young W3C REC and stuff that were W3C RECs were implemented less critically than nowadays. Actually, the implementation was well underway *before* RDF was a W3C REC, done by a team led by one of the designers of RDF. In other words, it was in Gecko because there were RDF advocates at Netscape (although advocating, I think, a somewhat different RDF than the current RDF recommendations). Compare the dates on: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ http://www.w3.org/TR/1999/PR-rdf-schema-19990303/ http://bonsai.mozilla.org/cvsquery.cgi?treeid=defaultmodule=allbranch=HEADbranchtype=matchdir=mozilla%2Frdffile=filetype=matchwho=whotype=matchsortby=Datehours=2date=explicitmindate=1998-01-01maxdate=1999-01-01cvsroot=%2Fcvsroot -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 17, 2009, at 22:35, Shelley Powers wrote: Generally, though, RDFa is based on reusing a set of attributes already existing in HTML5, and adding a few more. Also, RDFa uses CURIEs which in turn use the XML namespace mapping context. I would assume no differences in the DOM based on XHTML or HTML. The assumption is incorrect. Please compare http://hsivonen.iki.fi/test/moz/xmlns-dom.html and http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml Same bytes, different media type. I put together a very crude demonstration of JavaScript access of a specific RDFa attribute, about. It's temporary, but if you go to my main web page,http://realtech.burningbird.net, and look in the sidebar for the click me text, it will traverse each div element looking for an about attribute, and then pop up an alert with the value of the attribute. I would use console rather than alert, but I don't believe all browsers support console, yet. This misses the point, because the inconsistency is with attributes named xmlns:foo. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 17, 2009, at 22:43, Shelley Powers wrote: Henri Sivonen wrote: On Jan 17, 2009, at 21:38, Shelley Powers wrote: I'm not doubting the effort that went into getting MathML and SVG accepted. I've followed the effort associated with SVG since the beginning. I'm not sure if the same procedure was also applied to the canvas object, as well as the SQL query capability. Will assume so. Note that SVG, MathML and SQL have had different popularity trajectories in top four browser engines than RDF. SVG is going up. At the time it was included in HTML5 (only to be commented out shortly thereafter), three of the top browser engines implemented SVG for retained-mode vector graphics and their SVG support was actively being improved. (One of the top four engines implemented VML, though.) At the time MathML was included in HTML5, it was supported by Gecko with renewed investment into it as part of the Cairo migration. Also, Opera added some MathML features at that time. Thus, two of the top four engines had active MathML development going on. Further, one of the major MathML implementations is an ActiveX control for IE. When SQL was included in HTML5, Apple (in WebKit) and Google (in Gears) had decided to use SQLite for this functionality. Even though Firefox doesn't have a Web-exposed database, Firefox also already ships with embedded SQLite. At that point it would have been futile for HTML5 to go against the flow of implementations. The story of RDF is very different. Of the top four engines, only Gecko has RDF functionality. It was implemented at a time when RDF was a young W3C REC and stuff that were W3C RECs were implemented less critically than nowadays. Unlike SVG and MathML, the RDF code isn't actively developed (see hg logs). Moreover, the general direction seems to be away from using RDF data sources in Firefox internally. Now wait a second, you're changing the parameters of the requirements. I'm explaining how SVG, MathML and SQL are different from RDF(a) in a way that's very relevant to the practice of including stuff in the spec. Before, the criteria was based on the DOM. Now you're saying that the browsers actually have to do with something with it. Who is to say what the browsers will do with RDF in the future? http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/016045.html is a message where one of the editors of RDFa mentions RDFa together with client-side tools like Ubiquity. That Ubiquity is a Firefox extension rather than part of the core feature set is an implementation detail. I read this as envisioning browser-sensitivity to RDFa. In addition, is that the criteria for pages on the web -- that every element in them has to result in different behaviors in browsers, only? No. However, most of the time, when people publish HTML, they do it to elicit browser behavior when a user loads the HTML document in a browser. Meanwhile, the feed example you gave--RSS 1.0--shows how the feed spec community knowingly moved away from RDF with RSS 2.0 and Atom. Furthermore, RSS 1.0 usually isn't parsed into an RDF graph but is treated as XML instead. If RSS 1.0 is evidence, it's evidence *against* RDF. The point I'm making is that you set a precedent, and a good one I think: giving precedence to not invented here. In other words, to not re-invent new ways of doing something, but to look for established processes, models, et al already in place, implemented, vetted, etc, that solve specific problems. Now that you have accepted a use case, Martin's, and we've established that RDFa solves the problem associated with the use case, the issue then becomes is there another data model already as vetted, documented, implemented that would better solve the problem. Clearly, RDFa wasn't properly vetted--as far as the desire to deploy it in text/html goes--when the outcome was that it ended up using markup that doesn't parse into the DOM the same way in HTML and XML. SVG and MathML were both created as XML, and hence were not vetted for text/html, either. And yet, here they are. Well, here they'll be, eventually. Actually, the creators of MathML had the good sense and foresight to avoid name collisions with HTML even after Namespaces theoretically gave them a permission not to care. Unlike the creators of RDFa, the creators of SVG weren't pushing for inclusion in HTML5 or saying that it's OK to serve their XML as text/ html--quite the contrary. And the integration would have been nicer if the SVG WG had had the same prudence as the Math WG. Come to that -- I don't think the creators of SQL actually ever expected that someday SQL queries would be initiated from HTML pages. I don't see the creators of SQL asking for the inclusion of their stuff in HTML after building on another spec that is well-known to be trouble with HTML (Namespaces in XML in
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
The assumption is incorrect. Please compare http://hsivonen.iki.fi/test/moz/xmlns-dom.html and http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml Same bytes, different media type. I put together a very crude demonstration of JavaScript access of a specific RDFa attribute, about. It's temporary, but if you go to my main web page,http://realtech.burningbird.net, and look in the sidebar for the click me text, it will traverse each div element looking for an about attribute, and then pop up an alert with the value of the attribute. I would use console rather than alert, but I don't believe all browsers support console, yet. This misses the point, because the inconsistency is with attributes named xmlns:foo. And I also said that we would have to address the issue of namespaces, which actually may require additional effort. I said that the addition of RDFa would mean the addition of some attributes, and we would have to deal with namespace issues. Just like the HTML5 working group is having to deal with namespaces with MathML and SVG. And probably the next dozen or so innovations that come along. That is the price for not having distributed extensibility. One works the issues. I assume the same could be said of any many of the newer additions to HTML5. Are you then saying that this will be a showstopper, and there will never be either a workaround or compromise? Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, Jan 17, 2009 at 5:51 PM, Henri Sivonen hsivo...@iki.fi wrote: On Jan 17, 2009, at 22:35, Shelley Powers wrote: Generally, though, RDFa is based on reusing a set of attributes already existing in HTML5, and adding a few more. Also, RDFa uses CURIEs which in turn use the XML namespace mapping context. I would assume no differences in the DOM based on XHTML or HTML. The assumption is incorrect. Please compare http://hsivonen.iki.fi/test/moz/xmlns-dom.html and http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml Same bytes, different media type. The W3C Recommendation for DOM also describes a readonly attribute on Attr named 'name'. Discuss. I put together a very crude demonstration of JavaScript access of a specific RDFa attribute, about. It's temporary, but if you go to my main web page,http://realtech.burningbird.net, and look in the sidebar for the click me text, it will traverse each div element looking for an about attribute, and then pop up an alert with the value of the attribute. I would use console rather than alert, but I don't believe all browsers support console, yet. This misses the point, because the inconsistency is with attributes named xmlns:foo. There is a similar inconsistency in how xml:lang is handled. Discuss. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, 17 Jan 2009, Sam Ruby wrote: But back to expectations. I've seen references elsewhere to Ian being booked through the end of this quarter. I may have misheard, but in any case, my point is the same: if this is awaiting something from Ian, it will be prioritized and dealt with accordingly. For what it's worth, my current plan running up to last call in October includes an item in April for me to go through all the use cases that have by that point been put forward in the data markup space, and to work out for each use case and on the aggregate: 1. Whether there is compelling evidence that users want that use case addressed (e.g. whether there are successful companies addressing that use case using proprietary solutions or ad-hoc extensions to HTML, or whether there are usability studies or some independent market research showing demand from users, or whether it can be demonstrated that users are avoiding the Web because it doesn't address this problem). 2. Whether the use case is being addressed well enough already (e.g. if there are companies addressing this use case adequately, or whether the current solutions really are just hacks with numerous problems). 3. What the requirements are for each use case. 4. What solutions are available to address these use cases. 5. For each solution, whether it addresses the requirements. 6. Whether the relevant implementors are interested in implementing solutions for these use cases (e.g. whether authoring tools are willing to expose the feature, whether validator writers want to check for the correctness, whether browser vendors are willing to expose the relevant UI, whether search engine companies are willing to use the data, or whatever else might be appropriate). The more use cases there are, the better informed the results will be. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
