It spit this out:
https://gist.github.com/JacksonGariety/6766626
(after struggling and realizing CMD+S wasn't saving my file)
I feel sorry for whoever was tasked with making this application.
We are glad you are trying out GWD. You are correct that it seems like a bit of overhead just to render a simple rectangle. However, as alphakappa astutely observed, there is some overhead to parse the JSON data which describes the various shapes and to render those shapes in canvas(es).
What you see is the entire canvas rendering library used by GWD. That code will be reused for additional shapes you create, including more complex shapes you can create with the Pen tool.
You bring up a great point though. In most cases, you probably don't need to draw shapes (and the overhead that comes with the runtime). If you want to rectangle elements on stage, a much better option is to use the Tag tool (the fourth tool from the top) and add HTML elements such as DIV and give them background colors and modify the border styles using the Properties panel.
We are working on our help documentation to educate our users in how to optimize their content in both size and performance.
Thanks, Google Web Designer team - aka the ones tasked with making this application. ;o)
<div id="rectangle"></div>
#rectangle { width: 200px; height: 150px; background #FF0000; }
...by default?
Great observation! We have had this discussion internally as well.
For now, we wanted to have a clear separation in the types of content the user is creating on a canvas, since canvas enables different types of content. And, in some cases, there isn't a 1-1 fallback between a canvas shape definition and an HTML element, e.g., an oval with inner radius.
However, we realize that in a lot of cases users just want elements that look like rectangles, and a DIV with certain styles will suffice. We will work to direct users towards that workflow in such cases.
Thanks, Google Web Designer team
Regards Mparaiso.
{\"type\":1,\"xoff\":0,\"yoff\":-1.4210854715202004e-14,\"strokeWidth\":1,\"strokeColor\":[0,0,0,1],\"fillColor\":[1,0,0,1],\"tlRadius\":0,\"trRadius\":0,\"blRadius\":0,\"brRadius\":0,\"width\":201,\"height\":104.00000000000003,\"strokeStyle\":\"Solid\",\"strokeMat\":null,\"fillMat\":null}
That could be better, to be sure. It's for some reason part of a JSON-encoded string inside a JS object instead of just a JS object (hence the hard-to-read escaped quotes). And the properties could use defaults to spare us "strokeMat: null" and such. But it's not horrible.
Edits: numerous and minor
Draw one rectangle. Save as rect1.
Draw a second rectangle. Save as rect2.
Show us the diff between rect1 and rect2.
It would be nice if there was some options for stripping out the Ad specific javascript. But even at ~55k this is a pretty slimmed down codebase considering what it does. Swiffy, which converts flash files to HTML/javascript has a 200k JS runtime.
A tool that designers can use to make animations in HTML5/CSS3 is desperately needed if we are ever going to move to a truly post-Flash world. We can't expect everyone to be an HTML developer, and achieving the same level of complexity and polish is extremely difficult when just working with code.
Calling it "Google Web Designer" was a terrible decision, but that's clearly not what the tool was meant for.
Google Web Designer is an advanced web application that's built with HTML5 which lets you design and build HTML5 advertisements and other web content using an integrated visual and code interface
HTML5 Twitter isn't a document. The 1 to 1 correspondence between the window object and the document object is all wrong. There should have been a 1 to 1 or 1 to many relationship between window and documents. When there is a 1 to many relationship the window object reflects only the semantics of apps and within it, there should be many documents, one for each tweet displayed by the HTML5 twitter app.
[0] http://www.drdobbs.com/architecture-and-design/interview-wit...
http://www.microsoft.com/en-us/download/details.aspx?id=3618...
This did actually make the world a better place insofar as the web got some HTML pages that would otherwise have been Word doc file downloads.
MS Word also produces much smaller HTML pages if you save your web page as "filtered HTML", sacrificing some Word functionality in the process. http://office.microsoft.com/en-us/word-help/about-using-filt...
However, to do that, you would have to know the "filtered" option was there, and why you might want to use it. Which is probably not your average office drone.
So yes, Sir. Yes, really.
HTML generators like this (or MS Word, or Dreamweaver, you name it) unfortunately are not optimized to do just the job they are used for. A good example for that is the one gave by our fellow commenter above. It adds a lot of useless code because it is simpler to do it that way. In the times where every Kb/s used to count, load a HTML page with 3 times the size it should be was a real issue.
Also, MS Word to HTML was the worst thing I have ever seen in terms of compatibility for other browsers. That to me does not sound like making the world a better place, sorry.
This is like IE4/Netscape Communicator days all over again, except now with more than two dominant browsers...
"I was a web dev in the 90s and all I got was this lousy XMLHttpRequest object"
While editing a file, Google Web Designer uses -webkit prefixes. However, when you publish your content, the publish dialog allows you to specify additional vendor prefixes (or no prefixes) in the output so the content works in different browsers.
I hope this helps.
Thanks, Nivesh (Google Web Developer)
Google Web Designer (GWD) uses the WebKit HTML rendering engine inside the application's workspace and reports the styles that are actually applied to the content during editing.
Thanks, Google Web Designer team
1. This tool can't produce cross-browser output
2. This tool includes some rendering engine-specific markup to solve cross-platform issues.
1 is unlikely and 2 is benign.
Meaning what? Google isn't directly involved with WebKit anymore and can't make them implement standards.
Microsoft and FrontPage did the exact same thing back in the days.
Do you know how much code this is for a runtime and how many browser incompatibility issues this solves.
He probably does, to begin with. That you might disagree with him about how much code is warranted here does not make his comment unconstructive.
That sounds just condescending to me.
What is the problem with a < 4kb runtime and some browser hacks?