md`Here, the ${code("x", "channel")}, ${code("x1", "channel")} and ${code("x2", "channel")} channels all share the ${code("x", "scale")} scale; they determine its domain, and will then be rendered using it. This approach is more focused on decisions about the data than about its presentation: - In D3, you might write \`.attr("fill", d => d.active ? "steelblue" : "gray")\` to fill active items with steelblue. In Plot, \`{fill: d => d.active ? "steelblue" : "gray"}\` will interpret steelblue and gray as _categories in the data_ and map them to different colors according to Plot’s default categorical color scheme. Instead, you can write \`{fill: "active"}\` and then, in Plot options, \`{color: {domain: [true, false], range: ["steelblue", "gray"]}}\`. - You can’t assume that anything you can specify as a constant can also be specified as an accessor function. There are only so many scales (including x, y, color, and radius), and they’re assigned to specific channels. Both fill and stroke share the same color scale. Not every property of an SVG element can be made data-driven; you’re funneled into specific ways of representing your data. In return, a lot of typical boilerplate is done for you. - Different marks imply different scales. Plot.barY, Plot.barX, Plot.cell, and Plot.rect will all draw an SVG \`\` — in different ways:

	ordinal _x_	quantitative _x_
ordinal _y_	Plot.cell	Plot.barX
quantitative _y_	Plot.barY	Plot.rect

- Positional scales (x and y) get axes automatically. You set scale and axis options in the same place in the options object. - You don’t have to think about D3’s [margin conventions](https://observablehq.com/@d3/margin-convention). It just fits the dimensions you give it. Automating the scales means that when you want to change the structure of a graphic, you have to change code in fewer places.`