[uf-discuss] hAtom handheld CSS..?
chris.messina at gmail.com
Mon Mar 27 16:46:24 PST 2006
Another example of using hAtom could come from the devices
themselves... Imagine using a service proxy between the website you
want and your handheld:
originating website --> proxy --> handheld
While you could use RSS for this, hell, why not use the website you
want? Then you're not scuffling with feed URLs or managing an
aggregator... you're just going to a website (factoryjoe.com/blog).
The beautiful thing would be that the proxy would strip out the hAtom
object and present them, Gmail like, as posts -- viewable by title,
summary or complete. That way, those long long entries or blog
homepages won't take a million years to load because you've got a
transformation engine sitting between you and the destination grabbing
only the stuff that's of high value to you.
That to me seems like the ideal use case: partial loading of web
content based on semantic delimiters.
Now *there's* a business for ya.
On 3/27/06, David Janes -- BlogMatrix <davidjanes at blogmatrix.com> wrote:
> This is an interesting idea. Here are the key elements to Russell
> Beattie's proposal (I think) as it relates to hAtom:
> > I have to say I'm getting more and more convinced that this is the
> > direction that the mobile web is going to go. No recoding markup, no
> > "separate and always unequal" access to content, etc. Just include a
> > different style sheet on your server and you can re-arrange your
> > web-standard markup as you see fit.
> So what's being said is _make your websites so they can be restyled
> using CSS to make a mobile friendly presentation_. And...
> > But it's still the same underlying markup. And this works for the
> > whole portal like this, so for example if you sign up for a blog, you
> > also get a mobile readable/usable blog as well. That's pretty awesome.
> So they're producing weblogs also. The two points uses for for hAtom are
> hAtom provides a regular and consistent way to mark up your weblog
> content, not just for semantic reasons but also for presentation ones.
> Since they're proposing that web pages should be produced in a way that
> allows CSS restyling -- a non-trivial task -- having a standard way to
> mark up well known content means it will be easier for web designers to
> produce these stylesheets.
> So since web designers often work on blog presentation, having hAtom as
> the way to mark up weblog content to do all this is the way to go. A
> win/win for everyone.
> Note that we're not proposing a panacea here, just a partial solution to
> one frequently faced problem.
> They're producing blogs, so they should use hAtom anyway!
> Regards, etc...
> Chris Messina wrote:
> > Perhaps Danny can shed some light on his proposal?
> > On 3/27/06, Chris Casciano <chris at placenamehere.com> wrote:
> >> On Mar 27, 2006, at 3:39 PM, Chris Messina wrote:
> >>> On 3/27/06, Chris Casciano <chris at placenamehere.com> wrote:
> >>>> I guess I'm not clear where microformats (including hAtom or not)
> >>>> would
> >>>> serve to solve the handheld 'problem'.
> >>> I'm not clear either, except that, like CSS Zen Garden, having one set
> >>> of CSS classes to design for means that I could concoct one stylesheet
> >>> that could be used as the handheld stylesheet for thousands of blogs
> >>> instead of just one blog that chooses its own CSS classes.
> >>> In that way, we could actually iterate on design knowing that there's
> >>> some consistency in CSS classes.
> >>> Chris
> >> But what about everything else on the page -- from navigation to
> >> branding to any non-atom-like content? Or pages with multiple hatom
> >> feeds? Or the wide variety of "stuff" that could be entry content --
> >> from images, photos or screenshots to lengthy articles -- that would
> >> presumably go un-specified in an hatom-garden type setting.
> >> I guess I don't see how the others participating think the pages would
> >> be consumed, and the win I see from hAtom (the ability to subscribe to
> >> elements on any page of a site without shipping mulutple versions of a
> >> document) isn't at all related to the handheld space.
> microformats-discuss mailing list
> microformats-discuss at microformats.org
More information about the microformats-discuss