Readd links to moved files

[johanneswilm]

Closes #261

[annevk]

Could you explain why this is preferable? It seems you end up with more clutter, not less. And the inactive/graduated organization seems to encourage further breakage of links down the line.

[johanneswilm]

The new file structure was proposed by people from Microsoft, not me. I voiced my concerns at the time. This is me trying to reconcile the interests of the various parties involved and I know @gked is currently not available. I agree that there will be a little more clutter with this, but there will always be some of that given that we have used this repository for incubation.

[annevk]

I would prefer that we revert for now and then if there's a need for breaking URLs there's a slightly wider discussion that involves downstream dependencies.

[johanneswilm]

Note though that reverting will also reintroduce most of these link files. I believe that a number of other changes have been introduced in the meantime, so we'll have to move the files back manually.

[annevk]

That seems fine to me.

[johanneswilm]

One last question: Do we know if there are other files than execCommand.html that have links to them?

[annevk]

HTML only links execCommand.html at the moment. But that might not be the only place that links things.

[johanneswilm]

Ok, given that our next call is on June 12th and that @gked is on long-term holiday, what do you people think we should do? I don't have much of an opinion about what the ideal repository structure is, but in the past it was mentioned a number of times that the directory structure that I had inherited from Benjamin Peters and maintained over the last few years was not good by various other browser people, which is why I agreed to the change proposed by the Microsoft people.

@marcoscaceres @LJWatson @frivoal @saschanaz @BoCupp-Microsoft

[saschanaz]

Separating the main branch and the gh-pages branch might be a solution. That way we don't need to keep all those redirecting files in the main one.

[marcoscaceres]

I'd suggest doing this instead for each of them:

Suggested change

	<meta http-equiv="refresh" content="0; url=https://w3c.github.io/editing/docs/contentEditableDisabled.html">
	<script>
	let currentHash = window.location.hash;
	let newLocation = "https://w3c.github.io/editing/docs/contentEditableDisabled.html" + currentHash;
	window.location = newLocation;
	</script>

[marcoscaceres]

@johanneswilm feel free to commit this suggestion... you will need to update the other files too.

[marcoscaceres]

Separating the main branch and the gh-pages branch might be a solution. That way we don't need to keep all those redirecting files in the main one.

That sounds hard to keep in sync, to be honest. It also makes it hard for new contributors to know where to send stuff.

@johanneswilm, if the new structure works better for you and the task force, then I would merge this. However, I'd search for any downstream that might be pointing to the new location for the specs.

[johanneswilm]

@annevk Would you be OK with a solution such as that outlined by @marcoscaceres above? If so, I think it sounds as that would be the thing we should do unless someone else is against it.

[saschanaz]

That sounds hard to keep in sync, to be honest.

It should be automated with some GitHub Actions.

It also makes it hard for new contributors to know where to send stuff.

Not sure I follow this one, could you elaborate? I think a simple reverting will make things harder for new contributors as they will see more redundant placeholders.

[johanneswilm]

@saschanaz would the gh-branches contain the same as master + links from old doc locations and nothing more?

[saschanaz]

@saschanaz would the gh-branches contain the same as master + links from old doc locations and nothing more?

Yes, so that we can ignore redirection placeholders on the master branch.

[johanneswilm]

if the new structure works better for you and the task force

This seems to be the case for those participating in the task force that have voiced an opinion about this so far. The new structure also works for me but I'd also be willing to move to some third structure if there was strong opinion about that in the taskforce.

As for whether to only add the links to the gh-pages branch and have a separate master branch or not, I can see the advantages/disadvantages both of you are mentioning.

Given that @gked is on holidays, I don't have much of an opinion, and the next call is in more than week, does that mean that this is up the the WG chairs to decide? I take it that it is rather urgent to resolve the issue of dead links in the HTML spec.

[annevk]

It seems they have been dead since March and nobody noticed so it can probably take a little longer.

[johanneswilm]

Links I could find using a simple search engine lookup:

https://w3c.github.io/editing/execCommand.html
https://w3c.github.io/editing/contentEditable.html
https://w3c.github.io/editing/contentEditableDisabled.html
https://w3c.github.io/editing/contentEditableEvents.html
https://w3c.github.io/editing/contentEditableTyping.html
https://w3c.github.io/editing/contentEditableTrue.html
https://w3c.github.io/editing/input-events.html

I didn't find links for:

https://w3c.github.io/editing/contentEditableIntentions.html

[johanneswilm]

This has been replaced by #264