Expanding the HTML parsing about sablon HOT 8 CLOSED

Patches that expand HTML insertion for general purpose use are definitely welcome. Things that tend to be more use-case / project specific are better done in a fork. If we can tweak the HTML converter to allow custom extensions that would be even better. Then the extensions could live in app code or gems without a necessary fork. Do you think your changes are general purpose or more on the specific side of things?

from sablon.

In my mind the changes are general purpose. The first round will involve adding support for the <span> tag to create individual runs within a paragraph. Building upon that I want to add more styling options, text color, alignment, alternative methods to make bold and italics typeface, etc.

i.e. in the final product you could do something like:

<p style="text-align: center; color: #DDDDDD">
Paragraph text content, centered and gray
  ...
  <span style="font-weight: bold">Some bold Text</span>
  ...
  <span style="background-color: yellow">Some highlighted text</span>
  ...
</p>

Obviously all CSS styles wouldn't be, nor could be supported but a basic set to cover the common cases in MS Word.

After thinking about #48 and hyperlink injection it would be great if "inline" elements i.e. <span>, <a>, etc. didn't have to replace the entire paragraph but that might be beyond the scope of my needs.

from sablon.

@senny after thinking about #48 what are your thoughts of allowing HTML substitution that doesn't replace the entire paragraph if the HTML elements being adding are considered "inline" i.e. <a>, <b>, <i>, <span>.

I think there would be a clear enough break in the logic to justify full paragraph replacement if you use block level elements <div>, <p>, <ul>, etc. that it shouldn't confuse users. Currently the supported inline tags can't exist outside of a block level tag so a change like this wouldn't break existing backwards compatibility.

from sablon.

@stadelmanma I'm 👍 if we can find a solution that works for both paragraph and inline replacements. We could even use it to provide better content abstractions. Something like:

Sablon.content(:hyperlink, "Click Me", "https://google.com")

I think it should be fine if we CASE the behavior on the fact that the provided HTML contains at least 1 paragraph element.

from sablon.

@senny as I work through supporting the style tag (I'm almost ready for a PR that will build off of #51 you can see my branch here) I am finding myself setting up blocks like the following:

      # converts CSS => OpenXML
      attr_map = {
        'background-color' => ->(v) { return 'highlight', v },
        'font-weight' => ->(v) { return 'b', nil if v =~ /bold/ },
        'font-style' => lambda { |v|
          return 'b', nil if v =~ /bold/
          return 'i', nil if v =~ /italic/
        },
        'text-align' => ->(v) { return 'jc', v }
      }

...
     # maps HTML block element => MS Word Paragraph style
      styles = { 'div' => 'Normal', 'p' => 'Paragraph', 'h' => 'Heading',
                 'ul' => 'ListBullet', 'ol' => 'ListNumber' }

...
     # maps element style tags => OpennXML styles
      styles = {
        'span' => {}, 'strong' => { 'b' => '' },
        'b' => { 'b' => '' }, 'em' => { 'i' => '' },
        'i' => { 'i' => '' }, 'u' => { 'u' => 'single' }
      }

In my mind these are great candidates to define in a configuration module. The config could be altered by the user allowing them to support more styles, HTML tags, etc. to suit their needs when our defaults aren't sufficient. This fits right in with your proposal to make HTML conversion more extensible by the end user. I just couldn't think of how to make it extendable when you first brought up the idea.

What is your opinion on implementing a Sablon.config module to store all of these defaults?

from sablon.

@senny I have implemented support for the <s>, <sup> and <sup> HTML tags in my branch support-sup-and-sub-tags. Initial support for parsing of HTML tables is in branch support-table-tag. Both of these future PRs rely on the refactors added by #55.

I'll make PRs for those once we get the details of #55 worked out.

from sablon.

I also have support for parsing HTML tables into WordML tables with proper styling implemented on a branch in my fork. Its not perfect, because you can't nest additional block level tags (i.e. <div>, <p>, <ul> and <ol>, <table> inside a <td> element.

It appears that it would take a pretty major refactor of the AST generation to handle those tags inside a table cell. MS Word has no notion of paragraphs inside paragraphs (block level inside block level) and the current AST builder is built around that logic. Table cells can hold anything so they end up being an exception to the rule.

from sablon.

Just to give you an idea about capabilities could be handled by having HTML insertion: https://docxtemplater.com/demo/#html

from sablon.