Show HN: CSS Pokemon – created with clip-path and CSS variables
projects.lukehaas.meShould be called CSS pikachu unless you can somehow swap them. Good job though, better than I could do!
Edit: Major correction: it appears Firefox only supports clip-path behind a flag. Enabling this flag makes the experiment appear in Firefox.
---
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?
Because someone took time to make this, and we tend to approach Show HN projects with an open mind.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.
I understand, as others have said elsewhere, that it's just an experiment, and as such cross-browser support isn't as much of a priority - it's not a product that people need to work. I've made plenty of experiments myself that only work in one browser.
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.
You say it's subjective, but when you start posting things like the above, you're deeming this project as unworthy of being on HN just because you feel it's "novel". The OP never claims the technology is new or cutting-edge, so why even bring that up? And there's really no need to link other css artworks in an attempt to undermine the work at hand.much more impressive drawings have been created than this. The added animation doesn't add much.You could be right. I wouldn't conflate "novel" with "new or cutting-edge" (one can still do novel things with old tech) but even just limiting it to novel may be unfair. I guess this is just something I associate with HN submissions from experience - many things posted here really genuinely blow me away. This didn't. The normal reaction to that might be to just say nothing, but given the browser support issue, I commented.
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.
OP provided the source. Why not make a pull request and make those implementations and submit then back? Would be a good learning opportunity for some, no?
Unfortunately Firefox only supports clip-path behind a flag.
I was unaware of this. Thanks for the info. Edited.
It seems to me that nowadays Webkit/Blink has replaced IE for developers not caring about interoperability – with some even going so far as to claim „IE? but nobody uses that!“.
FWIW clip-path is specced and in CR stage right now. I think it's okay to implement it provided that there is an understanding that any further changes are reflected even if it breaks existing code using the new property.
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...
Clarification: My comment was not primarily about browser developers, it was about web developers that do not care about interoperability – and either do not test in non-Webkit/Blink browsers or declare that for some reason (e.g. marketshare, “it is just an experiment”), other browsers are irrelevant in their specific case.
Ah, fair point. Yeah, this irks me a lot.
It's important for web developers to experiment with new browser features. Browser vendors encourage this as it can help them with crushing bugs early and refining their specs.
Yes, which is why experimenting with features on the standards track is okay. At a certain stage it becomes less likely that the feature will change behavior.
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.)
Eh, it always only seems to be the case for experiments. Stuff that has no use case besides "looking fun" and probably being a fun challenge to work at. There are a few FF only, and many that are Chrome only.
> much more impressive drawings have been created[0][1] than this.
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.
Seems to work for me in mobile safari
Safari is webkit.
Edited, cheers.
Damn cool, I just love polygon cuts! CSS has become quite powerful in the last few years. Guess we're not so far from being able to replace images/icons/logos with "design code" written in CSS in the coming ten years.
Here's a book on ABCs for babies done entirely in CSS:
We can sorta already do that by inlining SVGs inside CSS (but perhaps it's cheating)
I am not sure what I am looking at. I see a big yellow rectangle. Should I be looking at the code only? Should I press a button?
View it in Chrome. It appears as a Pikachu made out of shapes, like in the screenshot I took here:
https://dl.dropboxusercontent.com/u/67216205/csspokemon.png
In Firefox or other browsers, it just appears as a yellow square.
Thanks for the screenshot.
I think the old "Best Viewed With Internet Explorer" is back (only ... with chrome as the new ie)
Except chrome is open source and actually improves multiple times a year...
Chrome is closed-source (though based on the open-source Chromium project so it can nicely claim the associated kudos of an open-source project).
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)
IE 6 did not improve for many years (7?) until Firefox got them to do IE7- also comparing the parts of chrome to the parts of IE6.... I'm not sure I buy your quick dismal of the open source difference between the two engines. I can download and compile chromium which is almost identical to chrome. What equivalent did we have with IE from 2000 until today I still can't download IE and compile from source?
In terms of improvement, I was referring to IE4->IE5->IE6
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.
so 1997 to 2001? MS was innovating. What about from 2001 to 2006? 5 years of zero development? Big difference between Chrome and IE6. IE7 (2006 - 2009) IE8 (2009 - 2011) You can't seriously tell me this is comparable progress to Chrome/Mozilla/Safari? My issue with anyone equating IE6 to recent browsers is they are not comparable. It was really bad during the IE6 days and we had no alternative. Today when new features land in Chromium they are opensource, available for the Mozilla, Webkit, and IE teams to study. IE is still closed source. Whether it calls itself Edge or IE it is still a closed source browser. A closed source browser is what allowed 5 years of zero. If you want to point out privacy concerns with Chrome please run Chromium - https://www.chromium.org/getting-involved/download-chromium or run Firefox. These are at least Open Source e.g. our internet is free. IE is the ultimate evil to the internet and any business that operates on the internet should remember IE is a threat because it is closed source.
As I already said above, I'm analogising; pointing out minor inconsistencies doesn't undermine the comparison. No two scenarios are ever identical. The post-IE6 history you're referring to is a bit moot: we have yet to see where Chrome will go.
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.
> the Edge engine is open-source,
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.)
> Chrome is closed-source (though based on the open-source Chromium project so it can nicely claim the associated kudos of an open-source project).
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?)
> the vast majority are just aliases for non-webkit-prefixed names
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).
> Is there a reason this exists for the -webkit prefix but not for the -moz or -ms prefixes?
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.
I think it's supposed to look like a Pikachu made out of polygons. Seems to work as it should in latest version of Chrome over here. JS enabled.
I made another pokemon in CSS (view from behind): https://jsfiddle.net/t2mngvwn/show/
I found this very cool and surprisingly beautiful!
I'd love to understand the techniques and processes @lukehaas used to create it.
Anyone notice how a website meant to showcase some CSS messed up the code display and gave it double scroll bars? Haha.
The Pikachu looks great though ;)
Awesome!
I never realized they introduced a yellow rectangle as a Pokémon.
Galaxy S7