[jira] [Commented] (DOXIA-767) Clarify block vs inline semantics in Sink API

["Konrad Windszus (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DOXIA-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17905543#comment-17905543 ] 

Konrad Windszus commented on DOXIA-767:
---------------------------------------

Compare with https://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/conformance.html

{quote}
In elements where the 'xml:space' attribute is set to 'preserve', the user agent must leave all whitespace characters intact (with the exception of leading and trailing whitespace characters, which should be removed). Otherwise, whitespace is handled according to the following rules:

All whitespace surrounding block elements should be removed.
Comments are removed entirely and do not affect whitespace handling. One whitespace character on either side of a comment is treated as two white space characters.
Leading and trailing whitespace inside a block element must be removed.
Line feed characters within a block element must be converted into a space (except when the 'xml:space' attribute is set to 'preserve').
A sequence of white space characters must be reduced to a single space character (except when the 'xml:space' attribute is set to 'preserve').
With regard to rendition, the User Agent should render the content in a manner appropriate to the language in which the content is written. In languages whose primary script is Latinate, the ASCII space character is typically used to encode both grammatical word boundaries and typographic whitespace; in languages whose script is related to Nagari (e.g., Sanskrit, Thai, etc.), grammatical boundaries may be encoded using the ZW 'space' character, but will not typically be represented by typographic whitespace in rendered output; languages using Arabiform scripts may encode typographic whitespace using a space character, but may also use the ZW space character to delimit 'internal' grammatical boundaries (what look like words in Arabic to an English eye frequently encode several words, e.g. 'kitAbuhum' = 'kitAbu-hum' = 'book them' == their book); and languages in the Chinese script tradition typically neither encode such delimiters nor use typographic whitespace in this way.

{quote}

> Clarify block vs inline semantics in Sink API
> ---------------------------------------------
>
>                 Key: DOXIA-767
>                 URL: https://issues.apache.org/jira/browse/DOXIA-767
>             Project: Maven Doxia
>          Issue Type: Task
>          Components: Documentation
>            Reporter: Konrad Windszus
>            Priority: Major
>
> The javadoc of https://maven.apache.org/doxia/doxia/doxia-sink-api/apidocs/org/apache/maven/doxia/sink/Sink.html should be clarified with regards to trimming whitespace behaviour for block/inline elements. Not necessarily each block Sink element is a block element in the desired output format (e.g. XHTML). Most prominently this is the case with
> {{Sink.verbatim(Decoration:source)}} which is a block element in Sink API but opens an inline element ({{<pre><code>}}) in XHTML.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)