Apple, Google, Microsoft, Mozilla agree on something: Make web dev lives easier Browser makers Apple, Google, Microsoft, and Mozilla, along with software consultancies Bocoup and Igalia, have agreed to work together to make web design technologies perform in a more consistent way across different platforms. The group has created a benchmark called Interop 2022 to assess how a handful of web standards get …
rendering unreadable graphs is very annoying, vector graphics is the answer but the support despite standards is lacking...
if SVG worked in all the browsers I'm sure developers would use it and data visualisation would be clearer and better all around
SVG works well in all recent browsers and there should be no problem displaying simple graphs; I use it for much more sophisticated stuff.
The problem is it's an absolute pain to use as a dev due to early design decisions. (For example, `element.r.baseVal.value` and hope that it's using the right units.) They anticipated and solved many of the problems but in doing so made the common use cases complicated, and have been left stranded by recent innovations. And that's before we get to the issue of hand building paths.
But many of the improvements don't lie in the SVG Working Groups remit. (`Path2D` should have a method that returns the path, for example. )
So, so… On https://perl1liner.sourceforge.io/Collatz/ the Sourceforge and CC BY-SA logos work fine everywhere. But there's a rogue decision that linked and embedded SVGs differ. The former's DOM is completely separate, so I can't apply CSS to them. By that crazy logic, external JS or CSS files shouldn't be able to interact with HTML either, nor filters on external images.
The favicon doesn't work on Safari, which arrogantly wants a list of different resolutions served individually instead.
In the chapter Good Given I start with links to (huge) standalone graphs. All browsers render them, but zooming, searching and deep linking to nodes give quite disparate results.
Stop trying to make the browser into an "everything & the kitchen sink" singing, dancing, do all & be all program. It has one purpose: to render the HTML code into something the visitor of the site can read. Stop trying to make it cover up your inability to code your way out of a wet bog roll.
Go back to HTML 1.0, perhaps add in a bit of DHTML, but stop all the CSS, JS, ActiveX, *scripting, attempts to cram 20Stone of shite into a 1Stone bag that is the current web.
Want it to be faster? Better? More responsive? Cleaner? Accessible? Then KISS & it'll happen naturally as a result of NOT opening every security-exploit in the known universe through your page.
You don't get to dictate the device, OS, browser, screen resolution, nor any other aspect of what the visitor has by which to view the web. It's not your job to even try. Unless you are going to buy them a brand new computer & provide a gigabit fibre connection to replace what they've got access to, then the only thing you can do is to write your site in such a way as to be properly viewable on *any* device, OS, browser, screen resolution, etc.
If your site involves a "Best if viewed on $Browser/$OS/$ScreenResolution" style bit, please step away from the computer, go back to school to learn proper web coding, and don't come back until you can create something that works.
Think of it this way: if you had a physical brick store & told all your customers that they needed to be of a certain height, weight, skin colour, & ethnicity, you wouldn't get much business. Why? Because you are intentionally telling "non compliant" customers that they're not good enough to spend their money with you. Do you want customers? Do you want them to spend their money in your store? Then don't stop them from doing it.
TL;DR: If you want site traffic to be as smooth & pleasing as possible, remember the KISS principal & write your code accordingly.
Exactly this.
You've taken a system that was designed to show text and hyperlinks and spent decades trying to make sure that what the user sees is the same as the coloured crayon brigade graphical designers want them to see, and in the process bolted on so much cruft that there is no surprise that they all work in different ways.
Standards? We've heard of them.
Best viewed in Nescape, 640x480.
When I first encountered the web - so, around '94 or so - I'm pretty sure I remember reading some functional description of HTML that basically said, "HTML describes the page content, and it is up to the web-browser as to how it's rendered. So don't make any assumptions about font size or colour scheme."
Now, I might be misremembering, but I do often wish that paradigm had persisted, assuming it ever existed in the first place. Provide the content in outline, and let the endpoint make the layout/readability decisions.
Icon, because I feel like an old fart more and more these days.
(Feel free to imagine a "This comment under construction!! Check back soon!!" roadworks .GIF here)
"...don't make any assumptions about font size or colour"
That was 30 years ago but, you can today as 99% of pages are flat 1.5D with 7 colours.
I guess I'm the only 1 who wants to see more WASM and WebGPU.
CSS sucks and DOM gets in the way by having to be present regardless of the GPU/render.
Maybe "web" browsers should be rethought from scratch.
All the web developer bootcamp graduates can't be helping matters. They seem to learn how to do web development and nothing else, no background in basic computer science principles.
Maybe that's why so many don't realize that Javascript is a steaming pile of crap or that the entirety of the web development ecosystem is an abomination. It's a house of cards built on quicksand.
The issue is probably more the opposite. Over my 16 or so years as a Web Dev I've interviewed more than my fair chunk of comp-sci grads who looked great on paper, but knew absolutely nothing about the specifics of web development. It's all very well knowing how to build factories and decorator classes, but if you don't know what SEO is...
Also, and I keep beating this drum, JavaScript is a tool, like a hammer or a screwdriver. Is JavaScript a perfect language? No, but, fundamentally it's fine and good luck making a modern web site without it. The problem with JavaScript stems from people using it as panacea for all of the web's supposed shortcomings. When Web Developers simply grab Vue, Bootstrap, Tailwind and whatever else the framework-du-jour is, and slap together something that they have no idea about the internal workings of.
Learn your craft and don't rely on other people to do your work for you.
"It's web designers..."
There's a ton of the 1-off framework style people that you can say that about but that doesn't change the delivery method of web based applications via web browsers. Framework or not, things are becoming too slow and tedious.
Browsers keep.extending functionality and nobody will stop that and sadly web browsers were never meant for all this. That's why I say they need to be redone from the ground up. It wouldn't have to be named "web browser", but anything would help as the alternative right now seems as if Google will run everything web browser related.
At David 132, re: the "under construction" image. Can it be the animated GIF with the men in hardhats & shovels doing a Fred Astare routine to the "Safety Dance" midi playing in the background under a scrolling marquis of dancing hamsters & the Alley McBeal "dancing baby" gyrating cherub? =-)p
*Runs like hell before the GeoCities haters come out of the woodwork to kick my arse*
Sorry, while I agree with some of the criticisms, I personally consider HTML 5 to be a considerable improvement on what was before. It was heavily influenced by Opera's MAMA study and does indeed make many common tasks easier, cleaner and more consistent. That was the main job. Since then there has been a certain amount of feature creep, mainly by Google, but this is better than the stasis that Microsoft forced upon HTML 4.
It should also be noted, that, if done correctly, the developments require less JS over time as stuff gets baked into the browsers.
The parsing rules for HTML5 alone should be enough to praise it. If every file format had a parser specified this way the world would be a better place (and I'm really not exaggerating). I quote:
"The decoder algorithms describe how to handle invalid input; for security reasons, it is imperative that those rules be followed precisely."
Even with invalid input the parsing process is deterministic. Think about that next time you're writing an exception handler for a file parser.
At Charlie Clark, re: "as things get baked into the browser."
Therein lies the problem. The more shite you try to cram in that 1Stone sack, the more likely the sack (browser) is to explode (go TITSUP) and spew shite (files, code, PII, etc) everywhere.
The more narrowly the browser is focused on just rendering plain HTML, the fewer security holes will be possible in either the HTML it's rendering or the browser itself.
Every additional function you bolt on, every extra task you force the browser to do, is another security exploit waiting to happen. The more of a kludge you make the browser, the greater the SNAFUBAR that will inevitably blow up in (your/our) faces.
*Hands you a pint*
Let us agree to disagree & drink to The Good Old Days. =-)
If your web-based application is spitting people's PII, files, and code all over the net that's not the web browser's fault.
It's yours.
And it has ever been thus. Blasting us back to the heady days of table layouts and CSS hacks to stop IE6 rendering pngs with a solid background isn't going to magically plug every security hole in every web application. Learning good software security practices is the only way to do that.
It's not always a binary choice but, for example, I'm not convinced that the video tag and the eventual adoption of unencumbered codecs (even if DRM is still very much a thing) can be considered a bad thing. Prior to this multimedia on the internet required proprietary solutions that were not known for their security. The same has happened with video conferencing which is now, generally, implemented using WebRTC.
While the "browser as OS" – web Bluetooth, web USB, etc – stuff is arguably very niche most of the changes reflect what people want to do with websites and standardisation means fewer JS libraries to include blindly, though why datalist wasn't taken up more widely remains a mystery.
This post has been deleted by its author
Fun fact. When I visit that page in Chrome on my mobile, the contents section, navigation, and all the code examples are so incredibly tiny that they can't be used. Also the line and paragraph spacing is WAY too narrow making the whole, ranty, word-soup, of an article really quite unpleasant to read.
Of course, all of that could have been fixed using media queries and responsive layouts.
Maybe HTML5 doesn't suck so badly, after all?
He who lives in a glass House, etc, etc...
Yes, mobile clients often render my site in insane ways, no two alike. And that is the whole frickin' point. HTML is supposed to be a universal page composing language. No site creator should have to re-code the rendering for every insane mobile-inspired user agent that gets vomited out by the fashionistas. This is exactly the IE6 garbage issue resurrected. The user agents should know to do what they are frickin' told.
When I turn my mobile to landscape, Chrome renders it just fine.
Your shite experience is down to shite browser rendering. Or, possibly, being too fashion-conscious to be seen turning your phone sideways. Maybe I should add a rider; "Best viewed in landscape mode".
What you're saying is that your website doesn't render correctly on the world's most popular browser, but that's your user's/Google's problem, not yours?
Welcome to 2022, where users browse the web on everything from game consoles, to ultra wide 18:9 pc monitors, to mobile phones. The modern features of HTML5 and CSS3 make building websites that, not only work, but deliver an optimal experience for every user on whatever device they choose to access the web on, a relatively painless process for web developers. It's certainly a HELL of a lot easier now than it was in the days of IE6, when I first started as a Web professional we were still building with back compatibility for IE5.
There seems to be this pervasive idea that there was a golden age where web browsers just did as they told and everything just worked. It was never thus. Never. Even if it was, the nature of the technology has fundamentally changed, devices have changed, networks have changed, use cases have changed, expectations have changed. If you'd have told me in 2004 that I'd be able to stream gigabytes of data over the web to play video at ten times the resolution of a standard analogue TV signal (ask your dads, kids), wirelessly, to a 5mm thick, hand-held device, in my lifetime, I'd probably still be laughing to this very day.
You either roll with the changes, or stand aside to let them through. You can't stop progress, and this IS progress.
No site creator should have to re-code the rendering for every insane mobile-inspired user agent that gets vomited out by the fashionistas. This is exactly the IE6 garbage issue resurrected.
The irony is that this position is exactly what lead to that garbage in the first place - your statement is essentially "best viewed on a Desktop browser", despite HTML5 giving your the means to ensure that you page could, with a modicum of effort, work on mobile too, in a cross-platform manner.
Consider that 280dpi, 2" wide screens did not exist a few years ago. As technology progresses, some adaptation will always be required. You're trying to hold back the tide.
No it doesn't. In fact it's WORSE in duckduckgo. EVERYTHING is too small to read without zooming in on that browser. At least the paragraph text is somewhat readable in Chromium based browsers.
About the best that can be said is it's more consistently bad than it is in Chromium browsers.
"Management wants the bells and whistles"
In my experience of involvement in web development (particularly the 'agile' kind), management don't actually set the agenda. They get presented with a succession of fait accompli presentations that are already bloated with cruft, bells, whistles and hooters, demonstrated on super fast local hardware. They like what they see and don't question how it works (or how it will work over the not so fast web or for those with more limited hardware).
This is the same sales pitch as used by Ali Baba and the 40 estate agents (car salesmen, double glazing fitters etc.) - never show the punter anything simple and straightforward, blind them instead with 'features'.
So it's the web devs that drive the bloat, not customer demand, and it's reached the pitch where CSS and scripting can be so complex they can eat up several fast cores to render a static page - and, what's worse, such pages are frequently unreadable with styles and/or scripting disabled. The basic principle that communication is for the benefit of both parties has been forgotten in favour of showing off how brilliant one party thinks it is.
Oh, gawd—yes. As one who was responsible for in-house online design (enterprise & consumer) I saw that shite all the time from outside vendors who management would contract without our knowledge (f#$k !). So many times we'd be asked by internal stakeholders to redesign/rebuild the entire disaster. Thankfully, I had a crack-on team who were able to rise to the challenge. The downside was trying to keep it under wraps from management that their 'wunderkind' vendor had caulked up. But that was the CIOs job, not mine.
At Pascal Monett, I disagree that CSS & JS are effectively mandatory. Visit your browser's options/settings, go to the Accessibility section, & tell it to ignore all fonts, colours, styles, etc. You've just given TheFinger to all those elements as far as your site visit is concerned.
As I've said before, ElReg doesn't require JS, my bank doesn't, Gmail doesn't, all my other news RSS feed sources don't, so if I run across a site that screams at me to enable it, especially if they claim it's for *security*, I send them an email to let them know they're so very, very wrong.
"Oh, and BTW, since you refuse to create a page that does not require JS to even render at all, you've just told all your potential customers that you can't be trusted to wipe your own arse much less handle anyone's PII. I'll be taking my business to your competition."
It tends to make them sit up & think about what they can do to "improve customer experiences", which usually means figuring out how to remove the JS artificial hurdle to prevent potential customers from BEING customers in the first place. =-J
*Hands you an extra large tankard*
Here's to the KISS principle & avoiding an entire class of security issues by not going down that rabbit hole in the first place. =-)p
Stop CSS? I have to disagree. I wouldn't want to go back to a web where all the presentation logic is mixed up with the contents, anymore than I'd want to use a word processor that didn't support some form of stylesheets.
But all the executable crap? Hell, yeah! Kill it with fire!
Once upon a time, in my early days as a dogsbody (and largely unsupervised) programmer, I formulated a couple of SQL queries for a web app that returned HTML to make the data look a little nicer.
I would sack myself as a hopeless case if I could go back in time!
Yes everyone is aware SVG is the laggard. The SVG working group has just (yesterday) been rechartered with a slightly different goal, which is to do things the way CSS does it: multiple independent implementations, and a testsuite to back them up. The existing testsuite is poor and interop for some of the more obscure features is bad. So this is a very good thing.
But I wanted to point out that all the companies listed are already working together, in the same working groups, on the same testsuites. This is about a push to drive adoption of the newer features that have less coverage - cascade layers, grid-2, color-5, the "lvh" unit or whatever it's being called today. These are all new things that didn't exist anywhere a couple of years ago.
So yes this is good, but 'best viewed in X" hasn't been the case for years because this cooperation is already happening, and because there are tests. Thousands and thousands of them: https://wpt.fyi
That's patently untrue. It used to be, probably back in the early naughties, that a fairly large number of websites wouldn't work in one browser or another. Hell, I've written some of those "Please upgrade your browser" messages myself, but now? No.
Except for Opera Mini.
F#&k Opera Mini.
As a devoted Firefox user, let me take a moment to articulate that you are sadly mistaken. I regularly encounter sites which render incorrectly in Firefox or refuse to load, demanding that I use some Chrome variant. Out of sheer perverse refusal, I use Edge rather than Chrome, which typically works fine.
Edge is currently both the fastest, and most standards compliant browser out there. It's my browser of choice and anybody who thinks differently? Fight me. I will beat you senseless with benchmarks and stats.
Firefox usually requires minor tweaks for some rendering quirks, as does Safari (often to a greater extent), but I'll be honest, I can't remember the last time I saw a website flat out choke on any browser, unless its doing something SERIOUSLY cutting-edge.
When that does happen, and I've said this before, that's the problem for the developer to address. We may not like it. We may not agree with it. But that is the reality of it. Ultimately it is our job, as Web Developers, to ensure that our websites work for everybody. That a user's experience matches their expectation. General user's don't care that your website doesn't work in Firefox because there's some kind of standards quirk that's difficult to work around. User's only care that your website doesn't work for them, at that time. If we don't fix those issues, then they just go somewhere else instead.
There have been symposiums, consortiums, thingiums all aimed at trying to solve the problem of why different browsers render different parts of the spec differently, and these efforts have been ongoing with varying degrees of success (and failure) for 20 odd years
I’ve got a radical idea which would side step this need - JUST IMPLEMENT THE DAMN SPEC!
It’s not rocket surgery. Some engineer has to rework a layout engine to render a box 2px smaller than it did yesterday to comply with the spec and the overflow will no longer occur in browser X, therefore behaving like browser Y, which met the spec yesterday
Problem solved
Browsers were supposed to render things differently and present pages in the best way for the platform it's running on. At least that was the original idea, now it's become a problem because browsers switched from rendering hypertext pages years ago to became app platforms.
The logical conclusion is that everyone runs a Chromium browser, wouldn't it? And that would be a very poor thing indeed.
Because the specs were written by humans and are thus somewhat ambiguous with some details.
The spec writer knew what they meant and it isn't until someone else interprets it differently that it becomes clear that it's ambiguous.
And that difference in interpretation isn't noticed until the product has shipped. Then it's not easy to fix because 'backwards compatibility'
Very true. I will say that of all the specs I've ever worked with - and that is a lot - CSS is the benchmark to which they should aspire. It's open, collaborative, it's correct - well, largely correct, if we skip over some of the dustier corners - and it's constantly under revision to ensure implementaitons match the spec or, if necessary, the spec matches the implementations.
Spec writing is an art, and without testcases to demonstrate and verify it's the art of fiction.
Also - Hail to you, great leader of the Anonymous Cowards!
In all seriousness: name one. I haven’t seen a site like that for years. I know there’s shit out there from the old days, if you like, that requires IE6. But I don’t recall seeing a site like that for a while, unless you count the application-in-a-website sites that’ are pushing the boundaries: of browser based circuit simulation, video editing, that sort of thing? The fact you can do it in any browser is what’s remarkable there.
Then it's not easy to fix because 'backwards compatibility'
Backwards compatibility is being dealt with by messages saying "Your browser is too old for this site". It isn't necessarily old, it's just one that the designer couldn't be arsed to support because they want to produce the flashiest, least secure thing possible so that means concentrating on just one engine - and quite possibly dropping functionality.
Behold! Some engineer reworked the layout engine for tables and they now render 3px smaller than they did the day before, but matches the spec: https://github.com/w3c/csswg-drafts/issues/6230
That was last week. So not that radical. Sorry.
The specification was often written without the practical experience that could be gained from implementations – tables are an example of this. This is why for things to be included in the specification they generally require at least one, and preferably two, implementations using different engines. This helps assess the usefulness in practice but also iron out ambiguity and bugs in the specification.
This reminds me of the Imbecile Explorer days when you had to have 2 versions of your website. One for Imbecile Explorer and the other for everybody else (e.g. Netscape); or it felt like that. Issues with browser rendering badly have been an issue ever since there has been more than 1 browser available. Part of it is with the browser and part of it is poorly coded/tested websites. I have seen browsers within the same family handle sites differently even now.
When I first started as a Junior Dev there wasn't really any concept of raster graphics and the most common use of vector graphics was when you drew a diagonal line along the side of your card deck in case you dropped it.
However, there were still interoperability problems - eg ASCII vs EBCDIC - and I'm told there was even an early agreement on the chalk content of cards so that they would feed correctly in different manufacturers' equipment.
Incompatibility seems to be a human feature rather than a specifically technological one.
Web development is all shite. Its a car crash of technologies that changes direction every 5 minutes.
Its also massively insecure based on most developers practices. Just NPM is a ticking time bomb.
Imagine if Windows or Linux pulled down .so or dll files from third party URL's each time the application ran. It's insane.
Then there is a the UI look of so many sites. Many work no better than mainframe screens...actually mainframe screens were at least slightly better thought out in terms of workflows.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
