The original goal of writing clean HTML was for static, document-centric websites where you could do things like run a filesystem search or a web spider to create an index of all your documents, use an HTML editor, or perhaps do a search and replace. And of course it helps with SEO. But how relevant is it to a web application where "view source" won't show you much and you'll only see the DOM in the debugger?
On Wednesday, October 10, 2012 2:22:32 PM UTC-7, Roger wrote: > > There is no such thing as "producing clean vs not clean" html unless you > rely on other peoples widgets. > > 100% of my widgets are a UIBTemplate.. of my creation… I use GWTQuery (or > jquery) to add/remove elements from my widgets. Thus, the HTML is exactly > as clean as any HTML that any non-gwt application would use/produce. > > Roger > > On Oct 10, 2012, at 4:57 PM, Thomas Broyer <[email protected]<javascript:>> > wrote: > > > > On Wednesday, October 10, 2012 10:13:36 PM UTC+2, Shaun Tarves wrote: >> >> There is no doubt that what GWT does, it's really good at. However, some >> things that I've found GWT really isn't good at: >> >> 1) Producing clean HTML >> >> The structure of GWT "page views," especially with GWT widgets, is really >> poor. The DOM gets bloated with lots of extra elements that are used for >> focus and positioning. There are ways around this, but I feel like I'm >> constantly fighting with GWT to generate HTML structure on my terms. >> >> For example, some of the most lauded constructs in GWT are the Cell-based >> widgets (CellTable, and CellList, specifically). With CellLists, you are >> stuck with divs. There's no way around it. So that means if you want to >> make a good data model-backed list and render it as a UL with LIs, you're >> SOL. >> > > It's a false problem. GWT widgets are generally good as far as > accessibility is concerned, and let's put it clearly the only reason on > having a "semantic" DOM tree is for a11y. > > 2) The history mechanism is really powerful, but it's important to get >> your URL structure correct from the start. The built-in history token >> parser is a little too rigid in that it forces the first part of your URLs >> to be of the form xxxx:yyy and then anything you want after that. When you >> dive deeper into GWT, you'll understand the limitations of the >> PlaceHistoryMapper and why you might want to avoid the tokenizers and write >> your own parser. > > > On the plus side: it's pluggable. (it wasn't at first, you had to > re-implement the whole PlaceHistoryHander+PlaceHistoryMapper) > > >> 3) The GWT CSS compiler doesn't understand any CSS3 attributes. Also, >> browser-specific attributes (such as the * hack for IE) throw warnings on >> compiling. It's not really GWT's fault (it's a Java compiler issue), but be >> aware nonetheless. > > > You don't need browser-specific hacks, simply use "@if user.agent ie6 > ie8". The real issue is with selectors. FYI, gradients can now be used > without literal() in 2.5.0-rc2: > http://code.google.com/p/google-web-toolkit/issues/detail?id=5771 > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-web-toolkit/-/A-GepWmKMf0J. > To post to this group, send email to > [email protected]<javascript:> > . > To unsubscribe from this group, send email to > [email protected] <javascript:>. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/WgLQsqv2dBoJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
