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
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
[whatwg] The blockquote element spec vs common quoting practices
Hi All, 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 2. Adding quote metadata inline, such as notes and attribution 3. Adding quote metadata on a line after the block quote, but such that it remains visually associated with the quote 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’ve outlined the problem and some potential solutions (with their pros and cons) in: http://oli.jp/2011/blockquote/ 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. Thanks for your time peace - oli studholme PS Background information: http://html5doctor.com/blockquote-q-cite/ http://www.w3.org/Bugs/Public/show_bug.cgi?id=13082 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032274.html (“Using footer in blockquote for attribution” thread)
[whatwg] Using footer in blockquote for attribution
Hi All, Over at http://html5doctor.com we’ve been using this pattern when quoting e.g. from the HTML5 spec: blockquote p[block quote]/p footer— citea href=…[title of work]/a/cite/footer /blockquote I wrote about our use of blockquote and footer in http://html5doctor.com/blockquote-q-cite/ recently, which lead to http://www.w3.org/Bugs/Public/show_bug.cgi?id=13082. To recap: Footer definition: “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.” Blockquote definition: “The blockquote element represents a section that is quoted from another source. Content inside a blockquote must be quoted from another source, whose address, if it has one, may be cited in the cite attribute.” Simon felt that “Content inside a blockquote must be quoted from another source” excludes footer. However the footer definition reads to me that footer is basically metadata *about* content (the non-footer or -header content of the sectioning or sectioning root element). I’m happy to propose some reasons for allowing this, but to start with does blockquote’s definition beat footer’s definition? Or, is footer considered content as far as the blockquote definition is concerned? Thanks in advance. peace - oli studholme
[whatwg] time element use cases for less specific datetime values
Hi there, I’d like to contribute to the discussion on the time element with some use cases On Thu, Mar 19, 2009 at 10:35 AM, Ian Hickson i...@hixie.ch wrote: The primary use cases for time are: * The ability to encode 80% of dates and times in a machine-readable way so that the user can make use of them in an automated fashion, in particular for adding dates to a calendar. * The ability to restyle dates that contain a day component so that they follow user conventions (2000-12-31 vs 31-12-2000 vs 12-31-2000). * The ability to encode the output of input type=date and input type=time in an unambiguous fashion, for styling. None of these require that time be able to express years or year-month pairs; what are the use cases that we should address that need time to support these formats? #1 Adding month or year (imprecise) dates to a calendar I’m involved in organising events, and as part of this we make plans for events with approximate times. Currently we use a shared calendar plus have a list of events and approximate dates on a private website. Rather than add a list of events to a web page plus add event data to both a calendar, I’d like to list the events on a web page using time and hCalendar or a microdata vocabulary, then add these events to a calendar via a conversion tool. A workaround would be to use full dates, but that gives a false indication of accuracy. #2 Restyling dates As others have already mentioned, in Japan it’s common to display dates as 20-8-2010, 2010-8-20 and 2010年8月20日. In addition there’s this fun alternative year system that’s still widely used, including in official documents such as driver’s licenses, based on eras. Currently it’s the 22nd year of the Heisei era; 平22年8月20日. As in Hixie’s example of allowing dates to be restyled to follow user conventions, it would also be very useful to allow this for year and year-month dates, as even Japanese people have difficulty converting between the two systems, especially for anything before they were born. Allowing year and year-month @datetime values would allow a browser to offer localisation of date display including conversion between these two date formats. For example: time datetime=1935昭9年/time could be automatically restyled to time datetime=19351935/time (that’s the ninth year of the Shōwa era btw ;) Japanese credit cards frequently list only two digits for expiry year (eg “10/15”), and some Japanese e-commerce sites use a 2-digit input for year. Confusingly (well initially for me) these are always the abbreviated 4-digit year not the era year. Having this information semantically notated would make it more accessible. #3 Encoding input unambiguously If this is a use case, it would be nice to be able to encode all the datetime-related states of the input element. It’s not currently possible to use time for month and week input states. It would also be nice to have a year state for input, as it has more use cases than week, and it would allow combining with the month state for e.g. credit card info. Finally, I’m not sure how much of a use-case this makes but I’d like to use time with microformats and microdata. Not allowing more time formats (year, year-month, month-day…) restricts the use of time to vocabularies with year-month-day specific dates. If these primary use cases have changed please let me know. Hopefully some of these use cases will be relevant for allowing at least year and year-month formats for @datetime, as per ISO 8601. Thanks for your time peace - oli studholme
[whatwg] hgroup functionality absorbed into header?
Hi All, In talking with authors about HTML5 hgroup[1] I’ve found it seems confusing for many people, and I’ve also found it a little difficult to explain so it’s easy to understand (conversation = why? outline algorithm. huh?). Currently it’s only role is to hide subheadings from the outline algorithm and it doesn’t map to a common use pattern for adding semantic meaning. There doesn’t seem to be any tangible benefit to authors in using it. Superfriends suggested a Boolean attribute for header to determine if all child h1-h6 elements are included in the outline[2]. The current hgroup model excludes all subtitles from the outline. Assuming that subtitles should not be included in the outline (eg to make sure the highest-ranked title is indeed descriptive), what if header by default masked subtitles from the outline algorithm as hgroup currently does? This would mean hgroup is no longer necessary, and make header less optional (it currently feels like solely a CSS hook from an author perspective). Currently #the-header-element[3] mentions a “Little Green Guys With Guns” example in which h1-h6 elements in the header but outside hgroup create implied section elements via the outline algorithm. If header hides all but one h1-h6 element this won’t happen (this is also a potential issue with the Boolean attribute idea). While the spec states authors should add wrapping sections I suspect many won’t bother and rely on implied ones (unless they need CSS hooks). This would also be potentially confusing compared with footer, and possibly encourage authors to mistakenly add sections with headers inside of a header (copypaste mistakes etc). While this idea has drawbacks I feel hgroup’s lack of tangible author benefit and ‘occasional use’ nature will result in it not being widely used when it should be. I’d like to hear your opinion on both this idea and the Superfriends Boolean attribute idea (which I haven’t found discussed in the list). Thanks for your time peace - oli PS note section elements implied by the outline algorithm aren’t present in the DOM and so are not styled (thanks @vant) [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-hgroup-element [2] http://www.zeldman.com/superfriends/guide/#hgroup [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element
