WordPress.org

Ready to get started?Download WordPress

Forums

Make WordPress Hands-Off on the HTML View (10 posts)

  1. mobpolitics
    Member
    Posted 3 years ago #

    I started using WordPress as a CMS in 2007.. Back then, I would do things as simple as adding a couple of (admittedly bad markup) br's in the HTML view, and WordPress would magically remove them for me when it was updated.

    Today, with the newest version of WordPress, I ran into a situation where WordPress is STILL editing the HTML for me.

    It is my belief that, when I click on the HTML tab, I can do whatever I want.. I don't want WordPress to modify that at all. For a simple GUI experience, the Visual View is fine. If I click to HTML, I want complete control.

    WordPress, Please, Please stop messing with the HTML view. Even if I put 10 br's in there, PHP code.. whatever.. I want it left alone, and I think many users would agree with me. The HTML view should have a completely "under the hood" paradigm.

  2. Rev. Voodoo
    Volunteer Moderator
    Posted 3 years ago #

    this may be the tenth post on this today, and I've read many before.

    It is what it is. They are working on a new one for the future.

    Until then, use proper markup
    <div style="clear:both;"></div> or <br style="clear:both;" />

  3. mobpolitics
    Member
    Posted 3 years ago #

    One thing clients consistently want to do is have a thumbnail image floating left, maybe 100px x 100px, with a title beside it, and have several of those in a row.

    It would be so much simpler if they could simply hit Return a few times and the br / 's get inserted without having to go crazy trying to figure out a way to make it happen with CSS.

    As soon as you have to tell your client to just "flip over to the html view and start writing this <div style= or <div class=", or click the image, go to advanced settings, and add this class.. they're asking you why content management systems are so hard to use.

    If there have been 10 posts about this today, that's all well.. Coding WordPress to not auto-revise your HTML for you is frustratingly simple UX.. along with letting the system insert br /s when you hit return multiple times. If it won't do the latter, then for god's sake let us go to HTML view and put <br /><br /><br /> without it vanishing into lala land.

  4. esmi
    Forum Moderator
    Posted 3 years ago #

    So create a theme with custom templates, custom fields or custom post types that handle this kind of thing automagically. Using markup to position page elements is just plain wrong.

  5. mobpolitics
    Member
    Posted 3 years ago #

    So you're fine with WordPress automatically making decisions for you as to what you should and should not put in the HTML view?

  6. esmi
    Forum Moderator
    Posted 3 years ago #

    I don't have a problem with the HTML tab and can pretty much use whatever markup I want. But then I rarely (if ever) switch to the Visual tab.

  7. mobpolitics
    Member
    Posted 3 years ago #

    I prefer it too, but clients expect that they'll be able to use visual view when using the CMS.

    I agree with you as far as best practice is to "create a theme with custom templates, custom fields or custom post types that handle this kind of thing automagically," and that "Using markup to position page elements is just plain wrong."

    The issue here is that you can easily run into a situation, like I did, where someone is making a blog post long after the project is closed, and you can't then go and spend your entire afternoon modifying your structure, css, template etc, to facilitate that.. If you put a few breaks after a line and solve the problem in 2 minutes, Tim Berners-Lee isn't going to kick down your door in the middle of the night lol.

    If I'm in a highly GUI'd environment, like MS Word, I expect it will auto-correct me typing "abuot" into "about." However, if I'm in the command line of Linux, and I misspell a command, I want it to fail, not auto-correct me. I think it is a bottom line to have complete control in the HTML view.. And if I fail w3c validation by doing something I shouldn't, that's my choice.

    That said, if I put 3 <br />s in a row in the HTML view, they are still disappearing. I remember reading about that issue in 2007. I would say that, before any more bells or whistles are added, the HTML view needs to be given completely to the user.

  8. Mark / t31os
    Moderator
    Posted 3 years ago #

    TIP: If you give the linebreaks a class they won't disappear when switching between tabs..

    Example:

    <br class="clear" />
  9. vatuma
    Member
    Posted 3 years ago #

    I agree with mobpolitics.
    The workarounds given by Mark and Voodoo do work but this is not right to let the system change human's decisions... And brs is not the only problem. I had a lot of problems with that when tried to make a complicated html mark-up.

  10. Gary
    Member
    Posted 3 years ago #

    Another example of problems...

    I was editing a page last night and specifically wanted two 'definition' lists - not the more common ordered/unordered lists provided by the visual editor. No problem - I produced what I wanted in the HTML editor. Everything rendered fine when previewed. The list was tweaked and reviewed several times more and everything remained laid out as I originally typed it, making the ongoing editing process easy.

    Then, a little later on, I swapped into the visual editor and then back to the html editor. Now, everything in my lists had been collapsed into single paragraphs/blocks of text. They still functioned when previewed, but the page will be a bitch to edit if/when I return to extend them in the future.

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.