[wp-trac] [WordPress Trac] #35395: Provide a better gateway for code-based theme customizations with the Customizer
WordPress Trac
noreply at wordpress.org
Sat Sep 24 02:59:00 UTC 2016
#35395: Provide a better gateway for code-based theme customizations with the
Customizer
-------------------------------------------------+-------------------------
Reporter: celloexpressions | Owner: johnregan3
Type: feature request | Status: assigned
Priority: normal | Milestone: 4.7
Component: Customize | Version:
Severity: normal | Resolution:
Keywords: has-screenshots needs-patch dev- | Focuses:
feedback |
-------------------------------------------------+-------------------------
Comment (by joyously):
Replying to [comment:36 azaozz]:
> I am pretty firmly against introducing another way for adding "hacks" to
WordPress.
My sentiments exactly. I spent 2 years as a moderator of a popular theme
forum, and most of those users had no clue what CSS is or what to type in
this new editor. Having yet another place to look for CSS will make it
that much harder for support.
>
> Apart from the above there are several other things that are pretty bad:
> - Inadequate space for editing/writing. Try resizing your coding (text)
editor to 275px width and edit something for 10-15 min. It's really bad.
The editor space needs to be adjustable. And at the point of editing, it's
best to be able to see the HTML of a page, not the rendering. How else
will you know what selectors to use?
> - "Deceiving" preview. CSS hacks affect the whole site but the user can
see only one template in the preview. For example it is pretty easy to
make a change that "looks good" on the front page but breaks the archive
pages, etc.
And how do you preview/test the responsiveness of your CSS (desktop,
mobile)?
>
> In addition there is no good way to make the user entered CSS "secure".
I addressed this issue earlier, but I don't know if anyone "got" it. If
the CSS lives in a file, then anything not CSS in there is a CSS error
instead of treated as HTML.
>>If it has to be theme specific, have you considered that the post type
is like an attachment and the CSS is actually stored in a file? This way
the storage is easier (CSS can be difficult to get into the database
correctly), and the inclusion in the header is better (using the src
attribute), and the browser can cache the file and it can be served
zipped.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/35395#comment:38>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list