WHATWG
2022-09-26
plaintext logs
prev next
source on github
07:52
<Domenic>
Thoughts welcome on https://github.com/whatwg/html/issues/8321
09:19
<sideshowbarker>
hsivonen: r? https://github.com/validator/htmlparser/pull/73
09:35
<hsivonen>
hsivonen: r? https://github.com/validator/htmlparser/pull/73
That's rather dramatic text considering the reason why /> was made into a non-error in the first place. I see that this builds on polyglot checking from 2009. Is there presently UI for this stuff (as opposed to appending parameters to the URL manually)?
09:36
<hsivonen>
That's rather dramatic text considering the reason why /> was made into a non-error in the first place. I see that this builds on polyglot checking from 2009. Is there presently UI for this stuff (as opposed to appending parameters to the URL manually)?
Is the goal of html-strict documented somewhere?
09:39
<sideshowbarker>
That's rather dramatic text considering the reason why /> was made into a non-error in the first place. I see that this builds on polyglot checking from 2009. Is there presently UI for this stuff (as opposed to appending parameters to the URL manually)?
There’s no UI for it. For the HTML checker, I plan to add a new off-by-default build-time flag, and enable it for the W3C service.
09:40
<sideshowbarker>
The context is https://github.com/prettier/prettier/issues/5246
09:42
<sideshowbarker>
Summary: When formatting HTML, Prettier changes all void elements to have self-closing tag syntax — without any option to make it not do that, despite an issue asking for such an option being open for 3 years, and having 231 thumbs-ups
09:46
<sideshowbarker>
Is the goal of html-strict documented somewhere?
I guess I could write up an extension spec for it. But the goal is basically to warn people using Prettier or other tools that do this to their HTML markup that such tools are doing something that’s a widely-discouraged antipattern bad practice.
09:47
<sideshowbarker>

see, e.g., https://google.github.io/styleguide/htmlcssguide.html#Document_Type

Although fine with HTML, do not close void elements, i.e. write <br>, not <br />.

09:48
<hsivonen>
Summary: When formatting HTML, Prettier changes all void elements to have self-closing tag syntax — without any option to make it not do that, despite an issue asking for such an option being open for 3 years, and having 231 thumbs-ups
So this is about winning a GitHub argument by serving the comment from the W3C validator? How does one enable the html-strict profile there?
09:48
<hsivonen>
Was Jake Archibald 's Twitter poll also subtweeting that GitHub issue?
09:49
<sideshowbarker>
I didn’t see Jake’s twitter poll, but it’s certainly not about winning a GitHub argument.
09:49
<sideshowbarker>
It’s about helping users of the HTML checker.
09:50
<Jake Archibald>
https://twitter.com/jaffathecake/status/1565315346516611072?t=LW39uwh0Vu6ZwlKub7twUw&s=19
09:50
<sideshowbarker>
The point is that without getting any kind of warning about it, users might assume that because Prettier does it, it must be some kind of best practice, and then they start preemptively using self-closing tag syntax everywhere.
09:51
<sideshowbarker>
Basically that Prettier behavior risks imposing a kind of cargo-cult mentality among users
09:52
<sideshowbarker>
https://twitter.com/jaffathecake/status/1565315346516611072?t=LW39uwh0Vu6ZwlKub7twUw&s=19
Thanks, looking now
09:53
<sideshowbarker>
so 62% like self-closing tag syntax. That’s pretty disappointing. I wonder if it would be possible to figure why so many people prefer it.
09:54
<Jake Archibald>
Pretty sure it's JSX
09:54
<sideshowbarker>
aha
09:54
<sideshowbarker>
pretty disheartening
09:55
<Jake Archibald>
Agreed
09:55
<Jake Archibald>
Although, I wouldn't mind if self-closing worked on all elements
09:55
<sideshowbarker>
This kind of makes me feel even more inclined to have the W3C HTML checker start emitting warnings for it
09:59
<annevk>
If only all browsers put some months into XML5
09:59
<sideshowbarker>
Although, I wouldn't mind if self-closing worked on all elements
We should do a twitter poll asking browser-project parser implementors when they might ever be interested in implement support for that… Pretty sure “When hell freezes over” would get the most votes 😆
10:02
<hsivonen>
So how does one enable the html-strict profile?
10:02
<sideshowbarker>
I wonder why it is that JSX requires self-closing syntax for void elements. I can’t possibly be using an XML parser? Does it also require other XML-isms? e.g., does it require attribute values to be quoted?
10:03
<sideshowbarker>
After reading all comments on the GitHub issue, I'm more sympathetic to the change. Still, I wonder if a message with the general sentiment of "This is a useless no-op that gives people the misconception that it's meaningful." would be better than calling out Prettier by name. (Though after reading all the comments, I can understand why you'd call out Prettier by name.)
OK — I can update the message to make it less specific
10:04
<hsivonen>
On a related note: I wonder what the present level of demand is for a mode that emits notes about implied tags. I've had that on my mental TODO list since XTech 2007 or 2008.
10:04
<annevk>
sideshowbarker: JSX is very XML-like as I understand it, but it allows some HTMLisms around attribute syntax iirc.
10:08
<sideshowbarker>
So how does one enable the html-strict profile?

When calling the parser code, by doing HashMap<String, String> profileMap = new HashMap<>(); profileMap.put("html-strict", "warn"); htmlParser.setErrorProfile(profileMap);

As far as the HTML checker code, I guess I’d have a build-time option that sets a boolean Java system property (which if it’s true, calls into the parser code as above).

10:09
<sideshowbarker>
sideshowbarker: JSX is very XML-like as I understand it, but it allows some HTMLisms around attribute syntax iirc.
I guess my next question would be why is it XML-like and does it really need to be. But I guess that just takes me further down the rabbit hole…
10:10
<sideshowbarker>
I really don’t like the arbitrary whims of tool maintainers ending up controlling how users have to mark up their HTML just to make the tools happy
10:12
<sideshowbarker>
Web developers/authors should be able to just use any HTML markup that conforms to the requirements in HTML spec, and tools should accept that without choking/failing on it or corrupting/mangling it
10:29
<sideshowbarker>
Perhaps the note could also say that the slash interacts badly with other HTML features and is discouraged for that reason as well. (Specifically, it interacts badly with unquoted attribute values. Prettier deals with this by adding the Netscape 4 space, but that already shows how Prettier has created a problem for itself.)

Proposed wording:

Self-closing tag syntax in text/html documents is unnecessary and widely discouraged. It interacts badly with other HTML features (e.g., unquoted attribute values). If you’re using a tool that injects self-closing tag syntax into all void elements, without any option to prevent it from doing so, or a system that’s unable to process HTML content containing void elements that don’t use self-closing tag syntax, then consider switching to a different tool or system.

10:32
<sideshowbarker>
On a related note: I wonder what the present level of demand is for a mode that emits notes about implied tags. I've had that on my mental TODO list since XTech 2007 or 2008.
I think that would pretty helpful to developers. I say that based on my experience from getting reports from users in the issue tracker for the HTML checker and on the www-validator list where the users don’t understand about implied tags
10:33
<annevk>
I am somewhat thankful that I care a lot less about this these days. Is <br /> ugly? Yes. Do I flinch when I see it? Maybe. Do I care? Meh. But more power to you all for keeping the dream alive! 😀
10:33
<sideshowbarker>
heh
10:35
<sideshowbarker>
One big specific reason I care about this is https://github.com/mdn/content/issues/20523
10:40
<sideshowbarker>

Summary: The MDN project recently starting running all HTML snippets through Prettier.

But somebody noticed that:

  • Prettier changed all the void elements to use self-closing tag syntax
  • But the MDN project has a long-standing code style guideline that says, “Don't include XHTML-style trailing slashes for empty elements because they're unnecessary”, so the Prettier behavior conflicts that

Unfortunately, the resolution to the issue was to silently remove that “Don't include XHTML-style trailing slashes for empty elements because they're unnecessary” style guideline.

And the ultimate outcome of this is that, at this point or at least going forward, every single HTML snippet in MDN that has void elements now uses self-closing tag syntax

10:42
<sideshowbarker>
…and because of all that, another likely outcome is that web developers/authors start saying/thinking, “Well, MDN using self-closing tag syntax in all its HTML examples, so that must mean it’s a best practice and I (you) should always use self-closing tag syntax too.”
10:42
<sideshowbarker>
…because if it weren’t a best practice, then MDN wouldn’t be doing it, right?
10:45
<sideshowbarker>
But the reality is that the reason MDN is using it is because it was decided that it would be a good idea to run all HTML snippets in MDN through Prettier — and because of shortcomings in Prettier, that necessarily means having self-closing tag syntax everywhere.
12:05
<hsivonen>
One big specific reason I care about this is https://github.com/mdn/content/issues/20523
Oh wow. That's so sad that I got baited into commenting: https://github.com/mdn/content/pull/20528
12:09
<sideshowbarker>
Oh wow. That's so sad that I got baited into commenting: https://github.com/mdn/content/pull/20528
Great comment — thanks for doing that
12:09
<hsivonen>

Proposed wording:

Self-closing tag syntax in text/html documents is unnecessary and widely discouraged. It interacts badly with other HTML features (e.g., unquoted attribute values). If you’re using a tool that injects self-closing tag syntax into all void elements, without any option to prevent it from doing so, or a system that’s unable to process HTML content containing void elements that don’t use self-closing tag syntax, then consider switching to a different tool or system.

Striking "or a system that’s unable to process HTML content containing void elements that don’t use self-closing tag syntax" (and then "or system") would still make the point while making the message shorter. Anyway, r+ in the sense that I don't want to prevent you from deploying a note on the W3C instance. (I still find it sad that something like Prettier is so contrary to the purpose of this aspect of the spec.)
12:10
<sideshowbarker>
OK, thanks, yeah it’s a relatively long message so dropping that part will help
12:58
<hsivonen>
Aside: VS Code syntax highlights the slash incorrectly in combination of an unquoted attribute value.
Filed as https://github.com/microsoft/vscode/issues/161764
13:03
<aja>
fwiw, i'm still in habit of polyglot served as xml on my local test systems, but served as text/html in production.
13:39
<Ms2ger 💉💉>
last polyglot standing, huh
13:46
<aja>
"pretty" much :)
14:41
<Jake Archibald>
Has anyone tried talking to Prettier about this? As in, 'official' HTML folks
17:35
<annevk>
Jake Archibald: I read through https://github.com/prettier/prettier/issues/5246 and I can kinda see why they go this way if they a) don't like options and b) want JSX compat
17:36
<annevk>
I think the problem here is really MDN using Prettier for examples. At least in the WHATWG we wouldn't do that kind of thing for specs since we want specs to show a variety of styles (although I suspect that most end up matching the preferences of their authors)
18:04
<Jake Archibald>
Yeah, I don't have a strong opinion here. I don't see much point in />, but I use Prettier for my blog
19:50
<networkException>

I'm struggling to get 8.1.5.5.3 HostResolveImportedModule(referencingScriptOrModule, moduleRequest) working properly:

Who's in charge of setting [[HostDefined]] on the current Realm record to a settings object, aka the current settings object? As far as I can tell the spec only defines setting [[HostDefined]] to a settings object when setting up a window environment settings object (ignoring workers for now).

All places (create a new browsing context and create and initialize a Document object) that run the window environment settings object setup steps do so with an execution context that has been removed from the execution context stack by create a new JavaScript realm - as such there doesn't seem to be a way the window settings object can ever become the current settings object.

Am I missing some implied logic here?