201–210 of 212 posts
XML is beautiful and clean, and I prefer to write full closing tags.
It’s funny how people’s aesthetic sensibilities can differ. Making use of HTML’s standard features to drop unnecessary elements and closing tags is very much in line with my own idea of “beautiful” and “clean.” Do you consider any table that doesn’t explicitly declare “unclean”? That’s an implicit element in every , according to the spec.
Earlier quoted context omitted.
I think having one set of fairly clear and complete polite responses to the question to then be linked from elsewhere (or possibly turned into an FAQ ... and then linked to when people inevitably don't spot it in the FAQ before opening an issue ;) is probably a net win in terms of maintaining a positive atmosphere on your bug tracker.
It can help indeed! Thanks for the suggestion BTW [1] [1] https://github.com/gildas-lormeau/SingleFile/commit/6c7a2ef1...
Earlier quoted context omitted.
I'm not claiming you claimed it was a simple specification :-) I just find it interesting. This would indicate to me that there are 500 "features" in the language. I thought mark-down languages just provided a few shortcuts for producing the most commonly needed HTML features and then provide a fallback to HTML. So if you cannot do it in the markdown language, use HTML instead.
I can't really be bothered to take a look at the tests, but I strongly doubt there are actually 500 features. A large part of those tests are probably trying combinations of features. E.g. suppose markdown only had tables as a feature, and nothing else. That feature alone deserves several several tests (for tables of various sizes, edge cases such as having only the header, having rows with an incorrect number of col…
Note however that this means that the whitespace between paragraphs will be part of the paragraph which can be annoying if someone tries to copy the text on your website and gets an additional space after each paragraph which wouldn't have happened if you explicitly closed the
directly after the text.Also, you should keep the opening and specify the language of your document even for english since e.g. automatic hyphenation does not work if you don't specify a language.
Otherwise really like this condensed HTML style and have recently converted my personal website to it.
I appreciate that this blog post itself is written in the exact same style! I really miss being able to read the view-source: version of websites easily, but this blog post does it well :)
Certainly beats the "you don't need so much JavaScript!" blog posts that load 10 external scripts.
Earlier quoted context omitted.
1. The article omits liberally. 2. The spec details situations where the tag may be omitted. 3. None of these (2) apply to what's going on at (1).
Okay, let's go over this then. First, let's talk about the basic case where there's no whitespace between the two paragraphs. Paragraph 1 Paragraph 2 In this case, the first can be omitted according to the rule "A p element's end tag may be omitted if the p element is immediately followed by an [...] p [...] element [...]", resulting in this code: Paragraph 1 Paragraph 2 If we assume that the body ends immediately af…
But it does render that extra whitespace (as a single space). Try selecting the text of the article and you see there is a trailing space after every paragraph.
While I'm no big fan of SEO and all that surrounds it: Will this open-tag-thing here influence how crawlers handle your site and index/rank it?
I don’t expect it to as long as the mark-up is valid. Perhaps someone with more SEO knowledge will stop by to correct me.
Earlier quoted context omitted.
Obnoxiously bad take. > Google info boxes[...] have nothing to do with the semantic web and everything to do with Google throwing a crapton of machine learning and humans at the problem of parsing distinctly non-semantic HTML until they cracked the problem This is verging on /r/SelfAwarewolves material.
I'm pretty sure you're misinterpreting it. Google did not simply write a web scraper that pulls a or a tag out of the web. They wrote a web scraper that super, super intelligently examines the HTML and looks for "anything that looks like business hours"; maybe it's in a table, maybe it's days of the week separated by and , maybe it's in s or s with suggestive CSS class names, maybe it's just in a pile of other…
You should be more sure of the things you're pretty sure of before saying you're sure of them.
There was no misinterpretation—from this end, that is. Your comment wasn't particularly sophisticated. It didn't require explanation.
> Google did not simply write a web scraper that pulls a or a tag out of the web. They wrote a web scraper that super, super intelligently examines the HTML and[...]
No shit. The value proposition of the semantic web follows from how the world would be much better off if that weren't necessary. It has always been the case that, without the "semantic" half of "semantic web", attaining Google-level mastery over the Web's messy inputs is really, really difficult and requires Google-level resources. This isn't news. Yet you presented it as if it were in insightful observation wrapped in sage wisdom.
In your attempt to "prove" by counterexample what's Wrong with the semantic web, you just end up undergirding its very premise.
> Which is why it is bizarrely unselfaware when Semantic Web advocates almost inevitably cite that as their biggest success.
You cited them. You are literally the only person who mentioned them here, at all. You brought them up.
Saddling someone who advocates for X with the burden of defending position Y that you yourself have pulled from thin air is a textbook example of a bad argument. If you defeat some easily take-downable opponent (a 6-year-old, let's say—and one who is made of straw, for good measure) and then plan to enter the ring in subsequent matches having only bothered yourself with the thought that you will face the threat of another strawchild, that's not wise. It's stupid.
Earlier quoted context omitted.
I don’t expect it to as long as the mark-up is valid. Perhaps someone with more SEO knowledge will stop by to correct me.
You're right. HTML5 does not work with DTDs anymore, so unclosed tags are not a violation of the document schema and therefore probably not "punishable" by search engines.
Earlier quoted context omitted.
Well this sounds like really interesting observation. May I ask where exactly were the original closing tags located and how the stripped source looked like? I can imagine there _might_ be some differences among differently formatted code: e.g. I'd expect Content Content[EOF fig1] to be (slightly) slower, than Content Content [EOF fig2] (most likely because of some "backtracking" when hitting ` ]`), or Content Conten…
It was just paragraphs of text. p, strong, em, and q mingled at most. No figures or images or anything of the like to radically shift DOM computations. That the effect can even be seen is probably due to the scale of the document, as I noted it's a little larger than most things. All paragraphs had a blank line between them, both with and without the p end tag. The p opening tag was always at the top-left, with no ga…
..` -> `..
..`), however such minification seems like a nuisance.)
Tested only on Windows, in browser consoles.
Numbers:
Firefox (Nightly) (performance.now is clamped to miliseconds)
total; median; average; snippet
2279.0; 4.0; 4.558; '_'
2652.0; 4.0; 5.304; '
_
'
2471.0; 4.0; 4.942; '_abcd'
2387.0; 4.0; 4.774; '
_\n'
3615.0; 5.0; 7.230; '
_
\n'
2380.0; 4.0; 4.760; '_abcd\n'
3093.0; 5.0; 6.186; '
_\n
\n'
3107.0; 5.0; 6.214; '_
\n\n'
2317.0; 4.0; 4.634; '_abcd\n\n'
2344.0; 4.0; 4.688; '
_\n\n'
total; median; average; snippet
2870.4; 5.2; 5.741; '_'
2895.2; 5.4; 5.790; '
_
'
2684.7; 5.2; 5.369; '_abcd'
2845.4; 5.2; 5.690; '
_\n'
3836.7; 7.3; 7.673; '
_
\n'
2837.8; 5.2; 5.676; '_abcd\n'
4022.5; 7.4; 8.045; '
_\n
\n'
4044.3; 7.3; 8.089; '_
\n\n'
2928.4; 5.2; 5.857; '_abcd\n\n'
2805.3; 5.2; 5.611; '
_\n\n'
Snippets per document: 5000
Rounds: 500
Wrap: '(items-paragraphs)'
Content each item (_): bunch of random digits chunks, something like '1943965927 52 27 5 51664138859173 5161 7226 5 15 2 55679 6553712585'
(Before realizing I can use synthetic domparser I made something what measures document load time in iframe (http://myfonj.github.io/tst/html-parsing-times.html) but it gives quite unconvincing results, although probably closer to the real world. Understandably, synthetic domparser can crunch much more code than visible iframe.)