[wp-trac] [WordPress Trac] #23347: Theme fallbacks for post format meta data
WordPress Trac
noreply at wordpress.org
Thu Jan 31 23:23:37 UTC 2013
#23347: Theme fallbacks for post format meta data
--------------------------+------------------
Reporter: helen | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: 3.6
Component: Template | Version:
Severity: normal | Resolution:
Keywords: |
--------------------------+------------------
Comment (by beaulebens):
Apologies, it's long :)
'''Goals/Constraints'''
* Minimal markup/design/layout
* Maximum (correct) semantics
* If we can't do something valid, at least don't do something explicitly
invalid
* Use all data elements from the UI (below)
* Present them in the "most expected/obvious" way
* Take into account "normal" CSS applied to HTML tags
* Must be backwards (pre-HTML5) compatible, and forwards (HTML5+)
compatible
* Informed by Best Practices and Common Usage, erring towards Best
Practices
'''Post Formats Data Fields/UI''' -- note I made up meta key names to
demonstrate consistency, those are not final
Standard (current post editor)
post_title[[BR]]
post_content
Status: http://cl.ly/image/170O1N0L062U/o
post_content
Quote: http://cl.ly/image/1V0h3O211K2T/o
post_content (Quote)[[BR]]
meta: _format_source[[BR]]
meta: _format_commentary (?)
Aside: http://cl.ly/image/3v3T3b3L2s1o/o
post_content[[BR]]
Link: http://cl.ly/image/2l213j3i2625/o
meta: _format_url[[BR]]
post_title[[BR]]
post_content (Description)[[BR]]
Chat: http://cl.ly/image/3Y2n0N153x3g/o
post_title[[BR]]
post_content (Transcript)[[BR]]
Image: http://cl.ly/image/2X0S2u2f053c/o
post_title[[BR]]
post_content (Caption)[[BR]]
meta: _format_url[[BR]]
Video: http://cl.ly/image/3J2v2v0j0o37/o
post_title[[BR]]
post_content (Description)[[BR]]
meta: _format_url[[BR]]
Audio: http://cl.ly/image/2a0c0y3z3v3i/o
post_title[[BR]]
post_content (Description)[[BR]]
meta: _format_url[[BR]]
Gallery: http://cl.ly/image/032J3l2w1t10/o
post_title[[BR]]
post_content (Description)
'''Post Formats Default HTML Output'''
''Standard''
Title
{$post_title}
Content
{$post_content}
''Status + Aside (identical treatment)''
Title
'' (empty string)
Content
{$post_content}
Discussion
We don't ask the user for a title, so we shouldn't
display one, but we *should* generate one based on the first x
characters/words of the post_content, for use in wp-admin. When rendering,
don't rely on a comparison (in case content changes); check format which
is instructive on how to handle the title.
''Quote''
Title
'' (empty string)
Content
{{{
<div class="format-quote-quotation">
<blockquote cite="{$url}">{$post_content}</blockquote>
<div class="format-quote-source">{$_format_source}</div>
</div> . "\n\n"
{$_format_commentary}
}}}
Discussion
Blockquotes are basically a semantic disaster :)
There does not appear to be a currently-agreed-upon solution which is
compatible with HTML<5 and which handles sourcing a quote that is anything
other than just a URL. <cite> is used commonly, but it presents a number
of problems, specifically around the changes from pre HTML5 into HTML5. In
short, we can't use it reliably without creating invalid markup somewhere.
Since we don't ask for a title, don't output one. Generate one for the
admin (based on the quote/post_content). The above recommendation is based
on common usage patterns, combined with accurate-as-possible semantic
usage, plus a desire to have information visually accessible without
special CSS allowances. The source/citation is outside the <blockquote>
because the HTML5 spec explicitly states "Attribution for the quotation,
if any, must be placed outside the blockquote element.". If we put the
citation inside the <blockquote>, it'd increase "compatibility" with
existing CSS (positioning, styling etc). In this case we would extract the
first URL (if available) from post_content and use that in the cite=""
attrib (could also be stored in _format_url?). Note that it's totally fine
for $post_content to contain other block-level elements. Note the
recommended method in the HTML5 spec is now to use a figure > blockquote +
figcaption grouping for citation. See also http://alistapart.com/blog/post
/more-thoughts-about-blockquotes-than-are-strictly-required and
http://html5doctor.com/blockquote-q-cite/
''Link''
Title
{$post_title}
Content
{{{
{$post_content} . "\n\n"
<p class="format-link-url"><a href="{$_format_url}">{$post_title}</a></p>
}}}
Discussion
Content, linked title in a new paragraph after
that. I opted to append rather than prepend the link to post_content,
since most themes display post_title before the content, so in that case
you'd end up with the post_title effectively duplicated. I think most
themes that choose to handle this themselves will make the link on the
post_title (main/biggest link) go to the external URL.
''Chat''
Title
{$post_title}
Content Alternative 1
{{{
<dl class="format-chat-transcript">
<dt>timestamp/name</dt>
<dd>message</dd>
<dt>timestamp/name</dt>
<dd>message</dd>
...
</dl>
}}}
Content Alternative 2
{{{
<ol class="format-chat-transcript">
<li><strong>timestamp/name</strong>: <span class="format-chat-
message">message</span></li>
<li><strong>timestamp/name</strong>: <span class="format-chat-
message">message</span></li>
<li><strong>timestamp/name</strong>: <span class="format-chat-
message">message</span></li>
...
</ol>
}}}
Content Alternative 3
{{{
<div class="format-chat-transcript">
<div>
<strong>timestamp/name</strong>: <span class="format-chat-
message">message</span>
</div>
<div>
<strong>timestamp/name</strong>: <span class="format-chat-
message">message</span>
</div>
<div>
<strong>timestamp/name</strong>: <span class="format-chat-
message">message</span>
</div>
...
</div>
}}}
Discussion
Using the <dl> keeps the pairs of data related in
a nice semantic way, although will probably be less-likely to have
appropriate CSS applied, since <dl> will often have a <dt>, then the <dd>
on a new line, indented. Using an <ol> gives us things on one line, but by
default is also going to be numbered. The HTML5 spec uses both Alternative
1 and 2 as possibilities for marking up a "conversation"
(http://www.w3.org/html/wg/drafts/html/master/common-
idioms.html#conversations). Trying to get some default CSS in there seems
to defeat the purpose a little. Alternative 3 is the only one I can see
that will keep things together, force each line of conversation to a new
line, and give us full CSS flexibility. In 2 and 3 we could drop the
<span> if we don't think it's worth including. I put it there to provide
more CSS formatting hooks. All of above assume that we can come up with a
reasonabe parsing algorithm for chat transcripts. If we can't, then 2 and
3 can just split post_content based on linebreaks, and otherwise I suggest
we use a trimmed version of the Quote format.
''Image''
Title
{$post_title}
Content
{{{
<div class="wp-caption format-image-img">
<img src="{$_format_url}" alt="{$post_title}" height="" width=""
border="0" />
<div class="wp-caption-text">{$post_content}</div>
</div>
}}}
Discussion
Re-using roughly what we already do for images
inserted with captions, and adding a standardized class in there for
targeting (maybe redundant, since you'll have the post_class?). Wrapping
post_content in a div since it's likely to be auto-p'd, so don't want to
wrap it in a <p> (which is what current captions do). <figure> and
<figcaption> are unfortunately out because they are HTML5 only. See also
http://www.cs.tut.fi/~jkorpela/www/captions.html (and some of the links at
the end)
''Video''
Title
{$post_title}
Content
{{{
[video src="{$_format_url}"] . "\n\n"
{$post_content}
}}}
Discussion
Assuming
http://core.trac.wordpress.org/ticket/23282 happens. We're going to need a
native player if we're giving a direct URL for the media item. If we get a
URL for a media *page* from the user, then we should put it on a line of
its own and let oEmbed handle it. post_content just goes directly below
that.
''Audio''
Title
{$post_title}
Content
{{{
[audio src="{$_format_url}"] . "\n\n"
{$post_content}
}}}
Discussion
Assuming
http://core.trac.wordpress.org/ticket/23282 happens. We're going to need a
native player if we're giving a direct URL for the media item. If we get a
URL for a media *page* from the user, then we should put it on a line of
its own and let oEmbed handle it. post_content just goes directly below
that.
''Gallery''
Title
{$post_title}
Content
{{{
[gallery] . "\n\n"
{$post_content}
}}}
Discussion
If we're just uploading a bunch of images against
a post, then we can just drop in a [gallery] shortcode and let it do its
thing. Below the gallery, we can insert the post_content (gives the media
priority over the text).
'''Further Discussion''
No titles
Might be the only navigation element to permalink pages in
some themes
Native media players
Can we do them? Will they be good? If we can then they can
handle audio/video
Standardized Postmeta
Need to figure out the standardized postmeta fields so
that we can provide some test data. We can just use the Custom Fields UI
to fill them for testing.
Test Content/Plugin
Should get some quick test content that covers each post
format and export it into a WXR file so that theme developers can see what
happens with their themes. Needs a quick and dirty plugin that applies the
above default HTML based on post format.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/23347#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list