Hi,

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)

I understand you guys want to serialize data efficiently. But perhaps you can pretty print the rectangle information? It would make designs a lot nicer when version controlled (esp so if you sort the content consistently). Also, it would make manually meddling easier.

I'm curious, why not...

<div id="rectangle"></div>

#rectangle { width: 200px; height: 150px; background #FF0000; }

...by default?

Hi,

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

Because you used the "shape" tool and not the "tag" tool.

Can you make the lib used to render the animation and the drawings opensource so developpers can understand it more easily and "hack" it when the designer goes overboard? thanks.

Regards Mparaiso.

The amount of code it generates for a page containing just a rectangle is not a good way to judge the tool. They may have some finite overhead because of the expectation that most users will be using the tool to create more complex pages. If the tool is good for the average ad-page that's created, while maintaining cross-browser compatibility, and bad for extremely simple pages, then who is to judge?

I agree. The big(gish) script they injected is just fixed overhead, as is the CSS for positioning the canvas. It's just stuff we're used to having in separate files. The actual non-boilerplate part is this:

{\"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

Please edit; stretches the page on 1366 width.

arg, too late for me to do it

It would help to see the following.

Draw one rectangle. Save as rect1.

Draw a second rectangle. Save as rect2.

Show us the diff between rect1 and rect2.

Despite the poorly chosen name, this is a WYSIWYG tool for animation, not a site design tool. If all you care about is markup, use a text editor and make your animations by hand. Compared with Adobe Edge Animate (which is very similar), the markup is actually very clean (aside from the big script block, which is for ad functionality and also animation / drawing routines). You can see the animations defined as real keyframes in CSS, not overly reliant on javascript, which is good. It means there is a chance of taking those and using them independently of the JS runtime code, and also that execution will take advantage of native browser animation functions, rather than being bottlenecked by JS code.

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.

From File > New if you select a blank HTML file, you get an empty HTML file with no Ad specific JavaScript.

Thanks, I thought I tried that. That does reduce the extra code quite a bit.

All I see are data for the location and size of the rectangle and some extra code added by default to allow their scripts to work.

I thought it's a tool for designing websites - nope.

It isn't -- it's a tool for designing ads.

Calling it "Google Web Designer" was a terrible decision, but that's clearly not what the tool was meant for.

Ad development is the last listed feature, if that is the main purpose of the app then their website is very misleading.

I agree it's very misleading but they do clarify it in the first sentence of the help page.

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

Uh-oh. So, while Frontpage just broke useragent stylesheets (all those sites setting the text-color, and assuming background was white, like it was in IE) -- this'll break what's left of the semantic web? I wonder how well google handles crawling these things...

The semantic web in the way that this tool breaks it has been dead since we had table-based layouts and div-hell further buried that notion. However, that doesn't mean that the semantic web is dead. I somewhat agree with Alan Kay when he said the web was built by amateurs [0]. The problem with the original design is that only documents were considered, when there are actually two citizens: documents and the apps used to display those documents for different contexts and usages. The original design only considered documents in one static use case, a desktop browser. There are two levels of semantics: document semantics, which the web got right and that xhtml 2.0 might have made even richer, and app semantics that were completely ignored by the semantic web crowd to the point where the app people hijacked the plans of those pushing semantic documents.

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...

Google has long been able to crawl pure javascript pages - I actually think their their crawler is just headless Chrome.

It's meant as an ad development tool, not a page development tool. Entirely different audience.

...which is why they should call it Google Ad Designer.

I don't disagree with you at all there. The name is terrible.

Google Web Designer 2013 = Microsoft Frontpage 2000?

I think its more like Microsoft Expression Design. It even looks similar.

http://www.microsoft.com/en-us/download/details.aspx?id=3618...

That's exactly what popped to mind immediately. Maybe it was that hairball of code combined with the "generator" meta tag.

Dreamweaver comes to mind.

This reminds me of the MS Word generating HTML

Not really. MS Word was designed to generate HTML that would look like your original MS Word document and be round-tripped. This is not particularly easy. However, it made sense if you wanted to use your word processor to create and edit web documents (rather than find and learn another program), or publish existing documents as web pages. Which some businesses did.

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.

I lost count of how many times I had to open a Word generated HTML document (by a regular Word user that though copying from Word and posting it in the CMS was a good idea) and clean it up by hand so it wouldn't break the page for browsers other than IE (even in IE it would break sometimes... surprise, surprise).

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.

Smells like FrontPage spirit.

My favorite part is the WebKit specific code... Don't be Evil and something about standards right?

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"

Hi,

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)

Can you explain the reasons behind this behavior?

Hi,

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

Are you saying:

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.

Thought so too, but when you publish they let you add FireFox / IE CSS prefixes (on by default)

> My favorite part is the WebKit specific code... Don't be Evil and something about standards right?

Meaning what? Google isn't directly involved with WebKit anymore and can't make them implement standards.

Google and Apple are the reason we are back to this mess again. They need to fix the problem not facilitate it with tools like this.

Microsoft and FrontPage did the exact same thing back in the days.

Hah! I did exactly the same, went to code view and closed the application. x-D

Github login wall.

Who cares about what you think? Give some constructive criticism or shut up.

Do you know how much code this is for a runtime and how many browser incompatibility issues this solves.

> Who cares about what you think?

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.

> I feel sorry for whoever was tasked with making this application.

That sounds just condescending to me.

What is the problem with a < 4kb runtime and some browser hacks?

I totally agree with you that there's nothing wrong with it. But which is correct is exactly what's up for discussion.

Pretty sure that he was being constructive. Did you look at the code?

I care, else I wouldn't be reading these comments.