[wp-trac] [WordPress Trac] #24977: Workflow change: automate RTL css generation

WordPress Trac noreply at wordpress.org
Wed Aug 7 13:46:05 UTC 2013


#24977: Workflow change: automate RTL css generation
----------------------------+------------------
 Reporter:  yoavf           |       Owner:
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  3.7
Component:  General         |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |
----------------------------+------------------

Comment (by mark-k):

 Replying to [comment:8 yoavf]:
 > @mark-k - automated css is perfectly doable - from what I know this is
 entirely how Google operate across all of their sites and services, and
 how Wikipedia is built (the PHP port of CSSJanus we use on WP.com has been
 done by Wikimedia).
 >

 well, this is not google with serious QA department and monopolistic grab
 on the market, and not wikipedia in which software development is the
 least important part of its operation and has similar monopolistic grab on
 the market.

 > Sure, you may have to write your (ltr) css in certain ways to minimize
 problems. But that's completely in line with general css best practices.
 In any case that's why education and documentation are a big part of this
 challenge.
 >

 And who will enforce the new css standard? Do we do a good enough code
 review to catch possible style violations?


 > As for the specific examples you've mentioned - CSSJanus has built in
 support for flipped images - and we'll make this part of our build
 process. Additionally, core has been and will be removing a lot of images
 used to style the admin. Quite a few of them are replaced by pure css
 and/or genericons. Background positioning can be problematic, but totally
 manageable either with mirrored sprites and/or percent based positioning.


 {{{
 background:url(image.png) top 30%; % rtl != background:url(image.png) top
 70%;
 }}}


 the reason is that image are drawn ltr and there is no way to specify
 drawing rtl, therefor in the example above you will not get 30% margin on
 the right. You actually have to know the image width to handle this kind
 of transformation, and how do you get it when the image is part of a
 sprite?

 As for genricons, flipping images there will be lots of fun. will the tool
 chain generate font files automatically?, cause I am not sure what tools
 should be used for that at all.

 >
 > With regard to testing - it won't be much different that the situation
 today. We have a lot of core contributors who regularly test core on RTL
 mode during development, and there's no reason this will change.

 testing rtl without actually blogging in rtl is problematic. How do they
 know what to test, what to look for? I never seen a QA plan in the WP
 development process....

 '''Summery''': I think there are theoretical hurdles and I suspect there
 will be practical ones as well. IMO The 3.7 time frame is too short for
 that. I suggest to break it in two, in 3.7 do the cleanup and education
 but introduce the tool as part of the build chain only in 3.8

--
Ticket URL: <http://core.trac.wordpress.org/ticket/24977#comment:9>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list