Re: [whatwg] Allow Fallback Text to Render Section Titles in Outlines
On Sat, Feb 11, 2012 at 5:18 AM, Hugh Guiney hugh.gui...@gmail.com wrote: Currently when I run markup like this through outliner programs, they return blank section titles: h1img src=/img/logo.png alt=Company Name //h1 h1 svg g titleCompany Name/title path / … /g /svg /h1 I feel that in both instances, Company Name should become the section title for the respective section. Doesn't the spec imply it should? -- Benjamin Hawkes-Lewis
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
