Re: [whatwg] The blockquote element spec vs common quoting practices
Riveting tale, chap. Can you provide proof? Actually the burden of proof is on those who think that blockquote has some useful support. No, that's not how burden of proof works. You made a claim regarding blockquote, nils asked for proof. The onus is on you. Thanks, Ash http://ashleysheridan.co.uk
Re: [whatwg] The blockquote element spec vs common quoting practices
2012-02-12 8:36, Nils Dagsson Moskopp wrote: Since in current usage, blockquote means just “indent” more often than not, browsers and search engines should not and will not imply any specific semantics for it. Thus it will be pointless to use it. Riveting tale, chap. Can you provide proof? Regarding browsers and search engines, what else could constitute a proof than the absence of any information about them doing anything with blockquote? Apart from the obvious default rendering, with indents, that is. Regarding the usage, I have not collected statistics on this during my 20 years of browsing web pages, and I don’t think anyone has. So objective argumentation is somewhat difficult. In this discussion, I mentioned the WIPO document http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html issued by a reputable organization, and if you look at the source code, you’ll see that the page uses blockquote just for subparagraphs, not for quotations. I’m sure that if you start looking around, you’ll see blockquote used mostly for mere indentation. Yucca
Re: [whatwg] The blockquote element spec vs common quoting practices
Jukka K. Korpela jkorp...@cs.tut.fi schrieb am Sun, 12 Feb 2012 12:04:13 +0200: 2012-02-12 8:36, Nils Dagsson Moskopp wrote: Since in current usage, blockquote means just “indent” more often than not, browsers and search engines should not and will not imply any specific semantics for it. Thus it will be pointless to use it. Riveting tale, chap. Can you provide proof? Regarding browsers and search engines, what else could constitute a proof than the absence of any information about them doing anything with blockquote? Apart from the obvious default rendering, with indents, that is. Maybe I am missing something here, but absence of evidence is not evidence of absence. Also, you may be conflating intended meaning (author intent) with interpretation (what browsers, search engines do). Default rendering in Browsers is abysmal for most elements – but many authors use blockquotes prominently decorated with graphical quotes. This is used to let (visual) readers know in a most explicit way that these are quotations. For example, see this article (in German), which quotes from and links to several essays regarding copyright and culture https://netzpolitik.org/2012/kulturkampf-konnt-ihr-haben/. Cheers, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] The blockquote element spec vs common quoting practices
On Sun, 12 Feb 2012, Jukka K. Korpela wrote: 2012-02-12 2:13, Ian Hickson wrote: That's not to say that one day we won't provide an explicit way to mark up attribution for blockquotes in markup, just that the desired presentation isn't a relevant concern in doing so The relationship between a quotation and the indication of source is not presentational, and more than being a quotation is presentational. Agreed. The blockquote has been, and will be, rather pointless without markup for “credits” (indication of author and source, which are normally required by law). What's the use case, other than presentation? On Sun, 12 Feb 2012, Smylers wrote: Ian Hickson writes: On Thu, 14 Jul 2011, Kevin Marks wrote: There is another common pattern, seen in blogging a lot, of putting the citation at the top eg As cite class=vcarda href=http://www.gyford.com/phil/; class=url rel=acquaintance met colleagueabbr title=Phil Gyford class=fnPhil/abbr/a/cite wrote about the a href=http://www.gyford.com/phil/writing/2009/04/28/geocities.php;ugly and neglected fragments/a of Geocities:/p blockquote pGeoCities is an awful, ugly, decrepit mess. And this is why it will be sorely missed. It’s not only a fine example of the amateur web vernacular but much of it is an increasingly rare example of a emperiod/em web vernacular. GeoCities sites show what normal, non-designer, people will create if given the tools available around the turn of the millennium./p /blockquote ... the current markup handles it fine already (as you demonstrate above). Using cite like that isn't conforming, surely? You're right, I missed that cite was used instead of span there. The key part was the use of a paragrah giving attribution just before a blockquote being sufficient for practical purposes in blog comment cases such as the one Kevin was describing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The blockquote element spec vs common quoting practices
2012-02-12 19:54, Ian Hickson wrote: The blockquote has been, and will be, rather pointless without markup for “credits” (indication of author and source, which are normally required by law). What's the use case, other than presentation? What’s the use case for markup for quotations in general, other than presentation? I would say it is just a matter of potential ways in which such markup could be used, rather than existing usage—as there can hardly be such usage without establish and reasonably consistent usage of markup for quotations. At the same level, “credits” can be used in editing and checking tools to verify that all quotations have credits (issuing warnings about those that don’t); in automatically generating a list of references; in an optional browsing mode where credits are hidden, with a button available for opening them; in finding out (even web-wide) which documents quote a certain document. If and when suitable microdata markup will be used inside an element designated as If we think that markup for quotations will not have much practical use, then it’s better to omit such markup altogether (and tell people to use whatever markup they like, maybe even blockquote if they prefer indentation). But if we think that quotation markup will become useful, then the markup should have an element for “credits” on the same optimistic grounds. The difference between blockquote and (for example) quotation as quotation markup is that the latter has no burden of existing use for other purposes. Anyone who plans to do some intelligent processing of quotations could expect quotation to be quotation markup and nothing else, since there is no motivation for using it for other purposes Yucca
Re: [whatwg] The blockquote element spec vs common quoting practices
Jukka K. Korpela jkorp...@cs.tut.fi schrieb am Sun, 12 Feb 2012 20:19:02 +0200: […] The difference between blockquote and (for example) quotation as quotation markup is that the latter has no burden of existing use for other purposes. By analogy, a completely new table element would also be necessary. Oh, and what about a way to denote images that is not tarnished by spacer GIFs and web bugs? Anyone who plans to do some intelligent processing of quotations could expect quotation to be quotation markup and nothing else, since there is no motivation for using it for other purposes Authors lie and we will have to live with it. You cannot make content producers honest by just introducing a new element intended to be used similar to the old element. Why do you think that *this* time, everyone will read the manual before producing markup? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] The blockquote element spec vs common quoting practices
2012-02-12 21:43, Nils Dagsson Moskopp wrote: The difference between blockquote and (for example) quotation as quotation markup is that the latter has no burden of existing use for other purposes. By analogy, a completely new table element would also be necessary. There has been quite a lot of discussion on distinguishing between layout tables and data tables. The heuristics look reasonable to me, so I don’t see why a new element or even a new attribute would be needed. There is existing software that treats table as tabular data, such as assistive software that lets the user access a cell by column and row information. So the situation is different from blockquote. Oh, and what about a way to denote images that is not tarnished by spacer GIFs and web bugs? You can use object for that if you like. But img is still an image, whether used as a spacer or otherwise. Anyone who plans to do some intelligent processing of quotations could expect quotation to be quotation markup and nothing else, since there is no motivation for using it for other purposes Authors lie and we will have to live with it. It’s not a lie if you use blockquote for indentation because others told you that it indents text (it was often described that way in tutorials, too). It might be wrong by some definition, but that does not make it a lie. You cannot make content producers honest by just introducing a new element intended to be used similar to the old element. Not by just doing that, but it would be part of the process. Why do you think that *this* time, everyone will read the manual before producing markup? The don’t need to. The important thing is that it would be used against the defined meaning, because there is no reason to do that. People use blockquote because they heard or observed that it indents, and it did that even when there was no better way to indent. Yucca
Re: [whatwg] The blockquote element spec vs common quoting practices
On Sun, 12 Feb 2012, Jukka K. Korpela wrote: 2012-02-12 19:54, Ian Hickson wrote: The blockquote has been, and will be, rather pointless without markup for “credits” (indication of author and source, which are normally required by law). What's the use case, other than presentation? What’s the use case for markup for quotations in general, other than presentation? The use case for most of the semantic markup is jsut easier authoring and maintenance, in particular for selectors in CSS. In the case of blockquote, we inherited it from HTML4 and so use cases weren't really a driving factor in the contemporary specification's development of the feature; it was more driven by consistency concerns. (Same as with, e.g., dfn, strong, and other semantic elements.) At the same level, “credits” can be used in editing and checking tools to verify that all quotations have credits (issuing warnings about those that don’t); in automatically generating a list of references; in an optional browsing mode where credits are hidden, with a button available for opening them; in finding out (even web-wide) which documents quote a certain document. Do any tools try to do any of this? If there are concrete use cases with software that is trying to address the use case and authors who want to use that software, then we should definitely look at the use cases. But we need to study the use cases and software, if that's the case. If we think that markup for quotations will not have much practical use, then it’s better to omit such markup altogether (and tell people to use whatever markup they like, maybe even blockquote if they prefer indentation). The practical use of moderately simplified maintenance is sufficient to justify keeping elements that are already deployed. I agree that if we didn't have the legacy here we probably wouldn't add blockquote or q, but that's water under the bridge. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The blockquote element spec vs common quoting practices
2012-02-12 23:25, Ian Hickson wrote: The use case for most of the semantic markup is jsut easier authoring and maintenance, in particular for selectors in CSS. If that’s the approach, and this reflects a consensus, shouldn’t this be explained in the introductory material (which is now rather limited and technical and does not really explain the goals and ideas)? This could even help to clarify the discussion but especially it would guide authors. The obvious meaning of “semantic” (and http://www.whatwg.org/specs/ speak about semantic markup without quotation marks) is that it is related to meaning, not ease of authoring. If you don’t expect semantic differences as such make any difference, then why introduce semantic markup at all? Surely it would be easier to author if you can introduce your own tags as you go, designing a tag set that suits a particular page, site, or application. If the idea is that in collaborative environments, it is easier to work when everyone uses the same tags, then it’s really about setting design and coding practices. It would be something rather orthogonal to all other aspects of HTML. In the case of blockquote, we inherited it from HTML4 and so use cases weren't really a driving factor in the contemporary specification's development of the feature; it was more driven by consistency concerns. Consistency with existing practice would be achieved by describing the default rendering in browsers. There’s little reason to aim at describing the semantics if it’s not really expected to be relevant – especially since we know that very often, existing pages (and existing authoring software) uses blockquote just for indentation. Designers and people who set coding standards can specify how they want blockquote to be used (Same as with, e.g., dfn,strong, and other semantic elements.) They, too, as well as b and u, have been modified quite a lot, with elaborated explanations about their meanings, causing both confusion and argumentation. It would be so much simpler, and it would give the same authoring and maintenance ease, to describe just how browsers render them by default. At the same level, “credits” can be used in editing and checking tools to verify that all quotations have credits (issuing warnings about those that don’t); in automatically generating a list of references; in an optional browsing mode where credits are hidden, with a button available for opening them; in finding out (even web-wide) which documents quote a certain document. Do any tools try to do any of this? Of course not; there is no markup for credits. (And in reality no markup for quotations either – no markup element that programs could reasonably expect to mean “quotation”, unless you count q – which is probably not used against its basic defined meaning, but it isn’t used much at all.) If there are concrete use cases with software that is trying to address the use case and authors who want to use that software, then we should definitely look at the use cases. But we need to study the use cases and software, if that's the case. So in order to have proposals for elements considered, one would need to present concrete cases of programs trying to work on the elements that do not exist. The practical use of moderately simplified maintenance is sufficient to justify keeping elements that are already deployed. Certainly. And to make this as simply and effectively as possible, the specification should just describe the existing markup in terms of browser behavior. Surely it does not ease authoring or maintenance to invent new meanings and new rules for markup that is currently in use – if the semantic definitions are not expected to be notified and used by browsers, search engines, etc. If the semantics are not supposed to be “real,” it would be much better to leave things open. If the specification would not designate any element as suitable for quotation, still less the right element for it, designers and authors would answer the question themselves, in their own coding rules and standards. It would be *easier* without a fairly complex part of a specification telling all kinds of things about the elements, possibly reflecting the design and coding ideas of some working group or editors. If no software is expected to treat blockquote text so that the semantics “quotation from an external source” is relevant, then it is completely immaterial whether one puts the references or credits inside or outside the element (if one uses blockquote for a quotation). Any rule on this would be just a rule for rule’s sake and would make life more difficult to people who take the specification seriously and face situations where the references would better go inside, or go outside, as the case may be. Yucca
Re: [whatwg] The blockquote element spec vs common quoting practices
On Mon, 13 Feb 2012, Jukka K. Korpela wrote: 2012-02-12 23:25, Ian Hickson wrote: The use case for most of the semantic markup is just easier authoring and maintenance, in particular for selectors in CSS. If that’s the approach, and this reflects a consensus, shouldn’t this be explained in the introductory material (which is now rather limited and technical and does not really explain the goals and ideas)? Generally speaking I do not include rationales in the document, as that would basically double the length of the work. In the past we have had people work on rationale documents, e.g.: http://wiki.whatwg.org/wiki/Rationale If you (or anyone else) is interested in further maintaining this work, please don't hesitate to do so. The obvious meaning of “semantic” (and http://www.whatwg.org/specs/ speak about semantic markup without quotation marks) is that it is related to meaning, not ease of authoring. They're are not mutually exclusive. Documents that are marked up according to the meaning of the content tends to be easier to maintain, especially in the face of changing desires with respect to the presentation. The concept of CSS and especially alternative style sheets is predicated on the document markup being rich enough that specific parts, e.g. headings, paragraphs, sections, sometimes even quotes, can be directly selected and styled. If you don’t expect semantic differences as such make any difference, then why introduce semantic markup at all? The basis of HTML on semantic markup far predates this effort. Surely it would be easier to author if you can introduce your own tags as you go, designing a tag set that suits a particular page, site, or application. Authors are of course able to do this using just div class= or even just XML, but in general document maintenance, especially across multiple authors over time, is significantly helped by the use of a common vocabulary. If the idea is that in collaborative environments, it is easier to work when everyone uses the same tags, then it’s really about setting design and coding practices. It would be something rather orthogonal to all other aspects of HTML. Yes. In the case of blockquote, we inherited it from HTML4 and so use cases weren't really a driving factor in the contemporary specification's development of the feature; it was more driven by consistency concerns. Consistency with existing practice would be achieved by describing the default rendering in browsers. That's certainly part of the work required of us (and it is done). There’s little reason to aim at describing the semantics if it’s not really expected to be relevant The semantics are definitely relevant. As I said in my last e-mail, they are what helps ease authoring and maintenance. especially since we know that very often, existing pages (and existing authoring software) uses blockquote just for indentation. Can you elaborate on your source for this? Data is always welcome. I'm not aware of a study that shows this one way or the other. Designers and people who set coding standards can specify how they want blockquote to be used If authors want to use text/html, and the HTML lexicon, but with different meanings, they are naturally able to do so by just writing their own spec that defines the language as they desire. There's nothing magical about the HTML standard; it's only useful because people agree amongst themselves to use it as their common definition of the vocabulary. (Same as with, e.g., dfn, strong, and other semantic elements.) They, too, as well as b and u, have been modified quite a lot dfn and strong haven't really been modified, merely clarified. b and u have been repurposed. with elaborated explanations about their meanings, causing both confusion and argumentation. I think overall the confusion and argumentation is significantly less for all these elements than it ever was in the HTML4 days. :-) It would be so much simpler, and it would give the same authoring and maintenance ease, to describe just how browsers render them by default. I think this rather misses the point. It's not the common default rendering that makes authoring with these elements easy. The default rendering is almost always overridden anyway. It's the common definition of the elements' meanings that helps ease authoring and maintenance. An author can join a project, and can immediately use h1 and know that whatever the page's styles are, they'll give h1 the same heading style as the main heading on all the other pages of the site. A blog author using a default theme can use blockquote to indicate when she quotes from another source, and then change to another theme with some confidence that the new styles will also treat blockquote in that way. If we only defined default renderings, there would be no way to be sure that that would happen. Many of the new
Re: [whatwg] The blockquote element spec vs common quoting practices
On Thu, 7 Jul 2011, Oli Studholme wrote: I�ve been thinking about this line in the blockquote spec: �Content inside a blockquote must be quoted from another source� Depending on how literally you read this, it makes the following common quoting practices annoying or impossible: 1. Typographically accepted changes to a quote, such as changing capitalisation or adding ellipses to indicate missing prose This is now explicitly allowed, with an example. 2. Adding quote metadata inline, such as notes and attribution This is indeed intentionally non-conforming. 3. Adding quote metadata on a line after the block quote, but such that it remains visually associated with the quote That's fine, so long as it's not in the blockquote, per the spec. I�ve found examples of these in the Chicago Manual of Style, web pages, and books (on Google Books), and the results are here: http://oli.jp/example/blockquote-metadata/ These examples are annoying (3) or impossible (2, 1?) to achieve while being conformant with the current spec. I don't think they're impossible, though I agree they're annoying, in particular the attributions inlined into the last paragraph. We should add support to CSS to make this kind of thing easier. On Fri, 8 Jul 2011, Jeremy Keith wrote: Oli has shown the real-world use cases for attribution *within* blockquotes. I think that overstates the case. The real world use cases are for the *presentation* having a block-like effect containing both the quote and the attribution. However, that's not a use case for the markup; the attribution still isn't actually a part of the quote, however it is presented. Presentation issues like this should be solved in CSS, not in HTML, even if it may superficially seem easier to fix in HTML. If we just fix things using the simplest possible fix rather than the best possible fix, we end up with things like font, javascript: links, using blockquote for indentation, document.write(), having bidi control in the presentation layer, etc. These were all mistakes, though, I think we'd all agree. They led to the Web being harder to maintain, they led to layering violations, they led to the technology being harder to explain, etc. It's important to keep things well-designed, even if it means more up-front work in getting the technology created. If CSS was flexible enough to address this kind of problem, it would also be flexible enough to solve many other problems. That's not to say that one day we won't provide an explicit way to mark up attribution for blockquotes in markup, just that the desired presentation isn't a relevant concern in doing so (except insofar as it may help decide between two otherwise equally good solutions). I expect we will eventually create a credit element that goes inside blockquote, figure or figcaption, caption, and maybe other contexts as well. At the moment, I'm deferring adding it so that we can see how figure and the other new elements do in the wild. On Sun, 17 Jul 2011, Jukka K. Korpela wrote: 17.07.2011 18:07, Nils Dagsson Moskopp wrote: Someone would need to standardize “ISBN sniffing behaviour” for UAs then. Could you make a proposal? I think it would be rather trivial. The string “ISBN” followed by something that matches the syntax of ISBN numbers, perhaps allowing some variation in punctuation, could be treated as an implicit link to a resource _if_ you have some mechanism(s) for mapping ISBN numbers to URLs. Given registerProtocolHandler(), it would be trivial to do that for an isbn: (or web+isbn:) scheme. No need for browser vendors to get involved. On Thu, 14 Jul 2011, Kevin Marks wrote: There is another common pattern, seen in blogging a lot, of putting the citation at the top eg As cite class=vcarda href=http://www.gyford.com/phil/; class=url rel=acquaintance met colleagueabbr title=Phil Gyford class=fnPhil/abbr/a/cite wrote about the a href=http://www.gyford.com/phil/writing/2009/04/28/geocities.php;ugly and neglected fragments/a of Geocities:/p blockquote pGeoCities is an awful, ugly, decrepit mess. And this is why it will be sorely missed. It’s not only a fine example of the amateur web vernacular but much of it is an increasingly rare example of a emperiod/em web vernacular. GeoCities sites show what normal, non-designer, people will create if given the tools available around the turn of the millennium./p /blockquote (from jeremy) or pretty much any post here: http://www.theatlantic.com/ta-nehisi-coates/ Would a header pattern in the blockquote work for this? No need, the current markup handles it fine already (as you demonstrate above). On Thu, 14 Jul 2011, Tantek �~Gelik wrote: In agreement with Jeremy, I too have found the blockquote/q cite attribute to be nearly as ignored as the longdesc attribute, despite having conducted talks and written tutorials about how to use the cite= attribute (makes me
Re: [whatwg] The blockquote element spec vs common quoting practices
2012-02-12 2:13, Ian Hickson wrote: That's not to say that one day we won't provide an explicit way to mark up attribution for blockquotes in markup, just that the desired presentation isn't a relevant concern in doing so The relationship between a quotation and the indication of source is not presentational, and more than being a quotation is presentational. Stylistic variations in displaying a quotation or the relationship are presentational. The blockquote has been, and will be, rather pointless without markup for “credits” (indication of author and source, which are normally required by law). It has been, and will be, either ignored by authors or used to mean “indent” in a comfortable way, though accidentally indentation may be used for quotations. Even formally, a blockquote element has been, and remains to be, at most semi-semantic. The definition “block quotation” left it open what distinguishes it from other quotations, except in rendering. “A section quoted from another source” surely looks like more semantic and structural, but if taken seriously, it would kill blockquote. Seldom does an author wish to quote an entire section. It is not even legal to quote more than is required to fulfill the acceptable purpose of quoting. I don’t think I have ever quoted anything that could sensibly be called a section. None of the examples currently presented at http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-blockquote-element comes even close Wrapping blockquote inside figure just to be able to present “credits” as figcaption is highly artificial. It is also clumsy, especially considering that it would have to be the *normal* way of presenting a block quotation to satisfy legal requirements. If we start from the semantic and logical concept of a quotation, then it should be obvious that the element should have a subelement for providing source information (“credits”), normally at the end of the element. The reason why this has not been so from the beginning is that blockquote was really designed for indentation, though it was _named_ after one use for indentation that the designers had in their mind. And that’s how it has been used. Since in current usage, blockquote means just “indent” more often than not, browsers and search engines should not and will not imply any specific semantics for it. Thus it will be pointless to use it. So leave blockquote as legacy markup and recommend it to be used, in new documents, only for indentation in rare situations where an author much prefers indentation even in the absence of CSS. And design markup for quotations so that suits practical needs and legal requirements. For this, introduce quotation with src as a subelement Yucca
Re: [whatwg] The blockquote element spec vs common quoting practices
Jukka K. Korpela jkorp...@cs.tut.fi schrieb am Sun, 12 Feb 2012 07:46:07 +0200: The blockquote has been, and will be, rather pointless without markup for “credits” (indication of author and source, which are normally required by law). Why do you hate the cite attribute? […] Seldom does an author wish to quote an entire section. It is not even legal to quote more than is required to fulfill the acceptable purpose of quoting. Elaborate? I don’t think I have ever quoted anything that could sensibly be called a section. And I don't think I have ever had a need for providing credits that went beyond having a URI in the cite attribute and a corresponding hyperlink in the surrounding prose. […] Wrapping blockquote inside figure just to be able to present “credits” as figcaption is highly artificial. It is also clumsy, especially considering that it would have to be the *normal* way of presenting a block quotation to satisfy legal requirements. May I conjecture that lawyers and judges function almost entirely unlike markup validators? Also, “normal” according to what rulebook? If we start from the semantic and logical concept of a quotation, then it should be obvious that the element should have a subelement for providing source information (“credits”), normally at the end of the element. That would needlessly complicate parsing the contents of a blockquote element quite a bit. Conceding that there is quite some content there that is marked up in this (incorrect) way … why would it not be “obvious” ro have a “for” attribute for the cite element? The reason why this has not been so from the beginning is that blockquote was really designed for indentation, though it was _named_ after one use for indentation that the designers had in their mind. And that’s how it has been used. https://tools.ietf.org/html/rfc1866#section-5.5.4 reads different. It even suggests an alternative presentation style for quotations we are currently using (prefixing with brackets instead of intendation). Since in current usage, blockquote means just “indent” more often than not, browsers and search engines should not and will not imply any specific semantics for it. Thus it will be pointless to use it. Riveting tale, chap. Can you provide proof? Anecdotally, I could tell you exactly one site (a forum) that uses blockquote for intendation and dozens (mostly blogs and wikis) who use it for quotation. So leave blockquote as legacy markup and recommend it to be used, in new documents, only for indentation in rare situations where an author much prefers indentation even in the absence of CSS. How do you propose to treat legacy content? And design markup for quotations so that suits practical needs and legal requirements. For this, introduce quotation with src as a subelement An alternative might lie in using some kind of framework … for description … of resources! Are you reasonably sure that Dublin Core or similar vocabularies can not help you with this use case? http://en.wikipedia.org/wiki/Dublin_Core Cheers, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] The blockquote element spec vs common quoting practices
2012-02-12 8:36, Nils Dagsson Moskopp wrote: Why do you hate the cite attribute? I don’t; it’s just useless, and it does not in any way satisfy the legal, moral, and scholarly requirements for specifying the source. Seldom does an author wish to quote an entire section. It is not even legal to quote more than is required to fulfill the acceptable purpose of quoting. Elaborate? “It shall be permissible to make quotations from a work which has already been lawfully made available to the public, provided that their making is compatible with fair practice, and their extent does not exceed that justified by the purpose.” http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html#P144_26032 And I don't think I have ever had a need for providing credits that went beyond having a URI in the cite attribute and a corresponding hyperlink in the surrounding prose. By the Berne convention, when a work is quoted, “mention shall be made of the source, and of the name of the author if it appears thereon.” The cite attribute, in addition to being practically unsupported, does not mention anything. A reference in the “surrounding prose” is a completely unstructured way, regarding HTML markup, and not suitable for most quotations. It is not reader-friendly at all to provide a bibliographic reference (author and full title at the minimum) inside text. If we start from the semantic and logical concept of a quotation, then it should be obvious that the element should have a subelement for providing source information (“credits”), normally at the end of the element. That would needlessly complicate parsing the contents of a blockquote element quite a bit. Is the comfortability of parsing crucial here? If you want semantic markup, you should be prepared to facing any technical difficulties that may arise, rather than let the technicalities dictate rules for markup. why would it not be “obvious” ro have a “for” attribute for the cite element? The cite element is, in practice, just some authors’ way of writing i, assumed to be more semantic, when the text is a book title, a movie name, or something similar. It has really nothing to do with quotations. The work mentioned might be quoted, too, in the context, but that’s coincidental. Since in current usage, blockquote means just “indent” more often than not, browsers and search engines should not and will not imply any specific semantics for it. Thus it will be pointless to use it. Riveting tale, chap. Can you provide proof? Actually the burden of proof is on those who think that blockquote has some useful support. Regarding on what authors actually use blockquote for, I’ve seen quite enough of pages that use nested blockquote elements to achieve different amounts of indentation. Discussion forums sometimes use blockquote for quotations (though surely not for quotations of sections), but that’s just because the authors of forum software found that markup suitable, as quotations are to be indented. Those who use table layout or style sheets often don’t bother using blockquote. So leave blockquote as legacy markup and recommend it to be used, in new documents, only for indentation in rare situations where an author much prefers indentation even in the absence of CSS. How do you propose to treat legacy content? The common treatment of blockquote has been well documented. An alternative might lie in using some kind of framework … for description … of resources! Are you reasonably sure that Dublin Core or similar vocabularies can not help you with this use case? No, I am absolutely sure that Dublin Core and friends has nothing to do with this. (Besides, DC is an old specification which has been casually used on web pages for many years, and turned out to be write-only metadata. All the recent efforts on the metadata front have ignored DC.) Whatever markup might turn out to be useful for metadata that associates a quoting document, a quotation, and the quoted source, it first needs some elements to relate to. In order to say, in metadata, something about the relationship between a quotation and its source, you need to mark up the quotation and a reference to the source at the very basic level. Preferably, using something that unambiguously mean “quotation” and “source of quotation” and not “indent” or “figure caption.” Yucca
Re: [whatwg] The blockquote element spec vs common quoting practices
Ian Hickson writes: On Thu, 14 Jul 2011, Kevin Marks wrote: There is another common pattern, seen in blogging a lot, of putting the citation at the top eg As cite class=vcarda href=http://www.gyford.com/phil/; class=url rel=acquaintance met colleagueabbr title=Phil Gyford class=fnPhil/abbr/a/cite wrote about the a href=http://www.gyford.com/phil/writing/2009/04/28/geocities.php;ugly and neglected fragments/a of Geocities:/p blockquote pGeoCities is an awful, ugly, decrepit mess. And this is why it will be sorely missed. It’s not only a fine example of the amateur web vernacular but much of it is an increasingly rare example of a emperiod/em web vernacular. GeoCities sites show what normal, non-designer, people will create if given the tools available around the turn of the millennium./p /blockquote ... the current markup handles it fine already (as you demonstrate above). Using cite like that isn't conforming, surely? Smylers
Re: [whatwg] The blockquote element spec vs common quoting practices
On Thu, Jul 14, 2011 at 22:48, Tantek Çelik tan...@cs.stanford.edu wrote: On Thu, Jul 14, 2011 at 12:35, Karl Dubost ka...@opera.com wrote: I like the pattern id/for pattern of forms. We could imagine p span for=quoteA class=authorSir John Typo/span has written plenty of a wonderful thing in cite for=quoteAAmazing title/cite very similar to those in span for=quoteB class=authorSusan Spellchecker/span's writings I really like this pattern. label for=input-id is a known working and in use pattern. It is a known working pattern because it actually has a direct effect on the UI, not because for+id is somehow more intuitive than its inverse, id+cite, which is currently not being used. It makes the label act as a click target for its associated input element, which is especially useful for radio buttons and checkboxes. That's the reason why I've used it, in any case, not because I wanted to be semantic in any way. Jorrit
Re: [whatwg] The blockquote element spec vs common quoting practices
15.07.2011 19:56, Bjartur Thorlacius wrote: On 7/15/11, Jukka K. Korpelajkorp...@cs.tut.fi wrote: Should it? Even when the book has no URL? If you expect urn:isbn:… to work anytime soon in any significant browser, you’re very optimistic. Wikipedia and Amazon (among others) have all the mechanisms already. Such ISBN handlers could even be registered by JavaScripts. Pardon? The issue is browser support to urn:isbn:…, not mechanisms that map ISBNs to some URLs in some system. Browsers currently treatcite just likei (except that it has a different name). There is no sign of advance functionality emerging. It does not matter how usable something is when it does not exist at all. Cite is not nearly as useful as @cite. cite is useful for using italics in a manner that makes you feel more structural. The cite attribute is completely useless unless you set up some processing of your own, just as a site could use for the foobar attribute (or data-foobar) So you're saying that users should rather search for the term ISBN, select the following number, copy it, remove/add hyphens as necessary and then paste it to a suitable bibliographic search form? No, I’m saying that a proper quotation cites a book unambiguously, and ISBNs are a useful tool there and should then appear in content proper, not hidden in an attribute that browsers ignore. It’s wishful thinking to say that cite attributes magically turn ISBN numbers to cool queries or links. If a browser, or some client-side JavaScript, can do something like that to a cite attribute, it could equally well do that to content like “ISBN” followed by a number of a certain type. That would be much more useful. But browsers need to be told that that number close to the quotation is an ISBN. The string “ISBN” is sufficient evidence of that. Before you saidcite was implemented asi, and your point is that the cite attribute is useless? Yes. They're barely related, They are both supposed to be used for citations. I think cite is actually used quite a lot, though not always consistently, whereas the cite attribute mostly occurs in W3C and related documents. @cite contains an URI, that an user agent might be able to use in an automated fashion. Might be able, but doesn’t. Can you mention one browser that actually does something useful with it? And it isn’t a particularly new feature in specifications; browser vendors have had plenty of time to implement it. Cite contains a human-readable name of a work. That'll rarely be machine-readable. HTML documents are always machine-readable. (Well, you _might_ just write HTML on a paper with a pen…) Association of a URL of the quoted work with a blockquote element is not _required_. Human-readable indication of the quoted work and its author is a legal requirement as well as a matter of appropriateness, so it should have priority over any kind of linking. When there is markup for such indications, and even now that there isn’t, you can always _link_ to the quoted work—if you have something to link to. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] The blockquote element spec vs common quoting practices
Le 15 juil. 2011 à 10:50, Jukka K. Korpela a écrit :
Should it? Even when the book has no URL? If you expect urn:isbn:… to work
anytime soon in any significant browser, you’re very optimistic.
in QuoteLink, I do a trick, eventually I should enable the provider of your
choice.
But basically
if (cite.startsWith(urn:isbn:)) {
isbn = cite.substring(9).replace(/\-/g, );
cite = http://openlibrary.org/isbn/; + isbn;
}
You could replace the openlibrary provider, by wikipedia, olcl, etc.
If we had a good model for describing authors, title, etc, we could even have a
pre-populated form, giving the information for things which are not yet
existent in Open Library. The first persons clicking on the link would have the
opportunity to add the book.
[1]: https://github.com/karlcow/QuoteLink
[2]: https://addons.opera.com/addons/extensions/details/quotelink/
--
Karl Dubost - http://dev.opera.com/
Developer Relations Tools, Opera Software
Re: [whatwg] The blockquote element spec vs common quoting practices
Jukka K. Korpela jkorp...@cs.tut.fi schrieb am Sun, 17 Jul 2011 17:09:54 +0300: 15.07.2011 19:56, Bjartur Thorlacius wrote: […] But browsers need to be told that that number close to the quotation is an ISBN. The string “ISBN” is sufficient evidence of that. Someone would need to standardize “ISBN sniffing behaviour” for UAs then. Could you make a proposal? […] @cite contains an URI, that an user agent might be able to use in an automated fashion. Might be able, but doesn’t. Can you mention one browser that actually does something useful with it? And it isn’t a particularly new feature in specifications; browser vendors have had plenty of time to implement it. Are any reasons for not doing anything with that information known? Probably a more basic issue: Is the cite attribute actually used? Cite contains a human-readable name of a work. That'll rarely be machine-readable. HTML documents are always machine-readable. (Well, you _might_ just write HTML on a paper with a pen…) This is a category error. “Machine-readable” in this context does not mean “digital information”. Fact: A scanned PDF of a printed out table of expenses (yes, these occur) may not be “machine-readable” in the sense Bjartur Thorlacius used here. An ATOM feed certainly is. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] The blockquote element spec vs common quoting practices
17.07.2011 18:07, Nils Dagsson Moskopp wrote: But browsers need to be told that that number close to the quotation is an ISBN. The string “ISBN” is sufficient evidence of that. Someone would need to standardize “ISBN sniffing behaviour” for UAs then. Could you make a proposal? I think it would be rather trivial. The string “ISBN” followed by something that matches the syntax of ISBN numbers, perhaps allowing some variation in punctuation, could be treated as an implicit link to a resource _if_ you have some mechanism(s) for mapping ISBN numbers to URLs. The key issue is whether browser vendors have interest in it and which mechanism(s) would be used. After all, an ISBN could be in a multitude of ways, like querying an online bookshop, querying an online bibliographic system, or querying an site of books in digital format online. Which one should be used? Would it be useful? To be really useful, it should be handled so that the browser checks what it can get using the ISBN and then make that information available to user (how to get bibliographic info, how to read reviews, how to buy the book, how to borrow it in a library, download or read the book via the net for free or for fee). Are any reasons for not doing anything with that information known? Probably a more basic issue: Is the cite attribute actually used? I don’t think it’s much used in the wild, except on pages by organizations that define HTML specs. What might be the motivation for browsers to do something special with it? Surely you could make things so that by clicking on a blockquote, the user accesses the resource pointed to by the cite attribute. Browsers could do that, and so could authors. But would users actually start clicking on quotations to see their sources? Surely they would far more probably click on the title of a work in visible credits if present and if it is a link, so what would the cite attribute help? Cite contains a human-readable name of a work. That'll rarely be machine-readable. HTML documents are always machine-readable. (Well, you _might_ just write HTML on a paper with a pen…) This is a category error. “Machine-readable” in this context does not mean “digital information”. No, it’s not a category thing. It’s about the relativity of being “machine-readable.” You are probably thinking of data in a specific format designed to be easily parseable and useable by computer software, such as a URL, an ISO 8601 date notation, or an XML tag. But browsers already do many kinds of heuristics, parsing data that doesn’t really match the specs. A title of a work is easily useable by software: put it inside quotation marks and throw it at Google, and the odds are that you get some useful links related to it, if there’s info on the work (and perhaps the work itself) on the web at all. Well, assuming that the title is relatively unique. Titles of works are often more useful in the long run than URLs. URLs change far too often when sites are revamped or for other reasons. I think a good start would be to add an optional (but usually recommended) credits or source element for use inside blockquote. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] The blockquote element spec vs common quoting practices
Þann sun 17.júl 2011 18:36, skrifaði Jukka K. Korpela: 17.07.2011 18:07, Nils Dagsson Moskopp wrote: I think it would be rather trivial. The string “ISBN” followed by something that matches the syntax of ISBN numbers, perhaps allowing some variation in punctuation, could be treated as an implicit link to a resource _if_ you have some mechanism(s) for mapping ISBN numbers to URLs. The key issue is whether browser vendors have interest in it and which mechanism(s) would be used. After all, an ISBN could be in a multitude of ways, like querying an online bookshop, querying an online bibliographic system, or querying an site of books in digital format online. Which one should be used? Would it be useful? To be really useful, it should be handled so that the browser checks what it can get using the ISBN and then make that information available to user (how to get bibliographic info, how to read reviews, how to buy the book, how to borrow it in a library, download or read the book via the net for free or for fee). I don’t think it’s much used in the wild, except on pages by organizations that define HTML specs. What might be the motivation for browsers to do something special with it? Surely you could make things so that by clicking on a blockquote, the user accesses the resource pointed to by the cite attribute. Browsers could do that, and so could authors. But would users actually start clicking on quotations to see their sources? Surely they would far more probably click on the title of a work in visible credits if present and if it is a link, so what would the cite attribute help? Good point No, it’s not a category thing. It’s about the relativity of being “machine-readable.” You are probably thinking of data in a specific format designed to be easily parseable and useable by computer software, such as a URL, an ISO 8601 date notation, or an XML tag. But browsers already do many kinds of heuristics, parsing data that doesn’t really match the specs. You *could* interpret handwritten text on a piece of paper using a machine and parse it as HTML. I'm not volunteering for making a machine for that task. A title of a work is easily useable by software: put it inside quotation marks and throw it at Google, and the odds are that you get some useful links related to it, if there’s info on the work (and perhaps the work itself) on the web at all. Well, assuming that the title is relatively unique. Titles of works are often more useful in the long run than URLs. URLs change far too often when sites are revamped or for other reasons. ISBNs are more useful in the long run than titles. Good titles get reused far too often. I think a good start would be to add an optional (but usually recommended) credits or source element for use inside blockquote. What about the common case of multiple quotations credited to the same source (interleaved with comments).
Re: [whatwg] The blockquote element spec vs common quoting practices
18.07.2011 01:18, Bjartur Thorlacius wrote: Titles of works are often more useful in the long run than URLs. URLs change far too often when sites are revamped or for other reasons. ISBNs are more useful in the long run than titles. Good titles get reused far too often. ISBNs have their uses (otherwise they wouldn’t be used), but they are codes, not names—suitable for use as unique identifiers, not in marketing and discussions. A quality quotation has credits that mention author, book title, book ISBN, and location within book. All this can be done in printed publications without any links or markup. So the adequate question is: which markup (if any) should we use for and within the credits? I haven’t seen many attempts to address this question. Maybe it’s not that crucial, as proper credits work without markup too—markup could just be very useful enhancement. But blockquote as a semantic element is wishful thinking then. HTML5 is currently making this a bit worse by explicitly forbidding blockquite from containing anything that doesn’t come from the external source, such as credits—without even telling how to deal with credits then. I think a good start would be to add an optional (but usually recommended) credits or source element for use inside blockquote. What about the common case of multiple quotations credited to the same source (interleaved with comments). People solve such issues every day when writing books and articles, using references to previous mentions of sources. At the shortest, “op. cit.” In hypertext, the reference can be made to a link. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] The blockquote element spec vs common quoting practices
14.07.2011 16:10, Bjartur Thorlacius wrote: Þann fim 14.júl 2011 11:09, skrifaði Jukka K. Korpela: 14.07.2011 13:49, Karl Dubost wrote: blockquote cite=urn:isbn:978-2-07-07533-7 pSur un pétale de lotus, j'écrivis ces quelques vers :/p p«qMême si l'on vient me chercherbr/ Comment, abandonnant la roséebr/ De pareil lotus,br/ Retournerai-jebr/ Dans le monde changeant et frivole ?/q »/p pet j'envoyais ce pétale./p p class=source cite class=auteurShonagon, Sei/cite, cite class=titreNotes de chevet/cite, p.64, Unesco, NRF, 1966./p /blockquote Yes, but for usability reasons the cite[@class=titre] should represent a hyperlink to the cited book. Should it? Even when the book has no URL? If you expect urn:isbn:… to work anytime soon in any significant browser, you’re very optimistic. Browsers currently treat cite just like i (except that it has a different name). There is no sign of advance functionality emerging. It does not matter how usable something is when it does not exist at all. Is an user agent to find a cite descendant of blockquote and make it represent a hyperlink to the cited resource (identified by the URI in the cite attribute of blockquote)? That would be rather pointless. If there is an online resource to link to, you can simply make the title a link to it, explicitly. Then you can also style the link to desired, and it will stand out as a link (unless the author styles it badly). I forgot to mention that the ISBN number should be included visibly in the credits, especially because it is usually the simplest and sometimes the only reasonable way to identify a book unambiguously (and can be copied and pasted into a suitable bibliographic search form). It’s metadata, but metadata that need not and should not be hidden but presented in textual content. At most it might be included into elements that are not initially displayed but become available when the user so requests—possibly some day via the details element if browsers implement it well. The cite attribute in blockquote should really be moved to the non-recommended part of HTML. It hardly ever serves a useful purpose, and it tends to mislead authors into including important information _only_ in the attribute, which has no browser support worth mentioning (despite having been in HTML for over 13 years). (I don't like to nitpick on the author identification, but wouldn’t cite class=auteur lang=jp-LatnShōnagon, Sei/cite be better?) I don't think author names are allowed in cite in HTML 5. They aren’t, but HTML5 linters (“validators”) won’t report the issue, as they don’t understand the meanings of words. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] The blockquote element spec vs common quoting practices
On 7/15/11, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 14.07.2011 16:10, Bjartur Thorlacius wrote: I don't think author names are allowed in cite in HTML 5. They aren’t, but HTML5 linters (“validators”) won’t report the issue, as they don’t understand the meanings of words. That doesn't make it any more valid.
Re: [whatwg] The blockquote element spec vs common quoting practices
On 7/15/11, Jukka K. Korpela jkorp...@cs.tut.fi wrote: Should it? Even when the book has no URL? If you expect urn:isbn:… to work anytime soon in any significant browser, you’re very optimistic. Wikipedia and Amazon (among others) have all the mechanisms already. Such ISBN handlers could even be registered by JavaScripts. Browsers currently treat cite just like i (except that it has a different name). There is no sign of advance functionality emerging. It does not matter how usable something is when it does not exist at all. Cite is not nearly as useful as @cite. I forgot to mention that the ISBN number should be included visibly in the credits, especially because it is usually the simplest and sometimes the only reasonable way to identify a book unambiguously (and can be copied and pasted into a suitable bibliographic search form). It’s So you're saying that users should rather search for the term ISBN, select the following number, copy it, remove/add hyphens as necessary and then paste it to a suitable bibliographic search form? Instead of registering a suitable bibliographic search form once, and having the user agent do the hard work in a click or two? metadata, but metadata that need not and should not be hidden but presented in textual content. At most it might be included into elements that are not initially displayed but become available when the user so requests—possibly some day via the details element if browsers implement it well. But browsers need to be told that that number close to the quotation is an ISBN. And if you always hide it in details, user agents may be compelled to expand it by default, making it unusable for e.g. hiding answers to a quiz. The cite attribute in blockquote should really be moved to the non-recommended part of HTML. It hardly ever serves a useful purpose, and it tends to mislead authors into including important information _only_ in the attribute, which has no browser support worth mentioning (despite having been in HTML for over 13 years). Before you said cite was implemented as i, and your point is that the cite attribute is useless? They're barely related, @cite contains an URI, that an user agent might be able to use in an automated fashion. Cite contains a human-readable name of a work. That'll rarely be machine-readable.
Re: [whatwg] The blockquote element spec vs common quoting practices
Hi Bjartur, On Tue, Jul 12, 2011 at 8:28 PM, Bjartur Thorlacius svartma...@gmail.com wrote: Þann þri 12.júl 2011 09:15, skrifaði Oli Studholme: Datetimes will usually be presented in a localized format to humans. I think at most user agents will offer users the option to localise datetime attributes. I don’t think such localisation would be the default. This is because even in one localisation there are multiple ways to present dates, and automatically changing a short date form to a long localised date form may break layout (which user agents avoid wherever possible). How would the user agent know which way the author wants to present attribution? By fetching and reading a linked stylesheet. I think it's easier to style attributes then text nodes polluted with delimiters such as from and by that make reordering hard. This is an interesting idea. However I think this would be a large increase in complexity (code l10n) for user agents, and for little gain. If the user agent was also translating the content then this might be considered, but merely styling block quote attribution this way would involve many options per language (depending on what attributes were present and what data they displayed). There are a *lot* of potential attributes just for citation. http://microformats.org/wiki/citation lists 22. Even providing for all of these will still exclude other potential block quote-related information, such as notes, copyright etc More importantly, how is the author to know how the user wants attribution presented? Heh. Generally users are happy with the author’s content as long as they can read it. I think there’d be few people in the world that would care enough to add user styles to change e.g. from a bibliographic to an author-date system citation. For more than this you may need to wait for the semantic web ;) Again I have no idea how a user agent would follow these rules. Arbitrarily showing one thing in one viewport size and something else at a different size would be a bug (arbitrarily meaning without author/user intervention, such as via CSS). A feature to one, a bug to another. The existence of the CSS height and width media features suggests that catering style to varying viewport sizes is desired by others than just me. I don't see why a user agent should seek an authors' permission to style a document for an unusually sized viewport, nor require users to write their own stylesheets instead of shipping customizable stylesheets. However you’re advocating the user agent follow these rules without author/user intervention. The reason that adaptive layout isn’t done by default by user agents (with some notable exceptions in mobile) is that it has the potential to break things, in such a way that neither the author or user can fix. For a lack of a valid URI identifying myself, I used an unregistered uri-scheme (kennitala) and my national ID as the scheme-specific part. The exact URI in question is unimportant to the example, but I see no reason to restrict values of cite to locators only, as opposed to identifiers in general. Quoting books identified by ISBN numbers seems like a good enough use case to me. But what would a user agent do with an ISBN number? if there’s a URL at least the user agent can theoretically present a link, like how the cite attribute is supposed to work. I also just realised you used this in your footer example for an href. This would present text styled as a link that doesn’t respond to clicks, a usability problem. This proves Jeremy's earlier point about attributes being a bad place to store data. Unless you look at the source you’d never notice these mistakes. Sure I would, had I actually tried to, say, render them or validate before posting them on the Internet. I refrained from doing so as I knew this to be invalid markup, anyway. Where datetime to be a valid attribute of blockquote You are assuming the rest of the internet’s authors are as conscientious as you are :/ humans are very adept at making mistakes. hidden data makes mistakes in this data far harder to identify and correct No, that would be quite an odd rendering. More likely renderings: Þann annan apríl 1997 skrifaði Bjartur Thorlacius: Lorem ipsum On the second April, 1997 Bjartur Thorlacius wrote: Lorem ipsum “ Lorem ipsum — Bjartur Thorlacius It all depends on the user's localized stylesheet. this requires the user agent to localise the attributes before displaying them. what about for languages which aren’t localised in the user’s stylesheet? There’s also the possibility of adding another inline element, such as credit, which could let someone credit an author of a quote, or e.g. to credit a photographer of an image togetherfigure and figcaption. So credit would be an inline version of footer, to be contained in q? Would it not be more consistent to use attributes, in that case? Note that figcaption may contain footers.
Re: [whatwg] The blockquote element spec vs common quoting practices
Le 8 juil. 2011 à 07:20, Jeremy Keith a écrit : 1) Oli has shown the real-world use cases for attribution *within* blockquotes. using that for years (almost every day), an example http://www.la-grange.net/2011/06/05/fruit blockquote cite=urn:isbn:978-2-07-07533-7 pSur un pétale de lotus, j'écrivis ces quelques vers :/p p« qMême si l'on vient me chercherbr/ Comment, abandonnant la roséebr/ De pareil lotus,br/ Retournerai-jebr/ Dans le monde changeant et frivole ?/q »/p pet j'envoyais ce pétale./p p class=source cite class=auteurShonagon, Sei/cite, cite class=titreNotes de chevet/cite, p.64, Unesco, NRF, 1966./p /blockquote mentioned here http://lists.w3.org/Archives/Public/www-html/2005Jun/0201 My favorite issue being when there is a mix of cite in the prose and blockquotes, there is no mechanism to associate the right cite with the right blockquote and this is happening often when you write about things referring to different sources. http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Dec/0016 -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [whatwg] The blockquote element spec vs common quoting practices
14.07.2011 13:49, Karl Dubost wrote:
using that for years (almost every day), an example
http://www.la-grange.net/2011/06/05/fruit
blockquote cite=urn:isbn:978-2-07-07533-7
pSur un pétale de lotus, j'écrivis ces quelques vers :/p
p«qMême si l'on vient me chercherbr/
Comment, abandonnant la roséebr/
De pareil lotus,br/
Retournerai-jebr/
Dans le monde changeant et frivole ?/q »/p
pet j'envoyais ce pétale./p
p class=source
cite class=auteurShonagon, Sei/cite,
cite class=titreNotes de chevet/cite, p.64, Unesco, NRF,
1966./p
/blockquote
That’s quite good, though I think footer class=source would be in
principle better than p class=source, though using footer still
requires some precautions in practice (I mean “teaching” it to old IE
using document.createElement('footer') in JavaScript, so that your
styling will take effect).
Microdata or microformats might be used to standardize the use of
specific attributes to be used, like class=credits, class=author,
class=title etc., if desired. But I don’t think that’s particularly
important.
(I don't like to nitpick on the author identification, but wouldn’t
cite class=auteur lang=jp-LatnShōnagon, Sei/cite be better?)
My favorite issue being when there is a mix of cite in the prose and
blockquotes,
there is no mechanism to associate the right cite with the right
blockquote
It would be nice to be able to associate credits with quotations at the
markup level, but in practice, presenting credits visibly (or audibly or
touchably) is much more important. No law requires us to provide credits
that way, but laws do require us to provide credits the way they are
normally provided in good style (or in a better way).
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] The blockquote element spec vs common quoting practices
Þann fim 14.júl 2011 09:38, skrifaði Oli Studholme: in graphic design a footer contains supplementary information about the content it follows. the spec initially disallowed ‘fat footers’, but the naming and common usage would have led to people using them for fat footers regardless of the spec. they still contain supplementary information about their sectioning element or sectioning root. This semantic connection seems stronger to me than one based on arbitrary size Would it not be less confusing to forbid 'fat footers' and rename footer - credit?
Re: [whatwg] The blockquote element spec vs common quoting practices
Þann fim 14.júl 2011 11:09, skrifaði Jukka K. Korpela: 14.07.2011 13:49, Karl Dubost wrote: blockquote cite=urn:isbn:978-2-07-07533-7 pSur un pétale de lotus, j'écrivis ces quelques vers :/p p«qMême si l'on vient me chercherbr/ Comment, abandonnant la roséebr/ De pareil lotus,br/ Retournerai-jebr/ Dans le monde changeant et frivole ?/q »/p pet j'envoyais ce pétale./p p class=source cite class=auteurShonagon, Sei/cite, cite class=titreNotes de chevet/cite, p.64, Unesco, NRF, 1966./p /blockquote Yes, but for usability reasons the cite[@class=titre] should represent a hyperlink to the cited book. Is an user agent to find a cite descendant of blockquote and make it represent a hyperlink to the cited resource (identified by the URI in the cite attribute of blockquote)? (I don't like to nitpick on the author identification, but wouldn’t cite class=auteur lang=jp-LatnShōnagon, Sei/cite be better?) I don't think author names are allowed in cite in HTML 5.
Re: [whatwg] The blockquote element spec vs common quoting practices
There is another common pattern, seen in blogging a lot, of putting the citation at the top eg As cite class=vcarda href=http://www.gyford.com/phil/; class=url rel=acquaintance met colleagueabbr title=Phil Gyford class=fnPhil/abbr/a/cite wrote about the a href=http://www.gyford.com/phil/writing/2009/04/28/geocities.php;ugly and neglected fragments/a of Geocities:/p blockquote pGeoCities is an awful, ugly, decrepit mess. And this is why it will be sorely missed. It’s not only a fine example of the amateur web vernacular but much of it is an increasingly rare example of a emperiod/em web vernacular. GeoCities sites show what normal, non-designer, people will create if given the tools available around the turn of the millennium./p /blockquote (from jeremy) or pretty much any post here: http://www.theatlantic.com/ta-nehisi-coates/ Would a header pattern in the blockquote work for this? If I was writing a detector for this pattern, a followed by a colon and blockquote would do it pretty reliably... On Fri, Jul 8, 2011 at 4:20 AM, Jeremy Keith jer...@adactio.com wrote: Oli wrote: I’ve outlined the problem and some potential solutions (with their pros and cons) in: http://oli.jp/2011/blockquote/ Excellent work, IMHO. I've added my own little +1 here: http://adactio.com/journal/4675/ Oli continues: I think the blockquote spec should be changed to allow the inclusion of notes and attribution (quote metadata), perhaps by the addition of a sentence like: “Block quotes may also contain annotations or attribution, inline or in an optional footer element” This would change blockquote from being purely source content, to being source content with possible metadata inline or in a footer. However I don’t think that’s a problem, as these things increase the value of the quoted content. I think a spec change is necessary to accommodate common quoting practices. This sounds good to me. 1) Oli has shown the real-world use cases for attribution *within* blockquotes. I know that the Pave the cowpaths principle gets trotted out a lot, but Oli's research here is a great example of highlighting existing cowpaths (albeit in printed rather than online material): http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new. 2) This is something that authors want, both on the semantic and styling level (i.e. a way to avoid having to wrap every blockquote in a div just to associate attribution information with said blockquote). I believe that the problem statement that Oli has outlined fits with the HTML design principle Solve real problems. http://www.w3.org/TR/html-design-principles/#solve-real-problems Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. 3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle Avoid needless complexity. http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand. 4) Because the footer element is new to HTML5, I don't foresee any backward-compatibility issues. The web isn't filled with blockquotes containing footers that are part of the quoted material. Oli's solution would match up nicely with the design principle Support existing content. http://www.w3.org/TR/html-design-principles/#support-existing-content The benefit of the proposed change should be weighed against the likely cost of breaking content Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] The blockquote element spec vs common quoting practices
On 7/14/11, Kevin Marks kevinma...@gmail.com wrote: There is another common pattern, seen in blogging a lot, of putting the citation at the top eg As cite class=vcarda href=http://www.gyford.com/phil/; class=url rel=acquaintance met colleagueabbr title=Phil Gyford class=fnPhil/abbr/a/cite wrote about the a href=http://www.gyford.com/phil/writing/2009/04/28/geocities.php;ugly and neglected fragments/a of Geocities:/p blockquote pGeoCities is an awful, ugly, decrepit mess. And this is why it will be sorely missed. It’s not only a fine example of the amateur web vernacular but much of it is an increasingly rare example of a emperiod/em web vernacular. GeoCities sites show what normal, non-designer, people will create if given the tools available around the turn of the millennium./p /blockquote (from jeremy) or pretty much any post here: http://www.theatlantic.com/ta-nehisi-coates/ Would a header pattern in the blockquote work for this? If I was writing a detector for this pattern, a followed by a colon and blockquote would do it pretty reliably... Ideally, the same markup should be used to mark citations up whether they're displayed one way or another. Whether to render author name(s) before or after the quotation is a matter of style.
Re: [whatwg] The blockquote element spec vs common quoting practices
Le 14 juil. 2011 à 14:59, Kevin Marks a écrit : If I was writing a detector for this pattern, a followed by a colon and blockquote would do it pretty reliably... yup unfortunately there are also many cases where you have more names in an introducing paragraph. It is happening when I'm writing, and the issue is then to tie the right person with the right blockquote/q I like the pattern id/for pattern of forms. We could imagine p span for=quoteA class=authorSir John Typo/span has written plenty of a wonderful thing in cite for=quoteAAmazing title/cite very similar to those in span for=quoteB class=authorSusan Spellchecker/span's writings blockquote id=quoteA […] /blockquote compare to cite for=quoteBAmazing title/cite blockquote id=quoteB /blockquote -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [whatwg] The blockquote element spec vs common quoting practices
In agreement with Jeremy, I too have found the blockquote/q cite attribute to be nearly as ignored as the longdesc attribute, despite having conducted talks and written tutorials about how to use the cite= attribute (makes me think that the non-visible-effect-URL attributes on elements should be considered an anti-pattern, evidenced by the fact that they (cite, longdesc, profile etc.) have all failed to get any meaningful uptake among web developers). On slightly a more positive note: On Thu, Jul 14, 2011 at 12:35, Karl Dubost ka...@opera.com wrote: Le 14 juil. 2011 à 14:59, Kevin Marks a écrit : If I was writing a detector for this pattern, a followed by a colon and blockquote would do it pretty reliably... yup unfortunately there are also many cases where you have more names in an introducing paragraph. It is happening when I'm writing, and the issue is then to tie the right person with the right blockquote/q I like the pattern id/for pattern of forms. We could imagine p span for=quoteA class=authorSir John Typo/span has written plenty of a wonderful thing in cite for=quoteAAmazing title/cite very similar to those in span for=quoteB class=authorSusan Spellchecker/span's writings blockquote id=quoteA […] /blockquote compare to cite for=quoteBAmazing title/cite blockquote id=quoteB /blockquote I really like this pattern. label for=input-id is a known working and in use pattern. Thus I feel much more confident advocating use of the parallel: cite for=quote-id With one concern - multiple blockquotes. Thus the for attribute should be a space separated set of IDREFs. E.g. this pattern (often seen on blog posts analyzing articles and other blog posts) cite for=quote1 quote2Some quoted title of a work/cite blockquote id=quote1 one quotation /blockquote p .. intervening commentary .. /p blockquote id=quote2 another quotation /blockquote p .. more commentary ../p Though that example is vulnerable to bad copy/paste errors. It requires two markup updates (done consistently) for each copy/paste: a new id on each new blockquote, and having to update the original cite element for each additional blockquote. That example redone with today's cite attribute would be: cite id=cite1Some quoted title of a work/cite blockquote cite=#cite1 one quotation /blockquote p .. intervening commentary .. /p blockquote cite=#cite1 another quotation /blockquote p .. more commentary ../p which is then much more copy/paste proof if/when the author adds more blockquotes from the same source that they're commenting on - fewer bits of markup (none) to update. So I don't know. Perhaps cite for handles the 80/20 one cite / one quote case better and that's good enough to add it, and then perhaps we keep the old cite= attribute for the one cite / multiple quote case? Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] The blockquote element spec vs common quoting practices
Le 14 juil. 2011 à 16:48, Tantek Çelik a écrit : cite= attribute (makes me think that the non-visible-effect-URL attributes on elements Yup. :) and there are ways to improve what the browser doesn't do :) (though I really think the browser should) I made a prototype for this https://github.com/karlcow/QuoteLink https://addons.opera.com/addons/extensions/details/quotelink/ any suggestions for improving are welcome. -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [whatwg] The blockquote element spec vs common quoting practices
Bjartur wrote: I'd like to reemphasize that: *unsupported by user agents* So you're saying that because attributes aren't rendered by default, user agents will ignore them and thus we should not use them? It's not a matter of should not. Because user agents ignore them, we *do not* use them. And the main reason why we don't use them is that there's little to be gained: the information isn't presented to the end user. Wishful thinking isn't going to make the @cite attribute any more useful or more widely adopted (either by authors or user agents). Putting attribution inside blockquotes seems like a hack around lax support for attributes. No, putting attribution inside blockquotes solves the real-world use-cases that Oli has gathered together. I'm not sure I understand the question. Do you mean presentational as in not conveying semantics or presentational as in visible? Not conveying semantics. How can you say that the footer element would not convey semantics, when it is defined as follows: The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like. —http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-footer-element ...and the blockquote element is a sectioning root. The semantics of those two elements match up perfectly. Interactive user agents should additionally make the cited resource available in manner similar to how they present other hyperlinked resources Can you please give an example of user agents presenting *invisible* hyperlinked resources? @longdesc, perhaps? Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] The blockquote element spec vs common quoting practices
Hi Bjartur, Firstly thank you (and you Jeremy!) for your input. This thread will help decide how the blockquote spec changes to accommodate the use cases I outlined, so the more input the better. On Tue, Jul 12, 2011 at 2:52 AM, Bjartur Thorlacius svartma...@gmail.com wrote: I'm not arguing against rendering attribution. On the contrary, IMO user agents should render at least the title of the cited resource. This is a can of worms as authors will want control over both content and style. Attributes turned into content are harder to style than content. Also attributes tend to be for either humans (@alt) or machines (@datetime), so displaying attributes (for humans) that contain data (for machines) generally gives bad results. Interactive user agents should additionally make the cited resource available in manner similar to how they present other hyperlinked resources. In the print use cases I found, sometimes attribution is inline after the last sentence and sometimes on a following line. This is in addition to having attribution in the prose surrounding the block quote, as currently recommended by the spec. How would the user agent know which way the author wants to present attribution? Additionally user agents with superfluous screen space may render the datetime. Handheld renderings should of course not display the datetime without user interaction, but reserve the screen estate for more critical information, such as the quotation itself. Again I have no idea how a user agent would follow these rules. Arbitrarily showing one thing in one viewport size and something else at a different size would be a bug (arbitrarily meaning without author/user intervention, such as via CSS). Love your phrase “superfluous screen space” btw ;) It's simply a question of blockquote Lorem ipsum footer a href=kennitala:2112952019 title=Bjartur ThorlaciusBjartur/a on time datetime=1997-4-2the second April, 1997/time /footer /blockquote vs blockquote title=Bjartur Thorlacius datetime=1997-4-2 cite=kennitala:2112952019 Lorem ipsum /blockquote You've got two additional problems in your example: * currently only the time, ins and del elements accept the datetime attribute, and this isn't even a valid datetime value (you wanted 1997-04-02) * the cite attribute must be a valid URL, and is for providing a link to more information about the quote (generally its source) – you can't use it for non-URL data This proves Jeremy's earlier point about attributes being a bad place to store data. Unless you look at the source you’d never notice these mistakes. I also note that your footer example contains a lot more content, the visible part being “Bjartur on the second April, 1997”. A potential rendering of the attributes in your second example would probably be something like “Bjartur Thorlacius 1997-04-02, which I think isn’t as good. This refers to my first point about authors wanting to control the content. Finally two other strikes against attributes are they're harder for people learning HTML (which is one reason we have section over role=section etc), and we already have three (I’d argue) perfectly good elements for the data you are suggesting adding via attributes: * footer for following-line attribution and notes * time for datetime information * a and cite for citation information There’s also the possibility of adding another inline element, such as credit, which could let someone credit an author of a quote, or e.g. to credit a photographer of an image together figure and figcaption. For the reasons Jeremy mentioned, I actually hope the cite attribute gets dropped in favour of a visible, explicit form of attribution. While something like a and cite in a footer could work for citation, I still don’t have a good idea about citing explicitly when the citation is inline (on the last line of the block quote), or for q. HTH peace - oli studholme
Re: [whatwg] The blockquote element spec vs common quoting practices
Þann þri 12.júl 2011 09:15, skrifaði Oli Studholme: Firstly thank you (and you Jeremy!) for your input. This thread will help decide how the blockquote spec changes to accommodate the use cases I outlined, so the more input the better. Thank you for your commentary, it is most appreciated. On Tue, Jul 12, 2011 at 2:52 AM, Bjartur Thorlacius svartma...@gmail.com wrote: I'm not arguing against rendering attribution. On the contrary, IMO user agents should render at least the title of the cited resource. This is a can of worms as authors will want control over both content and style. Attributes turned into content are harder to style than content. Also attributes tend to be for either humans (@alt) or machines (@datetime), so displaying attributes (for humans) that contain data (for machines) generally gives bad results. Datetimes will usually be presented in a localized format to humans. In the print use cases I found, sometimes attribution is inline after the last sentence and sometimes on a following line. This is in addition to having attribution in the prose surrounding the block quote, as currently recommended by the spec. How would the user agent know which way the author wants to present attribution? By fetching and reading a linked stylesheet. I think it's easier to style attributes then text nodes polluted with delimiters such as from and by that make reordering hard. More importantly, how is the author to know how the user wants attribution presented? Again I have no idea how a user agent would follow these rules. Arbitrarily showing one thing in one viewport size and something else at a different size would be a bug (arbitrarily meaning without author/user intervention, such as via CSS). A feature to one, a bug to another. The existence of the CSS height and width media features suggests that catering style to varying viewport sizes is desired by others than just me. I don't see why a user agent should seek an authors' permission to style a document for an unusually sized viewport, nor require users to write their own stylesheets instead of shipping customizable stylesheets. Love your phrase “superfluous screen space” btw ;) :P It's simply a question of blockquote Lorem ipsum footer a href=kennitala:2112952019 title=Bjartur ThorlaciusBjartur/a ontime datetime=1997-4-2the second April, 1997/time /footer /blockquote vs blockquote title=Bjartur Thorlacius datetime=1997-4-2 cite=kennitala:2112952019 Lorem ipsum /blockquote You've got two additional problems in your example: * currently only thetime,ins anddel elements accept the datetime attribute, and this isn't even a valid datetime value (you wanted 1997-04-02) Ops, you're correct; this should've been 1997-04-02. I'm proposing adding a datetime attribute to blockquote. * the cite attribute must be a valid URL, and is for providing a link to more information about the quote (generally its source) – you can't use it for non-URL data For a lack of a valid URI identifying myself, I used an unregistered uri-scheme (kennitala) and my national ID as the scheme-specific part. The exact URI in question is unimportant to the example, but I see no reason to restrict values of cite to locators only, as opposed to identifiers in general. Quoting books identified by ISBN numbers seems like a good enough use case to me. This proves Jeremy's earlier point about attributes being a bad place to store data. Unless you look at the source you’d never notice these mistakes. Sure I would, had I actually tried to, say, render them or validate before posting them on the Internet. I refrained from doing so as I knew this to be invalid markup, anyway. Where datetime to be a valid attribute of blockquote I also note that yourfooter example contains a lot more content, the visible part being “Bjartur on the second April, 1997”. A potential rendering of the attributes in your second example would probably be something like “Bjartur Thorlacius 1997-04-02, which I think isn’t as good. This refers to my first point about authors wanting to control the content. No, that would be quite an odd rendering. More likely renderings: Þann annan apríl 1997 skrifaði Bjartur Thorlacius: Lorem ipsum On the second April, 1997 Bjartur Thorlacius wrote: Lorem ipsum “ Lorem ipsum — Bjartur Thorlacius It all depends on the user's localized stylesheet. Note that a datetime in a time element would have to parsed just as date in a datetime attribute of a blockquote. They're both machine readable (and that's the best way to internationalize dates). Finally two other strikes against attributes are they're harder for people learning HTML (which is one reason we havesection over role=section etc), and we already have three (I’d argue) perfectly good elements for the data you are suggesting adding via attributes: *footer for following-line attribution and notes *time for datetime information *a andcite for
Re: [whatwg] The blockquote element spec vs common quoting practices
On 7/8/11, Jeremy Keith jer...@adactio.com wrote: Bjartur wrote: Citation will most likely contain the cited resource (@cite), the title of the cited resource (@title) and the date and optionally time of the quote (@datetime?). All three of which are invisible and so do not match the use cases that Oli has outlined. At least @title has a tooltip but the @cite attribute has proven to be a complete disaster, unsupported by user agents and ignored by authors, I'd like to reemphasize that: *unsupported by user agents* So you're saying that because attributes aren't rendered by default, user agents will ignore them and thus we should not use them? Why can't we fix UAs? Putting attribution inside blockquotes seems like a hack around lax support for attributes. That what's CSS is for. precisely because it is *hidden* metadata. http://www.well.com/~doctorow/metacrap.htm Yes, people lie. Unless you're arguing that using attribute syntax will encourage misquoting, I'll regard this article as interesting, correcting and unrelated. The article argues against searching for information in uncensored repositories of structured data prone to spamming, not typing footerasdf/footer instead of title=asdf. So I think that we can learn from the history of the @cite attribute in that it shows us how *not* to do it. But is it really possible to mark such citations up without presentational elements? I'm not sure I understand the question. Do you mean presentational as in not conveying semantics or presentational as in visible? Not conveying semantics. I'm not arguing against rendering attribution. On the contrary, IMO user agents should render at least the title of the cited resource. Interactive user agents should additionally make the cited resource available in manner similar to how they present other hyperlinked resources. Additionally user agents with superfluous screen space may render the datetime. Handheld renderings should of course not display the datetime without user interaction, but reserve the screen estate for more critical information, such as the quotation itself. It's simply a question of blockquote Lorem ipsum footer a href=kennitala:2112952019 title=Bjartur ThorlaciusBjartur/a on time datetime=1997-4-2the second April, 1997/time /footer /blockquote vs blockquote title=Bjartur Thorlacius datetime=1997-4-2 cite=kennitala:2112952019 Lorem ipsum /blockquote
Re: [whatwg] The blockquote element spec vs common quoting practices
Oli wrote: I’ve outlined the problem and some potential solutions (with their pros and cons) in: http://oli.jp/2011/blockquote/ Excellent work, IMHO. I've added my own little +1 here: http://adactio.com/journal/4675/ Oli continues: I think the blockquote spec should be changed to allow the inclusion of notes and attribution (quote metadata), perhaps by the addition of a sentence like: “Block quotes may also contain annotations or attribution, inline or in an optional footer element” This would change blockquote from being purely source content, to being source content with possible metadata inline or in a footer. However I don’t think that’s a problem, as these things increase the value of the quoted content. I think a spec change is necessary to accommodate common quoting practices. This sounds good to me. 1) Oli has shown the real-world use cases for attribution *within* blockquotes. I know that the Pave the cowpaths principle gets trotted out a lot, but Oli's research here is a great example of highlighting existing cowpaths (albeit in printed rather than online material): http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new. 2) This is something that authors want, both on the semantic and styling level (i.e. a way to avoid having to wrap every blockquote in a div just to associate attribution information with said blockquote). I believe that the problem statement that Oli has outlined fits with the HTML design principle Solve real problems. http://www.w3.org/TR/html-design-principles/#solve-real-problems Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. 3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle Avoid needless complexity. http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand. 4) Because the footer element is new to HTML5, I don't foresee any backward-compatibility issues. The web isn't filled with blockquotes containing footers that are part of the quoted material. Oli's solution would match up nicely with the design principle Support existing content. http://www.w3.org/TR/html-design-principles/#support-existing-content The benefit of the proposed change should be weighed against the likely cost of breaking content Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] The blockquote element spec vs common quoting practices
Þann fös 8.júl 2011 11:20, skrifaði Jeremy Keith: 3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle Avoid needless complexity. http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand. Citation will most likely contain the cited resource (@cite), the title of the cited resource (@title) and the date and optionally time of the quote (@datetime?). Further information could be put into other attributes as necessary. This seems simpler than cluttering the quote and citation together in the blockquote, but just throwing everything inside of the blockquote may very well be easier to implement. But is it really possible to mark such citations up without presentational elements? !-- 2112952019 = my national ID -- blockquote cite=kennitala:2112952019 title=Bjartur Thorlacius pLook ma, no lt;footer!/p pI think we should keep citations outside of lt;blockquote's contents as citations aren't part of the quote per se, but metadata on the quote and the quoted resource/p /blockquote
Re: [whatwg] The blockquote element spec vs common quoting practices
Bjartur wrote: Citation will most likely contain the cited resource (@cite), the title of the cited resource (@title) and the date and optionally time of the quote (@datetime?). All three of which are invisible and so do not match the use cases that Oli has outlined. At least @title has a tooltip but the @cite attribute has proven to be a complete disaster, unsupported by user agents and ignored by authors, precisely because it is *hidden* metadata. http://www.well.com/~doctorow/metacrap.htm So I think that we can learn from the history of the @cite attribute in that it shows us how *not* to do it. But is it really possible to mark such citations up without presentational elements? I'm not sure I understand the question. Do you mean presentational as in not conveying semantics or presentational as in visible? Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
