Slashdot Mirror

"WebP is better in every way."

Except for browser support.

No thanks, I'll stick with PNG. For web page graphics it is a perfect little format and has great browser support. If I am truly optimising page load times then I can put all my little graphics in one big PNG and use CSS sprites.

For those wanting a comparison of PNG vs WebP you can get one here. The main advantage is alpha transparency with lossy encoding, e.g. transparent backgrounds for JPEG images. This is actually a pretty good application, as I once had to code my own in Javascript using two images: a JPEG and a greyscale PNG of the mask.

You think this is bad, try a password keylogger implemented purely as CSS (no javascript):

https://css-tricks.com/css-key...

The real vulnerability in both this and the article example is allowing 3rd party code injection. If you can't trust the source of the code, the language being used doesn't really matter. There will be ways to abuse it.

I see your point in general, but I'd like to point out that the noscript web in 2018 is not quite the web circa 1997. A lot of things that used to require script no longer do, thanks to improvements in HTML and CSS. For example, show/hide buttons don't require script if a page can style the sibling of a checkbox or radio button. The same is true of animated transitions, as well as styling a page differently for different viewport sizes. HTML5 also includes declarative form input validation attributes that reduce the need for script when pre-validating user input before submission to a server that performs authoritative validation. These include required, pattern, min, max, and step.

I've seen some places where they could have the files sizes of their images cut in half without impacting quality.

Until you view the picture on a high-DPI monitor, at which point the images become a blurfest compared to the adjacent text. To work around this, some sites send photos at double resolution in case the user is on a Retina display or in case the user chooses Zoom. The srcset attribute is supposed to fix this but still doesn't work correctly in IE or Edge.

Yes. Some people just want an MFing website. Others are willing to spend an extra 151 bytes on making it readable.

Even showing and hiding replies can be done without script in 98 percent of browsers, using a small amount of CSS3 to restyle a checkbox.

Nobody wants to be forced to use a desktop computer to see the whole web page.

I was thinking of a news site that shows photo, headline, and first paragraph to desktop or tablet users, but only the headline and a differently cropped photo to users of 6" or smaller devices. This way you can still fit as many stories into 320x440px.*

The real threat to bandwidth usage is [...] embedded CSS/Javascript in the HTML that can't be cached from page view to page view.

I thought additional HTTP 1.1 requests were more expensive than repeating any styles or scripts that block rendering of the first screen of the document. Google PageSpeed Insights recommends that web authors inline CSS above the fold.

* In CSS, px means roughly 1/2700 of the distance from the eye to the surface, rounded to the nearest hardware half-pixel.

Also, True Type / Postscript / Web fonts still don't support color gradients.

And why should they? Fonts hold letter shapes and sometimes ligature data. CSS is for presentation/styling/color. CSS doesn't yet support color gradients on text (only backgrounds), but there are clever workarounds.

Slashdot isn't responsive. (Don't know about beta, I stayed on classic.)

This is responsive: https://css-tricks.com/
Tell me what's wrong with it.

Looks fine to me.

I use a PHP file as my CSS. Take a look... http://www.barelyfitz.com/projects/csscolor/ or http://css-tricks.com/css-variables-with-php/

For example, some ads can be an entire webpage that is saying how awesome this restaurant around the corner is through some sort of activity-finding / eatery finder website or whatever.

Things like large banners and the like just don't work right unless the device is large (tablet-sizes )
For a mobile phone, text-ads are about as close as you can get, maybe a tiny banner or ticker fixed to the top or bottom.
I'm speaking 1.5 lines of an average font optimized for mobiles, which is rather small, but still allows some space to add something more fleshed out than what could just be expressed as text.
Since people tend to want to view in landscape modes and more are adding support for this, also have space for ads that can be viewed in this format.
Now these ads would be on the left or right side, be around 80~% of the screens portrait width and you could fit a fair number of them in.
There is already some sort of a standard banner-ad of this size, but it isn't really that popular anymore for obvious reasons since screens are now massive and bandwidth plentiful.
I can see a return to older advertising dimensions for mobiles.

Using CSS media queries, you can do this trivially.
Of course, always have a mobile-optimized site which is detected and sent from the server.
Don't do some CSS and JS nonsense to hide non-mobile stuff. Bandwidth is costly.
I was just reading up on this recently and was actually rather surprised at how damn flexible this stuff really is. You can do so much with it.
It finally added conditional styling that we have always wanted. Anyone who has ever developed knows the pains of dealing with different resolutions and the limits of the fluid layouts. (using older CSS methods that is, and IE of course)
Things are finally getting useful and not obtuse.

Are you sure that it was this patent that was ruled invalid? The patent that you've linked to seems to describe the use of a visual metaphor to implement the slide-to-unlock feature (like this one: http://css-tricks.com/wp-content/uploads/2010/08/slidetounlock.png). The Neonode is similar, but doesn't have that - see this video review from 4 mins in: http://www.youtube.com/watch?v=Tj-KS2kfIr0.

Coming onto ODF and OOXML, we can start with the fact that there was one clear standard, ODF, that everybody had agreed on. Instead of joining an open process and ensuring that it's own needs were included, Microsoft "broke away from the standards process". Having done that, first Microsoft "broke the standards organisations " by ensuring that committes which had previously mainly consisted of technical experts were overloaded with Microsoft's commercial cronies. Then Microsoft "broke the standards it was trying to have implemented " by ensuring that the standards were at the same time incomplete ("do this as MS Word 2000"), inconsistent and unimplementable. Next Microsoft "broke the interoperability you would expect the standard to deliver" for ODF when Microsoft implemented ODF. Just recently, Microsoft has completed the circle by delivering an OOXML implementation which "broke the rules of the standard" by not following it. Microsoft has promised to to deliver a standards conforming implementation in 2015. The only question is, will Microsoft "break with it's standard practices" or will it "break it's promise to follow the standard? Did you have another meaning of "break the standard" in mind?

As a full time web application developer I hate them mostly because of browser incompatabilites with standards - HELLO Microsoft! DO YOU HEAR ME!!! Your IE browser (any version) sucks big green donkey dicks! EVERY VERSION! We are sick and tired of having to do a million HACKS to get your crappy browser(s) to render / handle pages correctly! Why is it Firefox, Opera, Safari kick your browsers ass? Because they are more standards compliant than you fucking browser(s)!!! I can write code that works perfect in Firefox, Opera and Safari but of course doesn't work in IE - I have to do hacks from hell to get IE to work! I'm pushing to use an "anti-IE" script in our apps - basically refusing to support IE because of the crappiness of IE. I'm looking at modifying the IE6 Blocker to work with -all- IE's

Speaking as a web developer, nowadays it is actually the other way around. You usually have to code hacks for IE6 and IE7 and let all other standards-based browsers figure themselves out.

There are, however, specific things that Webkit does different, and testing for "KHTML" in the UA string is pretty much the only way to fix them.

Don't complan to the web developers, complain to the W3C and the browser makers, who won't finalize standards to implement things like "opacity" in a standard format (in Mozilla it is "-moz-opacity", in KHTML/webkit it is "-khtml-opacity", in W3C CSS3 it is "opacity", in IE you have to do a DX transformation - see http://css-tricks.com/css-transparency-settings-for-all-broswers/ for an example of the retardedness).

In CSS you can just apply all the classes but if you have to dynamically manipulate the stuff in Javascript you have to know it's correct name to modify it properly.

This is just one example of many.