Marijn, I understand that "echo $form" is not supported as a way of creating deployment-ready, properly styled Symfony sites. Fabien has made that pretty clear - your design team is supposed to template out forms if they want them to look good. I think there's a reasonable middle ground somewhere but that's a completely separate discussion.
Here I am talking about "echo $form['date']->render()". That is a supported practice for well-styled Symfony sites, in fact it is the lowest level the designer is supposed to be able to access according to the relevant chapters of the Symfony books. This *is* "templating out the form all the way." So it ought to be possible to get good results with it from the standard widgets. The markup *inside* the widget is not accessible to them (the front end designers), they cannot fix it. And even if they could (perhaps by assuming that the id format and name format will never change and writing their own form elements, outputting all of their own attributes etc.), it would be a considerable waste of time. Every time and date widget in a given site will almost certainly have the same markup. We are currently overriding every single date and time widget via configure() in every single Symfony 1.4 site. This takes a lot of time and energy and it is worth questioning whether it is really true that nothing can be done about it until we all rewrite everything for Symfony 2.0. Unfortunately it's true that someone might be targeting span as a (very lazy) alternative to a class name for something inside a form row. As you point out they might feel safe doing so when they target spans within a particular form. Don't forget, my original suggestion to have Base classes for the widget was quite backwards compatible. I am hard pressed to imagine why any Symfony code could care that a widget class now had an additional parent in its tree of ancestor classes. I'm simply responding to Jon and Fabien's suggestions that Base classes for widgets are not an option, but that changing the markup might be acceptable. We have lots of existing projects to support here too and BC is a concern for us as well. Please don't assume the worst. Perhaps the best we can do is provide cleverness in BaseForm::configure() that explicitly looks for the standard widgets and replaces them with new widgets that receive the same options. It's wasteful, but at least it's reusable. On Wed, Sep 1, 2010 at 8:03 PM, Marijn Huizendveld <[email protected]> wrote: > Dear Tom, > As much as I agree with you that the current HTML is broken, this will > create backwards incompatible changes. > As much as I admire your effort to find the least obtrusive mark-up (on > which choice I agree) I simply cannot come up with a reasonable explanation > as to why we would want to create a possible backwards incompatible change > like this... > Although styling "naked" span elements is stupid I'm sure someone has a CSS > rule like the following: > form#my_admin_form #my_fieldset .sf_admin_form_row span > { > /*do something special here*/ > } > This is not generic styling but this will be effected by your changes in the > time widget. > It seems to me that the one and only reason you would like to get this > change include is that you can simply keep on calling <?php echo $form; ?> > in your template. > As much as that utopia is desirable (and sometimes reasonable) it should > never be considered the only viable option for creating forms. > I'm sorry if I seem like a jerk but to me it seems you are trying to push a > change through (again I agree for the need) that will fix a problem for you > that has other solutions for it (override those default widgets in your own > custom library, writing a more verbose template, creating a better time > widget for the sfFormExtraPlugin). > Again sorry for acting like a jerk who is putting his foot down, but could > you explain my why you don't choose any of the less intrusive alternatives > for other framework users? > Kindest regards, > Marijn > On Sep 1, 2010, at 11:45 PM, Tom Boutell wrote: > > I would love to see that change made. Thank you for considering it. > > I just had a chat with John Benson, one of our lead front end guys. He > wants this very much, but has his own backwards compatibility > concerns. Changes to markup affect designers the way changes to PHP > affect developers. > > Fortunately we have agreed on a safe way to do it. > > Right now we have this: > > <select>...</select> > / > <select>...</select> > / > <select>...</select> > > Two big problems: > > 1. There is no wrapper around the whole thing, thus no clean way to > target the whole thing with CSS or JavaScript. I've seen imaginative > and admirable hacks, but they are not clean and tend to target other > stuff in unexpected ways. This kills attempts at full progressive > enhancement. > > 2. The slashes (for dates) and colons (for times) have no wrapper, so > they cannot be targeted. This kills attempts to style or alter the > widgets for non-JS environments or otherwise improve them in ways less > dramatic than full replacement by JS. > > Please help us out by giving the whole thing a class, and by giving > the separators a class. Make sure those classes are namespaced to > Symfony: > > // For date > > <span class="sf-date"> > <select>...</select><span class="sf-separator">/</span> > <select>...</select><span class="sf-separator">/</span> > <select>...</select> > </span> > > // For time > > <span class="sf-time"> > <select>...</select><span class="sf-separator">:</span> > <select>...</select><span class="sf-separator">:</span> > <select>...</select> > </span> > > (There is whitespace here for legibility but of course there should be > no whitespace between the elements.) > > Now we can target .sf-date and .sf-time, and also target .sf-date > .sf-separator and .sf-time .sf-separator. > > The use of 'span' here is important. Any other element would be highly > likely to have non-BC impacts on reasonably well written CSS (or even > unstyled HTML). You can't suddenly make a div out of something and > have folks discovering that there's a line break between the date > widget and the time widget that they did not intend and did not have > before updating Symfony. > > 'span' is safe because it is well understood to be an element whose > only purpose is to allow ids and classes to be associated with a run > of inline content (which HTML5 has renamed "phrasing" content), > otherwise leaving it alone. Aggressively styling all naked span > elements in the entire document is widely understood to be a bad > choice. (: So we shouldn't have to worry that the mere presence of a > span will change the appearance of pages. > > Also, the select element is inline/phrasing content in both HTML 4 and > HTML 5, so it's appropriate to enclose in a span. > > With these changes it becomes possible to replace these composite > widgets cleanly through progressive enhancement or style them > reasonably well as they are. It would be better to be able to override > some of their defaults for an entire project, notably the interval > between choices on the minutes selector and the choice of separator, > but if we can't have that, this is still a huge improvement. > > One more concern: some people want to make sites whose connection to > Symfony (or any particular development tool) is invisible. If that is > an issue then the sf- prefix for the class names could be made > configurable via settings.yml. The vast majority would leave it set to > sf-, I imagine. > > Thanks again for looking at the possibility of improving the markup > for the composite date and time widgets. If there are any other > composite widgets in Symfony I'm not thinking of, it would be a good > idea to apply the same review to them to make sure they can be > effectively styled. > > On Wed, Sep 1, 2010 at 4:13 PM, Fabien Potencier > <[email protected]> wrote: > > On 8/27/10 6:30 PM, Tom Boutell wrote: > > Marijn, the basic time and date widgets are a miserable user > > experience and their lack of reasonable structure (there's no > > containing element to attach your progressive enhancements to) makes > > it extremely difficult to enhance them across your entire project > > unless you manually override every single widget, which defeats the > > purpose of Doctrine forms. > > Why not just fix this problem instead of inventing something new? I would > > happily change the default HTML if it makes sense and if it is BC. > > Fabien > > -- > > If you want to report a vulnerability issue on symfony, please send it to > > security at symfony-project.com > > You received this message because you are subscribed to the Google > > Groups "symfony developers" group. > > 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/symfony-devs?hl=en > > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > 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/symfony-devs?hl=en > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > 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/symfony-devs?hl=en > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. 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/symfony-devs?hl=en
