Serendipity Forums

garvinhicking wrote:

* The comment switch [theaded|linear] produces invalid HTML5. I'm not exactly sure what it is exactly.
* The quicksearch plugin's code is also not HTML5 compliant.

Once you find the exact problem, drop a note

First of all, "not HTML5 compliant" is too strong for the quicksearch plugin – its code is valid in HTML5, but it doesn't use the new "search" input type like the built-in search form. Obviously, this is not an issue since the built-in search form works fine and suppresses the quicksearch plugin in sidebars.

As for the comment switch, testing it with my local dev blog, the w3c validator gives me:

Bad value /serendipity/index.php?url=archives/16-Podcasting-Video.html&serendipity[cview]=linear#comments for attribute href on element a: Illegal character in query component.

Syntax of IRI reference:
Any URL. For example: /hello, #canvas, or http://example.org/. Characters should be represented in NFC and spaces should be escaped as %20.

Since said URL doesn't have any spaces, it has to be NFC representation:

For various reasons, Unicode sometimes has multiple representations of the same character.

I assume this relates to one of the special characters in the URL, meaning #, ?, & or the square brackets …

YL

Hi!

Is the "&" written as "&" in the HTML sourcecode?

Also, the [ and ] could be a problem, technically they are not allowed and needs to be escaped to %5B and %5E or something like that, but I always find those too hard to read in HTML, so this wouldn't be easily fixable.

Regards,
Garvin

garvinhicking wrote:Is the "&" written as "&" in the HTML sourcecode?

Yes.

garvinhicking wrote:Also, the [ and ] could be a problem, technically they are not allowed and needs to be escaped to %5B and %5E or something like that, but I always find those too hard to read in HTML, so this wouldn't be easily fixable.

If they're not allowed, why do we have them?

I really don't know much about this whole unicode thing – but in general (in plain HTML at least), it can help to use entities like &, so maybe we should try [/]?

YL

Hi!

If they're not allowed, why do we have them?

Because every browser always dealt with chose characters properly, and it's simply too much work to fix all of those links, and reporting that as an error is actually anal-retentive.

Maybe you could dump the page as HTML, make the changes to the URL and revalidate to see if that changes things.

Regards,
Garvin

garvinhicking wrote:Maybe you could dump the page as HTML, make the changes to the URL and revalidate to see if that changes things.

Done. (So much fun, the validator apparently is taking his bitchy five today.)

It's definitely the square brackets, removing them altogether passes the validator. However, neither [/] nor [/] work. But %5B/%5D does.

YL

garvinhicking wrote:Yeah, the nesting has always been complicated. The problem is that it's REALLY expensive (performance-wise) to perform, and coding-wise also a bit tricky. For categories not so much, because we have a nested tree compatible structure. Nesting comments though might be nearly impossible to resolve without a LOT of headache...

I am almost done with the rest of 2k11, just added a polyfill for the details element (used for trackbacks) and a user.css theme option (extra link element). What's left to do is nesting categories, the [cview] issue and some CSS cleanup.

After that, we should deal with the question of how to actually use it – i.e. the standard/default template discussion. I suggest a seperate thread for that. Also, we should discuss changes to various plugins in terms of HTML5 compliancy seperately.

Thanks again to anybody who provided feedback.

YL

Hi!

Well, then I don't think we can properly validate most of the code; chaing this 5B/5E issue is just a giant hydra that would take an awful lot of work. Fixing it for that single issue might help with that simple validating, but you'd still have several places where square brackets also occur...maybe that's not worth it, since picking on this issue is really TOO picky.

Regards,
Garvin

garvinhicking wrote:Fixing it for that single issue might help with that simple validating, but you'd still have several places where square brackets also occur...maybe that's not worth it, since picking on this issue is really TOO picky.

Well, let's put it this way – as far as I can see, most of the other occurences of square brackets are admin links, i.e. not visible to visitors but only to logged-in admin users. And yes, I do think it makes a difference in terms of endorsing s9y to the public if the emitted HTML is actually valid or not.

Then again, this is HTML5. It is still subject to change and will be for quite some time. There is an issue with the HTML code for the native audio player we use over at s9ycamp.info which I haven't even figured out yet. Like with the square brackets issue, the w3c validator is not exactly verbose on this. So let's just drop this for the time being and see what happens.

Something I'd still like to have, however, is proper category nesting, i.e. nested ul elements.

YL

yellowled wrote:

garvinhicking wrote:Fixing it for that single issue might help with that simple validating, but you'd still have several places where square brackets also occur...maybe that's not worth it, since picking on this issue is really TOO picky.

Well, let's put it this way – as far as I can see, most of the other occurences of square brackets are admin links, i.e. not visible to visitors but only to logged-in admin users. And yes, I do think it makes a difference in terms of endorsing s9y to the public if the emitted HTML is actually valid or not.

As I said before, the HTML5-Validator you are using, Matthias, is an experimental feature HTML5 Conformance Checker! I think the Authors will make square brackets in URLs be "valid" again, if you report it as being too strict and wish a change of this behaviour. The HTML4-Validator is not having this, is he?!

Timbalu wrote:I think the Authors will make square brackets in URLs be "valid" again, if you report it as being too strict and wish a change of this behaviour.

Yeah, well, I don't think so given the fact that they were not "legal" before. Nevermind.

YL

Yes nothing to ride on! What would be much more an interest is, gets the GET parameter automatically decoded to [] if you use the 5B/5E in template urls? Do our scripts respond to them?

BTW, I just remembered... If setting this template to >=1.6 only you can use as the new language includer by default, like in core plugins.