As I see it, the web is the most vibrant medium of expression and innovation we have today. While I don't doubt there would be gains in security to limiting it in many aspects, I question whether the specific level of security gain would be worth the loss of innovation and expression. I think there are many areas we could focus on instead that would increase security without the same level of negative consequences, so I espouse doing those first.
Not to mention I don't think it's a solution that's viable given economic principle and how much people value expression. We'd just be back to the equivalent of Flash sites again, with whatever takes over for flash (canvas?).
It's not just security, the other half is usability. The way popular web sites work is that they change stuff around regularly only to make it look different but change the behavior as well. This breaks stuff like existing functionality, key+mouse sequences to get stuff done, places you've learned to look at and navigate to quickly. Computers and modern appliances (including cars) are strangely affected by this constant desire to shift things around unnecessarily because someone told them they could sell it as it looks different now.
GitHub and gmail are prime examples for sites that broke a lot of things in the process.
Maybe what we need instead are real APIs and custom clients.
Consider the implications of what this means though. If sites are not free to innovate, things like Github and Gmail wouldn't exist. They only reason we aren't stuck with a Hotmail interface circa 2002 is because people were able to innovate on the web. To lock down CSS (or Javascript, there's no reason I can think of you would lock CSS and not Javascript) to a specific set of capabilities is both a statement that it is sufficient for all needs, and that we can decide by committee what is a good set of standards to lock into. I think both assertions are laughable false.
If we had locked down CSS five years ago, what CSS would be not be capable of using today? If we lock it down today, what would we be missing out on that would come five years from now?
Design by committee is horribly inefficient, and rarely takes into consideration the full needs of the users. What's more, it can't take into consideration future needs. Design by committee gets us XML. Adoption by iteration and evolution gets us JSON. XML has its place, but JSON is overwhelmingly more popular in certain contexts for a reason, it fits the domain better.
Lastly, iterating on Github and Gmail would not stop even if there was a complete lack of CSS and Javascript, it would just be more tedious as everything was done through a full page serve, just like the old days. That wouldn't prevent site redesigns along with missing or broken features, it would just make everything look shittier, perform slower, and use more server side resources.
That said, a sane standard for embedded interfaces, where choice is restricted, it needs to live a long time, and needs to have sane accessibility features would do well with better standards. I view that as a separate problem.
The fact of standard templates needn't prevent the possibility of novel templates. But it ought make the prospect slightly more user-controllable. Design-by-committee isn't the alternative to design-by-fuckwits, the present mode.
Github and Gmail are both tools which now face the dilemma of gratuitous changes -- many of the recent innovations haven't done much for usability, for numerous reasons (familiarity itself is a key factor, GUI offers limited capacity for improved functionality, jwz has commented on this from his Mozilla experiences).
But most changes to default styles are pants.
Hell, much the problem is that default styles are pants. If browsers had a set of presentation styles that did work well (see the "readability" modes offered by Safari, Firefox, Readability, Pocket, Instapaper, etc.), then we'd have slightly less a problem.
Github, Gmail, Google Maps, etc., are largely the exception to long-form informational content pages. I'm OK with an explicit "app mode" for such sites. But 99.999999% of what I read would do vastly better with uniform presentation.
More attention to content and semantic construction. Less to layout frippery.
> The fact of standard templates needn't prevent the possibility of novel templates.
If your stance is "provide well established default templates, but don't enforce their use", then I have no disagreement. That's not how I interpreted "I've considered what might be necessary to dispose of server-side CSS."
> Github, Gmail, Google Maps, etc., are largely the exception to long-form informational content pages. I'm OK with an explicit "app mode" for such sites. But 99.999999% of what I read would do vastly better with uniform presentation.
I think that depends heavily on what you use the web for. You and I likely read a lot on the web. Some people might stick largely to Facebook and Gmail. There are people that spend a lot of time in Github, and others that spend very little. Some people use a lot of online organizational and collaboration tools, others none.
> More attention to content and semantic construction. Less to layout frippery.
What you call layout frippery, someone else desires. This sounds suspiciously like remaking the web for your use cases, not for general use cases (which are always changing). But I'm not sure there's even a problem to address, you already addressed through referencing "readability modes" as an example of presentation styles that do work well. Why isn't that your solution to this perceived problem?
It feels like you're trying to achieve the equivalent of forcing all the printers to agree to not print magazines that don't conform to someone's opinion of what a good magazine is. I'm just not sure why that's even desirable.
> Something tells me you'll not be convinced.
No, not yet, if I understand your position correctly.
Defaulting to standard formats, and, on the basis of improved semantic parsing and ranking, promoting them through higher Search rankings (ceterus paribus) would be a Good Thing.
Among the problems of present Web design is that the Web is an error condition (there's a wonderful essay exploring this), and browsers default to allowing broken behavior, even adapting themselves to it, explicitly.
The lack of a publishing gateway, even a minimal one which enforces markup correctness to the Web is a problem.
Layout frippery as pertains textual content has a rather well-supported basis. Complexity is the enemy of reliability, and more complex layouts offer far more ways for sites to break. That's a well-established fact that successive generations eventual learn (or fail to learn) at their peril.
(The phrase "Complexity is the enemy" itself dates to the 1950s. I'd have to check the year, but have remarked on it before. Source is The Economist newspaper.)
I've seen what happens when documents and other media are aimed at very specific readers. Eventually, they rot.
Bog-standard HTML (or some alternative markup -- I'm increasingly partial to LaTeX) tends, strongly, to avoid this.
You're also going back to ignoring points raised earlier in this conversation about security, privacy, and usability.
And yes, if there's a call for an app-based runtime environment, which Google seem quite bent on producing, well, that's a thing. But no need to fuck up the game for the rest of us.
And models which prove useful could and should be incorporated.
I'm pretty gobstopped, for example, that 25 years after its introduction there's no affordance in HTML for notes (e.g., footnotes, endnotes, sidenotes, as presentation is a client issue), or for hierarchical presentation, e.g., of comments threads.
On can create nested hierarchies, but one with an integrated expand/collapse/sort/filter functionality doesn't exist. This was extant in Usenet newsreaders and mail clients 20 years ago. Why not the Web?
I don't really have any issue with most of what you are saying, except "The lack of a publishing gateway, even a minimal one which enforces markup correctness to the Web is a problem.", and my issue with that really depends on how what you mean by "problem". Sure, a publishing gateway would enforce some conformity, and some level of conformity is beneficial (I'll even allow that more conformity than we currently have would be beneficial), but too much conformity is not. Too much conformity breeds stagnation. So i'll re-frame my stance: How do you enforce or encourage conformity without going to far? How do you keep the entity or entities you've entrusted this task to from going to far?
> You're also going back to ignoring points raised earlier in this conversation about security, privacy, and usability.
I was just working off your points, which all seemed to be about usability. I've been treating this discussion as somewhat distinct from that one. I can definitely make arguments about conformity having it's own negative aspects with regard to security.
We can begin by actually reviving browser user style sheets and having a well known and respected sets of names will allow for appropriate styling on the client.
I'm all for user style sheets, I see no problem in people overriding site defaults. Re: sites breaking existing functionality while changing, maybe I just don't see big regressions as having happened in Gmail (which I always have open) or Github (which I rarely have open, as my source is in a local repo, but I visit on a regular basis from links here and elsewhere). It is interesting that you mention keyboard mouse combos, when to my knowledge both sites have put specific effort into making keyboard shortcuts that work and allow some level of navigation without any mouse.
I have to use Gmail in static HTML mode so that it doesn't try to reinvent and fail at a text edit control for composing a mail.
GitHub has been, like Twitter, grabbing more key bindings that existed before in a web browser like Ctrl-K and their comment edit box got limited in its resizability, forcing me to edit outside the website and paste into it often enough that it's an annoyance.
> I have to use Gmail in static HTML mode so that it doesn't try to reinvent and fail at a text edit control for composing a mail.
I'm not really sure what you are referring to here. Gmail does attempt to give you an editor for emails, but it's extremely simple in my experience to get it to do what you want most the time. If your complaint is that you want it to just send a text email, and not a multi-part with a plain text version and an HTML version, in which case I have to question why, as all it does it add choice and allow people to view it in the format they prefer, and it should look the same either way.
> grabbing more key bindings that existed before in a web browser like Ctrl-K and their comment edit box got limited in its resizability
Re: key binding, yeah, I can see that as somewhat annoying. I suspect they are trying to match some standard usability map and thinking of their site as an application, but it's annoying that it interferes with the browser (but only when within a text input, from what I can tell).
To some degree, I have to agree with what's probably Github's stance, which is that it's their site, and while it may seem annoying in some respects, they may have specific reasons they do things. They obviously aren't going to be able to make every change something everyone likes, but I don't necessarily think they are making change for change's sake. It's likely in response to pressure from gitlab and competitors. Presumably they are audience testing. The best way you can speak to this is to not use them when possible, or urge others to not use them.
Re Gmail: the bug is that they replaced the browser text box edit control with their homegrown JavaScript solution which does not work at all. Copy/Past, scrolling, and many other features are broken with it. On top of that, you cannot resize it.
Re Github:
The big issue is that they start hijacking keys that were free before. It's hard to impossible to sway developers to use anything but Github. I've tried and been treated as if I'm in the luddite camp.
> homegrown JavaScript solution which does not work at all. Copy/Past, scrolling, and many other features are broken with it.
These all just work for me. I'm not sure what the specific complaints are, maybe it's a Firefox thing, but it's not like there's a lot in chrome that FF doesn't support.
> On top of that, you cannot resize it.
A little convoluted, but there is a way. In the subject of the thread, to the right, along with the collaps all control, there's the option to open the thread in a new window. This window can be resized, and since the input is the size of the window. Although, I suspect Gmail is meant to be viewed as more of an app than a site, so if the window size is not just about composing, but use, it might be worth using it as a freestanding browser window, distinct from and sized differently than other tabs, if you aren't already. I might actually play around with doing that not that I've said it.
> Re Github: The big issue is that they start hijacking keys that were free before. It's hard to impossible to sway developers to use anything but Github. I've tried and been treated as if I'm in the luddite camp.
Yeah, that's unfortunate, and I would have hoped Github would do better. I don't really think it's the norm though.
As cm3 notes, usability is as much if not more a concern than privacy and security. Though I'd not dislodge any of these three from a position of high primacy.
There's a risk / frequency trade off with all of these. Privacy can be quite possibly costly or fatal, though slightly more rare. Not so rare though that 20% of all Web users in a US Department of Commerce survey (see my recent comments history) report known credit card fraud. That's many tens of millions of affected users.
The security risks are similar but also extend to organisations which might stand to lose control over their own (validly) private information, or control over systems (see for example concerns over SCADA infrastructure, or industrial process control).
Usability and adaptability issues pose lower risks, but have a much larger affected field.
It goes well beyond the visually disabled, illiterate, and cognitively challenged. Anyone who's landed on a desktop site that's unusable on mobile has encountered a usability challenge. Google, Apple, Facebook, and Amazon are all rapidly pushing us, some kicking and screaming (I include myself) to an audible Web -- one in which the primary control and response interfaces are spoken.
What landing on a small set of templates does is provide for clearly parseable and understandable content. In a world where the goal isn't to read a full page but to extract and convey a useful item of information from it, wading verbally through megabytes of unparsable and nonexcludable content isn't particularly useful (and yes, figuring out how much a data reference is worth to the data-rerference intermediary is another question worth considering).
More generally, in my case, with only modest perceptual impairments (reading small, low-contrast type is among the earlier signs of your impending death), I've come to conclude for some years now that Web design isn't the solution, Web design is the problem. There are only so many ways you can present content that doesn't fuck with readability. I try, very hard, to ensure I'm not doing this on my own modest designs (look up "Edward Morbius's Motherfucking Web Page", a riff on a popular refrain, for my own principals in action).
My most common response when landing on a website is to sigh, roll my eyes, and dump it to something more readable. Firefox's Reader Mode. Pocket. Straight ASCII text. w3m.
And no, "novel graphic design" isn't conveying vast new amounts of information. I grew tired of hearing that argument 30 years ago, it's not got fresher since. Bloomberg, The New York Times, and the BBD are all experimenting with high-concept article formatting. In my experienct, without exception, it simply Gets In The Fucking Way.
My half-serious response to this is to create a new web browser embodying these and a few other principles. The working title is "the fuck your web design browser". FYWD for short.
Ninnies may opt to call it the Fine Young Western Dinosaurs browser as an alternative.
> My most common response when landing on a website is to sigh, roll my eyes, and dump it to something more readable. Firefox's Reader Mode. Pocket. Straight ASCII text. w3m.
> My half-serious response to this is to create a new web browser embodying these and a few other principles.
In all seriousness, I wonder if spoofing a mobile client (easily done through most browser developer console's or an extension) might immediately result in a more useful experience for you on the majority of sites. Given the viewing constraints of most mobile platforms, and the focus on mobile accessibility (it's supposed to account for over 50% of traffic now), I imagine many sites try to but some minimum level of effort in to at least make it usable.
The majority of my browsing is mobile these days. 10" tablet.
Even sites which are otherwise well-designed (Aeon and Medium come to mind) insist on dark-pattern behavior such as fixed headers/footers. Again: straight to reader-mode for that.
(Screenshots contrasting site and a Reader Mode session included.)
I've written directly with the site designer who seems utterly insensate to why 14pt font isn't in fact a majickal solution to all readability problems.
Really? That seems unlikely. I mostly see people use phones, and small tables, so <= 7".
> Except for the sites which break that. Violet Blue's Peerlyst comes to mind
There will always be someone thwarting best practices, just as there will always be those that skirt or break the rules in systems that are less lenient. There's not a lot of recourse, you want what they've got, so you are at their whim unless you can work around their imposed difficulties or find another source.
> I've written directly with the site designer who seems utterly insensate to why 14pt font isn't in fact a majickal solution to all readability problems.
See above :/
> HN itself is only barely usable.
Yeah, but I think the reasoning behind HN is slightly different. I suspect HN assumes you will takes some appropriate steps to optimize your use of the platform. Instead of "we will tailor the view to our artistic vision and you shall not besmirch it!" it's more of a "we believe in user agency, so get off your ass and make it better for yourself." Depending on your point of view, skill level, and site usage, you might find one more appealing than the other.
Personally, I use one of the browser extensions that allows collapsible comments, inline replying, and user info on hover over username.
> Really? That seems unlikely. I mostly see people use phones, and small tables, so <= 7".
Ignore that, I misread the sentence. I thought you were saying most mobile browsing is with a 10" tablet. I'm not trying to tell you that you're wrong about your own reported habits...
Mozilla's replacement to the Gecko engine that run's Firefox, written in rust. Often covered here[1], the benchmarks look really promising. Small portions of the codebase are already trickling back to FF where applicable.
The complexity and size of a modern web browser and the need to better engineering tools to combat this are often touted as some of the reasoning the Rust project started.
Not to mention I don't think it's a solution that's viable given economic principle and how much people value expression. We'd just be back to the equivalent of Flash sites again, with whatever takes over for flash (canvas?).