PaceIconAndImage
On Thursday, January 27, 2005, at 01:26 AM, Henri Sivonen wrote: I'd prefer an element, because the nature of the favicon reference is not that a user would want to manually follow the link. That is: or While I agree with this sentiment, the working group has rejected attempts to add language to the spec to limit the use of , so I assume we do not have consensus on the desire to limit it's usage. So that's not necessarily a very strong argument for creating new elements (not that there aren't other arguments for it). Of the two options you listed, I'd prefer @src to @href...for reasons related to my agreement with the sentiment about the use of here. "src" is much more description of how the attribute's value is going to be used. Which brings me to PaceIconAndImage--the pace itself makes forbids putting one of the attributes of Link Constructs in the elements (@rel). Another of them (@href) is not accurately descriptive of what it would be used for. Another of them (@title) doesn't seem very useful for icon (unless for accessibility--do people more involved in accessibility issues think that's needed--that it's going to be used to say anything more than "xyz.com's icon"?) Is it really appropriate to call this a Link Construct? Also, why limit this to feed/head, and not entry? So that Atom feeds will be easily convertible to RSS 2.0? Certainly there are ways to add images to entries in RSS 2.0, though not icons (as far as I'm aware), but I don't think that's a big deal. Because link/@rel="enclosure|attachment" can be used for images at the entry level? Then why not do the same at the feed level? Because we don't have prior art for needing it at the entry level? True for icons, less true for images, but still probably the strongest argument. But I would still argue for allowing them in entries.
PaceIconAndImage
+1 if is changed to or, even better, if is allowed in . I don't care whether is allowed in entry, though I see no reason not to allow it.
RE: PaceIconAndImage
Antone Roundy wrote: > Also, why limit this to feed/head, and not entry? So that Atom > feeds will be easily convertible to RSS 2.0? Converting *to* RSS 2.0 shouldn't be a goal or even a consideration in any Atom related discussions. Only conversion *from* RSS 2.0 is interesting. If Atom is guaranteed to be convertible both to and from RSS 2.0 then Atom can never be more than RSS 2.0 and a great deal of the effort and goodwill that has gone into Atom would be a complete waste of time. bob wyman
Re: PaceIconAndImage
On 28/1/05 4:03 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote: >> Also, why limit this to feed/head, and not entry? So that Atom >> feeds will be easily convertible to RSS 2.0? > > Converting *to* RSS 2.0 shouldn't be a goal or even a consideration > in any Atom related discussions. Only conversion *from* RSS 2.0 is > interesting. > > If Atom is guaranteed to be convertible both to and from RSS 2.0 > then Atom can never be more than RSS 2.0 and a great deal of the effort and > goodwill that has gone into Atom would be a complete waste of time. but we shouldn't get spiteful about it. If it doesn't matter either way on some point, why not allow compatibility? I'm saying it should be a consideration and possibly even an assumption, but remembering that if there is a good reason to go another route (and break compatibility) then that trumps the case. Lets not be incompatible for incompatibilities sake.! e.
Re: PaceIconAndImage
On 28/1/05 3:08 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote: > Also, why limit this to feed/head, and not entry? So that Atom feeds > will be easily convertible to RSS 2.0? Certainly there are ways to add > images to entries in RSS 2.0, though not icons (as far as I'm aware), > but I don't think that's a big deal. RSS compatibility is one reason, as described in the rationale. Another is that we're not talking a generic image here, we're talking about some kind of special "badge" or branding image, which doesn't make sense for entries. You can still add whatever images (and other resources) you want to an entry with . Maybe we should rename the element to ? > Which brings me to PaceIconAndImage--the pace itself makes forbids > putting one of the attributes of Link Constructs in the elements > (@rel). Another of them (@href) is not accurately descriptive of what > it would be used for. Another of them (@title) doesn't seem very > useful for icon (unless for accessibility--do people more involved in > accessibility issues think that's needed--that it's going to be used to > say anything more than "xyz.com's icon"?) Is it really appropriate to > call this a Link Construct? I used a Link construct to keep word count down. Otherwise we'd need to define an extra four attributes which have exactly the same names as those in Link Constructs, which seemed like unnecessary wordage. It would really bloat the spec. Saying instead that it's a Link construct where one attribute is meaningless is much easier to not only write, but also to read. @rel - yeah, I wrestled with that myself too, but then remember that other elements place additional constraints on Link constructs elsewhere (eg. 4.2.2). Also, @rel is a MAY, so it's not like it's totally breaking the template. @href - what ever do you mean here? @title in certainly might be used for @alt text, the same way it is specced in RSS 2.0. That's why I left @title in. @title in could be used for @alt text if the icon is displayed someplace, or more likely simply ignored. The street will find a use for it, or not. e.
Re: PaceIconAndImage
On 28/1/05 10:02 AM, "Eric Scheid" <[EMAIL PROTECTED]> wrote: > I used a Link construct to keep word count down and now with -05 published there is no generic Link Construct. I'll update the pace with all the necessary extra wordage and bloat. e.
Re: PaceIconAndImage
On Thu, 27 Jan 2005 09:08:34 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote: While I agree with this sentiment, the working group has rejected attempts to add language to the spec to limit the use of , so I assume we do not have consensus on the desire to limit it's usage. So that's not necessarily a very strong argument for creating new elements (not that there aren't other arguments for it). But using atom:link for images requires us also to add several new attribtues to it, which tells me that we are overloading atom:link to such an extent that we should look for another element. Let people link all they want to images, but if they want their images to actually appear in blog software, they need to use the appropriate element (which shouldn't be atom:link). Of the two options you listed, I'd prefer @src to @href...for reasons related to my agreement with the sentiment about the use of here. "src" is much more description of how the attribute's value is going to be used. I agree with this, but still feel atom:link is a wrong element to stuff this into. atom:object or atom:embed would be much better, imo. Or maybe even xhtml:object. Also, why limit this to feed/head, and not entry? So that Atom feeds will be easily convertible to RSS 2.0? Certainly there are ways to add images to entries in RSS 2.0, though not icons (as far as I'm aware), but I don't think that's a big deal. Indeed. Images should be embeddable outside the atom:content, imo. Icons aren't that important, but if we create a general way of embedding graphical objects in Atom feeds (at both atom:feed and atom:entry level), people can use it for icons, images, movies and whatever they'd like. Heck, if people want a 3 minute move in 32 x 32 pixels as their feed icon, and feed consumer software adds support for this, why should we stand in the way? Because link/@rel="enclosure|attachment" can be used for images at the entry level? Then why not do the same at the feed level? Because we don't have prior art for needing it at the entry level? True for icons, less true for images, but still probably the strongest argument. But I would still argue for allowing them in entries. I would argue that we need a general graphical embed-mechanism that should be shared between entries and feeds. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceIconAndImage
On Thursday, January 27, 2005, at 09:08 AM, Antone Roundy wrote: Also, why limit this to feed/head, and not entry? If we ARE going to limit images to feeds, then please, let's change the name to "logo". If it were "logo", I'd agree it doesn't belong in entry.
Re: PaceIconAndImage
On Friday, February 4, 2005, at 09:16 AM, Antone Roundy wrote: On Thursday, January 27, 2005, at 09:08 AM, Antone Roundy wrote: Also, why limit this to feed/head, and not entry? If we ARE going to limit images to feeds, then please, let's change the name to "logo". If it were "logo", I'd agree it doesn't belong in entry. Let me restate this in a way that might lead to action: I have a sneaking suspicion that we're not going to get consensus on allowing image and/or icon in entry. If that's the case, would anyone object to me changing to in the Pace?
Re: PaceIconAndImage
Antone Roundy wrote: Let me restate this in a way that might lead to action: I have a sneaking suspicion that we're not going to get consensus on allowing image and/or icon in entry. If that's the case, would anyone object to me changing to in the Pace? That would be bogus a rule. How does it hurt interop to put an image in an entry? Robert Sayre
Re: PaceIconAndImage
On Friday, February 4, 2005, at 12:37 PM, Robert Sayre wrote: Antone Roundy wrote: Let me restate this in a way that might lead to action: I have a sneaking suspicion that we're not going to get consensus on allowing image and/or icon in entry. If that's the case, would anyone object to me changing to in the Pace? That would be bogus a rule. How does it hurt interop to put an image in an entry? Just to be sure this is clear, I am not advocating that limitation--it is imposed by the Pace, and I seem to recall hearing opinions on both sides about whether entries should have images and/or icons. I'd be happy to allow both, though I doubt icons would get used much in entries. I just want to be sure that if we DON'T allow images in entries, we use a name for the element that makes sense to me to limit to the feed level.
Re: PaceIconAndImage
+1 on PaceIconAndImage Rationale: I don't like rel. rel hoists the URL data type on the element pedestal and puts the role in an attribute. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceIconAndImage
-1. should be exactly as it is in RSS, except with the recommendation that it should be 1:1, instead of size recomendations. There's also no reason to limit it to atom:head. is silly. should usher in the brave new world of HTML relations leaking into the Atom space. Alright. Robert Sayre
Re: PaceIconAndImage
+1, agree with renaming image to logo. Disagree with allowing either in entry, since their are already one million ways to do that (HTML, [EMAIL PROTECTED], etc). Graham On 7 Feb 2005, at 7:08 pm, Antone Roundy wrote: +1 if is changed to or, even better, if is allowed in . I don't care whether is allowed in entry, though I see no reason not to allow it.
PaceIconAndImage, and PaceLinkEnclosure
resending with more appropriate subject line, just in case these two new paces got lost in the thread... > I'd prefer an element, because the nature of the favicon reference is > not that a user would want to manually follow the link. That is: > > or I've drafted a Pace for this... http://www.intertwingly.net/wiki/pie/PaceIconAndImage This competes with parts of PaceEnclosuresAndPix, and so have also written PaceLinkEnclosure which simply strips out the Pix part. http://www.intertwingly.net/wiki/pie/PaceLinkEnclosure e.
Re: PaceIconAndImage, PaceMultipleImages
> PaceIconAndImage +1 +1 to renaming atom:image to atom:logo > PaceMultipleImages -1 : multiple language variants of anything seems to be well-kyboshed anywhere in atom
Revised PaceIconAndImage, added PaceMultipleImages
Having produced my own Atom feed has made me a supporter of this Pace; without getting too deep into it However, this Pace needed work; first of all, it was based on link constructs, which no longer exist. So I revised it. Second, along with turning Icon and Image from into their own elements, it changed the cardinality, allowing more than one in . I think this is probably a bad idea, but I'm 100% sure that it's wrong to mix up this with the (entirely separate) debate on whether to use instead of . So, I ripped it out of PaceIconAndImage and created a new PaceMultipleImages to suggest this. Third, along with these other changes, the Pace changed the aspect ratio from 2:1 to 1:1. Once again, this may be a good idea, but it needs discussion. But I kind of think this may have been a cut&paste typo, so I ripped it out but didn't create a new Pace, if someone really wants to change the Aspect ratio they should create a Pace. Having said all that, I'm +1 on PaceIconAndImage. I'm -1 on PaceMultipleImages, this is an experimental feature, Atom, doesn't need those, YAGNI. -Tim
PaceIconAndImage - icon aspect ratio
The "atom:icon" element's content is a URI which identifies an image which provides iconic visual identification for a feed. The image SHOULD have an aspect ratio of one (horizontal) to one (vertical), and should be suitable for presentation in small size. Is there any reason why the aspect ratio shouldn't be a MUST? Aren't icons (on computers, anyway) pretty much universally 1:1?
Re: Revised PaceIconAndImage, added PaceMultipleImages
On 2/2/05 5:49 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > Having produced my own Atom feed has made me a supporter of this Pace; > without getting too deep into it while However, this Pace needed work; first of all, it was based on link > constructs, which no longer exist. So I revised it. I based it on Link Constructs because I was (a) trying to avoid spec bloat, and (b) being lazy. The Link Construct did provide for more than just a URI though -- there's @type, a title attribute (which could be used for the @alt), and (pushing it) @hreflang for those atom:image with text rendered. I'm happy to lose @hreflang, a user agent could use /feed/head/tagline instead of @title, and @type really isn't necessary because the set of image formats is pretty stable. So, +1. (with minor revisions ... change the section numbers to suit -05, and added cardinality to section "4.2 the atom:head element", otherwise the spec wouldn't say just where those elements could be used) > Second, along with turning Icon and Image from into their own > elements, it changed the cardinality, allowing more than one > in . I think this is probably a bad idea, but > I'm 100% sure that it's wrong to mix up this with the (entirely > separate) debate on whether to use instead of . So, I > ripped it out of PaceIconAndImage and created a new PaceMultipleImages > to suggest this. +1. I wish more paces were decoupled. (makes note to self) > Third, along with these other changes, the Pace changed the > aspect ratio from 2:1 to 1:1. That must have been a copy/pasto. I know I set the atom:icon aspect ratio to 1:1, and thought I kept the 2:1 aspect ratio for atom:image. > Once again, this may be a > good idea, but it needs discussion. But I kind of think this may have > been a cut&paste typo, so I ripped it out but didn't create a new Pace, > if someone really wants to change the Aspect ratio they should create a > Pace. Yep, copy/pasto ... no, wait ... it actually said: >> === 4.2.y atom:image Element === >> >> The "atom:icon" element is a Link construct that conveys a URI to an >> image resource which provides visual identification for a feed. The >> image SHOULD have an aspect ratio of 2 (horizontal) to 1 (vertical). 2:1, but I did have a copy/pasto brainfart with the name of the element in the prose of the section. > Having said all that, I'm +1 on PaceIconAndImage. +1 > I'm -1 on PaceMultipleImages, this is an experimental feature, Atom, > doesn't need those, YAGNI. fair enough - there's been enough flack over multiple content. e.
Re: Revised PaceIconAndImage, added PaceMultipleImages
On Wednesday, February 2, 2005, at 12:33 AM, Eric Scheid wrote: On 2/2/05 5:49 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: Having produced my own Atom feed has made me a supporter of this Pace; without getting too deep into it while +1 +1 ... and @type really isn't necessary because the set of image formats is pretty stable. So, +1. Yeah, if you want a hint at the image type, check the filename--it won't always end in a recognized ".gif", ".jpeg", ".png", etc., but should often enough. ...it changed the cardinality, allowing more than one in . I think this is probably a bad idea, but Agreed. At the feed level, one image is plenty. If entries get images (see below), then multiple images could be useful in some limited cases, but it would probably be a really slim edge case. If someone wants multiple images in an entry, they can use (X)HTML . With multiple images, it's likely the publisher will want that level of control over their presentation anyway. Having said all that, I'm +1 on PaceIconAndImage. +1 +1 Three questions (and my opinions--and reasoning (principled reasoning?)): 1) Should entries be able to have images? (Yes. Entries COULD include images using (X)HTML's elements, but atom:image would give consuming applications much greater flexibility in how they arrange their display. If publishers want an image displayed in a particular manner, they can use (X)HTML's element. I would think this would be a great way to publish images from camera phones, for example--snap off an image; add a little text; post it. Then why isn't everyone doing it that way using RSS 1.0's or RSS 2's ? ...uh, because they haven't had that "Aha!" moment yet!?) 1a) Should we recommend an aspect ratio for entry images? (No. That would be an unnatural constraint. People are going to be posting source images of all shapes, and (almost) forcing the images into one shape woudl be too heavy handed.) 2) Should entries be able to have icons? (Hmm...I'm torn. I can imagine it being put to good use, but I doubt it would be widely used. I'd be happy either way.) 3) Should images have a @title or @alt or some such thing? (If entries get images, then yes--cramming that in summary or some such place feels sloppy. If only feeds have images, then it's not so important.)
Re: Revised PaceIconAndImage, added PaceMultipleImages
I am +1 on having images, or what I call entry illustrations. BlogEd has those, and they work nicely. See <http://today.java.net/jag/> or <http://bblfish.net/blog> for blogs that use them. Notice that the top entry (the Feed itself) has an illustration too. Which is another hint that a Feed is a subclass of an Entry. Of course if they did not make it into the spec it would be easy to add them as extensions. So the effort in speccing this would not be wasted. You may want to consider that an icon of an image is also related somehow to the original. In the feeds mentioned above, clicking on the icon brings you to a the original image the icon is a representation of. In one case [1] it occurred to me that have been more intuitive to have clicking on the image bring up a video. Henry Story [1] http://www.bblfish.net/blog/page3.html#25 On 2 Feb 2005, at 07:49, Tim Bray wrote: Having produced my own Atom feed has made me a supporter of this Pace; without getting too deep into it However, this Pace needed work; first of all, it was based on link constructs, which no longer exist. So I revised it. Second, along with turning Icon and Image from into their own elements, it changed the cardinality, allowing more than one in . I think this is probably a bad idea, but I'm 100% sure that it's wrong to mix up this with the (entirely separate) debate on whether to use instead of . So, I ripped it out of PaceIconAndImage and created a new PaceMultipleImages to suggest this. Third, along with these other changes, the Pace changed the aspect ratio from 2:1 to 1:1. Once again, this may be a good idea, but it needs discussion. But I kind of think this may have been a cut&paste typo, so I ripped it out but didn't create a new Pace, if someone really wants to change the Aspect ratio they should create a Pace. Having said all that, I'm +1 on PaceIconAndImage. I'm -1 on PaceMultipleImages, this is an experimental feature, Atom, doesn't need those, YAGNI. -Tim
Re: PaceIconAndImage - icon aspect ratio
Antone Roundy wrote: The "atom:icon" element's content is a URI which identifies an image which provides iconic visual identification for a feed. The image SHOULD have an aspect ratio of one (horizontal) to one (vertical), and should be suitable for presentation in small size. Is there any reason why the aspect ratio shouldn't be a MUST? Aren't icons (on computers, anyway) pretty much universally 1:1? LiveJournal images are square. Robert Sayre
