Re: Hiding data using own tag

[Thomas 'PointedEars' Lahn]

[Since this has to do with both HTML and stylesheets, X-Post & F'up2
<news:comp.infosystems.www.authoring.misc>, where you should have posted in
the first place.]

Robert Prins wrote in <news:comp.infosystems.www.authoring.stylesheets>:

> Using tablesorter I need to sort data that it cannot easily handle, so the
> program that generates the html builds the <td> elements as
>
> <tbody class="awkward">

This should be pseudocode. Otherwise a more descriptive class name should
be chosen.

> <tr>
> <td>...
> <td>...
> <td><hidden>{sortable data}</hidden>{raw data}</td>
> </tr>
> </tbody>
>
> and the CSS I use is
>
> tbody.awkward tr td {
> text-align: right
> }
>
> tbody.awkward tr td > hidden {
> display: none;
> }
>
> and this works just as well, and has the "advantage" that the "hidden" tag

_Element_, not tag.

<http://www.w3.org/TR/2014/REC-html5-20141028/dom.html#elements>

> is rather a lot more meaningful than the original empty "span".
>
> Good practice,

No.

> or should I just not be too clever for my own good?

As for your stylesheet:

You should avoid element type selectors, particularly as key selector (the
rightmost one that represents the selected elements), since that makes your
stylesheet dependent on the chosen element types and will likely have it
apply to more elements than you intended. It is better to use class
selectors instead.

You should avoid having selectors that depend on the nesting of elements
unless a distinction is necessary. Keep in mind that the more simple
selectors you use in a selector, the greater the specificity of that
selector, and the harder to override the associated property declarations
except with “!important” or “style” attributes (which you want to avoid
since they create only more problems).

For example, since a “td” element must be nested in a “tr” element in Valid
HTML, you can skip the “tr” element type selector. And since a table cell
would be contained in a table row which would be contained in a table, you
could change “td” to “.table-cell”, and specify class="table-cell" on your
table cells. Likewise “.table-body” instead of “tbody”. Should you ever
decide to change the element type, or reuse that stylesheet in another
context with other element types, you can do that without changing your
stylesheet considerably.

<https://specificity.keegan.st/>
<http://cssguidelin.es/>


As for your markup:

Your custom markup is not Valid. Although HTML5 includes specifications to
support unknown element types (see the HTMLUnknownElement interface), it
forbids authors to make up element types arbitrarily:

,-<http://www.w3.org/TR/2014/REC-html5-20141028/dom.html#elements>
|
| […]
| Authors must not use elements, attributes, or attribute values that are
| not permitted by this specification or other applicable specifications, as
| doing so makes it significantly harder for the language to be extended in
| the future.

See also <https://validator.w3.org/>.

If you are using HTML5, you should be using the “hidden” attribute instead,
or look into other ways to embed the data. For example, if “tablesorter”
(URL?) is a client-side script, you could provide the data as JSON on demand
or as an ECMAScript Object instance created with literal notation.

<http://www.w3.org/TR/2014/REC-html5-20141028/editing.html#the-hidden-attribute>
<http://www.w3.org/TR/2014/REC-html5-20141028/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes>
<http://www.w3.org/TR/2014/REC-html5-20141028/text-level-semantics.html#the-data-element>

JFTR, as of 2016-06-21, HTML 5.1 has reached the status of Candidate
Recommendation (CR) and is now referred to as the “Latest Version of HTML”
by the W3C. As a result, <http://www.w3.org/TR/html/> is equivalent to
<https://www.w3.org/TR/html51/>.

The specification content in HTML 5.1 that corresponds to the content
referred above can be found by replacing “2014/REC-html5-20141028” with
“html51” or “2016/CR-html51-20160621” in the URIs.


PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14