What markup would you use for this?

Would you use an HTML table, a data table, or something else?

Thanks

(The history lesson is free!) :biggrin:

Difficult. I think I might use a definition list.

3 Likes

Oops, yes that’s what I meant by data table! Thanks TB.

1 Like

I would use a table because I think formatting would be easier.

How is the source data formatted?

1 Like

Yes I would. :winky:

Date in the first cell and Data in the second. :sunglasses:

coothead

1 Like

To match the formatting in the image I think a table would be harder to do.
Though ease of formatting should not take precedence over semantics.
It is debatable whether semantically this should be a table or dl, I think either could work.

This example shows the default styling of a dl and how css can change it to be more like the format in the image.

5 Likes

Thanks guys!

Ah. It started out as a Word doc which I saved as HTML :rolling_eyes: and spent many happy hours tidying up! I reduced 117KB to 36KB…

3 Likes

Maybe the formatting of your document is a bit different, but I find the amount of mark-up clutter in a Word to HTML export too much to bother with.
I do write articles in MS Word (or have them sent to me as). But when I transfer to HTML I do it manually, copying a paragraph at a time and pasting between <p> tags in my HTML document (or other elements as appropriate, but an article is mostly made of paragraphs). It can be laborious on longer articles, but I’m sure it’s better than removing all that clutter from a straight HTML export.
I don’t know if there are any tools that will do an HTML export with clean mark-up, it would be nice.

3 Likes

Yes, that’s what I usually do. In this case, I decided on a different route. I think it’s a case of swings and roundabouts, but yes the code was 'orrible. :unhappy:

1 Like

I’m sure I saw something a few weeks back. I’m not so sure I didn’t paste something in Slack. Let me see if I can find it.

Edit: This was the one - https://twitter.com/captainsafia/status/881551373212450818 - looks like it might be OSX only though.

1 Like

I can use the details tag:

<details>
<summary>You can avoid summary if you want</summary>
<p>Content here</p>
</details>

PS-1: You can put whatever you like inside the details (even a second details tag) so why tables or definitions lists? Details are better for the/this job

PS-2 If you use the details tag after all, you must use a normal markup, e.g paragraphs, tables etc. Don’t put just casual content.

Hi @SamA74,

I have created the following CodePen and curious to know if it is semantic.

https://codepen.io/John_Betong/pen/ZJgxVO?editors=1100#0

Lack of support for <details> in IE and Edge might make it less than an ideal choice.

Html5 indicates that Definitions lists (DL) are now data lists and can take any name/value content which means that the use you have shown is perfect for them.

There is a good discussion here (although a few years out of date) but the comments by Thierry and LEE are the most compelling arguments I think.

If you use a table then the first cell must be the th and the next cell the td (not just 2 tds in a row) because the semantics are then lost. A table would be overkill for this simple list but I have often used both depending on ‘use-case’ so its not a big issue either way.

6 Likes

An interesting article (and discussion).

Yes, I was thinking along similar lines before reaching those comments.
It is not the fault of the <dl> that the SR doesn’t interpret it well, but a fault with the SR. To be fair to the SRs, them pandering to unsemantic use of tables, lists and other elements is possibly born out on necessity due the the number of developers producing unsemantic code, possibly ignorant of lesser used elements like dl, while there are still old-school, legacy sites out there and Neanderthals still using tables for layout.
So the result is people avoiding proper semantics, instead choosing the elements the SR deals with best, and having to jump through hoops just to make SRs recognise table elements for what they actually are.
Should it really be necessary to give a <tr> role of row?

<tr role="row">

This is an absolute nonsense IMO. [rhetorical] What on earth else could it possibly be?`[/rhetorical] :unhappy:

I think it’s backwards for devs (who know good semantics) to pander to the SRs which are pandering to the Neanderthals, as this means they are holding us all back to the stone(table) age of web design rather than progressing to a more semantic and readable web. :angry:

I’m hoping, as was hinted at, that the SRs have improved since then.

3 Likes
  1. I wanted to give another option except tables and definition lists. OK, it’s true that ie has a bug with the specific tag, but according to my opinion it’s better for someone to know that he has an extra choice than not to be aware of it.

  2. You are absolutely right when you said about the bug. But generally it’s not an important bug really. To be more accurate, the only buggy thing, is that ie (don’t know about Edge, sorry) doesn’t understand that since someone did an action (i.e clicked over the details or summary elements), a result is required [open/close]. But that doesn’t change the fact that you can use the rest of the code. If for example you only want a normal question/answer sheet:

Question: ???
Answer: …

then you don’t care if the «answer» must close after clicking over the «question». The whole thing that counts -well, according to my opinion at least- is to have a proper structure, even if a fancy effect cannot be applied and especially when it works in 99% of the browsers

  1. There is a solution about the whole bug, (Css/Html code only i.e, no Js) which I often use (that’s why I didn’t explain about the bug since I -generally- ignore it, hence forgot about it)

Here is what I use (and it’s a common thing really… it’s not nothing special):

HTML CODE:

<a href="#open-me">Click to open the div</a>
<div id="open-me">
	<ul>
		<li>Li content here</li>
		<li>Li content here</li>
		<li>Li content here</li>
	</ul><a href="#">close me</a>
</div>

CSS CODE:

#open-me:target {display:block;}
#open-me:not(:target) {display:none;}

Using the above trick you have the same effect as when you click the details/summary tags. And the cool thing is that you can use it simultaneously with these tags instead of a div. Of course most of the browsers will recognize two clicks (one of the original details/summary tags and one of the “open-me” clicked event) and explorer only one, (the clicked event) but I don’t believe anyone would care about it, if the user prefers to have the choice to hide/close the «answer» in explorer, instead of not being able to close it at all. And from the other hand if the user doesn’t care for one more click… well, he doesn’t care so everything is fine. :innocent:

PS: I must admit that you’re right though. Since I didn’t explain all these my last post was incomplete. Sorry about that.

1 Like

I’m struggling to see how the use of <summary> or <detail> applies to the scenario give in the original post. Their use seems more related to behaviour than semantic markup; at least from the example quoted.

2 Likes

I think of <details><summary> as kind of an accordion for a tl;dr in terms of it’s semantic use.

For date and historical event, it could be made to “work”. And if other means failed I might be tempted to use it. But I think for this example the choices should be between using a table or a list.

For only two fields I would lean towards a list. But if I thought other fields might be added later, eg. “historical importance level” etc. then I’d go straight to a table.

5 Likes

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.