Show HN: CSS Pokemon – created with clip-path and CSS variables(projects.lukehaas.me) |
Show HN: CSS Pokemon – created with clip-path and CSS variables(projects.lukehaas.me) |
---
It's Webkit/Blink-only - no support for other browsers. It says it uses clip-path and variables, both supported in Firefox, so I see no compelling reason for this.
Also viewing it in Chrome, I don't see anything that would actually require the use of clip-path or variables - arbitrary triangles have been possible in CSS since the beginning, and much more impressive drawings have been created[0][1] than this. The added animation doesn't add much.
Why is this currently #6 on the HN front page?
Why is this currently #6 on the HN front page?
If it doesn't work on your browser, then try another one. The OP isn't asking you to buy anything or force anything down your throat.
However, for many experiments like this, they're doing something somewhat novel using a tech a single browser has just introduced - in those cases, it's limitations that lead to lack of interop. In this case, it just seemed a bit disappointing. That is subjective of course, but it was my - I think warranted - first reaction.
All browsers do this. Firefox implements around 88 properties (30 of these are "logical properties", which aren't exactly new properties) that Chrome doesn't[1] and Chrome implements around 68 properties that Firefox doesn't[2].
The numbers are a bit skewed here. My method of collecting the list of "properties that Firefox implements" included preffed-off properties, but the same is not true for Chrome, so for example the `grid` property shows up as implemented in Firefox but not Chrome even though both have it behind a pref/flag.
However, there are some properties implemented in Firefox without being behind a pref (ruby-align, scroll-snap-foo, image-orientation are examples).
-------------------
I do feel that in general Blink does push a lot of nonstandard (or not on the standards path) features into the web at times. But I don't have anything to back that assertion up.
Blink is being interoperable in this particular case.
[1]: https://manishearth.github.io/css-properties-list/?stylo=sho...
[2]: https://manishearth.github.io/css-properties-list/?stylo=sho...
Dude, that is highly subjective and you can't deny it's really impressive done. Stop being a fucking douchebag. I for one thinks this beats both your links.
Here's a book on ABCs for babies done entirely in CSS:
https://dl.dropboxusercontent.com/u/67216205/csspokemon.png
In Firefox or other browsers, it just appears as a yellow square.
I'd love to understand the techniques and processes @lukehaas used to create it.
The Pikachu looks great though ;)
Galaxy S7
This works in Firefox:
much more impressive drawings have been created than this.
The added animation doesn't add much.
Given that I was additionally mis-attributing the non-cross-browser functionality to the author (see edit - it works fine in Firefox), my own subjective reaction to it is probably that little bit more unfair again now.
The problem arises when the experimentation is done with entirely new features that the browser wants to push (features which haven't been discussed and somewhat settled on with other browsers). If they aren't behind a flag, sites start using it, and then you have to support the legacy syntax forever.
clip-path is on the standards track. It's not going to change much. So browser vendors exposing it by default is fine.
(However, if you're building an experiment using these, at least test in other browsers and put up a warning that it won't work in some browsers. A lot of the interior issues today are because folks only bother to test in chrome. Ultimately this means that all browsers have to copy Chrome bugs to make things work.)
IE also "improved" rapidly back in the IE4/5/6 days, adding features such as CSS filters and AJAX. These "improvements" were considered much needed progress by developers at the time; later, with the wisdom of hindsight, rightly seen as proprietary extensions with little to no consideration for interoperability.
And if you think the Blink team's membership of, and contributions to, WHATWG/W3C/&c. automatically ticks all the friendly interoperability boxes, you've clearly never encountered monstrosities such as https://compat.spec.whatwg.org/ (created and maintained by Mozilla)
I'm not really sure what you mean when you say "I'm not buying your quick dismissal": I never dismissed anything nor made out either that there is or isn't a large difference between the engines. I just corrected a statement that is definitely factually incorrect (and unfortunately believed by all too many).
On the actual differences between them, Chrome may be "almost identical" to Chromium, but unless you're working for Google, or have very comprehensively disassembled it, the differences is not easy to measure. What could be tiny in binary size could still be a massive change in behaviour, particularly in terms of things like telemetry.
Beyond that, they are of course not equivalent, they're just analogous. Finding a few tiny chinks in the comparison is not the same as invalidating it though. The primary analog is the approach to interop, and the resultant behaviour of the development community. Participation in standards bodies is an improvement over the IE6 days, but if you take a deeper look at Blink development, you quickly realise it's a pretty insignificant one in practice. Google controls the HTML5 spec. (the editor is a Google employee and the WHATWG is not a democratic body like the W3C), and outside of that the Blink team basically just implement what they want and specify later, rather than the reverse. The response of the development community: supporting the monopoly by ignoring interop - is pretty self-evident from links like this one.
My impression is that there aren't any closed-source bits in the browser itself (i.e., there are no proprietary patches to Chromium code), it's just the Google account integration, plus things like Hangouts or Cast or whatever which mostly take the form of extensions, plus things like the Flash plugin.
(Also, that compat page looks very non-monstrous; the vast majority are just aliases for non-webkit-prefixed names, and of the remainder, nothing is anywhere comparable to CSS filters or XHR. Is there a reason this exists for the -webkit prefix but not for the -moz or -ms prefixes?)
This ignores the history of many of these. The webkit-prefixed names came first, and the standardization folks just decided to make the unprefixed forms work the same way. If Chrome implements something as a prefixed property that folks start to use, standardization will be heavily skewed towards their syntax and semantics.
Also, the document does not include some things like -webkit-gradient which Firefox still implements (though I'd like to try and remove it). -webkit-gradient has more features than standardized foo-gradient and causes some complexities in the Firefox code.
(-webkit-gradient wasn't a Chrome thing, however, it was an Apple thing. There's a long and boring history here)
> but not for the -moz or -ms prefixes?
There aren't (m)any webpages out there using moz/ms-prefixed properties that don't use the webkit or standardized versions too. Also, IIRC Firefox and IE stopped prefixing things earlier on (could be wrong here).
I assume because the feeling is that -moz prefixes no longer form part of the "de facto web." Targeting for desktop Chrome isn't as common anymore, but this document seems squarely aimed at the mobile space, where Safari-specific (and to a lesser extent Chrome- and Android-specific) functionality is more or less epidemic.
Minor factual note: the Edge engine is open-source, so your arguments for studying Chrome's implementation source applies equally to Microsoft at this stage.
> IE is the ultimate evil to the internet
This is straying very quickly into hyperbole.
The debate about open-/closed-source somewhat misses the mark anyway. Opera (Presto) was always entirely closed-source and it did much more for the open web than most. The killer is market dominance - lack of diversity leads to bad things. And IE has long since lost its market crown.
Only the Javascript engine is open source, fwiw. That's not the majority of the browser.
(Unless EdgeHTML was open sourced since I last checked.)