I understand that according to the HTML specification, it's invalid to add custom attributes to elements. Is this also invalid with XHTML?
I thought XHTML was part of the XML family, and as such was extensible. Being extensible, isn't it ok to use custom attributes?
Dave
custom attributes won't be considered valid by the standard W3C validators.
You can define your own document type definition (DTD) though. See http://www.alistapart.com/articles/customdtd/ for more information about that.
With the standard document type definition, you can't introduce your own custom attributes.
But, starting with HTML5 you'll be able to introduce your own attributes as long as you prefix them with data-.
Related
How to generate an <abbr> abbreviation element in ReST?
<abbr title="Hypertext Markup Language">HTML</abbr>
The documentation indicates that "The abbreviation element is not exposed in default restructured text. It can only be accessed through custom roles." I'm not sure how to create such a custom role, and the rest of the documentation is a tad obscure to me.
For Sphinx users, an abbreviation can be added using the :abbr: role. For example,
This :abbr:`SDP (Software Development Plan)` defines ...
results in the following HTML
<p>This <abbr title="Software Development Plan">SDP</abbr> defines …</p>
I have solved it for now by adding this at the bottom of the document:
.. |HTMLabbr| raw:: html
<abbr title="Hypertext Markup Language">HTML</abbr>
Then in the document I've used this "tag"/custom role like this:
This document is written in |HTMLabbr| and renders nicely in a modern browser.
For each abbreviation you would have to define a new custom role, I'm wondering if there is a way to have a "tag" that would take the value and the title as parameters instead of having to hard-code it like this.
Creating custom docutils rst role is not hard (compared to other ways how to extension docutils). See rst roles howto, which contains all the details along with a full implementation of example RFC role. I was able to create custom bugzilla referencing role based on this document.
Recently I've been reading about how you can make custom tags valid in HTML5 by putting a dash in the name, so I've been wondering what the actual rules / guidelines are for custom tags.
custom-tag √
custom X
-custom ?
custom- ?
What I want to know is if the last two are valid.
Also, as a bonus, I'm kind of curious about how custom attributes work.. as far as I know:
<div my-attribute="demo"> X
<div data-my-attribute="demo"> √
<custom-tag my-attribute="demo"> √
<custom-tag data-my-attribute="demo"> √
But what happens if I'm trying to use existing global attributes, such as title or class?
Does this CSS..
custom-tag.banana {
color: yellow;
}
target this HTML?
<custom-tag class="banana">
Test!
</custom-tag>
Also, this CSS should target the above HTML whether or not global attributes work with custom tags, correct?
custom-tag[class=banana] {
color: yellow;
}
Finally, is there a rule/guideline stating I should have a "-" in the name of my custom attribute, like custom tags? E.g. <div custom-tag="demo">. If there is, like my original question, does it work with -customtag, and customtag-?
Thanks for the help. :)
TL;DR: There are no valid custom HTML5 tags.
I think you may be referring to this Custom Element Working Draft proposed by the Web Applications Working Group, which describes this:
The custom element type identifies a custom
element interface and is a sequence of
characters that must match the NCName
production, must contain a U+002D HYPHEN-MINUS
character, and must not contain any uppercase
ASCII letters. The custom element type must not
be one of the following values:
annotation-xml
color-profile
font-face
font-face-src
font-face-uri
font-face-format
font-face-name
missing-glyph
Additionally, according to HTML5 specification, HTML tag names can only start with ASCII letters. If we assume that the Custom Element proposal does not propose any changes to the HTML Syntax specification, then elements starting with hyphens-minus character is not a valid HTML tag name. If we combine what the Custom Element Working Draft proposal and the HTML5 Syntax specification says, then we can conclude that <-custom> is not a well-formed HTML and so cannot be a valid Custom Element because the tag name does not start with ASCII letter. On the other hand, custom- is both a well-formed HTML and a valid Custom Element.
Note that Custom Element is a Working Draft, not a W3C Recommendation. This means that Custom Elements is not valid in HTML5. Don't get your hopes up either, a lot of Working Drafts that are proposed in W3C never got anywhere (and for good reasons too, not all of the proposals are good).
<rant>Personally I hope that this proposal got shot down. I spent some time reading this proposal, it looks like this proposal tried to reinvent XML Namespace and SGML poorly, and probably forgot about what HTML and the semantic web is supposed to be. In any case, HTML5 syntax already allows authors to use elements that aren't specified in HTML5 specification, I don't see any need to standardize how to create custom elements any further than that. I hope that there would be people in HTML5 working group sane enough to realize how bad this proposal is and vote this proposal off. Keep HTML5 closed from author-defined custom modifications.</rant>
If you want to define your own custom vocabularies, I suggest you should write an XML application with XHTML5, which actually specifies how you can define your own custom elements with XML namespaces. Unlike HTML, XML is designed to be extensible.
As for your question about custom data attribute, this is what the HTML5 specification says:
A custom data attribute is an attribute in no namespace whose name starts with the string "data-", has at least one character after the hyphen, is XML-compatible, and contains no uppercase ASCII letters.
So with your examples, these are valid data-* attributes:
data-my-attribute
while these are not:
my-attribute
As far as I can tell, the Custom Elements Working Draft does not specify any additional syntactical requirement for custom attributes on Custom Elements, nor does it explicitly permit using arbitrary non-data-* attributes and how custom attributes interacts with existing HTML attributes, although we can reasonably infer that allowing custom attributes is probably the intent of the proposal.
As for your question about CSS, yes you understood correctly, those are valid CSS selectors to target those Custom Elements. CSS can be used to style any elements, not just elements defined by HTML, but also other markup languages like SVG, MathML, as well as arbitrary XML vocabularies when using XHTML. The CSS Selectors specification does not actually depend on HTML vocabulary in any substantial way (although HTML is used heavily in the examples, as it's what most people are most familiar with). It is for this reason that CSS Selector syntax can be used to refer to any elements in the document, including custom elements that aren't specified in the HTML specification. Styling custom tag already works in all major browsers today. You can use any arbitrary tag names, and select them with the selector that you expect, and CSS will style them as you would expect them to be. There is no requirement for having hyphen-minus in the tag name for this to work.
To pass validation, all attributes you add that aren't available for the element by default should be prefixed with data - it has nothing to do with it containing a dash or not.
Targeting these in CSS is done by using something like element[data-attribute].
So this is valid: <div data-title="Custom Data Title"></div>,
this would not be : <div custom-title="Custom Title"></div>.
Targeting could be done by using div[data-title="Custom Data Title"]{}
Concerning tags, you are limited to the tags provided by the browser if you want your site to validate. You cannot use custom elements willy-nilly, as it increases processing of your page.
You can use javascript to require a page to recognise certain tags, but it still won't validate. This will work, but is not advised:
<script type="text/javascript">document.createElement("custom");</script>
<custom data-name="Something">Here</custom>
Theres more info here: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Using_data_attributes
HTML5 does not have a specific doctype definition or an XML schema definition.
It is possible to create custom HTML tags (custom elements) as they can be used to create web components
Custom attributes are also valid as they can serve to supply a web component with required information
e.g.
<custom-element a="x" b="y"/>
Does there exist any "thing"(element, DOM manipulation, styling, nesting of elements, attributes, anything of that sort...) one can do in XHTML 5, that one CANNOT do in HTML 5? I remember reading on the web about one such case, but I cannot recall where it is I saw it.
This is apart from the use of content from external namespaces such as SVG and MathML (which is supported in HTML as well).
For reference, the number of answers to the converse question "what can you do in HTML 5 that you can't in XHTML 5?" are very large, given the strictness of XHTML. Hence I'm looking for answers to this question.
Yes, for example entity declarations and references to entities so defined. They are part of XML, so they must be supported when using XML serialization, as it is required to follow generic XML rules. Example:
<!DOCTYPE html [
<!ENTITY foo "Hello world">
]>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Demo</title>
</head>
<body>
&foo;
</body>
</html>
XHTML, being XML supports xml-stylesheet declarations. Not just CSS but also XSLT. Which can transform the document tree before presentationXSLT also supports inclusions via document("foo.xml"), which can be used as an XInclude surrogate since no browser supports the latter right now.
XML parsers validate well-formedness
XHTML supports namespaces, allowing other XML content (not just SVG and MathML) to be embedded
CDATA sections
.innerHTML, .insertAdjacentHTML() and .createContextualFragment() validate well-formedness
The topic is quite interesting in general. E.g. an XHTML5 parser is not quite the same as a pure XML parser, as the HTML5 spec mandates a few willful violations of the XML parser, e.g. to support the <template> element.
There also are a handful of states in which you can have a valid DOM that will throw an error if you try to export it through the XHTML fragment serialization algorithm.
And the HTML Fragment serialization algorithm may emit a string which will result in a different DOM when parsed again by a HTML parser.
So basically all three of the following are not fully isomorphic to one another, in any combination:
the XHTML5 serialization
the (X)HTML5 DOM
the HTML5 serialization.
In XHTML, you can use self-closing syntax (/>) on non-void elements:
<script src="js.js" />
And void elements can have stray end tags:
<input></input>
I was able to find what I was remembering vaguely in this unofficial Q&A by hsivonen. I'm still looking for other such "features".
[...] In this case, you must avoid constructs that aren’t supported in text/html (e.g. div as a child of p).
Searching about more, I found this page (second post from top) :
but basically a p can never enclose a div in HTML (or XHTML served with the mime type text/html). If you are serving XHTML with an XML mime type, you can do this in theory, but the result would not be valid XHTML.
saying that the HTML parser simply doesn't allow the possibility, while the XHTML parser, which doesn't need to second-guess the code, accepts it but it's still invalid.
I decided to test it out : took an application/xhtml+xml page, tried to add a div inside a p using Chrome dev tools "Edit as HTML" function. It worked. I copied the source, made the same change and tested it in validator.nu. It marked it as invalid, to my slight disappointment.
Trying to add a div in a text/html page in the same manner was impossible. As soon as I exited the "Edit as HTML" mode, it simply moved the div after the p.
the Qt documentation says
The Qt XML Module is provided for compatibility with older code. It
has been superseded by the QXMLStreamReader and QXMLStreamWriter
classes in the Qt Core Module.
I think we can use QDom* class to get data out of HTML before this claim ,although I never used it.
does this claim mean we can use QXmlStreamReader for pulling data out of HTML ?
I don't know the difference between XML and HTML.
XML stands for "Extensible Markup Language", whereas HTML stands for Hypertext Markup Language. In simple terms, they are not the same, or at least not used for the same purpose.
XML is a markup language that defines a set of rules for encoding documents in a format which is both human-readable and machine-readable.
HTML is the standard markup language used to create Web pages.
Looking at html and xml, they appear similar in that they both include tokens to define elements, though the elements used by HTML are of a fixed set, unlike XML whose elements are the meta-data of the document in which the elements reside.
Since XML elements can be named freely, unlike HTML, HTML can be added to a DOM document. As for being able to use QXmlStreamReader, according to this thread, it appears that you can, but note that the OP of that question has wrapped the html in an XML tag, which I expect will be required in order for the Dom document to accept parsing the data.
I'm working on a Drupal site/theme. The CSS and PHP modifications are fairly easy; they just take a little time to learn and get working exactly how I want.
However, I'm having issues applying CSS styles to some elements because of what I think is a property function.
The code looks like <h2 property="dc:title" datatype="" class="node-title">.
What is a property function and what does it do or control within the page? Also how can I modify or remove it?
It's not a property function; it's an attribute that is used from RDFa, and that is added from the RDF module.
The easier way to remove those attributes is to disable the module, but I would not suggest doing it, as the purpose of that module is to enrich your content with metadata to let other applications better understand its relationships and attributes.
Alternatively, if the problem is just with that property, used for the nodes, then you can implement code similar to the following one:
function mymodule_preprocess_node(&$variables) {
if (isset($variables['title_attributes_array'])) {
$variables['title_attributes_array']['property'] = NULL;
}
}
The module should be executed after the RDF module, to allow its hook to be executed after the one implemented by the RDF module.
I have not seen any compatibility problem between the attributes added by the RDF module and the JavaScript code executed by Drupal core or third-party modules. It would probably be the case to investigate why you are having problems with the JavaScript code when those HTML attributes are added.
in your css file, put:
h2[property="dc:title"]{color:#FFFFFF;}
or if it is a link, you may need:
h2[property="dc:title"] a {color:#FFFFFF;}
From wikipedia, check out RDFa
RDFa (or Resource Description
Framework – in – attributes) is a W3C
Recommendation that adds a set of
attribute-level extensions to XHTML
for embedding rich metadata within Web
documents.
It is basically a way to add more metadata to XHTML docs for better semantics.