[theme-reviewers] Theme Reviwers
Emil Uzelac
emil at themeid.com
Fri May 4 07:40:24 UTC 2012
And to add and possibly finish this up:
http://www.websiteoptimization.com/secrets/web-page/replace-inline-style.htmlwas
published in
http://www.amazon.com/dp/0596515081/?tag=websiteoptimi-20 as well ;) Do we
need to continue our "discussion" ? ;)
Thanks,
Emil
On Fri, May 4, 2012 at 2:27 AM, Emil Uzelac <emil at themeid.com> wrote:
> Not at all, inline stylesheet is also know as style embedding big
> difference. Inline stylesheet is wrapped in <style> while inline CSS is
> directly in DIV. So no I haven't confused these two.
>
> Inline stylesheet is being used by WordPress itself and that doesn't cause
> any issues or at least not to my knowledge:
>
> <style type='text/css'>#gallery-1 {margin: auto;}#gallery-1 .gallery-item
> {float: left;margin-top: 10px;text-align: center;width: 33%;}#gallery-1 img
> {border: 2px solid #cfcfcf;}#gallery-1 .gallery-caption {margin-left:
> 0;}</style>
>
> And if this *hypothetically speaking* is making some "problems" *and to
> outline it does not* user can easily override via functions.php
>
> /**
> * This function removes inline styles set by WordPress gallery.
> */
> function responsive_remove_gallery_css($css) {
> return preg_replace("#<style type='text/css'>(.*?)</style>#s", '',
> $css);
> }
>
> add_filter('gallery_style', 'responsive_remove_gallery_css');
>
> and add the elements in style.css
>
> Can you do that with <div style="background:#000">? Nope I don't think so.
> And just to get something clear and out there (in case that someone brings
> this up) you can override inline style as well, but not as easily, however
> you cannot override some or all* pseudo elements (classes)
>
> We're WordPress and this is not the best example but...
> http://drupal.org/node/81835 this was in 2006 so even back than it was
> very important. (*just so that you don't pull my arm again*) this is
> similar and not the same what we're discussing here. But we can go there as
> well:
> http://answers.oreilly.com/topic/497-replace-inline-style-with-css-rules-to-speed-up-web-pages/
>
> @Konstantin, just like @Chip said once, we cannot have everything in Theme
> Review guidelines, some will simply imply :)
>
> Emil
>
> On Fri, May 4, 2012 at 1:59 AM, Konstantin Obenland <
> konstantin at obenland.it> wrote:
>
>> Good morning everyone!
>>
>> hm, there are quite a few issues to discuss here:
>>
>>
>> - Inline styles, yes/no:
>> I'm with Emil here, I'd love to see cleaner template file. Adding
>> inline js or css should always be avoided where possible. I'm sure there
>> can be exceptions to the rule when asked (as there has been for other
>> requirements), but generally developers should strive for a separation of
>> CSS/JS and HTML.
>>
>> - catching some of the obvious "issues":
>> This brings me back to two emails I wrote concerning the
>> "findability" of requirements, where I unfortunately did not receive a
>> response:
>>
>> *I'm still pretty green as a reviewer, and in the beginning I found it confusing that I had to look all over the place to make sure I have all requirements in check, when reviewing. I still have like four reference tabs open when I review a Theme:
>>
>> Theme Review Codex
>> Theme Unit Test CodexWordPress 3.3 Proposed Guidelines Revisions
>>
>> Chips article for new reviewers on his blog
>>
>> This is what I base my reviews on but I can't be sure that I didn't miss a requirement hidden somewhere else. :)*
>>
>>
>> I, for one, was not aware that jQuery functions must not be embedded
>> in the Theme directly or that inline styles are not accepted. And I'm sure
>> that goes for many Theme authors, too, as these things are not documented
>> (to the best of my knowledge).
>>
>> - "I've seen that they were not reported in couple of reviews."
>> Except for when it was not a full review, I trust the preceding theme
>> reviewer when picking up a ticket, especially on pre-approved Themes. We
>> have to be able to rely on the judgement of our fellow reviewers. What do
>> you think?
>>
>> - SPAM links:
>> Since there are no clear guidelines in place, this is something I
>> always feel very uncomfortable with. I know it is hard to phrase
>> requirements to catch all forms and shapes of Spam-links, but I would love
>> to have a clearer set of principles that I can base my findings on.
>>
>>
>> I'll now have breakfast. :)
>>
>> Konstantin
>>
>> On 04.05.2012, at 08:02, Emil Uzelac wrote:
>>
>> *Of course not, we're here to discuss not to debate :) *
>>
>> Being an admin or reviewer has very little to do with what could be good
>> or not so good for WP users. Inline styles was something developers liked
>> to do I would say 6-8 years ago. Using inline styles for personal projects
>> is one thing, passing this onto users is another story. If and when we
>> decide to use inline styles, that's called "dictating" and that's not what
>> we should do. Users should be able to change their CSS elements from
>> stylesheet and not wondering where other styles might be.
>>
>> *In my understanding inline styles were not welcomed even before I've
>> joined the team in December of 2010 :)*
>>
>> Other issues of inline styles:
>>
>> - Code Bloating
>> - Potentially slowing down the page load time
>>
>> There's the reason why e.g. Google PageSpeed suggests that we load styles
>> at the top of the page, styles should load before the page does, that will
>> not be the case if inline styles are used. Inline styles will also cause
>> browser interruption as well. Next would be that when using stylesheet as
>> e.g style.css browser could easily cache that and reuse what you already
>> loaded the first time you entered example.com and again inline will not.
>> I can go on and on about this, but that would not be necessary :)
>>
>> As far as jQuery inline styles that too is not the best practice and what
>> I call "CSS Hacking". With jQuery you can use the stylesheet too. That's
>> why some jQuery plugins will affect the performance of the page load.
>>
>> I would highly recommend something like this:
>>
>> - jquery.example.js
>> - jquery.example.css
>>
>> Cleaner code = less issues for users, less issues for users = less
>> support for developers, simply stuff really.
>>
>> Yes, this specifically was not in any of the links I pasted above, but I
>> think that it goes into
>> http://codex.wordpress.org/Theme_Review#Code_Quality
>>
>> Anyone else if free to "jump in" and tell all of us why we should allow
>> inline CSS. This is an open topic and there's nothing one admin can do if
>> others don't agree with him, don't think of me that way please.
>>
>> Thanks,
>> Emil
>>
>>
>> On Thu, May 3, 2012 at 11:55 PM, Sayontan Sinha <sayontan at gmail.com>wrote:
>>
>>> Emil,
>>> I don't want to get into a debate here - this is too small a point. Just
>>> note this:
>>>
>>> 1. I am not saying inline styles are good. I am saying they are
>>> okay, depending on the context. They certainly aren't bad or wrong, and
>>> they have their place. Pick up any reliable resource on the web - they will
>>> recommend against inline styles with a caveat, that they shouldn't be used
>>> *if* you want to offer the ability to override them. One way to
>>> interpret this is, "They are fine if you don't care about the ability to
>>> override them". In the cases that I use them, I make sure that the user has
>>> no reason to override them. Correctness here is really a question of
>>> context.
>>> 2. None of the links you have provided says inline styles must not
>>> be used - you can go through them. Thus it is not the official position of
>>> WP. Frankly I would be surprised if this is made an official position, in
>>> which case using the "css" function of JQuery should be disallowed too, in
>>> favour of "addClass".
>>>
>>> I have never officially reviewed a theme, however I do follow this
>>> thread very closely. You are a WPTRT admin and thus your word carries
>>> weight amongst other reviewers. It is just that I have coded some insanely
>>> complex scenarios and I have come up against more "exception" situations
>>> than most other developers. I am just trying to bring to light some such
>>> scenarios.
>>>
>>> Sayontan.
>>>
>>> PS: I take the "lazy" developers as a compliment. As per Larry Wall (the
>>> creator of Perl), "The three chief virtues of a programmer are: Laziness,
>>> Impatience and Hubris".
>>>
>>> On Thu, May 3, 2012 at 7:11 PM, Emil Uzelac <emil at themeid.com> wrote:
>>>
>>>> There's no shortcuts in CSS, saving time -vs doing it right the first
>>>> time is completely different. It is very important <div
>>>> style="margin-top:33px;"> will be hard to override in a stylesheet and yes
>>>> it is wrong and bad practice, how can this be good. Tables too, I did not
>>>> use tables in years! <div style="margin-top:33px;"> is for "lazy"
>>>> developers I am sorry, not sure if you're using them or not.
>>>>
>>>> This is not something that I am pushing, it was much before me. My
>>>> first message was also intended for reviewers and only as a reminder that's
>>>> all.
>>>>
>>>> See:
>>>>
>>>> - http://codex.wordpress.org/CSS_Coding_Standards
>>>> - http://codex.wordpress.org/WordPress_Coding_Standards
>>>>
>>>> second link will give you better idea how strict the WP Standards are
>>>> and how much of slack review team is giving to all of us.
>>>>
>>>> Thanks,
>>>> Emil
>>>> _______________________________________________
>>>> theme-reviewers mailing list
>>>> theme-reviewers at lists.wordpress.org
>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>
>>>>
>>>
>>>
>>> --
>>> Sayontan Sinha
>>> http://mynethome.net | http://mynethome.net/blog
>>> --
>>> Beating Australia in Cricket is like killing a celebrity. The death gets
>>> more coverage than the crime.
>>>
>>>
>>> _______________________________________________
>>> theme-reviewers mailing list
>>> theme-reviewers at lists.wordpress.org
>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>
>>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20120504/df26da1f/attachment-0001.htm>
More information about the theme-reviewers
mailing list