Re: Inline HTML

Tab Atkins Jr.
...
>
> The reasoning behind us moving to include HTML more directly is that
> using <foreignObject><html xmlns=...>etc is pretty inconvenient, for
> something we'd like to make easier and more convenient.

At least this defines some viewport, that can be used to put the XHTML in
and it defines the language used roughly with a namespace indication.

To fit into the concept how objects are positioned and dimensioned in SVG 
and that finally there is no need to have a visual presentation for (X)HTML
at all, this approach to provide some viewport for a graphical representation
looks reasonable. If one does not want this, aural presentation of the
(X)HTML might be reasonable as well, but do we really want this for
a graphics format as default, if (X)HTML is embedded? An aural
presentation needs no positioning or viewport - but it may cause
accessibility problems as well for some users, for example if they
have no audio output.

>
> > HTML tag soup inside an XML language like SVG might
> > be complex - because one needs a specific tag soup parser
> > for this, not just an XML parser.
> > And it might be a lot of work for SVG to define rules for
> > non XML content to transform it to something meaningful.
>
> The HTML parser is completely defined.

Currently one does not need such an tag soup parser for SVG
and not all SVG viewers are HTML viewers as well - not sure,
that it uses an XML parser, but Batik/Squiggle does not care
about HTML. 
And in general it is a high burden for people interested in
implementing only SVG, if it suddenly requires a complete
HTML tag soup parser - it may take years to implement this ...

>
> > Once I suggested something to include just raw data
> > without any tags for interpretation in SVG, to make such
> > data accessible and SVG somehow useful and accessible
> > for scientific applications, but this was already rejected to be
> > too complex. Rules for tag soup are far more complex as can be
> > seen by the HTML5 drafts, that try to define some
> > behaviour for this ;o)
>
> There's a difference between "complex and undefined" and "complex, but
> completely defined, to the last detail".

I did not claim, that the HTML5 behaviour itself is complex and undefined.
If it is complex, it  is not undefined ;o)
Undefined is simple - everyone is free in interpretation, because it has no
defined meaning - this is not complex.
Because one cannot indicate with HTML5 syntax or more generic syntax for 
documents, that it is HTML5, there is not really a defined interpretation 
possible - the (abstraction of a reference to the) definition is missing.
If you put it somewhere in a SVG document, because it has no namespace and no
version, questionable, that one can distinguish this from other arbitrary text 
content, as one cannot for separate complete, maybe HTML5 targeting
documents - that it is intended to be HTML5 remains in the privacy of the
author ;o)
For example if we take desc or metadata - those can contain plain text or
content from other XMLs formats - without something like a namespace,
how to indicate, that something specific is used? Without, it does not
represent more than the plain text content itself.

If SVG starts to define from the scratch how to interpret arbitrary text
fragments outside of a CDATA-environment in an XML document, 
it might get complex ;o)
Fortunately in SVG one does not have to care about such legacy
syntax as HTML has to,  because it has all the XML benefits right 
from the start.

And with my limited experience in parsing data, it is far more simple to
parse numbers separated with whitespace or comma than parsing
arbitrary content looking similar to XML, but having a different behaviour
and structure in detail.


Olaf

Received on Saturday, 16 November 2013 18:32:40 UTC