Title format about mbtiles-spec HOT 8 CLOSED

I'd rather them not be: the spec itself should be more general than the usage of it: the iPad app might pull out <h1>s for its headers as a convention / de-facto standard.

from mbtiles-spec.

But isn't it up to the formatter function if <h1> ever appears in the formatted output? Reverse-parsing HTML, particularly in Obj-C, sounds like a slippery slope...

from mbtiles-spec.

True, but it's complexity in one direction or the other: if we start to split up the formatter's output beyond just 'content', then web implementations will need to detect the title field and wrap it in <h1> or similar. I think the slippery slope is really in the idea of making a formatter's output serve the needs of specific implementations within the spec: there could be, you know, a title, description, timestamp, author, etc., field. Using standards within the content instead of around them seems far more attractive, because it'll degrade gracefully and only require code on the platforms that need it.

from mbtiles-spec.

I still have concerns around using HTML, designed for presentation, to stand in for intent, though. I'm afraid that the tendency will be to have web clients just serve it up as HTML, no harm done -- as you say, only require code on other platforms. Every other platform has to mess with the desired presentation as intent, which is fragile.

We're already getting into somewhat ugly territory on the iPad around HTML-view presentation of interactivity data, when something more suited to a more true cross-platform nature (like, sigh, XML or some other non-visually-oriented markup). I'm afraid that continuing to favor HTML makes it more difficult on every other platform, of which we hope (I think) there will be more of than just mobile platforms.

To flip it around, say we put interactivity data in the files as binary property list format since it's natively parsed in Cocoa. You can just add a new key string (author) with a value and Cocoa can natively read this into a dictionary object and act on it with valueForKey:. In fact, if you were to just take a string output of the dictionary, it would look pretty good in a text field on the iPad (say, for argument's sake). We can just require every other platform to parse property lists and turn them into something useful-looking on their platform...

from mbtiles-spec.

It does make sense to avoid this because it would introduce the assumption that interactive regions even have titles, and not all do.

from mbtiles-spec.

I'm not sure I'm in agreement, now that you've brought titles up. In our formatter design, we've assumed a "teaser" and a "full" view, mirroring the common UI paradigm of master-detail. This works well for web (hover vs. click) as well as touch (touch vs. long touch, or touch to get bubble vs. disclose to get more detail -- admittedly we're still working on that). Inherent to master-detail is the possibility of a title, plus a teaser or a detail view of the data represented. I agree it could get large if we also start considering things like dates, authors, etc., but a title possibility at least is in keeping with the idea of a formatted feature being a "named thing".

Also, as is probably evidenced by my responses, I'm less worried about titles and more worried at a deeper issue about fully-rendered HTML being the formatter output, if this is truly to be cross-platform and not a "web-favored, everything else reverse engineer it into a presentation format that suits you" approach. My assumption with the formatter is that you should be able to bake in formatting, not final output. In the case of web-only, the approach I've heard is that the formatted HTML output can be further modified with CSS to better suit the hosting site. Feel free to call me on this if this is a straw man. But my concern is that then even web implementors will have to hack the HTML in an MBTiles to best suit their presentation needs, instead of getting at the intent of the baked-in data.

Basically, I'm arguing that the stuff in the features should be semantic.

from mbtiles-spec.

In our formatter design, we've assumed a "teaser" and a "full" view, mirroring the common UI paradigm of master-detail.

We require all formatters to implement teaser and full, but not just those: the .format attribute is still freeform, and other patterns - notably location, can be added by individual implementations before they're added to the spec. I'd expect a 'page' format to creep in soon enough. My point is that the spec isn't trying to mirror any UI paradigms, it's just trying to reflect defacto usage of an abitrary system, and to ensure that all clients can work with it.

Inherent to master-detail is the possibility of a title, plus a teaser or a detail view of the data represented.

I don't know if this goes without saying: there is the possibility of a title, but no guarantee that every item will have a title.

Also, as is probably evidenced by my responses, I'm less worried about titles and more worried at a deeper issue about fully-rendered HTML being the formatter output, if this is truly to be cross-platform and not a "web-favored, everything else reverse engineer it into a presentation format that suits you" approach.

What we originally looked for was a format that had widespread implementations and was standardized - the fact that HTML is well-supported on the iPad was a large factor. Is there a format that's less web-centered but also as broadly supported?

In the case of web-only, the approach I've heard is that the formatted HTML output can be further modified with CSS to better suit the hosting site.

The Wax implementation lets you do anything you want with the formatted output - modify it, style it, grab data from it, etc.

This statement

My assumption with the formatter is that you should be able to bake in formatting, not final output.

Conflicts with this statement.

Basically, I'm arguing that the stuff in the features should be semantic.

If we're going this route, it'd make the most sense to actually just push JSON data straight from the datasource to the client, but we didn't go that route because we don't want to put the task of understanding data in the client's hands - only the task of displaying it. The data itself is still accessible, if the code so wishes.

But the main point that I think is important is:

But my concern is that then even web implementors will have to hack the HTML in an MBTiles to best suit their presentation needs, instead of getting at the intent of the baked-in data.

Ignoring the fact that no usage of the tile field other than aesthetics has been brought up, the problem with arguing for communicating the intent of the data is that you need to assume an intent for the data in order to do that, and that's where assumptions and implementation-specific tweaks can become a large problem - this issue only came up because of the iPad implementation, not because of problems with the semanticness or unsemanticness of the standard.

from mbtiles-spec.

Closing; the next push in iPad compatibility might broach these issues, but for the time being users should try to write semantic HTML.

from mbtiles-spec.