Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorganize Spec for consistency and clarity #8

Merged
merged 6 commits into from
Sep 7, 2023
Merged

Conversation

Ethan-Arrowood
Copy link
Contributor

While attempting to fix the problems detailed in #5 I realized that there was a lot of inconsistencies between the usage of markdown and html. Furthermore, the linking was so difficult for me to fix.

This PR is a rewrite/reorganization of the spec that follows patterns I see in the Streams and Fetch specs. It strictly uses HTML elements instead of markdown. It also attempts to reorganize the information in such a way that allows for easier linking, and ideally improved readability.

Still some minor things to fix up. But wanted to share so we can start reviewing asap.

🚀

similarities with that document.
</div>

<h2 id="concepts">Concepts</h2>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure we need this section. I like how it is in the Streams spec because it lays out the higher level concepts before diving into all the individual (and complex) classes. But this spec is simpler, so I think this is redundant. Should I remove this section and move the explanations into the various other relevant sections?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless other folks find value in this section, I'm going to remove it. I just tried it out locally and I personally like it more that way. It simplifies the spec and declutters some of the linking nonesense.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No strong feelings either way here.

index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
Comment on lines -124 to +165
* the `close` method is called on the socket
* the socket was constructed with the `allowHalfOpen` parameter set to `false`, the ReadableStream
is being read from, and the remote connection sends a FIN packet (graceful closure) or a RST
packet
<ul>
<li>the {{close()}} method is called on the socket</li>
<li>the socket was constructed with the `allowHalfOpen` parameter set to `false`, the ReadableStream is being read from, and the remote connection sends a FIN packet (graceful closure) or a RST packet</li>
</ul>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't these equivalent? just a style preference?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, just trying to be consistent. There was * - and <ol> used so I switch everything to HTML

case where this can happen is if the input address is incorrectly formatted.
Errors which occur asynchronously- after the socket instance has been returned- must reject the
socket's `closed` promise.
At any point during the creation of the {{Socket}} instance, `connect` may throw a [=SocketError=]. One case where this can happen is if the input address is incorrectly formatted. Errors which occur asynchronously (after the socket instance has been returned) must reject the socket's {{closed}} promise.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpicking but it would be nice to keep to a 80 or 100 line length limit. (there are cases above as well where the wrapping is missing too)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh yeah I tend to favor wrapping only if theres a tool to do it for me. Otherwise its easier to leave everything and toggle word wrap in the editor. Let me look into if theres an automation i can add for this (maybe just a vscode plugin or something)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

speced/bikeshed#662 (comment) :( so this wont exist in Bikeshed ever. A quick search also came up empty. My preference in this circumstance is to not wrap because then we'll have to manually check line lengths every time we make changes (and I guarantee we'll miss something). If you feel strongly I'm happy to manually wrap though 👍 doesn't matter that much to me

similarities with that document.
</div>

<h2 id="concepts">Concepts</h2>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No strong feelings either way here.

Ethan Arrowood and others added 4 commits September 7, 2023 09:56
Co-authored-by: Dominik Picheta <[email protected]>
Co-authored-by: Dominik Picheta <[email protected]>
Co-authored-by: Dominik Picheta <[email protected]>
Co-authored-by: Dominik Picheta <[email protected]>
@Ethan-Arrowood
Copy link
Contributor Author

Ethan-Arrowood commented Sep 7, 2023

Thank you for the review! I'm going to merge this now and then we can iterate on some of the other pieces in follow up PRs.

Things to revisit:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants