12 ms·

Tags to make HTML work like you expect

• theandrewbailey 11mo ago
  I often reach for the HTML5 boilerplate for things like this: https://github.com/h5bp/html5-boilerplate/blob/main/dist/index.html https://github.com/h5bp/html5-boilerplate/blob/main/dist/ind...
  • xg15 11mo ago
    There is some irony in then-Facebook's proprietary metadata lines being in there (the "og:..." lines). Now with their name being "Meta", it looks even more proprietary than before. Maybe the name was never about the Metaverse at all...
    • zelphirkalt 11mo ago
      Are they proprietary? How? Isn't open graph a standard and widely implemented by many parties, including many open source softwares?
      • FoxBJK 11mo ago
        They're not, at all. It was invented by Facebook, but it's literally just a few lines of metadata that applications can choose to read if they want.
        • kaoD 11mo ago
          Being invented by $company does not preclude it from being a standard. https://en.wikipedia.org/wiki/Technical_standard https://en.wikipedia.org/wiki/Technical_standard > A technical standard may be developed privately or unilaterally, for example by a corporation, regulatory body, military, etc. PDF is now an international standard (ISO 32000) but it was invented by Adobe. HTML was invented at the CERN and is now controlled by W3C (a private consortium). OpenGL was created by SGI and is maintained by the Khronos Group. All had different "ownership" paths and yet I'd say all of them are standards.
          • albedoa 11mo ago
            Did you mean to type "does not" in that first sentence? Otherwise, the rest of your comment acts as evidence against it.
            • kaoD 11mo ago
              Yep, it was a typo. Thanks! Fixed.
      • chrismorgan 11mo ago
        The Open Graph Protocol was thrown over the wall by Facebook and promptly abandoned. It’s an atrocious spec, a good chunk of what it did (and most of what people actually wanted from it) was already unnecessary (og:description, for example, is stupid), its data model makes several woefully bad choices, it’s firmly based around Facebook’s interests (especially pictures!), it’s built on standards that were already looking like they were failing and are definitely long abandoned now, and I don’t think I’ve seen a single page implementing OGP tags correctly in the last five years and I’m not confident that a strictly correct reader implementation even exists (the specific matter I have in mind pertains to the prefix attribute). Also a bunch of key URLs have been 404ing for many years now.
  • fud101 11mo ago
    how do you find this when you need it?
    • deleted 11mo ago
      [deleted]
    • crabmusket 11mo ago
      DuckDuckGo "html5 boilerplate", click on website, click on "source code", follow your nose to the index.html file
• chrismorgan 11mo ago
  > <html lange="en"> s/lange/lang/ > <meta name="viewport" content="width=device-width,initial-scale=1.0"> Don’t need the “.0”. In fact, the atrocious incomplete spec of this stuff <https://www.w3.org/TR/css-viewport-1/ https://www.w3.org/TR/css-viewport-1/> specifies using strtod to parse the number, which is locale dependent, so in theory on a locale that uses a different decimal separator (e.g. French), the “.0” will be ignored. I have yet to test whether <meta name="viewport" content="width=device-width,initial-scale=1.5"> misbehaves (parsing as 1 instead of 1½) with LC_NUMERIC=fr_FR.UTF-8 on any user agents.
  • cousin_it 11mo ago
    Wow. This reminds me of Google Sheets formulas, where function parameters are separated with , or ; depending on locale.
    • noja 11mo ago
      Same as Excel and LibreOffice surely?
      • KoolKat23 11mo ago
        Yes
    • troupo 11mo ago
      The behaviour predates Google Sheets and likely comes from Excel (whose behavior Sheets emulate/reverse engineer in many places). And I wouldn't be surprised if Excel got it from Lotus.
    • Moru 11mo ago
      Not to mention the functions are also translated to the other language. I think both these are the fault of Excel to be honest. I had this problem long before Google came around. And it's really irritating when you have the computer read something out to you that contains numbers. 53.1 km reads like you expect but 53,1 km becomes "fifty-three (long pause) one kilometer".
• Aransentin 11mo ago
  Note that <html> and <body> auto-close and don't need to be terminated. Also, wrapping the <head> tags in an actual <head></head> is optional. You also don't need the quotes as long the attribute doesn't have spaces or the like; <html lang=en> is OK. (kind of pointless as the average website fetches a bazillion bytes of javascript for every page load nowadays, but sometimes slimming things down as much as possible can be fun and satisfying)
  • chrismorgan 11mo ago
    <html>, <head> and <body> start and end tags are all optional. In practice, you shouldn’t omit the <html> start tag because of the lang attribute, but the others never need any attributes. (If you’re putting attributes or classes on the body element, consider whether the html element is more appropriate.) It’s a long time since I wrote <head>, </head>, <body>, </body> or </html>.
  • zelphirkalt 11mo ago
    This kind of thing will always just feel shoddy to me. It is not much work to properly close a tag. The number of bytes saved is negligible, compared to basically any other aspect of a website. Avoiding not needed div spam already would save more. Or for example making sure CSS is not bloated. And of course avoiding downloading 3MB of JS. What this achieves is making the syntax more irregular and harder to parse. I wish all these tolerances wouldn't exist in HTML5 and browsers simply showed an error, instead of being lenient. It would greatly simplify browser code and HTML spec.
    • ifwinterco 11mo ago
      You're not alone, this is called XHTML and it was tried but not enough people wanted to use it
      • sevenseacat 11mo ago
        oh man, I wish XHTML had won the war. But so many people (and CMSes) were creating dodgy markup that simply rendered yellow screens of doom, that no-one wanted it :(
• hlava 11mo ago
  It's 2025, the end of it. Is this really necessary to share?
  • 4ndrewl 11mo ago
    Yes. Knowledge is not equally distributed.
  • troupo 11mo ago
    Every day you can expect 10000 people learning a thing you thought everyone knew: https://xkcd.com/1053/ https://xkcd.com/1053/ To quote the alt text: "Saying 'what kind of an idiot doesn't know about the Yellowstone supervolcano' is so much more boring than telling someone about the Yellowstone supervolcano for the first time."
    • allknowingfrog 11mo ago
      XKCD 1053 is a way of life. I think about it all the time, and it has made me a better human being.
    • Skeime 11mo ago
      And here I was, thinking everybody already knew XKCD 1053 ...
    • janwillemb 11mo ago
      Thanks! I didn't know that one. I had a teacher who became angry when a question was asked about a subject he felt students should already be knowledgeable about. "YOU ARE IN xTH GRADE AND STILL DON'T KNOW THIS?!" (intentional shouting uppercase). The fact that you learned it yesterday doesn't mean all humans in the world also learned it yesterday. Ask questions, always. Explain, always.
      • spc476 11mo ago
        Such questions can be jarring though. I remember my "Unix Systems Programming" class in college. It's a third year course. The instructor was describing the layout of a process in memory, "here's the text segment, the data segment, etc." when a student asked, "Where do the comments go?"
• isolay 11mo ago
  The "without meta utf-8" part of course depends on your browser's default encoding.
  • kevin_thibedeau 11mo ago
    What mainstream browsers aren't defaulting to utf-8 in 2025?
    • naniwaduni 11mo ago
      All of them, pretty much.
    • akho 11mo ago
      html5 does not even allow any other values in <meta charset=>. I think you need to use a different doctype to get what the screenshot shows.
      • layer8 11mo ago
        While true, they also require user agents to support other encodings specified that way: https://html.spec.whatwg.org/multipage/parsing.html#character-encodings https://html.spec.whatwg.org/multipage/parsing.html#characte... Another funny thing here is that they say “but not limited to” (the listed encodings), but then say “must not support other encodings” (than the listed ones).
        • shiomiru 11mo ago
          It says > the encodings defined in Encoding, including, but not limited to where "Encoding" refers to https://encoding.spec.whatwg.org https://encoding.spec.whatwg.org (probably that should be a link.) So it just means "the other spec defines at least these, but maybe others too." (e.g. EUC-JP is included in Encoding but not listed in HTML.)
          • layer8 11mo ago
• ilaksh 11mo ago
  Anyone else prefer to use web components without bundling? I probably should not admit this, but I have been using Lit Elements with raw JavaScript code. Because I stopped using autocomplete awhile ago. I guess not using TypeScript at this point is basically the equivalent for many people these days of saying that I use punch cards.
  • VPenkov 11mo ago
    37 Signals [0] famously uses their own Stimulus [1] framework on most of their products. Their CEO is a proponent of the whole no-build approach because of the additional complexity it adds, and because it makes it difficult for people to pop your code and learn from it. [0]: https://basecamp.com/ https://basecamp.com/ [1]: https://stimulus.hotwired.dev/ https://stimulus.hotwired.dev/
    • christophilus 11mo ago
      Dunno. You can build without minifying if you want it to be (mostly) readable. I wouldn’t want to give up static typing again in my career.
    • evilduck 11mo ago
      It's impossible to look at a Stimulus based site (or any similar SSR/hypermedia app) and learn anything useful beyond superficial web design from them because all of the meaningful work is being done on the other side of the network calls. Seeing a "data-action" or a "hx-swap" in the author's original text doesn't really help anyone learn anything without server code in hand. That basically means the point is moot because if it's an internal team member or open source wanting to learn from it, the original source vs. minified source would also be available. It's also more complex to do JS builds in Ruby when Ruby isn't up to the task of doing builds performantly and the only good option is calling out to other binaries. That can also be viewed from the outside as "we painted ourselves into a corner, and now we will discuss the virtues of standing in corners". Compared to Bun, this feels like a dated perspective. DHH has had a lot of opinions, he's not wrong on many things but he's also not universally right for all scenarios either and the world moved past him back in like 2010.
• lapcat 11mo ago
  <meta name="viewport" content="width=device-width,initial-scale=1.0"> width=device-width is actually redundant and cargo culting. All you need is initial-scale. I explain in a bit more detail here: https://news.ycombinator.com/item?id=36112889 https://news.ycombinator.com/item?id=36112889
  • cxr 11mo ago
    outerHTML is an attribute of Element and DocumentFragment is not an Element. Where do the standards say it ought to work?
  • qingcharles 11mo ago
    I've read your post. I'm going to test this on some crappy devices this week to confirm and then update my boilerplate.
• irarelycomment 11mo ago
  Similar vibes to https://j4e.name/articles/a-minimal-valid-html5-document/ https://j4e.name/articles/a-minimal-valid-html5-document/
• aragonite 11mo ago
  Fun fact: both HN and (no doubt not coincidentally) paulgraham.com ship no DOCTYPE and are rendered in Quirks Mode. You can see this in devtools by evaluating `document.compatMode`. I ran into this because I have a little userscript I inject everywhere that helps me copy text in hovered elements (not just links). It does: [...document.querySelectorAll(":hover")].at(-1) to grab the innermost hovered element. It works fine on standards-mode pages, but it's flaky on quirks-mode pages. Question: is there any straightforward & clean way as a user to force a quirks-mode page to render in standards mode? I know you can do something like: document.write("<!DOCTYPE html>" + document.documentElement.innerHTML); but that blows away the entire document & introduces a ton of problems. Is there a cleaner trick?
  • rob 11mo ago
    I wish `dang` would take some time to go through the website and make some usability updates. HN still uses a font-size value that usually renders to 12px by default as well, making it look insanely small on most modern devices, etc. At quick glance, it looks like they're still using the same CSS that was made public ~13 years ago: https://github.com/wting/hackernews/blob/5a3296417d23d1ecc901447af63dfc27af217f40/news.arc#L473 https://github.com/wting/hackernews/blob/5a3296417d23d1ecc90...
    • martin-t 11mo ago
      I find it exactly the right size on both PC and phone. There's a trend to make fonts bigger but I never understood why. Do people really have trouble reading it? I prefer seeing more information at the same time, when I used Discord (on PC), I even switched to IRC mode and made the font smaller so that more text would fit.
      • askonomm 11mo ago
        I'm assuming you have a rather small resolution display? On a 27" 4k display, scaled to 150%, the font is quite tiny, to the point where the textarea I currently type this in (which uses the browsers default font size) is about 3 times the perceivable size in comparison to the HN comments themselves.
• jraph 11mo ago
  > <!doctype html> is what you want for consistent rendering. Or <!DOCTYPE HTML> if you prefer writing markup like it’s 1998. Or even <!doCTypE HTml> if you eschew all societal norms. It’s case-insensitive so they’ll all work. And <!DOCTYPE html> if you want polyglot (X)HTML.
  • bombcar 11mo ago
    We need HTML Sophisticated - <!Dr. Type, HtML, PhD>
  • nikeee 11mo ago
    I tend to lower-case all my HTML because it has less entropy and therefore can be compressed more effectively. But in case of modern compression algorithms, some of them come with a pre-defined dictionary for websites. These usually contain the common stuff like <!DOCTYPE html> in its most used form. So doing it like everybody else might even make the compression even more effective.
• dugmartin 11mo ago
  I know this was a joke: <div id="root"></div> <script src="bundle.js"></script> but I feel there is a last tag missing: <main>...</main> that will ensure screenreaders skip all your page "chrome" and make life much easier for a lot of folks. As a bonus mark any navigation elements inside main using <nav> (or role="navigation").
  • eska 11mo ago
    I’m not a blind person but I was curious about once when I tried to make a hyper-optimized website. It seemed like the best way to please screen readers was to have the navigation HTML come last, but style it so it visually comes first (top nav bar on phones, left nav menu on wider screens).
    • hnthrowaway121 11mo ago
      Wouldn’t that run afoul of other rules like keeping visual order and tab order the same? Screen reader users are used to skip links & other standard navigation techniques.
      • eska 11mo ago
        Interesting question. I don’t remember testing this, sorry.
    • striking 11mo ago
      You want a hidden "jump to content" link as the first element available to tab to.
    • sholladay 11mo ago
      Props to you for taking the time to test with a screen reader, as opposed to simply reading about best practices. Not enough people do this. Each screen reader does things a bit differently, so testing real behavior is important. It's also worth noting that a lot of alternative input/output devices use the same screen reader protocols, so it's not only blind people you are helping, but anyone with a non-traditional setup. Navigation should come early in document and tab order. Screen readers have shortcuts for quickly jumping around the page and skipping things. It's a normal part of the user experience. Some screen readers and settings de-prioritize navigation elements in favor of reading headings quickly, so if you don't hear the navigation right away, it's not necessarily a bug, and there's a shortcut to get to it. The most important thing to test is whether the screen reader says what you expect it to for dynamic and complex components, such as buttons and forms, e.g. does it communicate progress, errors, and success? It's usually pretty easy to implement, but this is where many apps mess up.
• brianzelip 11mo ago
  > `<html lang="en">` The author might consider instead: `<html lang="en-US">`
  • mobeigi 11mo ago
    Interesting. From what I can tell this allows some screen readers to select specific accents. Also the browser can select the appropriate spell checker (US English vs British English).
  • childintime 11mo ago
    It's time for an "en-INTL" (or similar) for international english, that is mostly "en-US", but implies a US-International keyboard and removes americanisms, like Logical Punctuation in quotes [1]. Then AI can start writing for a wider and much larger public (and can also default to regular ISO units instead of imperial baby food). Additionally, it's kind of crazy we are not able to write any language with any keyboard, as nowadays we just don't know the idiom the person who sits behind the keyboard needs. [1] https://slate.com/human-interest/2011/05/logical-punctuation-should-we-start-placing-commas-outside-quotation-marks.html https://slate.com/human-interest/2011/05/logical-punctuation...
    • qingcharles 11mo ago
      Isn't that what "en" on its own should be, though?
    • chrismorgan 11mo ago
      If you want to divide English into only two categories, I reckon US English (color, analyze, center) and International English (colour, analyse, centre) is the best divide. It’s imperfect—Canadians are mostly International but want analyze, and there are other controversial words like program/programme (US, CA and AU prefer program; GB and IN prefer programme)—but I think it’s the best divide if you want only two. Windows distributes ISOs labelled English (en-US) and English International (en-GB) along this divide. It’s also a valuable divide for reasons beyond language, because the USA really does have a habit of doing its own thing, even when pretty much the rest of the world has agreed on something different. Your US English locale can default to Fahrenheit, miles, pounds, Letter, and their bizarre middle-endian date format, while International English can default to Celsius, kilometres, kilograms, A4, and DD/MM/YYYY. It doesn’t sort out everything, but it gives a much better starting point. Not every non-American prefers DD/MM/YYYY, but even if they’d prefer something like DD.MM.YY or YYYY-MM-DD, DD/MM/YYYY is a whole lot better than MM/DD/YYYY.
• orliesaurus 11mo ago
  Quirks quirks aside there are other ways to tame old markup... If a site won't update itself you can... use a user stylesheet or extension to fix things like font sizes and colors without waiting for the maintainer... BUT for scripts that rely on CSS behaviors there is a simple check... test document.compatMode and bail when it's not what you expect... sometimes adding a wrapper element and extracting the contents with a Range keeps the page intact... ALSO adding semantic elements and ARIA roles goes a long way for accessibility... it costs little and helps screen readers navigate... Would love to see more community hacks that improve usability without rewriting the whole thing...
• reconnecting 11mo ago
  I wish I could use this one day again to make my HTML work as expected. <bgsound src="test.mid" loop=3>
• Grom_PE 11mo ago
  I hate how because of iPhone and subsequent mobile phones we have bad defaults for webpages so we're stuck with that viewport meta forever. If only we had UTF-8 as a default encoding in HTML5 specs too.
  • jonhohle 11mo ago
    I came here to say the same regarding UTF-8. What a huge miss and long overdue. I’ve had my default encoding set to UTF-8 for probably 20 years at this point, so I often miss some encoding bugs, but then hit others.
• teekert 11mo ago
  Nice, the basics again, very good to see. But then: I know what you’re thinking, I forgot the most important snippet of them all for writing HTML: <div id="root"></div> <script src="bundle.js"></script> Lol. -> Ok, thanx, now I do feel like I'm missing an inside joke.
  • Ayesh 11mo ago
    It's a typical pattern in, say react, to have just this scaffolding in the HTML and let some frond end framework to build the UI.
  • deleted 11mo ago
    [deleted]
• dinkelberg 11mo ago
  TFA itself has an incorrect DOCTYPE. It’s missing the whitespace between "DOCTYPE" and "html". Also, all spaces between HTML attributes where removed, although the HTML spec says: "If an attribute using the double-quoted attribute syntax is to be followed by another attribute, then there must be ASCII whitespace separating the two." (https://html.spec.whatwg.org/multipage/syntax.html#attributes-2 https://html.spec.whatwg.org/multipage/syntax.html#attribute...) I guess the browser gets it anyway. This was probably automatically done by an HTML minifier. Actually the minifier could have generated less bytes by using the unquoted attribute value syntax (`lang=en-us id=top` rather than `lang="en-us"id="top"`). Edit: In the `minify-html` Rust crate you can specify "enable_possibly_noncompliant", which leads to such things. They are exploiting the fact that HTML parsers have to accept this per the (parsing) spec even though it's not valid HTML according to the (authoring) spec.
  • 9029 11mo ago
    Maybe a dumb question but I have always wondered, why does the (authoring?) spec not consider e.g. "doctypehtml" as valid HTML if compliant parsers have to support it anyway? Why allow this situation where non-compliant HTML is guaranteed to work anyway on a compliant parser?
    • HWR_14 11mo ago
      Because there are multiple doctypes you can use. The same reason "varx" is not valid and must be written "var x".
    • LegionMammal978 11mo ago
      It's considered a parse error [0]: it basically says that a parser may reject the document entirely if it occurs, but if it accepts the document, then it must act as if a space is present. In practice, browsers want to ignore all parse errors and accept as many documents as possible. [0] https://html.spec.whatwg.org/multipage/parsing.html#parse-error-missing-whitespace-before-doctype-name https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
      • 11mo ago
• daneel_w 11mo ago
  For clarity and conformity, while optional these days, I insist on placing meta information within <head>.
• flymasterv 11mo ago
  I still don’t understand what people think they’re accomplishing with the lang attribute. It’s trivial to determine the language, and in the cases where it isn’t, it’s not trivial for the reader, either.
  • janwillemb 11mo ago
    Doesn't it state this in the article? > Browsers, search engines, assistive technologies, etc. can leverage it to: > - Get pronunciation and voice right for screen readers > - Improve indexing and translation accuracy > - Apply locale-specific tools (e.g. spell-checking)
    • flymasterv 11mo ago
      It states the cargo culted reasons, but not the actual truth. 1) Pronounciation is either solved by a) automatic language detection, or b) doesn't matter. If I am reading a book, and I see text in a language I recognize, I will pronounce it correctly, just like the screen reader will. If I see text in a language I don't recognize, I won't pronounce it correctly, and neither will the screen reader. There's no benefit to my screen reader pronouncing Hungarian correctly to me, a person who doesn't speak Hungarian. On the off chance that the screen reader gets it wrong, even though I do speak Hungarian, I can certainly tell that I'm hearing english-pronounced hungarian. But there's no reason that the screen reader will get it wrong, because "Mit csináljunk, hogy boldogok legyünk?" isn't ambiguous. It's just simply Hungarian, and if I have a Hungarian screen reader installed, it's trivial to figure that out. 2) Again, if you can translate it, you already know what language it is in. If you don't know what language it is in, then you can't read it from a book, either. 3) See above. Locale is mildly useful, but the example linked in the article was strictly language, and spell checking will either a) fail, in the case of en-US/en-UK, or b) be obvious, in the case of 1) above. The lang attribute adds nothing to the process.
      • bilkow 11mo ago
        Your whole comment assumes language identification is both trivial and fail-safe. It is neither and it can get worse if you consider e.g. cases where the page has different elements in different languages, different languages that are similar. Even if language identification was very simple, you're still putting the burden on the user's tools to identify something the writer already knew.
• notepad0x90 11mo ago
  I'm not a web developer, so if someone can please enlighten me: Why does this site, and so many "modern" sites like it have it so that the actual content of the site takes up only 20% of my screen? My browser window is 2560x1487. 80% of the screen is blank. I have to zoom in 170% to read the content. With older blogs, I don't have this issue, it just works. Is it on purpose or it is it bad css? Given the title of the post, i think this is somewhat relevant.
  • majora2007 11mo ago
    I'm not sure, but when I was working with UX years ago, they designed everything for a fixed width and centered it in the screen. Kinda like how HackerNews is, it's centered and doesn't scale to my full width of the monitor.
    • notepad0x90 11mo ago
      I understand not using the full width, but unless you zoom in, it feels like I'm viewing tiny text on a smart phone in portrait mode. You would think browsers themselves would handle the rest, if the website simply specified "center the content div with 60% width" or something like that.
  • Menu_Overview 11mo ago
    Often times that is to create a comfortable reading width. (https://ux.stackexchange.com/questions/108801/what-is-the-best-number-of-paragraph-width-for-readability https://ux.stackexchange.com/questions/108801/what-is-the-be...)
    • AlienRobot 11mo ago
      I wonder if this research is really valid. It was published 20 years ago, there is nothing in the abstract about arcdegrees and I can't read the full thing, and it's cited with zero consideration for the actual content being presented. If Wikipedia had 70 characters per line I would never read it.
• wpollock 11mo ago
  I appreciate this post! I was hoping you would add an inline CSS style sheet to take care of the broken defaults. I only remember one off the top of my head, the rule for monospace font size. You need something like: code, pre, tt, kbd, samp { font-family: monospace, monospace; } But I vaguely remember there are other broken CSS defaults for links, img tags, and other stuff. An HTML 5 boilerplate guide should include that too, but I don't know of any that do.
  • keane 11mo ago
    Paired with H5BP you can use Normalize.css (as an alternative to a reset like http://meyerweb.com/eric/tools/css/reset/ http://meyerweb.com/eric/tools/css/reset/) found at https://github.com/necolas/normalize.css/blob/master/normalize.css https://github.com/necolas/normalize.css/blob/master/normali... There's also this short reset: https://www.joshwcomeau.com/css/custom-css-reset/ https://www.joshwcomeau.com/css/custom-css-reset/
• deleted 11mo ago
  [deleted]
• cluckindan 11mo ago
  CSS rules to make styling work like you expect: *, *:before, *:after { box-sizing: border-box; }
  • fud101 11mo ago
    can you explain why you add this please?
• chroma_zone 11mo ago
  I usually add: <meta name="color-scheme" content="light dark"> which gives you a nice automatic dark theme "for free"
  • jimniels 11mo ago
    Ah this is a good one! I should maybe start considering this as a default...
• chrisofspades 11mo ago
  If your IDE supports Emmet (supported by VS Code out of the box) then you can use "!"-tab to get the same tags.
• extraduder_ire 11mo ago
  I thought <!doctype html> automatically implied utf-8, or have things changed since html5 was the new hotness?
• est 11mo ago
  the lang="en" always irritates me. What if the page has mixed language content? e.g. on the /r/france/ reddit. The page says lang="en" because every subreddit shares the same template. But actual content were generated by French speaking users.
  • zeroq 11mo ago
    You can add lang attributes to elements too! https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/lang https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
  • acdha 11mo ago
    This is one of the great parts of the web: you can tag every element with the global lang attribute and have things work the way you expect. For example, you can have CSS generate the appropriate quotation marks even in nested contexts so you can painlessly use <q> tags to markup scholarly articles even if the site itself is translated and thus would have different nested quotation marks for, say, the French version embedding an English quote including a French quote or vice versa. In your Reddit example, the top level page should be in the user’s preferred site language with individual posts or other elements using author’s language: <html lang=en>…<div lang=fr>
  • Telaneo 11mo ago
    lang="" if you don't know what language your page will be in. <html lang="en">, and then <p lang="fr"> on whatever other language content. Content from users that aren't tagged to be in a specific language doesn't really fit into this system though. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/lang https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
    • est 11mo ago
      That sounds good in theory. On bsky.social you are supposed to choose a lang before posting. But again there's mixed language issue Or do users even bother to choose the correct lang?