Dump HTML

rs79

I think it's time to admit that HTML and CSS is a round hole for our square peg. There was never any debate about using them, they've run out of breath and it'll be years before it can catch up to .... 1985. I should fix this up, there's typos and it deserves a couple of rewrites but I've been thinking about this for a couple of years now and finally put mu thopghts down on paper, spurred on by a thing a saw today, a poll on a css site that said shoud we dumb CSS and just do everything in Javascript? Ho ho! Now there's a thought. So, here's my screen, if you know something about PS I'd love to have a discussion. If you don't it helps to know what you're talking about. A copy can be found here. Text follows. Cheers! R. http://risingslug.blogspot.ca/2015/08/rationalization-of-inline-level-1.html Vivaldi is the new web browser from the core Opera team that seem to have split from Opera, the latter now simply rebranding Chrome now thus loosing all the unique features Opera had, many of which they invented such as tabs and CSS. An experimental version of the browser has been out for a couple of months now, it's on the edge of being my "daily driver" here now, displacing the venerable Opera 12 that I'll never upgrade. So. Is it everything I've hoped for? Looks like it. Probably. It might be, or be on the path to being, the best browser hands down bar none. And that sucks. Why? Recall Shaw's quote about the reasonable man: "the reasonable man adapts to the status quo, therefore all progress depends on the unreasonable man" So, by making the perfect browser for today's needs, that's adapting to the status quo. I want an unreasonable browser, it's the only straight line between here and a vision I have of how this is supposed to work. Here's my list of unreasonable requests and features. You'd better sit down. 1) Dump HTML 2) Dump CSS Ok, you can leave them in for comparability with 20th century stuff, but they should always bee swapped out in a fair and just word. 3) Keep JavaScript. Markup languages are great for marking up documents into virtual and physical containers. They're just swell. But as a way of driving display and print devices? They're the worst thing ever and it's a miracle they work at all. JS is the only language since C worth knowing and a naked browser with just javascript could do everything (and more) you can do with HTML and CSS. 4) Decent web page editing. I've been writing and looking at web based editing sytems since the second day I stumbed onto HTML in 1993 or 4. I think mine is better than anything out there and we're a generation away from decent web editing. Fair play, the technology just came out to let you do certain things. Think about that. The web came out in 1989 and in 2015 you can do a few more things. Let's see how HTML5/CSS3 stack up today: "I need to display a 14 point outline of an upper case Garamond demibold 'A' - how do I do that in HTML?" "Oh, easy, in Webkit, you just say -webkit-text-border" "What about everything else?" "Not supported." That's right. You can't do it. a quarter century of HTML and it can't do this... yet. Will it be another 25 years before this happens? 50? Who exactly has the 100 year plan for this? This is not a failure of math or science, this is a failure of vision and thought. HTML came from SGML which came from SCRIBE, Brian Reid's document database system. It's the sort of product that makes writing a maintenance manual for a 747 possible, to quote Brian when he worked ar director of Digital Equipment Corporation's Western Research Laboratory (DECWRL). HTML isn't really new. Before it there was runoff. Runoff/Roff was the markup langiage that came out of Bell Labs, Cherry Hill, in the late 1960s early 1960s. Three major things did: Unix, C, Runoff. Runoff was written to Dennis and Ken cold write manuals for Unix and C by using Unix and C. The first job any Unix system ever did was to replace hot lead publishing. Ironically, as a teenager I worked at a newspaper computerizing their system to replace hot lead casting of actual printing plates in the evolution of digital typography and printing. So all though the 1970s if you did anything with printing or displaying text you used Roff and it was as ubiquitous around Digital machines as HTML is today. So there was a real case of lunch bag letdown when Sir Tim proclaimed ot the world "Here's how you make a new paragraph: "

" and here's how you make the first heading: "

" Sir Tim beams. But this was a facepalm moment. Note the similarity: ROFF HTML .p

.h1

In other words, Sir Tim gave us state of the art 1969 text markup. By 1989 Tim was able to use a laser printer that didn't exist in 1969 and wrote a program a programmer might use to format source code for HP or Postscript printers. You see printing changed. Dennis and Ken had serial line printers. 10 years later everybody had an Epson MX-80 dot matrix printer, but they were functionally identical and drop in replacements; you could unplug the $25,000 Digitial PDP-11 printer and plug in a $99 Epson and it'd still work. Either one, when you send it the letters "H e l l o w o r l d" it'll print "Hello world". Not so a later printer. Send it those 11 letters to a laser printer or typesetter and you get nothing. Send it to any HP compatible (and by this it means "can speak the printer control langauge known as "HP-PCL" printer and you'll get 11 tiny letters and the paper might be the wrong way around. Laser printers are so complicated that you have to talk to them in their own language and there are two: PCL used by HP and compatible printers, and PostScript used by LaserWriters, Typsetting machines, iPhone and PDF files. PCL is not meant to be read/written by humans. For exampe: "ESC & l # c" sets the VMI to #/48 on an HP Laser. Want to draw a circle? Send me the dots. All of them. Junk. Got that? If you want to print on one of these you need a program to print your file for you, you can't just send text to the printer and have it show up on a page. It has to be a combination of PCL commands and the original text you want to be printed. Postscript on the other hand is a computer language, like Forth, and it drives the guts of all high end printers and typesetting equipment. It's a human readable language. A program to draw a circle is a few words, not megs of data like it is in PCL. In 1998 Canon sold a $12,000 laser printer engine and in 1985 Jobs announced Apple would sell a $7000 PostScript printer. PCL "lacked the power and flexibility of PostScript". So does HTML and it's 25 years later. The LaserWriter succeeded because it could be shared among up to sixteen Macs, you'd need sixteen HP's for 16 PC's to do this or additional hardware, Macs did it out of the box and because that same PostScript file can be used by Phototypesetters as well as LaserWriters then you can go from screen to paper, then to mylar for proof, then clear mylar at 1200 or 2500 dpi for production. Oh and don't kid yourself that "effective 4300 dpi" from an ink jet is even close to a 2500 film phototypesetter. You gotta see this stuff. Now, Sir Tim will have understood all this, he was at CERN at the time, and I happened to have written a program that prints files on either HP or PostScript laser printers. It was the only thing I ever write that I released onto the net (around 1987) and I only got one bug report - from CERN. At seven thousand grand a pop laser printers wern't common in the mod 1980s. I had an engineering prototype from QMS and used it to typeset the manual for the Amiga program that would eventually morph into Flash. So I had one and sir Tim had one. Or somebody there did. I bet they had more than one. But the point is although the technology changed it was the same problem Dennis and Ken faced with Unix in 1969 "We need to get a printout" or "we need to send this to the typesetter now" and none of these devices could take plain text. The major difference between PCL and Postscript is PCL is a markup langauge, the same as Roff and Runoff where you add commands to tell the thing what to do with the text it's getting. Postsctipt on the other hand is a compute language, so you send a postscript program to the printer and text you want to print is part of the data of that program. The point is there's intelligence there. Consider the case where you want to print a circle. For the HP you send all the dots for the circle, on a serial printer this could take 5 minutes. In postscript you say "circle". So you send 6 letters to the printer and not 6 megabytes of dots; because it's intelligent you can describe the circle and not have to send all the dots that make up the circle to the printer. HTML is the PCL of display interfaces. Postscript is what should have been used. You can't say it won't work, PDF's are PostScript and they work fine. Actually PDF's are a couple of evolutionary steps above Level 1 Postscript. Another problem was, at the time, Postscript was covered by patent protection. That expired a couple of years ago, and Adobe has frozen Level 1 PS now at EOL. This is fine, the language itself is trivially extensible, it could be shipped as a raw interpreter and would still be useful, but I digress. My guess is patent protection was the biggest reason to reject PS as the language of the web - if it was even considered at all. Patents would have been a show stopper here. Also the complexity of PostScript - having to write and send a program to a printer as opposed to just sending the text and a few markup codes is overkill. That's the fatal error. 1) Presently HTML5/CSS3/Javascript - and all three are required to come close to what PostScript could do in 1985 - are now more complicated that Postscript ever was. Plus nobody writes in HTML any more, most is generated by programs - that were generating Postscript a decade prior to doing HTML. Also, any still writing in native HTML (waves, hi) would most appreciate the power and flexibility of it more than anyone. 2) Look at a web page. If more than half the code is for positioning the object than describing the object itself - you're wasting time. While there is always going to be positioning the ratio of positioning goop just to say where stuff should be to line up perfectly is a bloated nightmare in the HTML model and worse than any of the similar things that came before it: GKS, PhIGS, etc. They went away, just as HTML should. That is HTML stands out where the majority of the language by volume of commands, is for the most minor of tasks: positioning. Half a 300K file may be to get stuff to be in the right place to look right (and god knows it's hard enough to get it there) whereas in the most complex postscript image, positioning is always trivial - x, y in "points" - which works as well at 75 dpi as it does for 5000 dpi or 4K. I don't buy the separation of markup from content. Because PS is an extensible language you can do anything you bloody well want. To be honest, after watching this for a few decades I'm not sure what this great separation of content and markup gets us. I suspect most people just don't give a shit that just want to be able to put a box at x% and y% and have it actually goddamn show up. Text flow? Who really gives a shit about that? Who are are you people? Hands up. So. it's twenty five years after HTML was adopted as THE language for web markup, without discussion and no debate. Do we really not get to talk about this? It took ten years to ass gradents, box-shadow and text-shadow. Oh and you can sort of draw shapes now by using the rounded corner option and the new transform math stuff nobody understands. Buf if you want to draw anything else you need SVG which is new. And there is is. HTML was too lame so we needed JavaScript to do ANYTHING and we added CSS after that as it cut down on the amount of JS we need. So now to draw a Bezier spline the answer is... "add another language". No. Just no. This violates every principle of scalability. Lemme guess, there's a 3D equivalent of SVG lurking in the shadows too now isn't there? Sun demonstrated a realtime bouncing bezier spline curve in 1986 on a $250,000 sun. I went home and did it on an Amiga. Think you're gonna do that in HTMK or PCL? Well you might if you use HTML5, CSS3, Javascript and SVG. A good person intimately familiar with 4 of the most complex compute languages every written can probably knock it out in under a week, a couple of days maybe, and on a decent 2+ gigahertz machine can probably hit 100+ frames a second. In 1986 a $1200 5 megahertz 68000 could do that - with postscript. How about rendering an outline of an 'A' ? You can fake it with text outline and it's ok but it fails miserably below 30 pixels. the Postscript. NeXT used to do this and was flawless down to about 12 on a crappy display, 9 or 6 on better ones. So after 25 years of refinements, and throwing more language at it, there are still things you can't do on a screen because the language - languages - can't do it. Gradients in text? Nope, can't do that either. Both are a one liner in Postscript and have been since 1985. And you can't do it at all in 2015 after 5 generations of HTML refinements and 3 generations of CSS refinements and so on and so forth. This is just fucking embarrassing. Here are the reasons to use PS instead of HTML: The amount of markup as a percent of payload will shrink. With https being nearly ubiquitous and ubiquitous slow, this would help make things a bit more snappy. You can typically do in a 10K .ps file what it takes several megs of html, and it's not scalable, PS is, infinity. The same icons can work at 100 x 100 displays or on 4K monitors. Native to IOS and Typesetters. This makes the step from web page to print not a step any more. Same file works flawlessly on both devices. One version of one file. How many versions of various language do you want to maintain? Any decnet program has an "output to PostScript" option. Even the Windows printer utility does. It's the industry standard. Yet we ignore it on the web despite Display Postscript shipping o You'll be able to do more things. It'll be easier than now, a LOT easier. HTML has run out of breath. By the time all the missing features are added (maybe in 3 years from now we'll get text gradients) it'll be obsolete - the entire model is wrong. If we want a new feature in the web we have to get browser authors to add it. If we had postscript - everything's a PostScript program and here are no limitations whatsoever - we can get back to 1986 levels of rapid development. The change can be utterly transparent and can only be done by browser manufacturers and HTML need not stop working. All that's required is to interpret level 1 Postscript inline. That's all ya gotta do. The SVG code probably has all you need and you can modify the V8 interpreter to be a PS interpreter thus adding the async i/o of JS which is a nice touch. This if one webserver's default for http://example.com is index.ps and not index.html, and doesn't look any different, then who's to know? It's that simple. So, all Vivaldi has to do it support Level 1 Postscript inline. Don't spawn off an external viewer. Just do what it says and draw. Embedded postscript change publishing, being able to drop a Postscript illustration into a Word document eliminated the need to great extent for Knuth's arcane TeX system and similarly so being able ot say "Garamond demibold findfont setfont 100 scalefont draw" will draw you the outline of a letter 'A' so perfectly even under a microscope that you cannot do at all today in HTML5/CSS3. The radial gradients and gradients that didn't quite make it into Opera 12? Free in PostScript, why worry about that stuff? A hybrid of the better parts of HTML and Postscript makes sense to me and I can see some combination of

<section>with bits of postscript here and there to do the illustrations - not all the world is a jpg and i you check the fewest bytes you need to send to render a bar chart are a Postscript program - I checked. So, please add postscript. Or pay me and I'll add it. But the reasons for doing it are manifold: certain intermediate steps in the publishing sector are eliminated. It takes less time to design, code, transmit and render the same thing with Postscript than it does with current web languages - which can't even do what PS did when Reagan was in Office and on a 12 Mhz 68000. Plus, the most altruistic reason for browser authors - add PS and there's no more debates about language, no more meetings, work groups, standards bodies and their glacial movements. Everything's a PostScript program. You want a feature? Rather than schedule it into browser and standards development bodies, here's the PS code. Done. Ship it. Fini. It's easy to add, there are no limitations, it's transparent to the user, is of great benefit and not hard to do. The time you save will probably be your own.</section>

</article>

</header>

Frenzie

By the way, the CANVAS element allows for stuff like that, in a way. http://logand.com/sw/wps/index.html

ThomasWrobel

You think its bad now?

I was on a W3C group disusing possible ways to achieve a standard for Augmented Reality experiences. Essentially how to link physical spaces to virtual data.

One of the suggestions was to build the whole thing ontop of existing standards. Not just tcp/ip/http - but to actually build solutions in html.
So in order to, say, see a 3d model positioned over a gps location you would first load a webpage, which in turn would load a piece of javascript, which in turn would render the 3d file against the videofeed.
Madness.

ersi

@rs79:

I don't buy the separation of markup from content. Because PS is an extensible language you can do anything you bloody well want.

To be honest, after watching this for a few decades I'm not sure what this great separation of content and markup gets us. I suspect most people just don't give a shit that just want to be able to put a box at x% and y% and have it actually goddamn show up. Text flow? Who really gives a shit about that? Who are are you people? Hands up.

Well, looks like there are different purposes to it. Sometimes you want to create stuff and feed it to others, such as to the printer, precisely a certain way and not a dot differently. At other times you want to get given stuff, such as web content, to display in a readable way. In the latter case, you most definitely want the text to flow, you want to eliminate boxes, frames, scripts, to set your own fonts and colours. The tools should be able to trim every aspect of the style, because if the hip web designer has ignored readability and accessibility, the user will have to make up for it. This seems to work pretty well with the current structure of the web.

deathshadow

*** WARNING ***

While I'm going to avoid profanity and be as polite as possible given the topic, if you're one of these little "wah wah, he's saying something negative" wussies who cannot stand having the status quo contested, just do the world a favor and stop reading now!

Also, if you're one of those Twitter generation "TLDR" mouth breathers the door is right there, don't worry I'll make sure it hits you in the backside on the way out.

This should be fun, wonder what the post size limit is here… guess I'll find out!

*** END WARNING ***

I really don't think the problem is HTML or CSS, at least not in terms of their original intent. The problem lies with the endless hordes of fools sleazing out HTML and CSS any-old-way in complete ignorance of that intent.

The whole point was to have a standardized set of SGML style tags that said what things ARE, or WOULD BE, in a professionally written document, allowing user-agents to decipher that meaning and convey that meaning within the capabilities of the device it's being showed on.

A LOT of what you are saying reeks of being a visuals only print only type of person, who has completely missed the point of what website are, what they are for, or why they exist. Like the fools messing around in photoshop and calling it "design", or the nubes thinking that WYSIWYG can be used to make websites, you seem to be working from a flawed understanding.

That you suggest postscript, somethign that by it's very nature is designed for creating FIXED layouts that don't reflow is proof enough of that. How exactly does a postscript file change the number of words per line to change the layout to fit a different size display WITHOUT changing the font-size? It's doesn't. How does it inherit the user's preferred font size? It doesn't.

Ever heard of elastic layout? Dynamic fonts? Fluid and/or semi-fluid design? RESPONSIVE DESIGN?

Postscript is the PINNACLE of inaccessible design as document formats go. The only reason to use it is if you know the physical dimensions of what you are printing to. Sure, you could scale it, but are you going to shove pan-and-scan down mobile user's throats? Are you going to waste time having multiple different copies of the same document for every conceivable device size (all five-billion or so of them at this point?). Particularly "level 1" which is effectively useless on screen readers, braille readers… the result is going to be about as useful as trying to browse a PDF of a 4" phone display. (which stands to reason since PDF inherits a lot from Postscript -- there's a reason GhostScript can parse PS and PDF)

The complaints about file sizes is utter and complete nonsense -- a PS smaller than your HTML+CSS? That would have to be one utterly jacked up halfwit poorly coded set of HTML and CSS. ADMITTEDLY that describes what a LOT of people sleaze together out of ignorance using automated tools, blindly trusting off the shelf templates, and the endless pointless bloated redundant GARBAGE like jQuery, Bootstrap, LESS, SASS, React.js, YUI, blueprint, etc, etc...

Most of which when I see people using them I have the overwhelming urge to deliver a nice big *****slap followed by shoving a can of drain cleaner down someone's throat. Pimpin' ain't easy…

You also go on about typesetting – which again is concepts meant for a fixed size output. Again, "the web is not print" -- the concepts for print and assumptions made with it do NOT translate well if at all to screen media -- from goofy hard to read webfont crap "typography" folks seem to cream their panties over, to fixed designs and the concept of "one design for all sizes" it's utter and complete usability and accessibility rubbish!

Remember, the whole reason HTML exists is to allow content (you know, this pesky "text" stuff) to be conveyed to as many devices as possible - when TBL made it that meant everything from teletype terminals to Commodore Vic=20's up to the 1152x864 resolution NeXT workstation he happened to be at. In the modern world that means everything from a 2" wide 128x224 phone to a 4k display, much less non-visual targets like screen readers, braille readers and of course, search engines. THAT'S WHAT IT'S FOR!

–---------------------------

A well written website should have a "normal" page (things like galleries are inherently larger) fall relatively close to this calculation:

3072 bytes + plaintext size * 1.5 + 256 bytes per image/object/video/audio/embed + 128 bytes per form element.

If it's more than 50% over that calculation, it's poorly coded rubbish. If it's more than twice that figure??? Well... do the world a favor, grab a shotgun and take the developer around back o' the woodshed to be put down like Old Yeller.

So if without markup you have 5k of plaintext, 8 content images, and a 2 input form (search text + submit) there's little reason for the page to exceed 13.5k. That's why it's a laugh when you see the outright developer ineptitude common to things like turdpress templates when they vomit up 60 to 100k of code to do the job.

In that same way there is NO reason for an ENTIRE website to need more than 48k of CSS other that developer ineptitude. A typical website should clock in somewhere between 24k and 32k of CSS for the entire site.

Laugh is you say JS is fine, when that's the REAL steaming pile people need to use less of since it tends to piss all over accessibility from so in high you'd think the Almighty himself just got back from a kegger.

There's something called "the unwritten rule of JavaScript" – that rule is "If you can't make a fully functional page without JavaScript first, you probably have no business adding scripting to it!"

Good scripting should enhance functionality, not supplant it or be the only means of providing it. It REALLY shouldn't be wasted on artsy fartsy crap that does nothing but get in the way of the user doing what they came to a site to do, GET THE BLOODY CONTENT!

A lesson lost on today's scripttards sleazing out megabytes of JS, hundreds of K of CSS and a host of other nonsense on doing 72k's job.

See, as a rule of thumb I say there is NO legitimate reason for a site template without content to EVER exceed 72k in a dozen files other than developer ineptitude.

–-----------------------

All of the above is part of what's known as "progressive enhancement" -- there's a reason the method of building websites I advocate involves taking the content or a reasonable facsimile of future content and arranging it in a text editor in a logical order as if HTML doesn't even exist, to which I then apply markup to say what things are, to which I then apply the lowest common denominator visual layout to with CSS (which IMHO means non-media query capable desktop browsers. We can target mobile, why the **** would we start with that?!?), then enhance that layout with media queries to make it responsive. Then and only then do I worry about colours, borders or hanging presentational graphics on it, much less enhancing it with scripting.

That "progressive enhancement" means the page will "gracefully degrade" should any of the fancy bits along the way – even HTML itself -- fail to work.

Really a lot of the "problem" with websites is that we've let artists and marketing asshats take over the industry and call themselves "designers" when to be brutally frank the majority of them don't know enough about HTML, CSS, accessibility, emissive colourspace or user interaction to be designing but two things… and Jack left town!. You ask most of them the most rudimentary questions about legible colour contrasts or usability, they get that blank stare trying to explain why they have no idea what you are talking about, and if pressed usually go "WCAG, what's that?!?"

It's why dicking around drawing goofy pictures in Photoshop is NOT "design" – that's like hiring Bob Ross instead of an Architect when building the Dubai Tower. It's why all the pointless scripttard animated crap is a waste of bandwidth that just gets in the way of users getting to the content -- see why those massive trendy slideshow banners cropping up all over the web amount to little more than a sleazy attempt at hiding a lack of content the same way people used splash pages a decade ago.

It's why fixed width layouts are rubbish. It's why declaring font sizes, widths and heights in pixels is rubbish. It's why nonsense like "grids' are rubbish.

A well written page should have a number of things.

Semantic markup -- using HTML to say what things ARE, NOT what they look like. In many ways "semantic markup" is just a sick euphemism for "using HTML properly" – we use it so as not to offend the people who still sleaze out presentational HTML 3.2 and the proprietary tags that followed and then slap either 4 tranny or 5 lip-service around their two decade out of date methodologies just so they can pat themselves on the back over how "modern" they are.
Separation of presentation from content. You say you aren't "sold" on this one? Then you're missing one of HTML's greatest strengths -- graceful degradation and multiple media targets.

A website is NOT supposed to be about making one pixel perfect or perfect aspect/scale layout and then forcing devices to use that. That's the garbage the folks coming from print -- or worse, the folks who can't see any farther than the screen they're seated in front of -- seem to think is "design" -- it isn't.

Semantic markup provides a baseline that should things like CSS not be available or apply the user-agent can still attempt to provide either a useful/usable page. This allows access to less capable devices (which is why things like WAP and WML were redundant garbage) as well as non-sighted users. Again, screen readers, braille readers -- you say "this is the topmost heading", "this heading starts a subsection of that", "this is a GRAMMATICAL paragraph so it's flow text", "this is a list of short choices or bullet point items" you are providing a means for the user-agent (browser) to convey that meaning within the limitations of the device.

We got away from that during the browser wars, it's what 4 STRICT was trying to shove us back to, and it's what the asshattery known as HTML 5 is pissing all over just like 4 tranny and 3.2 did. The pointless redundancies and re-introduction of things 4 STRICT was trying to get rid of tells me that HTML 5 is not meant for anyone who ever embraced semantics and separation of presentation from content -- it's carefully crafted to satiate the wants and desires of those who were sleazing out 4 tranny because they never extracted their cranium from 1997's rectum. After all, that's what transitional MEANT – in transition from 1997 to 1998 development practices!

Stands to reason though since the WhatWG freely admits they were documenting what people WERE doing, instead of what people SHOULD be doing – that's not a specification, that's documentation. WORLD of difference.

The other aspect of that separation is what CSS provides -- the ability to customize for multiple device types via media targets (screen, print, aural, etc) and now with CSS3 we have media queries to further detect the capabilities of those devices.

Elastic layout with dynamic fonts. Fonts should inherit off the browser default since that default is NOT always the 16px the "62.5%" mouth-breathers woul have you believe. Windows users can change it in the OS and some browsers inherit it. ALL browsers let you change that so you aren't diving for the zoom resulting in broken layouts and crappy image resizing. That's why fonts should be declared in % or EM whenever possible (the only real exception being when there's an image interaction) and things like widths, margins or padding should be declared in EM. That way users get their acceessible font size.

See "WCAG" for more.

Semi-fluid. This pretty much means a min-width on the layout for non media query browsers so as to force scrolling before the layout breaks, and a max-width so long lines of text aren't too hard to follow. The layout should be fluid between these two extremes changing the number of words per line to fit that space. This is why things like "width:768px" is inept halfwit rubbish done by people who have no business making websites.
Responsive. The "new kid" 'round these parts it's just the next logical step in accessible design. If you have everything outlined above and leverage your tags properly this shouldn't take more than a k or two of code for an entire site to implement. (again see why bootcrap is dumbass bloated nonsense). Re-arrange the layout to fit based on the available space.

A LOT of people seem to think that means "designing to certain device sizes" using pixels or other triggers. That's ALSO halfwit nonsense and completely missing the point. The breakpoints for media queries should be based on the needs of the content, in EM, not on "Well my iPhone is this resolutions". Simple fact is there are SO many devices in SO many different sizes you can never customize to each of them, so instead use max and min-width triggers in EM for where the CONTENT and layout breaks to fix it being broken.

You follow all of the above, there's no reason for a site to be useless to any potential visitor and no real reason to have the massive code sizes people seem to sleaze out... and then there's not one blasted thing wrong with HTML or CSS that needs some alternative to replace it.

That's why the problem lies not with the technology, but the people using it. Just take a look at your typical sleazeball turdpress template with such mind-numbing nonsense like this:


<header id="masthead" class="site-header" role="banner">

# [WordPress Demo Install](http://demosite.center/wordpress/ "WordPress Demo Install")

## Just another WordPress site

<nav id="site-navigation" class="main-navigation" role="navigation">

				[Skip to content](#content)

*   [Home](http://demosite.center/wordpress/ "Home")
*   [Sample Page](http://demosite.center/wordpress/?page_id=2)
    *   [This is a test](http://demosite.center/wordpress/?page_id=60)
    *   [Goo Work !!!](http://demosite.center/wordpress/?page_id=70)
*   [Test Page!](http://demosite.center/wordpress/?page_id=39)

			</nav>

	</header>

What's wrong with that you ask? Endless pointless DIV for nothing, gibberish use of a H2 (since it's not starting a new subsection of the page under the h1), pointless redundant use of TITLE (if it's the same as the content of the tag there is no legitimate reason to put TITLE on it), endless pointless classes for nothing, class on a tag (h1) that should be entirely unique to the page meaning there's no reason for it to ever have a class, span doing label's job, span inside label pissing on accessibility because some art *** wanted it hidden, placeholder doing label's job, the idiotic pointless redundant HTML 5-tard HEADER tag, malformed form (where's the fieldset?), absolute URI's for no good reason other than intentionally wasting bandwidth, multiple H1's makign the document structure gibberish, that more HTML 5-tard bs with that stupid NAV tag (that's redundant to properly using numbered headings and horizontal rules semantically), that stupid malfing data-scraping ARIA role crap… That's 1.7k of developer ineptitude **doing 671 bytes JOB.**

From a semantics as meaning point of view using the structural rules on which HTML was created, there is NO legitimate excuse for that to be more than:

	 [Wordpress Demo Install](/)

Apart from the people making things like turdpress not knowing enough about HTML or CSS to be "designing" a blasted thing! That would provide MORE than enough hooks and selectability to be just as easily styled identically to what they were doing, in a fraction the code!!!

–------------------------------

Now that said, there are a LOT of problems that should be addressed with the current state of HTML. 

Probably the biggest is the language and perspective used in the specifications. They are written NOT for the people using the language to build websites -- which I'd point out is the ENTIRE reason it even exists, but from the point of view of what browser makers should know for implementing it...

Which is funny since the point of HTML is meanings, so apart from the difference between a block-level tag and a inline-level tag, parsing rules and so forth (basically something that shouldn't take more than 6k to explain) it's supposed to be up to the user-agent to interpret that stuff to the capabilities of the device. You want default appearance/presentation, that's CSS' job. A separate recommendations and so forth for things like element behaviors might be in order, but really how does any of that make it clear what the tags meanings are, what the tags are for, or how to use/nest them properly. 5 made some forward steps on this (mostly by getting rid of using DTD) but at the same time bloated out the spec with pointless redundant tags.

Worse is the legalese in which it is written. The ambiguous language, misleading use of words, and general poor organization of the specifications are guaranteed to make sure that "Joe Sixpack and Susie Sunshine" have NO CHANCE IN HELL of understanding it.

Lemme give you an example. "empty" -- you'd think we all know what "empty" means... Well what if I told you that this:

... is **NOT** an empty tag according to the HTML specification?

This is where the XML fanboys got confused as only EMPTY tags can use the XML shortform of 
 – DIV is never an empty tag even when it is empty as when they say "empty" they mean that it cannot wrap/contain content or other elements, not that it doesn't. So whilst 
, , , etc, etc are EMPTY tags by the specification, , , etc, etc never are, even when they are what any sane person would call "empty".

If a word as simple as "empty" can be such a confusing disjointed mess, how in blazes is a normal person supposed to decipher terms like "deprecated", "normative" or "polyglot". It's like when lawyers and judges use terms like "arrears", "indigent". "adjudication" or "tort" which you'd never encounter outside an accounting or judiciary setting. Those of us with a nice fat vocabulary may be able to make sense of it, but you take the typical mouth-breather who would have glazed over 16k ago in this document with "TLDR" and throw those words at them? Yeah, that. Not only does HTML and CSS have this problem, but so does the WCAG -- the only real attempt at making guidelines for people to follow so that websites might actually be useful to users!

Simple fact is a markup specification should be easy... but the W3C and groups like the WhatWG have made it hard; and it's gotten worse with the fact that most people wedged their heads up 1997's backside by sticking with 4 tranny, and that the WhatWG's steaming pile of garbage known as HTML 5 undoes all the things 4 STRICT was trying to move us towards.

I mean hell, if you know from professional writing what heading levels and things like horizontal rules MEAN (as opposed to their default appearance in browsers) most of the new tags like NAV, ARTICLE, HEADER, FOOTER, and SECTION are pointless redundancies. HTML 4 STRICT was trying to get rid of redundancies in addition to the presentational aspect. In fact they removed more tags for being redundant (ISINDEX, DIR, MENU, APPLET, IFRAME, S, STRIKE, U) than they did presentation (BASEFONT, FONT, CENTER). 

Take APPLET, the unofficial browser specific EMBED, and IFRAME -- all were redundant to OBJECT. The whole idea of object being to allow us to add formats either through plugins or internally via the browser for non-CDATA elements. Even the IMG tag was supposed to be on the chopping block for the next iteration of HTML to get rid of again, for being redundant to OBJECT.

So what did the WhatWG do in their ignorance of the point of HTML? Well, EMBED is now in the specification, IFRAME gets some lip service, and they then crap all over things by introducing two new and ultimately pointless tags in the form of AUDIO and VIDEO!

Or how MENU is back for some weird purpose in forms unrelated to it's original meaning that I have yet to even hear a proper explanation of what it's even there for...

HTML 5 is setting markup practices back a decade or more!!!

But again that means nothing to the halfwits, morons and fools who see nothing wrong with a 60-100k HTML file to deliver 3k of plaintext. That's not so much the problem of the specification, as it is the people sleazing out HTML either failing to grasp it, or basically going "who gives a ****!"

I think what's REALLY needed is a specification that is to HTML 5 what 4 STRICT was to 4 tranny. Clean out the redundant crap, get some damned version control back in the thing (_That living document crap can go **** itself – really there are people who think that's a good idea?_) and then write up a proper specification written in two parts – one for people using it to make websites (what the W3C likes to call "web producers") and one for those making browsers.

... because what we have right now for specifications? It ain't cutting it... and contrary to the WhatWG's mindset, documenting what people are doing instead of telling them what they should be doing is NOT the answer, nor is throwing more tags at an already painfully large set of meanings.

Preferably such a thing being built keeping the mantra "If you choose your tags based on their default appearance, you are choosing all the wrong tags for all the wrong reasons". Remember, not all users are sighted, not all user agents convey your page visually, **and search engines don't have eyeballs!**

_Which is why I laugh at the halfwit SEO nonsense where you now have alleged experts claiming search cares about your layout… uhm, no. Gee, SOE Experts are nothing more than hoodoo-voodoo snake oil doctors? Who knew?!?_

But what do I know, if I made such a thing (which I've been playing with) the

deathshadow

Oh, BTW, -webkit- values are NOT CSS – you'll not find them in any official specification. The vendor specific prefixes are supposed to be for testing purpose and NOT for production use. Generally speaking they were one of the DUMBEST things browser makers have ever done, PROOF that the browser makers have no business being the ones determining the specifications, and it's a damned fine thing that everyone except Apple has moved on from them...

Since at this point -webkit- is the only prefix you really need to use, and that's for the plethora of iOS devices with their crappy outddated steaming pile of manure browser known as Safari.

You'd almost think webkit was rotting on the vine as someone absconded with all the talent to work on a fork... Blink, Blink, know what I mean, say no more?

There's a reason a LOT of people are writing articles about how "Safari is the new IE 6".

Ayespy

@yellowfour:

I…but most importantly is the loss of a superior rendering engine (Presto).

…Which took literally hundreds of people to try to maintain and fight for web standards, and STILL could not produce good enough web compatibility (due to standards transgressions by developers world-wide in pursuit of IE, Gecko and Webkit compatibility) to attract better than a 5% user base. There is a REASON why Opera gave up on Presto. It was not an arbitrary decision. And now that that has happened, Vivaldi developers are left with no other option than to go with an engine written by others, if they are even to survive long enough to establish a new browser.

Ayespy

The initial concept was to provide a home to to Opera

640k

It would be refreshing to see a CMS use Semantic HTML5 & no divitis…

Been looking at some Micro-CMS; they have less code bloat - but I'm wondering if clients would be happier w/ that?
Some do change their minds when I show them how many times a day; WP sites are attacked.... around 20+ times for my site.
Misdirection is lots of phun.... I'm not using WP ;}

deathshadow

Wow, a year later and this got bounced.

@yellowfour:

So market share is the most important factor?

Market share is probably one of the biggest LIES in the industry… well, that's not entirely fair. In and of itself it's not a lie, but what people try to use it to claim is! Almost any time someone uses market share in a discussion, they're trying to spin a viewpoint with disinformation or make false claims.

See how for years (pretty much until Chrome started kicking them in the junk) Firefox fanboys used IE's "dwindling market share" to try and say there were less and less people using IE. 100% fabricated CONCLUSION if you understand in the slightest what share is!

I mean sure, IE's usage went from 95% in Q2 2004 to what today could be treated as 25% if you include edge (depending on who's stats you use), which you might as well since Joe Sixpack and Susie Sunshine just know they click on the big blue E. All well and good, so they lost 67% share, they must have tanked horribly on the number of users, right?

WRONG!!! Because the pool size grew; in Quarter 2 2004 when IE was at its peak, there were "only" 800 million Internet users, so they had around 760 million people using IE. Today there are a little over 3.48 BILLION internet users, so that 25% is 870 million users… so whilst losing share, they GAINED users! they GREW.

Now apply that math to Opera... Oh yeah, their going from 0.65% to a peak of 5.4% made them so inconsequential... just as their loss of share from 2008 onward didn't mean a loss of USERS -- it just meant they weren't growing into new markets as quickly as the competitors.

Share is a classic marketing tool to dupe investors and the public into drawing irrational unfounded conclusions. It's one of the best spin techniques out there and it's why unless they tell you "out of how many" it's a meaningless marketspeak datapoint.

Are you attracting users? Is the NUMBER of users growing or at least stable? Then you're good. Letting share -- even falling share -- dictate the mindset? Bullshit either trying to dupe you into doing something foolish or discourage you from accomplishing goals.

That said, I really don't have a problem with webkit/blink per-se... Blink has made a lot of improvements and Vivaldi is proving what it's really capable of. The complaints about it being "a travesty" so far as rendering engines go -- I just don't see it. It's plenty fast (V8 for JS is bloody brilliant on performance), compatibility is high (more so since Google kicked Apple to the curb)... and now that the stupid malfing -webkit crap isn't needed for most of the properties, that just leaves Safari as the odd man out.

Again why people keep comparing Safari to IE6. Thanks to iOS devices being ubiquitous, we're stuck having to support it no matter how far it falls behind Blink, Gecko, and even Edge on standards support.

The travesty to me wasn't so much that Opera threw a good engine in the trash, but that theyfailed to move over even a fraction of the user interface features that had me using Opera instead of some other browser to begin with! We're talking really simple stuff too like custom programmable buttons, portrait mode tabs, built in notes, rocker navigation, etc, etc... Opera's attempt at using blink just feels lazy, sloppy, and offers nothing to make me use it instead of Chrome...

... and to be frank Chrome to me feels like a trip in the wayback machine to the WORST of IE 3 Mac so far as UI design goes. Customization, what's that? Usability? Their entire UX team's goal seems to be "Oh you want accessibility, well *** you!"

Which laughably seems to be the attitude of most people vomiting up websites these days as well. Again, see jQuery, bootcrap and turdpress. Semantics? Graceful degradation? Accessibility? Who needs that when we can just slop together off the shelf code we don't even understand any old way and then wonder why nobody wants to use our sites.