Skip to content

Conversation

mfreed7
Copy link
Collaborator

@mfreed7 mfreed7 commented Aug 19, 2025

This goes along with whatwg/html#11563.

Closes #181.

(See WHATWG Working Mode: Changes for more details.)


Preview | Diff

@duckdotapk

This comment was marked as abuse.

@mfreed7
Copy link
Collaborator Author

mfreed7 commented Aug 19, 2025

Seems extremely chilish for adults that work for a company as large as Google to keep locking threads where there are comments criticizing this push to drop XSLT, such as this issue and this pull request.

FYI: If you have to lock threads for there not to be opposition, you're probably the ones in the wrong. A discussion isn't "too heated" because people disagree with you.

So two things. One is that I haven't locked a single thread. Two is that others have (rightly) locked several threads because people kept making ad hominem attacks (like calling people "extremely childish") rather than focusing on the technical discussion. I've never seen a thread on WHATWG locked for disagreements - there are many examples of quite heated disagreements that are still open for comment. However, in those examples, the participants were able to talk about the merits of the technology being discussed, without disparaging the people making the comments.

@duckdotapk
Copy link

I do apologise if it was not actually you or any other user from Google who locked those threads, but, IMO, the point still stands that the person who did do so is acting in a manner that's actively hostile to having an open dialogue regarding a proposal that appears to be quite unpopular.

@mfreed7
Copy link
Collaborator Author

mfreed7 commented Aug 19, 2025

I do apologise if it was not actually you or any other user from Google who locked those threads

It wasn't me, but again, I appreciate that they did so.

IMO, the point still stands that the person who did do so is acting in a manner that's actively hostile to having an open dialogue regarding a proposal that appears to be quite unpopular.

On the contrary, it's unfortunate that the people who feel so passionate about this tech can't control themselves enough to act professionally and have a civil discussion. I want to understand actual use cases and try to mitigate issues, but now I can't hear from the subset of affected people who are able to carry on a conversation without name calling.

@ocdtrekkie

This comment was marked as off-topic.

@whatwg whatwg locked as off-topic and limited conversation to collaborators Aug 20, 2025
Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

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

We should add the interface to the Historical section. That would more clearly indicate its status. Looks good otherwise.

@annevk
Copy link
Member

annevk commented Oct 10, 2025

Oh, and I guess we need to figure out how to deal with the MDN CI failures. Would that require first removing the incoming references from MDN @sideshowbarker?

@sideshowbarker
Copy link
Member

Oh, and I guess we need to figure out how to deal with the MDN CI failures. Would that require first removing the incoming references from MDN @sideshowbarker?

Yeah, or else — based on what the error message at https://github.com/whatwg/dom/actions/runs/17081950335/job/48437853413?pr=1400#step:5:30 says, we could set the Ignore MDN Failure option to ignore the missing-ID problems.

(And to be clear, the only related consequence of those IDs going missing is that, in the margins next to places in the spec where those IDs occur, the MDN panels that’d otherwise show up there just no longer show up any more. In other words, it doesn’t otherwise break anything in any observable way — in particular, it doesn’t affect end-users/readers of the spec.)

@mfreed7
Copy link
Collaborator Author

mfreed7 commented Oct 10, 2025

We should add the interface to the Historical section. That would more clearly indicate its status.

Done.

Looks good otherwise.

Thanks!

Yeah, or else — based on what the error message at https://github.com/whatwg/dom/actions/runs/17081950335/job/48437853413?pr=1400#step:5:30 says, we could set the Ignore MDN Failure option to ignore the missing-ID problems.

Let me know if there's something I need to do within this PR, or if this should be separate. I don't know where the bikeshed options are configured.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Define XSLTProcessor

5 participants