HTML is the Web
petelambert.com
petelambert.com
When people ask me why SEO isn't working. Well, try to see the first results on Google, and check their code. Most of the times you will see worsen HTML validation and semantics trumped over better (not perfect), not mentioning the first page is mostly paid ads. Google is not like back in the 2000s. Things has changed.
https://commons.wikimedia.org/wiki/File:Valid_XHTML_1.0.svg
I still have a hard time un-learning `<br />`
https://blogs.msdn.microsoft.com/ie/2010/11/01/xhtml-in-ie9/
While I often hear this "draconian error handling" about XML/XHTML by such people who then complain that a language compiler is just as draconian and real programmers complain when it's not and doesn't catch their every little mistake.
It's this lack of education and drive for the pursuit of knowledge and understanding that caused XHTML to fall out of favor and no other reason.
From https://html.spec.whatwg.org/#start-tags
> 6. Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.
From https://html.spec.whatwg.org/#void-elements
> Void elements: area, base, br, col, embed, hr, img, input, link, meta, param, source, track, wbr
The problem with making the SOLIDUS optional for so-called void elements is that the set of void elements isn't finite across time. A new one could be added in the future, which means any document which relies on implicit syntactic behavior requires an updated parser simply to get the most basic AST.
XML and XHTML formalized a distinction between syntax from semantics, permitting forward compatibility for code, like low-level parsers, only processing the syntax.
The WHATWG made the argument that out in the real world syntactically correct documents are almost the exception, not the norm. Because that's true the vision of being able to ubiquitously slice-and-dice documents with a shared syntax but distinct internal semantics was not attainable as a general matter. Any software consuming HTML out in the open universe would always need to be aware of contemporary HTML semantics even for low-level parsing. The insistence on separating syntax from semantics for HTML had a high cost but very little realized benefit.
However, the benefits are attainable within a closed universe, such as a CMS. And this is why HTML5 doesn't require, but nonetheless permits, XML- and XHTML-compliant syntax. It's not even treated as an error or exception, not in the way that other malformed but recoverable constructs are. A self-closing tag is syntactically valid, so there's absolutely no reason not to use it other than convenience. Excluding it out of convenience is perfectly acceptable, but in some situations--e.g. when using the more general and diverse ecosystems of XML and XSLT processors--it can be extremely inconvenient to exclude the SOLIDUS.
The lax nature of the HTML5 doctype did no one any favors. For most elements (`<br />` included) I still use a variant of XHTML Strict. Granted, it wasn't really necessary to have all the URLs and dates there, but to me, the only "correct" way to do this is with `<!DOCTYPE html>`.
The fact that validators don't choke on this is an accident of history.
This works properly in all modern browsers (Chrome, Firefox, Safari, Edge; PC, Mac, Android, iOS) and even Internet Explorer 11. Though in the past, I had to make concessions for older versions of IE, serving the same code as text/html instead.
I arranged things this way because I hand-write much of the HTML code on the site, and want to catch syntax errors as early as possible without the browser silently (and possibly incorrectly) fixing my mistakes. In any case, this is living proof that XHTML5 works.
document instanceof XMLDocument // false
document instanceof XMLDocument // trueOh boy, I'm supposed to stop doing that? Yikes ... when did that happen?
wait what ?
(I think `<br />` still works in HTML5 or maybe browsers just don't mind it, but it's not the recommended way.)
Arguably, it's bad style to use the same syntax for opening a tag as for a void tag, because it forces semantics into the syntax for trivial benefit. With out the "/", your HTML syntax parser now has to include a lexicon of all the void tags, and be updated with spec revisions.
These days, none of that occurs. Just try switching off Javascript (I use NoScript heavily to avoid invasive ad trackers). 75% of web pages don't load at all. Others completely mangle their layouts into an unnavigable mess. Only a very small subset of pages are readable. And these are just landing pages - pages that should welcome one and all to the site. Most of the time, unless I'm looking for something specific on the site, if it loads a blank or mangled page, I just move on. If everything's a dynamically-arranged <div>, the browser has no hope of making sense of it.
You can lead a horse to water, sure...
That synths article uses built in JavaScript synths (using audio apis). I agree the text should display without JavaScript but the purpose of the article (get hands on with synths) is eliminated without JS.
Basically, the web not only is a document delivery place, it's also the new Newgrounds. None of those games would work if you disabled flash, why should web applications (beyond ones that are simple documents) work without JavaScript?
If there is nothing to read, there is no way to know there is any app, let alone decide that I want it to run.
> why should web applications (beyond ones that are simple documents) work without JavaScript?
I imagine that the other kind of web app does everything with POST and forms and such like it's 2003, and I can understand that you'd prefer not to. I'm not saying they should or that they must all do without JS. I'm saying that if the article was a document that (also) documented the proper use of the web app within it then I would have liked to have been free to read it first. NoScript blocks <embed>ded things all the time and I temporarily allow them all the time. That workflow would have worked here, but if (as you seem to suggest is reasonable) the entire article was blocked because its app would be useless, then my strategy wasn't even considered, and someone is doing it wrong.
However, if a goal was to teach everyone to just run anything and everything and stop caring about privacy and security because it's a PITA, then someone is doing it right. I sure miss the good old days of Weekly_Report.doc.exe
> What about web applications?
I would say is depends upon the application.
A data entry and simple reporting service? That should definitely be accessible and can easily be made to work without JS. Though some scripting might be acceptable: modern screen readers will cope and holding back for people with ancient screen readers is no different to holding back because some people still use IE or Android 4.4 (though do some research/testing to see what they actually w{ill|on't} commonly cope with).
If it is an interactive game or similar then you are not going to replace that practically with form submissions and no JS, so by all means don't bother caring that it doesn't work without JS. Though do make sure you include a <noscript> tag if otherwise nothing useful would display, just so users know what is going on and there isn't a fault at their end or a fault in your app that they should report.
Anything between is a grey area: you'll have to use your best judgement of your actual and potential target audiences. Though again, make sure something useful displays for everyone even if that is just a polite "sorry, we can't get this working for you" message.
>The noscript element is a blunt instrument. Sometimes, scripts might be enabled, but for some reason the page's script might fail. For this reason, it's generally better to avoid using noscript, and to instead design the script to change the page from being a scriptless page to a scripted page on the fly, as in the next example
https://html.spec.whatwg.org/multipage/scripting.html#the-no...
Probably "according to the original designers' intent," see this comment below you: https://news.ycombinator.com/item?id=20284550
This can be directly attributed to the fact that the purpose of the average webpage is no longer to convey information, but to display ads.
I frequently see people say that if a site doesn't allow people with an ad blocker to read their content, they immediately bounce off the site, and that site loses a visitor. What I don't think people get is that this is what those sites want.
They don't care about pageviews or impressions. They care about ad views. Someone with an ad blocker uses their bandwidth, but doesn't increase revenue.
To an extent, the more important conveying information is, the more likely the page is to gracefully degrade. Of course, even that is mitigated by the fact that most people throwing up a web page are either hosted by a commercial platform (Medium, et al), or at the very least using a popular framework that is designed with commercial usage in mind.
This is a horrible state to be in. I mean, I get that advertising is the only way to make regular money on the web, but dear god, we are in a sad situation where people who don't want to be blasted with advertising aren't made welcome.
I primarily work with ecom, and we build highly dynamic sites in an increasingly rapid arms race for engaging design.
Before vue I worked with jQuery like everyone else, controlling the dom manually to react to changes in application state. Those were dark days.
Now I can manage the cart state and increasingly everything else over apis and have the application display all these updates in real time, along with all the whizz bang the design team decides is flavour of the week. All in not much more time than jQuery and basic layouts previously took.
So, sorry if my site doesn't load without JS, but it's not about the ads. The web isn't just document display anymore, everything is an app.
What I am protesting, however, is that graceful degredation doesn't happen. The entire site either breaks or blocks you from viewing static content unless you enable JS. Why am I prevented from viewing a product's information page before I decide whether or not I want to add it to the cart? Why does a news article render as 3 columns of disjointed text that are unreadable until they're assembled? Why don't images load at all unless I permit a CDN to shove a load of JS into my browser for fancy slideshows, zooming, whatever, rather than just placing a small static image there so I can decide if I want to zoom into the dynamic larger image?
The worst ones are those that pop up a banner or overlay that darkens the page with the loaded article until I enable JS. Like, you have literally proved your page works without JS. There is literally no reason for me to enable it, except for you to load several different analytics modules that chew up my CPU and siphon as much identifiable data as they can get their hands on.
Ultimately all website are optimised for their target audience, if 30% of our users used IE6 then we would (sadly) target that. If users value ease of use on a baseline browser then that is prioritised, and if static information and nojs turned out to be what most users valued highly then we would do that too.
For us, the arms race is that other one about getting code to execute on people's machines, including the virtual ones, versus preventing that. The mere existence of good code that is worth running makes it a hard problem. More of that just makes it more pressing even if not actually harder.
> Ultimately all website are optimised for their target audience
Ultimately all audiences are being optimized for the ideal website which shares its ideal viewing conditions with websites that are being used against the users (i.e. code runs even though we don't know or explicitly trust the authors or their employers or really anyone around it).
> banner or overlay that darkens the page
Sometimes with ABP or UBO you can right-click and blow out that <div> which their JS would have cheerfully made invisible. Also, sometimes FF's "reader view" blanks everything but the meat of the article even if the article was hidden. (you probably know that-- for future reference and any passers-by, until the world breaks it all again. vive la révolution)
Hands down, this was the comment I was looking for to agree with.
A large majority of whizz bang the design team decides, can be done just with HTML 5 and CSS 3.
Vue replaces the dom of wherever the app is, so the choice is between having everything within a single app div or having a ton of apps talking to each other. Given that the ton of apps solution still breaks fairly essential functionality (for online shopping) and requires a fair amount more structure it's a bit hard to see the benefits.
But the point I think the author is trying to make is that whether you do or don’t use a framework, you need to understand the fundamentals. The fundamental language of a browser has always been HTML. JavaScript and CSS are great and came along in due time but before all that there was HTML. So whether you’re simply marking up a document or building a full-fledged web app with React or Vue, you’re doing yourself a disservice by not learning and using proper HTML.
IMHO in the sense of fundamentalism all major frameworks tried to reimplement and resemble HTML (or its dialect) and browsers on existing HTML and browsers, which eliminated divergence of platforms for developers, relieving them from dealing with variations of users’ environment, i.e. the differences of browsers and HTML implementations. It was a transfer of control from client end to server end, from users to websites, implicitly.
It's perfectly malleable - I can make every page do exactly what I want it to. It's lean and fast - every page even with all the interactive plots, games and quizzes, and syntax highlighting, is still under 64K. And it doesn't accumulate technical debt. There are no dependencies, even within the project. An occasional bug from the past wouldn't bite me in the future.
At the beginning, I thought that typing the HTML by hand would be too tedious. But it's not. It is a bit boring, sure, but it's only like 5% of all the work so usually I don't really want to automate it.
And when I do, I just write scripts that handle HTML just like any other text. Works wonders for me.
Your site looks nice, but one comment I'll make about your coding style is that you (or anyone getting inspired from your code) should probably switch away from innerHTML as the default choice for DOM modification. In a lot of otherwise useful contexts it is an HTML injection hole. (For the record it doesn't seem to be a security issue for the kind of content you have made, but better kill the habit before it becomes a problem.)
For a while I used document.createElement and friends to generate injection-free DOM, but that style takes a lot more typing than innerHTML usually does. Eventually I made a tiny library for easing the job, and I haven't looked back since. I don't think anyone else uses it, but so far it is definitely worth it for the one happy user. https://github.com/NoHatCoder/DOM_Maker
I wonder how you manage your overall style, though. Is your design set in stone, do you never change it or fix quirks? If you e.g. change from GitHub to GitLab, would you edit the footer of every single page?
One small suggestion: Please advertise your RSS feed to the browser using the <link rel="alternate" ...> tag. Ideally on every page. Otherwise, visitors of your blog articles (like myself) get the wrong impression that you don't provide a feed, until they go back to the main page and scroll down to the bottom.
<button class="minor red labeled button">
<div class="ui list">
<div class="ui list item">...</div>
<div class="ui list item">...</div>
</div>
So presumably the 'proper' way to do it, if you're not looking for convenience, is to use `div`s. /s
You could always use a little classname vomit to go with your div soup.
The problem is that "modern" development has misplaced importance. It's become an incredibly selfish practice. There is more concern placed for the developers than the users.
Personally I think the web should evolve to play to its strengths: Simplicity, Flexibility, Separation of data from code and from style.
It'd be nice if instead of trying to shove javascript into every hole because it happened to be bundled with browsers, we pushed browsers to bundle more runtimes for client-side work (a WASM standard library if you like), so that the web can continue to be a place where you can post about javascript on a server running arc software, and not care which technology the server or server uses, which can be swapped out at will. One of the great joys of web development from my point of view is not being tied to a particular language or ecosystem, because the web is heterogeneous.
No it's not. It never was. Even a long time ago when websites were static things rendered by the browser once and then left alone there was always a tree of nodes underlying everything. The only thing that's changed in the past three decades is that now when we make websites and web apps we often ship a little JS application that lets the user modify the underlying tree. That's what the web is now and HTML is just what we use to describe the initial state of the tree (and arguably it's the wrong language for that job, but hey ho). Using semantic markup is important for a bunch of things like accessibility, but you can't really expect the initial state of the page to stay the same after it's loaded, and software that renders things from the web has to deal with that.
If you're old enough you might remember that once there were no stylesheets. HTML wasn't just the content and structure, but also the visual description. We used font tags. We used color attributes. We used spacer gifs. We don't do that now because it sucked. We moved forwards. The same is becoming true for HTML. Users demanded interactivity, and we gave them exactly that, and browsers turned in to things that run little applications rather than things that render mark up. The web has grown and evolved and moved on, and thinking of the web as "HTML pages" is just plain out of date.
That's not to say static content isn't still useful. It is. Very useful. But static HTML pages isn't the web, and the single page application genie isn't going back in the bottle.
As I like to occasionally point out in wasm threads, the browser was a thing that ran little applications all along, in the form of Java applets. I have yet to see an explanation of how wasm applets are a different approach to the problem, but they sure are a more popular one.
Also Java tried to be a gateway out of the browser to the OS, and that's just a terrible idea for security. WASM isn't trying to be that, and hopefully it never will.
Given that almost every thread about WASM includes someone like yourself wondering why it isn't just a pointless rehash of the JVM, I have to assume you would have already seen the numerous discussions about the differences at length.
Here is one: wasm is smaller and better sandboxed
Viewing "pages" and "apps" as wholly separate and mutually hostile paradigms seems to be a recent cultural development born more out of frustration with advertising and modern complexity than any technically meaningful distinction between the two.
Well there is a pretty fundamental tension between programs written in a Turing-complete language and a program written in one that is not. Resorting to too much power too early is dangerous and messy.
Maybe, but you still can't consider anything running javascript an "app" and anything not a "document," since interactivity and state isn't bound to running javascript, and most javascript is just used to render documents.
My point is that the distinction people draw between the two is more emotional than technical.
>Resorting to too much power too early is dangerous and messy.
To be fair, notwithstanding exploits in the underlying browser or hardware which lead to things like Spectre, at least javascript is sandboxed. No one is going to be able to sneak "rm -rf /*" into a script and have it work the way they could a native application.
It is fair to note this, but I would still take those examples as indicating the inherent dangers and failures of the paradigm. It's obviously infinitely better than just naively sticking native code execution into the browser without any protection at all, but that does not mean it is ultimately a good approach.
... yes ? the name of this "tree of nodes" is not "Document object model" for nothing.
There's no native way to link to specific objects in the DOM that are not identified as part of the document through an ID; the anonymous objects in the DOM can only be accessed programmatically, URLs have no syntax to traverse the tree like there is an "#anchor" section for accessing chapters.
We almost had it at one stage
(Citation needed.)
Developers love interactivity. Users despise it but put up with it because there's not much choice.
Does anybody think the Web is a better experience now than it was 15 years ago? Honestly?
They didn't demand it per se because no one actually asked. I'm inferring from the fact that users spent much more time on the interactive websites which resulted in more revenue for those sites and everyone else copying. There might have been a reason other than the interactivity itself, but we are where we are now because of user behaviour.
How efficient? The most popular sites on the internet are about _fun_, not _efficiency_ ;-)
Single page applications are the corporate web. The profit web. The web that exists to squeeze information and money out of you without ever sharing or exposing any of itself. SPA are a cancer on the web that aren't going back in the bottle. Corps are gonna corp and institutions will follow.
But you, the single web dev, don't have to take this bullshit design philosophy home with you. Just because you have to shovel manure at work doesn't mean it's beautiful or that you need to bring the shovel home for personal projects. Get paid for shoveling shit. At home make real web pages.
Source: The HTML 3 Specification.
It started out that way, but grew to TRY to replace GUI's, Flash, etc.
We need three different standards: one for documents (HTML may be good enough); one for media, art, and games; and one for desktop-like GUI's. There may be some overlap between these, but the one-size-fits-all of HTML/CS/JS has been a big messy time-sink where otherwise simple UI tasks take rocket science and luck to get right.
These are low level enough, and powerful enough that you can build document, multimedia or application frameworks on top of them. Simple UI tasks don't take rocket science, they take a proper understanding of those three standards, and a lot of discipline.
I appears to me you are contradicting yourself. It comes across as: "It doesn't take the discipline of rocket science, but merely the discipline of rocket science". GUI's didn't take "a lot of discipline" in say VB-classic, Delphi, or Oracle Forms[1]: you dragged it to where you intended it to be, and Wazaam, it was there and always there. WYSIWYG was a huuuge time-saver. Now to do it right you have to test on dozens of platforms and versions because they each have a mind of their own. WYSIWYG gave you one central coordinate reference point, not 30 different positioning engines.
Re: "We already have 3 different standards: HTML, CSS, JavaScript."
That's part of the problem, not a solution. They are not domain-specific, for one.
[1] They had glitches, but were getting better over time.
rocket science !== discipline
VB-classic, Delphi, or Oracle Forms have whats known as drag-and-drop/visual programming. Comparing them to CSS & HTML isn't a fair comparison, unless you compare that to a drag-and-drop GUI that creates HTML & CSS for you.
It would be nice if operating systems would be exactly that, but for some reason "commercial" OS vendors are not able or willing to provide a safe "native" sandbox completely uncoupled from curated app stores.
The ability of a browser to be a document viewer with a very limited layout system should be implemented in an optional layer on top of a bare bones browser.
Again, this should all be provided by the underlying operating systems (click an URL and instantly run cross-platform applications in a safe sandbox), but for some reason we didn't get that. It's the same with Electron apps by the way, those wouldn't exist if operating systems would come with cross-platform UI frameworks that are actually better than the unholy mix of HTML+CSS+JS. But Microsoft, Apple etc... had decades to get their act together without delivering.
I agree with you that the URL is the most important feature of the web. Without it, you could just as well deploy native apps because it wouldn't really make that much of a difference.
Without javascript and a heavy client side, I wouldn't have a job today since the application I build is simply not possible to create with just html+css.
Sure there are many web pages that don't need to be a SPA, but a lot of other webpages do need it. I think an increasing amount of webpages are not simply text documents but we can easily see a move from traditional applications to web applications.
It's obvious why, it is truly a "write once, run everywhere" scenario, it's easy to scale on many different devices and there is little to no advantages to write a native app in most circumstances.
The document web has already been done, just use wordpress or whatever framework to create those sites but the new exciting web for me is the more interactive web where we can seriously move heavy apps into the browser.
What's happening now is like trying to force ftp to show documents, with markup, and forms, and so forth when it's just supposed to transfer data.
The web was never intended to only ever be static, nor is scripting in the browser somehow a corruption or aberration of the web's original purpose. If anything, the web should have been a lot more programmable[1] than it turned out to be.
[0]https://www.w3.org/TR/2018/SPSD-html32-20180315/#script
[1]https://eager.io/blog/a-brief-history-of-weird-scripting-lan...
I am content with what we got and are happy about it. I think it works pretty great after all.
I use linux as well and I have yet to find a webpage that doesn't work with Firefox and Brave.
Maybe you shouldn't block javascript and instead block trackers and ads. There are a lot of tools to do that like uBlock Origin, pi-hole, privacy badger etc.
Javascript is used by pretty much all websites today to do mostly other stuff than tracking. Why are you blocking it if I may ask?
Also, I am very curious (I really am), what websites do you visit daily? I'm sure at least some of them are depending on javascript and couldn't be solved with html+css alone?
I use uBlock Origin at home. I use NoScript at work. I like it because it blocks ads and because it does break much of the web. I don't want auto-playing videos, I don't want an enhanced experience, I just want to find the information I'm looking for. If the website I go to won't show me anything even after enabling the main domain and a CDN, then I move on to the next choice. Enabling js on the main domain usually makes menus and such work. The rest seems to be ad-related, from what I can tell.
There are a handful of sites where I really am looking for an enhanced experience. Mainly my banking sites, sites I frequent for shopping, and some forums. Most other places I visit I'm happy that the site is mostly broken as long as I can see what I went there to find. In many cases, I'd be happier with a 90's era gray page with text and pictures. But then I'm old.
If you want, I can tell you some of the apps I use. I use Slack, Telegram, Visual Studio Code, Discord, Tidal (as a PWA) and a bunch of other web apps.
Some apps I really do require to be fancy, like fastmail. Using it with normal forms and no ajax would suck imo.
I am myself also building an app where we heavily rely on a map and rendering stuff upon it. It is very interactive, and it would not be possible (at least to the extent that we want to deliver it) to make it without javascript.
I also think most of the "desktop" apps I heavily use wouldn't really exist for linux if electron didn't exist which is kind of sad.
But now they do and they work wonders, so good I use them every day. You can barely tell that Discord or Visual Studio Code is web apps nowadays since they work so damn good, better than most hacky open source alternatives that exist for linux.
I think it's cool that you and some other people can have a functional user experience without javascript but for me it's simply not possible if I want to enjoy all the benefits that running with javascript enables me.
I actually rather use web apps, progressive web apps etc than install a native app that can ruin my entire computer. They are equally fast nowadays, web apps often get updates a lot faster and it isn't a risk to update the app. Just refresh the app and everything is safe and sound, especially with PWAs.
Just check this screenshot, it even looks native (and hardware keys work fine):
That sounds like it would be great if it were even possible. What about the million times that someone relies on ajax.googleapis.com and forces me to either allow it or walk away? Am I really supposed to believe that Google isn't logging my visit, each and every time I get a script from there to restore the functionality to or even put text into someone's page?
And then, what will we do about any original domain owners (hypothetically) cooperating with them by hosting such scripts in order to go under the uBlock radar and keep getting paid? What about sites that intentionally host and run whatever malicious scripts themselves? Right now it is merely convenient that we can often choose (correctly) to run or block based on URLs alone, and I don't expect that to last.
I just admitted to everyone that if there are blocking mechanisms which work around other bits besides URLs, I haven't heard of them. I just admitted to myself that I have no real reason to think that it's even enough, and I might be just punishing myself and making everything needlessly difficult-- for my own little privacy theater.
I suppose that unless uBlock or Pi-Hole can (someday) analyze every script in every page (hopefully in sub-second time), and determine whether it is cosmetic or mandatory or exploitative or malicious based on nothing but the code and the context, we lose anyway.
I think privacy is important, but to a certain extent. I think I am pretty tin foiled when it comes to integrity. I don't use any social networks, I don't publish my images and location to everyone. I use services that encrypt my information like SpiderOak for backups and I use encryption on my disk.
That said, some things ought to be allowed like loading a crappy jquery file from google cdn. Sure they will log that visit, but comon that is just like visiting a GCP site. The same amount of logs can be made from that.
I think you provide some valid points, but I think your fears are a bit too far fetched. I also fear Google and Facebook. I use DuckDuckGo as my main search engine and I try to not use Google products. I don't think you can do so much more than that to be honest.
I think the W3C are a big part of why the web works so well cross-platform... even though the web was supposed to be "so much more". It's quite hard to imagine a similar kind of body for cross-platform UI frameworks.
It is not perfect, but it feels a lot more native on every platform than virtually any web or electron app I have seen (including predictable keyboard shortcuts).
Flash tried to do this 15-20 years ago. Flash was basically "here's a canvas, do whatever you want within reason". It had its use cases back then but the general web vastly preferred good old HTML and eventually CSS and JS.
There's a lot of value in having constraints, especially when those constraints (HTML) are specifically designed for displaying documents.
- it was owned and controlled by a single company and thus a target for other companies instead of other companies helping to improve it
- that single company was unable or unwilling to fix security holes in the sandbox and browser makers eventually got fed up with that
- while there were some ways to interact with the underlying browser environment, ultimately a Flash instance lived in its own little bubble, creating usability problems
Putting the HTML+CSS layout engine into a separate module doesn't mean that it wouldn't remain the standard way of doing document-layouts on the web, it would just mean that higher-level solutions wouldn't need to use hacks and workarounds to map their concepts to HTML+CSS (same way as Javascript had to be used as a less-than-perfect compile target before WASM because it was the only option to run code in a browser).
The thing is, most people don't want a blank canvas to go nuts with for the general use case. It's too complicated. Suddenly you need to learn entire SDKs and pull in many dependencies just to render text on the screen.
The reason HTML and the web was so well accepted back in the day was all you had to learn were a few HTML tags, a couple of properties and then drop it onto a Geocities site and you were good to go. It was something you can do and see real progress on in 10 minutes with very little background knowledge.
Compare that to now where if you wanted to be a "trendy front-end dev" you would probably reach for Vue / React + Webpack* and go SPA style for all of the sites you make because you learned something and now you want to apply it everywhere. Meanwhile to serve a document such as a blog post, you just went from having 15 HTML tags in a single HTML file and some CSS to pulling megabytes of Javascript sprawled across hundreds of dependencies and now you have build tools, an entire runtime environment (Node) and are using APIs that don't exactly match up with HTML exactly, and then your entire site isn't even crawlable by search engines unless you introduce even more complexity to do server side rendering and before you know it, you're dealing with something that's even more complicated than Flash was back in the day.
* I personally use Webpack to handle my assets too, but I don't write SPAs for sites that are document based (which tbh are most sites).
Are you kidding me? Flash was an absurdly popular platform. Careers were launched on Newgrounds!
I'm not saying it wasn't popular, but what do you think the percent spread was between sites that were fully driven by Flash vs not Flash?
I don't have the stats in front of me, but I would guess it was probably 2% Flash vs 98% non-Flash. Now, a lot of sites had sprinkles of Flash but very few sites in the grand scheme of things were solely rendered with Flash. Part of the 2% were sites like 2advanced studios.
...yeah, because that's not what Flash was about. Flash was an application platform (ok, so more like an Animation platform) first and foremost. Why would anyone run their whole site in flash? It wasn't the right tool for that job.
And this is exactly what I'm trying to say.
Back in the day you would very likely reach for Flash if you wanted to build an FTP client that ran in a browser. Totally reasonable use case because that's a highly interactive app that doesn't really follow the request / response style of a document style page. But you likely wouldn't reach for Flash to build some type of site that presented data in a document style (pretty much the general use case of what a website outputs).
But if you fast forward to today's technology, some front end developers are bringing in the complexity of creating SPA style applications that are primarily rendered with JS for everything -- even document style websites like a personal blog and the original comment I replied to is hinting they want to remove constraints from browsers to give us more of a FFA style of doing whatever we want to render pages. I was just saying that model didn't really take off for the general use case with Flash decades ago.
Fortunately we still live in a time where web developers can choose what they want to do, but browsers shouldn't change the concept of being something that renders HTML that is optionally combined with other things like CSS, fonts, JS and images.
If people really wanted a no constraints platform to build any UI they want with a blank slate then web development as we know it today would be a completely different environment.
Instead, 20 years later, we're still trucking along with HTML as being the primary focus, and everything else can be loaded as needed.
You can build some pretty amazing things today with a combination of HTML, CSS, JS, fonts and websockets. But at the same time, if you don't need an application and just want to serve a HN style site, you can render HTML with a bit of CSS and everything works well. To me, that's one hell of a success story.
I'm not sure that happened. My friends and I got on MSN Messenger and shared flash sites all the time. Kongregate and similar gaming sites were part of it, but so was YouTube, and so were greeting card sites, ESPN, various other news sites and many, many others.
At least from my POV, maybe a few people hanging out places like here didn't like flash, but the general population had no problems with it until Steve Jobs did his best to kill it. Even then, people not on iPods/Pads/Phones didn't seem to have any problems with it. AFIK, the fast majority of people still installed it years later.
- It wasn't visually scalable. (Today we say "responsive", mostly, but that's too easy to confuse.)
- It didn't integrate with HTML and CSS in any interesting way other than sitting there in the middle.
- Performance was mediocre to terrible.
- A rent-seeking company was in charge of it.
As you say, eventually JS supplanted it.
Regarding integration, some text elements featured basic HTML capabilities. Nothing terrific, but you could extend on this. (And, of course, XML parsing, but this is another story.) Also, later Flash Player applications (Air) featured a full-fledged WebKit element for rendering web views. That said, it was good thing that Flash had eventually to go, and, at times, the state of the web today is pretty reminding of this.
For the user, flash applets where super easy to block in general and to whitelist on pages where you wanted to use that particular flash application. Basically the same was true with Java. And for a certain extend JavaScript -- until the ugly DHTML menus arised and websites stopped to be usable without JavaScript.
Nowadays there are only two options: Either you block JavaScript --- and percieve a 1995's web view, in general --- or you let it run on your browser, having tons of programs running which you probably don't want (ads, tracking, that particular application that replaces flash).
It isn't used because it's just not how the suppliers of content nor consumers of the web want to use the web.
If they want a full featured app, they use it. Even with super fast speeds, latency and minimal startup time still make the browser unattractive for this.
Web users and content providers want linkable documents.
I'd argue that the modern browser stack is so good that we see installed apps adopting html/css/js for the presentation layer.
Of course this goes hand in hand with an instant start (no dreaded splash screens please), and not having to download gigabytes upon gigabytes of data upfront.
Modern web apps might be bad at this, and browser engines might be bloated, but native apps aren't any better (even heavy web pages still load many times faster than - for instance - starting Visual Studio or Photoshop).
The maximum speed of moving data from one physical place to another, moving data from the hard drive to the motherboard and the ram to the cpu/cache is faster than from the internet to a computer. To he speed of light is still noticably slow when you're making round trips to get data.
The other issue is configuration, even if automated, software needs to make decisions about how to deal with different hardware and system differences. This takes time to bootstrap after initial load increase time to usuability or it can be done on the fly slowing down the interactions.
Once I "install" an application, for example libreoffice:
- It works even if I do not have a working Internet connection (or back in the day, even if I had removed the original media from the drive);
- It works even if the original is gone.
That is, by "installing" an application, I gain a permanent, offline, working copy of it.
On the other hand, PWAs (Progressive Web Apps) also work in offline mode without a "traditional" installation step.
"Traditional" applications that are subscription-only are only partially installed, if their full functionality requires always-on connectivity.
Stay offline for 30 days (iirc) and try to play the games you paid for.
Please stop saying this as if it is in any way acceptable. Some parts of the computing world work like this, but this is not, nor should it ever be, the new normal.
You can still definitely use your computer without resorting to such licensed crapware.
All the HTML+CSS+JS stuff only makes browsers difficult to secure, and also causes bloat and performance issues when they are not needed.
Furthermore, all these hairy web specifications cause compatibility issues, and are a barrier to entry for new browser makers.
If people want HTML or CSS or JS, then they should implement these inside the sandbox. In practice, this would mean that developers would simply include one of the standard libs for rendering HTML, etc., and these standard libraries can be cached by the browser, so their use does not cause performance/bandwidth penalties.
Here's how you do it: create the new platform and its spec. Include an open 'document rendering engine' to replace that portion of the web. For backwards compatibility, go ahead and port a web browser to the new platform. For forwards compatibility, port the new platform to the current web.
You are completely free to write and launch a new app that does this today. Just don't try and shoehorn it into my web browser.
It's "the sandboxed, browser agnostic web".
Won’t make them “useless”, maybe inconvenient for non-security minded individuals.
There are very few RCEs now on modern browser (they still exist[0,1], though). The main threat is phishing, because users are gullible (and should be educated).
[0] https://www.mozilla.org/en-US/security/advisories/mfsa2019-1...
> the important feature of the browser is that it provides a sandboxed platform for running untrusted code without a builtin "walled garden moral police".
> for some reason "commercial" OS vendors are not able or willing to provide a safe "native" sandbox completely uncoupled from curated app stores.
The key word here is absolutely "unwilling". All the platform vendors want platform lock-in, they don't want a general purpose platform. Microsoft originally tried to do this to the web with ActiveX, before even Flash. At least Flash was slightly cross-platform in that Adobe provided Mac and Linux versions. These days no platform vendor is going to give up their 30% cut voluntarily.
In a world of fully general app sandboxes, you can switch out your hardware and OS at any time without disrupting your life or business. Therefore those are commoditized, and their price drops to the marginal cost of production - which for software is zero.
(Also I think CS theory took a while to catch up to practical security; everyone used to teach the model in which multi-user systems were trying to protect users from one another, not one where a single-user system is trying to protect the user from predatory apps, viruses and potentially unwanted programs.)
I think software's marginal cost of production is zero only if no updates/fixes are ever needed. I know it sounds like nitpicking but just think of all the vulnerabilities discovered, specially the closer software gets to the lower end of the stack. Even if an OS could suddenly stop adding features and still be viable in the market, the cost of patching it as holes are discovered is certainly not zero.
It certainly is a real cost that has encouraged software vendors to move from "box" sales (which became tricky when we gave up on boxes) to annual licenses and/or SaaS. But it's not a marginal cost.
Paradigm 1 - interconnected, hyperlinked web of text-and-content-based documents: open, accessible, amenable to indexing and tooling and so forth.
Paradigm 2 - delivery vehicle for cross-platform, full-featured, somewhat-security-sandboxed, applications.
I agree with the article that it's sad if Paradigm 1 is trampled to make way for Paradigm 2, just because (as you point out) we haven't been able to develop a viable alternative. In theory these could coexist, but the point of the article is people are being trained in Paradigm 2 and try to use it for purposes that are much more suited for Paradigm 1.
Just as sad, Paradigm 1 is more oriented around decentralization, giving power, options, and information to the user; Paradigm 2 is often exploited for lock-in, control over user's decisions, collecting information about the user, etc.
To me, the Browser is the most widely distributed sandbox runtime ever! It’s just missing a few crucial things we plan to add soon :-)
It can be used to update itself, too :-)
Hopefully, but people have a large capacity to deal with broken web software. Back when I was young, it was all the Java & .Net websites that turned every friggin link into a POST form so that navigating back, and opening in a new window was completely broken.
Go on?
But mostly because it's usually unnecessary and smacks of laziness on the developer's part.
Buttons by default have keyboard support for focusing and clicking. You’d have to manually add this to a div.
Screenreaders, scrapers, and other automated tools reading your html understand buttons and treat them differently from divs.
It’s easier for other devs to understand your code at a glance if clickable elements are buttons.
Does it semantically make the most sense? Not necessarily, but it isn't a blocker to most accessibility tools and use and support for ARIA attributes is pretty widespread nowadays, including all of the major browsers and screen readers.
> https://developers.google.com/web/fundamentals/accessibility...
> https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
The important point is that fundamentally using a <div> in place of <button> can still be made to work easily with these accessibility tools - many comments here imply it can't be done at all and only a button will work. Does it semantically make sense? Likely no, but it isn't a hard blocker on accessibility.
In a clean (from scratch) dev situation, when would it make sense to use the div option?
I read a lot of articles about front end, including framework & library trends, usage statistics, rumors, etc., though I've never heard that React has begun to die. Can you provide a citation?
I tend to prefer semantic tags most of the time. I do wish there was a CSS declaration, or maybe an <html> attribute to start off with absolutely NO styling, so that it all comes up from what's in the CSS only. Various resets suck or don't work well, or are really big for various reasons. For that matter, being able to reset everything under a given element that way so that in-browser rules aren't applied would be really nice for WebComponents.
My own weakest point is probably on CSS these days, I just haven't really kept up since 2.x as I haven't really needed to, and can usually google when I need more. I feel the flexbox stuff is more complex than it should be.
Browser vendors (Firefox, Chrome, Brave) please get your act together to prevent https://nothingprivate.ml
The need to serve Paradigm 2 existed all over the place in the plain html days.
It’s just instead of having standards-based languages for Paradigm 2, we used to embed janky Flash SWFs and Java applets, were dependent on single vendors to patch zero-days in closed source code, and had to pay hundreds of dollars for licenses for developer tools.
Today’s Paradigm 2 now has multiple competing implementations, open standards, and powerful DOM inspectors in almost every web browser to tear apart any modern Paradigm 2 app you come across.
I think today’s Paradigm 2 gives more power to users than the Paradigm 2 of the past :)
From a user's perspective, it's maybe a bit more nuanced... I'm tired of websites trying to get around my adblocker, and everyone attempting to enable desktop notifications, for example. If I'm trying to read someone's document they've published, I'd like it to just be a document, thanks. But, increasingly, "Paradigm 2" webapps like Spotify and Google docs are as good or better than "rich" desktop apps.
Also agreed, many web apps these days are as good or better than desktop. I actually have worked and am working on applications that replace their desktop counterparts. They're practically easier to scale, tend to have tooling to handle window sizes better, customization is easier and imho just nicer to write against. Better still if you don't have to support legacy browsers. Most browsers today are supporting modules and async import. Still using Webpack and Babel for JSX, but really close to a point where I'd just assume write for esm and have a server-side translation for JSX on demand (cached).
That being said - I agree with your ideal, and I don't think it's far off. HTML as a view engine combined with WASM as a cross-platform runtime can enable truly cross-platform, industry-standard native applications. I think it's only a matter of time until Electron apps morph into cross-platform native apps running off of a thin WASM layer. Once those are available, then the OS vendors will have a huge competitive advantage if they develop fast native WASM runtimes.
Apple is going down this route with code signing and granular permissions with Macintosh applications that don’t have to be part of the Mac App Store and there is still whining from geeks that this is leading to a walled garden, even though there are approved ways to work around it.
It's the same with Electron apps by the way, those wouldn't exist if operating systems would come with cross-platform UI frameworks that are actually better than the unholy mix of HTML+CSS+JS. But Microsoft, Apple etc... had decades to get their act together without delivering.
One of the problems with Electron is that it’s the same interface everywhere. I don’t want the same interface on a Mac that I have on Windows.
They haven't done it because it doesn't bring any benefits to the greedy corps, and apple is the worst offender with their dumbed down, shackled os
So how is MacOS - a real certified Unix OS “dumbed down”?
Edit: Corrected Link
https://www.cnet.com/news/fortnites-battle-royale-with-andro...
https://www.cnet.com/news/fortnites-battle-royale-with-andro...
A storm of security issues is closing in on the Android version of Fortnite. And it isn't likely to pass anytime soon.
Developer Epic Games just fixed a security flaw with Fortnite's installer for Android devices, but researchers are expecting a flurry of problems for the online game as it gets more popular on Android.
That's because Fortnite isn't available through Google's Play Store. Epic instead chose an unorthodox -- and more dangerous -- route for the game's fans. Rather than download it through the official Google app store, players need to download the game and "sideload" the app on their Android devices instead.
Now in both cases, you can just make your app a fullscreen canvas or opengl/metal viewport or whatever and manually render everything to that while manually handling user input, but you lose interactivity, accessibility, extensibility, etc.
Mostly this already works, I can open a standard file dialog, or copy data into or out of the system-wide clipboard. If there are any APIs for accessibility missing (e.g. for hooking into screen-readers), I would consider that a bug on that particular platform. There's no reason that applications which use the system UIs should behave any different from applications using custom UIs.
There are so many parts that go into the accessibility of an element, handling tab index, handling keyboard input, handling screenreaders, spoken voice prompting, etc, that a custom solution usually ends up being detrimental to the user's experience.
As others have pointed out, that's hardly a contrary opinion.
To quote Roy Fielding's Dissertation (p 109).
"Uniform Resource Identifiers (URI) are both the simplest element of the Web architecture and the most important."
https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...
Opinions are almost universally contrary, despite the knowledge that the URL can be a tool. How often is it put forth that the URL is meant to be indempotent or the URL is supposed to be mapped to another routing system etc. The number of commercial sites where the URL is a field you are meant to manipulate (other than say search engines and even they don't point it out for you) is so small as to be significant.
Unfortunately it's not true. Zero day exploits happen all the time, even the recent Intel CPU vulnerabilities were exploitable via JavaScript. Morevever, some harmful effects of arbitrary code execution cannot be mitigated (like the drained battery or user tracking), that's why I have recently adopted a view that code execution on web pages is just a Bad Idea and my non-work browsers are configured with JS turned completely off.
This gives me nearly 2 full days of battery life on my phone and I'm less worried about privacy/security aspects of visiting random web sites.
Unfortunately, even within the last year, I'm noticing that more and more web sites simply serve me a blank screen without JS enabled. This forces me to stop using such sites, which is gradually reducing the size of the usable web for me. My only hope is for a new trendy server-side rendering fad to come along and rescue the Internet :)
If that had ended up as the dominant paradigm... Google (or a search engine like it) wouldn't exist.
A URLs-only web, one that sees the browser as nothing more than The VM That Lived™, is actually the more limited vision.
Windows 10 comes with a VM-based application sandbox. But it's meant for powerusers and has to be explicitly enabled
https://www.windowscentral.com/how-use-windows-sandbox-windo...
I don't mind Electron too much, current (for 5+ years or so) desktops support running a handful of them without issue (provided at least 8gb ram).
I think that once a few quirks are worked out, we may well see a "one runtime to rule them all" with WebAssembly. WASM + Sandboxed FS + Canvas/WebGL could go a VERY long way towards a lot of application use cases. There's been a lot of work underway for this type of thing and it could be very interesting to say the least. I do think we'll wind up with an XML based markup for UI over the top, maybe a ReactNative-like syntax for WebAssembly+Canvas or WebGL would be very cool.
If I make a tool with an intended use but the world uses it in another unanticipated way, and they're happy about doing so, then that is a very fortunate accident. I then shape the next iteration of my tool around real world use.
As an “old school” designer who writes HTML and CSS by hand, with JavaScript for progressive enhancement, I found myself agreeing, and it reminded me of this, from back in 2001: https://www.thenoodleincident.com/tutorials/box_lesson/why.h...
> The idea of HTML et al is a document markup language that would grow. Its architects saw we were going digital and sat back and took a long view. A very long view. They laid the foundations for a language that would work with all the conceivable technology of the time, and would be expandable to the unconceivable technology that would follow. So that documents would never be unretrievable due to age. Ever. A browser in 2050 would be able to read a 1994 document. And in 2094. And so on. They made a stand of cultural importance to the world.
The slow, less usable feeling of JavaScript-heavy websites — my current personal website included — has remained a constant, and I mourn the reduced usability of View Source as a map for learning, lost in the forest of DIVs and obfuscated JS in much of today’s World Wide Web.
Don't take me wrong, I love crafting my website 20kb of CSS over static files. Always sign me up for a static site, but for complex websites, where interactivty and state are needed, it's important to have these frameworks.
On a project where I was doing frontend work, I just tried to think about the semantics of html elements and http requests, and reason my way through the tasks from first principles. I really enjoyed doing that actually, and don't regret it. But it didn't teach me angular which is what the frontend people at that company were using at the time, or probably any of the other ones.
I hope to venture into frontend land again, because I think it's a valuable skillset, but I hope the next time I do things will have settled into something a bit more sane. When I find a layer of a technology stack that seems to have been misused or misunderstood, my tendency has been to stop at that point and dive into a rabbit hole trying to understand what is going wrong and how to fix it.
[1] technically, there was SGML and HyTime, HyperCard, Xanadu
I was very much behind the "separation of concerns" brigade (with respect to HTML/CSS/JS) a few years ago, but the invent of React/Angular etc. and the "component driven architecture" has seen an end to that.
It's a shame - from my perspective, new entrants into the front-end market lack much of the knowledge I'd regard as fundamental even a few years back (most saliently for me TypeScript/ES2015 obscuring JS's prototypal inheritance) - but its also understandable.
This is perhaps an annoying pedantic answer, but I feel like this discounts what HTML actually represents, and what the Javascript libraries operate on, which is the DOM, bypassing HTML syntax often completely. The HTML, fundamentally is a representation of this Document Object Model, and if we're to be essentialist, HTML's success relies on good fundamental ideas of what kind of document it generates.
I do, however absolutely agree that the semantic representation of a document is important, and HTML's ideas of what a good representation of a document looks like really do shape the success of the web. This is why in very successful frameworks like React for example go so far as to implement their own pseudo-HTML transpiler that turns HTML-like representations of DOM nodes into DOM construction calls.
That said, I think there is a certain kind of essentiallism echoed in this post that goes along the lines of 'everything can't just be <div>s with classes' and I agree with that, but I don't think it has to do with writing more HTML-like DOM trees as much as augmenting the DOM to integrate more modern representations of DOM operation. I hope that in the future, systems like React leverage something similar to Custom Elements to truly represent their functionality in the DOM tree, as God intended ;)
Developers love simplicity and semantics. But when a UI gets to a certain level of complexity (I say 10 interactions per page) then semantics get hard to maintain or translate.
I'm building a recommendation engine for a client right now. Lots of wooshes, whirring and moving parts, a good amount of items don't directly translate to semantic HTML elements. It's not clear if my app should have <section> tags, <article> tags or <aside> tags.
And again, when a developer has to manage that much complexity, then it's a-ok to breakdown or lose semantics in exchange for comprehensibility. Pretty much any trade-off is ok for comprehensibility. And making my users pay the 500kb React tax is a-ok with me, because I'm not superman and it's only 500kb. One un-optimized image can be that size. It's worth it for the project to be maintainable and reasonable by the next person.
And one day when the business stakeholder decides that people on your education site don't need badges, or that quality content matters more than gamification, then we can dial these interactions back and make the web sane again.
While rewriting what's already out there may be a business decision, choosing between what HTML tag to use when changing/writing new ones, is completely business agnostic.
If using canvas or web-assembly would be easier/possible than using HTML tags for a rendering layer, nobody would ever disturb the HTML document designers with this div "soup" :)
Semantic HTML serves 2 purposes: lets search engines correctly index your content and makes it easier for a human to edit this HTML directly. Other than that, there is no other reason which requires semantic HTML.
True accessibility is achieved through other means.
Nitpick: I write code that renders things in a browser. I do not touch HTML. I use GL/D3D/Vulkan and C++.
I'm not really sure what point I'm making, perhaps that the author might want to consider the other parts of the web/web browsers.
Edit: to clarify, I work on the lowest level of browser's rendering stack.
That's what I meant by "the promise of the semantic web". As I originally understood it, you could make your own custom tags that describe the intent of the document. You wouldn't be bound by what the w3c or browser vendors blessed. Any tags that were unknown to the browser would be treated mostly the same as a div. Web components occupy a similar space.
> make your own custom tags that describe the intent of the document
If you make up your own tags for everything then to a visitor (human, bot, indexer or otherwise) it describes nothing, since those tags only have that meaning on your site (and worse, they have different meanings on other sites). Semantic web or RDF or Linked Data or whatever you want to call it is not about describing your document within the context of your document, it's about making sure your document is understood in relation to all the documents that link to it and all the documents that it links to.
I guess the semantic web is orthogonal to this discussion. My apologies. I guess it's another buzzword that was thrown around for a time. In that case, assume I meant web components whenever I said semantic web.
Prescriptively, HTML was designed to be used a certain way. "Proper" use of it supports a variety of use cases beyond graphical browser-based publications and applications.
Descriptively, there is no "right" or "wrong", "proper" or "improper". <div>s and <span>s are often enough because they get The Job™ done, for some critical subset of all "jobs." It is true that web scraping and machine parsing of content becomes harder when tags aren't applied semantically, and that text- and speech-based browsing is more difficult. It would seem that those needs are simply not substantial enough to the commissioners of web development work to warrant the extra attention and care, especially in the hyper-competitive, sink-or-swim environment of tech startups.
It is (nominally) what it is (actually).
The real problem is a lack of exploitation and education of the secondary applications of semantic HTML and how it fits in with related technologies (HTTP headers vs <META>, URLs and fragment identifiers, microformats and CSS semantic class naming) by product designers. This would naturally drive developer interest. In the meantime, those who do understand these things can continue to devise solutions orders of magnitude more efficient or effective.
It started with AJAX and now we’ve converged on single page apps, which are effectively native clients where the target platform is the browser. There is simply a real demand for rich client UX and you can’t get that with pure HTML. Which is no surprise because it wasn’t designed for that. It was designed for sharing textual documents, as the article proclaims. But is that an accurate model of an application? I don’t think it is. The web has evolved to support more than just hyperlinked documents. Good or bad, that’s why people want.
It's not about the what. It's about how it's delivered and consumed.
One could provide a web-like experience using any number of proprietary technologies. It's only "The Web" when you deliver that experience in an open and standards-based way, and consumers consume it using their standards-supporting client of choice.
Podcasts are another great example of "The Web". What makes a podcast a podcast isn't what gets consumed, but how it's delivered and consumed. You can post an audio show on proprietary platforms that require proprietary clients, but those aren't podcasts any more than a web page saved as PDF is still a web page. If you can't play it in a podcast app, it's not a podcast.
Take Bulma for example. They provide styles for titles and subtitles, but their examples use h1 elements.
See: https://bulma.io/documentation/elements/title/
Why is that a problem?
This is explicitly addressed in the HTML 5.2 specification.
> h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection.
See: https://www.w3.org/TR/html52/sections.html#headings-and-sect...
As the author suggests, they don't understand the tools they're using.
If anything they are purposely decoupling the styling from the semantics to make it more obvious which one you are choosing (although the example could make this more clear).
I'm interested, how close to reality is this view of front end devs?
In my day job, it's difficult to get through a project without encountering WCAG 2.x or some other accessibility criteria. Which usually forces you to be more semantic in order to avoid having to be more explicit using aria to tell screen readers etc what your special version of HTML means. Is this so uncommon? This comes up as a contractual obligation all the time in educational products, is this not the case in most other sectors?
It rings true to me. Accessibility isn't really on the radar of many of the developers I've worked with, and managers want business reasons to justify the extra effort that WCAG compliance would require. I didn't start thinking about/pushing for it until I saw a talk at a conference last year.
Education, banking, and government sites are mandated by law to be accessible in the US, but outside of that there's no guarantee that anything will be accessible, what I've seen?
There are 2 different things: documents and applications. These days you can find IDEs running in the browsers, excel spreadsheets, terminals and all other things which are not HTML documents. Yes, you cannot use <ul/> </li> to style an output of terminal `$ tree ` command. This is why you see <div/> soup when you examine HTML of the web terminal output.
As web-assembly becomes more mature, I expect developers to abandoned the HTML/CSS scene and leave it to HTML document template designers so there again can be a clear understanding when you have to use HTML.
People have tried, but getting the rest of the world to agree is the hard part.
we did a simple live coding challenge that didnt require React. Only some javascript to output some html in the document. They were confused because they couldn't do `return <div>hello world</div>` and couldn't figure out how to instead simply do `return "<div>hello world</div>"` (jsx vs a string of pure html).
It was pretty painful to see but also made me realise how Vue and React can make life easier but seems to get people to know even less how underlying things are working.
I guess it's the fate of all technologies.
I would argue the behavior is more important if the website does anything else other than just show articles.
A beautiful site with no behavior is useless; an ugly site with functioning behavior is not.
I always found Vue and React to be not good enough abstraction layers - you still need to tweak and fiddle with the layer below from time to time to make anything work properly.
> And it is becoming increasingly clear to me that there’s a whole swathe of Frontend Engineers who don’t know or understand the frontend-est of frontend technologies.
I would need some data on this, since it sounds like this claim is backed by anecdotes. None of my co-workers struggle with this and there's lot of frontenders in our company. Semantic HTML's usage is now baked into VS Code in a tooltip.
Yes, every web developer should be at least moderately good with HTML. Can we agree on that? Good :) Learn a bit CSS and now you have superpowers.
HTML only provides the LEGO blocks for the web, but the web is much more than that. It's an interconnected network of information with rich media. What matters is the information persistence, quality and accessibility.
Vue -> HTML, CSS, JS
I think people living at the edges of web apps and web pages are pretty happy, but the contention is when one is in between.
So it might be "compilation target for JS engines", but it sure as hell isn't "compilation target for the web". The web is so much more than just running logic in a browser.
That might come in the future, but it sure isn't the present.
The Web, when properly used (and perhaps also when it's not) is much, much more powerful and useful than just painting on a screen and running logic underneath.
Great way to get your audience ("back end of the front end" engineers and full-stack devs) on side, by trivialising the work we do as adding pointless fluff. Actually in most of my work, the JavaScript is the essential part of the app, and whether it is perfect HTML or not is not a high priority.
HTML is the compiled format which browser could understand and run, it's not for human to produce/read it.
We need more powerful tooling/language/framework/library just like what we see in React, Vue,...
Like the article says, there is literally zero drawback to being slightly more semantic. In fact, semantic HTML probably improves your own code, making it easier at a glance to see what components do.
He actually did it without any knowledge of "real html".
Any examples?
Need more?
Future tech too. Who knows what's going to be consuming our content in the future, or what input and output devices we (or others) are going to be using to navigate content and apps.