posts rewriting html code
-
*snort* Best feature of wordpress? You have used it, right? ;)
From my read of Andy’s response, it’s more of a HTML 4.01 issue than a TinyMCE issue.
-
SPANs are really irrelevant to what I was trying to do. I only tried SPANs as a workaround. The editor rewrites SPANs to make them HTML 4.0 compliant. I’m fine with that. But what doesn’t make any sense to me is converting DIVs to Ps. The are not the same, do not serve the same purpose. Andy’s email said this is the designed behavior and they do not intend to change it. So the only way around this bizarre feature is to turn off the rich text editor. As I pointed out in my response to Andy’s e-mail: this editor behavior makes life harder for everyone who wants to use a DIV on the rationale that somebody might use it when what they really mean is a P. I think that is, to say the least, a debatable design decision. How often is it going to happen that somebody goes to all the trouble in the rich editor to switch to code view to type a DIV tag when what they really want is something ELSE? I can’t get my mind around the logic of this reasoning.
-
@drmike- i use it every time i post. the people who complain about it being crap don’t use it. i’m no stranger to writing code. when i post about my weekend, i don’t want to write about it in code.
there’s a hack for standalone wordpress that will return the div functionality to the rich text editor. it’s not an issue with HTML 4.0* , it’s an issue with automattic thinking that you won’t need to use div’s inside a post. they specifically changed the rule, it’s a bad change, and it should be reverted.
* the block element inside an inline one is fine, and valid, and only affects the workaround, not the issue of div’s
-
I guess there’s no any specific design decision; it’s just happened that there’s a raison d’être: people who use HTML don’t use RTE.
so called rich text editor (TinyMCE) is a third-party project which is included into WP core for some time (it has its own user forums).
there are many popular FOSS projects around that actually grown up rather than designed — not sure if any particular logic could be found behind some misterious behavior of theirs (apart from “it just works!”).
-
We will re-evaluate the reasons for converting DIV to P.
It had something to do with the way some browsers implement design mode, the feature that makes WYSIWYG work, and the alignment buttons.
Please understand that we have many other things on our plates and this one just isn’t a high priority. TinyMCE is open-source, so if you’re inclined to help please contribute code to MoxieCode or wordpress.org.
-
Here is the reasoning behind converting DIVs to Ps that was given to me in email from WP support:
The DIV/P conversion is intentional. It is done when the content is taken from the rich editor (i.e. when saving or switching editors). We do this because, due to browser quirks, the rich editor sometimes creates DIV tags when P tags are wanted. Compared to your scenario, the frequency of this scenario is overwhelmingly more compelling. It’s a case of the unskilled majority being favored over the expert minority.
-
I wonder if I could write a Firefox extension to change this?
I was playing around with the idea of writing a wordpress.com tinymce expert extension that did things like:
– remove the spellcheck function and turn on firefox spellcheck
– automatically enable the Alt-Shift-V hidden menuI’m not sure if this conversion is happening on the java TinyMCE side or the backend, but it sounds like it’s happening on the Java side which means it can be tweaked.
I wish I had more time.
-
the file that gets hacked is formatting.php, so i’m pretty sure it’s on the backend.
and at least for me, the firefox spellcheck now checks the RTE field.
given the answer that garyglass got, i dunno that i’m qualified to submit patches on the subject.
-
admittedly, I didn’t have enough time to investigate (and test) whether this issue is caused by an erroneus richedit behavior, judging by the [#3826] bug ticket [of normal prority, milestoned to the 2.1.3, has no patch; not tested] it seems like this problem is on the backend side.
also, function wpautop() is definitely needs to be revised thoroughly as I was able to reproduce a bug in the ticket [#3007] opened 8 months ago (see also tickets ##: 3935, 3669, 2348, 1099).
I wonder if I could write a Firefox extension to change this?
I think it could be done by means of a GreaseMonkey user script; needs time too but somewhat less than full fledged extension though.
- The topic ‘posts rewriting html code’ is closed to new replies.
WordPress.com Forums 