Hacker News Reader

Comment by hawski | Hacker News Reader

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.

View on HN

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.

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.

> 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.

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.

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.

You should use system-ui, sans-serif to avoid abusing the semantics of menu.

Excuse my ignorance: what the heck does this achieve?!

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

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.

if you remove all css it looks good again on mobile devices

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?

It sets mobile browsers use actual widths and not emulate desktop width.

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...

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.

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...

s/"ttp"/http"/

Fixed. Thanks!

No box-sizing: border-box?

I'm not doing anything complex enough for it to matter.

Like using margins or padding?

> <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.

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.

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.

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.

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.

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.

Do they earn 30% from HTML5 apps?

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.

The browser is the app.

The web app is the app. A browser is a mini OS at this point.

That's what web devs like to pretend. Then they are surprised when browser developers continue developing their browsers.

If you want to develop an app, develop an app, not a website. Use Electron or its mobile equivalents if you must.

So you are saying that pinch and double tap should just be removed from js specs because one company arbitrarily decided you can't use them anymore. Whatever.

Also, MS office and Adobe are web apps and far more complex than almost any "real apps" out there. It's completely untrue that web apps are not apps.

No, I think JS as a whole should be removed completely independently of what any company decided. Websites in general aren't trustworthy, which means they can't be trusted to determine the browser's behaviour.

> Also, MS office and Adobe are web apps and far more complex than almost any "real apps" out there. It's completely untrue that web apps are not apps.

You can pretend they are until someone takes away your toys. Then, suddenly, your "app" cannot even process its own input. Or access the clipboard. Or do any of the other things that websites just aren't trustworthy enough for.

There is nothing that makes an installed app, with higher permissions, more trustworthy than a web app. Getting rid of js altogether is just throwing away the web to make it something poorly performing and requires sending all data back to the server - so not really a serious option. Browsers only exist to allow interaction with websites, and as such they should follow specs and allow them to be used. Websites are more important than browsers by definition.

> There is nothing that makes an installed app, with higher permissions, more trustworthy than a web app.

Yes, there is. The fact the user has installed it.

> Getting rid of js altogether is just throwing away the web to make it something poorly performing and requires sending all data back to the server - so not really a serious option.

Not the web, just webapps. The web will perform better afterwards.

> Browsers only exist to allow interaction with websites, and as such they should follow specs and allow them to be used.

Yes, but those specs have to be sane. Which means even a completely untrusted party – that's what a random website is – cannot abuse them.

> Websites are more important than browsers by definition.

Nonsense, either is useless without the other. Websites are content, browsers define how they're viewed.

At what point do they think my English "makes the iOS user experience worse" and change the text between two <div>s?

> 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.

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.

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.

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

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.

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.

> 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.

Why doesn't it zoom the object along with the rest of the page?

Probably meant "it zooms the whole UI and not just the object". (WAG.)

Sounds like the expected behavior to me.

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.

You can implement whatever you want, just not in a website. Write an app instead. Sure, it may not be available on Apple device because of their restrictions on that matter, but that's a separate issue.

It would be nice if web developers could be trusted to only disable zoom when it either does not impact accessibility or when making a website accessible is absolutely not possible. In practice, making an inaccessible website is often more profitable because it's less effort. Also, I've seen a lot of ordinary websites disable zoom for no real reason.

Important websites have to be accessible. So if your website would not be accessible anyway, it not existing may not be a gain for anyone but it isn't a big deal either.

And in many cases, it is better for a website to not exist that for it to be inaccessible: Market forces, your employer, school, university or state can require you to access a website that is not accessible to you. They cannot do that if it does not exist.

> You can implement whatever you want, just not in a website. Write an app instead.

I don't want to write an app for it. By your logic websites should be plain text and we should all be learning N frameworks to do things that are way easier to do in a browser, available without having to install black box crap software on our devices.

It makes no sense, since you can do plenty of worse things than disabling zoom, in fact the browser allows a whole range of things that are not in the interest of users and they don't do anything to curb those, so your point is basically moot.

> In practice, making an inaccessible website is often more profitable because it's less effort.

This has no bearing in real accessibility, it's, as plenty of other things, a red herring, since real accessibility is not defined by zooming or changing your scrollbar appearance - as you can confirm by visiting a very large part of the internet.

> And in many cases, it is better for a website to not exist that for it to be inaccessible:

This is like, your opinion. Which besides being as the saying goes, isn't even backed by any rational argument. Just because you keep saying the same words they don't change reality, unless you're Dumbledore, and you're a character in a book, or a movie, and even then, it only changes the story there, not the story outside of it.

All the cases you mention can, and should be dealt with in legal terms - your school, employer, university, or state, are public entities, there can certainly be accessibility guides, references and standards, as there are in a multitude of others things, exactly to regulate that.

Your argument is like saying, that paper should not be used to draw, or do origami, or write in other languages because someone might not understand what it is, or what is contained in it. Of course, that's silly. And when it comes to government, schools, and public entities, according to the type of documents, printed and available in paper, they do have to follow a specific ruleset, without impacting what paper can be used for in other situations.

> I don't want to write an app for it. By your logic websites should be plain text and we should all be learning N frameworks to do things that are way easier to do in a browser, available without having to install black box crap software on our devices.

- Web apps don't require less trust than proper ones. Their developers can use dark patterns, abuse your data, etc.

- Cross-platform frameworks exist

- I have no idea why you think I mind hypertext

> This has no bearing in real accessibility, it's, as plenty of other things, a red herring, since real accessibility is not defined by zooming or changing your scrollbar appearance - as you can confirm by visiting a very large part of the internet.

Are you seriously claiming zooming is not an accessibility feature?

> This is like, your opinion. Which besides being as the saying goes, isn't even backed by any rational argument.

Please stop the flaming.

> All the cases you mention can, and should be dealt with in legal terms - your school, employer, university, or state, are public entities, there can certainly be accessibility guides, references and standards, as there are in a multitude of others things, exactly to regulate that.

Sure. And once there are strict accessibility laws, worldwide, that everyone follows, and all the legacy software has been replaced, we can give developers control over zooming again.

> Web apps don't require less trust than proper ones. Their developers can use dark patterns, abuse your data, etc.

They do, mostly because the browser allows it.

> I have no idea why you think I mind hypertext

Perhaps a better model would be that the web shouldn't be hypertext by default (or can be something else), and instead that hypertext is one of the possible formats for something on the web, along with others - the web would be the "envelope" and not the definition of the content.

If you follow your line of thought to the end, then the conclusion would be that we should be left to pure hypertext.

> Are you seriously claiming zooming is not an accessibility feature?

No, I'm claiming that there's no reason to not allow someone to control the behaviour of certain parts of the browser when browsing a web property of someone else, as long as it doesn't pose a security risk. While at it, the browser could implement white listing of actions, data, and other details that the web property has access to without my consent. If I visit a website for a game and it tells me "this website is going to: - disable zoom - change your scrollbars - change the right click button; check which ones you agree/do you agree" there's no loss of accessibility. And the same for scripts, watching mouse input, text typing, hijacking the back button, showing me popups, etc. Of course that would be technically very challenging to implement.

> Please stop the flaming.

The first rule is if you don't like something done to you, you shouldn't do it to others. Once you do you have to man up.

> Sure. And once there are strict accessibility laws, worldwide, that everyone follows, and all the legacy software has been replaced, we can give developers control over zooming again.

Why do they need to be strict and before-hand?

This! The whole movement of making webpages do all the things apps can do…

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.

Yes, if their browser's UI has problems distinguishing between zooming and clicking buttons, that's definitely the responsibility of the browser's vendor. Who can only improve that if the browser is actually in charge of the UI – e.g. zooming is implemented by the browser, not by every random website.

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.

Thanks for this, is it backwards compatible with previous versions of iOS? Or is there some combination of incantations that does graceful degradation?

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.

Not using either of those things sounds like a benefit.

Yeh want to justify your ROI you will :-)

And using GTM instead of hand coding every thing is a win

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.

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.

Reply on news.ycombinator.com