PaceIconAndImage
+1 if image is changed to logo or, even better, if image is allowed in entry. I don't care whether icon is allowed in entry, though I see no reason not to allow it.
Re: PaceIconAndImage
-1. image 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. icon is silly. link rel=icon 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 image is changed to logo or, even better, if image is allowed in entry. I don't care whether icon is allowed in entry, though I see no reason not to allow it.
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
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
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 image to logo 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 image to logo 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: 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 link rel=self feels quite sensible, while link rel=icon feels stupid. 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 link into their own elements, it changed the cardinality, allowing more than one atom:image in atom:head. 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 image instead of link. 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 atom:image 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 cutpaste 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: 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
Revised PaceIconAndImage, added PaceMultipleImages
Having produced my own Atom feed has made me a supporter of this Pace; without getting too deep into it link rel=self feels quite sensible, while link rel=icon feels stupid. 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 link into their own elements, it changed the cardinality, allowing more than one atom:image in atom:head. 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 image instead of link. 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 atom:image 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 cutpaste 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: 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 link rel=self feels quite sensible, while link rel=icon feels stupid. +1 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 link into their own elements, it changed the cardinality, allowing more than one atom:image in atom:head. 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 image instead of link. 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 atom:image 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 cutpaste 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.
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: icon src='...' or icon href='...' 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
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 link. Maybe we should rename the image element to logo? 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 image 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 icon 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.
