Re: [whatwg] Navigation events generated during unload
AFAIK, only one event can run at a time. JavaScript has only one thread, so an event generated while another event listener is executing is placed in a queue, to be executed when the current execution thread is done. With onunload, the entire page is unloaded after the event (if it returns true), so the next event in the queue is ignored. Marius Gundersen On Tue, Sep 22, 2009 at 3:45 PM, Adam Barth wha...@adambarth.com wrote: I looked around in the HTML5 draft, but it wasn't obvious to me if it explains how to handle navigation events generated during the unload event. As far as I can tell by testing browsers, these navigation events are ignored. Adam
Re: [whatwg] Navigation events generated during unload
Everything you say is true, but it is possible to generate navigation events synchronously. For example, you can programmatically submit a form to about:blank. Adam On Mon, Sep 21, 2009 at 11:02 PM, Marius Gundersen gunder...@gmail.com wrote: AFAIK, only one event can run at a time. JavaScript has only one thread, so an event generated while another event listener is executing is placed in a queue, to be executed when the current execution thread is done. With onunload, the entire page is unloaded after the event (if it returns true), so the next event in the queue is ignored. Marius Gundersen On Tue, Sep 22, 2009 at 3:45 PM, Adam Barth wha...@adambarth.com wrote: I looked around in the HTML5 draft, but it wasn't obvious to me if it explains how to handle navigation events generated during the unload event. As far as I can tell by testing browsers, these navigation events are ignored. Adam
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Sat, 19 Sep 2009 13:49:15 +0200, Michael A. Puls II shadow2...@gmail.com wrote: Currently, registerProtcolHandler works like this: navigator.registerProtocolHandler(protocol, http://example.org/?uri=%s;, title); However, this doesn't allow the site to specify some useful and important information about the site like: 1. What encoding the server expects. For example, uri= might expect the protocol link that was invoked in the browser to be interpreted as koi8-r instead of utf-8. This might be the case even if the page that uses registerProtocolHandler uses Windows-1251 for example. The IRI specification dictates UTF-8 already. 2. The location of an icon like a favicon.ico file or png etc. Is this not already known? Or is there no same-origin restriction on these methods? 3. URI to a help page where the site explains how it makes uses of registerProtocolHandler and gives help and support contacts etc. How does this help the user? 4. Whether to use POST instead of GET. That seems dangerous. Following a link should always use GET. [...] Point being, registerProtocolHandler needs to be more robust. And, although this post is long, the requested additions are quite simple to specify. Maybe these things can be supported in registerProtocolHandler v.02 once sites like the above prove that they are needed. I don't see why existing sites would not update what they accept to make registerProtocolHandler work. And if user agents want to support sites that do not support registerProtocolHandler that is their business I think and not an necessarily an issue for the feature. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
2. The location of an icon like a favicon.ico file or png etc. This is actually a real privacy issue. The user agent would periodically fetch a remove favicon, which discloses the end user's ip. If any, such favicon would need to be made available offline immediately when installing the protocol handler, or a data uri could be used.
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Tue, 22 Sep 2009 09:54:12 -0400, João Eiras jo...@opera.com wrote: 2. The location of an icon like a favicon.ico file or png etc. This is actually a real privacy issue. The user agent would periodically fetch a remove favicon, which discloses the end user's ip. If you go to a site that uses registerProtocolHandler and you allow it to register the handler, you already trust that site and have already disclosed your ip to it. You'll disclose your ip to it again each time you visit the site. Now, if the site, which I obviously trust given the above, knows that my browser is fetching the favicon fresh now and then and can see my ip (and can even set a cookie when requesting the favicon), I think that's a non-issue. However... If any, such favicon would need to be made available offline immediately when installing the protocol handler O.K., that would be acceptable. And, the UA could allow the *user* to explicitly refetch the icon if they ever wanted to. The UA wouldn't even really have to allow a refetch as the user could just go back to the site and re-register then handler. -- Michael
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Tue, 22 Sep 2009 09:10:02 -0400, Anne van Kesteren ann...@opera.com wrote: On Sat, 19 Sep 2009 13:49:15 +0200, Michael A. Puls II shadow2...@gmail.com wrote: Currently, registerProtcolHandler works like this: navigator.registerProtocolHandler(protocol, http://example.org/?uri=%s;, title); However, this doesn't allow the site to specify some useful and important information about the site like: 1. What encoding the server expects. For example, uri= might expect the protocol link that was invoked in the browser to be interpreted as koi8-r instead of utf-8. This might be the case even if the page that uses registerProtocolHandler uses Windows-1251 for example. The IRI specification dictates UTF-8 already. But sites might not follow it. 2. The location of an icon like a favicon.ico file or png etc. Is this not already known? Or is there no same-origin restriction on these methods? Do you mean, is the location known like favicon.ico at the root of the site? It's not always in that spot. And, if it's not a favicon, but a png for example, it could be anywhere on the site. 3. URI to a help page where the site explains how it makes uses of registerProtocolHandler and gives help and support contacts etc. How does this help the user? Say the user sees that things are not working right with the handler. The user goes into the options to see what's doing with the handler settings and notices the link. The user clicks on it. Then, on the page, it says Attention: We've changed some things with what our server accepts from our protocol handler. You need to register the handler again by clicking here to get the updated version for example. User does and is happy again. :) Now, the user could go hunting through the site to find that page, but the link is much more user-friendly. 4. Whether to use POST instead of GET. That seems dangerous. Following a link should always use GET. But, I don't think it's necessarily following a link in the normal sense. It's launching a trusted web-based application, where POST could be used to support longer data. Sure, it's great to look at the query to see what's being submitted (if it's in a format that you know how to decode). By default though, the handler only works on pages for the site that registered the handler, so it'd be like just using a form POST right on the site. [...] Point being, registerProtocolHandler needs to be more robust. And, although this post is long, the requested additions are quite simple to specify. Maybe these things can be supported in registerProtocolHandler v.02 once sites like the above prove that they are needed. I don't see why existing sites would not update what they accept to make registerProtocolHandler work. I do. Sites can be a pain. :) And if user agents want to support sites that do not support registerProtocolHandler that is their business I think and not an necessarily an issue for the feature. Sure, but if registerProtocolHandler is robust, users don't have to wait around for browsers to do that. registerProtcolHandler would be self-sufficient. I think it's important to have robust tools to allow users to make things work when either the site or the browser or both are of no help. But, my main point in all this is if the UA has more than just a plain UI, it could make use of more info given by registerProtocolHandler to make things nicer. In short though, I think registerProtocolHandler is too simple. Maybe that's intentional and browses are encouraged to support some other more advanced function like window.ff|ie|opera|safari|chrome_advancedRegisterProtocolHandler, but why do that when registerProtocolHandler could? But, understood if you don't share my enthusiasm. -- Michael
Re: [whatwg] object behavior
On Mon, Sep 21, 2009 at 5:26 PM, Michael A. Puls II shadow2...@gmail.com wrote: On Mon, 21 Sep 2009 16:30:29 -0400, Boris Zbarsky bzbar...@mit.edu wrote: Of course, if the idea is to support deferring for images, object and embed etc. and it's not desired that that support be given through css, perhaps there should be some attribute that does that. img disabled object disabled embed disabled etc. where .disabled = false brings them alive. I would prefer something like this. Using CSS for this purpose seems wrong. Sounds good. If it is an attribute, I wonder what would be a good name. 'disabled' might be likely to conflict with some plug-in param and might conflict with object and img when they are form controls. The obvious answer seems to be to use @hidden, which indicates that the element is not currently relevant and should not be displayed. ~TJ
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Tue, 22 Sep 2009 17:32:59 +0200, Michael A. Puls II shadow2...@gmail.com wrote: On Tue, 22 Sep 2009 09:10:02 -0400, Anne van Kesteren ann...@opera.com wrote: The IRI specification dictates UTF-8 already. But sites might not follow it. Then they will need to be updated if they want to work with registerProtocolHandler and pretty much any form of requests to their URL space they do not control themselves (i.e. is not initiated by following some HTML link on their site). Even XMLHttpRequest forces UTF-8. Is this not already known? Or is there no same-origin restriction on these methods? Do you mean, is the location known like favicon.ico at the root of the site? It's not always in that spot. And, if it's not a favicon, but a png for example, it could be anywhere on the site. I have a PNG called favicon.ico on my site, but what I meant is that the user has likely visited the site already so a favicon of some sorts will be known. Also, this only matters when registering for the handler and having icon support there might actually make phishing easier as the user would recognize the icon and maybe ignore the text. 3. URI to a help page where the site explains how it makes uses of registerProtocolHandler and gives help and support contacts etc. How does this help the user? Say the user sees that things are not working right with the handler. The user goes into the options to see what's doing with the handler settings and notices the link. The user clicks on it. Then, on the page, it says Attention: We've changed some things with what our server accepts from our protocol handler. You need to register the handler again by clicking here to get the updated version for example. User does and is happy again. :) Now, the user could go hunting through the site to find that page, but the link is much more user-friendly. What can possibly go wrong that the site cannot fix with a redirect of some sorts? 4. Whether to use POST instead of GET. That seems dangerous. Following a link should always use GET. But, I don't think it's necessarily following a link in the normal sense. It's launching a trusted web-based application, where POST could be used to support longer data. Sure, it's great to look at the query to see what's being submitted (if it's in a format that you know how to decode). By default though, the handler only works on pages for the site that registered the handler, so it'd be like just using a form POST right on the site. I don't quite see how you envision this to work. I suppose at some point unknown protocols could be made to work in form. Dunno though. And if user agents want to support sites that do not support registerProtocolHandler that is their business I think and not an necessarily an issue for the feature. Sure, but if registerProtocolHandler is robust, users don't have to wait around for browsers to do that. registerProtcolHandler would be self-sufficient. It is robust. Adding lots of complexity is likely to make it less so. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Tue, 22 Sep 2009 11:46:01 -0400, Anne van Kesteren ann...@opera.com wrote: On Tue, 22 Sep 2009 17:32:59 +0200, Michael A. Puls II shadow2...@gmail.com wrote: On Tue, 22 Sep 2009 09:10:02 -0400, Anne van Kesteren ann...@opera.com wrote: Is this not already known? Or is there no same-origin restriction on these methods? Do you mean, is the location known like favicon.ico at the root of the site? It's not always in that spot. And, if it's not a favicon, but a png for example, it could be anywhere on the site. I have a PNG called favicon.ico on my site, but what I meant is that the user has likely visited the site already so a favicon of some sorts will be known. O.K., I see. Thank for clarifying. In those cases, a favicon will most likely be already known. But, take Opera's webmailproviders.ini for example. You have to manually specify the icon location. It's not discovered automatically through other means. If the user allowed registerProtocolHandler to add a webmail entry to the file, being able to say what icon to load would be great. But, even if a favicon (or other type of pic) can be discovered automatically, will the browser pick the right one? Maybe there's a specific file that should be used. Now, if every UA's protocol configuration is going to be plain jane text-only, then an icon for example isn't an issue. -- Michael
Re: [whatwg] object behavior
On Tue, 22 Sep 2009 11:42:25 -0400, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Sep 21, 2009 at 5:26 PM, Michael A. Puls II shadow2...@gmail.com wrote: On Mon, 21 Sep 2009 16:30:29 -0400, Boris Zbarsky bzbar...@mit.edu wrote: Of course, if the idea is to support deferring for images, object and embed etc. and it's not desired that that support be given through css, perhaps there should be some attribute that does that. img disabled object disabled embed disabled etc. where .disabled = false brings them alive. I would prefer something like this. Using CSS for this purpose seems wrong. Sounds good. If it is an attribute, I wonder what would be a good name. 'disabled' might be likely to conflict with some plug-in param and might conflict with object and img when they are form controls. The obvious answer seems to be to use @hidden, which indicates that the element is not currently relevant and should not be displayed. O.K., so object hidden would prevent the object from being evaluated. That would mean that nothing will load in it (plug-in, image or document etc.) and nothing in @data would be fetched. Then, if you remove @hidden or do .hidden = false, the object would be evaluated and things would be fetched and loaded depending on @type and @data etc. Then, if you set @hidden or do .hidden = true, the plug-in instance or document (caches aside) would be destroyed and the object would be hidden again and be back to its declared-only state. Finally, a hidden object would obviously not be shown visibly , but would also take up zero space. I guess it could be @noeval instead of @hidden if you like @noeval better. -- Michael
[whatwg] [Fwd: [hybi] Proposed charter for HyBi BoF in Hiroshima]
please provide comments on the HyBi mailing list ( https://www.ietf.org/mailman/listinfo/hybi ). cheers Salvatore Loreto www.sloreto.com Original Message Subject:[hybi] Proposed charter for HyBi BoF in Hiroshima Date: Tue, 22 Sep 2009 00:15:46 -0600 From: Joe Hildebrand joe.hildebr...@webex.com To: h...@ietf.org Please suggest changes, this is just a first draft that tries to capture several conversations that we've had, including the bar BoF in Stockholm. -- Joe Hildebrand Chairs: * TBD * TBD Applications Area Director(s): * Lisa Dusseault lisa.dussea...@gmail.com * Alexey Melnikov alexey.melni...@isode.com Applications Area Advisor: * Lisa Dusseault lisa.dussea...@gmail.com Mailing Lists: General Discussion: h...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hybi Archive: http://www.ietf.org/mail-archive/web/hybi/current/maillist.html Description of Working Group: HTTP has in the past been used as a request/response protocol most often, leading to clients polling for new data or users hitting the refresh button in their browsers. Newer web applications are finding ways to push data from the server to the client as soon as it is available, through a variety of mechanisms. The Hypertext-Bidirectional (HyBi) working group will seek standardization of approaches that HTTP clients, servers, and intermediate boxes can use to communicate with one another in both directions. Since any modification of the web infrastructure may take a good amount of time to be deployed, outputs of the working group will include both short and long term solutions. The existing web being much more complicated than it seems, the working group will prioritize the characterization of the design space, including the web clients, intermediaries, firewalls, NATs, web servers, etc. into which both solutions will need to be deployed. For both short and long term, the amount of semantic encoded at the HyBi layer will be minimized, allowing multiple higher-level protocols to take advantage of the basic eventing mechanism. These higher-level protocols are out of scope for the working group, although liaison with other working groups will be encouraged. The short term approach will be deployable on today's Internet, across whichever current or historical web browsers the working group decides upon. Although wide browser support is a goal, lack of support on any single browser version will not be a sufficient cause to block consensus. The short term approach may also define hints to allow newer intermediaries to optimize traffic. In the long term, new features will be required of clients, servers, or intermediaries allowing a more scalable and robust end-to-end experience. Although multiple protocols exist as starting points for both the short and long term, backward compatibility with these protocols is not a requirement. In particular, the working group will liaison with the HTML5 working group of the W3C around the websockets protocol; if agreed by both parties, the HyBi working group may take over the development of the websockets protocol. The Working Group should consider: * Implementer experience * Impact on existing implementations and deployments * Ability to achieve broad implementation * Ability to address broader use cases than may be contemplated by the original authors The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Define requirements for short- and long-term solutions, including characterization of the design space * Define a short-term solution for the bi-directional web, deployable on today's Internet * Define a long-term solution for the bi-directional web, which will likely require modifications to the web infrastructure ___ hybi mailing list h...@ietf.org https://www.ietf.org/mailman/listinfo/hybi
[whatwg] Potentially avoidable tokeniser/treebuilder dependency
As currently specified, the tokeniser is mostly, but not completely, independent of the treebuiilder. The major obstacle for an independent tokeniser seems to be that the content model flag is set to RCDATA, RAWTEXT or PLAINTEXT by the treebuilder and not by the tokeniser. In most cases, the new content model flag is entirely predictable from the start tag (and RCDATA/ RAWTEXT element names are known to the tokeniser already). The only exceptions I have found so far concern start tags within select and frameset, which are dropped by the treebuilder and therefore do not cause the content model flag to change. Even these cases could perhaps have been handled by the tokeniser without too much trouble (and without changing the spec) if it were not for the in select in table insertion mode, where a missing /select end tag may be inferred depending on the stack of open elements. It seems unfortunate to abandon the possibility of an independent tokeniser just to handle what appears to be a corner case of a corner case, viz, unclosed RCDATA/RAWTEXT elements inside an unclosed select element in a table. The easiest solution would be to switch the content model flag upon seeing an RCDATA/RAWTEXT/PLAINTEXT start tag irrespective of insertion mode, i.e., also within select and frameset, which would allow the tokeniser to take care of this without added complexity. Other solutions might be worth considering if this is found to be too incompatible with existing pages. (I could have a look at the the http://www.dotnetdotcom.org/ dataset if that would be of any use.) (A tiny bit of context: I recently implemented most of the tokeniser in lex in the view of using it as a tool to investigate the use of named character references in existing documents. It uses about 20 start conditions instead of the spec's 39 states and two flags, is fairly compact and readable (500 lines compared to 5,500 in the Validator.nu implementation), and runs about 35 times faster than the full Validator.nu HTML Parser (both under highly suboptimal conditions). Unfortunately, it is of little use without a treebuilder to set the content model flag. It has been pointed out that use cases for which a tree is not needed may not require perfect tokenisation; even if that be true, it is much more difficult to assure that an approximate implementation is sufficiently close than to follow the specification; perhaps more importantly, removing unnecessary dependencies and allowing the tokeniser to run on its own would also make it easier to develop and test a tokeniser for use as part of a full parser.) -- Øistein E. Andersen
Re: [whatwg] the cite element
On Wed, 16 Sep 2009, Erik Vorhes wrote: On Wed, Sep 16, 2009 at 4:16 AM, Ian Hickson i...@hixie.ch wrote: Unless there is some semantic value to the name being more than just a name, yes. Is there? Yes What is it? and with the removal of the dialog element (of which I was unaware when I sent my last message) makes a compelling case for the re-expansion of cite for dialog. Why? On October 31, 2006, Michael Fortin suggested the following pattern: pciteMe:/cite qCan I say something?/q Which Jeremy Keith also recommends. [1] (For longer text it would make more sense to do something like cite/citeblockquote/blockquote, but that's beside the point.) You didn't explicitly object to such a pattern (though implemented a different one for dialog) as late as May 5, 2008 [2]. You don't think this is all moot is explicit enough? :-) Aside from the current definition of cite, I think this would be a good use of the element, since it makes more sense than b or span (what do those signify in this context?) and there's nothing wrong with an italicized name in this context. Moreover, there are examples of Fortin/Keith's usage in the wild. I don't understand why we need an element here at all, and I don't understand why we would want to reuse cite, of all elements, if we did in fact need one. ... I don't understand what your proposal is, at this point. How do you define citation? What problem does it solve? I should have made this clearer, I suppose, sorry. What I propose is that cite should be allowed for markup in the following instances: - titles of works - full citations - names and other sources of quote attribution (including identifying speakers in dialog) - names of blog post commenters and authors (in the context of their comments, posts, etc.) That seems like a really strange and eclectic variety of uses. It seems like authors are better served with more focused elements or with elements where there's no seeming gaps in what the element can be used. For example, it seems odd to say that in the following, the third cite is non-conforming, but the other two are fine: article footerComment by citeJohn Adams/cite/footer pI think that the following comment by citeFred Fox/cite is right:/p blockquote pTomatoes are juicy./p /blockquote pHowever, I like to visit citeIan/cite and he does not like them at all./p /article It seems like it would be better to not have any elements for the bottom three definitions you list, or to introduce a new element for those that have use cases. However, no compelling use cases have been mentioned as far as I am aware. On Wed, 16 Sep 2009, Erik Vorhes wrote: A use-case for person's name in the context of cite: In reference to many Classical texts one will often refer to the author in lieu of the title (or in some cases that author's corpus). E.g.: pYou should read citeHerodotus/cite./p That's a fine use of cite, though, because there Herodotus is being used as the name of a work (albeit not the name printed on the cover). On Mon, 21 Sep 2009, Erik Vorhes wrote: I never suggested otherwise. I want to be able to mark up names, etc., not just titles of works, with cite when the context is appropriate. That is, I want to mark up these things when they function as an attribution. (As I have previously detailed.) I'm still having trouble with the why. Could you elaborate on why you need to mark these up explicitly? I feel here that you're stretching the definition of title of work beyond its usefulness. If we can use aliases within cite, great, but that seems to make more apparent the usefulness of having cite be for more than just title of work. There's two uses that I know of: making titles of works italics by default, and making it easier to change that style. In: pYou should read citeHerodotus/cite./p On Wed, 16 Sep 2009, Jim Jewett wrote: Ian wrote: Eric wrote: Put another way, if you had no prior knowledge of the current HTML5 definition of cite (and perhaps any other specification's definition of the element), what would seem to be logical and appropriate uses of the element? You mean based on just the element name? I wouldn't use it without reading the spec first. Most people seem to think it means italics, though, for what that's worth. I think that gets at the root of the problem with cite. Most people don't read the spec, or even know where to find it. cite isn't common enough to just copy by example, and it turns out to be ambiguous as the name of an element or attribute. Agreed. Not sure what to do about that, though; removing the whole element seems a little brutal since it is used and isn't causing that much harm. Do you wrap the actual excerpt (the precise thing you're citing), or the name of the source? If you wrap the name/title of the source, is there a way to show the
Re: [whatwg] the cite element
On Tue, Sep 22, 2009 at 8:46 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 16 Sep 2009, Erik Vorhes wrote: On Wed, Sep 16, 2009 at 4:16 AM, Ian Hickson i...@hixie.ch wrote: Unless there is some semantic value to the name being more than just a name, yes. Is there? Yes What is it? cite points to a primary source of the statement, as opposed to an someone merely named by the statement. and with the removal of the dialog element (of which I was unaware when I sent my last message) makes a compelling case for the re-expansion of cite for dialog. Why? dialogues and transcripts and credits and theatrical scripts are all arguably too fine-grained for a citation, as opposed to a label or attribution, but they are certainly real use cases where the attribution is important. These three are even cases where print sources will typically shift font in some way between the attribution (bMephistopheles/b) and the actual statement, though not always in the same manner. Of the three that I found first, NAME IN ALL CAPS Indented lines, said or sung aloud. iName./i Statement begins here. BY MS LASTNAME: Q.Attorney's question. A.Witness answers. Q.Attorney's next question. A.Next response. On October 31, 2006, Michael Fortin suggested the following pattern: pciteMe:/cite qCan I say something?/q Which Jeremy Keith also recommends. [1] ... Aside from the current definition of cite, I think this would be a good use of the element, since it makes more sense than b or span (what do those signify in this context?) and there's nothing wrong with an italicized name in this context. Moreover, there are examples of Fortin/Keith's usage in the wild. I don't understand why we need an element here at all, and I don't understand why we would want to reuse cite, of all elements, if we did in fact need one. That Me: isn't pronounced; it is metadata so important that it gets written (in an odd style) in printed form. The punctuation (followed by a new sentence, complete with initial capitals) is the closest a typewriter can come to markup, and scripts will typically make the difference more emphatic. I'll agree that it seems odd to have that many cite elements in such close proximity, but it is the closest match I can find in the spec, and it doesn't seem to be actually wrong. Searching for lines by a particular character is a fairly common use case. ... How do you define citation? What problem does it solve? cite should be allowed for markup in the following instances: - titles of works - full citations - names and other sources of quote attribution (including identifying speakers in dialog) - names of blog post commenters and authors (in the context of their comments, posts, etc.) That seems like a really strange and eclectic variety of uses. All boil down to says who?. A title of a work indicates something about when they said it, and how (formally enough to have a title), but ... so does a hyperlink to the author. For example, it seems odd to say that in the following, the third cite is non-conforming, but the other two are fine: article footerComment by citeJohn Adams/cite/footer pI think that the following comment by citeFred Fox/cite is right:/p blockquote pTomatoes are juicy./p /blockquote pHowever, I like to visit citeIan/cite and he does not like them at all./p /article Please do some hallway testing on this. Ask half a dozen people what they think of this markup. If you have to prompt, ask about the use of cite in particular. I'm guessing that most won't even really notice the cites to John Adams or Fred Fox, but almost all will wonder about the cite to Ian. The difference is that John Adams and Fred Fox were the ones saying something -- the cite was attributing something to them. They were actors as opposed to objects in the linguistic sense. Ian was simply an object (a direct object, in this case) that happens to be human. It seems like it would be better to not have any elements for the bottom three definitions you list, or to introduce a new element for those that have use cases. However, no compelling use cases have been mentioned as far as I am aware. Are you seriously saying that there is no need to attribute to names and other sources of quote attribution (including identifying speakers in dialog), or to markup the user name of names of blog post commenters and authors (in the context of their comments, posts, etc.) ??? I haven't yet seen a forum that didn't style usernames of the commentators differently (generally either bold or as a link, rather than italics, but still differently). Nor have I yet seen a script (or published play) that didn't use some styling variation to distinguish the character names from their words. (Usually -- but not quite always -- I see additional variations to indicate character actions, and generic stage directions such as scene endings.) On
