Next in thread →
Next in month →
Re: [dita-lightweight-dita] Refactoring HDITA with custom tags
For HDITA, it would be nice to offer authors this shortcut:
<dt>No para in HTML</dt>
<dd>No para in
HTML</dd>
<li>No para in HTML <p>Unless maybe this one.</p></li>
since we can infer the XDITA wrapping for the
non-para portion easily enough.
Likewise in Markdown, when an indented paragraph
follows a list item entry, both blocks receive <p> wrappers
when converted into HTML (see the last part of LISTS here:
https://daringfireball.net/projects/markdown/basics). In this
regard, I think that "authoring HDITA" can be regarded the same
way--as an authoring vehicle with regular shortcuts from which
architecturally required markup can be constructed.
--
Don
On 5/11/2016 12:20 PM, Michael
Priestley wrote:
I was just applying
the same constraints
as in XML - you can have multiple paragraphs, just no text
outside the
para.
Is there a reason we'd want to
allow
mixed text/para models in HDITA, even though we've eliminated
them from
XDITA?
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
http://dita.xml.org/blog/michael-priestley
From:
Carlos Evia
<>
To:
Don Day
<>
Cc:
Date:
05/11/2016 11:50 AM
Subject:
Re:
[dita-lightweight-dita]
Refactoring HDITA with custom tags
Sent by:
<>
That paragraph in list items came from Michael’s
original
HDITA draft.
Carlos
--
Carlos Evia, Ph.D.
Director of Professional and Technical Writing
Associate Professor of Technical Communication
Department of English
Center for Human-Computer Interaction
Virginia Tech
Blacksburg, VA 24061-0112
(540)200-8201
On May 11, 2016, at 11:29 AM, Don Day <>
wrote:
So on to content models in the live converter...
Carlos' examples tend to follow the convention of including a
p wrapper
inside list items and definition components. I added a
look-ahead in these
contexts to add a p wrapper if the first node was not a p
node, and this
now works equally either way for samples like this:
<article>
<h1>The point of it all</h1>
<p>I can sum it up here</p>
<p>I can say some more stuff</p>
<section>
<h2>Stuff</h2>
<p>And so on</p>
<ul> <li>This</li>
<li>Is></li>
<li>A List</li> </ul>
</section>
<section-example>
<h2>And more stuff</h2>
<p>With its own explanation</p>
<dl>
<dt>No para in HTML</dt> <dd>No para in
HTML</dd>
<dt><p>With para</p></dt>
<dd><p>with
para</p></dd>
</dl>
</section-example>
</article>
(try this in the paste box to see the lw topic result)
But this brings up a question: can list items and definition
descriptions
only have one paragraph? That is what this tool will do (or
wrap the mixed
content example in a possibly redundant paragraph). I think it
is a blessing
to remove syntactic complexity from student authors, so I hope
the HDITA
minimal case can relax the required paragraph burden, but
tools then need
to have the right remediations for going into XDITA.
I realize that Markdown has no such ambiguity because you
cannot start
a list item with a required paragraph anyway. In the Markdown
case, then,
do you get only the one inner paragraph implied by the XDITA
requirement?
__
Don
On 5/11/2016 8:16 AM, Carlos Evia wrote:
Oh I had some Polymer nightmares last year, but I
think
most browsers play with custom tags now. Safari still doesn’t…
but that
probably will change soon.
I like that Don’s http://ditax.ml/hd/experiment allows an author to enter an
<article> without any fancy
custom tags and the result is a generic DITA topic. Jarno’s
Markdown plugin
does something similar: an author can create a Markdown file
without fancy
classes or extensions, and the result is a generic DITA topic.
Of course, then authors can specialize to
concept, task,
reference as needed… but this gives people a Lightweight DITA
base architecture
(think of the “Why three editions?” white paper that came with
DITA 1.3).
You can be a casual contributor and create a simple topic in
Markdown or
HTML5 and then someone else will mix it with XDITA or DITA.
That’s an
excellent way to make Lightweight DITA accesible (and easy)
before getting
into complicated markup/markdown like what we saw in the
Bluemix examples.
Carlos
--
Carlos Evia, Ph.D.
Director of Professional and Technical Writing
Associate Professor of Technical Communication
Department of English
Center for Human-Computer Interaction
Virginia Tech
Blacksburg, VA 24061-0112
(540)200-8201
On May 10, 2016, at 11:50 PM, Mark Giffin <>
wrote:
Hi Michael,
If you are talking about custom tags as in late-model W3C web
components,
a custom tag can be pretty lightweight, since the browser
itself will support
this capability (not sure if all major browsers turn them on
by default
yet). You don't have to load an external library necessarily.
It needs
a bit of _javascript_ that can be inside the HTML file itself.
I'm not sure
about performance, I'm sure it depends on what you're doing.
Google's Polymer requires substantial external libraries and
Polymer often
gets confused with W3C web components because it's related,
but I'm not
talking about Polymer. I recall some info about Polymer having
some performance
problems but that was a year ago.
This page gives a simple example of a W3C custom element with
some CSS
to style it.
https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements
Please excuse if I completely misunderstood your question!
Mark Giffin
Mark Giffin Consulting, Inc.
http://markgiffin.com/
On 5/10/2016 12:47 PM, Michael Priestley wrote:
How much freight does custom
tags add
to a displayable HTML page? Is there any impact on
performance?
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
http://dita.xml.org/blog/michael-priestley
From: Carlos
Evia <>
To:
Date: 05/10/2016
02:46 PM
Subject: [dita-lightweight-dita]
Refactoring HDITA with custom tags
Sent by: <>
Apologies (in advance) but I won't make it to the 05/16 call.
Continuing
the conversation about refactoring HDITA, I wonder how much
mixing of HTML5
custom tags (Don's proposal) and custom data attributes
(Michael's original
approach) we should keep. I have been experimenting with Don's
approach
to extend HTML5's native elements to mimic XDITA/DITA tags, and
I really
think we should explore that as HDITA's evolution path. It makes
authoring
much easier than having to remember the data attributes.
I compare here both approaches with the proto-example included
in the Technical
Communication paper I wrote with Michael:
Current HDITA model (based on Michael's 2014 idea)
<article data-hd-class="task">
<h1>How to do something</h1>
<p>Introduction to this specific task</p>
<section data-hd-class="task/context">
<p>Use only when ready</p>
</section>
<section data-hd-class="task/steps-informal">
<ol>
<li><p>Plan something</p></li>
<li><p>Do something</p></li>
<li><p>Evaluate something</p></li>
</ol>
</section>
<section data-hd-class="topic/example">
<p>Like this</p>
</section>
</article>
My aberrant take on Don's proposed use of custom tags:
<article-task>
<h1>How to do something</h1>
<p>Introduction to this specific task</p>
<section-context>
<p>Use only when ready</p>
</section-context>
<section-steps>
<ol>
<li><p>Plan something</p></li>
<li><p>Do something</p></li>
<li><p>Evaluate something</p></li>
</ol>
</section-steps>
<section-example>
<p>Like this</p>
</section-example>
</article-task>
Is there a third way that combines both approaches? What would
we gain?
Right now, moving to custom tags will only break a) my former
students'
projects, and b) Jarno's HDITA plug-in (which was pretty much
his experimental
contribution to our DITA NA presentation this year).
If this is a good idea, we (I) can work on re-mapping HDITA and
new examples....
and then we can move on to the headache of MarkDITA, MDITA or
however we
want to call the Markdown flavor of Lightweight DITA.
Comments?
---
Carlos Evia, Ph.D.
Director of Professional and Technical Writing
Associate Professor of Technical Communication
Department of English
Center for Human-Computer Interaction
Virginia Tech
Blacksburg, VA 24061-0112
(540)200-8201
--
Don
R. Day
Founding Chair, OASIS DITA Technical Committee (current
version: DITA
1.3)
LinkedIn: donrday
Twitter: @donrday
About.me:
Don
R. Day Skype:
don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
Virus-free.
www.avast.com
--
Don R. Day
Founding Chair, OASIS DITA Technical Committee (current version:
DITA
1.3)
LinkedIn: donrday Twitter:
@donrday
About.me: Don R. Day Skype:
don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
Virus-free. www.avast.com
Next in thread →
Next in month →