Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This potentially the most interesting function for conversion, some ideas for discussion:
1. Leave it as div for styling only.
2. Use template suggestions (both core and contrib might end up doing this).
3. Make it "content aware" and let the most appropriate element win.
4. Leave it as div by default - allow users to set the wrapper in the UI.
http://api.drupal.org/api/drupal/modules--field--field.module/function/t...
Comments
Comment #1
yched CreditAttribution: yched commentedSubscribe
Comment #2
Jeff Burnz CreditAttribution: Jeff Burnz commentedI should clarify my OP, its about as clear as mud.
There is probably a pretty good argument for fields almost always being sections, but not always, so there's a bikeshed in itself.
These are just brainstormed ideas to generate some discussion, I'm not sure what where this should go as yet.
Comment #3
jessebeach CreditAttribution: jessebeach commentedsubscribe
Comment #4
pixelmord CreditAttribution: pixelmord commentedI would say:
I like what views is doing with the configuration for the fields style regarding the choice between different tags and classes.
The contrib fieldgroup module has configurable formatters also, for me it feels natural to have these options there.
This would also be good in terms of flexibility apart from HTML5, because it makes semantic markup available to everybody.
Currently I don't see a point in having template suggestions targeting for specific markup. With the suggestions that are already available you have a lot of granularity in targeting fields. So we are not lacking possibility for applying special markup. But right now there is only one variant of default markup, even the "labels" have only variants determined by classes.
So here a more flexible method of generating the the HTML tags around the data would be nice to have in both theme function and template (may be like views does it). The tags to be output could then be determined by the above mentioned configuration options or by preprocess functions.
Comment #5
pixelmord CreditAttribution: pixelmord commentedAh now i saw that there is already a discussion regarding dynamic wrappers/templates going on at
http://groups.drupal.org/node/159734
Comment #6
JacineI think it would be nice to have some additional field formatters, and that we could do a decent job providing defaults based on the information we know by utilizing theme hook suggestions. So, I would love to see some proposals here for what the markup should look like given the types of fields and formatters we already have as well as things that are missing (i.e. a formatter that outputs an HTML list).
Comment #7
yched CreditAttribution: yched commented@Jacine : that wouldn't be formatters per se, but rather options for the wrapping HTML - i.e variants of field.tpl.php.
Formatters generate the output for one single value, field.tpl wraps the some HTML (divs currently) around each of the multiple values.
Formatters are specific to a given field type(s), while ideally those "wrappers" should stay independent of the formatter and the field type. You can use a 'comma separated' wrapper or an 'ordered list' wrapper around any formatter and whatever the field type.
A different approach is the one provided by Display Suite, which lets you specify in the UI the HTML tags to be used in the field.tpl (aka "semantic fields", similar to the "semantic views" feature that got integrated in Views 3). Similar, but you pick 3-4 tags instead of a template. You guys could probably provide the most relevant feedback on which approach is best.
The roadblocks are not that much on the code side (relatively easy), but rather :
- UI : that's another bunch of options to add to the "Manage display" screens. Within the D7 cycle we restricted ourselves to finding and agreeing on a UI shape for "formatter settings" - which proved difficult enough. But the resulting UI is not really ready to receive this kind of extra params settings. See #1234624: Limit the number of fields to display for a similar "non-formatter parameter".
- "philosophically" : having the UI control something that is typically a theme-level mechanism (using a given template or a given set of tags), means that you basically rob the theme layer of its expected functionnality, introducing possible WTFs like "why don't my UI changes have a visible effect ? oh, because the theme has a dedicated field--field_foo.tpl.php that overlooks the settings from the UI"
A generic field template that takes the actual HTML tags to use from UI settings is also much less readable and unfriendly to override.
Comment #8
JacineHey thanks @yched! I should probably be a little clearer about what I mean, because I am definitely NOT looking for field.tpl.php level wrappers in the UI. :) I'm actually very much against that for the exact reasons you mention. I completely agree with most of what you wrote. I don't think the UI/WTF's that it would cause would actually be worth all the trouble that would go into it.
I agree with this, but in practice it's actually pretty hard. The theme implementation of those wrappers is what gets quite messy. For example, field_tags should absolutely be output in a UL by default, so how do we get there?
None of those are exactly ideal, and I'd also note that for all of the above I'm talking about modifying the field "items" not the field "wrapper." I'd like to see a cleaner way of doing this, and think that formatters could be a decent option, but maybe not. Just throwing the option out there... Another option is to have a field-multiple.tpl.php, but that would probably require 2 levels of templates to get the job done (contents + wrapper) in a way that would allow reuse. This is also not exactly a thrilling prospect. The point of the above examples is that a list of field items output in a UL is something that could work globally and isn't really tied specific to a field type. I don't know if this can be improved, but I'd like to hope that it can be.
Right now, I'm mostly looking to find out what markup people want to see, given the field types that we already have. I want to see people thinking about this and showing examples.
Hopefully that makes sense. :)
Comment #9
aspilicious CreditAttribution: aspilicious commentedWell i'm working on HTML5 for display suite and there I stumbled into this.
Display suite provides custom field templates containing "HTML5 wrapper" options behind the "cogwheel" in the field UI. This DOES create extra bloat in the field formatter settings that I don't want to see in drupal core.
So, why just don't leave these advanced settings for contrib?
Comment #10
mgiffordLooks like we can close this as theme_field() doesn't exist any more:
https://api.drupal.org/api/drupal/8/search/theme_field
Comment #11
star-szrSure, but field.html.twig still exists and this issue is all about markup. I think if we close it should be for another reason. Thanks for bumping this @mgifford :)
Comment #12
mgiffordThanks for reopening it @Cottser I forgot about field.html.twig...
Comment #13
joelpittetComment #14
joelpittetComment #15
Jeff Burnz CreditAttribution: Jeff Burnz commentedI would say if we can't come up with a valid reason to add html5 to field.html.twig then we should close this won't fix.
We already use section in field--comment and plausibly we could use figure in field--image, however those are specific template suggestions, this issue I think, at least for D8, is a won't fix.
Comment #16
joelpittetLet's do that, if someone has a plan for this, they can create a new issue unless the above discussion helps their case and plan.