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
