Add support for namespaced elements

[pdf]

This allows the creation of elements like inline SVG.

Refs #54

Implementing full SVG support is a much more complex beast - that would require generating a new set of elements and properties for SVGs, and possibly some new interfaces to ensure they're only used inside an SVG element.

This change will support attempts at implementing the above, but in the mean time it allows people to construct SVGs manually using vecty.NamespacedTag and vecty.Attribute.

[dmitshur]

Some optional thoughts from me.

[dmitshur]

I think namespace should be there before tag. It goes before tag in the call to createElementNS. Logically, that order makes more sense to me.

[dmitshur]

If it were me, I'd prefer a single-level switch with 3 cases, rather than nesting:

switch {
case h.tag != "" && h.namespace == "":
	h.Node = js.Global.Get("document").Call("createElement", h.tag)
case h.tag != "" && h.namespace != "":
	h.Node = js.Global.Get("document").Call("createElementNS", h.namespace, h.tag)
default:
	h.Node = js.Global.Get("document").Call("createTextNode", h.text)
}

I think that's more readable.

But I think you should defer to @slimsag's preferences. Also, I'm not sure about the performance characteristics of switch vs if in GopherJS. Maybe that's a factor.

[pdf]

Yeah, not sure about this one - I haven't really got my head around testing for GopherJS to do some benching. I think I'll just make this change for readability and let @slimsag weigh in if he'd prefer alternative syntax.

[dmitshur]

It's simpler/more common to represent empty string with an interpreted – rather than raw – string literal ("").

[pdf]

I've no problem changing this for consistency, but as a general personal query, can you explain the assertion that interpreted strings are simpler?

I tend to use raw strings liberally, but I may examine that behaviour if there are technical deficiencies that I'm unaware of.

[dmitshur]

can you explain the assertion that interpreted strings are simpler?

Good question, I'm happy to discuss it.

I should clarify, it's not that I think interpreted strings are simpler overall. But rather than using "" to represent empty string is simpler.

For me, when it comes to single-line strings, I generally always start with interpreted strings as a default, and "upgrade" to raw strings when doing so makes the string simpler. That's typically when the strings involve characters such as ".

So, by default, I would do "foo", not `foo`.

For a short and simple string like that, both work equally well. The differences start to come out as soon as you add special characters. With interpreted strings, the special characters can/need to be escaped. But a raw string literal cannot contain the ` character itself.

For multi-line strings, I consider both equally, and often go with raw strings, because they're more readable and look more like the string value they represent. If the raw string is very long and happens to contain a few ` characters, I can get around that by concatenating the raw string + "`" + rest of raw string.

The absolute only potential technical advantage I see in using interpreted string for empty string is the following. The " character is wider, and more vertical than `. So with the two of them together, to me at least, I think it's more visible that "" and " " are empty sting and single space. But with raw string, it's a tiny bit harder to tell whether `` is empty string or a single space.

However, in the end, I think the main deciding factor comes down to consistency. If you look at the Go source code, there are a total of 7753 hits for "":

But only 241 matches for ``, and many of those hits are false positives:

So, I prefer to go with the most popular representation because it's most what most people writing Go code tend to agree on. Given there are no strong technical reasons to prefer one over the other – they're pretty much equivalent – that's all I have to go on.

[pdf]

Thank you for the brain-dump 😉

My preference has always been to be explicit about where escape sequences or interpolation are expected, and I expect the parser to be simpler for raw strings, however consistency is absolutely a good enough reason to prefer one form from mostly equivalent options.

I must admit though that ergonomics does play a part in my preference - my pinky gets tired these days, and one keypress is less strain than two. I'll have to consider before applying this to my personal code, as I write more Go. Perhaps I'll try a keycode mod.

In any case, thanks for the discussion, change is inbound.

[pdf]

Closing in favour of #107 meta-pull.