Whenever you use Freeway’s built-in Insert / HTML Markup dialog in an
inline context (you have a flashing text cursor) rather than an object
context (nothing on the page is selected), then you will always end up
with your markup content (or more likely, what your markup generates)
wrapped inside of either a P, LI, DD, DT, or H1-6 tag, depending on
the surrounding text style. There are no exceptions to this rule.
So if your Pulse content was set to generate a div, or a group of P
tags, or an UL or similar, then that block-level tag would become a
direct child of a P (or whatever) tag, which would mean that it was
improperly nested in the DOM. The browser would silently move it out
of the container, but then it has its own choice of how to do that
when constructing the DOM, so it might remove the wrapper tag
(unlikely) or close the wrapper tag immediately before and re-open it
after the misplaced block content. This could certainly lead to extra
space before and after the block of Pulse content (in the best case)
or it could lead to JavaScript not working correctly in that part of
the DOM, or maybe worse, the inline block might not appear at all.
Now if your Pulse block is set to export text only, or only inline
tags like span and em, then you’re golden. Freeway will generate a
wrapper P or similar tag based on the design and the text style
“wrapped” around that block. But if not, if your Pulse block generates
an actual block-level tag, then using my CrowBar Action is your only
way out.
CrowBar, when used in an inline context, takes the following approach
to inserting its content into the page. If the CrowBar is all by
itself on the line (the only non-Freeway content in the parent tag),
then it erases the parent tag entirely, and inserts its code instead.
If the CrowBar element is the first character of the line, but it’s
not alone on the line, then it moves its code directly outside of the
parent tag, so:
<p>CrowBar more text here</p>
becomes
CrowBar<p> more text here</p>
Similarly, if the CrowBar is the last item in the parent tag, it moves
outside the close tag of the parent.
Until Freeway adds a more granular inline Markup Item tool (and I’m
not holding my breath here) Actions like this are the only way around
this problem.
Walter
On Jun 11, 2011, at 5:54 PM, markf wrote:
There’s one possible problem awaiting you if your Pulse ?content is
more than one line of text. If you use the Markup Item, and the
resulting code from Pulse generates a block-level wrapper like
or
around its content, you will invalidate your page. (It
will probably look fine in most browsers, but it will fail W3C
validation, and having an invalid page can contribute to nearly-
impossible-to- debug problems in other areas, especially if you use
JavaScript effects elsewhere on the same page.)
Hi,
I am the developer of Pulse CMS, just wanted to chime in here.
Unless I am missing something, can you explain why
tags would
make your page fail W3C validation? (You can also turn this off)
Mark
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options