Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke julian.resc...@gmx.de wrote: Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs. It seems much better to wait until it can actually be implemented. Especially since it's not at all clear to me that a specific opt-in mechanism is at all needed once we have the appropriate plugin APIs implemented. And those APIs are needed anyway if we want to allow plugins in any form in the sandbox. / Jonas
Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
On 2011-07-14 08:22, Jonas Sicking wrote: On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesterenann...@opera.com wrote: On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschkejulian.resc...@gmx.de wrote: Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs. It seems much better to wait until it can actually be implemented. Especially since it's not at all clear to me that a specific opt-in mechanism is at all needed once we have the appropriate plugin APIs implemented. And those APIs are needed anyway if we want to allow plugins in any form in the sandbox. When the attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled, links are prevented from targeting other browsing contexts, and plugins are disabled. A browser negotiating something with plugins using that API and enabling them despite @sandbox would violate the above requirement, no?
Re: [whatwg] PeerConnection, MediaStream, getUserMedia(), and other feedback
On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson i...@hixie.ch wrote: Another question is flash. As far as I have seen, there seems to be no option to specify whether the camera needs to use flash or not. Is this decision left up to the device? (If someone is making an app which is just clicking a picture of the person, then it would be nice to have the camera use flash in low light conditions). getUserMedia() returns a video stream, so it wouldn't use a flash. Wouldn't it make sense to have a provision for flash separately then? I think a lot of apps would like just a picture instead of video, and in those cases, flash would be required. Maybe a seperate provision in the spec which defines whether to use flash, and if so, for how many miliseconds. Is that doable? -- Shwetank Dixit Web Evangelist, Site Compatibility / Developer Relations / Core Engineering Group Member - W3C Mobile Web for Social Development (MW4D) Group Member - Web Standards Project (WaSP) - International Liaison Group Opera Software - www.opera.com Using Opera's revolutionary email client: http://www.opera.com/mail/
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] PeerConnection, MediaStream, getUserMedia(), and other feedback
I'd expect a web app to have no idea about device camera specifications and thus to not be able to properly specify a flash duration. I don't see how such a thing is valuable. If a user is in a movie theater, or a museum, it's quite likely they won't notice a web app is forcing a flash. Let the user control flash through a useragent only or host application only mode. I believe the hazards of exposing flash duration outweigh any benefits. The only application class I know of built using control of camera flash is flash-light, and that's both a hack and not guaranteed to be workable for all possible flash technologies. On 7/14/11, Shwetank Dixit shweta...@opera.com wrote: On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson i...@hixie.ch wrote: Another question is flash. As far as I have seen, there seems to be no option to specify whether the camera needs to use flash or not. Is this decision left up to the device? (If someone is making an app which is just clicking a picture of the person, then it would be nice to have the camera use flash in low light conditions). getUserMedia() returns a video stream, so it wouldn't use a flash. Wouldn't it make sense to have a provision for flash separately then? I think a lot of apps would like just a picture instead of video, and in those cases, flash would be required. Maybe a seperate provision in the spec which defines whether to use flash, and if so, for how many miliseconds. Is that doable? -- Shwetank Dixit Web Evangelist, Site Compatibility / Developer Relations / Core Engineering Group Member - W3C Mobile Web for Social Development (MW4D) Group Member - Web Standards Project (WaSP) - International Liaison Group Opera Software - www.opera.com Using Opera's revolutionary email client: http://www.opera.com/mail/ -- Sent from my mobile device
Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
On Thu, Jul 14, 2011 at 1:16 AM, Julian Reschke julian.resc...@gmx.de wrote: On 2011-07-14 08:22, Jonas Sicking wrote: On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesterenann...@opera.com wrote: On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschkejulian.resc...@gmx.de wrote: Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs. It seems much better to wait until it can actually be implemented. Especially since it's not at all clear to me that a specific opt-in mechanism is at all needed once we have the appropriate plugin APIs implemented. And those APIs are needed anyway if we want to allow plugins in any form in the sandbox. When the attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled, links are prevented from targeting other browsing contexts, and plugins are disabled. A browser negotiating something with plugins using that API and enabling them despite @sandbox would violate the above requirement, no? True. I would be fine with removing the plugin requirement. Or changing it such that it states that plugins can only be loaded if it's done in a manner that ensures that all other requirements are still fulfilled. Or just dealing with this once there actually are plugins and plugin APIs which could be loaded while still fulfilling the other requirements. / Jonas
Re: [whatwg] Proposal for a MediaSource API that allows sending media data to a HTMLMediaElement
On Wed, Jul 13, 2011 at 8:00 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Jul 14, 2011 at 4:35 AM, Aaron Colwell acolw...@google.comwrote: I am open to suggestions. My intent was that the browser would not attempt to cache any data passed into append(). It would just demux the buffers that are sent in. When a seek is requested, it flushes whatever it has and waits for more data from append(). If the web application wants to do caching it can use the WebStorage or File APIs. If the browser's media engine needs a certain amount of preroll data before it starts playback it can signal this explicitly through new attributes or just use HAVE_FUTURE_DATA HAVE_ENOUGH_DATA readyStates to signal when it has enough. OK, I sorta get the idea. I think you're defining a new interface to the media processing pipeline that integrates with the demuxer and codecs at a different level to regular media resource loading. (For example, all the browser's built-in logic for seeking and buffering would have to be disabled and/or bypassed.) Yes. As such, it would have to be carefully specified, potentially in a container- or codec-dependent way, unlike APIs like Blobs which work just like regular media resource loading and can thus work with any container/codec. My hope is that the data passed to append will basically look like the live streaming form of containers like Ogg WebM so this isn't totally foreign to the existing browser code. We'd probably have to spec the level of support for Ogg chaining and multiple WebM segments but I don't think that should be too bad. Seeking is where the trickiness happens and I was just planning on making it look like a new live stream whose starting timestamp indicates the actual point seeked to. I was tempted to create an API that just passed in compressed video/audio frames and made JavaScript do all of the demuxing, but I thought people might find that too radical. I'm not sure what the best way to do this is, to be honest. It comes down to the use-cases. If you want to experiment with different seeking strategies, can't you just do that in Chrome itself? If you want scriptable adaptive streaming (or even if you don't) then I think we want APIs for seamless transitioning along a sequence of media resources, or between resources loaded in parallel. I think the best course of action is for me to get my prototype in a state where others can play with it and I can demonstrate some of the uses that I'm trying to enable. I think that will make this a little more concrete. I'll keep this list posted on my progress. Thanks for your help, Aaron
[whatwg] a rel=attachment
Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the page author to have control over the response headers sent by the server.*(A related example is offline apps, which may wish to provide the user with a way to download a file stored locally using the filesystem API but again can't set any headers.) It would be nice to provide the page author with a client side mechanism to trigger a download. After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser should treat this link as if the response came with a content-disposition: attachment header, and offer to download/save the file for the user. -Ian
[whatwg] Microdata - Handling the case where a string is upgraded to an object
Some IRC discussion this morning concerned the scenario where an API starts by exposing a property as a string, but later wants to change it to be a complex object. This appears to be a reasonably common scenario. For example, a vocabulary with a name property may start with it being a string, and then later change to an object exposing firstname/lastname/etc properties. A vocabulary for a music library may start by having track as a string, then later expanding it to expose the track title, the individual artist, the running time, etc. In a very similar vein, the CSSOM is currently defined to always return property values as strings. We want to instead return complex objects that expose useful information and interfaces specialized on the value's type, however. For compat reasons, we have to use an entirely different accessor in order to expose this type of thing. It seems that this may be a useful problem to solve in Microdata. We can expose either an attribute or a privileged property name for the object's name/title/string representation. Then, when using the .items accessor, objects can be returned with a custom .toString that returns that value, so they can be used as strings in legacy code. Thoughts? ~TJ
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] a rel=attachment
On Thu, Jul 14, 2011 at 12:03 PM, Karl Dubost ka...@opera.com wrote: Le 14 juil. 2011 à 14:45, Ian Fette (イアンフェッティ) a écrit : Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Which current websites? Take gmail as one example off the top of my head. If any of these files are present as an attachment I get an option to view or download. it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser should treat this link as if the response came with a content-disposition: attachment header, and offer to download/save the file for the user. Are you then proposing to reverse the contextual click on the link to give the option, view in the browser. All browsers have currently implemented save this link as? It may please some users. As a user, I will place this in the category of super annoying features. It then means I would need a preference in the browser to disable it. Then it is at least 3 modifications to implement it. Not for all links, no, only links that have rel=attachment. And I would assume that on such a link, yes, perhaps a view inline right click option may make sense. I wouldn't expect this to be used on anywhere near a majority of links, but an author can already try to craft a download link -- it's just that in many cases it's either requiring them to jump through hoops or impossible (e.g. offline apps). -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [whatwg] a rel=attachment
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the page author to have control over the response headers sent by the server.*(A related example is offline apps, which may wish to provide the user with a way to download a file stored locally using the filesystem API but again can't set any headers.) It would be nice to provide the page author with a client side mechanism to trigger a download. After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser should treat this link as if the response came with a content-disposition: attachment header, and offer to download/save the file for the user. -Ian I should also point out that there was a similar proposal from Dennis Joachimsthaler last year. There was a fair amount of discussion on the thread back and forth; near the end Hixie's recommendation [1] was to propose this as a rel= attribute and push forward with implementation. That is essentially what we intend to do. [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028148.html -Ian
Re: [whatwg] a rel=attachment
Le 14 juil. 2011 à 14:45, Ian Fette (イアンフェッティ) a écrit : Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Which current websites? it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser should treat this link as if the response came with a content-disposition: attachment header, and offer to download/save the file for the user. Are you then proposing to reverse the contextual click on the link to give the option, view in the browser. All browsers have currently implemented save this link as? It may please some users. As a user, I will place this in the category of super annoying features. It then means I would need a preference in the browser to disable it. Then it is at least 3 modifications to implement it. -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [whatwg] a rel=attachment
2011/7/14 Andy Mabbett a...@pigsonthewing.org.uk 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com: Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the page author to have control over the response headers sent by the server.*(A related example is offline apps, which may wish to provide the user with a way to download a file stored locally using the filesystem API but again can't set any headers.) It would be nice to provide the page author with a client side mechanism to trigger a download. After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser should treat this link as if the response came with a content-disposition: attachment header, and offer to download/save the file for the user. How would this be different to the already-available rel=enclosure ? It seems quite similar, except that afaik no browser yet acts on enclosure. I don't want to get into bikeshedding discussions, both enclosure and attachment have precedent, I simply want to implement this :) -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
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] a rel=attachment
On 7/14/11, Ian Fette (イアンフェッティ) ife...@google.com wrote: Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the page author to have control over the response headers sent by the server.*(A related example is offline apps, which may wish to provide the user with a way to download a file stored locally using the filesystem API but again can't set any headers.) It would be nice to provide the page author with a client side mechanism to trigger a download. As already stated you can use rel=enclosure. Alternatively, you can specify the type attribute with the appropriate value and let the user agent offer to write it to permanent storage.
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] a rel=attachment
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the This has been raised a couple times: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread was derailed partway through) I've wanted this several times and I'm strongly in favor of it. After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser This isn't enough; the filename needs to be overridable as well, as it is with Content-Disposition. My recommendation has been: a href=image.jpg download a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg where the first is equivalent to Content-Disposition: attachment, and the second is equivalent to Content-Disposition: attachment; filename=picture.jpg. -- Glenn Maynard
[whatwg] proposal: extend time to markup durations
Some in the microformats community have been making good use of the time element, e.g. for publishing hCalendar, and implementing consuming/converting hCalendar [1] with good success. It would be great if the time element could support expressing durations as well for the use cases as needed by the hMedia and hAudio microformats as well as other use-cases (Wikipedia, IMDB). Simple proposal, examples, faq, discussion (please contribute) http://wiki.whatwg.org/wiki/Time_element#duration Thanks, Tantek [1] http://microformats.org/wiki/h2vx#HTML5_support -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] a rel=attachment
The download=filename seems like a nice proposal (assuming that the filename is optional, and if not specified it just takes whatever the name would otherwise be). It also neatly solves the filename issue without cluttering the a tag with tons of options. On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote: 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the This has been raised a couple times: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread was derailed partway through) I've wanted this several times and I'm strongly in favor of it. After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser This isn't enough; the filename needs to be overridable as well, as it is with Content-Disposition. My recommendation has been: a href=image.jpg download a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg where the first is equivalent to Content-Disposition: attachment, and the second is equivalent to Content-Disposition: attachment; filename=picture.jpg. -- Glenn Maynard
Re: [whatwg] a rel=attachment
On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote: 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the This has been raised a couple times: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread was derailed partway through) I've wanted this several times and I'm strongly in favor of it. Yes, it seems very useful. After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser This isn't enough; the filename needs to be overridable as well, as it is with Content-Disposition. My recommendation has been: a href=image.jpg download a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg where the first is equivalent to Content-Disposition: attachment, and the second is equivalent to Content-Disposition: attachment; filename=picture.jpg. This is an interesting variation! I like that it addresses the issue of providing a name for the download. Using the term download here is also nice. I know that there is also a proposal to add a FileSaver API. I like that as well, _but_ it is very nice to be able to simply decorate an anchor tag. In many cases, that will be a lot simpler for developers than using JavaScript to construct a FileSaver. I think it makes sense to implement both. On the other thread, Michal Zalewski raised a concern about giving client-side JS the power to name files. It looks like that discussion did not conclude, but I will note that even without the proposal here to name the download, an attacker could still have control over the downloaded filename. They could either manufacture a file using the FileSystem API, and then get a filesystem: URL to that file, or they could simply use a server to produce an URL with a C-D header of their choosing. It seems like we are well past the point of trying to limit a web page authors ability to influence the downloaded filename. Fortunately, however, user agents can protect the user from potentially harmful downloads. Chrome for instance asks the user to confirm the download of a EXE file before we ever write a file to the filesystem with a .exe extension. -Darin
Re: [whatwg] a rel=attachment
2011/7/14 Darin Fisher da...@chromium.org: On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote: 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the This has been raised a couple times: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread was derailed partway through) I've wanted this several times and I'm strongly in favor of it. Yes, it seems very useful. Indeed, and has been pointed out, already specified (since 2005) and implemented as well for HTML: http://microformats.org/wiki/rel-enclosure re-using the enclosure term from the Atom format (thus minimal bikeshedding) After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser This isn't enough; the filename needs to be overridable as well, as it is with Content-Disposition. My recommendation has been: a href=image.jpg download a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg where the first is equivalent to Content-Disposition: attachment, and the second is equivalent to Content-Disposition: attachment; filename=picture.jpg. This is an interesting variation! I like that it addresses the issue of providing a name for the download. Using the term download here is also nice. Agreed. I've captured the suggestion on a brainstorming page: http://microformats.org/wiki/rel-enclosure-brainstorming Feel free to contribute or iterate. Thanks, Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] a rel=attachment
On Thu, Jul 14, 2011 at 1:32 PM, Tantek Çelik tan...@cs.stanford.eduwrote: 2011/7/14 Darin Fisher da...@chromium.org: On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote: 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the This has been raised a couple times: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread was derailed partway through) I've wanted this several times and I'm strongly in favor of it. Yes, it seems very useful. Indeed, and has been pointed out, already specified (since 2005) and implemented as well for HTML: http://microformats.org/wiki/rel-enclosure re-using the enclosure term from the Atom format (thus minimal bikeshedding) After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser This isn't enough; the filename needs to be overridable as well, as it is with Content-Disposition. My recommendation has been: a href=image.jpg download a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg where the first is equivalent to Content-Disposition: attachment, and the second is equivalent to Content-Disposition: attachment; filename=picture.jpg. This is an interesting variation! I like that it addresses the issue of providing a name for the download. Using the term download here is also nice. Agreed. I've captured the suggestion on a brainstorming page: http://microformats.org/wiki/rel-enclosure-brainstorming Feel free to contribute or iterate. Thanks, Tantek Why do you feel it is important to specify rel=enclosure in addition to the download attribute? Thanks, -Darin
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] a rel=attachment
On Thu, Jul 14, 2011 at 13:46, Darin Fisher da...@chromium.org wrote: On Thu, Jul 14, 2011 at 1:32 PM, Tantek Çelik tan...@cs.stanford.edu wrote: 2011/7/14 Darin Fisher da...@chromium.org: On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote: 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the This has been raised a couple times: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread was derailed partway through) I've wanted this several times and I'm strongly in favor of it. Yes, it seems very useful. Indeed, and has been pointed out, already specified (since 2005) and implemented as well for HTML: http://microformats.org/wiki/rel-enclosure re-using the enclosure term from the Atom format (thus minimal bikeshedding) After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser This isn't enough; the filename needs to be overridable as well, as it is with Content-Disposition. My recommendation has been: a href=image.jpg download a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg where the first is equivalent to Content-Disposition: attachment, and the second is equivalent to Content-Disposition: attachment; filename=picture.jpg. This is an interesting variation! I like that it addresses the issue of providing a name for the download. Using the term download here is also nice. Agreed. I've captured the suggestion on a brainstorming page: http://microformats.org/wiki/rel-enclosure-brainstorming Feel free to contribute or iterate. Thanks, Tantek Why do you feel it is important to specify rel=enclosure in addition to the download attribute? Thanks, -Darin Other way around. rel=enclosure is sufficient for today's use cases because authors simply name the file accordingly on their server and then implementations simply use the last segment of the URL as the filename - presto 80/20 case solved (and solved 6 years ago with no modification needed to HTML for it to be valid). Having to specify a download attribute that reflects a filename different from the last segment of the URL is the minority case, but still sufficient to justify addition of the attribute. Also the empty download attribute doesn't work as it is supposed to be equivalent to download=download which would simply name the file download which is unlikely what author or user want. Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] a rel=attachment
2011/7/14 Darin Fisher da...@chromium.org I know that there is also a proposal to add a FileSaver API. I like that as well, _but_ it is very nice to be able to simply decorate an anchor tag. In many cases, that will be a lot simpler for developers than using JavaScript to construct a FileSaver. I think it makes sense to implement both. FileSaver is useful in its own right, but it's not a great fit for this. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031398.html That reminds me of something download=filename can't do: assign a filename while leaving it inline, so save as and other operations can have a specified filename. That would require two separate properties. One case I've come across is img, where I want to display an image, but provide a different filename for save-as. Separating the filename would allow this to be applied generically both links and inline resources: img src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg filename=picture.jpg. In that case, rel=enclosure would probably make sense. On the other thread, Michal Zalewski raised a concern about giving client-side JS the power to name files. That subthread just seemed to be asking whether browsers should implement Content-Disposition, which didn't seem relevant--they already have, for years. Separately, there was a security question raised about the ability to serve a file off of a third-party site with a different filename than was intended. For example, uploading a file which is both an executable trojan and a valid JPEG to an image hosting site, and linking to it externally, overriding its filename to .EXE. The question there isn't about being able to serve executables--you can always do that--but being able to serve executables that appear to be from the image hosting site. Arguably, it could 1: cause users to trust the file because it appears to be from a site they recognize, or 2: cause the site to be blamed for the trojan. I mention it so people don't have to scour the previous threads for it, but I think it's uncompelling. It just seems like something UI designers would need to take into consideration. (In my opinion, the trust and blame for saving a file to disk should be applied to the host *linking* the file, and not from the site hosting the file, which makes the above irrelevant.) -- Glenn Maynard
Re: [whatwg] a rel=attachment
On Thu, Jul 14, 2011 at 1:53 PM, Glenn Maynard gl...@zewt.org wrote: 2011/7/14 Darin Fisher da...@chromium.org I know that there is also a proposal to add a FileSaver API. I like that as well, _but_ it is very nice to be able to simply decorate an anchor tag. In many cases, that will be a lot simpler for developers than using JavaScript to construct a FileSaver. I think it makes sense to implement both. FileSaver is useful in its own right, but it's not a great fit for this. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031398.html That reminds me of something download=filename can't do: assign a filename while leaving it inline, so save as and other operations can have a specified filename. That would require two separate properties. One case I've come across is img, where I want to display an image, but provide a different filename for save-as. Separating the filename would allow this to be applied generically both links and inline resources: img src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg filename=picture.jpg. In that case, rel=enclosure would probably make sense. Yeah, that makes a lot of sense. I'm fine with using rel=enclosure too. On the other thread, Michal Zalewski raised a concern about giving client-side JS the power to name files. That subthread just seemed to be asking whether browsers should implement Content-Disposition, which didn't seem relevant--they already have, for years. Separately, there was a security question raised about the ability to serve a file off of a third-party site with a different filename than was intended. For example, uploading a file which is both an executable trojan and a valid JPEG to an image hosting site, and linking to it externally, overriding its filename to .EXE. The question there isn't about being able to serve executables--you can always do that--but being able to serve executables that appear to be from the image hosting site. Arguably, it could 1: cause users to trust the file because it appears to be from a site they recognize, or 2: cause the site to be blamed for the trojan. I mention it so people don't have to scour the previous threads for it, but I think it's uncompelling. It just seems like something UI designers would need to take into consideration. (In my opinion, the trust and blame for saving a file to disk should be applied to the host *linking* the file, and not from the site hosting the file, which makes the above irrelevant.) Agreed. I suspect that users will associate a download with whatever host they see in the location bar. -Darin
Re: [whatwg] a rel=attachment
On Thu, Jul 14, 2011 at 1:32 PM, Tantek Çelik tan...@cs.stanford.edu wrote: Indeed, and has been pointed out, already specified (since 2005) and implemented as well for HTML: http://microformats.org/wiki/rel-enclosure re-using the enclosure term from the Atom format (thus minimal bikeshedding) enclosure is a completely opaque name. I have no idea how it is meant to refer to download the linked resource instead of navigating to it. If I think about it in terms of Atom I can *kinda* imagine it, but it feels like a bad term there, and it would be an even worse term in HTML. A boolean @download attribute is much clearer and more direct. If you're using @download to name the file as well, then adding a @rel value is unneeded. ~TJ
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] a rel=attachment
Le 14 juil. 2011 à 14:45, Ian Fette (イアンフェッティ) a écrit : a rel=attachment href=blah.pdf would indicate that the browser should treat this link as if the response came with a content-disposition: attachment header, and offer to download/save the file for the user. A random thought just occured to me (maybe dumb) But is it a relation qualifier or in fact a target? In http://dev.w3.org/html5/spec/browsers.html#valid-browsing-context-name-or-keyword A valid browsing context name or keyword is any string that is either a valid browsing context name or that is an ASCII case-insensitive match for one of: _blank, _self, _parent, or _top. what about adding a href=foo.pdf target=_downloadSave a Tree, Eat a beaver/a -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [whatwg] a rel=attachment
On Thu, Jul 14, 2011 at 1:52 PM, Tantek Çelik tan...@cs.stanford.edu wrote:
Also the empty download attribute doesn't work as it is supposed to be
equivalent to download=download which would simply name the file
download which is unlikely what author or user want.
This is incorrect. If you omit an attribute's value it becomes the
empty string. See this testcase:
!DOCTYPE html
body foo
/body
script
alert(document.body.getAttribute('foo'));
/script
(In SGML languages, omitting an attribute's value was *actually*
omitting the attribute name, and the name was inferred from looking in
the DTD for what attribute had that as a possible enumerated value.
This is why XHTML1 requires boolean attributes to be written as
foo='foo'. XHTML5, though, prefers the form foo='', as that makes the
value identical to what it would be as an HTML boolean attribute.)
~TJ
Re: [whatwg] proposal: extend time to markup durations
On Thu, 14 Jul 2011, Tantek �~Gelik wrote: Some in the microformats community have been making good use of the time element, e.g. for publishing hCalendar, and implementing consuming/converting hCalendar [1] with good success. [1] http://microformats.org/wiki/h2vx#HTML5_support It would be great if the time element could support expressing durations as well for the use cases as needed by the hMedia and hAudio microformats as well as other use-cases (Wikipedia, IMDB). Simple proposal, examples, faq, discussion (please contribute) http://wiki.whatwg.org/wiki/Time_element#duration I haven't studied the above yet, but I just wanted to bring up a trial balloon for a possible alternative solution: drop time and replace it with a generic solution. There are several use cases for time: A. Easier styling of dates and times from CSS. B. A way to mark up the publication date/time for an article (e.g. for conversion to Atom). C. A way to mark up machine-readable times and dates for use in Microformats or microdata. Use cases A and B do not seem to have much traction. Use case C applies to more than just dates, and the lack of solution for stuff outside dates and times is being problematic to many communities. Proposal: we dump use cases A and B, and pivot time on use case C, changing it to data and making it like the abbr for machine-readable data, primarily for use by Microformats and HTML's microdata feature. (I've also filed this as a bug here: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 I generally prefer to only have issues discussed either in e-mail or in a bug, but Tantek informs me that for technical reasons he can't discuss this on the bug and his input is more important to me than convention, thus my bringing this up here again!) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] a rel=attachment
On Thu, Jul 14, 2011 at 1:53 PM, Glenn Maynard gl...@zewt.org wrote: That reminds me of something download=filename can't do: assign a filename while leaving it inline, so save as and other operations can have a specified filename. That would require two separate properties. One case I've come across is img, where I want to display an image, but provide a different filename for save-as. Separating the filename would allow this to be applied generically both links and inline resources: img src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg filename=picture.jpg. Optimizing for the user choosing to right-click=Save seems like a much more niche case than linking to a file that should be downloaded. Plus, you could address it by just wrapping the img in an a: a href=uglyurl.jpg download=prettyurl.jpgimg src=uglyurl.jpg/a Alternately, there's nothing saying that @download can't be useful on img directly. It would still be embedded normally, but @download would set the download filename the same way that it does on a. (It seems more obvious to me that the download filename is in @download than @filename - the latter seems likely to confused people into thinking that it's involved somehow in linking to the image, or that you're required to set the filename on all images). ~TJ
Re: [whatwg] proposal: extend time to markup durations
On Thu, Jul 14, 2011 at 2:36 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 14 Jul 2011, Tantek Ã~Gelik wrote: Some in the microformats community have been making good use of the time element, e.g. for publishing hCalendar, and implementing consuming/converting hCalendar [1] with good success. [1] http://microformats.org/wiki/h2vx#HTML5_support It would be great if the time element could support expressing durations as well for the use cases as needed by the hMedia and hAudio microformats as well as other use-cases (Wikipedia, IMDB). Simple proposal, examples, faq, discussion (please contribute) http://wiki.whatwg.org/wiki/Time_element#duration I haven't studied the above yet, but I just wanted to bring up a trial balloon for a possible alternative solution: drop time and replace it with a generic solution. There are several use cases for time: A. Easier styling of dates and times from CSS. B. A way to mark up the publication date/time for an article (e.g. for conversion to Atom). C. A way to mark up machine-readable times and dates for use in Microformats or microdata. Use cases A and B do not seem to have much traction. Use case C applies to more than just dates, and the lack of solution for stuff outside dates and times is being problematic to many communities. Proposal: we dump use cases A and B, and pivot time on use case C, changing it to data and making it like the abbr for machine-readable data, primarily for use by Microformats and HTML's microdata feature. I'm fine with this, but as I expressed when this was discussed earlier, I think this should be more explicitly aimed at Microdata, with something like itemdata @itemprop @data.../itemdata. This makes it less immediately applicable to Microformats, but in my opinion Microformats should switch to using Microdata as their embedding syntax, as that would solve their you have to write a custom parser for each vocab problem. (I want to address usecase A at some point, but it's a complicated problem that I don't have anywhere near the bandwidth for. It doesn't necessarily require time, though - itemdata would work just fine if CSS specified a particular date format that the data had to be in.) ~TJ
Re: [whatwg] a rel=attachment
On 7/14/11, Karl Dubost ka...@opera.com wrote: what about adding a href=foo.pdf target=_downloadSave a Tree, Eat a beaver/a This seems like the best solution to me. A filename hint has two use cases: a suggestion for a local identifier, and providing a filename extension for systems that use them to identify file types with incomplete or nonexistent /etc/mime.type media type mappings. I'll only name so many pictures pic.jpg, so I suggest using the descriptive (and thus verbose) value of the title attribute. The worst problem will be encoding the name on filesystems such as FAT. a href=//samplecdn.example/pix/2011/7/14/party/cake title=Súkkulaðikaka með ís target=_downloadAfmæliskaka mín/a
Re: [whatwg] Styling details
(This isn't the final reply on this thread, but I thought I should give a heads-up as to the general direction I am expecting us to go in here.) On Wed, 6 Apr 2011, Lachlan Hunt wrote: We've been experimenting with the styling of the details element, trying to figure out the most sensible way style it. We have tried to find a solution that behaves the way authors expect, provides for easy restyling by authors and avoiding the troubles associated with magic styles that can't be expressed in CSS. The rendering section of the spec is currently very inadequate and does not describe accurate styles. Also, the sample XBL binding given in the XBL 2.0 draft is also inadequate for a number of reasons. I think the long term solution here is some sort of widget definition binding language like XBL. I don't think it makes sense to do it purely in CSS. Discolsure widgets have all kinds of subtle behaviours like animation during disclosure, hover effects on the triangle, etc. Some systems use a More... or Details... button, some use a triangle, some use +/-. On the short term, I would recommend using the 'icon' property to allow authors to override the icon. I agree that what the spec says is currently inadequate, but without a binding language, I don't think it makes sense to spend time trying to improve it, since any improvement would be a stop-gap measure. The same applies to pretty much all the other form controls. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] a rel=attachment
On Thu, Jul 14, 2011 at 5:44 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: Optimizing for the user choosing to right-click=Save seems like a much more niche case than linking to a file that should be downloaded. Plus, you could address it by just wrapping the img in an a: a href=uglyurl.jpg download=prettyurl.jpgimg src=uglyurl.jpg/a I don't want to turn my images into links--and in some cases the images are already links to something else, or use click for other site UI. A similar and probably more common use case is links to files which can be viewed usefully in the browser, and are also often saved to disk; very frequently PDFs. Using a href=ugly.pdf download=pretty.pdf would obstruct users who want to view the link in the browser. I don't feel very strongly about this, and download=filename is clean and straightforward, but we should at least consider the use cases of specifying a filename without implying C-D: attachment. -- Glenn Maynard
Re: [whatwg] Styling details
On Thu, Jul 14, 2011 at 15:21, Ian Hickson i...@hixie.ch wrote: (This isn't the final reply on this thread, but I thought I should give a heads-up as to the general direction I am expecting us to go in here.) On Wed, 6 Apr 2011, Lachlan Hunt wrote: We've been experimenting with the styling of the details element, trying to figure out the most sensible way style it. We have tried to find a solution that behaves the way authors expect, provides for easy restyling by authors and avoiding the troubles associated with magic styles that can't be expressed in CSS. The rendering section of the spec is currently very inadequate and does not describe accurate styles. Also, the sample XBL binding given in the XBL 2.0 draft is also inadequate for a number of reasons. I think the long term solution here is some sort of widget definition binding language like XBL. I don't think it makes sense to do it purely in CSS. Discolsure widgets have all kinds of subtle behaviours like animation during disclosure, hover effects on the triangle, etc. Some systems use a More... or Details... button, some use a triangle, some use +/-. On the short term, I would recommend using the 'icon' property to allow authors to override the icon. Agreed. FYI: http://dev.w3.org/csswg/css3-ui/#icon Feel free to follow-up feedback on that to www-st...@w3.org. I agree that what the spec says is currently inadequate, but without a binding language, I don't think it makes sense to spend time trying to improve it, since any improvement would be a stop-gap measure. The same applies to pretty much all the other form controls. Also agreed. Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
