Indication of publication date is complicated and inconsistent #1392

Open
opened 2020-05-16 20:53:13 +00:00 by reinhard · 8 comments
Member

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.
Owner

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.
Author
Member
  • 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"`?
Owner

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!
Author
Member

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.

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
Author
Member

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 added the
build
xsl
labels 2020-05-28 13:18:41 +00:00
Owner

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.
Author
Member

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 :-)
Author
Member

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.

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.
reinhard added a new dependency 2020-05-28 18:35:04 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: FSFE/fsfe-website#1392
No description provided.