Hacker Newsnew | past | comments | ask | show | jobs | submit | OuterVale's commentslogin

Keywords aren't (completely) dead (yet), unfortunately. https://bsky.app/profile/vale.rocks/post/3muylxyhg5222

Mention of usage by Yandex: https://yandex.com/support/webmaster/en/controlling-robot/me...


Ha! Last year I did some preliminary research, and all contemporary sources I've found agreed that last public search engine stopped supporting meta keywords around 2018, IIUC. So good catch about Yandex, thanks for the headsup! Funny, how things get complicated :) This meta had very turbulent history in 2010s and refuses to die, apparently.

I use them whenever I have an excuse!

Oh, that is so great to hear. Glad to provide it! While writing I was very much thinking about it from the perspective of stripping things out, rather than incorporating legacy code for legacy contexts. Really interesting to think about that line of usage.

I still generally avoid browser-specific hacks like these, aiming for lowest-common-denominator most-minimal HTML that still satisfies most browsers. However, now and then there's just no avoiding it.

I am continuously in awe of the Web's decentralized and open nature that allows something like this to happen-- for one reasonably complex file/application to be compatible with 30 years of co-evolving client software written by many different developers and teams, much of it no longer supported.


You don't need both, but you should have the width set. From that page:

> A page fails the audit unless all of these conditions are met:

> - The document's <head> contains a <meta name="viewport"> tag.

> - The viewport meta tag contains a content attribute.

> - The content attribute's value includes the text width=.

I researched and tested this extensively the other day. `<meta name="viewport" content="width=device-width">` is all you need. https://vale.rocks/micros/20260902-1350


> I researched and tested this extensively the other day. `<meta name="viewport" content="width=device-width">` is all you need.

This is incorrect. Try adding an <img> that's wider than the device width. Then the whole page gets zoomed and the text unreadably small.


The same will happen regardless in the case of content extending beyond the width of the viewport. With `initial-scale=1` it'll be a horizontal overflow, without it'll zoom out. I argue that the latter is preferable (https://vale.rocks/micros/20260908-1315) but either way should never reach users due to the usability fails and major accessibility issues.

When you brought these arguments up on Lobsters <https://lobste.rs/c/dsm1up> I said it wasn’t cut and dried but that my general feeling was of disagreeing with you. I’ve thought about it more since then, and firmed my position up: you should make sure that the presence of initial-scale=1 won’t affect anything (we agree on this point), but that if you make a mistake in this area, it’s much better to have it than not to (we disagree on this part). Of your five points:

Your first point is correct. It could be reasonable to omit initial-scale=1 during development, or have something that complains on width overflow.

Your second is unavoidable: omitting initial-scale introduces a worse failure (excessively small text).

Your third I disagree with: when overflow occurs it will almost always be obvious that you could scroll, because you’ll have text or image that runs to the inline-end edge of the viewport rather than being contained by a page margin as is universally practised.

Your fourth isn’t useful—by that argument all documents should be zoomed out until the entire thing fits on screen; but we don’t do that in general because having to manage the zoom to get a useful result is unpleasant, yet that’s what you’re advocating for.

Your fifth is irrelevant, I think entirely unrelated to initial-scale.


The "fifth" was probably from their essay <https://vale.rocks/micros/20260908-1315>, that was fourth on Lobsters (?)

> People often pair initial-scale=1 with overflow-x: hidden in their CSS […]

(That one in particular really seems like a strawman.)

Spotted under PPK's share <https://front-end.social/@ppk/117201706620768380>


Yeah, I was responding to the new micros post here rather than the earlier Lobsters list.

> I argue that the latter is preferable

I disagree vehemently. I couldn't disagree more. The text has to be readable. If you force the reader to zoom in order to read the text, your website is fundamentally broken.

Moreover, neither of these considerations apply to images: "you risk having content off-screen which cannot be focused by a keyboard" "A user is extremely unlikely to think to scroll horizontally to see the rest of a document"

"There is even great president for it with documents on the web" Typo: precedent.

> either way should never reach users

This seems practically unavoidable with images, especially screenshots for example. Device widths vary, image widths vary. There is no magical image width that fits every device width, unless the image is very narrow. Moreover, I try to avoid JavaScript altogether when possible, so I don't want custom JS image viewers all over the place.


Also not to be confused with the 1980 film starring Olivia Newton-John with a great soundtrack by her, Electric Light Orchestra, The Tubes, and Cliff Richard.

Also not to be confused with the place where Kubla Khan decreed a stately pleasure done.

Gaze upon my blogs, and despair.

It is one click from that article to the homepage, which offers a blurb on the site.

https://lwn.net/


It is Windows 7 reminiscent, but it lacks the glassy appearance of Aero which is the defining characteristic of the OS' visual identity.

In this case it is because the posting account has explicitly ticked 'Ask apps and sites not to show my account to logged-out users'. Of course, Bluesky is built upon the open AT Protocol, so you can still view the post by any one of a number of other means without requiring a complex workaround.


They're not really 'tricks' as much of mentions of assorted features of HTML and CSS. You get to discover a similar assortment of things (with much more immediately available detail and many examples) just clicking around MDN.


Sure, they're not "tricks", but it's also definitely not the same as what you get randomly browsing formal documentation.


What's the difference?


That’s fair, "tricks" may be overselling it. The website is meant to be a small, opinionated collection of features I want to remember, not a replacement for an authoritative reference like MDN. I can probably make that positioning clearer.


Users scare me.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: