Currently it is nearly impossible to create a valid website with strict doctype.
Too much html is still generated inside the functions and therefore not easy to edit and maintain.
For example:
template.class.php writes the combined css with <link> where it should be <link /> for a strict doctype. I'd have to change the php file and would lose it on updates.
**Reported by Matthes0815 on 22 Oct 2012 15:16**
**Version:** 2.4.5
Currently it is nearly impossible to create a valid website with strict doctype.
Too much html is still generated inside the functions and therefore not easy to edit and maintain.
For example:
template.class.php writes the combined css with <link> where it should be <link /> for a strict doctype. I'd have to change the php file and would lose it on updates.
[Piwigo Bugtracker #2776](http://piwigo.org/bugs/view.php?id=2776)
<!-- github-sync-id:97226476 -->
as we have switched to the HTML5 doctype for Piwigo 2.5 I don't think this is still relevant
**Comment posted by mistic100 on 27 Oct 2012 12:21**
as we have switched to the HTML5 doctype for Piwigo 2.5 I don't think this is still relevant
<!-- github-comment-id:124892928 -->
Comment posted by Matthes0815 on 27 Oct 2012 12:41
Well, it's at least still bad style...
It should be in the template's choice, which doctype gets used. I like to use XHTML and create my own little template, but I have to edit core files to make it valid - especially if I want to serve it with the right mime type "application/xml" or "application/xhtml+xml".
It's not a big thing to move the entire html to template files. Instead of assigning the whole link-tag for the combined css there could be the link-tag inside the template and template.class.php just assigns the new src.
**Comment posted by Matthes0815 on 27 Oct 2012 12:41**
Well, it's at least still bad style...
It should be in the template's choice, which doctype gets used. I like to use XHTML and create my own little template, but I have to edit core files to make it valid - especially if I want to serve it with the right mime type "application/xml" or "application/xhtml+xml".
It's not a big thing to move the entire html to template files. Instead of assigning the whole link-tag for the combined css there could be the link-tag inside the template and template.class.php just assigns the new src.
<!-- github-comment-id:124892940 -->
We can't keep this issue as it is, simply because it's not precise enough. This issue will never be closed (which is the purpose of all issues)
We can't keep this issue as it is, simply because it's not precise enough. This issue will never be closed (which is the purpose of all issues)
<!-- github-comment-id:215341301 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Reported by Matthes0815 on 22 Oct 2012 15:16
Version: 2.4.5
Currently it is nearly impossible to create a valid website with strict doctype.
Too much html is still generated inside the functions and therefore not easy to edit and maintain.
For example:
template.class.php writes the combined css with <link> where it should be <link /> for a strict doctype. I'd have to change the php file and would lose it on updates.
Piwigo Bugtracker #2776
Comment posted by mistic100 on 27 Oct 2012 12:21
as we have switched to the HTML5 doctype for Piwigo 2.5 I don't think this is still relevant
Comment posted by Matthes0815 on 27 Oct 2012 12:41
Well, it's at least still bad style...
It should be in the template's choice, which doctype gets used. I like to use XHTML and create my own little template, but I have to edit core files to make it valid - especially if I want to serve it with the right mime type "application/xml" or "application/xhtml+xml".
It's not a big thing to move the entire html to template files. Instead of assigning the whole link-tag for the combined css there could be the link-tag inside the template and template.class.php just assigns the new src.
We can't keep this issue as it is, simply because it's not precise enough. This issue will never be closed (which is the purpose of all issues)