[Resolved] W3C Validation Error after Update

Home Forums Support W3C Validation Error after Update

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #1252469
    Maarten

    Dear support,

    Normally when my homepage or any page I made is done, I view source to get the HTML code then copy and paste that into the following tool:
    https://validator.w3.org/ and use the source option.

    9 out of 10 when it comes to WordPress I get the errors about not needing inline “type=” errors.

    I know this is not an error of GeneratePress but WordPress code – Yes, I have made a post for them about this now for 3 times and they keep saying they will fix it but that was last told me 6 months ago. I have no time now to make a new post about this issue, maybe some time later as Tom gave me code to put in functions to remove all type=”….” lines from all the source code. It does use buffers so it might slow down first site load (no idea) but it does remove the errors.

    When I run this code it will remove the errors and all HTML is 100% valid like it should be.

    But since the theme update I also check all CSS created by GP in this tool for CSS check, and after the last update of GP or maybe it is the latest GP Premium version, I get errors.

    Only 2 and some notices about not needed code for the browsers.

    I do all these tests on my own server with no traffic before I deploy my website just to make sure my site is running as good and clean as it could be.

    I know W3C is not that important for SEO but if one day it might be it would be nice to have someone look at the error.

    As I am not at home or able to make a screenshot I hope this info could help.

    Just open source and copy all data from – all.min.css from head block into W3C
    https://jigsaw.w3.org/css-validator/

    It also gives the error when I do this with the code from GP homepage.
    You can in the source code of your homepage just double click the mouse to have the whole line to CSS blue color and then press the middle mouse button to open this code in a new TAB. Then go to the next CSS line and do the same untill you get to <body> TAG. You do not need to check body, just the head-block that gets loaded before the body (hope this helps when someone like to check this as well)

    I have this even without GP Premium if I remember so could be in the code of GP theme.

    Hope this helps!

    Regards!

    #1253773
    Tom
    Lead Developer
    Lead Developer

    Hi there,

    The speak error is fixed in GP 2.5.0 – is that the one you’re noticing?

    Let me know πŸ™‚

    #1255528
    Maarten

    Hello Tom,

    Thanks for the reply. I made some screenshots that might help to show what I did.

    They should be in correct order and uploaded them.

    First image is the settings in GP that are activated fot the theme.
    Not upgraded to version 10 yet.

    001-gp-pre

    Link

    I have to check if this image is to big, if not I will post more or just paste the direct link

    Next is first found CSS code in Home selected

    002-1st-part

    Paste into CSS validator

    003-1st-part

    Result

    004-1st-part

    Link

    Next found CSS in Home selected

    005-2nd-part

    Paste into CSS validator

    006-2nd-part

    Result

    007-2nd-part

    Link

    Next found CSS (See URL) selected

    008-2nd-part

    Past into CSS validator

    009-2nd-part

    Result (See this CSS 100% perfect)

    010-2nd-part

    Link

    First found inline CSS in Home selected

    011-1st-inline

    Paste into CSS validator

    012-1st-inline

    Result (100% perfect)

    013-1st-inline

    Final found inline CSS in Home selected

    014-2nd-inline

    Paste into CSS validator

    015-2nd-inline

    Result (Again 100% perfect)

    016-2nd-inline

    Link

    Conclusion:

    So, it seems to be this URL and CSS giving the following result

    https://i.ibb.co/k5k3Lx1/002-1st-part.png
    https://i.ibb.co/tZcDBNL/004-1st-part.png

    And this URL CSS

    https://i.ibb.co/1bBVKXM/005-2nd-part.png
    https://i.ibb.co/GxXk086/007-2nd-part.png

    Hope this helps,

    Regards!

    #1255736
    Tom
    Lead Developer
    Lead Developer

    Hi there,

    Those “errors” are just because W3C doesn’t recognize those old vendor prefixes. Those are necessary for older browsers as of right now, but we will be able to remove them eventually when more people ditch older browsers.

    I agree it will be much cleaner once we’re able to ditch them.

    Thanks for the screenshots! Appreciate it πŸ™‚

    #1256827
    Maarten

    Ah thanks so also the first notice about: .load-more:not (.has-svg-icon) is just because of the browser.

    I think I have seen more theme generate the notices below the first one.

    But if this is normal and will be removed some time in the future that would be great of course.

    Thanks again for all your great work, love GeneratePress !!

    Regards!

    #1256990
    Tom
    Lead Developer
    Lead Developer

    The speak property needs to be updated – we’ll get that done in the next update.

    I’ll run the theme through these tests to clean up anything that might have made its way in since the last time we checked as well πŸ™‚

    Thanks!

    #1257075
    Maarten

    Thanks so much Tom.

    Could you also confirm if the following code for source HTML will not slow down Pagespeed because of using buffers, this is what I got from you to get rid off “type=” errors:

    /////////////////////////////////
    // Core
    /////////////////////////////////

    define( ‘remove_w3c_notices’, ‘yes’ );

    /////////////////////////////////
    // Begin
    /////////////////////////////////

    if ( remove_w3c_notices == ‘yes’ ) {
    function output_buffer_start() {
    ob_start( ‘output_callback’ );
    }
    add_action( ‘wp_loaded’, ‘output_buffer_start’ );
    function output_buffer_end() {
    if ( ob_get_contents() ) ob_end_flush();
    }
    add_action( ‘shutdown’, ‘output_buffer_end’ );
    function output_callback( $buffer ) {
    return preg_replace( “%[ ]type=[\’\”]text\/(javascript|css)[\’\”]%”, ”, $buffer );
    }
    }

    If this does have effect on speed, I will post an other post at WP to ask for a fix like I did last year.

    Have a great day.

    Regards!

    #1258129
    Tom
    Lead Developer
    Lead Developer

    Any sort of function will affect performance, especially something like preg_replace. However, benchmarks would have to be run to find out whether the difference is significant or not.

    #1260568
    Maarten

    Thanks Tom,

    Well, maybe because of page caching like WP Rocket or WP super cache it might after page load not be a big problem anymore as if I understand it correctly the code has ben converted to raw HTML after first page load.

    But yeah I have no other way than using preg_replace.

    I will post an new issue at WP to ask them to have a look at it again for a update but I still think caching could solve the performance hit after first page visit (hopefully)

    Thanks for your support!

    Regards.

    #1261514
    Tom
    Lead Developer
    Lead Developer
Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.