In
https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31,
after
label {
font-weight: normal;
color:#666;
font-size:13px;
}
you would add
label::first-letter {
text-transform: capitalize;
}
(see https://css-tricks.com/almanac/selectors/f/first-letter/)
text-transform: capitalize on the label itself would capitalize all words,
which is not wanted. The ::first-letter pseudo-selector is supported on all
browsers, for IE 8 and lower you need a sigle colon instead of a double
colon.
On Thursday, November 19, 2015 at 11:23:48 PM UTC+1, Tim Graham wrote:
>
> I'd like to see the admin's CSS updated under the assumption that this
> change moves forward to better understand the extent of changes that would
> be required from Django users to maintain the current behavior.
>
> On Thursday, November 19, 2015 at 4:52:57 PM UTC-5, Sergei Maertens wrote:
>>
>> Yes, I've thought about a setting as well briefly but quickly discarded
>> it because it would be 'yet another setting'. But this one would ofcourse
>> be temporarily, and if that's been applied successfully in the past, then
>> that's probably the best way to tackle this.
>>
>> I'd be happy to write the patch for this myself if no objections turn up.
>>
>> On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote:
>>>
>>> The best solution I can think of at the moment would be a setting
>>> allowing users to opt-in to the new behavior which would then silence the
>>> warning. That leaves you with a defunct setting once the deprecation period
>>> completes. That's basically how SessionAuthenticationMiddleware worked
>>> when we decided to require it.
>>>
>>> On Thursday, November 19, 2015 at 4:13:40 PM UTC-5, Sergei Maertens
>>> wrote:
>>>>
>>>> Good catch.
>>>>
>>>> I'm not sure, haven't there been similar cases in the past? First thing
>>>> I can think of is using naive datetimes when timezone-support is enabled,
>>>> and then you get a warning for each naive datetime you use, but that's of
>>>> course different then a DeprecationWarning.
>>>>
>>>> It's probably not best practice, but maybe it could be tracked with a
>>>> module-level flag/constant, to check if the warning has been emited or
>>>> not,
>>>> ensuring that it gets only emited once during the lifetime of a thread?
>>>>
>>>> On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:
>>>>>
>>>>> How would a developer acknowledge/silence that deprecation warning? It
>>>>> seems to me that if it's emitted for every form field in a project that's
>>>>> not really going to be helpful.
>>>>>
>>>>> On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens
>>>>> wrote:
>>>>>>
>>>>>> I think I would start with locally creating a wrapper capfirst that
>>>>>> is only called in the referenced line and
>>>>>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>>>>>>
>>>>>> (missed that one in the previous post) and possible other ocurrences.
>>>>>> Emit
>>>>>> a PendingDeprecationWarning, something along the lines of
>>>>>>
>>>>>> def deprecated_capfirst(value):
>>>>>> warnings.warn(
>>>>>> "form field labels generated from model field 'verbose_name'
>>>>>> will no longer automatically be capitalized",
>>>>>> PendingDeprecationWarning, stacklevel=2
>>>>>> )
>>>>>> return capfirst(value)
>>>>>>
>>>>>> and replace the capfirst with deprecated_capfirst ofcourse. At the
>>>>>> same time, in the admin the CSS for labels can be added to
>>>>>> text-transform
>>>>>> them to capitalize.
>>>>>>
>>>>>> In the next Django version this becomes loud, and in the next+1
>>>>>> version it is effectively removed.
>>>>>>
>>>>>> As soon as the PendingDeprecation is added, the entry should be added
>>>>>> to the docs with example CSS to make your own templates/styling
>>>>>> capitalize
>>>>>> the labels - and/or mention the `capfirst` template filter.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>> On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>>>>>>>
>>>>>>> How do you envision putting this through a deprecation cycle?
>>>>>>>
>>>>>>> On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei
>>>>>>> Maertens wrote:
>>>>>>>>
>>>>>>>> This is a proposal to change how Django generates form field labels
>>>>>>>> from model fields. Currently, `capfirst` is called on
>>>>>>>> `field.verbose_name`
>>>>>>>> (see
>>>>>>>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872
>>>>>>>>
>>>>>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2Fmaster%2Fdjango%2Fdb%2Fmodels%2Ffields%2F__init__.py%23L872&sa=D&sntz=1&usg=AFQjCNGUcFeQthwsqiwrA57fw50I20lHtw>).
>>>>>>>>
>>>>>>>> This behaviour has been around since pretty much forever and makes
>>>>>>>> sense.
>>>>>>>>
>>>>>>>> However, this affects what you put down in your translations - if a
>>>>>>>> lowercased verbose name is what you want (and you translate it as
>>>>>>>> such),
>>>>>>>> Django will make your form labels uppercase and there's no clean way
>>>>>>>> around
>>>>>>>> that.
>>>>>>>>
>>>>>>>> There is a very specific use case for this proposal. The
>>>>>>>> house-style of a design states that all form labels should be
>>>>>>>> lowercase -
>>>>>>>> but names of the brand should be capitalized. Example: 'you agree to
>>>>>>>> the
>>>>>>>> Brand terms'. This is not easily feasible: css text-transform will
>>>>>>>> also
>>>>>>>> lowercase the brand name, and Django uppercases the first letter.
>>>>>>>> Another
>>>>>>>> possible use case could be if you insist on putting the labels to the
>>>>>>>> right
>>>>>>>> of the form input, but I will agree that looks silly.
>>>>>>>>
>>>>>>>> So the proposal is to get rid of the capfirst call, and in the
>>>>>>>> admin this could be mitigated for backwards compatibility by modifying
>>>>>>>> the
>>>>>>>> css to include:
>>>>>>>> label {
>>>>>>>> text-transform: capitalize;
>>>>>>>> }
>>>>>>>>
>>>>>>>> This is ofcourse a fairly big backwards-incompatible change towards
>>>>>>>> front-end/non-vendor code, as people now have to explicitly make sure
>>>>>>>> that
>>>>>>>> labels are capitalized in their own templates. So this should probably
>>>>>>>> go
>>>>>>>> through the usual deprecation mechanics (silent, warning, remove), if
>>>>>>>> it
>>>>>>>> happens at all.
>>>>>>>>
>>>>>>>> What are current workarounds for this problem?
>>>>>>>>
>>>>>>>> - explicitly specifying the label value in the ModelForm
>>>>>>>> definition: this violates the DRY principle, you already defined
>>>>>>>> the
>>>>>>>> verbose_name on the model field
>>>>>>>> - creating a form mixin that will lowercase the first letter of
>>>>>>>> the label for all fields
>>>>>>>> - you still have to check if the first word if it's the
>>>>>>>> Brand string, because then it should stay capitalized
>>>>>>>> - you now have to include this mixin in every single form,
>>>>>>>> and can no longer rely on implicitly generated form classes in
>>>>>>>> generic CBV
>>>>>>>> - create a templatefilter that decapitalizes the label, and
>>>>>>>> re-capitalizes 'brand' occurrences to 'Brand' (currently
>>>>>>>> implemented)
>>>>>>>> - you now have to not forget this filter everywhere you
>>>>>>>> render forms
>>>>>>>> - performance hit if this is based on regular expressions
>>>>>>>> (which in this case it is because subbrand should not become
>>>>>>>> subBrand)
>>>>>>>>
>>>>>>>> All in all, I'm of the opinion that the flexibility you gain by NOT
>>>>>>>> manipulating the label in Django outweighs the backwards incompatible
>>>>>>>> change. I'm also strongly of the opinion that capitalizing labels is
>>>>>>>> something that should be done entirely in CSS - whether the label is
>>>>>>>> capitalized, lower case or upper case shouldn't matter for Django's
>>>>>>>> internals.
>>>>>>>>
>>>>>>>> Reasons to not do this:
>>>>>>>>
>>>>>>>> - cater to common convention, not clients (quoted from
>>>>>>>> #django-dev on irc): in my opinion this works 95% of the time, but
>>>>>>>> your
>>>>>>>> forced into violating some of Django's principles if you divert
>>>>>>>> from this,
>>>>>>>> most notably DRY
>>>>>>>> - maintain backwards compatibility
>>>>>>>>
>>>>>>>> Reasons to do this:
>>>>>>>>
>>>>>>>> - gain flexibility about the display of form labels
>>>>>>>> - keep the codebase sane
>>>>>>>>
>>>>>>>>
>>>>>>>> Bonus: vaguely related ticket:
>>>>>>>> https://code.djangoproject.com/ticket/5518
>>>>>>>>
>>>>>>>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/4c6772ae-92c6-48d0-ac0f-23bdb2d5b483%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
