Indication of publication date is complicated and inconsistent #1392

New Issue

reinhard · 2020-05-16T20:53:13Z

reinhard commented

2020-05-16 20:53:13 +00:00

The publication date of a web page is done in two different ways:

Variant A:

<html newsdate="YYYY-MM-DD">

Variant B:

<html>
  <date>
    <original content="YYYY-MM-DD"/>
  </date>

Regular news items and podcasts use variant A, pages outside the news tree use variant B, and newsletters even use both, where the date from variant A is used for sorting the newsletter within other news, while variant B is used for displaying the publication date and used to contain only the month.

Especially variant B is overly complex to allow for an additional revision date, which is used only on 2 pages at all: https://fsfe.org/activities/os/eifv2.html and https://fsfe.org/news/2012/news-20120920-01.html

I suggest to forget about the revision date altogether and replace all of the above with a simple

<html date="YYYY-MM-DD">

Because currently, the “newsdate“ tag is also used to tell which source files actually are news, we would at the same time have to introduce a third value for “type”, so for regular news items, newsletters, and podcasts, we'd have a straightforward pattern for the root element:

<html date="YYYY-MM-DD" type="news">
<html date="YYYY-MM-DD" type="newsletter">
<html date="YYYY-MM-DD" type="podcast">

As a side effect from this, we could stop abusing the newsdate to change a news item from unpublished to published, and instead just leave away the “type” while the news item should not be published.

The publication date of a web page is done in two different ways: Variant A: ```xml <html newsdate="YYYY-MM-DD"> ``` Variant B: ```xml <html> <date> <original content="YYYY-MM-DD"/> </date> ``` Regular news items and podcasts use variant A, pages outside the news tree use variant B, and newsletters even use both, where the date from variant A is used for sorting the newsletter within other news, while variant B is used for displaying the publication date and used to contain only the month. Especially variant B is overly complex to allow for an additional revision date, which is used only on 2 pages at all: https://fsfe.org/activities/os/eifv2.html and https://fsfe.org/news/2012/news-20120920-01.html I suggest to forget about the revision date altogether and replace all of the above with a simple ```xml <html date="YYYY-MM-DD"> ``` Because currently, the “newsdate“ tag is also used to tell which source files actually are news, we would at the same time have to introduce a third value for “type”, so for regular news items, newsletters, and podcasts, we'd have a straightforward pattern for the root element: ```xml <html date="YYYY-MM-DD" type="news"> <html date="YYYY-MM-DD" type="newsletter"> <html date="YYYY-MM-DD" type="podcast"> ``` As a side effect from this, we could stop abusing the newsdate to change a news item from *unpublished* to *published*, and instead just leave away the “type” while the news item should not be published.

reinhard referenced this issue

2020-05-16 21:05:03 +00:00

Improve display of Date and Author in news #1387

max.mehl commented

2020-05-20 15:42:52 +00:00

Thanks for the suggestions!

I agree on dropping variant B altogether. I also agree that a simple "date" is great.
Is the "type" actually necessary? (It probably is, just want to cross-check)
However, the way to (un)publish news probably will create some confusion, and is yet another attribute editors have to control, while the "date" is something they already know and have to update anyway. I especially am afraid of a situation when someone just adds the "news" tag to a newsletter or so.

So I would suggest to stick with this "abuse" of the newsdate, or introduce another way to unpublish a news item that is more obvious.

Thanks for the suggestions! * I agree on dropping variant B altogether. I also agree that a simple "date" is great. * Is the "type" actually necessary? (It probably is, just want to cross-check) * However, the way to (un)publish news probably will create some confusion, and is yet another attribute editors have to control, while the "date" is something they already know and have to update anyway. I especially am afraid of a situation when someone just adds the "news" tag to a newsletter or so. So I would suggest to stick with this "abuse" of the newsdate, or introduce another way to unpublish a news item that is more obvious.

reinhard commented

2020-05-20 15:56:43 +00:00

Is the "type" actually necessary? (It probably is, just want to cross-check)

The "type" is used for 3 things:

Add the correct breadcrumb on top
Add a sidebar even though there is no <sidebar> in the xhtml file
Modify the way the newsdate is displayed

The last item is what we want ot get rid of with this issue. The other two items are probably worth keeping.

However, the way to (un)publish news probably will create some confusion, and is yet another attribute editors have to control, while the "date" is something they already know and have to update anyway. I especially am afraid of a situation when someone just adds the "news" tag to a newsletter or so.

So I would suggest to stick with this "abuse" of the newsdate, or introduce another way to unpublish a news item that is more obvious.

What about being clear and straightforward and adding a publish="yes"?

> * Is the "type" actually necessary? (It probably is, just want to cross-check) The "type" is used for 3 things: * Add the correct breadcrumb on top * Add a sidebar even though there is no `<sidebar>` in the xhtml file * Modify the way the newsdate is displayed The last item is what we want ot get rid of with this issue. The other two items are probably worth keeping. > * However, the way to (un)publish news probably will create some confusion, and is yet another attribute editors have to control, while the "date" is something they already know and have to update anyway. I especially am afraid of a situation when someone just adds the "news" tag to a newsletter or so. > > So I would suggest to stick with this "abuse" of the newsdate, or introduce another way to unpublish a news item that is more obvious. What about being clear and straightforward and adding a `publish="yes"`?

max.mehl commented

2020-05-20 16:06:40 +00:00

I see, thank you for the explanation. Ack for keeping the type.

What about being clear and straightforward and adding a publish="yes"?

I think that would be very clear!

I see, thank you for the explanation. Ack for keeping the type. > What about being clear and straightforward and adding a publish="yes"? I think that would be very clear!

reinhard commented

2020-05-27 19:36:20 +00:00

The more I think of the "type" thing, the more I get convinced that it would be good to get rid of it. I have some ideas tossing around in my head. Stay tuned.

reinhard added a new dependency 2020-05-27 21:44:02 +00:00

#1410 Idea: auto-generate breadcrumbs based on directory tree

reinhard commented

2020-05-28 12:41:28 +00:00

If we go for #1410 then the type would only be used for automatically inserting the correct sidebar. I wonder whether it wouldn't be better then to remove the type completely and instead add modules for the standard sidebars. So instead of

<html date="YYYY-MM-DD" type="newsletter">
  :
</html>

one would have to write

<html date="YYYY-MM-DD">
  :
  <sidebar>
    <module id="sidebar-newsletter"/>
  </sidebar>
</html>

which would be much more straightforward and understandable. What do you think?

If we go for #1410 then the type would only be used for automatically inserting the correct sidebar. I wonder whether it wouldn't be better then to remove the type completely and instead add modules for the standard sidebars. So instead of ```xml <html date="YYYY-MM-DD" type="newsletter"> : </html> ``` one would have to write ```xml <html date="YYYY-MM-DD"> : <sidebar> <module id="sidebar-newsletter"/> </sidebar> </html> ``` which would be much more straightforward and understandable. What do you think?

reinhard referenced this issue

2020-05-28 12:43:34 +00:00

Add "Follow our News" + "Social Media" to news items #1399

reinhard added the

build

xsl

labels 2020-05-28 13:18:41 +00:00

max.mehl commented

2020-05-28 15:46:00 +00:00

Hm, so in both cases we would have an element/attribute that differs depending on the type of the file, so from the users' perspective, there is no difference.

But I guess the main advantage is in not having to set some XSL rules which target the "type", but just reusing the neat modules, right? In this case, I would be fine with using the modules approach.

Hm, so in both cases we would have an element/attribute that differs depending on the type of the file, so from the users' perspective, there is no difference. But I guess the main advantage is in not having to set some XSL rules which target the "type", but just reusing the neat modules, right? In this case, I would be fine with using the modules approach.

max.mehl referenced this issue

2020-05-28 15:47:17 +00:00

Add "Follow our News" + "Social Media" to news items #1399

reinhard commented

2020-05-28 18:08:06 +00:00

But I guess the main advantage is in not having to set some XSL rules which target the "type", but just reusing the neat modules, right?

Yes. The general idea is to have generally usable good features instead of many specialized distinct features. It's also about how intuitively something is understandable: you had to ask for what function the "type" parameter actually has, and I had to grep it, on the other hand the <sidebar><module/></sidebar> construction is clear and immediately understandable.

In this case, I would be fine with using the modules approach.

I'll open a new issue for clarity because it's actually a different topic than the date parameter :-)

> But I guess the main advantage is in not having to set some XSL rules which target the "type", but just reusing the neat modules, right? Yes. The general idea is to have generally usable good features instead of many specialized distinct features. It's also about how intuitively something is understandable: you had to ask for what function the "type" parameter actually has, and I had to grep it, on the other hand the `<sidebar><module/></sidebar>` construction is clear and immediately understandable. > In this case, I would be fine with using the modules approach. I'll open a new issue for clarity because it's actually a different topic than the date parameter :-)

reinhard referenced this issue

2020-05-28 18:11:24 +00:00

Implicit sidebar for news items is hard to understand and adds unnecessary complexity #1415

reinhard added a new dependency 2020-05-28 18:13:02 +00:00

#1415 Implicit sidebar for news items is hard to understand and adds unnecessary complexity

reinhard commented

2020-05-28 18:14:19 +00:00

As soon as #1410 and #1415 are fixed, we can globally change to the date parameter as proposed here, and at the same time remove the type parameter.