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

yched’s picture

Subscribe

Jeff Burnz’s picture

I should clarify my OP, its about as clear as mud.

1. Leave it as div for styling only.
Don't assume what the content is, just leave the template as it is now - let themers override with suggestions if they want to add semantics.
2. Use template suggestions (both core and contrib might end up doing this).
Use suggestions in core - for example for taxonomy fields (output as a list), image fields might use figure.
3. Make it "content aware" and let the most appropriate element win.
Have some logic that knows what its content is, if its a taxonomy field - output as list, if its images, use figure etc.
4. Leave it as div by default - allow users to set the wrapper in the UI.
Similar to 1, however should we end up having some way to set wrapper elements in the UI it should support this concept - since field is really nice place to be injecting semantics (such as section).

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.

jessebeach’s picture

subscribe

pixelmord’s picture

I would say:

  1. Leave the div where there is no other good choice, without knowing the context of the field
  2. Have configurable formatters in the field UI for site builders to choose the wrapping tags
  3. Provide sensible defaults for the applied default formatter according to the type of field (e.g. have a figure tag for images by default, that can be changed to a div, if something more generic is wanted by the site builder)

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.

pixelmord’s picture

Ah now i saw that there is already a discussion regarding dynamic wrappers/templates going on at
http://groups.drupal.org/node/159734

Jacine’s picture

I 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).

yched’s picture

@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.

Jacine’s picture

Hey 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.

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.

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?

  1. Create a field--tags.tpl.php, which is a very generic implementation for a very specific field.
  2. Decide to be more general and target field--taxonomy-term-reference.tpl.php, but then end up having to override other fields where that list is not desired, and the code that sits in there is literally applicable to a slew of other fields. :/
  3. End up creating a field--list.tpl.php and manually switch the template in preprocess functions. This gets unruly in template.php, and is harder for non-Drupal maniacs to grasp.

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. :)

aspilicious’s picture

Well 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?

mgifford’s picture

Issue summary: View changes
Status: Active » Closed (cannot reproduce)

Looks like we can close this as theme_field() doesn't exist any more:
https://api.drupal.org/api/drupal/8/search/theme_field

star-szr’s picture

Status: Closed (cannot reproduce) » Active
Issue tags: +frontend
Related issues: +#2214249: Fields classes - what do we actually need & want in Drupal8 twig

Sure, 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 :)

mgifford’s picture

Thanks for reopening it @Cottser I forgot about field.html.twig...

joelpittet’s picture

Title: Convert theme_field() to HTML5 » Convert field.html.twig to HTML5
Category: Task » Plan
joelpittet’s picture

Version: 8.0.x-dev » 8.1.x-dev
Jeff Burnz’s picture

I 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.

joelpittet’s picture

Status: Active » Closed (fixed)

Let'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.