HN user
If hypothetically 10% of the population said A but you slice up B into specific enough buckets then A wins even if the overwhelming majority dislike A.
Yes, if you're only allowed to vote for a single option. If you're allowed to vote yes/no for each option, or rank them from best to worst, then this problem doesn't happen.
Okay, let's go over this then.
First, let's talk about the basic case where there's no whitespace between the two paragraphs.
<p>Paragraph 1</p><p>Paragraph 2</p>
<p>Paragraph 1<p>Paragraph 2</p>
<p>Paragraph 1<p>Paragraph 2
<p>Paragraph 1</p>
<p>Paragraph 2</p>
<p>Paragraph 1
</p><p>Paragraph 2</p>
<p>Paragraph 1
<p>Paragraph 2</p>
<p>Paragraph 1
<p>Paragraph 2
And that leads us to this point: the HTML spec is specifying the exact circumstances where you can omit tags without changing the DOM. However, if we are okay with changing the DOM a bit, by moving that whitespace into the first paragraph, then we can simply pretend that we wrote
<p>Paragraph 1
</p><p>Paragraph 2</p>
In this comment section? Are you talking about stuff like the example I used earlier?
<p><div></div></p>
<p></p><div></div></p>
<foo><bar></bar></foo>
I don't understand what you mean. Please elaborate.
That quote says that </p> is not needed in many cases. When you say "none of those clauses apply to <p>", this is true, you can't omit <p>, only </p>... but the blog article doesn't advocate for omitting <p> at any point.
Although there are some other uses for <p>, it is perfectly valid to use <p> tags for textual paragraphs and that has been the main use for <p> for as long as HTML has existed. I'm not sure why you believe otherwise.
Take a look at the source code for http://info.cern.ch/hypertext/WWW/MarkUp/Future.html for instance, which was written by the creator of HTML, Tim Berners-Lee.
You can also look at the source code for any page of the current HTML spec (e.g. https://html.spec.whatwg.org/multipage/introduction.html) where, again, <p> is used for each paragraph in the text.
What's not in the spec? Every example in the article is valid HTML, and the article itself, which is written in the same style, is valid as well:
https://validator.w3.org/nu/?doc=https%3A%2F%2Flofi.limo%2Fb...
Document checking completed. No errors or warnings to show.
Or are you complaining that the rules are too complicated? It's very verbose and explicit because this is a specification, but the basic rule of thumb is that anything that would normally be a block element and thus doesn't make sense inside a paragraph will end that paragraph. In practice, this is not really an issue I run into.
Moreover, you need to know about this rule even if you don't omit </p>, because this is the list of elements that implicitly ends a paragraph. For example, <p><div></div></p> is invalid HTML because <div> ends the paragraph implicitly, making it equivalent to <p></p><div></div></p>.
If you don't like that, then your problem is not with this particular code style but HTML itself, which is reasonable. HTML's syntax is very complicated due to its history and doesn't always make sense. But you still have to know how it works regardless of how you personally like to write it.
One interesting detail is that a lack of deep nesting was in fact a deliberate design goal for HTML originally, to make WYSIWYG editing more feasible.
http://info.cern.ch/hypertext/WWW/MarkUp/HTMLConstraints.htm...
Were the five unclosed runs before the five closed runs? I could see that making a difference vs. interleaving them, if the hardware needs to "warm up" first.
For me, on Firefox on Linux (I know it's the one with the smallest difference, but I don't have the others on hand, sorry), using the "load" time at the bottom of the Network tab, with cache disabled and refreshing with Ctrl+F5, interleaving the tests:
- Unclosed: 1.38s, 1.49s, 1.45s, 1.52s, 1.48s
- Closed: 1.47s, 1.37s, 1.48s, 1.49s, 1.35s
The one with </p> omitted takes about 0.032s longer on average going by these numbers, but that's about 2 frames of extra latency for a page almost twice the length of The Lord of the Rings.
Regarding the page itself, I tried to keep everything else as identical between the two versions as possible, including the DOM, hence why I wrote the </p> immediately before each <p>. As for backtracking, I'm not sure what you mean. The rule for the parser is simply "If the start tag is one from this list, and there's an open <p> element on the stack, close the <p> element before handling the start tag."
I can't verify your numbers. As far as I can tell, loading a ~900,000 word document with no other differences than including or excluding </p> has about the same load time, though there's too much variance from load to load for me to really give definitive numbers.
Are you sure you converted it properly? I'd expect those kinds of numbers if your elements were very deeply nested by mistake (e.g. omitting tags where it's not valid to do so), but I don't see why leaving out </p> should be so slow.
Try these two pages:
You have to know about what breaks out of <p> tags regardless of whether or not you leave off the end tag, though.
<p><div></div></p> is invalid HTML because <div> ends the paragraph, resulting in an unpaired </p>.
Okay, I've gotten a bit carried away with HTML spec minutia elsewhere in these comments, mainly because this stuff really isn't common knowledge among web developers and it's hard to resist talking about it.
However, I also want to add to the other point here; namely, "why do this in the first place?"
Google mentions "file size optimization" in the style guide linked above, and it led to criticism on HN and elsewhere along the lines of "sure, maybe shaving off a few bytes adds up for Google, but you're not Google." However, this really isn't why I do it, and I think maybe it's poisoned the discussion a bit.
For me, it's mostly about reducing visual noise. It's not necessarily less typing if you're using an editor that auto-inserts closing tags, but I think it's harder to read with the end tags, particularly when it comes to tables. For instance, consider this table (which, if you're curious, is about Super Nintendo audio samples):
<table>
<tr><th>sample rate</th> <th>data rate</th> <th>max length</th></tr>
<tr><td>32000 Hz</td> <td>18000 byte/s</td> <td> ~3.641 s</td></tr>
<tr><td>16000 Hz</td> <td> 9000 byte/s</td> <td> ~7.282 s</td></tr>
<tr><td> 8000 Hz</td> <td> 4500 byte/s</td> <td>~14.564 s</td></tr>
</table>
<table>
<tr><th>sample rate <th>data rate <th>max length
<tr><td>32000 Hz <td>18000 byte/s <td> ~3.641 s
<tr><td>16000 Hz <td> 9000 byte/s <td> ~7.282 s
<tr><td> 8000 Hz <td> 4500 byte/s <td>~14.564 s
</table>
On top of that, let's be honest, <html><head></head><body></body></html> is just useless boilerplate. We all know what goes in the head and what goes in the body, and I think we can all figure out where the HTML starts and ends. The browser knows all of this too, which is why all of those tags are completely optional. Not only does getting rid of that make the code less noisy, it solves the age-old problem of "should I indent the head and body or not?" (Though, in practice, I still keep <html lang=en> so that I can specify the language for people who use screen readers. </html> is just silly, though.)
This is not quite right. The HTML spec specifies not only what browsers/user agents are allowed to do, but also what document authors are allowed to do.
While the HTML parser does handle errors, to conform to the spec, document authors must not make these errors.
Here is an excerpt from the spec[1]:
As described in the conformance requirements section below, this specification describes conformance criteria for a variety of conformance classes. In particular, there are conformance requirements that apply to producers, for example authors and the documents they create, and there are conformance requirements that apply to consumers, for example web browsers. They can be distinguished by what they are requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act.
Furthermore, a user agent is not required to correct errors, and can simply halt at the first error[2]:
The error handling for parse errors is well-defined (that's the processing rules described throughout this specification), but user agents, while parsing an HTML document, may abort the parser at the first parse error that they encounter for which they do not wish to apply the rules described in this specification.
[1] https://html.spec.whatwg.org/multipage/introduction.html#how...
[2] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
Just to add to this, HTML parsers will attempt to make sense of any random line noise you give it and turn it into a DOM. When I say something is "invalid" HTML, what I mean is that it's not allowed by the spec and will result in an error if you run it through a validator (which you should do!)
For example, try running the following document through the W3C's HTML validator[1]:
<!DOCTYPE html>
<html lang=en>
<title>Test Document</title>
<p>
<div></div>
</p>
[1] https://validator.w3.org/nu/#textarea
[2] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
Oh, for sure, actually parsing HTML was awful before HTML5. The spec sometimes diverged from how browsers actually interpreted HTML, and error correction basically boiled down to browsers trying to reverse-engineer each other to figure out how they handled broken HTML. HTML5 was a godsend for actually standardizing all of that.
I mentioned "block elements" in my other comment, but to be clear, CSS has no effect on how HTML is parsed, so the display property isn't relevant here.
Furthermore, you need to know about this rule even if you do write `</p>`. If you write this:
<p>
<div>hello</div>
</p>
<p>
</p><div>hello</div>
</p>
Yes, that is a case where it's not legal to omit `</p>` if you don't want the image to be inside the paragraph. Take a look at the spec[1], which outlines exactly when it is valid to omit tags.
The `p` element in particular has pretty scary rules, but it basically boils down to "if it doesn't make sense for this to be inside a paragraph (usually because it's a block element of some kind), it ends the paragraph."
[1] https://html.spec.whatwg.org/multipage/syntax.html#optional-...
Well, then they were wrong, because it's always been part of every HTML spec.
Perhaps they were thinking of XHTML, which did require all tags because it was based on XML.
Just to clarify, HTML5 didn't introduce this, it's been the case since at least 1993.
I'm pretty sure they're talking about Japan, not the US.
It's not one server, he's obtained control over the whole Freenode network.
I think you misunderstood the comment you're replying to. They're saying Andrew Lee is the one crapping on the channel owners by hijacking their channels.
Effectively, each server ticket increases your upload limit by 200 MB, permanently. I'd imagine things could add up with custom graphics and things like that, but I have no idea exactly how big the userbase is in Japan. It's definitely bigger than in the West, but I don't know by how much.
No, but SmileBASIC itself supports a USB keyboard and mouse.
Well, let me try explaining how it works, because they honestly do a pretty bad job of it.
So SmileBASIC 4 itself costs 25 USD (40 AUD).
A server ticket costs 5 USD (9 AUD). Despite the name, these tickets never expire or get used up. How these work is as follows:
- If you have 0 tickets, you can only download once every 8 hours, and you can't upload anything.
- If you have n tickets, where n > 0, then you have unlimited downloads, and can upload 10*n projects at once. (Note that you can take down old projects to make room for new ones.)
Personally speaking, unless you really need to upload a lot of projects at once (and 10 slots goes further than you might think), you really only need one ticket.
The reason this server ticket system exists is because SmileBoom is a pretty small company (their site lists 8.2 million yen in capital, about 76,000 USD or 120,000 AUD), and this helps offset server costs.
In any case, if you still find this system distasteful, there's nothing stopping you from continuing to do it the old way, manually typing in programs by hand. That said, I don't think it's so unreasonable to ask for a few bucks for server access, especially as a one-time fee.
(Note also that originally the plan was for SmileBASIC 4 to only be sold as a bundle with one ticket. The standalone version was added because there were issues with it showing up in the eShop properly otherwise.)
EDIT: One more note: this is a project limit, but you can have multiple files in a project, and the maximum project upload size is 20 MB. As you probably know, text doesn't take up much space, so you can cram a LOT of small programs into one project if you need to.
Previous versions of SmileBASIC also exist on the DSi (under the name "Petit Computer") and 3DS (simply called "SmileBASIC").
I think you may have misread that RFC. With my emphasis:
Here is a list of limitations with the current bounds syntax that are overcome with the where syntax:
The list is of the limitations of normal bounds, not the limitations of where clauses. This was actually the RFC that added where clauses, and that list was the rationale for doing so.
I think it's less about the implementations themselves, and more to show how little we need to worry about performance these days in comparison. Even our "slow" languages are tens of thousands times faster than anything used back in the 1980s.
In the first paragraph, the writer links to an earlier blog post[1] which brings up the point that, though there's a lot of debate about the merits of different programming languages, things are fast enough that you really don't have to worry about that. Even the slowest languages are more than fast enough for most purposes.
A bit reluctant to bring this up since strictly speaking it's not quite on-topic, but you don't have an email address or other method of contact listed, and it's something I don't really want to ignore.
I don't want to presume too much here, but my question is, if your friend identifies as female, and you're aware that she does, why do you refer to her as "he"? From a lot of your comments I get the impression that you're not very aware of feminist issues in general, but even without that knowledge, doesn't it seem disrespectful towards your friend to call her that? If she identifies as a woman, why call her something she's not? If who we are is in our minds, why should the body take precedence?
I could say a lot worse, certainly, since I'm a trans woman myself. I know firsthand what it feels like to have people deny your identity day after day (really shitty, to clarify). Even so, I'm trying to at least be understanding here, rather than give a knee-jerk reaction.