- Drupal abuses
LEGENDHTML elements to achieve "grouped, collapsible form elements".
- Fieldsets/legends are very hard to style, since all web browsers are handling them differently.
- Fieldsets/legends were never intended be used for the task that Drupal is using them for.
- Introduce the new HTML5
SUMMARYelements as replacement for current fieldsets/legends.
- Leverage native user agent handling for details instead of collapse.js when supported.
- The rendering of fieldsets and legends vastly differs across major browsers. Previous major tasks like required an awful lot of time to invent nasty workarounds to achieve a consistent x-browser styling of fieldsets/legends.
- The use-case of fieldsets in Drupal is to bundle/group multiple form elements into a collapsible container. The contained controls are always advanced controls, which allow the user to customize more detailed settings.
- To resolve the rendering/styling issues, we originally considered to get rid of the fieldset/legend combo and just simply use
- But luckily, the HTML5 spec supplies a native answer for this use-case: The
- HTML5 Details management summary: HTML5: How to Use <DETAILS> and <SUMMARY> Tags
'#type' => 'details'.
- Use details everywhere we're (ab)using fieldsets currently. (including vertical tabs)
- Retain fieldsets for... regular HTML fieldsets.
Native user agent implementations of Details do not support "uncollapsible" (always-open) details; i.e., all details elements are always collapsible. While this sounds like a regression, it is not. The fact that details are always collapsible and thus always details is very beneficial, because it enforces that the user interface pattern is only used where appropriate.
Latest Chrome is the only browser that natively supports Details as of now. To test the native implementation, just apply this patch and browse the site in Chrome. The
— will completely remove
core/misc/collapse.jsand replace it with a proper HTML5 polyfill.
The current patch here introduces a minor regression for IE8, but it does not make sense to fix and battle-test collapse.js any further, since we will delete it anyway.
— Determine whether/how to address the '#group' Form API property in light of the more specific semantics and functionality of
A few configuration settings forms are literally abusing collapsible fieldsets, which contain a single form element only, and even the entire form may consist of a single fieldset only. Those forms ought to be fixed and simplified either way, the switch to details merely forces us to clean up those forms, and to do it right.
Only a few settings pages are affected, and those need to be fixed in separate follow-up issues, since each of them requires its own, dedicated discussion on how exactly we can simplify the interface.
This patch introduces a new testing module,
design_test.module. Coincidentally, I originally authored that module to test a major refactoring and clean-up of fieldsets for Drupal 7. ;) Since then, @Jacine and I advanced on it for various other D7 core patches, and eventually turned it into the contributed Design module.
The purpose of the design_test module is to allow focused, dedicated testing of theme/markup/design components in an isolated but also "cumulated" environment; i.e., testing all possible incarnations of a certain thing on a single page, without having to hop through the entire system, and also without having to manually switch themes back and forth like hell. The module provides a very simplistic infrastructure for authoring and "executing" (using) the design test cases (which are totally manual tests, of course; but that's just how design works).
The test cases/pages in the module will have to use unorthodox ways to achieve all possible incarnations of markup at times, and we shouldn't be scared by that. The module and its test cases should be exempt from code quality rules and guidelines. It should be treated as kind of a "sandbox" for core contributors who are working on frontend/theme components, and it must be crystal clear that its primary and only purpose is to facilitate manual cross-browser and cross-core-theme testing of markup/theme changes. At some point in the future, we can and may want to consider to turn this into an actual, user-facing module that has a concrete and helpful purpose, but that's absolutely not the idea and purpose right now, which is why it is added as a hidden test module only.
Also, only recently I added the precursor for design_test module to facilitate manual testing of the new dropbuttons to the theme_test module. This code is moved into a design test case as part of this patch.
The comment onas well as bugs like make pretty clear that using fieldsets to form a visual containment, which may be visually overridden collapsible, or even more overridden to be no more collapsible but tab-switchable instead, is quite an abuse and extreme stretch of the original meaning of HTML fieldsets.
Monster issues like
In fact, we're abusing fieldsets to be something they were never designed for:
- For many years already, people are trying hard (and often fail) to render non-form material in a collapsible fieldset.
- Since D7, many people would like to render arbitrary stuff in vertical tabs - but you figured it:
What we actually want is a renderable element #type
'section' that mostly behaves like #type
- It has a
- It has renderable
- It is rendered as a container, similar to #type
'container', to group multiple other elements, whereas its structured markup follows that of #type
- It is shrinked to an expandable title if it is
- It is rendered without/specially positioned title if it is a
Introducing a proper and unique new element type allows us to finally forget about browser quirks on fieldsets, and extend our presentation layer for new concepts that involve multiple sections that each contain a set of grouped other elements.
|PASSED: [[SimpleTest]]: [MySQL] 48,840 pass(es).|
|PASSED: [[SimpleTest]]: [MySQL] 48,780 pass(es).|
|PASSED: [[SimpleTest]]: [MySQL] 48,720 pass(es).|