Re: PaceEnclosuresAndPix status
Just a point of data; most logos are designed to look good at a 1-to-1 aspect ratio. On Jan 24, 2005, at 5:25 PM, Tim Bray wrote: On Jan 24, 2005, at 5:18 PM, Joe Gregorio wrote: +1 Should there be a suggested size for images? A suggested aspect ratio, actually. Drat. Brent Simmons loved this idea, and I meant to update the draft. Would anyone be upset if I updated the draft to say an aspect ratio of 2 (horizontal) to 1 (vertical)? -Tim -- Mark Nottingham http://www.mnot.net/
Re: PaceEnclosuresAndPix status
On Thu, 27 Jan 2005 22:12:41 +1100, Eric Scheid [EMAIL PROTECTED] wrote: http://www.intertwingly.net/wiki/pie/PaceIconAndImage Nice. But if we have both atom:icon and atom:image for the feed, why do we need to do all kinds of wierd stuff to have images attached to Atom entries? Can't atom:image (perhaps not atom:icon) occur as a child of atom:entry too? This competes with parts of PaceEnclosuresAndPix, and so have also written PaceLinkEnclosure which simply strips out the Pix part. Right. So we include images of the feed with 'image', while images for entries with 'link'. That doesn't make sense. It also doesn't make much sense to have several elements to do the exact same thing. My head is screaming for atom:object here. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEnclosuresAndPix status
On 29/1/05 4:22 PM, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: http://www.intertwingly.net/wiki/pie/PaceIconAndImage Nice. But if we have both atom:icon and atom:image for the feed, why do we need to do all kinds of wierd stuff to have images attached to Atom entries? Can't atom:image (perhaps not atom:icon) occur as a child of atom:entry too? Maybe image is the wrong name for the concept. We're not talking about some random image associated with some entity, we're talking about a branding badge or logo of some kind which is representative of the feed. While entries may well have images of various kinds attached to them (cat pictures, anyone?), the individual entries don't get branded with their own logo/badge, do they? Hmmm... maybe I'll rename it to atom:logo ... would that help? e.
Re: PaceEnclosuresAndPix status
On Sat, 29 Jan 2005 16:47:09 +1100, Eric Scheid [EMAIL PROTECTED] wrote: Maybe image is the wrong name for the concept. We're not talking about some random image associated with some entity, we're talking about a branding badge or logo of some kind which is representative of the feed. I know what we're talking about and still don't understand why embedding so-called «favorite icons» is so wildely different from embedding other types of graphical objects in feeds (at all levels) that it has to be done in a wildely different way. We're trying to create a mechanism for embedding graphics, and in some cases the graphic has special meaning. Then let's of course assert that special meaning, but not by creating several completely different mechanisms for embedding graphics in Atom feeds! While entries may well have images of various kinds attached to them (cat pictures, anyone?), the individual entries don't get branded with their own logo/badge, do they? If they do, that's none of our (or at least my) business. If people want icons for their entries, let them have it. If aggregator writers want to add support for bookmarking individual entries (it makes sense, doesn't it?), it would be a lot easier to find these entries later on if they had some kind of icon attached to them. That icon could of course be the same as the feed's, but it could also be something completely different. The point is that if we have a general way of embedding graphical objects in Atom feeds, we don't need to differ between feed- and entry-level graphics. We only need to define some types of graphical objects that have special meaning so they can be treated specially by aggregators. One such graphical object is «icon». It is an embedded graphical object, but it's supposed to be shown in a special place in the aggregator. Hmmm... maybe I'll rename it to atom:logo ... would that help? If the renamed element can be used to embed all sorts of graphical objects in both feeds and entries; yes. :) -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEnclosuresAndPix status
On 27/1/05 7:26 PM, Henri Sivonen [EMAIL PROTECTED] 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: 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: PaceEnclosuresAndPix status
On Wednesday, January 26, 2005, at 10:40 PM, Eric Scheid wrote: so, icon ... or favicon. I prefer the latter. I prefer the former. favicon = favorites icon. I think favorites is a bad name for bookmarks--a person's reason for bookmarking something (or in the case of Atom, subscribing to a feed) may not have anything to do with how much they like it. And besides, the icon is displayed (in some browsers at least) when you're viewing the page, not just when it's bookmarked. I'd rather not propagate the use of the term. Let's just call it what we know it is--an icon.
Re: PaceEnclosuresAndPix status
* Ray Slakinski [EMAIL PROTECTED] [2005-01-25 10:40-0500] +1 from me, I'm happy to see this added! +1 likewise to http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix Dan On 24-Jan-05, at 7:18 PM, Tim Bray wrote: If there were no further discussion: Got no -1's, seems useful, needed for feature parity with RSS2, will likely go in absent some objections. -Tim
Re: PaceEnclosuresAndPix status
On Jan 26, 2005, at 5:03 PM, Graham wrote: On 26 Jan 2005, at 8:00 pm, Tim Bray wrote: Hearing no objections, I modified the Pace to say the image SHOULD have an aspect ratio of 2 (horizontal) to 1 (vertical). -Tim What's our story on favicons? Quite a few programs support them and most presumably do it by guessing the URI from the feed URI (or possibly downloading the home page and looking for the URI there). I think it's a hole in RSS that needs plugging by us. I agree with that. It's something many feed producers care about -- I get email just about every day asking how to make a favicon appear in my software. And I always wish I could say that there's a way to specify it in the feed. I would favor specifying that favicons should be 16 x 16, or at least that they should be square. -Brent
Re: PaceEnclosuresAndPix status
On Jan 26, 2005, at 5:54 PM, Brent Simmons wrote: I agree with that. It's something many feed producers care about -- I get email just about every day asking how to make a favicon appear in my software. And I always wish I could say that there's a way to specify it in the feed. I would favor specifying that favicons should be 16 x 16, or at least that they should be square. Uh, the way browsers do it is just like the way robots.txt works. They do a GET on /favicon.ico, hardwired path, and (at least some of them) just silently ignore it if it's not 16x16. This sucks (just like /robots.txt sucks) because if you have multiple sites on the same host you're hosed. This is *not* just an RSS/syndication problem, it's bigger, and I don't think we own it. -Tim
Re: PaceEnclosuresAndPix status
Tim Bray wrote: On Jan 26, 2005, at 5:54 PM, Brent Simmons wrote: I agree with that. It's something many feed producers care about -- I get email just about every day asking how to make a favicon appear in my software. And I always wish I could say that there's a way to specify it in the feed. I would favor specifying that favicons should be 16 x 16, or at least that they should be square. Uh, the way browsers do it is just like the way robots.txt works. They do a GET on /favicon.ico, hardwired path, and (at least some of them) just silently ignore it if it's not 16x16. This sucks (just like /robots.txt sucks) because if you have multiple sites on the same host you're hosed. This is *not* just an RSS/syndication problem, it's bigger, and I don't think we own it. -Tim Take a look at: http://lists.w3.org/Archives/Public/www-html/2003Jun/0132.html For quite some time, my XHTML has contained the following: link rel=shortcut icon href=/favicon.ico/ Question: would it be of value to people like Graham and Brent if we were to register this rel value for Atom feeds? - Sam Ruby
Re: PaceEnclosuresAndPix status
On Jan 26, 2005, at 7:25 PM, Sam Ruby wrote: Tim Bray wrote: On Jan 26, 2005, at 5:54 PM, Brent Simmons wrote: I agree with that. It's something many feed producers care about -- I get email just about every day asking how to make a favicon appear in my software. And I always wish I could say that there's a way to specify it in the feed. I would favor specifying that favicons should be 16 x 16, or at least that they should be square. Uh, the way browsers do it is just like the way robots.txt works. They do a GET on /favicon.ico, hardwired path, and (at least some of them) just silently ignore it if it's not 16x16. This sucks (just like /robots.txt sucks) because if you have multiple sites on the same host you're hosed. This is *not* just an RSS/syndication problem, it's bigger, and I don't think we own it. -Tim Take a look at: http://lists.w3.org/Archives/Public/www-html/2003Jun/0132.html For quite some time, my XHTML has contained the following: link rel=shortcut icon href=/favicon.ico/ Question: would it be of value to people like Graham and Brent if we were to register this rel value for Atom feeds? - Sam Ruby Yes, this would work for me. -Brent
Re: PaceEnclosuresAndPix status
On Jan 26, 2005, at 7:25 PM, Sam Ruby wrote: http://lists.w3.org/Archives/Public/www-html/2003Jun/0132.html For quite some time, my XHTML has contained the following: link rel=shortcut icon href=/favicon.ico/ Question: would it be of value to people like Graham and Brent if we were to register this rel value for Atom feeds? Heh, didn't know that. Much better than hardwiring /favicon.ico. So someone write a Pace already, it only needs 3 lines. -Tim
Re: PaceEnclosuresAndPix status
On 27/1/05 3:38 PM, Sam Ruby [EMAIL PROTECTED] wrote: atom:@rel doesn't allow for multiple space delimited values. e. http://lists.w3.org/Archives/Public/www-html/2003Jun/0133.html agreed, a single term @rel value is preferred. the shortcut icon thing is borked ... the linked favicon is used for more than just an icon for the shortcuts/bookmarks list in browsers, f'rinstance, and the resource so linked is not a shortcut to the linking resource, whatever that means (an html page with links to popular posts might be). so, icon ... or favicon. I prefer the latter. e.
Re: PaceEnclosuresAndPix status
Tim Bray wrote: Would anyone be upset if I updated the draft to say an aspect ratio of 2 (horizontal) to 1 (vertical)? -Tim Not me. +1 cheers Bill
Re: PaceEnclosuresAndPix status
A suggestion on drafting of the pace: cardinality should be stated. The idea of multiple parallel elements formatted per PaceEnclosuresAndPix was discussed with interest, and the cardinality of RSS 2.0 enclosure elements has been written up and discussed quite a lot, so the cardinality of PaceEnclosuresAndPix should be explicit. - Lucas Gonze
Re: PaceEnclosuresAndPix status
+1 Should there be a suggested size for images? -joe On Mon, 24 Jan 2005 16:18:00 -0800, Tim Bray [EMAIL PROTECTED] wrote: If there were no further discussion: Got no -1's, seems useful, needed for feature parity with RSS2, will likely go in absent some objections. -Tim -- Joe Gregoriohttp://bitworking.org
Re: PaceEnclosuresAndPix status
On Jan 24, 2005, at 5:18 PM, Joe Gregorio wrote: +1 Should there be a suggested size for images? A suggested aspect ratio, actually. Drat. Brent Simmons loved this idea, and I meant to update the draft. Would anyone be upset if I updated the draft to say an aspect ratio of 2 (horizontal) to 1 (vertical)? -Tim
Re: PaceEnclosuresAndPix status
On Monday, January 24, 2005, at 05:18 PM, Tim Bray wrote: If there were no further discussion: Got no -1's, seems useful, needed for feature parity with RSS2, will likely go in absent some objections. -Tim -0.7. Turns link into a kitchen sink by using it to point to things that are intended to be pre-fetched and presented along with the content (image, at least, though perhaps not enclosure). But given that we've failed to achieve consensus on any language to limit the range of uses of link, perhaps that argument is dead.
