Re: [whatwg] the cite element
On Mon, Oct 5, 2009 at 9:13 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 22 Sep 2009, Jim Jewett wrote: 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. I hate to be so repetitive, but why is that beneficial? What is the semantic value of this? Is there as much semantic value in pointing to the primary source of a statement as there is in knowing that the word earth refers to the planet and not the dirt, for example? If so, what is that extra value? Identifying speakers and other sources of attribution have multiple use-cases, as identified previously to this list. Such uses are often extra-contextual, unlike your example of earth. I don't know how otherwise to respond to such laughably obvious reductio ad absurdum arguments. 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. Why? This is not a rhetorical question, I'm trying to get to the use case that means that there is an actual benefit to what you are asking for. Just saying that it's important doesn't say _why_ it is important. I'm not denying that it is important, I'm just trying to work out _why_, so that the proposal (e.g. to use cite for this) can be properly evaluated. What does cite do that you want? It may not need to be cite, per se, but that is the element that has been used in examples of multiple kinds of quote + attribution markup patterns. And since the WG has a general aversion to creating new elements (except when it doesn't), using cite makes the most sense. To me, recommending b or i or span for such contexts is a nonstarter, as these all appear to be designated for marking up text without conveying any extra importance. The desire is to have speakers' names and other sources of attribution marked up in such a way that sets them apart from the surrounding context. Especially in the cases of dialog and transcription, their being special is important. For example, listen to any of Nina Totenberg's reports on US Supreme Court proceedings, or read just about any printed play text in existence. Above other sources of attribution, it is important for speakers' names to be marked up as distinct from its surrounding context. Moreover, this markup is not something that can be properly conveyed by any element whose primary function is presentation- or typographic-only. I don't buy that at all. It's just one way that people write dialogs, but as far as I can tell this is perfectly adequate: pMe: Can I say something?/p ...and you need neither q nor cite. I really feel that you are trying too hard to solve a problem that really doesn't exist here. Surely you jest. Have you ever read a play? In every instance I have run across, speakers and their words are clearly demarcated (not to mention stage directions, etc. I've started asking people what they think the errors are in the following snippet: article h1Welcome to my home page/h1 pMy name is citeBob Smith/cite./p pI like the book citePandora's Star/cite./p pWhat do you think?/p article citeJames Smith/cite pI'm with you citeBob/cite!/p /article article citeFred/cite pciteJames/cite wrote:/p blockquotepI'm with you citeBob/cite!/p/blockquote pBut I disagree, I think citePat/cite's blog post is better. /article /article ...but frankly I'm having trouble working out which you are proposing to have valid and not, which is not a good sign. Given that I don't see the use case of marking up any of the cites in the above except the book title (which would be styled differently), I really don't see the point of having this level of complexity. Your example hardly dignifies a response, but here goes: 1. The proposal, as far as I can tell, is to allow cite (or some nonexistent element whose name would likely be less logical) to mark up text for attribution, which often would be a name. I don't believe *anyone* is arguing that every name should be marked up with cite. Who are you trying to argue against here? You're not arguing against those of us advocating for additional allowable uses for cite. 2. If you want to play the reductio ad absurdum game, I propose we eliminate article from the specification, because some stupid content author might try to create a document with the following markup
Re: [whatwg] the cite element
On Tue, Oct 6, 2009 at 2:52 PM, Gordon P. Hemsley gphems...@gmail.com wrote: I was discussing the cite element with TabAtkins on IRC and I proposed analyzing the actual word 'cite'. Using it as a verb, the definition of 'cite' applies to quotes/quotations, titles, and people, depending on the context. TabAtkins noted that the first use case is so far off of legacy implementations, that it wouldn't even be worth considering for cite (especially because we have other elements that function as such). That leaves usages of 'cite' for both titles of works and authors of works. Putting aside the issue of styling for a moment, these two pieces of data both fall under the semantic meaning of 'cite'. Thus, they should fall under the semantic meaning of cite. If an author should have the need to differentiate between the two, I propose that they use cite class=title and cite class=author. Thus, I propose the following (which TabAtkins generally agrees with): Leave the default styling of cite to be italicized for legacy implementations and allow any reference to any work or author, with the granularity decided by the individual web developer. +1 for this redefinition. I believe it addresses most common non-title uses of cite without opening it up to the kind of confusion/abuse that Ian and others have been concerned about. It has the added benefit of not adding a new element to the spec. I also propose allowing parenthetical citations and footnote markers (as is used in the various W3C/WHATWG specifications) to also be marked up with cite, though I'm not sure if TabAtkins agrees with me on that point. I suppose a allows for more functionality in current UAs, but this is an interesting proposition, especially if there were a way to crosslink cite used in this way to the original source (or whatever it would point to). Would it be something along the lines of cite for=aside-id, or did you have something else in mind? Erik
Re: [whatwg] the cite element
On Tue, Oct 6, 2009 at 3:31 PM, tjeddo tje...@gmail.com wrote: Erik, Just so you are aware in the future, reductio ad absurdum (aka proof by contradiction) is a legitimate technique used in mathematics and logic to deductively prove statements. I'm not sure your usage of that phrase is correct or common--that is, to simply call someones argument absurd. If you realize that someones argument is absurd it means you have identified at least one invalid statement in the argument. Apologies for the error; in both instances I meant to use slippery slope.
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Wed, Sep 30, 2009 at 3:31 AM, Bruce Lawson bru...@opera.com wrote: On Tue, 29 Sep 2009 20:53:44 +0100, Dean Edwards dean.edwa...@gmail.com wrote: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) Or even just one for both: rubric anyone? rubric and credit (or name) could solve a lot of element rancor on this list (and this icky IE DOM issue). So count me as +1! Erik Vorhes
Re: [whatwg] Bibliography Markup in HTML5
On Sun, Sep 27, 2009 at 8:28 PM, tjeddo tje...@gmail.com wrote: I am surprised at how little concern there seems to be over the lack of bibliography markup in HTML5. Most of this discussion has revolved around the cite element as well as methods to mark-up attribution in such elements as figure. There's also been some discussion about Bibtex as microdata, though I think that's been dropped. I mean, there is new language support for an 'aside' section element but no 'bibliography' section element!? A full-on bibliography (if it's not a separate page) would function well as a section or footer, unless I misunderstand the way those elements are supposed to work. bibliography ... dt id=refsRFC5322[RFC5322]/dt ddcitea href=http://www.ietf.org/rfc/rfc5322.txt;Internet Message Format/a/cite, P. Resnick. IETF, October 2008./dd ... /bibliography The value here is the elimination of ambiguity and that a number of new inferences can now be drawn by user agents. With the dl tags, the interpreting agent can only determine that there is a definition list containing term/definition entries. Whereas, in the context of a new bibliography section element, user agents can unambiguously interpret the 'dt' element to be the displayed content that humans identify a bibliography entry by (e.g., [RFC5322] in the example given). Additionally, in this context the 'dd' element would be defined to contain a representation of a bibliography entry. Of course, more concise definitions for these elements occurring in the bibliography context should be worked out. 1. There'd need to be some clear-cut understanding about what would go in the dt and dd elements. Would the dt before the citation entry and the dd optional for annotation or something? Would multiple dds be allowed per dt? Would authors understand the difference? In your example, it feels like dt is for shorthand bibliographic entry and dd is for longer bibliographic entry, which feels a bit cumbersome and offers pretty good odds for repeated content. 2. I'm not sure the dtdd pattern allows for any useful mnemonic device related to a dedicated bibliography element. My own practice has been to mark-up a bibliography as either a ul or ol within a div, with each li being used to mark discrete items in the list of works cited. Would a more generalized block/inline element to identify attribution (such as credit or my own attempt to expand the function of cite) suit your needs? Erik Vorhes
Re: [whatwg] the cite element
On Sun, Sep 20, 2009 at 4:09 AM, Smylers smyl...@stripey.com wrote: Erik Vorhes writes: 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). That isn't an argument for people's names _in general_ being marked up; it's an argument for marking them up in the specific case where they are used as (nicknames of) titles of works. 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.) E.g.: pYou should read citeHerodotus/cite./p That's using Herodotus as the title of a work. In many fields it's common to refer to well-known works by nicknames, such as 'Smith Thomas', 'The Dragon Book', 'The Red Book', or 'The White Album'. So cite should be used for them. 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. Indeed, titles of works and these other examples more readily fall under the rubric of something for attribution. (I'm working on more specific wording but wanted to get this out there.) But it doesn't follow that cite should be used for any other occurrences of those terms -- the people Smith and Thomas, or a book which just happens to be red. Really? ;) Erik
Re: [whatwg] the cite element
A few points of clarification: 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, 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. 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]. 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. There's nothing wrong with overriding default presentaional styles, but there _is_ something wrong with a spec's defaults being different than what authors want. Agreed. How many sites using cite for people's names (or other reasonable uses that deviate from title of work) would it take to convince you that it _was_ a common case? Benjamin already asked me that, I was turning the tables on him when I asked the question above. :-) Oops! I like to think of myself as a better reader than that. Sorry! :) I had answered: A random sample of the Web would need to show more uses of this than uses of other things. I'm not sure the lack of majority use should be an impediment, but that's an issue of conclusions rather than reasoning. (And I sympathize with needing to draw the line at some point, even if it makes some of us unhappy or some of us feel it's incorrect.) ... 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.) It doesn't matter how many people say something on this mailing list, that's not an unbiased sample. (The people who think cite is fine as defined in HTML5 don't have motivation to say so, for example.) I agree that basing decisions exclusively on what is said on the mailing list is not always the right approach. The length of this thread (and filtering out your and my messages) suggests that the representation of voices pro con (re: cite in HTML5) is pretty close to equal. In other words, it's not just you and a bunch of cranky folks objecting to the specification (as much as it may feel that way sometimes). Erik [1] http://adactio.com/journal/1609/ [2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014684.html
Re: [whatwg] article/section/details naming/definition problems
On Wed, Sep 16, 2009 at 3:35 AM, Bruce Lawson bru...@opera.com wrote: there would also need to be a comment element I'd be *slightly* concerned that confusion could arise between a comment element and the !-- comment syntax --, at least in discussion. (I.e., what would HTML comment mean?) entry (which has already been proposed) might more logically suit the bill for standalone articles (in a blog or whatever) as well as blog/forum comments. And since it's part of the Atom spec., there's some precedent for defining its use. That said, I don't have a problem with article as a special kind of section (though having articles nested within articles doesn't agree with my brain at this point). Erik
Re: [whatwg] the cite element
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 Erik
Re: [whatwg] the cite element
as easily be provided by something like i class=title), and works perfectly well in all extant browser implementations. Sincerely, Erik Vorhes [1] http://www.w3.org/TR/html401/struct/text.html#h-9.2.1
Re: [whatwg] the cite element
On Thu, Aug 13, 2009 at 4:59 AM, Smylerssmyl...@stripey.com wrote: As Ian has pointed out, the above is technically non-conforming with what the HTML 4 spec claims. But it's how I've been using cite for years, since it makes sense and has a use. I defy you to show me in the HTML 4.01 specification where something like the following is nonconforming: pI like to read nonfiction, such as citeJohn Adams/cite, but I had more time for that when I was a professional academic./p Erik
Re: [whatwg] the cite element
On Thu, Aug 13, 2009 at 4:59 AM, Smylerssmyl...@stripey.com wrote: For words that you wish to have no distinct presentation from the surrounding text -- words that readers don't need calling out to them as being in any way 'special' -- simply don't mark them up. Interesting point. Should the HTML5 specification explicitly admonish against using microformats, microdata, RDFa, and the like?
Re: [whatwg] the cite element
On Wed, Aug 12, 2009 at 6:21 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 3 Aug 2009, Erik Vorhes wrote: On Mon, Aug 3, 2009 at 6:29 AM, Ian Hickson i...@hixie.ch wrote: Not all titles are citations, actually. For example, I've heard of the /Pirates of Penzance/, but I'm not citing it, just mentioning it in passing. No, that actually is a citation, whether you realize it or not. You are making reference to a musical and are therefore citing it, even in passing. Your definition of citation is far looser than my dictionary's (a quotation from or reference to). In fact your definition seems to be basically the same as HTML5's -- a title of a work. Unless you think that this should be valid use of cite: pI picked up citemy favourite book/cite, and put it next to citethe painting I got from my aunt/cite./p I don't think that those references to works should use cite. Doing so has zero benefit, as far as I can tell. No, No, NO. That is not what I mean at all. You again deliberately misrepresent what I am trying to convey, that cite should be for citations, not for a subset of citations. I agree (and never suggested otherwise): those are in no way explicit citations, as there is nothing specific about them that would justify calling them citations. citePirates of Penzance/cite, however is an explicit reference to that work and therefore a citation, not just a title of the work. Why not? An orchestral arrangement is a work, and has a title -- the spec explicitly lists score, song, and opera as possible works, for instance. I've added legal case report to the list, to clarify that you can use cite to name such reports. So the definition of cite in HTML5 should currently be title of work or something that could be construed as a title where one doesn't exist in the explicit sense of 'title.' But not people's names, even if they're the citation, because using cite for citations is silly. Unless by title of work you mean standard citation for an item, usually its title; but then cite really means what it is defined as in the HTML 4.01 specification. Unless you have a very loose definition of citation, or unless you consider a person to be a possible source, cite in HTML5 is a strict superset of HTML4's definition. For example, the following is valid HTML5 but wouldn't be valid HTML4, since it's not a citation or reference to another source, but merely something mentioned in passing: pToday, as I was moving my copy of citeDreamer's Void/cite, I hurt my back./p That's perfectly fine in HTML4. It's a citation, as I have explained previously, and there's nothing in the HTML4 spec that prohibits that use. Why are you misrepresenting the HTML4 spec? Besides, there's already tt, which could be used to identify title text or something like that. It has the wrong default styles. So does cite, in many contexts even if we're relying on the definition in HTML5 as it stands. cite is also used to mark up titles that aren't citations, as shown by Philip's data. Again. Those *are* citations. There's no reason to limit it to a subset of citation (more below). I honestly don't understand how HTML5 is a subset of HTML4 here, unless you mean people's names, which as far as I can tell aren't commonly used with cite, and for which there is no benefit to using cite. I believe they are more commonly used than you are willing to admit. Wikipedia's output is not an argument for consuming cite. In fact, what they're doing is an argument against keeping cite for that purpose: they are explicitly overriding the only behaviour cite gives them (italics) and then going out of their way to reintroduce that effect on a span! If that's not an argument for changing the meaning of cite to something more convenient, I don't know what is. Yes, Wikipedia's overall markup is problematic, but you seemed to be needing some actual evidence that cite is used for more than simply title of work other than blog commenter names (which for some inexplicable reason you have rejected out-of-hand as evidence that cite is used for people's names and other non-title citations). Any reference to a title of a work is by definition a citation. Therefore you are limiting cite to a subset of citation. I disagree with your definition of citation. I'm sorry the New Oxford American Dictionary isn't good enough for you. I quote: - a quotation from or reference to a book, paper, or author, esp. in a scholarly work - a mention of a praiseworthy act or achievement in an official report, esp. that of a member of the armed forces in wartime - a note accompanying an award, describing the reasons for it - [in Law] a reference to a former tried case, used as guidance in the trying of comparable cases or in support of an argument Unless you can demonstrate that there is a concrete benefit to doing what you describe, I do not think it is a good idea. There are concrete
Re: [whatwg] HTML5: compatible with all legacy Web browsers
On Fri, Aug 7, 2009 at 5:39 AM, Simon Pieterssim...@opera.com wrote: What is it that is not compatible with which browser? Any use of legend outside of a fieldset is broken in every modern browser: IE6-8, Firefox 3-3.5, Safari 3-4, and Opera 9-10b all break in interesting ways. For more details, see Remy Sharp's Legend not such a legend anymore http://html5doctor.com/legend-not-such-a-legend-anymore/. Erik
Re: [whatwg] HTML5: compatible with all legacy Web browsers
On Fri, Aug 7, 2009 at 8:28 AM, Aryeh Gregorsimetrical+...@gmail.com wrote: I think the meaning of compatible with all existing browsers here is that HTML 5 does not *require* authors to break compatibility with any existing browser. I agree completely with your interpretation of the phrase. HTML5 is intended to enhance the web without breaking it, so noting (or even emphasizing) how it's backwards-compatible is important and useful. But the phrase should be clarified along similar lines to what you've articulated. Maybe: HTML5 can be written in such a way that it is compatible with all browsers made after X date? Erik
Re: [whatwg] the cite element
On Mon, Aug 3, 2009 at 6:29 AM, Ian Hickson i...@hixie.ch wrote: See http://www.four24.com/; note near the top of the source: blockquote id=verse cite=John 4:24... My statement stands, on the aggregate: On Mon, 27 Jul 2009, Philip Taylor wrote: See http://philip.html5.org/data/cite-attribute-values.txt for some data. (Looks like non-URI values are quite rare.) I agree that @cite is rarely used as anything other than a URI; I was attempting to demonstrate that even very recent uses of HTML don't necessarily get that it is for URIs (the site I referenced launched last month, as I recall). While we're at it, Philip had other data: Also maybe relevant: see http://philip.html5.org/data/cite.txt for some older data about cite. (Looks like non-title uses are very common.) This seems to support my point that cite is used for a whole variety of purposes, like em, i, q, HTML4's cite, and HTML5's cite. Very few, actually much fewer than I had remembered from my last look at the data, are names of people, citations or otherwise. I actually took this information the other way, that there are indeed other uses for cite out there beyond titles. On Mon, 27 Jul 2009, Erik Vorhes wrote: A new element wouldn't work in legacy UAs, so it wouldn't be as compelling a solution. Also, cite is already being used for this purpose. My preference would be for cite to retain the flexibility it has in pre-HTML5 specifications, which would include referencing titles. The flexibility doesn't seem as useful as limiting it to titles. What is the problem solved by allowing names to be marked up in the same manner as titles? The problem solved by allowing titles specifically to be marked up is that titles are usually typographically offset from the surrounding text in a distinctive fashion. This doesn't apply to names. Reusing the same element for both encourages authors to use cite for both which makes it harder for them to get the right typographic effect, leading to a lower quality of typography overall. I think this is a bad thing. This is not just about names. It allows other (non-title) text to be identified as a citation. If cite is identified as title of work, you can't cite many major orchestral arrangements at all, nor can you cite legal decisions. Unless by title of work you mean standard citation for an item, usually its title; but then cite really means what it is defined as in the HTML 4.01 specification. If backwards compatibility is that big a concern, why does HTML5 use legend outside of fieldset elements? There were no existing elements that could be reused for many of the new semantics. When there were, we used them (e.g. i, b, cite, menu, legend, h1). I agree that there aren't always existing elements for the new semantics included in HTML5, but I don't believe that backwards compatibility is as big a concern as you claim it is. HTML5's re-use of legend, for example, is completely broken in every extant browser. (See http://html5doctor.com/legend-not-such-a-legend-anymore/ for evidence). Besides, there's already tt, which could be used to identify title text or something like that. What is the pressing need for an element for citations, which would require that we overload cite with two uses? A title can be a citation, but not all citations are titles. What's the pressing need for limiting cite only to titles? As described above, the need to have an element for titles is that there are typographic conventions that apply to titles. What is the pressing need for an element for citations, which would require that we overload cite with two uses? As I have said previously, there aren't consistent typographic conventions that apply to titles. The pressing need is that cite is already used to define citations. There's no reason to limit it to a subset of citation (more below). But why does that have value? How would you use this information? To collect citation information. I don't see how that as any less value that collecting titles of works, especially since not all works have titles or means of reference that would constitute a conventional title. Note that HTML5 now has a more detailed way of marking up citations, using the Bibtex vocabulary. I think this removes the need for using the cite element in the manner you describe. Since this is supposed to be the case, why shouldn't HTML5 just ditch cite altogether? (Aside from backward compatibility, which is beside the point of the question.) Backwards compatibility (with legacy documents, which uses it to mean title of work) is the main reason. I'd beg to differ, regarding legacy documents. See, for example the automated citation generation at Wikipedia: http://en.wikipedia.org/wiki/Wikipedia:Citation_templates What specifically am I looking for here? This doesn't seem to have any relevance to HTML. Wikipedia automatically
Re: [whatwg] the cite element
On Sun, Jul 19, 2009 at 4:58 AM, Ian Hicksoni...@hixie.ch wrote: If cite is exclusively for titles, it shouldn't be called cite. Sure, but we're about 15 years too late for that. Well, no: the as far as I have been able to determine, every HTML specification (before HTML5) did not limit this element to titles. In practice, people haven't been confused between these two attributes as far as we can tell. People who use cite seem to use it for titles, and people who use cite= seem to use it for URLs. (The latter is rare.) See http://www.four24.com/; note near the top of the source: blockquote id=verse cite=John 4:24... A new element wouldn't work in legacy UAs, so it wouldn't be as compelling a solution. Also, cite is already being used for this purpose. My preference would be for cite to retain the flexibility it has in pre-HTML5 specifications, which would include referencing titles. If backwards compatibility is that big a concern, why does HTML5 use legend outside of fieldset elements? See: http://twitter.com/rem/status/2869618614 And if the definition of new elements is such a concern, why introduce *any* new elements? (Please forgive the snark.) What is the pressing need for an element for citations, which would require that we overload cite with two uses? A title can be a citation, but not all citations are titles. What's the pressing need for limiting cite only to titles? I understand HTML5's attempts to provide semantic value to such elements as i, b, and small. To at the same time remove semantic value at the same time is completely asinine. If cite's original meaning has value, that is true; what is its value? I would assume that this would be obvious. cite both denotes and connotes citation. Note that HTML5 now has a more detailed way of marking up citations, using the Bibtex vocabulary. I think this removes the need for using the cite element in the manner you describe. Since this is supposed to be the case, why shouldn't HTML5 just ditch cite altogether? (Aside from backward compatibility, which is beside the point of the question.) Backwards compatibility (with legacy documents, which uses it to mean title of work) is the main reason. I'd beg to differ, regarding legacy documents. See, for example the automated citation generation at Wikipedia: http://en.wikipedia.org/wiki/Wikipedia:Citation_templates In addition, the comments at zeldman.com use cite to reference authors of comments. While that specific example is younger than HTML5, this is merely an example of a relatively common use-case for cite that does not use it to signify title of work. There is no reason at all why it can't be defined as citing whom. The main reason would be that there doesn't appear to be a useful purpose to doing that. The above references suggest otherwise. There are plenty of instances where one would want to cite people rather than just a title of work; blog commenters are only the most obvious example. On Wed, 1 Jul 2009, Erik Vorhes wrote: On Wed, Jul 1, 2009 at 11:49 AM, Kristof Zelechovskigiecr...@stegny.2a.pl wrote: I can imagine two reasons the CITE element cannot be defined as citing whom: 1. Existing tools may assume it contains a title. Existing tools (which I would assume follow the HTML 4.01 spec) It appears this assumption is mistaken. Really? Please provide evidence. Existing tools that treat cite exclusively as title of work do so against every HTML specification out there (i.e., HTML 4.01 and earlier). While the HTML 4.01 specification is hardly perfect, I don't see the value in limiting the semantic potential of the cite element in HTML5. As far as I can tell, increasing it from citations to titles of works is actually increasing its semantic potential, not limiting it. Well, no. It's making it more exclusive. Defining cit as title of work increases its specificity, but limits its semantic potential. As I noted before, all titles are citations, but not all citations are titles. By defining cite as an element that identifies a citation you allow for title of work while not excluding other justifiable uses of this element, e.g., cited person. Indeed, there is a lot of misuse of the element -- as alternatives for q, i, em, and HTML5's meaning of cite, in particular. Expanding it to cover the meanings of q, i, and em doesn't seem as useful as expanding it just to cover works. I believe you mean limiting it just to cover works here. By requesting cite to retain a definition of this is a citation, I am not advocating that it be allowed to overlap q, i, or em. (I realize you were responding to someone else's message, here. What I've suggested allows cite to retain its semantic value.) I think it's clear that people want to use cite for things other than citations, and in fact do use it that way widely. If we're increasing it past just citations, then there seems to be clear value to using it to mark up
Re: [whatwg] the cite element
On Mon, Jul 27, 2009 at 10:17 AM, Kristof Zelechovskigiecr...@stegny.2a.pl wrote: 1. If you cite a person, the person you cite does not become a citation because of that. Putting the person inside the CITE element distorts the meaning. If you are citing a person (either as someone worth quoting or as, say, the photographer of an image), how does using cite to identify the citation distort the meaning? 2. The example CITE Chaucer and the CITE Canterbury Tales/CITE /CITE is invalid because Canterbury Tales are not being cited, at least not in the title page. Why not? It seems clear to me that one title is citing the other. 3. The semantic potential does not decrease uniformly with specificity. Rather, there is an optimal value somewhere in the middle of specificity. Arguably, that optimum is attained with CITE reserved for titles. Arguably, the optimum is attained with cite reserved for citations. 4. Of course titles are not always styled the same way. However, there is a requirement that the presentation makes sense in most cases when CSS is not supported. The cases where styling all titles in the same way makes the information hard to understand are scarce. This doesn't explain why cite needs to be used exclusively used for titles. (And I didn't realize that HTML was really just for use as styling hooks. There's no audible difference between cite style=font-style:normal;MLA Handbook for Writers of Research Papers/cite and citeMLA Handbook for Writers of Research Papers/cite.) 5. Random markup errors a few pages do not constitute an obstacle here, nor do errors in template code (they are ubiquitous once deployed but they are easy to fix, at least at Wikipedia). Except that Wikipedia is not erroneous in its usage of cite. It is declaring conformance to XHTML 1.0 Transitional, which is based off of the HTML 4.01 specification, which defines cite as a citation or a reference to other sources. To the issue of cite in HTML5, using cite as title of work provides for no distinction between editions or translations of works. 6. It does not mean anything to say this is a citation; this definition is too ambiguous to be useful. I obviously disagree. cite identifies a title is too narrow a definition to be useful. Erik Vorhes
Re: [whatwg] Nested list
On Mon, Jul 13, 2009 at 10:22 AM, Ryosuke Niwarn...@google.com wrote: Does anyone see a serious compatibility issue with adding ol / ul as child nodes of ol / ul? I feel like not allowing them is more problematic given the situation. Part of the reason that browsers handle this-- ul li/li olli/li/ol li/li /ul -- pretty well is because, in HTML 4.01 (and earlier HTML specs), li was not required to be explicitly closed, so it would implicitly handle that ol as a child of the preceding li. (Inconsistencies in rendering most likely arise because the browser havs already found the explicit close to a list item before getting to the nested list.) Do you have use case for when a child list is *not* an item in the parent list? Otherwise, it doesn't make sense *not* to wrap the child list in the li element. Erik
Re: [whatwg] Nested list
On Mon, Jul 13, 2009 at 11:34 AM, Ryosuke Niwarn...@google.com wrote: We can define it in this way. When a list A appears within anther list B (without being enclosed by li), then the list A is a sublist of B and that lists A and B constitutes a tree structure. When a list C appears within a list item of the list B, then list C is a list appears in a paragraph of a list item of B. i.e. C ad B does not constitute a tree structure. This can be seen from the way those two constructs are rendered in major UAs. Namely, when lists A and B are nested, you don't see a bullet before A. Because A and B together constitutes a tree-structure, this rendering is semantically correct. On the other hand, UAs render a bullet before C. B has a list item that happens to contain a list, but that doesn't prevent B from having a bullet for that particular list item. While I think I understand your description, I'm a little concerned for a few reasons. 1. Depending on context, lists within lists don't render differently than lists within list items do. 2. How does the User Agent determine if a list within a list is part of the preceding li if that li isn't closed? Is it part of the li or something on its own? 3. Why should ol and ul provide different semantic meaning depending on context? Won't that lead to confusion? 4. If two lists aren't actually supposed to be items in the same list, why would you group them as a list? Shouldn't they be separate entities entirely? I've cobbled together a demonstration page to address some of these issues (more clearly, I hope): http://textivism.com/list-items/ Erik Vorhes
Re: [whatwg] the cite element
On Tue, Jun 30, 2009 at 11:19 PM, Ian Hicksoni...@hixie.ch wrote: I don't understand why it would be more useful. Having an element for the typographic purpose of marking up titles seems more useful than an element for the purpose of indicating what is a citation. Why is it more useful? If cite is exclusively for titles, it shouldn't be called cite. In addition to the semantic difference between a title and a citation, limiting cite to titles potentially raises confusion between this element and the cite attribute (for blockquote and q), as the latter is limited to URLs. Yes, elements and attributes are different things. But in one context the concept cite is limited only to titles (and forbids URLs); in another context cite is limited only to URLs (and forbids titles). While it makes some sense, I suppose, to limit the cite attribute to URLs, it makes absolutely no sense to limit the cite element only to titles. If it's so pressing for there to be an element allowed in the body to mark up titles, why not create a new element for that purpose or allow for a cite-specific attribute to note that designation? I understand HTML5's attempts to provide semantic value to such elements as i, b, and small. To at the same time remove semantic value at the same time is completely asinine. Note that HTML5 now has a more detailed way of marking up citations, using the Bibtex vocabulary. I think this removes the need for using the cite element in the manner you describe. Since this is supposed to be the case, why shouldn't HTML5 just ditch cite altogether? (Aside from backward compatibility, which is beside the point of the question.) Erik Vorhes
Re: [whatwg] the cite element
On Wed, Jul 1, 2009 at 11:49 AM, Kristof Zelechovskigiecr...@stegny.2a.pl wrote: I can imagine two reasons the CITE element cannot be defined as citing whom: 1. Existing tools may assume it contains a title. Existing tools (which I would assume follow the HTML 4.01 spec) would be mistaken in their implementation of the cite element, then: CITE: Contains a citation or reference to other sources. (See http://www.w3.org/TR/html401/struct/text.html#h-9.2.1.) Moreover, in its sample usage, the HTML 4.01 spec uses cite for more than titles. While the HTML 4.01 specification is hardly perfect, I don't see the value in limiting the semantic potential of the cite element in HTML5. Erik Vorhes
Re: [whatwg] nostyle consideration
On Mon, Jun 15, 2009 at 7:28 PM, Thomas Powelltpow...@gmail.com wrote: There is no intention of that in the proposal, you seem to have eliminated the discussion about dynamic content which is also discrimentory of such users as well as well as the error reporting examples. I showed a variety of negative and positive cases. My interest here in this tag in fact has grown out of a problem with lack of understanding of users with various capabilities rather than some particular design or tech agenda. For the same reason you shouldn't rely only on JavaScript to provide necessary content, you shouldn't rely on generated content in CSS. If you follow this very basic principle, you obviate the need for nostyle. I encourage you to view the following excerpt from an Eric Meyer presentation, on the perils of relying on CSS to generate content: http://www.vimeo.com/1149007?pg=embedsec=1149007 The key point is this: If it's important, it should be in the content, it shouldn't be generated. Erik Vorhes
Re: [whatwg] code attributes
On Fri, Jun 5, 2009 at 2:21 PM, Tab Atkins Jr.jackalm...@gmail.com wrote: On the other hand, a simple code lang=xml/html could be used to introduce the pre and all the lt; s This is the one part of the suggestion that I could possibly see being introduced in the language, but the benefit is *still* very small. It's also worth pointing out that currently the lang attribute is supposed to designate language codes defined in RFC 3066, which (as far as I can tell) don't include programming languages. A microformat approach (using class attributes) to programming languages for code probably makes more sense than using lang. Erik
Re: [whatwg] the cite element
On Thu, Jun 4, 2009 at 3:13 AM, Kristof Zelechovski giecr...@stegny.2a.pl wrote: The HTML is required to produce a meaningful rendering without CSS. The level of reader surprise at the default rendering of cite Aristotle/cite said is high and such markup should be verbally deprecated. (I agree that it cannot be technically invalid, of course.) If I'm reading your message correctly, you assert that the spec's documentation of semantic uses for cite must be limited because of how browsers render text within cite by default. But the argument in favor of limiting cite in the spec. to titles becomes almost immediately problematic. According to many scholarly style guides (e.g., APA, MLA, and Chicago), default browser styles properly italicize citeCrime and Punishment/cite, but they would improperly italicize the title to an article in a periodical. Logically, then, if we are to use default styling as a baseline for the usage of cite, the spec. would need to identify which kinds of titles are appropriate to wrap within that element. In addition, I'm skeptical about how much users are surprised when they encounter italicized text. Visually, at least, by default cite renders no differently from em, so it's not as if italicization is an issue in itself; and judging my some of the seemingly random uses of em in the wild, I doubt this is as big an issue as you suggest. So count me as seconding Andrew Hagen's suggestions regarding cite. It's too semantically useful an element to preemptively limit its use only to titles. Erik Vorhes
Re: [whatwg] Spec should require UAs to have control to mute/ pause audio/ video
On Sat, May 9, 2009, at 2:16 PM, Tab Atkins Jr. wrote: The issue is that not all browsers have significant configs (I'm thinking of mobile browsers here), and I don't believe their inability to provide such a choice to the user should make them nonconforming. If a UA is incapable of audio output, by extension it conforms to wording that uses MUST. (That is, it mutes audio by default, as it provides no means to play audio.) So I'm not sure this is an actual issue. In the illogical event that an audio-free UA wouldn't conform to this requirement, surely it's possible to word the specification in such a way that exempts those browsers from the requirement. As well, recall that the majority browser for 'unsophisticated' users is still IE6 or 7, and IE8 still lacks any support for video at all What does the lack of support for video in IE 6-8 have to do with an argument against requiring UAs to mute audio in audio and video? Because those browsers exist without support for those elements, it falls upon developers, content producers, et al., to make a good-faith effort to provide accessible (and screenreader-friendly) content; the wording of the HTML5 spec doesn't change current conditions, nor should it be expected to. Thanks, Erik Vorhes
