wordpress / twentysixteen Goto Github PK

I would like to suggest to add a separate category template instead of having to rely on the archive template which is far too general.

Layout doesn't need to be exactly the same but let's make it at least readable and usable on IE7 and above.

One small tweak we could make to improve the accessibility of Twenty Sixteen is adding the post title to the edit_post_link and hiding it with screen-reader-text. We do this in a few other spots to provide more context to link text, and the case would be the same here.

Thoughts?

Pull request incoming. 😄

http://microformats.org/wiki/hcard

HCards are recognized by a variety of sites and the formatting for them appear in various parts of WordPress.

Perhaps with a nice picture? My eye seems to be consistently drawn to the peculiar stuffed potato dumplings at the Renfield. :) Perhaps something that fades in the background? More "common" like last year? A photo of a place, a title related to that photo, and some more "abstract" text?

Since TwentySixteen is a showcase of what WordPress can do, should the new singular.php file be provided in the theme despite the fact that single.php and page.php are already provided?

Hey

Ideas will come up that are really good but for whatever reason are not be added to the official theme.
So what if an underground unofficial theme is created at the same time?
To showcase various things the official theme chooses not to showcase. It will show more variation of what can be done and can be used for further study for various users.

In editor-style.css there are 2 unprocessed variables used. Looks like sass variables left from some previous code.
https://github.com/WordPress/twentysixteen/blob/master/css/editor-style.css#L335

There's three calls I noticed in functions.php for requiring files from the /inc/ folder. Any objection to a PR that replaces these with get_stylesheet_directory() for child theme over-ride potential?

The overhanging treatment works well with a newly uploaded .size-large image, but there is an issue if the image was added when a different theme was activated. This is because of the width attribute and the value comes from $content_width of the previous theme.

The image below was uploaded when Twenty Twelve was activated. (The $content_width is 625px in Twenty Twelve)

To resolve the issue, it's safer to apply the treatment only to .size-full image because the value of the width attribute is the same as the actual image width.

When there is no title and no featured image in the sticky post, we cannot go to that individual post as there is no date and the "featured" text isn't linked as well. Not sure how to fix but maybe we can add a link to Featured text or add the date back. maybe an edge case..

At some point there is this little design issue. When there are two or more categories, it seems the padding between the categories list and tags list in entry footer become larger than when its only 1 category. Looks like this css is the issue

.entry-footer > span:not(:last-child):after {
  padding: 0 0.538461538em;
}

That padding appears on the next line which triggers that space.

Here is the screenshot that should be self explanatory.

Steps to get started:

1. Create a new post and use the Image Post Format.
2. Insert an image into the post.
3. Do not define a Featured Image.

In parallel, do the following:

1. Create a new post and use the Standard Post Format.
2. Define a Featured Image.

When comparing the 2 posts, I find that the standard post (with its Featured Image) actually does a better job of showing off my image.

I wonder if we should handle that special case:

• When a post uses the "Image" post format but does not include a featured image, improve twentysixteen_post_thumbnail to look for the first image in the post and display it instead of the featured image.
• Remove that first image from the post content.

What do you think?

Just like other default theme, lets create a language folder which will contain translatable strings.

In template-tags.php, the function twentysixteen_categorized_blog() uses get_categories() and passes an array of args. One of these values is 'hide_empty' => 1, however, the default value for hide_empty is 1, thus is unnecessary.

As brought up in #23

As WordPress core has included full inline documentation. We should do the same for the default theme.

Image captions in editor isn't italic as it is in the preview post

Line 197 of template-tags.php
@return bool True of if there is more than one category, false otherwise.

PR incoming.

As now custom-header.php contains functions for both Custom Header and Custom Background, may be we should rename it to more suitable name.

When a long name is displayed, the hidden "/" separator drops down to the next line creating an empty line artifact in the entry-footer area. Patch to follow.

First noticed this with an actual post title:

After looking a little deeper into it and realizing word-wrap: break-word; was being used in several places and just happened to miss the title, I took into account where it was being used and made some adjustments.

• It was being applied to .entry-intro in two different places, which is always in a post/page article.
• It was being applied to .entry-content and .entry-summary, which are always in a post/page article.
• It was being applied to .type-attachment .entry-title which I'm not even sure is part of the theme (that's a separate issue) but if it was, it would only be in image.php, which is always in the aforementioned article element.
• It was being applied to .entry-caption, which is also only part of image.php.
• It was being applied to .textwidget, which is always going to be nested in .widget where it's already applied.

So in all things listed above, it was either 1) unnecessary to have or 2) always in a post/page/attachment article element, which all share the article[class^="post-"] selector already in the stylesheet. So I put the word-wrap there.

All other places it's being used in a legit manner, I left it alone.

I would like to discus what the file and folder structure might look like if the theme included minfied versions of styles and scripts as well as non-minified versions when as the theme progresses.

It may not be the best time to include these right now but closer to completion I think that minified versions should be included for sure.

With merge of PR #61 all files in the theme are currently non-minified. For production I would suggest that using minified files would be preferential but the issue would be how to do that.

My suggestion is to have minified versions of each script inside the same folder as the non-minified versions. As for the stylesheet - it may not be the best idea to include style.min.css in the root alongside the standard style.css but I still think providing a minified version would be of benefit.

What does everyone think about where minified files should be placed and how they should be enqueued? Should they only be enqueued conditionally by choice of the user... Is that too complicated an option for a default theme?

What about an option inside the customizer for a choice of boxed or fluid layout?
Perhaps a page template.

Inside the .each() iterator on found images, we have redundant $( this ) selectors, even though we cached it in the img variable. While the performance costs of creating a few more instances of a jQuery object here probably won't make much difference, it is best practice to use the stored instance.

Also, in the same bigImageClass() function, we use the img var as a selector like $( img ) when img is already a jQuery object.

Will add a PR shortly.

By default <code> selector has no CSS style defined. Screenshot:

It's nice to have a style for the <code> selector with a background color & some padding. Screenshot:

at Austria we use a big black border for notices about someone's death. I was really shocked as I've seen the screen of twenty sixteen the first time.
The bold black headlines and bold black borders complement this.

I know this is the background, but the initial visual impact was shocking.

The microformats class for an excerpt is entry-summary, not entry-intro.

http://microformats.org/wiki/hatom

When there is Post Date in Recent Posts widget the gap between the title and date is larger than the gap between the list items.

Here is what is happening (first image) and how it should be (second image)

Doing some brainstorming here...

Page Template:

• Portfolio masonry.
• Portfolio standard.
• A nicely stylized blog. (Actually there can be a few different blog templates to choose from.)
• Archive pages.
• A few landing pages.

Comment states it registers one location, but actually registers two.

All 3 fonts used in the theme have only Latin (2 of them - Latin Extended) subsets. For any language with non-latin characters (for example, any cyrillic language - ukrainian, russian, bulgarian etc) it defaults to system serif / sans-serif which are completely different and things look awful, sometimes just break (because of different character widths and baselines).

[grumble_mode=on]

People, really. I don't get this. We spend a lot of time working on some mere fallbacks and edge-cases needed by fractions of percent of users, like old IE fixes, eot webfonts etc. We do spend a lot of time working on accessibility. But we (well, those US-people mostly, to be honest) still forget that we live in a world where people speak many different languages. WP still does not have a proper multilingual content support. That's a whole another topic, but let's make the themes truly multilingual at least.

[grumble_mode=off]

I'm not sure how to fix it better. One option I can think of is adding similar-looking fallback fonts with extra subsets, so our css declarations would look like font-family: Merriweather, Some_Alternative, serif;.

Another option is to use alternatives right out of the box.

• Merriweather has cyrillic (vietnamese and some other non-latin subsets), but the Google-hosted version of the font is missing them. See here and here for the font with all subsets.
• Montserrat does not have non-latin characters (it even lacks extended latin support). It's closest alternative, Proxima Nova has non-latin subsets.However, it's not free. I suppose, in twentysixteen, Montserrat will be used for that hipster small labels in caps mostly. In this case, replacing (or adding a fallback) with Helvetica will be fine.
• Inconsolata can be safely replaced with Fira Mono. Or any other monospace font from Google Fonts. Personally, I prefer Roboto Mono.

While resizing, I noticed there was a certain window of width where there is margin on the right side. The header, menu and footer menu seems to extend full width but the content seems to cover like 75%. Is this done deliberately for "readability" ?

See _s Automattic/_s#743

HFeed indicates a page where multiple hentrys exist. It should not appear on any single page.

On wide screens, when blockquotes at the top of a post are aligned left, they cover the entry-footer data:

This is a standard issue with this type of layout and will likely affect the full-width image display as well.

I've been meaning to do this. Uppercase text currently a little condensed and I'm going to loosen the tracking.

There is Wrong Number of location above register_nav_menus on functions.php in line number 71

I like that the sidebar is on the right-hand side by default. It is an "aside" and reading starts to the left, so it makes sense. But reading doesn't start to the left for everyone. Should there be an option to have the sidebar on the left specifically for RTL readers? Of course it has benefits for LTR readers as well if they just have a preference.

I thought the boxy border didn't go well with the menu items with submenus (on the mobile nav). It looks odd on the overall neat design.

I know "whitespace only" code refactoring changes for core files are discouraged, but this isn't in core yet so I felt it should at least be noted.

Some multi-line var declarations use spaces to indent the next line, while others correctly use tabs (according to the Javascript coding standards).

Assignments within the var statement should be listed on individual lines, while declarations can be grouped on a single line. Any additional lines should be indented with an additional tab.

Offending files include:

• /js/functions.js
• /js/customize-preview.js
• /js/skip-link-focus-fix.js

Like other default themes, let's add print style at the bottom of the main stylesheet.

Function ending comment are missing on different file.

Nitpicky, but necessary. The name of the contributors file has a typo. Should be contributors.md, not contributErs.md

Function: twentysixteen_widgets_init
Line : 128
It would be good to add description rather than keeping empty.

It looks like post formats are a part of standard posts because of the font size differences..

I know there has been a lot of discussions about Post Formats.
I am just wondering what you think.
Should Post Formats instead be handled in future core plugins like Shortcake? (If my thinking is correct.)

• Add rtl.css
• Add rtl-language-support tag to both style.css andreadme.txt

File: custom-header.php
Function: twentysixteen_custom_header_and_background