Google site editor does not support chrome.



  • While irretrievably signing my privacy away setting up google apps for my domain, i learned that their site editor doodah does not support* chrome. I guess user agent sniffing is to blame.

    Free Image Hosting by FreeImageHosting.net

     *It seems to work just fine tho.



  • Having specific support for something that's in a beta state and by definition liable to support breaking changes would be TRWTF, especially from the company behind BOTH. So, I'm not entirely sure what your problem is.



  • @Flatline said:

    Having specific support for something that's in a beta state and by definition liable to support breaking changes would be TRWTF, especially from the company behind BOTH. So, I'm not entirely sure what your problem is.
     

    That user-agent sniffing is a bad idea?

     If the page is standards compliant then it will display just fine in any compliant browser, no need to waste effort and make your site worse at the same time.



  • @Cursorkeys said:

    @Flatline said:

    Having specific support for something that's in a beta state and by definition liable to support breaking changes would be TRWTF, especially from the company behind BOTH. So, I'm not entirely sure what your problem is.
     

    That user-agent sniffing is a bad idea?

     If the page is standards compliant then it will display just fine in any compliant browser, no need to waste effort and make your site worse at the same time.

    UA sniffing is sometimes necessary to work around browser bugs.  That standards compliance will automatically make everything work perfectly is a ridiculous myth that people need to stop propagating.  The only WTF here is that Google didn't test their own browser beforehand and add it to the UA sniffing code.



  • @morbiuswilters said:

    The only WTF here is that Google didn't test their own browser beforehand and add it to the UA sniffing code.
    Which is still a pretty amusing WTF in its own right.



  • Hey, I'd never sniff another user's agent.  It's just not manly.

    It's more doggly.



  • @morbiuswilters said:

    That standards compliance will automatically make everything work perfectly is a
    ridiculous myth that people need to [b]make real[/b].

    FTFY, because the idea is surely great?



  •  @morbiuswilters said:

    UA sniffing is sometimes necessary to work around browser bugs.  That standards compliance will automatically make everything work perfectly is a ridiculous myth that people need to stop propagating.  The only WTF here is that Google didn't test their own browser beforehand and add it to the UA sniffing code.

    Real purpose of standards compliance: passing the buck. "You're right, my page looks like a flaming pile of crap in X browser. But X browser doesn't support <table>'s correctly! How am I supposed to do good work when I have to listen to other people's standards as well as my own?!"



  • @Spectre said:

    @morbiuswilters said:
    That standards compliance will automatically make everything work perfectly is a ridiculous myth that people need to make real.

    FTFY, because the idea is surely great?

    In a broad sense, standards are great.  But no single product will ever adhere to a standard just right.  And, now, the idea is not surely great.  Advancements are made because people are willing to try things that haven't been done before.  If all progress is to come from a central authority, then we end up with...  well, Russia (and you should know how that ends).  So standards have their place, but appealing to standards when something doesn't work in the real world is just a shitty way of shirking responsiblity.



  • @morbiuswilters said:

    But no single product will ever adhere to a standard just right.

    I'm pretty sure I could make a decent implementation of [url=http://tools.ietf.org/html/rfc863]RFC 863[/url]...

    @morbiuswilters said:

    Advancements are made because people are willing to try things that haven't been
    done before.

    Sure. But there's an ample difference between sets { not done before } and { stuff making the implementation non-compliant }. Good standards are usually extensible.

    @morbiuswilters said:

    appealing to standards when something doesn't work in the real world is
    just a shitty way of shirking responsiblity.

    I like it!



  • @Spectre said:

    I'm pretty sure I could make a decent implementation of RFC 863...

    I tried but my daemon kept saving all the data to a text file..  D:

     

    @Spectre said:

    Sure. But there's an ample difference between sets { not done before } and { stuff making the implementation non-compliant }. Good standards are usually extensible.

    But then if some people take advantage of it, you end up with the standards-compliance people screaming about it.  I'm not saying standards aren't good to have, but they do not represent reality.  Appealing to the standard to justify the browser-specific problems with your code doesn't make that code work any better.  And saying you will not support a large portion of the market because they are not "standards-compliant" is just stupid, especially when those users form a de facto standard.

     

    @Spectre said:

    @morbiuswilters said:
    appealing to standards when something doesn't work in the real world is just a shitty way of shirking responsiblity.

    I like it!

    Have you considered a job with the W3C?


Log in to reply