Prefix SvelteKit-specific stuff

[benmccann]

Closes #271

[Rich-Harris]

i wonder if this should be svelte: or sveltekit:? or sk:? 'kit' feels possibly a bit ambiguous. though none of the options are perfect

[arxpoetica]

I vote svelte:

[lukeed]

IMO should be svelte: – which also leads me to wonder if there should be an easy way to define custom svelte: component behaviors. Basically, a shortcut entry to define a preprocessor

[benmccann]

I had thought about svelte:, but my worry was that people would think it came from Svelte core and not understand that it was SvelteKit-specific

[antony]

If we intend kit to be a toolkit around svelte to build "svelte apps" as was the intention, then surely svelte would be fine.

it'd be one of those things where a framework author could implement however they wanted, and by default in svelte it has no effect.

Routify might want to implement noscroll differently for example, or elder, or crown, but if we had a common prefix of svelte:noscroll it would allow a set of attributes pertinent to various frameworks to be defined, to be implemented in a framework-specific manner.

So I also vote for svelte.

[babichjacob]

I have a loose collection of reasons not to go with svelte: or at least not svelte:noscroll:

• Everything else svelte:-prefixed (e.x. svelte:window, svelte:component, ...) is provided by core Svelte. (The rest of my reasons are sort of dependent on this fact).
• Third-party (routing) frameworks are now implicitly expected to support svelte:noscroll even though that's a SvelteKit feature (in contrast to being expected to support a core Svelte feature).
• Any attempt to port a SvelteKit app to something else, for whatever reason anyone wants to do such a thing, could be met with confusion about why svelte:noscroll either behaves differently or not at all — "but I thought that was a Svelte feature? Why's it called svelte:noscroll if it's from SvelteKit?"
• While it would be nice for SvelteKit to fade into the background so that beginners don't have to care or even be aware that it exists, there has to be a different documentation site or page or section for it than core Svelte (to explain endpoints and etc) just like Sapper currently. It would neither be good to explain something called svelte:noscroll in SvelteKit documentation, nor to explain svelte:noscroll in core Svelte documentation with the asterisks that it only works if a framework chooses to implement it.
• Additionally, the svelte command was already renamed to svelte-kit in package scripts. It would be more consistent to do that here too.
• Teaching why/that this is the case would be hard. (I have already lost faith in people understanding that npm init svelte@next does not mean Svelte 4 is coming, and this situation is probably even harder to explain than that).

[benmccann]

Ooh, yeah. I'd forgotten that svelte: is already used elsewhere. That does seem like it will cause endless confusion

How do folks feel about sveltekit: as a compromise option? It's a bit longer than the other two options but not terribly so, it more clearly relates to SvelteKit than kit:, and it's not overloaded like svelte:

[babichjacob]

Previous discussion #183 on naming the CLI (also the only place I can find any discussion on naming / branding standards) and the example called svelte-kit-demo make me prefer svelte-kit:

... unless replacing every instance of svelte-kit with sveltekit so that the spelling is the same whether it's in lowercase or properly capitalized is on the table.

[Conduitry]

I'm less keen on sveltekit: or svelte-kit: for the prefix here. The longer name svelte-kit was fine for the CLI, because you don't type its name very often and instead will mostly be using npm run scripts.

I don't want to derail this too far, but: Should we have (or is it already too late to have) some sort of defined behavior around attributes containing colons? Any time Svelte adds a new directive to core, it risks being a breaking change for anyone who happened to use it as an attribute. Do we want to discourage people from using attributes containing colons as having special meaning in their app/library/whatever? Should we practice what we preach, and not use colons in what are (to Svelte core) just attributes?

[benmccann]

Any time Svelte adds a new directive to core, it risks being a breaking change for anyone who happened to use it as an attribute.

I think this is only true if we use svelte: as a prefix in SvelteKit, which seems like an argument against using svelte:. As long as Svelte core sticks to svelte: and library/app authors use a different prefix then there's no issue, so I think it's less about colons and more about whether we have overlapping prefixes.

[Conduitry]

Svelte core doesn't stick to svelte:. It has bind: and use: and class: and in: and out: and all of the other directives, which are indistinguishable from 'attributes which happen to contain a colon' other than by looking at what the currently implemented directives are.

[benmccann]

True. Though it seems highly unlikely that Svelte core would ever add something like kit:, svelte-kit:, etc.

We could also reserve one specifically for apps and frameworks like app:. I guess the question would be in that case whether we want to establish some sort of shared standard (e.g. any library could provide a component which has app:noscroll in it) or if we're more worried that it'd create a mess of overlapping and conflicting attributes in which case it'd be safer to use something like kit:, svelte-kit:, etc.

[arxpoetica]

If we're going down the route of something that isn't svelte: (I still favor this—I think the objections are more nit-picky than actually problematic), I would favor something short for the sake of brevity in the markup.

I agree that kit: feels weird, but it is shorter. Could also agree to app:.

[antony]

I was thinking about app. I like the framework-agnosticity.

[benmccann]

I created a ranked choice voting poll here for people to vote: https://app.rankedvote.co/elections/1422/Preferred-SvelteKit-attribute-prefix/1417/vote

[benmccann]

sveltekit was the narrow leader in the vote: https://app.rankedvote.co/elections/1422/Preferred-SvelteKit-attribute-prefix/1417/results

I've gone ahead and updated this accordingly unless @Rich-Harris wants to make an executive decision for it to be something else