Over at <http://www.adobeforums.com/webx?128@@.59b4e1c9> we've been discussing SiteGrinder, the PS plug-in which converts Photoshop designs to working websites.

One of the posters had concerns about the SG coding. (I don't know if he's used the plug-in.) He pointed out that on their users' sample sites at <http://www.medialab.com/sitegrinder> , if you enlarge the text with cmd-+, everything gets crowded and overlaps. I noted that this is a common problem with most/all sites, regardless of their origins. He responded:

It's common -- far too common -- but not inevitable. It's bound to happen with SG, though, because they carve up the layout into fixed size chunks and then use absolute positioning, so there's no way for the containers to accommodate changes in font size except by crashing into each other, or growing scroll bars, which is only sometimes going to work. For the same reason -- starting with a single Photoshop image -- they can't identify headings or lists, so the pages aren't properly accessible to some assistive technology. If you don't care about accessibility, you should realize that this also means that they become hard or impossible for search engines to analyze, so people aren't going to find your site so easily.

I've only just downloaded the SiteGrinder demo, so I couldn't confirm or deny this, so I sent it along to the developer at MediaLab, who replied overnight on a weekend. He says:

The criticisms are partly true. SiteGrinder uses something called "absolute" positioning as its default. This means that if the text size is increased and the text has been divided into several closely packed layers that after resizing the text may overlap.

But, while this is the default SiteGrinder positioning behavior, it is not the only option. SiteGrinder supports relative positioning through use of a -grow layer. Content in a grow layer (and the footer below it) won't suffer this problem.

Also, no website is fully resize resistant to any amount of text size increase. The normal expectation is that a site should accommodate two levels of font size changes in either direction. This can also be accomplished by simply keeping text layers away from each other so they don't crowd one another.

SiteGrinder does a lot of unseen work for supporting accessibility. It always outputs the content in read order, puts title attributes on graphic buttons, doesn't clutter the HTML with IMG tag graphics ( CSS should be used for design graphics, and that's the SG default - semantically important image layers can be noted as such with the -img hint), properly sets the alt attribute when img tags are used and never puts empty alt="" attributes into the HTML (if you are doing that you should be using CSS for the graphic, not an IMG tag). Also, text -menu layers are nicely converted to UL-LI constructs for you - very important for search engines and accessibility.

However, SiteGrinder does not yet support header tags, simply because there is no simple way to designate them from Photoshop. However, of all the changes one might want to do downstream, those are by far the easiest. It is our goal for SiteGrinder to one day support header tags in an elegant and seamless way, but I personally don't see their current absence as a big drawback. Why would someone who hand codes HTML be upset if a helper tool didn't put in header tags for them? Hope this helps, Chris

P.S. SiteGrinder has advanced features for importing HTML, inserting HTML directly into a Photoshop layer, as well as adjusting the HEAD portion of a page. Our more savvy users have no trouble getting header tags into their SiteGrinder builds. And others just put them in downstream.

This is mostly Greek to me (and fortunately SG users don't need to understand most of it, as it happens behind the plug-in scenes) but I'd be interested to hear what other html-savvy folks think.

Nigel_Chapman

Replied in the following topics

SiteGrinder (PS plug-in) web design question answered