Make WordPress Core

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • lessbloat 5:26 pm on February 8, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Menus Office Hours (Feb 7) 

    Here’s a recap of yesterdays office hours.

    Work accomplished since last office hours

    Major items discussed

    1) Theme locations continues to be our biggest design challenge. We discussed a bunch of options and decided to go with checkboxes for theme locations for now – while we continue to stew on alternative approaches.

    2) We discussed having settings at the top or the bottom, and settled on them being on the bottom.

    On the docket

    • Refactor accordion code (@lessbloat)
    • Re-assess CSS in latest patch (currently 23119.28.1.diff), and move colors to colors.css (Looking for a volunteer here)
    • Browser compat testing (Looking for a volunteer here)
    • No JS testing (Looking for a volunteer here)
    • Code review (Looking for volunteers here – hopefully from multiple people)
    • Commit what we’ve got

    After that

    • Any additional accessibility work
    • Additional code refactoring
    • Am I missing anything?

    p.s. @DrewAPicture, I added a title this time just for you. ;-)

     

    • Drew Jaynes (DrewAPicture) 5:57 pm on February 8, 2013 Permalink | Log in to Reply

      RE: title, “He can be taught!”

      We also need to do an extensive round of RTL testing as well as completing docblocks for any new functions we’re introducing, @access private or not.

      I can start on no-js testing this weekend.

      • lessbloat 6:05 pm on February 8, 2013 Permalink | Log in to Reply

        I did a round of RTl testing/fixing (I’m not sure I would call it extensive, but I think I caught most everything).

        I can start on no-js testing this weekend.

        Awesome! Thanks for that.

    • sireneweb 4:50 pm on February 11, 2013 Permalink | Log in to Reply

      Hi, very nice :)
      When you use Mega drop down menu, you can’t delete all children from main menu. It would be great if we can Expand/Collaspe main menu and delete all children sub menu from main menu

      • lessbloat 6:14 pm on February 11, 2013 Permalink | Log in to Reply

        I asked @jkudish to gather some data around avg number of menu items per menu for sites on WP.com. Out of 1000 random sites (with at least one menu added), here’s what the distribution looked like:

        Excluding the menus with zero items added, the average comes out to 5.

        So, based on this data, should we make some sort of expand/collaspe menu item functionality a part of core, or keep it in plugin territory?

        I think my preference would be to keep it as a plugin, but I’d love to hear everyones thoughts.

  • Daniel Bachhuber 1:52 am on February 8, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Editorial Flow Update, 2/7 

    Editorial flow is making progress and hitting interesting questions to answer. Our two primary tickets right now are #12706 and #23314.

    For the first, we’re waiting on feedback on the approach from @nacin. Once we’ve gotten confirmation it’s the right direction, I’ll continue working to make the patch commit-ready.

    For the second, the biggest question was how we should handle revisions for post meta and taxonomy terms. In the interest of getting to a committable patch, we’ll be dropping post meta / custom taxonomy support in favor of just being able to stage edits for the title and body content. Furthermore we’ve decided it would be worthwhile to add a new post type property so this functionality is opt-in. Posts and Pages in core will receive this by default.

    Our primary goals are to have commit-ready patches for both tickets by the beginning of next week. Konstantin’s secondary goal is to chat with @westi and @ethitter and see whether revisions for post meta is within scope for 3.6. My secondary goal is to go through other editorial flow tickets and touch base with where each is at.

    Next office hours are Tuesday, February 12th at 10 am PT / 1 pm ET / 1800 UTC.

    Office hour log

     

    • Jon Brown 2:12 am on February 8, 2013 Permalink | Log in to Reply

      Initially I was disheartened that you guys were dropping metadata support, but read the irclogs and it makes sense and I’m glad their are still advocates for adding it back in later.

      All of which I share only to say, THANK YOU, for such an open and transparent process. Really all the teams are doing a fabulous job and all the communication is hugely appreciated, so thank you for that and all the great work.

    • Erick Hitter 2:21 am on February 8, 2013 Permalink | Log in to Reply

      Tuesday office hours conflict (for me) with the WordCamp Base Theme chat, so I’ll note here that meta revisions are not in scope for 3.6.

      While the relevant tickets (#20564 and #20299) marked as 3.6, we’ve spent a good deal of time on UI/UX, and that will likely continue to be the bulk of our focus for this iteration. @nacin marked both as 3.6 because they block #23314, but we (@westi, @adamsilverstein, @karmatosed, and I) don’t have the availability to address them at this time.

  • Erick Hitter 4:39 pm on February 7, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Revisions Update, 2/7 

    We started today’s office hours by reviewing @karmatosed’s latest mockups for the revisions screen. We’re in agreement that these reflect the direction we’ll take, so @adamsilverstein will begin coding the changes in preparation for Monday’s meeting. As some concerns have been raised about the use of red and green, @karmatosed will post to the Accessibility group’s P2 asking for feedback on the current mockups. She will also explore the use of patterns to differentiate additions and deletions, as suggested by @helen.

    @westi made a few suggestions, based on his recent experiences with Revisions, which we’ve agreed to incorporate. For clarity, the current version will be included in the revisions list to provide a stronger connection with the overall revisions workflow. Second, we decided that when first landing on the revision screen for a given post, we should show the diff of the current version and its immediate predecessor revision; since most users are probably looking for this anyway, why not save them a step?

    Lastly, we chatted about the status of code-oriented tickets scoped for 3.6. A few (#16215, #22289, and #19932) have patches, which we’ll be reviewing and providing feedback on before Monday’s meeting. With any luck, we can land at least one in Core before the next dev chat. Beyond that, development on the remaining tickets should progress over the weekend, with the aim of having more patches to review for our next office hours.

    For reference, the tickets that are in scope for 3.6 (at least at this point), can be found here.

    [IRC Log]

     

  • Sergey Biryukov 11:14 pm on February 6, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Ticket Scrub 

    We’ll have a patch clearing session in IRC on Friday, February 8 at 11AM Eastern/1600 UTC, for two hours. Let’s aim to go through the commit candidates and resolve some of the other tickets currently slated for 3.6.

     

  • Erick Hitter 7:43 pm on February 5, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Revisions Update, 2/5 

    Yesterday’s meeting focused on revisions to the revisions interface :) . @lessbloat joined us to ask some great questions, and helped refocus the UI changes that have been proposed and mocked up so far. We started off by trying to identify the major uses of revisions, and settled on two primary cases: undoing mistakes by finding the last correct revisions, and reviewing changes as part of an editorial workflow.

    In light of those focuses, we’ve decided to revisit the UI mockups we’ve (namely, @karmatosed and @adamsilverstein) worked on so far. The general consensus is that they’ve become overly complicated, and led to feature creep (looking at you, line-by-line accept/reject capabilities). @karmatosed is working on some new mockups for Thursday’s office hours. One possible source of inspiration may be @benbalter’s post forking plugin.

    On the code side, @mdawaffe worked out a pretty comprehensive patch for the display of incorrect authors on revisions (#16215). We’ll be reviewing that, along with the patches added to the other tickets we’ve scoped for 3.6. As was the case when I last posted, progress is slow at this point due to travel and the ongoing UI discussions.

    [IRC log]

     

    • adamsilverstein 8:47 pm on February 5, 2013 Permalink | Log in to Reply

      i posted patches for testing that implement some of the mockup concepts we talked about during our meeting here – #23396

    • karmatosed 2:56 pm on February 7, 2013 Permalink | Log in to Reply

      I’ve got some more mockups for discussion in the meeting today here:

      I spent some time with @benbalter’s plugin and merged that with some of the ideas that seemed ‘easy wins’ from a UI view. It’s mainly a tidy up in a lot of respects. I did one with notes but understand this feature probably will not be included – I just wanted to see what it looked like.

      I felt the picking in the post forking plugin worked well for that instance but may be overly complicating for us as the ‘new’ would always be the newer version so that’s what I was keeping to by you just picking 2. I didn’t add a submit or confirm as figured if you picked 2 it could reload – we may want to reconsider this as perhaps a pause through clicking something could be useful.

  • Helen Hou-Sandi 3:51 am on February 5, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Post Formats UI Update, 2/4 

    Not a whole lot to discuss today – working away at patches on #19570 (edit form UI) and #23347 (theme compat). Could use a patch on #15490 (retrieval of oEmbed data and previewing, which I suspect will become relevant to the edit form UI) and testing of #23282 (audio/video shortcode and player) and #16047 (list table column).

     

  • Peter Westwood 11:16 am on February 4, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Revisions Update(s) for Last Week 

    These are combined and late (sorry).

    Last week we had two successful Office Hours discussions:

    We discussed the different mockups that both @adamsilverstein and @karmatosed have been working on with the discussions in the first meeting leading to some new mockups here: http://make.wordpress.org/core/2013/01/25/revision-update-125/#comment-7869

    And then @karmatosed created some further mockups after our second meeting bringing together our feedback and the different idea threads:

    Outside of the meetings our progress has been slow because most of us have been travelling for conferences / meetups

    Our next office hours are today at 1600 UTC

     

    • John Saddington 2:09 pm on February 4, 2013 Permalink | Log in to Reply

      Just curious… are you guys using mockingbird mockup app for these? looks great!

    • Robert Chapin (miqrogroove) 7:42 pm on February 4, 2013 Permalink | Log in to Reply

      What’s the difference between Apply and Discard? Apply to what? Discard from where? What does it mean to discard a removal? I think this needs to be more verbose or more intuitive like Undo and Redo.

    • lessbloat 10:20 pm on February 4, 2013 Permalink | Log in to Reply

      I played around with an alternate concept this afternoon.

      My assumptions

      There are two major use cases:

      A) Undo a mistake I made

      B) Review changes & find mistakes other people have made

      With the major use cases in mind, here are the problems I see with the existing UI:

      1) With just a date/time stamp and author, there is no way to tell (at-a-glance) what revision you’re after from the post edit page, requiring you to click into revisions.

      2) Once you click a link from the post edit page, you are taken to a complete revision (without any comparison showing). This seems backwards to me. Seems like you should be taken to the comparison view by default. As you are oftentimes looking for mistakes, which are much harder to spot in the “complete revision” view.

      3) The “Revisions” table at the bottom is super confusing. :-)

      4) It’s hard once on the revisions page to quickly move through additional revision sets.

      My rough proposal

      With those use cases and existing UI problems in mind, here’s what I came up with:

      Post edit page

      On the post edit page show more details related to each revision (base them off of comparisons with previous revisions):

      Or perhaps:

      Which adds:

      • gravatar (optional)
      • words removed
      • words added
      • total words (after add/removed)

      Revisions page

      Start off in comparison view:

      • Default to comparison view
      • Assume that the user wants to diff against the previous revision. We could add the advanced diff table selection option (with the radios) back in as either a screen option, or boot it to a plugin (it really is painful to use).
      • Allow them to quickly paginate through all revisions (“View Previous” button)
      • Give them a sense of which revision this is (out of all of them) with the black/gray dots at the top.
      • Change the paradigm from “older” “newer” to “removed” always on the left, and “added” always on the right.

      If you mouse over the black/gray icons, more info would show up in a tooltip:

      Then if you clicked the “View previous” button you’d see:

      Anyhoo… It’s still super rough, but I thought I’d through the concept out there.

    • adamsilverstein 5:03 pm on February 5, 2013 Permalink | Log in to Reply

      thanks for the new mockups!

      before reading your post, i created a ticket and posed patches that implement some of the mockup concepts we had talked about during office hours – #23396

      a few responses -

      i really like the idea of entering the revision screen already comparing to the previous revision, i never understood why we have the extra option of viewing a revision by itself.

      i still don’t understand the meta box on the post page, even if you can pinpoint the revision you want, which is doubtful, you still have to click into the revisions page to restore the revision. for this reason, and because of use case A, i think a link into the revisions interface belongs near the publish button, see #23352. i would just leave the meta box as is (hidden) and focus on the actual revisions page.

      i really like the next/back idea, especially if we can get the view refreshing without page reloads. this will make it easy to go back to find the exact revision a user needs.

      the little dot idea with popups, while nifty, is not really accessible. what do you think of the idea of a left column showing the list of revisions? ideally, i’d like to see these grouped when there are more than a certain number, either by user or by hour; otherwise the list becomes unwieldy on posts with many edits.

      i’m not sure i get the paradigm of removed on one side and added on the other, how will the user know what the post will look like when the restore the revision? willing to try, but i think i prefer the direction of a combined diff view with labels down the edge.

    • Midhun Devasia 7:37 pm on February 6, 2013 Permalink | Log in to Reply

      I had an idea about the revision change updates.

      What I’m thinking is that, when a user want to find what was changed
      1. Show the last changes in Revision meta box.
      2. And it should show the “Inline Diff” between last version and its previous version. (Comparing Side by Side or left right methods are more complex for normal users, I think they prefer Stoked text, wth color changes of what they deleted and what they added from the last change or revision )
      3. The revision meta should show the abbreviation of Big changes.
      4. If he is still can’t idenftify the changes he can link to the revision management page.
      5. Show atleast 10-20 revisions on the Revision Metabox, or else pagination/link to revision management page.

      The Above points are only for Revision Meta box as considered as Quick Reference of the revisions/changes what they made. can give restore link there too, if he find that was his revision.

      I had submitted a rough working patch for the above Inline diff method.

      Check my ticket.

      http://core.trac.wordpress.org/attachment/ticket/18733/wp_revision_meta_.png
      http://core.trac.wordpress.org/attachment/ticket/18733/2Screen1.png

      http://core.trac.wordpress.org/ticket/18733

      Patch
      http://core.trac.wordpress.org/attachment/ticket/18733/Qucik%20Revision.patch

    • esmi 7:50 pm on February 6, 2013 Permalink | Log in to Reply

      Still rather concerned about the colours being used here — both in the original screenshots & @lessbloats alternative concept screenshots. Can we look at using colours other than red & green? Red/green is the most common form of colour blindness, so this could potentially impact on 10% of all make users. See http://quirm.net/temp/revisions-cb2.jpg for an example of how the original screenshot would look to a user with red/green colour blindness.

      I’ve also analysed the foreground/background contrast on both the red & green test. Both fail the recommended 4.5:1 contrasts ratio. The red is 4.3:1 whilst the green only manages a really miserable 2.8:1. Anything below the recommended 4.5:1 ratio will hit visually impaired users (not all of whom use screen reading software) and about 50% of dyslexics.

      • Peter Westwood 9:12 am on February 7, 2013 Permalink | Log in to Reply

        Your concern is noted and not forgotten, our mockups have focused on the layout of the page and I want to try different colours once we have something implemented so as to address the accessibility issues.

  • Mike Schroder 10:47 pm on February 2, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Autosave and Post Locking Update 2/2 

    A quick update on status!

    Earlier this week, the initial run at the Heartbeat API went in. @azaozz is continuing to work on it, and flesh out the API further ( #23216 ).

    Tonight, the initial post lock view for the post listing was committed [23355] along with a temporary icon:
    new_lock

    I took a look over an older version of the NYT plugin kindly contributed on #18515.
    For discussion, I’m including a few examples of the UI/UX from the workflow included in it below.
    We don’t necessarily think everything here is a good idea for core (for instance, the “get me out” buttons wouldn’t be necessary), and will likely go a different route for UI, but hoping to get a bit of discussion going regarding the UI/UX flow for the project.

    Lock table:
    nyt_lock

    Lock table user mouseover:
    nyt_lock_notice

    Popup for lock within Post Editor:
    nyt_lock_popup

     

    • Ipstenu (Mika Epstein) 7:44 am on February 3, 2013 Permalink | Log in to Reply

      The first icon goes better with the new icon sets that’ve been worked on. Don’t forget to loop back to that group ;)

      What user levels can break locks? Is it hierarchical so Admins can break anyone’s locks, but Editors can break admins and so on down the line?

      The alert boxes greying out the screen behind is good, that reinforces ‘Hey! Someone’s in here!’ You could use that extra space to have something like …

      Warning: POSTTITLE is locked

      Other Person is currently editing this post.

      You can view the post as read only, exit out, or unlock the post and take over. If you chose to break the lock, their edits will be lost(?).

    • Alex 8:13 am on February 3, 2013 Permalink | Log in to Reply

      Why not open the edit screen as read-only directly? Greyed out with a warning on the top of the page which contains the “request” and “force” buttons. Content refreshes every 15 seconds and you directly see what the other is working on. Less buttons, less clutter.

      • Mike Schroder 6:44 pm on February 4, 2013 Permalink | Log in to Reply

        Read-only on edit is what we’d initially chatted about, so I’m glad to see you agree! I really like the idea of having the warning within something similar to the current warnings, only with “request” buttons there. Do you think it’s important to be able to force immediately, or only allow that after you’ve requested, and don’t immediately get feedback?

        • Ipstenu (Mika Epstein) 7:19 pm on February 4, 2013 Permalink | Log in to Reply

          I think… people don’t RTFM enough. A splash is annoying, but less likely to miss (never underestimate the ability of people to click on something without reading).

          • Alex 9:49 pm on February 4, 2013 Permalink | Log in to Reply

            Grey everything out and set the input fields to read only. Then refresh them all 15 seconds with auto-save changes from the current editor.

            @Mike Schroder: I think a button to force-get the right for editing would be necessary for people with a higher role. Still, the user currently editing would need to get a warning and a countdown for deciding to save or discard his work.

    • Alex 8:17 am on February 3, 2013 Permalink | Log in to Reply

      And is it already planned to add a “x people are watching you editing this post” notification?

    • Andrew Ozz 6:25 pm on February 4, 2013 Permalink | Log in to Reply

      Yes, we can use a modal to block access to the Edit Post screen when opening a locked post and show a “preview” of the latest content entered by the other user. In that modal we won’t need the “Read Only” button from the above screenshot and the “Get Me Out” would be “Return to [previous page]” or “Go to All Posts”.

      The “Unlock” could be “Request to edit” or “Request the lock” which will pop up a notification on the other user’s screen letting them finish what they are doing and save or perhaps refuse to give up the lock.

      Instead of a modal, this can also be a whole different screen. Then after the lock is transferred, the user will be able to load the post for editing. This way we will be loading everything fresh from the server.

    • Sam Parsons 5:04 pm on February 5, 2013 Permalink | Log in to Reply

      I know this maybe off-topic, but the whole idea of the hearbeat API and even perhaps showing updates from a locked post to an editor who is about to acquire a lock makes me think about perhaps making it a full collaborative editor? Why not go that far? It seems we’re already getting close. It’s a matter of sending/receiving diffs on the long-polling method which was discussed earlier.

  • lessbloat 4:41 pm on February 1, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    We had a great discussion yesterday during office hours. I’m excited to say that we’ve found our direction.

    We’ll only be focusing on changes to nav-menus.php for now.

    I just posted an updated diff containing some of the ideas we discussed.

    Remaining Tasks (already assigned to someone)

    • Test theme locations as checkboxes (@jkudish volunteered to code this up). Note: we decided to leave widgets as checkboxes out.
    • Menu selection dropdown should show location(s) it is used in (@DrewAPicture offered to tackle this)
    • A round of user tests on 23119.23.diff, plus additional testing once “theme locations as checkboxes” and the accordion code is ready
    • Updated copy for help tabs (both manage, and add/edit screen) (@DrewAPicture will oversee this)
    • Updated copy for ​http://codex.wordpress.org/WordPress_Menu_User_Guide (@DrewAPicture will oversee this)
    • Updated copy for ​http://codex.wordpress.org/Appearance_Menus_Screen (@DrewAPicture will oversee this)

    Remaining Tasks (still needing a volunteer)

    • Code up menu item boxes as an accordion for us to test (similar in style to customizer).
    • Code reviews (multiple people please :-) )
    • RTL testing
    • Browser compatibility testing
    • No JS testing

    Comment below if you’re interested in helping out. Thanks!

     

    • Joey Kudish 4:46 pm on February 1, 2013 Permalink | Log in to Reply

      In addition to the checkboxes, I’ll help out with code reviewing and all the testing :)

    • Jon Brown 5:53 pm on February 1, 2013 Permalink | Log in to Reply

      I agree that the checkboxes shouldn’t be there for widgets, that’s be very confusing IMHO. However, maybe there should be a little tool tip or note below theme locations directing users that “Menus can also be added tomwidget areas via the custom menu widget available on the widget settings page”.

    • Travis Northcutt 12:18 am on February 2, 2013 Permalink | Log in to Reply

      @lessbloat, what is the “deadline” for getting the accordion done for testing?

      • lessbloat 1:14 pm on February 4, 2013 Permalink | Log in to Reply

        I’d like to wrap up all dev for this feature ASAP. I’ll likely pick it up if no one else grabs it by tomorrow.

  • Helen Hou-Sandi 5:32 am on February 1, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Post Formats UI Update, 1/31 

    Had really good conversations in Wednesday’s dev chat and continued in today’s office hours. Seems like we’ve got a really good direction. All the UI will be available all the time and theme support for individual formats will shift to serving as a flag for whether or not the theme handles format-specific data for display. If a format is not explicitly supported by the theme, there should be simple, semantic fallback output that can be hooked on to the_content. This allows the admin UI to stay consistent and able to offer data fields that don’t just disappear into nothingness, and themes can actually support post formats with just styling rather than handling format-specific data themselves.

    @beaulebens is working on the fallback output on #23347, and @sabreuse is joining @rachelbaker to work on the edit form and switcher on #19570. @melchoyce has updated wireframes she’ll be linking to in a comment here. TBD: no-JS treatment, will also need to be keeping an eye on accessibility.

    Also, user testing was done with core as-is, and I’ve got videos to watch and analyze for post formats using Crowd Favorite’s UI and fallback code. These are extremely revealing and are really helping us identify pain points as well as setting a baseline for measuring any improvements we hope to make.

     

    • Erlend Sogge Heggen 7:44 am on February 1, 2013 Permalink | Log in to Reply

      Will the post formats update include any work towards making post formats more usable via the front-end? I really love the idea of bbPress being able to use post formats to distinguish between normal posts and support posts for instance, as well as its own take on link posts and so forth.

      • Beau Lebens 2:14 pm on February 1, 2013 Permalink | Log in to Reply

        The list of core-supported post formats will be (currently):

        • Standard
        • Status
        • Quote
        • Aside
        • Link
        • Chat
        • Image
        • Video
        • Audio
        • Gallery

        There are no plans to allow plugins/themes to modify that list

        • Erlend Sogge Heggen 5:02 am on February 4, 2013 Permalink | Log in to Reply

          So I suppose that means we won’t be able to easily create a post format like, say, “Forum Link” to mimic the Facebook style link posts with autoembedding? Too bad, I was really excited about the possibilities there.

          • Helen Hou-Sandi 9:35 am on February 4, 2013 Permalink | Log in to Reply

            Post formats already exists as an enumerated list and that will not be changing. In your cited example, not sure why a “Link” format post wouldn’t work.

    • Mel Choyce 12:21 pm on February 1, 2013 Permalink | Log in to Reply

      Updated wireframes: http://cl.ly/0p260s3U0L3p

    • Justin Tadlock 12:33 am on February 2, 2013 Permalink | Log in to Reply

      As a user, I hope there’ll be an easy way (via plugin if need be) to continue using things like post titles for “asides” since this is the way I’ve been doing them for the past 6+ years. Some people use titles and some people don’t. Personally, I like to have the title shown on the singular view.

      As a theme developer, I just want to ask that we make it easy to open any hidden fields back up without having to jump through hoops to do it, especially for those of us who have been using those fields in our themes. A simple filter hook or something like that would do it.

      • Helen Hou-Sandi 12:54 am on February 2, 2013 Permalink | Log in to Reply

        One of the things I’ve been thinking about suggesting (hadn’t gotten there yet) was that title always be editable, even if for some formats it’s more buried.

        Can you elaborate on what you mean by hidden fields?

        • Justin Tadlock 5:58 am on February 2, 2013 Permalink | Log in to Reply

          Any hidden fields that represent normal post_fieldname data such as the title field. I’m not sure if there are any others, but the title is the biggie.

          I definitely agree that the title should always be editable, especially because it’s the <title> element on a page and is what’s used to populate the permalink field. I like the wireframe of the chat format where it says “Chat Title (optional)”. I think that’d be a good use for the aside and status formats too.

    • Synapticism 10:57 pm on February 2, 2013 Permalink | Log in to Reply

      I was mucking about with the quote post format on my personal blog and ended up writing some thoughts about usage that may be of interest to the team. Here are the links:

      http://synapticism.com/working-with-wordpress-post-formats-and-quotations/
      http://synapticism.com/marking-up-quotations-with-html5/

      My main point: adding a third field, “source title”, to the quote post format will encourage HTML5 best practices.

      I’m no expert in these things so there might be something really terrible about this idea that I wouldn’t have thought of :)

← Older posts

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel