rs79 last edited by
" and here's how you make the first heading: "
" Sir Tim beams. But this was a facepalm moment. Note the similarity: ROFF HTML .p
<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>
Frenzie last edited by
By the way, the CANVAS element allows for stuff like that, in a way. http://logand.com/sw/wps/index.html
ThomasWrobel last edited by
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.
ersi last edited by
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.
*** 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.
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
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".
yellowfour last edited by
I tend to agree. Webkit is actually not very ergonomic and efficient to browse in. It gained popularity only because of Apple and Google. That Opera and Vivaldi chose to follow this is a travesty and disservice to the browsing community. Not just eliminating competition, narrowing the market of viable rendering engines, but most importantly is the loss of a superior rendering engine (Presto).
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.
yellowfour last edited by
So market share is the most important factor? then you should question why they are making Vivaldi in the first place, which we know will never achieve 1% of market, regardless of engine.
new browser to what purpose? does the world need another browser? 99% dont care. for the 1% that do care, would a new browser built on top of mainstream engine make any difference? the same engines that support 3rd party plugins to customize your browsing experience.
so pray tell what is the killer feature that entices Chrome users to jump ship to Vivaldi and Opera. so far nothing.
The initial concept was to provide a home to to Opera
640k last edited by
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 ;}
It would be refreshing to see a CMS use Semantic HTML5 & no divitis…
It would be a nice brave and good world if Web creators would know what Semantic HTML means.
I fear we two here in forum are the only who were concerned about Web standards – ok, Molly Holzschlag from Vivaldi is an other one.
Wow, a year later and this got bounced.
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.