Live data from Hacker News

Oh, Adobe... read the copy, then view the source.

muse.adobe.com

71–80 of 151 posts

Re: Oh, Adobe... read the copy, then view the source.

#71

Please, tell me this is Adobe trying to mock IE. It has to be, right? I mean, they've always sort of not valued source code, but this is beyond torturing it. This is so inspirationally horrible someone spent hours remaking it, like it should've been: http://studentweb.infotech.monash.edu/~wlay/FIT1012/muse-dem... .

Indeed. The inefficiency here is astounding, especially considering the relatively straightforward page layout involved. Original: 1496 lines, 77.9kB Your version: 104 lines, 4.75kB I'd thought we'd progressed beyond the state of a decade ago where Dreamweaver or what-have-you would build you a cumbersome and baroque html splooge to match whatever you had done in the designer, but I guess we haven't advanced that far…

P.S. The big background image is only about 49kb...

Re: Oh, Adobe... read the copy, then view the source.

#73

People on HN love ripping on Adobe. I agree that the code is gross, but can we get some constructive criticism? What's a better way to programmatically write good HTML? I'm willing to bet everybody on this thread writes their HTML by hand. How many of you have a framework for programmatically writing HTML? How many have a framework for writing HTML as broadly as Muse can?

WYSIWYG for HTML is just never a good thing. You spend more time learning the idiosyncrasies of a crippled GUI when you could just get busy in a text file.

Why? WYSIWYG works perfectly well in InDesign (which is absolutely awesome, by the way), why can it never work with HTML? I don’t really understand.

Current and past implementations are or have been bad, sure, but why can’t it work in principle?

Re: Oh, Adobe... read the copy, then view the source.

#74

People on HN love ripping on Adobe. I agree that the code is gross, but can we get some constructive criticism? What's a better way to programmatically write good HTML? I'm willing to bet everybody on this thread writes their HTML by hand. How many of you have a framework for programmatically writing HTML? How many have a framework for writing HTML as broadly as Muse can?

Well, at least they're using it. It hurts adoption if people perceive Microsoft to be tepid about WPF or Google with regards to Go. But Adobe is clearly dogfooding.

Re: Oh, Adobe... read the copy, then view the source.

#75

I recommend reading this post by Zeldman from last year: http://www.zeldman.com/2010/07/05/an-indesign-for-html-and-c... Says Nack: As I noted the other day, “Almost no one would look inside, say, an EPS file and harrumph, ‘Well, that’s not how I’d write PostScript’–but they absolutely do that with HTML.”

Good article, except for this minor point:

> Certain kinds of human creativity and expertise cannot be reproduced by machines. […] [machine's] music can never be the Eroica or “This Land is Your Land,” because there is no algorithm with the creative and life experience of Beethoven or Woody Guthrie.

Of course, I agree with the practical point where no current machine can do human art. Because of that we can't currently automatically extract the semantics of an image, or even convert a post-script document into clean HTML. So, it doesn't affect the conclusion in the foreseeable future.

But one can't seriously believe there's no algorithm behind an artist's art without believing in some kind of ghost controlling her brain, and that ghost somehow doesn't run an algorithm. As far as I know, there is no such ghost. It very much looks like our cognition (including our art), is entirely the product of physical processes, even though it definitely doesn't feel like it.

Now, I reckon art is not just the product of some internal algorithm, running in isolation from the rest of the world. We're highly interactive beings, and our output mostly depend on our input. But there is some kind of algorithm which does all these interactions, though it is likely incredibly complex.

My point is, I wouldn't loose hope of automating something that currently, only humans can do. Take spam filters, for example. With very little knowledge, they can take out spam with stunning accuracy. But if no-one told me about Bayesian filters, I would likely try to make the computer parse the whole e-mail like a human, then give up, thinking that only humans can understand those e-mails well enough to filter them (note my mistaken assumption that the spam filter somehow must acquire some high-level understanding of the e-mail to do its job).

Re: Oh, Adobe... read the copy, then view the source.

#76
So they use tables. Big deal.

I don't get that CSS snobbery. Tables do work on even older browsers. That's something you want for a tool that generates code for people who don't want/can't put up with writing HTML themselves. For them the product has to work and look good in most of the browsers.

Re: Oh, Adobe... read the copy, then view the source.

#77

Earlier quoted context omitted.

Do you really think everyone has 100+ hours to spend learning the idiosyncrasies of HTML and CSS? That's asking a lot for someone that just wants to put up a landing page for an idea, or to design their portfolio. Everytime my artist friend wants to put their portfolio online, I suggest they start by writing some simple markup and half an hour later I'm explaining the finer points of the box model while they whinge a…

That's why we have WordPress, Tumblr, etc., even things like launchrock, about.me, shopify, the list goes on.

You mean things that are (eventually) html page generators?

Re: Oh, Adobe... read the copy, then view the source.

#78
post #73

Earlier quoted context omitted.

WYSIWYG for HTML is just never a good thing. You spend more time learning the idiosyncrasies of a crippled GUI when you could just get busy in a text file.

Why? WYSIWYG works perfectly well in InDesign (which is absolutely awesome, by the way), why can it never work with HTML? I don’t really understand. Current and past implementations are or have been bad, sure, but why can’t it work in principle?

It's hard (not impossible) to make it work in principle because a printing press doesn't need to infer meaning from the post script or whatever you provide it. A browser does need to, so you'd need to layer the extra semantics on top of your WYSIWYG editor.

Which means asking questions like "this is 36 pixels high: is it a heading,; or is this just a landing page with big text?" etc. So maybe I lack imagination, but I don't see it being that easy a problem to solve from a UI point of view.

Re: Oh, Adobe... read the copy, then view the source.

#79
post #76

So they use tables. Big deal. I don't get that CSS snobbery. Tables do work on even older browsers. That's something you want for a tool that generates code for people who don't want/can't put up with writing HTML themselves. For them the product has to work and look good in most of the browsers.

It's not CSS snobbery. It's HTML snobbery, which to some people still matters, for the usual accessibility reasons as well as wanting to write the correct code for the job.

Re: Oh, Adobe... read the copy, then view the source.

#80

I recommend reading this post by Zeldman from last year: http://www.zeldman.com/2010/07/05/an-indesign-for-html-and-c... Says Nack: As I noted the other day, “Almost no one would look inside, say, an EPS file and harrumph, ‘Well, that’s not how I’d write PostScript’–but they absolutely do that with HTML.”

I find your largely contextless restatement of the quote a bit odd, when the actual post is quoting that from somewhere else, and explaining why this is so (when out of context the quote seems to imply that this shouldn't be so).
Post reply on HN