Particularly amused by
OOCSS says to never specify elements in the CSS, right? :)
Oh, Adobe... read the copy, then view the source.
131–140 of 151 posts
Re: Oh, Adobe... read the copy, then view the source.
#132The sense I am getting is that GUI generation of markup code is as inevitable as was the first compiler back in the old days. Whether that point is now or not remains to be seen. Back then we had a combination of increase in RAM sizes/processor speed and democratization of Computers beyond advanced research laboratories, that prompted this change. It no longer was necessary to worry about that extra 10 KB or so of cr…
Are you too young to remember front page? We've already trod this path and it lead us to dark places.
Like I said the correct time and the correct product will be the beginning of a new era. It definitely wasn't time then, and it may not be now, but isn't it kinda inevitable, that we would someday move to a layer of abstraction above the html code?
Re: Oh, Adobe... read the copy, then view the source.
#133Earlier quoted context omitted.
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?
One big part is that when something is designed for print, it is essentially always designed for a fixed size page, so you don't have to deal with resizing. Then there is the fact that web sites have to cope with people not always having the same fonts you do - which makes it almost impossible to do pixel perfect designs involving text rendering. Then there is the fact that something like an Indesign document doesn't…
I’m not suggesting to slavishly copy InDesign and I’m not saying it’s easy. InDesign would be absolutely horrible for web design. I’m merely suggesting that WYSIWYG for HTML and CSS is not impossible.
Being able to flexibly test (e.g. different fonts, different resolutions, different browsers) would certainly be one of the requirements, as would be the implicit assumption that pixel perfect designs are not possible.
As for style and content? InDesign does actually separate them to a degree. It’s not perfect but neither is HTML at that task. The concept of character, paragraph, list and table styles is central to InDesign. It’s what makes InDesign so great. It even has a bare bones text input mode where all you do is type completely unstyled text. It’s then easy to apply all the different styles you made to your text.
I think a truly powerful WYSIWYG HTML editor is eminently possible, someone has only dare to do it.
Re: Oh, Adobe... read the copy, then view the source.
#134Please, 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... .
Thanks for that. I know a little about ancient-style table-layout web dev, but didn't know what the "proper way" of laying out that site would have been.
Re: Oh, Adobe... read the copy, then view the source.
#135Earlier quoted context omitted.
This . And, not to mention no business owner want to get locked into a solution, they want their "data" transferable and standardized to at least some extend. The code this produces is so horrible you've lost all the time spent with it. Muse dies out, and your time spent in it dies with it.
And, not to mention no business owner want to get locked into a solution, they want their "data" transferable and standardized to at least some extend. That's a weird thing to say. Why do many business continue to use things like MS Office - or rather, its fabulous file formats then? Or other vendor-lock-in products? Don't misunderstand me, I'd wish all businesses would think like this, because open standards are inf…
Completely off-topic, but - like it or not - business runs on Excel. I certainly don't because I have to deal with it on a day to day basis. There's simply no convincing them to move to another format. Excel is the defacto "move numbers and data around" file format in the organization I work for.
Re: Oh, Adobe... read the copy, then view the source.
#136On a casual inspection this is just bloated ineptness, exactly what I have come to expect from Adobe.
One passage consisted of a string of empty divs of the form which a decent 'code generator' would simply have omitted. In fact the bulk of the bloat appears to be divs which add nothing to the page.
I strongly suspect one previous version of this code generated tables, then they got the "tables used for layout are bad" memo and did a simplistic translation to nested divs.
Perhaps, to be charitable, they have debugging turned on.
Re: Oh, Adobe... read the copy, then view the source.
#137I 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.”
No, clean HTML semantics still matters a lot! Forget about programmatic efficiencies like crawlers and page load times. Think about the poor web dev who is handed this steaming heap of bad markup like so: Management: "We need you to change all the buttons on this web site and enlarge the logo." Web dev: "OK, these pages were puked out of Muse. Do you have the Muse project files and a copy of Muse for me to install?"…
So guess what? HTML is still source code not a machine language.
Your metaphor would be great, if it wasn't for all the times developers (myself included) have been asked to dig into assembly or bytecode to fix something when the higher level source file had been lost to the ages.
Compared to those, editing machine generated html is a treat.
Re: Oh, Adobe... read the copy, then view the source.
#138Earlier quoted context omitted.
And how much is it compressed? Let's see... ~ $ curl -s 'http://studentweb.infotech.monash.edu/~wlay/FIT1012/muse-demo/' | gzip | wc -c 1741 ~ $ curl -s 'http://muse.adobe.com/index.html' | gzip | wc -c 11521 Hmm, so 11.5kB vs 1.7kB with gzip, which I believe browsers can usually handle. That's a factor of 6.6, incidentally. I don't know much about this, but might it still be ok? I thought to check this because of ri…
Keep in mind that those connections are all going to be stuck in TCP slow start (gradually improving) for the duration of their communications, meaning that the smaller version gets loaded in 2*RTT, as it will probably fit, in it's entirety, in 2 packets. The larger one is going to take 8 or so packets, meaning a lot more RTTs (probably at least 4, assuming aggressive TCP tuning, and possibly 6. Since RTT can easily…
Basic RFC 2581 should hardly count as an aggressively tuned stack, and even it'd do the larger file in 4 roundtrips (syn/synack, req/2 packets, -/4 packets more, -/8 packets more). These days even an initial cwnd of 10 might not count as aggressive any more, given it's the default initial cwnd on recent Linux kernels...
Re: Oh, Adobe... read the copy, then view the source.
#139Oh heavens! An ugly html file? We can't have one of those dirtying up our monstrosity that poorly attempts to turn a document into an application.
Re: Oh, Adobe... read the copy, then view the source.
#140I 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).
it's a teaser not a TL;DR; read the context.