Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Are We Taking CSS Too Far?

blog.echoenduring.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Are We Taking CSS Too Far?

#41

Post by mike-cardwell »

metamemetics wrote: post #39
tptacek wrote: post #5

It bothers the hell out of me that many web devs have decides that all HTML and CSS should be hand-editable and comprehensible at a glance. Obviously, it's vital that both those features be possible. But it's not obvious to me that those features be required in all markup; on the contrary, it seems far more useful for there to be a standard, predictable strata of functionality that developers can target with compiler…

> the ability to do pure-CSS buttons and icons is a win. CSS is not designed for assembly of vector graphics, we have SVG for that. SVG is a well defined and logical format for web vector graphics. The ideal case would be Firefox and IExplorer implement embedding SVG graphics with to catch up with Opera\WebKit. Also since SVG is xml based any web app could also probably implement dynamic generation and cacheing for b…

I didn't realise Opera/Webkit would display SVG from an img tag! They don't execute the embedded javascript though, you need to use an object tag for that still.

Re: Are We Taking CSS Too Far?

#42

Post by mike-cardwell »

mgcross wrote: post #22
nanairo wrote: post #10

I agree with the author wholeheartedly. I always assumed these were experimental of the "just 'cause I can" type. Trying to show off how far CSS can go, but not really in a realistic usage. I read here though that people believe this is a useful type of use. Without getting into a flame-war if it is or isn't, I think the answer there is SVG: that should be just perfect for these sort of usage.

Unfortunately, IE 8 won't render SVG at all. I suppose graphics could be designed in a vector-based tool like Illustrator that can export SVG for compatible browsers as well as raster for lte IE8.

1.) apt-get install imagemagick

2.) convert image.svg image.png

3.) Profit

Sometimes if I want a simple GIF knocking up, it's quicker to open vi and write the SVG, then use imagmagick to convert to GIF, than it is to open a proper paint program.

Re: Are We Taking CSS Too Far?

#43

Post by mike-cardwell »

robin_reala wrote: post #38
zokier wrote: post #21

Earlier quoted context omitted.

SVG didn't gain the needed momentum as it's approach was more revolutionary instead of evolutionary. Also Internet Explorer, although I'm not sure how it fits in this situation as it surely can't support all that fancy CSS required to do advanced graphics either.

SVG is supported (and hardware accelerated) in IE9.

Also, SVG can be embedded directly in HTML5 now. Also, Firefox 4 seems to be making progress on actually supporting SVG animations now.

I don't think SVG is dead, I think it's getting closer and closer to the point where people will actually be able to start using it as was intended. Not quite there yet though.

Re: Are We Taking CSS Too Far?

#44

Post by wihon »

Is there any way we can unite the global community and ditch IE? Or at least make it catch up with everyone else? I've only been involved in the world of web for a short time - but even for me IE is a massive clumsy thorn in my ass.

I agree with the author about the slightly over-the-top usage of CSS to make graphics - but what bothers me more is the fact that IE may either fail to render your creations properly (c.f. http://bit.ly/aqv6jT from the article), or make perhaps better alternatives (like SVG) unecessarily painful.

Re: Are We Taking CSS Too Far?

#45

Post by arethuza »

protomyth wrote: post #9

Somedays I just wish we had used Postscript with hyperlinks instead of HTML/CSS/Javascript.

Have you ever used a hypertext environment built around PostScript? I worked with one for a few years in the early 90s (HyperNeWS).

While this was very powerful and hugely entertaining from a geek perspective it was never going to be suitable for a wider audience - primarily due to the nature of PostScript itself. Don't get me wrong, I really liked PostScript as a programming language, but you have to admit that it isn't something that most people would be happy working with.

Re: Are We Taking CSS Too Far?

#46

Post by soren_dahl »

jacquesm wrote: post #16
soren_dahl wrote: post #11

Earlier quoted context omitted.

I'm not entirely sure I understand your point. All of these examples were likely designed in PhotoShop (or Gimp) and then realised as PNGs, GIFs or in this case CSS. Beyond that adding a button is pretty simple regardless how you do it; however, how that button is rendered, which is the point, is certainly simpler with an image (and can be made trivial for developers with appropriate use of CSS).

I think what tptacek is getting at is programatically describing the button which then gets created in an automated way rather than manually creating it using a graphical tool such as photoshop.

You still have to "manually" create it in the first place. After that you can automate it regardless of how you choose to render it.

Re: Are We Taking CSS Too Far?

#47

Post by rix0r »

sjtgraham wrote: post #15

"Are We Taking CSS Too Far?" I would say yes. I first had thoughts like this when Webkit introduced CSS animations. Something like an animation seems to me to be a behavioural concern rather than one of presentation, and thus belongs in the JS layer. Pragmatically speaking I don't mind CSS animations as much since they can do things that are non-trivial to pull off convincingly in JS, e.g. 3D transforms. I also under…

A nice compromise would be:

transformations in CSS (display concerns), animations in JS (behavioral concerns)

WebKit went ahead and did both...

Re: Are We Taking CSS Too Far?

#48

Post by jff »

jonhendry wrote: post #32
jws wrote: post #27

Earlier quoted context omitted.

At the rendering level Postscript and PDF are similar, but Postscript is a complete language. You could send semantically structured content and do appropriate layout on the client device all from inside Postscript. You'd probably want to write in some other language or tool and use Postscript as an object language, like in the day of printers. The huge difference is that the evolution of the media would be in the ha…

The Postscript rendering has to be sandboxed, running in a secure, limited context. At least, that's what NeXT had to do with their Display Postscript. Prior to that it was possible to email someone a postscript file which the WindowServer would try to render for display in the mail window. One such file that went around would, when you clicked on the email, grab all your windows, spin them around the screen, and thr…

Yeah, thank god we now have operating systems which can't be harmed by email attachments... oh wait.

Re: Are We Taking CSS Too Far?

#49

Post by jff »

arethuza wrote: post #45
protomyth wrote: post #9

Somedays I just wish we had used Postscript with hyperlinks instead of HTML/CSS/Javascript.

Have you ever used a hypertext environment built around PostScript? I worked with one for a few years in the early 90s (HyperNeWS). While this was very powerful and hugely entertaining from a geek perspective it was never going to be suitable for a wider audience - primarily due to the nature of PostScript itself. Don't get me wrong, I really liked PostScript as a programming language, but you have to admit that it i…

I use postscript all the time--as an automatically generated result of my LaTeX files. A decent set of LaTeX macros would let you make basic text+hyperlinks postscript web pages without too much trouble, I'd think.

Re: Are We Taking CSS Too Far?

#50

Post by jws »

jonhendry wrote: post #32
jws wrote: post #27

Earlier quoted context omitted.

At the rendering level Postscript and PDF are similar, but Postscript is a complete language. You could send semantically structured content and do appropriate layout on the client device all from inside Postscript. You'd probably want to write in some other language or tool and use Postscript as an object language, like in the day of printers. The huge difference is that the evolution of the media would be in the ha…

The Postscript rendering has to be sandboxed, running in a secure, limited context. At least, that's what NeXT had to do with their Display Postscript. Prior to that it was possible to email someone a postscript file which the WindowServer would try to render for display in the mail window. One such file that went around would, when you clicked on the email, grab all your windows, spin them around the screen, and thr…

Sandboxing would be required.

Delegating an area of display would also need to be part of the security model to support things like third party ads.

Ah, the details…

Post reply on HN