#19978 closed task (blessed) (fixed)
Twenty Twelve
Reported by: | nacin | Owned by: | |
---|---|---|---|
Milestone: | 3.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Bundled Theme | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
In [19842]:
Initial import of the Twenty Twelve theme, by Drew Strojny. This time around we're trying something different than the previous twenty-something themes, a much more minimalist approach that affords easy use as a CMS in addition to being blog-forward. More information will be on wpdevel soon. Props drewstrojny and lancewillett.
Attachments (3)
Change History (79)
#4
follow-up:
↓ 10
@
13 years ago
[19845] — Move the wp_enqueue_style() to header.php.
I like the change to proper enqueueing of styles in a theme, but burying it in functions.php isn't very intuitive, or consistent with how JS is handled in header.php. Given how simple this theme is, let's keep it in header.php.
#5
@
13 years ago
- Description modified (diff)
See #19627 for related "Default to static front page" action.
#10
in reply to:
↑ 4
@
13 years ago
Replying to nacin:
[19845] — Move the wp_enqueue_style() to header.php.
I like the change to proper enqueueing of styles in a theme, but burying it in functions.php isn't very intuitive, or consistent with how JS is handled in header.php. Given how simple this theme is, let's keep it in header.php.
We could use get_stylesheet_uri()
for more simplicity, also suggested by Theme Review guidelines - http://codex.wordpress.org/Theme_Review#Site_Information
#12
@
13 years ago
In working on the comment markup I realized instead of hacking it to pieces with a custom callback passed to wp_list_comments()
we should eat our own dogfood and improve the markup that WP spits out by default.
The only reason we might still keep the custom Twenty Twelve comments callback is to use HTML5 semantic elements.
Otherwise: see #20088 for my patch and more details.
#20
in reply to:
↑ 19
@
13 years ago
Replying to lancewillett:
Replying to nacin:
Revert [19959]. The footer generator URL should be translated (think pt.wordpress.org)
Interesting ... seems really odd to me that a URL would be translated, versus using a plugin or server-side redirect to send people to the correct site.
There is code on wordpress.org to detect the user's language and suggest a local site for them. However, local sites are distinct entities, with their own showcase, forums, blog, etc., not simply a translated version of wordpress.org. So we treat them as such, and translate URLs like http://wordpress.org, http://wordpress.org/support/, etc.
#22
@
13 years ago
- Cc chip@… added
I would be happy to take on any tasks that you might want to throw my way: inline docs, code cleanup, guidelines conformance, best practice/coding standards, functionality. Just let me know how I can help!
#23
follow-up:
↓ 24
@
13 years ago
Google web font Open Sans is released under Apache License v2.0, which is compatible only with GPL v3, can we still use it?
#24
in reply to:
↑ 23
;
follow-up:
↓ 25
@
13 years ago
Replying to Mamaduka:
Google web font Open Sans is released under Apache License v2.0, which is compatible only with GPL v3, can we still use it?
FYI, here is the list of repository-acceptable font licenses. Apache License isn't on that list.
#25
in reply to:
↑ 24
;
follow-up:
↓ 26
@
13 years ago
Replying to chipbennett:
Replying to Mamaduka:
Google web font Open Sans is released under Apache License v2.0, which is compatible only with GPL v3, can we still use it?
FYI, here is the list of repository-acceptable font licenses. Apache License isn't on that list.
Checked that list first and asked here only to be sure, that we didn't miss something in Theme Review guidelines.
#26
in reply to:
↑ 25
@
13 years ago
Replying to Mamaduka:
Checked that list first and asked here only to be sure, that we didn't miss something in Theme Review guidelines.
The list in the Guidelines is compiled/maintained by external projects (GNU and Fedora; see links in the Guidelines). I just double-checked the original sources, and neither one has added Apache 2.0 as a GPL-compatible font license.
Also, it appears that Apache defers to FSF regarding the Apache license incompatibility with GPLv2.
#28
in reply to:
↑ 27
;
follow-up:
↓ 36
@
13 years ago
Replying to Mamaduka:
So that font needs to be removed/changed.
We won't be releasing any theme with a non-GPLv2 font, so yes.
#37
in reply to:
↑ 36
;
follow-up:
↓ 39
@
13 years ago
Replying to nacin:
Sorry, I didn't have all the facts. The font is not packaged with the theme. It links directly from Google Web Fonts.
That means we can approve themes that use non-GPL fonts linked from Google Web Fonts.
#38
@
13 years ago
Font issue update:
Matt gave us his approval for using Open Sans in the default theme, as long as it’s a theme option—off by default—and not bundled directly with the theme.
I’m fine with having an option to turn on linked google fonts
I don’t think the license of the font being apache 2 is a minus — the options for fonts aren’t great and that’s probably more efficient than GPL
for a font you really want something like LGPL or apache so you don't get into anything weird with licensing of documents / things created with the font
The bottom line is since the font will be off by default the theme should still look great without it.
#39
in reply to:
↑ 37
@
13 years ago
Replying to Mamaduka:
Replying to nacin:
Sorry, I didn't have all the facts. The font is not packaged with the theme. It links directly from Google Web Fonts.
That means we can approve themes that use non-GPL fonts linked from Google Web Fonts.
If it's not bundled with the Theme, then there is no licensing issue whatsoever.
I think Matt's suggestion (via Lance's comment) is a perfectly sane approach (though I don't know why it would need to be disabled by default?).
#40
@
13 years ago
though I don't know why it would need to be disabled by default?
The reason we're leaving it off by default is for RTL and non-supported languages. Otherwise, those users would have a broken default experience.
#41
@
13 years ago
The reason we're leaving it off by default is for RTL and non-supported languages. Otherwise, those users would have a broken default experience.
Assuming Matt, Lance, and Drew don't object to it being a default for other reasons, we can easily code it to be a default except for in non-supported languages.
#42
follow-up:
↓ 43
@
13 years ago
Assuming Matt, Lance, and Drew don't object to it being a default for other reasons, we can easily code it to be a default except for in non-supported languages.
I'd be on board, but we'd also have to consider setting the appropriate character sets based on the language. Otherwise those users would be required to manually choose a character set, and have a broken experience by default. I'm not familiar with the nitty gritty on how that would all work, but if you're confident it would be comprehensive, I'm all for it.
Loading all character sets by default would be another option, but that's adding a bunch of extra bloat and decreasing page load time for everyone, which I don't think is a good idea.
#43
in reply to:
↑ 42
@
13 years ago
Replying to drewstrojny:
Assuming Matt, Lance, and Drew don't object to it being a default for other reasons, we can easily code it to be a default except for in non-supported languages.
Yep, let's shoot for that. A quick check of the language and load the necessary language sets on demand—instead of loading *all* sets for everyone.
#45
follow-up:
↓ 49
@
13 years ago
Google allows us to load fonts via https too. We should use this if is_ssl()
is true.
(#16560 would be good now.)
#49
in reply to:
↑ 45
@
13 years ago
- Cc emil@… added
Replying to ocean90:
Google allows us to load fonts via https too. We should use this if
is_ssl()
is true.
(#16560 would be good now.)
I don't think that is_ssl(
) is necessary at all. (less is more)
This works well for both and there are no issues with any of the servers that I manage for my clients:
@import url(//fonts.googleapis.com/css?family=Droid+Sans);
Also see what Google itself does when loading fonts (same thing):
- http://www.google.com/intl/en/chromebook/static/css/chromeos.min.css
- view-source:http://www.google.com/intl/en/chromebook/
Emil
#52
follow-ups:
↓ 53
↓ 55
@
13 years ago
Out of curiosity: would it be possible for the default Theme actually to use the default output of wp_list_comments()
?
I've noticed that Twenty Ten, Twenty Eleven, and now Twenty Twelve all use custom callbacks wp wp_list_comments()
output. Given the prominence of the default Theme, and its likelihood to be used to fork and/or to create child Themes, IMHO it makes sense that the default Theme should use the default output for comments - or else, if the core-defined markup is inadequate, perhaps the core output should be updated?
#53
in reply to:
↑ 52
;
follow-up:
↓ 54
@
13 years ago
Replying to chipbennett:
Out of curiosity: would it be possible for the default Theme actually to use the default output of
wp_list_comments()
?
I've noticed that Twenty Ten, Twenty Eleven, and now Twenty Twelve all use custom callbacks wp
wp_list_comments()
output. Given the prominence of the default Theme, and its likelihood to be used to fork and/or to create child Themes, IMHO it makes sense that the default Theme should use the default output for comments - or else, if the core-defined markup is inadequate, perhaps the core output should be updated?
#54
in reply to:
↑ 53
@
13 years ago
Replying to nacin:
Replying to chipbennett:
Out of curiosity: would it be possible for the default Theme actually to use the default output of
wp_list_comments()
?
I've noticed that Twenty Ten, Twenty Eleven, and now Twenty Twelve all use custom callbacks wp
wp_list_comments()
output. Given the prominence of the default Theme, and its likelihood to be used to fork and/or to create child Themes, IMHO it makes sense that the default Theme should use the default output for comments - or else, if the core-defined markup is inadequate, perhaps the core output should be updated?
#facepalm
Thanks, Nacin. Not sure how I missed that.
#55
in reply to:
↑ 52
@
13 years ago
Replying to chipbennett:
Out of curiosity: would it be possible for the default Theme actually to use the default output of
wp_list_comments()
?
See #20088 and my notes in http://wpdevel.wordpress.com/2012/02/20/team-update-twenty-twelve-3/
#56
in reply to:
↑ 31
;
follow-up:
↓ 57
@
13 years ago
- Cc forumi@… added
Replying to lancewillett:
In [20007]:
navigation.js is enqueued in the wrong way. There is no need for wp_enqueue_script( 'jquery' ), and $deps argument in wp_enqueue_script() should be array, not string. Attached patch fixes this.
twentytwelve_scripts() should be called later so that jQuery is loaded in footer too (if it's not called earlier by some plugin). Also, navigation.js could get minification.
#57
in reply to:
↑ 56
@
13 years ago
navigation.js is enqueued in the wrong way. There is no need for wp_enqueue_script( 'jquery' ), and $deps argument in wp_enqueue_script() should be array, not string.
Thanks for the notes, dirmadin. Will fix up that up soon.
I disagree on loading the JS later; and we probably won't minify JS in the default theme. You can certainly do it on your end, in production.
#60
@
12 years ago
- Milestone Future Release deleted
- Resolution set to maybelater
- Status changed from new to closed
- Type changed from task (blessed) to feature request
#61
@
12 years ago
- Milestone set to 3.5
- Resolution maybelater deleted
- Status changed from closed to reopened
- Type changed from feature request to task (blessed)
#62
@
12 years ago
nice theme!
about the screenshot of the theme... need 250 px height, the current one has 200 px.
#63
follow-up:
↓ 65
@
12 years ago
about the screenshot of the theme... need 250 px height, the current one has 200 px.
Let me know the exact dimensions for the screenshot and I'll work up a new one, it needs to be updated anyhow.
#65
in reply to:
↑ 63
@
12 years ago
Replying to drewstrojny:
Let me know the exact dimensions for the screenshot and I'll work up a new one, it needs to be updated anyhow.
300px wide, 225px tall (not 250).
#66
@
12 years ago
Please see screenshot
- Recommended 4:3 W:H ratio, size 300x225px.
- Maximum size: 320:240px
that's exactly what Nacin is saying :)
#67
@
12 years ago
Replying to nacin:
300px wide, 225px tall (not 250).
Got it, thanks gents. Just to clear my name, I wasn't the one who created the current screenshot. I'm not saying who did, I would never throw Lance under the bus like that :)
#69
@
12 years ago
I am going to close out this ticket. Everyone should open new tickets for new issues. Feel free to cross-post them here.
In [19843]: