RE: [uf-discuss] Proposal: wine
Hi all. 2c from an infrequent poster... It seems pretty clear to me that certain products have lots and lots of content written about them (book reviews, movie reviews, and wine reviews) whereas others do not (schnapps, for example). For those areas where intense reviewing happens, there is always industry specific information that would be good to standardize. For example, movies always have a director. Wine (almost) always has a vintage. To me, it seems useful to have a format dedicated to the description of wine, since there is so much wine information out there in the world. In the glorious future, it would be great to be able to use this information in a consistent way. One caveat is that the microformats list may not a great place to find a ton of people to discuss the pros and cons of how to structure this information. The kinds of discussions you want to have are really specific to the world of wine (e.g., how do you characterize "Meritage"?) -Sho -- Sho Kuwamoto Adobe Flex Builder www.adobe.com > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Steve Marshall > Sent: Thursday, November 16, 2006 1:33 AM > To: Microformats Discuss > Subject: Re: [uf-discuss] Proposal: wine > > Correct me if I'm wrong, but isn't everything you both mentioned > covered by the much more generic proposal for hListing [1]? > > If we were to go down the route of a wine µF, the next step would be > beer, but then the real-ale types would want a real-ale one, and the > lager people would want a lager one, and then there's vodka, > whisk(e)y, schnapps, and I'm not even out of the alcomahols yet. > > We'd then have eleventy-billion different µFs, one for each and every > possible type of product one person in the world is interested in, and > then everything on the intertubes would be marked up differently and > we may as well have just switched to XML and killed off all hopes for > a common base for a semantic web here and now. > > [1]: http://microformats.org/wiki/hlisting-proposal > -- > http://nascentguruism.com > > ___ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] More responses to slashdot comments
Michael Leikam wrote: > s and s are not structurally equivalent. span > and div tags are general structural markup, while heading > tags are specifically defined in relation to other heading > tags. Collectively they define an outline for the page, > while the set of spans on a page defines nothing. Exactly my point. There are two competing schema living in the same document: the world of HTML (semantically poor and unextensible), and the world of microformats. While this works out OK usually, I believe there are cases where the two worlds combine in uncomfortable ways. BTW, I don't know if saying that spans "define nothing" in the HTML world fits with my view of the things. To me, spans and divs in HTML are an escape mechanism that allows me to add my own meaning above and beyond what HTML provides. For example, I might have an "appendix" section, which I think of as "containing" other elements, such as h3, etc. > > This is essentially the same issue that people have with > > hacks like > > adding into a document, which is > > clearly presentational. > > That may be an unfortunate choice of class name, but one of > the uses of class names is as a style sheet selector[1] so > I hardly see that as a hack. Web pages have an inherent > presentational aspect and coding specifically to address > that isn't something to discourage. Well, I guess my viewpoint is that adding span tags with classes into your HTML purely for the sake of having a place for CSS to attach itself is, in a way, adding presentation to your document. In an ideal world, the divs and spans would be added to your document to represent structure, and CSS would be applied later to make it look right. For example, I might have a page that has four sections: "mainNav", "adSection", "links", and "main". Creating divs for these sections seems fine. I'm just marking out parts of my document that have meaning. Depending on the look I wanted to achieve, I might find myself needing to surround, say, the first three divs by another div (let's call it "leftColumn" because there is no semantic relationship between these three sections). That, to me, feels like adding markup to your document for the sake of presentation. Anyway, getting back to my earlier point... I think the pros of microformats outweigh the cons, so I'm not arguing against microformats. I'm just saying that when people look at all the spans and divs with classes on them and wonder if that will complicate things... well... I think it's a fair point. It probably does slightly complicate things. -Sho ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] More responses to slashdot comments
While I agree that the use of the class attribute in microformats is consistent with the intended use (i.e., to embed semantic information into HTML), I think there are some subtle gotchas to consider. My recollection is that when span and class were introduced, there were a lot of people who had some unease with the very existence of class, span and div, because it adds an orthogonal layer of semantics onto HTML. For example, what is the difference between: a) This is an emphasized point vs. b) This is an emphasized point Presumably, (a) would be preferred over (b), although I personally prefer (b). (I think strong and em are copouts, but that's a whole other story). It gets even more confusing when you mix tags and classes more aggressively. Example A: -- 5 out of 5 stars Crepes on Cole is awesome ... Is the h4 the "structure" that defines the semantics of the document, or is the "summary" class the structure that defines the semantics? In other words, why not do this: Example B: -- 5 out of 5 stars Crepes on Cole is awesome ... Ostensibly, the reason for preferring example A over example B is that there are two systems of semantics for two different reasons. The HTML view of the document says that the header is an h4. The microformats view of the document says it's a "summary". Example A allows both views of the document to live together. What's the problem with this? Well, you'll notice that the HTML document has become polluted by the div and span tags. Are the span and div tags part of the HTML semantics, or are they just scaffolding to hold the microformat information? In other words, should we ignore the span and div tags when interpreting our document as HTML? This is essentially the same issue that people have with hacks like adding into a document, which is clearly presentational. While the microformat tags are not presentational, they are a different, orthogonal set of semantics that is being embedded into the document, which can make it hard to know how to interpret the semantics of the HTML tags. Anyway, I think the above arguments are not a reason to discount microformats -- the benefits outweigh the costs. But I do think there is a valid point to consider here, which is that mashing two (or more) systems of semantics together comes at a cost. -Sho -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Allsopp Sent: Wednesday, July 12, 2006 5:50 PM To: microformats-discuss@microformats.org Subject: [uf-discuss] More responses to slashdot comments Tantek (and others) As I have too much time on my hands :-) Another draft response to some /. comments [SDC=Slashdot comment, MFR=Micrformats response] SDC: Mixing presentation and data - good... bad... good. But it gets better a little, each time (maybe more of a spiral than a wheel). SDC: Ok, so this "microformats" thing is about encoding extra data inside an HTML file by abusing CSS class names for markup, isn't that completly unnecessary and nothing more than an ugly hack? MFR: Several slashdot comments carry in essence the same criticism as these - that microfomats, abuse the class attribute, and by doing so mix presentation with document structure. This demonstrates a misunderstanding of the class attribute of HTML. The class attribute is very commonly used by web designers in conjunction with CSS to style pages (which is one of the roles outlined for it in the HTML specification [1]), and in truth, it is often overused in this way. But despite that, class, according to the HTML specification "has several roles in HTML", including "for general purpose processing by user agents" [1]. Microformats make use of this second aspect of the class (and id) attribute, and do so legitimately. It is not an abuse of the class or id attribute to use it to add semantic context to a document. Nor is the use of class in and of itself presentational - in fact, it is an important mechanism for separating presentation from structured content. [1] http://www.w3.org/TR/html401/struct/global.html#h-7.5.2 john John Allsopp style master :: css editor :: http://westciv.com/style_master blog :: dog or higher :: http://blogs.westciv.com/dog_or_higher WebPatterns :: http://webpatterns.org Web Directions Conference :: Sydney September 28-29 :: http://wd06.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Could microformats be classed as spam by searchengines?
My understanding of why search engines such as Google don't like hidden text is that it can be used as a strategy for spoofing search results: put innocuous search words here Given this, I think that the philosophy of tagging human readable content with semantics actually is in line with what Google wants, and should not be a problem. To the extent that Google and other search engines may not trust hidden information, they may choose not to index information found only within the machine readable portion of the document. -Sho -- Sho Kuwamoto Macromedia Flex Builder http://labs.macromedia.com/technologies/flexbuilder2/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Thursday, November 17, 2005 10:16 AM To: Microformats Discuss Subject: Re: [uf-discuss] Could microformats be classed as spam by searchengines? On 11/17/05, brian suda <[EMAIL PROTECTED]> wrote: > justin norton wrote: > > > Hello, > > > > Could anyone provide an answer to the following: > > Google recently updated their search engine and now treat text that is > > hidden through CSS as spam. > > --- do you have reference to this? but it is not relevant because you > shouldn't be hiding any microformat data with CSS anyway. The first rule > of microformats is 'Human readable' any hidden information goes against > this. I agree that there's much to worry about... microformats aren't meant to disguise semantics -- only provide a mechanism for marking up the content you intend to display on a page, typically no more and no less. Where we embed semantic equivalents in the tags themselves (i.e. GMT times in abbr tags for times), I don't see how that could be considered spam. The matter in question is important though -- if microformats use grows to the point where they are abused -- in ways that might be hard to imagine today (who knows, spammers convert all their content first??) -- what can we do in the design of microformats to stem what is arguably inevitable? Perhaps it isn't even something worth fretting over, but it is an interesting problem that's yet to be addressed on this list from what I've read. The only other question I have about this move on google's behalf is what it will mean for techniques like sFIR or text-replacement techniques like using negative text-indents... Chris ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
