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
