I'm seeing a versioning layout like

<script src='http://api.mapbox.com/js/dev/mapbox.min.js'></script>
 <link  href='http://api.mapbox.com/js/dev/mapbox.min.css' type='text/css' rel='stylesheet' />

<script src='http://api.mapbox.com/js/0.0.0/mapbox.min.js'></script>
 <link  href='http://api.mapbox.com/js/0.0.0/mapbox.min.css' type='text/css' rel='stylesheet' />

This could either be reflected only in 'built' versions or in the repository itself. Thoughts?

cc @yhahn @tmcw

Tom and I talked about the possibility of introducing options in mapbox.js to control the layout position of map control elements. Options like:

• vertical/horizontal alignment
• area placement like top left, top right ..

Not sure if this is the best idea but it would make it easy for authors to control the design of controls without touching the css.

Also needs docs.

This could be a high-level addon, or in modestmaps-ui

Currently the links point to s3, they shouldn't.

We should have one or two full html examples of how to include mapbox.js like google maps's getting started guide - that frame what to do with the script and link tags on the homepage.

7037c73 is not documented; plz document all public APIs

There should be centralized tests here for broad goals.

This library should make stuff like tilejson loading less painful. I'm not sure how to do this, but this is a problem for site-builders.

Right now Wax is 104KB compressed, which is by far the largest thing in this distribution. We should look at this in depth and see if there is room for improvement.

@tristen How do you think we should show the changelog online? Linking to GitHub might be a fine solution, though it'd be nice to have it front and center for early users.

@aibram Can you doc the ui tweaks that you've made?

Upstream: mapbox/mmg#22

This repository should be able to tag to versions in semver and manage dependencies intelligently. It'll be one javascript file at the end, so should not need async loading initially.

Is this code correct: https://github.com/mapbox/mapbox.js/blob/master/src/map.js#L17

Tests fail because mapbox.interaction doesn't exist. /cc @aibram

Otherwise this is breaking the chaining possible in modestmaps itself. /cc @aibram

I think this should be optional and currently isn't:

/cc @aibram

Discussed this with @willwhite yesterday: our gameplan is

• Push this library, versioned, to js.mapbox.com which is an s3 repo
• Make sure to set very-long expires on all of the component files
• Make a shell script or makefile to make this clearer

After the first push, we should be able to write some docs that refer to mapbox.js but keep all concepts pretty surface-level.

It should only automatically set the tilejson of the topmost layer if interaction.auto() has been called.

It might be cool to have simple events proxied around modest maps, easey, and everything else.

@tristen this might be interesting to you:

I'd like to start documenting the element structure in mapbox.js - the wax-generated elements, modestmaps, anything that's styled by the mapbox.min.css style - so that we know where things come from, their structure in the DOM, and can provide alternative styles - themes - and maintain them properly.

one upstream: cutting-room-floor/wax#101

@aibram can you take a look at this?

ModestMaps centering and zooming functions were extended with another argument, animate. Would it be a good idea to simplify these cases in Easey instead of extending the MM functions?

For example:
map.centerzoom(location, level, true)
becomes map.ease.center(location).zoom(level).run()
or perhaps just map.ease.centerzoom(location, zoom)?

If we override as little of MM as possible then mapbox.js stays as simple as possible.

If we avoid extending the MM functions like this we could say here's a regular MM map, with interaction, ui, and easey attached for convenience and with .auto() and .refresh() functions, instead of having to also document a whole bunch of functions.

Do we want to merge the projects together into one api, or just glue various individual components together?

@tmcw what do you think?

This is somewhat in the court of designers, but basically need to figure whether it'll be possible to just cat CSS or whether something more complex needs to happen here. Might want a final style push from @yhahn or another before this part goes live.

@tmcw Does it make sense to use Jekyll for the site? It would allow us to keep a consistent page layout on example sections and one place to revise the mapbox.js version.

I mention this because it changes this slightly:

The structure of this repo is index.html, examplename/index.html.

Also we might want examples to bear different versions?

These are upstream but I wanted to discuss them here:

map

layer.named -> layer.name
Named in the past tense just seems weird - even for what it does.

markers

markers.factory -> markers.render
factory to me is a pretty internal name. "Render" qualify's what it does: renders the object out as html
or re-renders them out

markers.features -> markers.data
Features is such a geojson spec name. "data" seems like a more appropriate name for how we are using features.

markers.addCallback -> markers.onEvent
This feels more clear to me on some event specified in the first argument, do something (callback)

markers.removeCallback -> markers.removeEvent

interaction.hide_on_move -> interaction.hideOnMove
underscores just dont sit right with me .. we should camelCase right?

interaction.formatter -> interaction.template
Debatable change.

ease

ease.t -> ease.toPoint
More clear

UI is currently undocumented.

Let's build out a big, beautiful examples gallery as part of this. This'll serve as a good test suite as well as a good place to show off proper coding patterns with mapbox.js.

Assuming that we'll need a skeleton to start out with ( @tristen lead as soon as you're done with a site revision ) and then we can all claim examples we want to build / port over.

This should be _the_push to make things perfectly retina & mobile compatible.

• DONE: zoom controls should adapt or look correct at 1:1 px
• interaction controls may need the fix in cutting-room-floor/wax#198
• should users be able to supply a retina version of their tiles?

@yhahn would it be super fun to have this be able to produce static maps just like it can do dynamic ones?

This is, I think, an issue upstream in the control styles w/ wax.

This is an eventual task. The URL will be something like

api.tiles.mapbox.com/v3/js/mapbox.js

I think the map's movement is not rounded and mmg's is. this should be fixed.

Upstream: cutting-room-floor/markers.js#24

@aibram want to take this one? Your pick as far as how to proxy or differentiate easey calls from mm calls

This code should make a lot of the things in map-site less necessary.

Would it make sense to support, for instance, listing a user's maps, getting thumbnails, etc?

Might be a nice feature in mapbox.js to make it easy to set map boundaries. This is currently pretty modest mappy to do ..

The way they've been added to mapbox.ui makes them unusable.

Should there be a mapbox.css? Should this implementation of MM.Map detect for zero-width & zero-height maps and correct them?

Basically setting the .name attribute and adding a getter/setter. @tristen want to take a whack at this?

The first shot at this is here: http://mapbox.com/mapbox.js/

@tristen do you have any thoughts on how to improve this? Basically the approach right now is (and this is prototyped, I haven't written the script to do it automatically)

1. Pull in node_modules of modules as usual
2. Get the API.md file out of each, copy to _posts and add YAML header
3. Serve a jekyll site with a straight list of them all
4. Build a TOC in JS

Ideally this will have the mapbox look, and may live in mapbox.github.com

To be fixed upstream. Currently elements created via mapbox.js uses a prefixed class name like wax-zoomer etc ..
Which is ambiguous to users styling elements and coming from mapbox (not knowing about wax)

Prefixing a name to these controls is the right way to go but we may want a new name for this other than wax. A potential candidate could be .ui-zoomer or .map-zoomer.

@yhahn @tmcw curious on your thoughts here.

Currently just map, should be map, options; right now the callback is undocumented.