I would like to have a <ul> inside the help_text of a django form field.
Unfortunately django renders the help_text inside a <span>.
According to the HTML spec a <span> must not contain a <ul>. At least that is what my validation tool says.
Here is the source of django: https://github.com/django/django/blob/master/django/forms/forms.py#L283
def as_table(self):
"Return this form rendered as HTML <tr>s -- excluding the <table></table>."
return self._html_output(
normal_row='<tr%(html_class_attr)s><th>%(label)s</th><td>%(errors)s%(field)s%(help_text)s</td></tr>',
error_row='<tr><td colspan="2">%s</td></tr>',
row_ender='</td></tr>',
help_text_html='<br><span class="helptext">%s</span>',
errors_on_separate_row=False)
What can I do to get <ul> in the help_text and valid html.
Overriding as_table() does not work, since the form is from "core_app" and the field is from a plugin. Both are two different git repos and I don't want to modify the core just because of this.
As you already mentioned, in HTML there is a concept of block and inline elements.
In short block elements generate a new line and may contain other block and inline elements. Inline elements don't generate a new line and may contain other inline elements, but not block elements.
MDN web docs offers more information on block and inline elements.
Since span is an inline element, you can't place ul which is a block-level element inside. Or, you could, but then it's not a valid HTML, and that's not what you want.
Since you're using a third-party code, modifiying it could introduce other problems.
You could fork it, modify the parts you need and then use your fork. But when that third-party code gets updated, you have to repeat the whole process.
In cases like that you could just do monkey patching.
For your particular problem we could therefore do something like this:
from django import forms
class MyBaseForm(forms.BaseForm):
def as_table(self):
"Return this form rendered as HTML s -- excluding the ."
return self._html_output(
normal_row='%(label)s%(errors)s%(field)s%(help_text)s',
error_row='%s',
row_ender='',
help_text_html='<div class="helptext">%s</div>',
errors_on_separate_row=False)
BaseForm.as_table = MyBaseForm.as_table
You can place this code in your forms.py or any other file that is suitable to you.
Now the help_text will be rendered as a div element, which is a block-level element. You can place an unordered list ul inside and have a valid HTML.
Monkey patching isn't the most beautiful way of solving problems, but it is in my opinion a pragmatic way to overcome some tricky issues.
I think what you want is not exactly to "have an <ul> inside your help_text" but rather "display a bullet list inside your help text".
So if you don't have the ability to override as_table() or use something other than as_table(), I hope you are still able to change the stylesheet. In which case you can fake your ul with a span:
from django.utils.safestring import mark_safe
help_text=mark_safe(
'<span class="fake-ul">'
'<span class="fake-li">foo</span>'
'<span class="fake-li">bar</span>'
'</span>'
)
And here is your CSS:
.fake-ul {
display: block;
padding-left: 40px;
list-style-type: disc;
}
.fake-li {
display: list-item;
}
So probably it is too late, but I think you may find Django widget tweaks usefull.
Related
A while ago there was a term that I remembered that described two categories of elements. I forgot the term and I want to know what that term was. The information I can remember is that the first category of elements get their values from within HTML like <p> or <a> or <ul> but there is another category of elements which get their values from "outside" of HTML like <img> or <input type="textbox">. I want to know the terminology for these types.
Edit - I've went through Zomry, Difster and BoltClock's answers and didn't get anything. So I remembered some extra piece of information and decided to add it. The two categories are Lazy Opposites of each other. For example if one is called xyz, then the other is called non-xyz.
Probably you mean replaced elements (and non-replaced, respectively)?
However, the distinction between them is not so unambigous. For example, form controls were traditionally considered replaced elements, but the HTML spec currently explicitly lists them as non-replaced (introducing the "widget" term instead).
The HTML specification mentions for tags like <img> and <input> the following: Tag omission in text/html: No end tag.
Tags with an end tag are defined as: Tag omission in text/html: Neither tag is omissible.
So as far as I can find, the HTML spec does define a technical name for this, apart from void versus normal elements, so what Watilin pointed out in the comments should be fine: standalone vs containers.
As an added side-note: HTML has a lot more HTML content categories. You can find a complete overview at the HTML spec here: https://html.spec.whatwg.org/multipage/indices.html#element-content-categories
Also interesting to read to visualize that a bit better: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories
Elements whose contents are defined by text and/or other elements between their start and end tags don't have a special category. Even the HTML spec just calls them normal elements for the most part in section 8.1.2.
Elements whose primary values are defined by attributes and that cannot have content between their tags are called void elements. img and input are indeed two examples of void elements. Note that void elements are not to be confused with empty elements; see the following questions for more details on that:
Are void elements and empty elements the same?
HTML "void elements" so called because without content?
<input type="text" id="someField" name="someField">
With an input selector, you can get a value from it like so (with jQuery):
$("#someField).val();
Where as with a paragraph or a div, you don't get a value, you get the text or html.
<div id="someDiv">Blah, blah, blah</div> You can get that with jQuery as follows:
$("#someDiv").html();
Do you see the difference?
I'd like to my own HTML tags but I don't want new tags that might use the same name to cause them to break in the future.
Is this a good idea? Could I use a namespace to avoid conflicts?
Example:
HTML :
<b:HGroup>
<span>item 1</span><span>item 2</span><span>item 3</span>
</b:HGroup>
CSS:
#namespace b "library://ns.example.com/framework/1";
b|HGroup {
display:inline-block;
vertical-align: middle;
}
I read a related question and it suggests DTD. I'd rather not create a DTD but if it's necessary, then I'd like to define it inline. Also, I'd like it to be run as HTML5, not XHTML.
Note:
I do NOT want to use div plus a class.
As far as I understand it, it looks like custom elements I've written will not be overwritten by future elements of the same name if I explicitly register my custom element. Here is a quote from the W3:
Because element registration can occur at any time, a non-custom
element could be created that might in the future become a custom
element after an appropriate definition is registered. Such elements
are called undefined potentially-custom elements. If such a definition
is ever registered, the element will be upgraded, becoming a custom
element.
I've included a full page prototype based on the answers and I can't get it to attach any CSS to any element with a namespace. I've included some JS I found on one of the links but commented out part of it that was giving me errors. My main concern is getting elements with namespaces to be styled by the CSS with namespaces. From how I understand it that should work without JS.
<!DOCTYPE html>
<html xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:s="http://www.w3.org/2002/spark"
xmlns:space="http://www.w3.org/2002/space"
xmlns:spaced="http://www.w3.org/2002/spaced">
<head>
<script>
"use strict";
const inDocument = document.querySelector("example-element");
const outOfDocument = document.createElement("example-element");
// Before the element definition, both are HTMLElement:
//console.assert(inDocument instanceof HTMLElement);
//console.assert(outOfDocument instanceof HTMLElement);
//class ExampleElement extends HTMLElement {};
//customElements.define("example-element", HTMLElement);
//class ExampleElement3 extends HTMLElement {}
//customElements.define("element3", ExampleElement3);
//document.body.appendChild(outOfDocument);
</script>
<style>
#namespace s url(http://www.w3.org/2000/spark);
#namespace space url(http://www.example.com/2000/spark-space);
#namespace spaced "http://www.example.com/2002/spark-spaced";
example-element {
color: red;
display:block;
}
element2 {
color:green;
font-weight:bold;
}
s|element3 {
color:yellow;
}
space-element {
color:yellow;
}
space|space-element {
display:block;
color:yellow;
}
spaced|spaced-element {
display:block;
color:yellow;
}
</style>
</head>
<body>
<example-element>example-element</example-element>
<element2>element 2</element2>
<space-element>space element</space-element>
<s:element3>s namespace element 3</s:element3>
<space:space-element>space namespace el</space:space-element>
<spaced:spaced-element>spaced namespace el</spaced:spaced-element>
</body>
</html>
Custom HTML elements are supported by HTML5, but according to the specs they should contain a - character :
The name must contain a dash (-). So for example, <x-tags>,
<my-element>, and <my-awesome-app> are all valid names, while <tabs>
and <foo_bar> are not. This restriction allows the parser to
distinguish custom elements from regular elements but also ensures
forward compatibility when new tags are added to HTML.
See this article for a good introduction.
Applying CSS to custom HTML elements works the same way as applying CSS to standard HTML elements :
custom-element {
font-weight: bold;
background-color: #ff0;
}
<custom-element>
This is a custom HTML element
</custom-element>
You have a well researched question here. In doing so, you've eliminated all of the "valid" solutions.
You can definitely do what you have proposed, which (harmlessly*) breaks the standards. To be future proof, all HTML standards allow for unknown elements, instructing browsers to ignore them (essentially, they all become <span> elements) since there's no indication of what to do with them, though CSS can indeed affect them. This will work in ALL browsers, even Mosaic and the original IE (though CSS won't work in such ancient browsers).
As you already noted, the "proper" way to do this would be to define your own Document Type Definition (DTD) that can then be included at the top of your ~HTML document with the <!DOCTYPE> tag. This is probably overkill, but it is technically the right approach.
Another solution (that you've also eliminated) would be to use <span class="HGroup"> for inline elements and <div class="HGroup"> for block elements since these elements don't actually do anything by default.
A variant of that solution is to override the action of some otherwise useless tag and disable its standard properties in CSS, <s> for example:
s {
text-decoration: none; /* remove line-through */
display: inline-block;
vertical-align: middle;
}
(* The "harm" you can run into with custom element names is that if you don't specify a DTD (your own or else an existing one with an exact version), a future version of the HTML standard could theoretically define some undesired property for your custom element.)
The template page http://www.blacktie.co/demo/kelvin contains a tag I haven't seen before: <t>Email</t>
The corresponding CSS styles this: #footwrap t {font-weight: 700;}
I'm curious as to the significance of the <t>. It's not listed at http://htmldog.com/reference/htmltags or other lists I can find.
Is this a custom HTML tag? From what I've read about custom elements (eg http://www.html5rocks.com/en/tutorials/webcomponents/customelements) you need to call document.registerElement() or document.createElement() but this doesn't seem to be the case here.
Is this code semantically correct, or should it be written as:
<span class="t">Email</span>
#footwrap .t {font-weight: 700;}
Yes, the <t> tag is a custom element. While custom tags can be useful, if you want them supported in all browsers, you have to register the element with JS:
var tTag = document.registerElement('t');
More about custom tags here
So to answer your question, the coding is not valid, unless they have registered the element with the browser with JavaScript.
Sometimes, its just easier to use a class :D
This may be completely wrong, but t is not a real HTML tag. Therefor I assume it is a XHTML item. So yes if it IS XHTML then that would be correct, and the class would not be (unless that was the name of it of course).
I have been busy making an interactive tab layout using only CSS and I've had someone tell me that this is not the intended semantic meaning of <input> tags. Now, I know that HTML5 focuses a lot more on semantics than previous versions of HTML did, so I was wondering, is something that does something like the following against the input semantics:
<label for="toggleTab" class="togglelabel">Toggle tab</label>
<input type="checkbox" id="toggleTab" class="toggleinput">
<div class="toggletab">Look at this thing hide and show</div>
CSS:
.toggletab, .togglelabel {border:1px solid #AAA;display:block;}
.toggleinput, .toggletab {display:none;}
.toggleinput:checked + .toggletab {display:block;}
(demo)
The standards[1][2] both say the same thing:
The input element represents a typed data field, usually with a form control to allow the user to edit the data.
So to me this seems like this is indeed against what the input tag should be used for (since this has nothing to do with data, but just with displaying certain things to the user or not).
And then of course my followup question would be, if this is indeed not what input tags should be used for according to the standard, is it bad to go against the semantics standards?
Well structurally this will be quite difficult. Inputs need go inside form elements, and if you are going to be using these all over the page, most of your page will be wrapped as one giant form, potentially will nested forms, for search bars, user input and the like.
As your quote says:
The input element represents a typed data field, usually with a form control to allow the user to edit the data.
The control you are suggesting isn't for editing data its for adding graphical user functionality. If you were to bing the input to a form, either by placing the input inline into a form, or using the #form attribute as your comment suggests, what exactly is the semantic of that form? If would have no action, it would have no site to post to, and if an accessibile browser were to try and render the elements of that form in a different way it would have no semantic content.
For the kind of hide/show toggle functionality, I'd recommend instead using an a link and hanging some javascript off that. As stated:
If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor) labeled by its contents.
In this context Hyperlink does not preclude the use of javascript as the acting force on the page, if it did most pages would be non-compliant to the spec. This is backed up by the first type of link suggested in the definition of hyperlink suggests that the link can be "used to augment the current document".
As a side note, in accessible browsers, inputs like these maye be rendered or presented in ways different to what you expect. Each form might be pulled out into a list of possible data editing options, and this would not fit the semantics of what a user might expect.
Semantics & custom behaviour
If the question is about which element has the least implied semantics, I reckon your best bet is the <button type="button"> element: the HTML5 spec describes it as « a button with no additional semantics» which, without scripting, « does nothing » — unlike the <a> element, which has implicit behaviour as a hypertext link and anchor.
The HTML4 forms spec refers to these as 'push buttons', which « …have no default behavior. Each push button may have client-side scripts associated with the element's event attributes ».
Furthermore, the HTML4 spec cites buttons repeatedly in its description of scripts: they are the only element referenced specifically in the introduction to scripts, although inputs also feature in the examples of DOM-event triggered scripts — however, as buttons are non-self-closing, they can contain other DOM nodes, which may make them more flexible depending on your needs.
Non-<input> solution
Using the push button, custom behaviour can be inferred by using data-* attributes for CSS selectors:
.toggleinput[ data-checked ] + .toggletab {
display:block;
}
…and scripted as follows:
// Use Array's forEach to loop through selection
Array.prototype.forEach.call(
// …of all `.toggleinput` elements
document.querySelectorAll( '.toggleinput' ),
function bind( input ){
input.addEventListener( 'click', function toggleCheckedState(){
// `dataset` is an object representation of data-* attributes
if( this.dataset.checked ){
// Remove the attribute if it exists
delete this.dataset.checked;
}
else {
// Declare it if it doesn't
this.dataset.checked = true;
}
}, false );
}
);
Forked code demo
I have a custom tag <my-tag> created with an Angular directive, and replace it with a simple <div> in the directive definition code:
.directive('myTag',function(){
return {
restrict: 'E',
template: '<div>contents in template</div>',
replace: true
}
})
Things get strange when I put this tag inside a <p> tag and have some block element in it (for later transcluding maybe):
<p>
<my-tag><div>leak</div></my-tag>
</p>
the rendered html is something like this:
<p><div>contents in template</div></p>
<div>leak</div>
rather than been replaced as a whole, the <div>leak</div> is leaked out. Firstly I thought this might be some inline/block element issue, since the <p> tag is only allowed to have phrasing content in it. But when I switched it to <pre>, <h1>, <span>(they all have the same restrictions in the content model), I don't have the problem anymore:
<span>
<my-tag><div>leak</div></my-tag>
</span>
rendered html (as expected):
<span><div>contents in template</div></span>
This could be a big problem when tries to transclude the contents - they are completely unavailable in the directive.
Here is a plunker for the live demo:
http://plnkr.co/edit/hOByDb
Frankly I'm not sure whether this is a browser issue or a Angular issue, or maybe is just an intended behavior?
Edit:
I think this is rather a common HTML issue than an Angular issue, but it's more likely to happen in an Angular project, since we tend to have many custom directives/tags there.
According to W3C docs ( HTML4 & HTML5), block level elements are not valid children of <p>. This is cause of your problem
The P element represents a paragraph. It cannot contain block-level elements (including P itself).
Reference docs