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.

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.

  much more impressive drawings have been created than this.
  The added animation doesn't add much.

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.

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.