[HN Gopher] My Current HTML Boilerplate
___________________________________________________________________
My Current HTML Boilerplate
Author : adrian_mrd
Score : 976 points
Date : 2021-04-27 06:04 UTC (16 hours ago)
(HTM) web link (www.matuzo.at)
(TXT) w3m dump (www.matuzo.at)
| jayd16 wrote:
| >because it's a vector and not raster image, and we can add HTML
| and CSS to the SVG, which means that we can support dark mode.
|
| Doesn't work with the black chrome theme though, it seems. Can't
| see the icon at all because they gave it no outline.
| mlang23 wrote:
| +1 for the natural language tag. Remember to actually update it
| to the language used on the site. I regularily stumble across
| pages with a wrong language declaration. You pretty quickly
| notice this if you rely on a speech synthesizer to read the page
| content to you. Just a small change which can make such a big
| difference :-)
| dheera wrote:
| Why can't the speech synthesizer detect the language,
| especially when the language of dynamic content may change on
| the client-side after the page is loaded?
|
| Language detection is much easier than synthesis, and one would
| think that a good synthesizer would devote the 0.1% of their
| engineering time necessary to have good language detection as
| well.
| mlang23 wrote:
| Surprisingly, automatic language detection isn't always
| reliable. And since the DOM actually has an attribute for
| this, which can also be placed on individual elements like a
| p or div, the first choice IMO is to rely on what the site
| declared.
| harperlee wrote:
| Yeah in general, explicit declarations should not be
| overriden by guesswork!
| sswam wrote:
| It seems to me that correctly guessing a natural language
| is a whole lot easier than speech synthesis. I think it
| would be more common to have incorrect declarations than
| detection failures. A bit like how comments describing
| code are often incorrect because they weren't updated
| when the code changed.
| harperlee wrote:
| I wonder the same about Microsoft Word and Powerpoint. Is it
| so difficult to guess language in 2021? Particularly, to
| discern language between spanish and english, if both have
| already been manually set by the user in the document? It
| seems so...
| naniwaduni wrote:
| People _routinely_ manage to have "manually set" the
| language of documents that are very not English to en-US.
| Mauricebranagh wrote:
| Bing also uses it for geo targeting I had not thought about
| accessibility and speech synthesisers - I will add that to our
| Guidance for developers.
| [deleted]
| busymom0 wrote:
| Slightly related note, if you are a web developer, I would highly
| recommend reading this long read on "How to Section Your HTML".
| This is especially important if you want your site to function
| correctly when screen readers are used for accessibility
| purposes. I would pretty much give 100% credit to this article
| which helped me go from a newbie on HTML design to knowing how to
| correctly structure it:
|
| https://css-tricks.com/how-to-section-your-html/
| [deleted]
| rnhmjoj wrote:
| Something worth mentioning if you're using color schemes:
| chromium has a "Force dark mode" option that inverts the colors
| of light pages to make them dark. This used to play well with
| color schemes: normal page - inverted, page with prefers-color-
| scheme: dark - use dark theme. Of course they managed to break
| it: for some reason (but it's not a bug!), new chromium versions
| always choose the light theme and invert it, even if the page
| declares it has a dark theme, which is not nice.
|
| They only way to make chromium in dark mode use the CSS color
| schemes is to add the meta tag: <meta
| name="color-scheme" content="dark light">
|
| This is also useful on other browsers: for example, it will make
| safari choose dark/light UI elements (buttons, dropdowns, etc.)
| depending on the color-scheme preference.
| vanderZwan wrote:
| Tangent:
|
| > _I totally forgot about print style sheets_
|
| You know who else seems to have forgotten about print style
| sheets, at least for a while? Wikipedia. Or maybe they didn't do
| anything and it was browser support that got worse for a while, I
| dunno, I shouldn't be too quick to assign blame to a specific
| party here.
|
| All I remember is that years ago, if I clicked the "print page"
| link I would get a nicely styled printable version with minimal
| markup. It was a great way to get a "light markup" version of the
| page before browsers had built-in "reader view" tools.
|
| Then for a while it just gave me a terrible1 webpage version -
| basically showing the left menu bar and the huge logo when trying
| to print the page. Now it seems to have print style-sheets again,
| but with a "no longer supported" warning when used on a screen
| (not visible when printing though). See and compare:
|
| https://en.wikipedia.org/wiki/CSS
|
| https://en.wikipedia.org/w/index.php?title=CSS&printable=yes
|
| 1 terrible _in the context of printing_ , I'm not hating on the
| regular webpage here
| runiq wrote:
| It's using media queries now, so you can use the browser's
| default printing function instead of having to find a bespoke
| button for that functionality.
| jakub_g wrote:
| Must-have extension to use before printing anything:
|
| https://addons.mozilla.org/en-US/firefox/addon/aardvark-duex...
| (based on https://www.karmatics.com/aardvark/ which is a
| bookmarklet hence does not work with Content-Security-Policy
| enabled pages)
|
| It allows to easily and quickly remove stuff from webpages,
| without opening devtools. Just hover over unwanted element,
| keep clicking `w` (wider) until you have its whole container,
| then `r` to remove.
| vanderZwan wrote:
| Oh wow, that _is_ a really useful extension, thank you!
| zokier wrote:
| I feel you are bit confused what print stylesheets are? They
| are exactly the opposite of having special version of the page
| for printing, and instead just restyling the same page for
| different media. That is why the printable=yes page is "no
| longer supported" in wikipedia, because it doesn't need a
| special printable page anymore, it can use just print
| stylesheet on the normal page instead.
|
| This is what the print style looks on screen on Firefox on my
| computer: https://ibb.co/QN6Gsjk
|
| Pretty decent if you ask me. Sure, technically its not separate
| stylesheet in Wikipedias case, but media queries, but the
| effect is the same.
| vanderZwan wrote:
| I think you missed this sentence while reading my message:
|
| > _Then for a while it just gave me a terrible webpage
| version - basically showing the left menu bar and the huge
| logo when trying to print the page._
|
| That is to say: trying to print the page in any way (clicking
| the "print page" link, using the browser menu) resulted in a
| webpage-styled output.
| nlitened wrote:
| I like how the author says "we don't need these and these things
| because latest versions of X don't require it anymore" -- well
| what about people who don't use the latest versions of X?
| Daegalus wrote:
| time to upgrade?
| skrebbel wrote:
| I think the argument that most X'es are self-updating browsers.
| I'm not sure how valid that is, but it seems to me that you
| need to do active effort to be eg on Firefox 70 today.
|
| The big non-self-updating X is IE11 which the author addresses
| separately.
| davewasthere wrote:
| Well, it's perfect readable in lynx & IE6.
|
| I think for the most part, it's a pretty reasonable selection
| of tags. And there's almost no excuse to keep crazy old stuff
| around these days.
| tsujp wrote:
| I've never thought to do something like this as a way to detect
| whether or not js is being used. <html
| lang="en" class="no-js"> ... <script
| type="module">
| document.documentElement.classList.remove('no-js');
| document.documentElement.classList.add('js'); </script>
|
| It's so simple but so effective. Will be copying that.
| blauditore wrote:
| I think this is the most obvious way, no? What approach did you
| use before?
| illumanaughty wrote:
| Simple =/= Obvious.
| faitswulff wrote:
| Hmm, why bother even having the no-js class, then?
| [deleted]
| Cederfjard wrote:
| Because you can target it with CSS and apply styles specific
| for when the document is viewed without JavaScript enabled.
| faitswulff wrote:
| Is it too much trouble to just override the base style with
| the js style? As in, don't specify the base style with "no-
| js" at all, just the js overrides.
| mikepurvis wrote:
| Complicates the base case if you need to undo in it any
| unwanted styled applied in the no-js case.
|
| Conceptually it's a lot easier to manage if they're fully
| distinct, or at least if the common bits are explicitly
| common.
| deckard1 wrote:
| most websites are going to be JS-first. If it makes sense
| for you to augment your site with JS, then sure knock
| yourself out and reverse it.
| contradistinct wrote:
| If javascript isn't running in the browser, the script won't
| run and the class won't change from no-js to js.
| dan1234 wrote:
| I first saw that technique used by Moderinizr, which was a very
| useful tool back in IE8 days!
|
| https://modernizr.com/
| jojohohanon wrote:
| There was a post on Metafilter highlighting a similar
| approach to graceful javascripting, back when javascript was
| a question, not an answer.
|
| Basically, serve a page with formatting done via table
| layout, and then rewrite it with javascript in the client to
| use more modern layout tools, depending on which features
| were available on the browser.
| ok123456 wrote:
| What's wrong with using modernizer now?
| frereubu wrote:
| As long as you don't have to deal with IE11, cross-browser
| support is much better, partially due to fast release
| cycles. No point including a whole library if all you want
| to do is detect whether JS is enabled.
|
| Edit: To be clear, Modernizr isn't a big library like
| jQuery and you can specify the thing you want to detect, so
| you can cut it down, but it's still pointless if you just
| want to know if JS is enabled or not.
| _-o-_ wrote:
| Browser landscape changed, absolute majority of users are
| on one of the evergreen browsers with almost identical
| feature set.
| gerardnll wrote:
| Website is unmaintained, check the Github repo for the
| lastest version.
|
| https://github.com/Modernizr/Modernizr
| tiborsaas wrote:
| There's even a <noscript> tag since HTML 4.01. You can apply
| CSS to it too.
| chrismorgan wrote:
| <noscript> is a blunt instrument that isn't anywhere near as
| useful as you think it is.
|
| <noscript> is pretty much a feature of the HTML parser. It
| disappears. The DOM representation doesn't include a
| <noscript> element, so you can't style it. (This is also why
| you can't use <noscript> in the XML syntax of HTML. If you
| don't know about the XML syntax, I'll simplify and say it
| roughly means what was commonly called XHTML.)
|
| What makes it even less useful is that the absence of the
| <noscript> content doesn't mean that your scripts are being
| executed. If you use something like uMatrix or uBlock Origin
| to block certain types of scripts, for example, you might
| find that none of the scripts execute, but that the
| <noscript> content is also not loaded, because it _could_
| have executed some scripts, if the right URLs had been
| requested. Or perhaps the browser was happy to execute
| JavaScript, it's just that it failed to fetch the JavaScript,
| for whatever reason. (Perhaps you put your JS on a CDN, on a
| different origin, and it's down.)
|
| In the end, the .no-js approach is far superior to the use of
| <noscript>.
| tiborsaas wrote:
| You CAN style stuff you put in <noscript>.
|
| Of course, if your app breaks because of browser
| extensions, you should handle errors gracefully, but that
| goes beyond the no-js classname.
|
| I just posted this since I haven't seen it mentioned and
| it's fairly useful.
| thesuitonym wrote:
| >Of course, if your app breaks because of browser
| extensions, you should handle errors gracefully
|
| Web developers don't do graceful degredation anymore.
| chrismorgan wrote:
| > _You can apply CSS to it too._
|
| I read that as "you can apply CSS to a <noscript> tag",
| which is false. Stuff _within_ it, sure. But the
| <noscript> tag itself vanishes during document parsing.
|
| I maintain my position: <noscript> is nowhere near as
| useful as it first appears, and should seldom be used.
|
| I would even suggest that, excluding spiders, user agents
| that don't run some or all JavaScript will _normally_ be
| due to browser extensions. This is a fairly niche area
| overall, and various extensions are the main factor.
| ChrisSD wrote:
| I think you're talking past each other.
|
| To be clear, the noscript tag "disappears" when
| javascript is enabled in the browser. When javascript is
| disabled it behaves like any other tag and can be styled
| accordingly.
|
| Extension can disable scripts selectively but in that
| case javascript is still considered enabled for the
| purposes of the noscript tag.
| FlorianRappl wrote:
| > But the <noscript> tag itself vanishes during document
| parsing.
|
| This is wrong. In case the browser does not have JS
| (enabled) its a normal element.
| megous wrote:
| Yes, you can see it in the dev tools/inspector.
| theandrewbailey wrote:
| In uMatrix, there is an option "Spoof <noscript> tags when
| 1st-party scripts are blocked" that shows <noscript>
| content.
|
| edit: uBlock Origin shows <noscript> when the entire site's
| JS is disabled.
| stedaniels wrote:
| Not to bring you down, but to let anyone else know, this isn't
| novel and has been standard practice for a decade or so.
| dt3ft wrote:
| > "To let everyone know, this is not novel"
|
| Who asked?
| RONROC wrote:
| "Not to bring you down, and not adding anything useful
| here, but..."
| nsonha wrote:
| It is kind of useful. I'm trained to feel dubious of
| anything newly invented if the underlying elements of the
| solution have been there for 2 decades (there must be
| some reason people didnt do it that way then). If this is
| existing practice then it sounds right.
| [deleted]
| acdha wrote:
| It's not novel but consider how unproductive your attitude
| is. Someone was excited about learning something new, and you
| took a massive dump all over it, with no benefit whatsoever.
| If you're upset that not everyone knows everything, you
| should be working to cultivate that excitement!
|
| https://xkcd.com/1053/
| elaus wrote:
| The technique as it isn't new of course, but I doubt this
| specific implementation (checking for module-supporting JS)
| is standard practice for a decade.
| [deleted]
| greggturkington wrote:
| This _doesn 't_ check for "module-supporting JS"
|
| > [not] for a decade
|
| Agreed, probably longer. How old is Modernizr?
| _0o6v wrote:
| No it hasn't
| nathell wrote:
| I won't. Under my definition, it causes the page to stop being
| a document and start being an application. Being able to detect
| JS can be useful sometimes, but, to me, it doesn't belong in a
| boilerplate.
|
| http://blog.danieljanus.pl/2019/10/07/web-of-documents/
| cjohansson wrote:
| "You can't argue with popularity. Well, you could, but you'd
| be wrong!" - Robbie Williams
| weird-eye-issue wrote:
| The web is moving on without you.
|
| Edit: Your blog doesn't even use SSL...
| spookthesunset wrote:
| The "documents not applications" battle is like 10 years
| old at this point. The web moved on a decade ago...
|
| I've had the "how to deal with folks who disable
| JavaScript" discussion for well over 10 years and the
| answer in every shop I've worked in has always been the
| same... don't bother. And it was the developers themselves
| making that call, not the "business people".
| weird-eye-issue wrote:
| Yeah I was being nice. It moved on so long ago I'm not
| sure how he calls himself a developer. Okay there... I
| said it.
| milkey_mouse wrote:
| Sometimes "the industry" "moves on without" a valuable
| perspective. That doesn't mean those "left behind" (e.g.
| Richard Stallman) should give up. Something something
| "marketplace of ideas."
|
| But yeah, GP, get a Let's Encrypt certificate for the sake
| of your readers!
| nashashmi wrote:
| OT :
|
| What http site is left we can go to when isp or WiFi
| greets with a welcome login page. Going to https sites
| gives an error.
| depressedpanda wrote:
| http://example.com/
| ziml77 wrote:
| http://neverssl.com or
| http://detectportal.firefox.com/canonical.html
| krazerlasers wrote:
| You are welcome to use my site: http://krazerlasers.com
|
| You are also welcome to use my html boilerplate:
| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
| Transitional//EN"
| "http://www.w3.org/TR/html4/loose.dtd">
| <html><head> <meta http-equiv="Content-Type"
| content="text/html; charset=ISO-8859-1"> <link
| rel="stylesheet" type="text/css" href="blue-white.css">
| wnevets wrote:
| I've also used something like this for Internet Explorer 10
| detection.
| twic wrote:
| I use: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML
| 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
| <html> <head> <title></title> </head>
| <body> <h1></h1> </body>
| </html>
|
| And according to the file timestamp, have done so since Nov 24
| 2005.
| JCVI-syn10 wrote:
| Wow, I haven't seen an HTML 4.01 doctype in ages.
|
| Your boilerplate lacks all the features of this one...
| chrismorgan wrote:
| For comparison, this would achieve the same thing now and is
| much shorter and more memorable: <!doctype
| html> <title></title> <h1></h1>
|
| (My recollection is that the HTML 4.01 Strict DTD doesn't
| trigger quirks mode; if that's correct, then it should be
| precisely the same, except for whitespace variation and the
| actual doctype node. Also neither is valid, because the title
| element can't be empty.)
| bloak wrote:
| This is the shortest thing starting with that doctype that I
| can get validator.w3.org to accept without error or warning:
| <!doctype html><html lang=""><meta
| charset="UTF-8"><title>x</title>
| aparks517 wrote:
| You may be able to use a UTF BOM instead of the meta tag,
| or I think someone mentioned elsewhere having the server
| declare the character encoding in a header. I guess it
| depends on whether you count the header size which is
| better for golfing.
| chrismorgan wrote:
| The ="" there is unnecessary; writing an attribute name
| only implies an empty value.
|
| If you're going for shortest valid document at all,
| <!doctype html> is enough, provided the document exists in
| a context that makes title optional (e.g. email or <iframe
| srcdoc>) and that the charset is declared out-of-band.
| twic wrote:
| I fill in the title and h1 elements - this is just the
| template. And this version is not precisely the same, because
| it can't have the same timestamp :).
| hawski wrote:
| I expect this to become a thread of people sharing their
| preferences. I prefer something minimal, that I can almost
| remember and write by hand: <!DOCTYPE html>
| <meta charset=utf-8> <meta name=viewport
| content="width=device-width,initial-scale=1"> <style>
| body{ font:menu;font-size:1.125em; margin:auto;max-
| width:40em; padding:0 0.5em 90vh 0.5em; }
| </style>
|
| I don't use html, head and body tags and I don't close tags that
| don't need to be closed like p. With this html is almost like
| markdown.
|
| I use this bottom padding, because I like to scroll all the way
| up and it also is useful if you have low anchors for one to see
| on top what was supposed to be there.
| conaclos wrote:
| I prefer a parser-friendly template that makes Web Scraping
| easy. My template [1] is both parsable by HTML5 and XML
| processors.
|
| [1]
| https://github.com/Conaclos/origin.html/blob/master/template...
| megous wrote:
| s/"ttp"/http"/
| conaclos wrote:
| Fixed. Thanks!
| lrem wrote:
| <meta name=viewport content="width=device-width,initial-
| scale=1">
|
| Excuse my ignorance: what the heck does this achieve?!
| ohazi wrote:
| It's an incantation to make the page look slightly less
| stupid on a phone.
|
| https://www.w3schools.com/css/css_rwd_viewport.asp for an
| example image
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Viewport_m... for more detailed info
| SahAssar wrote:
| It sets mobile browsers use actual widths and not emulate
| desktop width.
| la_fayette wrote:
| it is not exactly the actual width of the device, but the
| default viewport width, given in CSS pixels. E.g. for the
| iphone 6 it is 375 pixel, although the physical width is
| 750 pixel...
| SahAssar wrote:
| Yeah, but the same is true for desktops/laptops that use
| scaling. I think that people are used to the fact that 1
| render pixel does not always equal 1 physical pixel.
| hawski wrote:
| So the html looks as god intended on mobile devices. It
| became necessary, because web pages squeezed to mobile sizes
| were looking terrible with all those sidebars bent and
| excessive padding and margins. So Apple (I believe it was
| them) made this workaround, by default your phone renders
| pages scaled, like it's a window to your desktop computer's
| maximized browser. Then it looked good. But what about pages
| that are responsive or just look good no matter the window
| size? That's the line that needs to be there.
| enriquto wrote:
| if you remove all css it looks good again on mobile devices
| hawski wrote:
| Thanks! I didn't know about this, but it does make sense.
| Is there a way to limit the max-width of text without
| CSS?
| dheera wrote:
| > <meta name=viewport content="width=device-width,initial-
| scale=1">
|
| This is a cat and mouse game. iOS 14 doesn't respect user-
| scalable=no or maximum-scale, unfortunately.
|
| What you need to do is this now, if you don't want the web
| browser to respond to scaling (and as much as the idiots at
| Apple love their high horses, there are actual use cases for
| this, including when you are building a webapp or when you are
| building a web page with your own pinch zoom logic):
| <meta name="viewport" content="width=device-width, initial-
| scale=1.0, maximum-scale=1.0, user-scalable=no">
| <style>body { touch-action: pan-x pan-y; }</body>
|
| Basically, Apple tries hard to break HTML5 apps at every new
| iOS release.
| austinjp wrote:
| Thanks for this, is it backwards compatible with previous
| versions of iOS? Or is there some combination of incantations
| that does graceful degradation?
| hvdijk wrote:
| Are you surprised? If every damn website out there starts
| copying and pasting the same thing regardless of whether it
| makes sense, and it makes the iOS user experience worse as a
| result, of course they're going to change things. Their
| priority should be their users. It sucks for those that
| actually have a valid reason for it but there's no way to
| separate those automatically.
| sgc wrote:
| The OS or browser should not just take over one of the
| primary means of interacting with an app and effectively
| disable it for any other use. You might as well just pull
| those gestures out of the specs at that point. The point of
| an os or browser is to get out of the way, not be
| omnipresent. It's extremely patronizing and cripples
| important functionality for likely millions of sites.
| KingOfCoders wrote:
| At what point do they think my English "makes the iOS user
| experience worse" and change the text between two <div>s?
| dheera wrote:
| The problem is the OS zooming fights against pinch zooming
| that you may implement inside your webapp's logic,
| especially for non-static content (maps for example),
| multi-finger games where two touches don't signify a zoom,
| etc. They just broke the UX of a whole bunch of websites.
|
| When will we ever have HTML5 apps that match native apps?
| When they actually let HTML5 apps do what native apps do,
| like multitouch without triggering a default action.
| hvdijk wrote:
| No, that's not the problem. Remember, developers are a
| minority, users are the majority, so making things work
| well for users takes priority over making things work
| well for developers. When functionality that's useful for
| webapps is misused for websites where it has no place and
| where it breaks the user experience, the only way to
| improve things for users is to make things harder for
| developers.
| bryanrasmussen wrote:
| developers make the things the majority use, if you make
| things worse for developers they have a harder time
| making things that work well for the user, when that
| happens they will look to misuse functionality to improve
| things for their users. The only way to improve things
| for users is to make things easier for developers.
| hvdijk wrote:
| There are good developers who try to improve things for
| their users. There are also many developers who don't and
| ruin it for the rest.
| KingOfCoders wrote:
| Do they earn 30% from HTML5 apps?
| ericbarrett wrote:
| > iOS 14 doesn't respect user-scalable=no
|
| Best change made in Safari in a long time. My eyesight is
| going and unzoomable websites were a serious accessibility
| issue.
| dheera wrote:
| At the same time, they created accessibility issues on lots
| of other websites. Games that need multitouch, photo
| galleries that implement their own pinch zoom and
| progressive higher res image loading logic, and lots of
| other things.
| anoncake wrote:
| Then websites just cannot use that feature. Zoom is
| necessary for accessibility, period. Being able to
| implement games as websites isn't. If you want to control
| the UI, write an app.
| hnedeotes wrote:
| I'm not even arguing if zoom is or not necessary but this
| kind of thought doesn't make sense for me anywhere else
| than when a feature can compromise a user device.
|
| If a website borks its usability/accessibility you as a
| user can decide not to use it. If it's a public service
| or a company there will be for sure pressure for it to
| conform to whatever accessibility standard is deemed
| appropriate. Developers in those situations will have to
| do the work they are hired to do.
|
| Now saying that I should not as an independent developer
| customise certain behaviour or appearance in a browser
| (say scrollbars, or many others) to appease that
| arbitrary accessibility doesn't make sense. If I can't
| build a certain app (due to arbitrary constraints that
| have no security implications) then its accessibility is
| effectively reduced to 0 isn't it?
|
| If I, as an idiot, want to build a website that screen
| readers won't be able to parse or will spew lines of
| William Shake-s-pear as image alt tags, isn't that my
| choice and am I not able already to do so?
|
| As such, if I for instance wanted to write a game in a
| browser where some of these things are detrimental, and
| just can't because, no, accessibility, what does that net
| any one?
|
| This patronising "we know better everything" is sincerely
| annoying.
| maple3142 wrote:
| But not everyone wants to give money to apple to be able
| to deploy their apps, so the "sensible" way is to use
| hacks[1] to have a normal html5 behavior.
|
| [1]: https://stackoverflow.com/q/37808180/6885801
| Spivak wrote:
| I'm sympathetic to the argument that you shouldn't have
| to pay to play on iOS devices but that doesn't mean that
| the browser has to cater to every possible use-case
| _especially when that use-case hurts accessibility_ for
| almost all real web pages if used.
|
| If you give web developers any way to disable zoom they
| will disable zoom whether it's appropriate or not. With
| an app that gets human reviewed you can make rules like
| "this feature can only be used for full-screen games" but
| not on the web where there's one set of rules for
| everyone.
| dheera wrote:
| No, it's shitty developers that hurt accessibility. There
| are so many other worse ways to wreck accessibility than
| disabling zoom, including popup modals, grossly large
| banner ads, JS that consumes CPU and huge amounts of
| bandwidth, supporting only English, putting text in
| images without alt text, hard-to-read font choices, and
| so on. People do all of the above. There are good devs
| and crappy devs. If a website is made by crappy devs it
| will naturally lose reader interest.
|
| There are actual accessibility reasons for wanting to
| take control of pinch zoom behavior. As long as I'm
| actually catering to accessibility, if I have to be
| forced to use the OS pinch zoom to do that it's going to
| be LESS accessible. The OS pinch zoom only works for text
| and static 2D images and nothing else. If you try to OS-
| pinch-zoom a 3D object on a web page, it zooms the whole
| UI and not the object. That's a major accessibility
| problem for say a website that offers 3D models.
|
| And no, I don't think "create an app" is the answer as
| another comment said. I want LESS apps, LESS spyware, and
| more in-browser, fully-featured, perfect mobile
| experiences designed in HTML5 because it's MUCH harder to
| invade privacy with HTML5 than it is with a native app,
| and if Apple would stop compromising HTML5 features, a
| huge number of mobile apps can be implemented in it.
| mvanbaak wrote:
| This! The whole movement of making webpages do all the
| things apps can do...
| megous wrote:
| That's what I tell iOS users that complain that page
| zooms in if they tap too fast on a button adding items to
| cart. It's for their own good, and they can thank their
| overlord - Apple.
|
| Not zooming in when doing stuff unrelated to intent to
| zoom, is just not in their interest as determined by
| Apple.
| pjc50 wrote:
| Perhaps one of those features which should have been made a
| toggle, but yes: pinch-zoom is an essential feature which all
| sorts of sites were disabling for no good reason, and so this
| toy gets taken away from everyone. This kind of tragedy of
| the commons stuff is why we can't have nice things on the
| web.
| Mauricebranagh wrote:
| Erm WTF your going to have problems using things like GTM and
| GA for a start.
|
| Just blatantly breaking standards like this is not a good idea
| seen some real howlers from sprint back when I worked on x.400.
| Symbiote wrote:
| Not using either of those things sounds like a benefit.
| Mauricebranagh wrote:
| Yeh want to justify your ROI you will :-)
|
| And using GTM instead of hand coding every thing is a win
| megous wrote:
| No standards are broken here. Maybe you can bother to read
| them:
|
| https://html.spec.whatwg.org/#optional-tags
|
| There will also be no issue including GTM/GA or other
| scripts.
| hawski wrote:
| W3C HTML5 validator will issue a single warning for not
| having an openning html tag with the lang attribute. Other
| than that there are no errors. It is not breaking any
| standards. As sibling commented I would just add the html tag
| with the lang attribute.
|
| I don't use GTM or GA or almost any JavaScript whatsoever.
| Thainbbdl wrote:
| While not closing tag or using head / body element is a matter
| of taste, not using the HTML element with a proper lang
| attribute and missing the title element can lead to
| accessibility issues.
| hawski wrote:
| I guess you're right. The lang attribute is useful. I'll add
| it to my personal template.
|
| I omitted the title, but it's a part of the content for me.
| This way I can use the simplest SSG there is: cat.
| jfk13 wrote:
| > font:menu;font-size:1.125em;
|
| As a default for otherwise-unstyled content, it's not very
| user-friendly to override the user's default font and size
| preferences.
|
| The browser lets _me_ decide how I 'd like unstyled text to
| appear. Unless you're explicitly doing typographic design,
| please don't arbitrarily override my choice.
| hawski wrote:
| I hear you. But this battle is lost for a long time, isn't
| it? You already know, that if you allow CSS things will
| happen.
|
| I would personally not do this if browsers would have
| sensible defaults, but IMO they don't. Mostly it is a matter
| of backward compatibility.
|
| Also I'm using font:menu so theoretically the same as your
| browser is using. Depending on your browser/OS you can change
| the font for all, not ideal, but doable. Similar to how every
| browser has different settings for your preferred fonts. But
| in Firefox for example you can deselect "Allow pages to
| choose their own fonts, instead of your selections above" and
| you're done.
|
| I'm saying all this as a person wanting to implement a modern
| html-only browser to make all those obnoxious stylesheets go
| away.
| easrng wrote:
| You should use system-ui, sans-serif to avoid abusing the
| semantics of menu.
| jfk13 wrote:
| I don't see why you'd think font:menu is appropriate for
| the general body of web content. Menus are a UI element
| that normally contain just a few isolated words or very
| short phrases. Recognizing words in such a context is not
| the same as reading textual content on a page. A font
| chosen for one may not be well suited to the other.
|
| If your issue is that many browsers default to a serif
| font, and you really dislike that, maybe setting font-
| family:sans-serif would be better? At least that's intended
| to be suitable for content, rather than UI.
| SquareWheel wrote:
| No box-sizing: border-box?
| hawski wrote:
| I'm not doing anything complex enough for it to matter.
| greggturkington wrote:
| Like using margins or padding?
| thanatos519 wrote:
| Why are the non-container elements like 'meta' and 'link' not
| terminated with '/>'? Did I miss a memo?
| chrismorgan wrote:
| The HTML serialisation doesn't do self-closing tags. A trailing
| slash does _precisely nothing_ : the parser just skips it. It's
| dead weight. I strongly recommend against including trailing
| slashes, because (a) they serve no purpose to the machine; and
| (b) they mislead people into thinking they mean something, when
| they don't--and indeed the _vast_ majority of cases where I see
| trailing slashes used, they're not used consistently, so some
| void tags have them and others don't (if it was used
| consistently I wouldn't mind so much).
|
| (The XML serialisation is still a thing, in various contexts.
| Serve a document with an XHTML MIME type and the XML parser
| will be used; or embed HTML in SVG via foreignObject and it'll
| be XML serialisation you need. Also note that SVG in HTML
| invokes... uhh... more XMLy behaviour from the HTML parser, so
| that the trailing slash _does_ have its XML meaning.)
| ufo wrote:
| To add to what you said: the HTML specification has a bunch
| of rules to say how to parse a tag that doesn't have a
| matching close tag. These grew organically based on how
| browsers responded to malformed documents. At some point the
| rules were enshrined in the HTML specification.
|
| Some tags such as <meta> and <img> are always considered as a
| leaf node ("void element"). The HTML parser knows that these
| tags cannot contain other tags.
|
| Other tags, such as <p> or <li> have various rules saying how
| to automatically insert a closing tag if it's missing. For
| example, if you leave out the </li> tags in a list the HTML
| parser will parse it as if you had closed all the list items.
| <ul> <li>first </li>second
| </ul> <ul> <li>first</li>
| </li>second</li> </ul>
|
| For these tags, what ends up happening if you try to use the
| XML self-closing notation is that the "/>" is ignored and
| then the missing close tag is inserted at a later point,
| which may or may not be where you want.
| tomgp wrote:
| yes, you don't use those in html5 (though they are required in
| things like jsx)
| Daegalus wrote:
| that hasn't been a thing since xhtml. html5 did away with />
| for tags that don't have a closing tag. like img, meta, br,
| etc.
| jontro wrote:
| xhtml was never supported by all major browsers. You couldn't
| do stuff like <div/> and get away with it.
|
| Not sure why the the self closing tags became widely used
| mjhagen wrote:
| Some editors had trouble with color coding non-compliant
| xhtml. At least that was my reason for doing it. (In the
| very early 2000s)
| progval wrote:
| > xhtml was never supported by all major browsers.
|
| Source? https://caniuse.com/xhtml says otherwise
|
| > You couldn't do stuff like <div/> and get away with it.
|
| I just tried on both Firefox and Chromium, they parse it
| properly.
| jontro wrote:
| When xhtml was popular internet explorer was a major
| blocker for using it properly. I never saw xhtml served
| with the proper content type at the time.
|
| I don't see a reason to mix html and xhtml today. It will
| only lead to problems. (I.e using self-closing tags and
| & mismatches in urls)
|
| If you use <div/> in html the browser will just ignore
| the end / See https://jsfiddle.net/sw8j9fo2/
| [deleted]
| wwweston wrote:
| > Not sure why the the self closing tags became widely used
|
| For a while adhering to the open/close conventions helped
| use tooling / libraries built around the assumptions for
| XML in dealing with HTML, maybe up through the late
| 00s/early 10s.
|
| Any utility gains there faded as HTML5 conventions and
| libraries became more solid, but I still have a bit of the
| habit, especially with <img/> & <br/>.
| _AzMoo wrote:
| 'link' and 'meta' are void elements in HTML5 and are forbidden
| to have end tags.
|
| https://www.w3.org/TR/2011/WD-html-markup-20110113/syntax.ht...
| ttt0 wrote:
| He meant terminating with '/>' like '<meta/>', not
| '<meta></meta>'.
|
| I was coincidentally checking the same thing yesterday, and
| yes, '/>' is optional.
| yoz-y wrote:
| You may still use them, they are not invalid syntax.
| thanatos519 wrote:
| Thanks, I did miss that ... probably because I don't do front-
| end development anymore.
| rsto wrote:
| As a user of wien.gv.at I want to thank you for your work. It's
| great to use a website that puts HTML first, rather than a mess
| of Javascript to render what essentially is just text.
| megous wrote:
| You can also skip the " in many places, to be even more minimal.
|
| Browsers don't follow the standard here completely, so you can
| do:
|
| <a href = /some<!--li=nk<<"&wer' >link</a>
|
| and all that garbage is parsed as is as attribute content until
| the first space or >. Only thing that terminates attribute value
| is > or whitespace.
|
| You can also use entity refs in unqoted value.
|
| That means you can use unquoted attribute values for almost
| anything that doesn't contain whitespace when writing html
| manually.
| dheera wrote:
| One more thing I do is this to prevent FOUC:
| <style>html{visibility: hidden;opacity:0;}</style>
|
| And then put this in your styles.css file: html
| { visibility:visible; opacity:1;
| }
|
| Honestly though the amount of meta tags in this boilerplate is
| ridiculous. What has the web come to? Why can't it use <title>
| for og:title? Why can't it use the favicon for apple-touch-icon?
| Why can't it use the URL for the url? Why can't we assume UTF-8
| unless told otherwise?
| hsivonen wrote:
| > Why can't we assume UTF-8 unless told otherwise?
|
| See https://hsivonen.fi/utf-8-detection/
| hutzlibu wrote:
| Because there are millions of people involved who have millions
| opinions on the topic and everyone wants their way. Thats why
| we have the bloody mess called HTML as a compromise.
|
| "Why can't we assume UTF-8 unless told otherwise?"
|
| And this I really do not understand either. I lost hours to
| restore data, that got lost in conversion from various text
| encoding formats, discovered too late.
| [deleted]
| chrismorgan wrote:
| On your FOUC preventer: please never ever do this. If your
| styles.css link tag is placed sanely (largely meaning "in the
| head"), the document won't be drawn until it's loaded or failed
| to load. If it loads successfully, the <style> tag served no
| purpose. If it fails to load, the <style> tag is now blocking
| access to the content.
|
| On the rest: I mostly agree.
|
| <title> versus og:title is commonly stupid, especially because
| consumers will tend to fall back to the <title> tag anyway
| (though in theory they should differ, with <title> normally
| including the site name, but og:title not supposed to); og:url
| and rel=canonical are even more stupid, because consumers will
| fall back to using the actual URL, so their only purpose is
| cases where the content is _actually_ found at multiple URLs.
| ("But og:title and og:url are mandatory for OpenGraph
| validity!" you say? Please, you didn't even put the prefix=
| "og: https://ogp.me/ns#" attribute on the root element. No one
| does. No one cares. And I don't think anyone cares for at least
| og:title and og:url either, though <meta
| property=og:description> versus <meta name=description> is
| uglier, and you can't even merge the two or Twitter ignores the
| thing.)
|
| Why can't we assume UTF-8 unless told otherwise? Historical
| reasons, mostly. The web is an old place. Rejoice that
| everything _new_ is done purely in UTF-8, and be comforted that
| even some of the older things are slowly shifted to a UTF-8
| default over time, as the impacts of doing so become smaller.
|
| The Apple icons are a more complicated historical mess. Be glad
| it's down to only _one_ stupid extra tag now, rather than a
| dozen or so, for each of their different device sizes. The time
| has come when they could fairly reasonably merge it back into
| icon, since they've given up on all of their fancy appearance
| of their icons.
| webstrand wrote:
| In my experience, rel="canonical" is very useful for the very
| reason that if the content gets served from a different URL,
| say an archival page or a misconfigured server, you don't end
| up with two versions of the page being indexed by search
| engines. I try to add it to every page, now, so long as I can
| determine the page's canonical URL. I've found that it saves
| me a lot of future pain, when having to deal with duplicates
| that I may not even be able to control.
| account42 wrote:
| > so their only purpose is cases where the content is
| actually found at multiple URLs
|
| Most content can be retrieved using multiple URLs - for
| example this comment section is available at both
| https://news.ycombinator.com/item?id=26952557 and
| https://news.ycombinator.com/item?id=26952557&blah as well as
| infinite other variants. Even if you only actively link to
| one version, you can't be sure no one else will fuck it up so
| rel="canonical" is useful. og:url should just default to that
| though (no idea if it does).
| megous wrote:
| Because people using default OS encodings didn't mark their
| html files with explicit encoding. And defaults were not utf-8
| for a long time. For example notepad defaults to utf-8 only
| since 2019, lol.
|
| https://techcommunity.microsoft.com/t5/windows-10/windows-10...
| lexicality wrote:
| > Why can't it use the URL for the url?
|
| Because you can have multiple URLs for the same content and you
| need a way to say "by the way if you want to link to this page
| here's the proper URL"
|
| For example, if you have example.com/blog/foo, it's possible
| that m.example.com/blog/foo, example.com/blog/foo/,
| example.com/index.php?path=/blog/foo,
| example.com/index.php?p=1234, example.com/blog/foo?textonly=1
| etc etc all point to the same blog post and in many cases you
| simply can't set up a redirect because the URL is valid.
| runarberg wrote:
| What I don't understand is if we omit e.g. the og:title meta
| tag, why can't scrapers fall back to <title>? Or if there is
| no <meta name="og:description"> why not fall back to <meta
| name="description">?
|
| Most of the pages I make are unique and supplying these
| values twice is simply redundant. My only conclusion is that
| scrapers are stupid and developers are too laze to fix it
| (which ironically casts the work on other developers as we
| now need to supply these redundant values).
| kijin wrote:
| The stupid scrapers we're talking about are major social
| networks like Facebook and Twitter.
|
| At this point I think it's more about unequal power than it
| has anything to do with developer laziness. Facebook and
| Twitter can tell others to add whatever stupid tags they
| demand, and people will comply. They can even call it a
| standard, and people will readily acknowledge it as such.
| Why change the status quo when you have the upper hand?
| aflag wrote:
| What if your style never loads for one reason or another? Isn't
| it better for the user to get the content they are after as
| soon as possible? I thought the whole point of rendering the
| page as soon as possible was to be helpful to the user, why
| disable that?
| mschuster91 wrote:
| > Why can't it use <title> for og:title?
|
| Because the <title> is often something like "My Content | The
| Example Blog", which is a redundant information on social media
| cards so you set og:title to "My Content" only.
|
| > Why can't it use the favicon for apple-touch-icon?
|
| Because the favicon usually is a 32x32 icon that is _small_ and
| only seen in the tab of the browser, whereas the apple-touch-
| icon is physically _huge_ , and so requires more resolution.
|
| > Why can't it use the URL for the url?
|
| I assume you're talking about the canonical link tag? This is
| to prevent SEO penalties - specify a canonical link and Google
| will prefer _your_ site as origin for the content over spammers
| that don 't bother setting the tag, or in case you run an old-
| school site with dedicated mobile and desktop sites (see https:
| //developers.google.com/search/docs/advanced/crawling/...).
|
| > Why can't we assume UTF-8 unless told otherwise?
|
| Historical baggage, mostly - the default charset for old
| content unless specified was either US-ASCII or its superset
| ISO-8859-1/latin1 (the HTTP/1.0 spec defaulted to US-ASCII, see
| https://tools.ietf.org/html/rfc1945 section 3.4 and the
| HTTP/1.1 spec, section 3.7.1,
| https://www.ietf.org/rfc/rfc2616.txt that defaults to
| ISO-8859-1). And there is _a lot_ of old content that would
| break if this default assumption would change.
| account42 wrote:
| > Because the favicon usually is a 32x32 icon that is small
| and only seen in the tab of the browser, whereas the apple-
| touch-icon is physically huge, and so requires more
| resolution.
|
| You can have multiple rel=icon elements with different
| resolutions or even scalable ones. Also, browser tabs are not
| the only place where the favicon is used - and definitely not
| the original one.
| megous wrote:
| > Historical...
|
| If you call 2019 history already...
|
| https://techcommunity.microsoft.com/t5/windows-10/windows-10.
| ..
| mschuster91 wrote:
| Jesus Christ
| atum47 wrote:
| I used to have a template (with css and js) that can be used as
| PWA, with offline caching and all that stuff. I copy most of the
| stuff from Google itself, but I never found their explanation
| that great. I wish there was a guide for it too
| greggturkington wrote:
| Cool, this is like https://github.com/h5bp/html5-boilerplate but
| a little worse
| edoceo wrote:
| why worse?
| greggturkington wrote:
| Is it _better_ in any way? There 's very little difference.
|
| We might not need a canonical URL, the favicon declarations
| are not needed, there's no repo...there's a reason HTML5BP is
| an industry standard.
| postalrat wrote:
| Is it the same reason create-react-app is an "industry
| standard?"
| greggturkington wrote:
| no of course not, is this your first time hearing of
| HTML5BP?
|
| There's a reason most of OP's boilerplate is copied and
| pasted from HTML5BP.
| davewasthere wrote:
| It's missing an obnoxious cookie dialog, mailing list modal
| window and multiple ads.
| 867-5309 wrote:
| they're hidden behind the script.js
| matijs wrote:
| You both made me laugh. Thanks :)
| coding_lobster wrote:
| Why is type="module" the opposite of nomodule? This isn't a real
| question... just a big ol _sigh_
| chrismorgan wrote:
| It's a way of conveniently achieving compatibility with old and
| new browsers.
|
| JavaScript is executed differently when it's a "module script"
| to when it's a "classic script" (using the HTML spec terms), so
| you want a way of preventing old browsers from executing it
| (whether they're syntactically compatible or not). Hence
| type="module", because old browsers won't execute scripts with
| the type attribute containing an unknown value.
|
| Once you have that, you commonly want to bifurcate on modules
| support, so you want a way of saying "don't execute this if you
| support modules". This can be done with feature-detection code,
| to the effect of "does it support modules? if yes, do nothing;
| if no, load the code, probably by adding another script tag
| with the correct src to the document", but this is inconvenient
| and causes at least mild inconvenience with security measures
| like Content-Security-Policy. So the solution was to put
| another attribute there that new browsers could use as the
| inverse of type="module": nomodule.
|
| Perhaps it's a big ol' _sigh_ , but as is very commonly the
| case with such sighs, they make a good deal of sense when you
| understand the reasons and history involved.
| youngtaff wrote:
| Be really interesting to understand when this actually get's
| executed <script type="module">
| document.documentElement.classList.remove('no-js');
| document.documentElement.classList.add('js'); </script>
|
| module has defer semantics by default i.e. it gets executed
| after the document has finished parsed, and I can't find
| anything in the WHATWG spec to suggest it's different for
| inline scripts
|
| Maybe inline scripts ignore module, as they do defer and
| async
| chrismorgan wrote:
| Inline <script type="module"> is executed after
| DOMContentLoaded.
|
| Inline <script> is executed during parsing.
|
| https://html.spec.whatwg.org/multipage/scripting.html#the-
| sc... gives the full details of the interactions between
| type, src, defer and async. Inline scripts are normally
| referred to as script elements where the src attribute is
| not present.
| andrewmcwatters wrote:
| Wow, thanks for that detail. That's some obscura to me.
| abbe98 wrote:
| What are the benefits of using the no-js approach over a style or
| link tag inside of a noscript element? Other than that all CSS
| can be contained in the same file.
| maddyboo wrote:
| If you wanna get real fancy, you could _replace_
| document.documentElement.classList.remove('no-js');
| document.documentElement.classList.add('js');
|
| with
| document.documentElement.classList.replace('no-js', 'js');
|
| https://developer.mozilla.org/en-US/docs/Web/API/DOMTokenLis...
| ryannevius wrote:
| But in the first example, `js` is always added, even if `no-js`
| doesn't exist.
| C4stor wrote:
| In the context of the presented html, the first line is <html
| lang="en" class="no-js"> . So, "no-js" does exist.
| umvi wrote:
| Indeed, but this is a case where you are reducing lines of
| source code in exchange for (slightly) increased coupling
| and fragility. By replacing remove/add with replace, you
| have now made an assumption that causes the replace line to
| be coupled to the html lang line where no coupling existed
| previously...
| playpause wrote:
| It's a well known convention (CTM), it's been part of a
| lot of front end application shells for years. Like other
| shells, an HTML boilerplate is somewhat expected to be a
| delicate, hand-optimised system. When it needs revising
| (which should be very rare) it should always be reasoned
| about as a whole. Its job is to bootstrap the front-end
| environment with maximum efficiency, and that means doing
| things that would be considered bad programming in
| another context.
| spookyuser wrote:
| Wow thank you, tangentially I was trying to figure out how to
| change a hidden object to visible with tailwind and this seems
| like it would be perfect for that!
| butt__hugger wrote:
| Don't use Tailwind, it's garbage.
| spookyuser wrote:
| But I like it!
| alpaca128 wrote:
| As someone not doing web development all day, to me it's
| much closer to how CSS should have been from the start. I
| still find it a bit too overloaded thanks to many years of
| piling more features on a standard that has to keep
| backwards compatibility, but that's another problem.
| craftinator wrote:
| And comments like this are why I no longer do any web
| programming.
| postalrat wrote:
| How meta
| tobr wrote:
| If you want to get _less_ fancy, and even briefer, and
| incidentally fix the (non-)issue described by ryannevius and
| umvi in the adjacent subthread, you could use
| document.documentElement.className = 'js';
| timdaub wrote:
| Time ago, I made a minimal HTML boilerplate myself. Mainly
| because nobody seems to understand what the word minimal means...
|
| Mine is truly minimal: https://github.com/TimDaub/mynimal-
| html5-boilerplate
| account42 wrote:
| > License MIT
|
| You expect people to paste the MIT license into their website
| source in order to use your "minimal" headers?
| enriquto wrote:
| Not truly minimal, it is fairly bloated due to the unnecessary
| usage of implicitly opened tags. You could get away with this:
| <!doctype html> <title>Your website: title</title>
| <h1>Title of your site</h1> <p> Here
| begins the text of this page.
|
| This is a complete, conformant, html5 document. Markdown is
| unnecessary nowadays.
| dheera wrote:
| > Markdown is unnecessary nowadays.
|
| Exactly! I personally hate Markdown. I can never remember how
| many asterisks is bold, italic, or whether images are
| [!img(src)] or !(img)(src) or  or [link](src!) or
| some other nonsense.
|
| HTML is much more consistent, limiting yourself to a subset
| of HTML keeps things very readable, and it's super easy to
| slap a stylesheet on the top and make it come to life, and
| change that stylesheet at any time.
| ZephyrBlu wrote:
| * for italic, ** for bold. This is pretty standard on the
| internet in my experience.
|
| Links are [](), but I do mess that up sometimes as well.
|
| Markdown is not inconsistent though, and I find it very
| readable.
| zimpenfish wrote:
| > * for italic, * for bold.
|
| I think something ate one of your *s. One star or
| underscore for italic; two stars or underscores for bold.
|
| > Links are [](), but I do mess that up sometimes as
| well.
|
| If you use the "remote ref" style[1], links are
| `[text][ref]` which is much easier (I remember the order
| as "this [text] points to that [ref]").
|
| [1] https://www.markdownguide.org/basic-
| syntax/#reference-style-...
| input_sh wrote:
| > I think something ate one of your *s.
|
| That's because HN supports stripped version of Markdown
| and supports italic with one *, but not bold with **. You
| have to escape it with \\.
| ZephyrBlu wrote:
| Ah thanks. I didn't notice I was missing a *.
| dheera wrote:
| I find it readable, but not that much more readable than
| plain old HTML with all styling relegated to a separate
| stylesheet, and using only the basic set of elements e.g.
| <h1>-<h6>, <a>, <img>, <p>, <pre>, etc.
|
| I find HTML far more _writeable_ than Markdown, however,
| as all things have a consistent syntax.
| BiteCode_dev wrote:
| Markdown would make it: # You website:
| title ## Title of your site Here
| begins the text of this page
|
| I do think it's easier to type.
| enriquto wrote:
| > I do think it's easier to type.
|
| I agree, but it's only marginally easier to type.
|
| But the markdown is not the final product, it still needs
| to be converted to html using a "static site generator" or
| some other thing that breaks every couple of years. I had
| my static site break due to jekyll shenanigans _four_ times
| in the last few years, and then I decided to move the whole
| thing to plain html, and replace jekyll and its myriad of
| unused and fragile dependencies with a three-line shell
| script that calls "cat". Moreover, markdown is confusing
| to use for basic stuff like links, images (see the sibling
| comment), and even enumerated lists [0].
|
| [0] https://stackoverflow.com/questions/12145232/create-an-
| autom...
|
| every dialect of markdown has an infuriatingly different
| way of doing basic things that totally breaks your soul if
| you use a handful of them at the same time.
|
| EDIT:the example you wrote is not exactly the same thing as
| mine, is it? It seems like it would convert to H1 and H2
| headings and both would be displayed in the body.
| BiteCode_dev wrote:
| I agree, and went the html road as well for a time, but I
| hit roadblocks:
|
| - When I'm in the flow, I really don't want to think
| about the structure of my text. The ms required for the
| tag insertion breaks that.
|
| - Unless you very disciplined with your HTML use, it's
| hard to get back structure from you HTML doc. You have to
| limit yourself to the subset you would get from markdown.
|
| I'm experimenting with asciidoc now, let's see if it's
| working.
| megous wrote:
| You can use style="white-space: pre-wrap" on a div, and
| deal with the structure later. You'll still be able to
| use links and images, and the text will not look like a
| turd, before you get to finishing up the structure. At
| that point you can remove the pre-wrap style.
| mro_name wrote:
| when in flow - does markup really matter then or is it
| mainly about letters and whitespace in sequence like
| text/plain?
|
| Not sure but guess for me the latter, what about you?
| enriquto wrote:
| > is it mainly about letters and whitespace in sequence
| like text/plain?
|
| The main inconvenience of writing plain html is the need
| for <p> tags. They really do break the flow! It would be
| so much better if a blank line inserted them implicitly.
| This is indeed the killer feature of markdown and TeX.
| mro_name wrote:
| just add them 'after flow' and replace /^$/ -> </p><p> ?
| BiteCode_dev wrote:
| You just wrapped your titles in <p>
| input_sh wrote:
| > Moreover, markdown is confusing to use for basic stuff
| like [...] enumerated lists
|
| This is a huge plus for me. Any list with more a dozen of
| entries and it would be tiresome to have to fix that.
| Also I can move the lines around freely without weird
| formatting issues.
|
| Links are okay in my opinion, images are just a bunch of
| crap. To make an image clickable you'd have to do an
| image within a link, something like:
| [](url)
|
| > every dialect of markdown has an infuriatingly
| different way of doing basic things that totally breaks
| your soul if you use a handful of them at the same time.
|
| Completely agree there. Extensions of Markdown are really
| annoying, but I guess that's what happens when "true"
| Markdown wasn't updated since 2004.
| nindalf wrote:
| I don't understand these complaints about breakages.
| Download Hugo. Generate your site. Now use that Hugo
| binary till the end of eternity. The Hugo project might
| add, deprecate or remove features but that won't affect
| you in any way. Your binary will continue to work till
| the end of time. (Assuming we still have x86 or ARM
| computers available)
| enriquto wrote:
| > Download Hugo.
|
| Never tried hugo, but it surely must be cleaner than
| jekyll. As a matter of policy I prefer to install tools
| packaged by my distribution. For debian, the jekyll
| package went through several "engines" and whatnot along
| the years, and _each_ change broke the build. For some
| reason it even needed particular python versions, even if
| it is written in ruby. A complete nightmare. I honestly
| lost faith in static site generators after the experience
| with jekyll. Even if hugo is saner, it is still amenable
| to breaking as its debian package evolves, and I don 't
| want to deal with that.
| nindalf wrote:
| If you care about breakage, don't rely on a package
| manager that will constantly change the package version.
| Grab the binary from the Github releases page and use it
| in perpetuity.
| enriquto wrote:
| > If you care about breakage, don't rely on a package
| manager that will constantly change the package version.
|
| I do care about breakage of my C, C++ and Fortran
| programs, and I would be very surprised if updating gcc
| broke their build (unless using -Werror). Why can't
| static site generators, which are arguably much simpler
| than compilers, have the basic property of not breaking
| sites?
| unicornporn wrote:
| Hugo has no dependency (or rather they'd baked into the
| single binary), it's just a binary and even runs on my
| shared hosting. It's the only reason I switched from
| Jekyll. I had so much trouble with Jekyll breaking it was
| unbearable. Zola is another option.
| chrismorgan wrote:
| That's quite different: # is <h1>, ## is <h2>. What you
| were responding to used <title> and <h1>. Markdown is for
| units of content _smaller_ than a page. It doesn't provide
| any means of specifying document metadata or similar.
| smt88 wrote:
| Markdown is more human-readable, easier to type, and more
| concise. Its lack of flexibility is an important feature, too
| (no JS, no styles, and only one way to make text bold).
| nindalf wrote:
| No JS? That's news to me. I added <script> tags and custom
| HTML tags in the markdown and it worked. Check the source
| of this page (https://blog.nindalf.com/posts/how-to-learn-
| unix-tools/). It contains a CSS and JS declaration not
| present on other posts because they were included in the
| markdown.
|
| Also if you want to fully commit to JS frameworks, you can.
| Some frameworks support MDX, which has full support for JSX
| tags. You can include react components right next to your
| text.
| Hedepig wrote:
| The lack of any formal specification means Markdown can
| be pretty much anything you want it to be (provided there
| a supported implementation)
| nindalf wrote:
| All markdown parsers I've encountered add tags into the
| final HTML without modification. It might not be a part
| of the standard, but it's the standard practice.
| squiggleblaz wrote:
| > Its lack of flexibility is an important feature, too (no
| JS, no styles, and only one way to make text bold)
|
| HTML has two ways to make things bold: b and strong. But
| only one way to make a toplevel heading, h1.
|
| Markdown has one way to make things bold: ** **, but two
| ways to make a toplevel heading: # or ======
|
| Other users have commented that Markdown in the wild is now
| little more than an alternative syntax for HTML, with
| scripts and other tags freely embeddable.
|
| Moreover, HTML is basically HTML: we used to have problems
| with browser compatibility, but most of those are in the
| land of CSS and Javascript now. Whereas Markdown can be
| found in different flavors. Aside from the burden on the
| author to know what flavor they are writing, it limits the
| reusability of documents. Consider a git repo that has a
| Github-flavored README.md file written for github, but it
| is also shown as part of the package documentation in a
| language specific library repository that shows the same
| README.md file using a simpler flavor of Markdown. The
| basic tags probably all work fine, but the broken CI badges
| will perhaps make it frustrating to read.
|
| HTML and Markdown both began with the best of intents as
| declarative document markup schemes. But because it is much
| harder to design a declarative programmer interface than an
| imperative one, both have accreted junk.
| smt88 wrote:
| HTML has three other ways to make things bold using CSS
|
| > _Markdown in the wild is now little more than an
| alternative syntax for HTML, with scripts and other tags
| freely embeddable_
|
| HTML is not in the MD spec. We use a WYSIWYG MD editor so
| it's not an issue.
| ravi-delia wrote:
| Markdown has broader applications than HTML though.
| Pandoc is my preferred document writing system for
| exactly that reason. Of course, when you go for the
| weirder branches of Markdown spec you'll get weirder
| results, but the documentation is fantastic, and it's
| pretty easy to stick to the golden path.
| timdaub wrote:
| Clearly you're not a front end developer.
| timdaub wrote:
| > <title>Your website: title</title>
|
| Well...
| [deleted]
| shivbhatt wrote:
| I want to convert my html website mayurbhatt.c1.biz in wordpress
| but can`t code it properly what is solution for this?
| PinkPigeon wrote:
| Might I note that you are also lacking an SSL certificate,
| which marks your site as 'not secure' and can trigger various
| anti-phishing protections in browsers and firewalls.
|
| I am not sure what you mean by 'convert wordpress', but if you
| are looking for a no-code solution for throwing up a static
| site to Cloudflare (with SSL), I happen to make a website
| builder that does just that. I like to think it's much easier
| to use than Wordpress.
|
| I won't advertise it here, but have a look in my profile if
| you're interested. Ping me for a discount :)
| shadowfaxRodeo wrote:
| Someone correct me if i'm wrong but I've been doing a bit of
| research and I'm pretty sure you can remove these:
| <link rel="icon" href="/favicon.ico">
|
| by default if a supported icon isn't found in the markup all
| browsers search for favicon.ico at the site's root.
|
| The same is true for apple touch icon, you can just remove it:
| <link rel="apple-touch-icon" href="/apple-touch-icon.png">
|
| I've tested this and it works fine on apple devices.
| <meta charset="UTF-8">
|
| By default servers add the charset as an http header. So you
| don't need to declare it in the document -- in the case of
| offline where there are no http headers, the browser works out
| what encoding to use. And since utf-8 is the only valid charset
| for HTML5 it should be the default. I've tested this a bit, and
| it seems to work.
| kijin wrote:
| > the browser works out what encoding to use.
|
| Historically, letting the browser guess anything at all has
| been a disaster. Although IE is all but dead now, there's no
| guarantee that another browser won't try something similarly
| reckless in an attempt to be a little too convenient.
| shadowfaxRodeo wrote:
| So i guess the question is -- should we keep markup for the
| case where someone downloads our webpage on a legacy browser?
|
| For me the answer is yes, if people are using an old netbook
| on a dialup connection and they save your site locally to
| save data. That could be a good idea. I'll do some testing
| though because I think even old IE defaults to utf-8.
| kijin wrote:
| The edge cases are hard to test. IIRC the weirdest issues
| had something to do with valid UTF-8 content the first X
| bytes of which also happened to be valid in some exotic
| charset related to the user's locale. English users would
| rarely come across such issues.
| hsivonen wrote:
| IE defaults to the locale-dependent legacy Windows code
| page.
| hsivonen wrote:
| > in the case of offline where there are no http headers, the
| browser works out what encoding to use
|
| For file: URLs, Firefox and, a bit less reliably, Chrome do
| work out that an HTML file is UTF-8. Safari does not.
|
| > And since utf-8 is the only valid charset for HTML5
|
| Correct.
|
| > it should be the default.
|
| It isn't. See https://hsivonen.fi/utf-8-detection/ for why.
|
| Having <meta charset="UTF-8"> in the boilerplate is good
| advice.
| j-james wrote:
| I have run into issues using KaTeX and some other rendering
| libraries without the <meta charset="UTF-8"/> tag. There are
| likely other problems that could occur without it.
| chrismorgan wrote:
| > _I 'm pretty sure you can remove these: <link rel="icon"
| href="/favicon.ico">_
|
| The presence of the _SVG_ favicon, with the same rel, may throw
| the default-finding off. I haven't tested it, but I would
| expect various older user agents that don't support SVG to fall
| over if you omit the favicon.ico link once you've provided the
| SVG link.
|
| > _By default servers add the charset as an http header._
|
| This is not true: it depends entirely on the server
| configuration. Maybe one serves `content-type: text/html`,
| maybe another serves `content-type: text/html; charset=utf-8`.
| The reason people recommend <meta charset="utf-8"> is so that
| you don't depend on server configuration that the authors of
| the HTML commonly can't control, and which may not always be
| possible: specifically, what happens if someone saves your HTML
| page locally?
|
| > _And since utf-8 is the only valid charset for HTML5 it
| shouldn 't be the default._
|
| UTF-8 is the only _valid_ charset for HTML now, but that
| doesn't mean it's the only _supported_ charset. See
| https://html.spec.whatwg.org/#determining-the-character-
| enco.... The default varies by locale and even user
| configuration (see the table in step 9). If the default was
| changed to UTF-8, many non-English old documents would break.
| Maybe eventually the default will be changed anyway, at least
| where the short <!doctype html> doctype is used.
| shadowfaxRodeo wrote:
| That's a good point about the favicon mix. I really want to
| get a difinitve answer to all this. I'll do some tests when I
| have time.
|
| I guess that should read most servers? I'm not much of a
| backend dev, but every default I've seen has included the
| charset in the headers.
|
| I realize I'm blowing against the wind on this one!
|
| On a site by site basis it seems that you really can get rid
| of it. I've only tested my own sites offline in various
| browsers and they work fine without the meta tag.
|
| One example of a site that doesn't use it is YouTube, and I
| figured that can't be an accident.
| [deleted]
| chrismorgan wrote:
| A few notes:
|
| > _It must come before the <title> element to avoid faulty
| characters in the page title._
|
| This isn't quite true. Rather, any meta element declaraing a
| charset should occur within the first 1024 bytes, or it may be
| ignored.
|
| ------
|
| Print styles: you might think that putting print styles in a
| separate file would let the browser not load them unless the user
| actually seeks to print, but in practice browsers load all
| stylesheets, even for media queries that will never match. I
| think this may be for fingerprinting reasons, but I don't truly
| know. In the distant past (maybe a decade ago), print stylesheets
| would block rendering while they loaded in most browsers. No idea
| whether they still do, but I'd _guess_ (uneducated) that they may
| be deferred a bit now.
|
| In light of all this, I generally recommend a small @media print
| { ... } block in your existing stylesheet, rather than a separate
| print stylesheet file.
|
| ------
|
| The favicon prefers-color-scheme thing: don't put too much weight
| on this, it doesn't actually do what people are commonly saying
| it does: there is only a slight correlation between prefers-
| color-scheme and the colour the favicon is rendered atop.
| prefers-color-scheme is for _content_ , not chrome. If I recall
| correctly, Chrome's incognito mode renders the tab bar dark; and
| in Firefox the concept of browser theme (light/dark/all kinds of
| custom) is completely separate from prefers-color-scheme--so I
| have dark browser chrome but light content.
|
| Understand that the favicon could be being rendered atop
| _anything at all_. Any solid colour, any image, anything. Very
| light and very dark greys are the most _common_ colours for them
| to be rendered against, but you want to make it so that your
| favicon is at least not horrifically bad on any background.
| Ashanmaril wrote:
| I wish Google would pay attention to the favicon colors thing
| with their new icons. The new Gmail logo looks bad on pretty
| much every background because it has various light and dark
| colors in it, and isn't on its own backdrop, so pretty much any
| color it sits on, one of the colors kinda blends into it. It
| looks so bad
| voces wrote:
| > This isn't quite true. Rather, any meta element declaraing a
| charset should occur within the first 1024 bytes, or it may be
| ignored.
|
| Both correct: charset before title element, and charset within
| first 1024 bytes.
|
| Older browsers would infer charset automatically if not in
| first 1024 bytes or undefined. So if user had possibility to
| change the page title (for example: profile name), they could
| do persistent XSS by having IE infer the title contents as
| UTF-7, before the actual declaration happens. Sometimes the
| title or other elements can also be stuffed, so the charset
| declaration happens after 1024 bytes.
|
| > Older versions of Internet Explorer can be tricked into
| interpreting the page as UTF-7. This can be used for a cross-
| site scripting attack as the < and > marks can be encoded as
| +ADw- and +AD4- in UTF-7, which most validators let through as
| simple text.
|
| Modern browsers don't fall for this, but this was a huge XSS
| vector back in the day (for instance, Google was vulnerable to
| this, and maybe still is, for its users on ancient browsers).
| kijin wrote:
| Fun project: create a favicon using just the right tones of
| gray so that it appears one way against a light background and
| another way against a dark background.
| chrismorgan wrote:
| Related to this, alpha channels can be very useful in writing
| a single colour that appears as different colours against
| known dark and light colours. For example, see the mention of
| #8888 in https://chrismorgan.info/blog/dark-theme-
| implementation/, where that #8888 becomes effectively #bfbfbf
| against white, and #484848 against black.
| Brajeshwar wrote:
| Nice. Check this out too https://htmlhead.dev
| ChrisArchitect wrote:
| fix the fucking dates on these blog posts
|
| April 9., 2021
| crazypython wrote:
| Note that HTML allows you to avoid quoting parameters to make
| them easier to type: <html lang=en class=no-js>
|
| This is a feature React lacks.
| xixixao wrote:
| In JSX it wouldn't be obvious whether "en" is a
| variable/literal or a string.
| postalrat wrote:
| It's always a string unless it's in a {} pair. So if <
| lang=en > it would always be a string.
| TheGoodBarn wrote:
| The only other tag I suggest adding to this, especially since its
| a boilerplate is the _< meta http-equiv="X-UA-Compatible"
| content="IE=edge">_.
|
| [You can read more about why from smart people on
| StackOverflow](https://stackoverflow.com/a/8942455/10783165)
| matijs wrote:
| As far as I know, edge is the default mode [1], no need to set
| it explicitly, especially not for sites that target modern
| browsers.
|
| [1]: https://docs.microsoft.com/en-us/archive/blogs/ie/living-
| on-...
| runarberg wrote:
| All these open graph data tags (!) and half of them redundant.
|
| I'm gonna be the one to complain about it here. Why are we
| adhering to a proprietary format by facebook when equivalent meta
| tags exists. e.g. why is og:description a thing when we have
| <meta name="description"> and why specify og:title when <title>
| is literally the only contented tag required by the HTML standard
| (so all websites are required to have one).
|
| This reminds me of a post from yesterday: _"We were promised
| Strong AI, but instead we got metadata analysis"_ [1]. And a poor
| one at that indeed.
|
| https://news.ycombinator.com/item?id=26941332
| Mauricebranagh wrote:
| Because when someone (or our social media team/agency) shares
| one of our pages on FB we want it to look nice.
| runarberg wrote:
| Then a follow up question: Why are the scrapers on FB,
| Twitter, etc. so dumb? Why can't they fall back to <title> if
| <meta name="og:title"> is missing? Why is it my job to make
| things look nice on _their_ platforms, when all the metadata
| they require is already there?
| Mauricebranagh wrote:
| Optimal Titles are different lengths for different use
| cases for FB and Twitter ideally you want a call to action
| shorter title as compared to a longer optimised page
| <title>
| runarberg wrote:
| It still begs the question: What about the--in my
| experience--more common use case where they are the same
| (i.e. current title and description is sufficient for
| social shares)?
|
| Here is an example of a discord server refusing the
| expand the site description and title on one of my
| sites[1], just because there is no og:title and
| og:description (even though I provide both <title> and
| <meta name="description">).
|
| All I can take from this is either: a) Social media
| companies are bad at (or don't care about) implementing
| common sense features, or b) Facebook is actively and
| aggressively pushing their own proprietary format over
| established standards. In either case it is bad.
|
| 1: https://forums.online-go.com/t/random-starting-
| position-flex...
| lenkite wrote:
| I wish there was a metadata tag that could prevent sharing on
| social media platforms.
| pgcj_poster wrote:
| What if you set og:image to a female-presenting nipple?
| procombo wrote:
| You used to be able to prevent sharing by blocking their
| "thumbnail generator" requests via firewall. Or block entire
| range such as "2a03:2880::/32".
|
| I haven't looked into this method's feasibility in years
| though. I imagine there are much better ways they protect
| outbound clicks from their apps these days.
| earthboundkid wrote:
| <meta name="robots" content="noindex">
| heywherelogingo wrote:
| All your content are belong to us.
| nodex-alex wrote:
| " why is og:description a thing when we have <meta
| name="description"> and why specify og:title when <title>"
|
| .....
|
| Because facebook/twitter/linkedin have different ways to
| display information and sometimes what's inside the description
| (for SEO purposes) is NOT the same as what you want displayed
| on a social media platform or other outlet for your content!
|
| <title>, <meta name="description" ...> nearly always get used
| to optimise for Google and not the end user of a social media
| platform.
| SavantIdiot wrote:
| I think it is important to review best practices like this
| yearly. However I am also disappointed how much accomodation is
| required to make various platforms happy. From social media cues
| with og: to meta tags for crawlers, to manifests for Android. It
| just seems ... infected with ephemera. I mean, social media is
| pushing 20 years so I'm probably sounding my age, but something
| about all those customizations hidden behind meta tag prop lists
| is icky. IMHO.
| nicky0 wrote:
| The in-your-face disclaimer at the top is really not needed. The
| site looks fine.
| squiggleblaz wrote:
| I think it's expected to look fine most of the time. But since
| the author isn't developing it locally, but rather updating the
| live site and seeing how things go, sometimes they will stuff
| up.
| lloydatkinson wrote:
| This is useful I think purely for the meta tags and the opengraph
| properties and related magic values you need to make things like
| twitter show images and descriptions properly when a link is
| embedded.
___________________________________________________________________
(page generated 2021-04-27 23:01 UTC)