Use a single-case name for meshGradient

[AmeliaBR]

As explained in #140, we've opted to separate out the paint server aspect of mesh gradients from the renderable graphics aspect. Currently, the draft uses <meshGradient> and <mesh> respectively, but the camelCased <meshGradient> contradicts with the working group's commitment to not introduce new camelCase names (as discussed in #161).

@nikosandronikos has argued against the name <meshgradient> without camelCase (and I agree with him), because of inconsistency with the existing <linearGradient> and <radialGradient>. It's confusing enough that we have some camelCase and some single-case names, without having them so similar as well.

So we need a new name. Again, we're using the name <mesh> for an element that creates a painted shape on screen, the missing name is for the element that defines the shape and color stops.

My best recommendation: <meshgrid>. I think that makes clear that this is the element that contains <meshrow>s of <meshpatch>es.

[tabatkins]

Sounds good.

[AmeliaBR]

Adding to agenda so we can get a resolution:

PROPOSAL: Change the name of <meshGradient> to <meshgrid> to avoid mixed-case confusion.

[Tavmjong]

We, as a group, agreed to no longer introduce new camelCase element names except for consistency with previously defined elements. I think fits this case. Try searching for images using the two terms, 'mesh grid' and 'mesh gradient'. The two searches yield dramatically different types of images; only 'mesh gradient' returns the expected images for a mesh paint server.

[tabatkins]

I'm going to register a complaint if we try and introduce new camelCase names. There is a reason we're avoiding them (they'll cause compat problems until implementations converge, and every new name slightly increases the cost of some hot paths), and "we don't want to think of a different name for this new element" is not a strong justification to go against that.

[AmeliaBR]

Discussed at the telcon of 30 June 2016. Those present agreed not to make any decision until we have further feedback. If anyone else shares @tabatkins' strong concerns about new mixed-case elements, please speak up.

If we do change to a single case name, @Tavmjong and @nikosandronikos are arguing for keeping it as <meshgradient>, for clarity of purpose over consistency with the old elements.

[annevk]

What @tabatkins raises are not just concerns, but arguments that have a basis in fact, right? We know that any new SVG element that does not follow the HTML (parser) conventions will require us to add a special case to the HTML parser.

I agree with @tabatkins that we should not do that.

[nikosandronikos]

Thanks for chiming in @annevk. It's not that we doubt Tab, but this is going to suck for users so we want to make sure the general consensus among browser implementers is to avoid special cases in the parser at all costs.

So on to the bikeshedding...
How about meshpaint?

I think ultimately I'd like to extend the content model of meshpatch to support elements other than stop. For example, a solid fill, or a uv mapped paint server. I think that the structure of mesh gradients is currently set up so that we could do that and it would make sense - as long as the outer element doesn't reference a particular type of paint server.

[AmeliaBR]

Resolution from 7 July 2016:

RESOLUTION: Rename meshGradient to meshgradient, add a note in the spec asking for feedback from authors and implementors as to their preference for use and separately their feedback on the difficulty of implementing camelcased element names

[Tavmjong]

Note in spec is missing.

[annevk]

It seems somewhat pointless to have such a note. Implementers are not going to want this to change. And developers probably don't want it to change either since the transition pain in HTML land would be huge.