Drop requirement to use polyglot syntax

kornelski commented 9 years ago

I suggest dropping requirements to use XML-like syntax.

Technically there's absolutely no benefit in using XML syntax if it's not guaranteed to be 100% right 100% of the time (and even then I'd argue there's no point). In non-trivial projects in practice that requires use of serializers rather than text-based templates. It's even harder to generate working polyglot documents, so in practice we're calling for use of XHTML syntax in documents that are quite unlikely to actually work as XHTML.
I don't agree that use of self-closing talisman is helping newbies. Pretending that it closes elements causes confusion and real errors with elements such as <script/>, <iframe/> and <a name/>. In practice it's required to know "which elements allow />", which is exactly the same as knowing empty elements.
Overuse of /> is more likely to cause invalid DOM than overuse of closing tags, e.g. this creates valid DOM:
```
<!DOCTYPE html>
<head><meta></meta><link></link>
<p>foo<img></img>bar
```

kaelig commented 9 years ago

Good debate to have, thanks for opening the discussion.

Using a XML-like syntax isn't a requirement for products but we want to have a consistent code formatting across Origami modules and the documentation.

It seems that embracing the XML-Like syntax removes ambiguity, and as a result makes the HTML easier to understand / edit.

This code is valid but contains ambiguities:

<ul>
    <li>Look 'ma, no closing tag!
        <ul>
            <li>Confusing imbricated list
        </ul>
</ul>

<p>Look 'pa, no closing tag!

<img src=blah.jpg alt>
<img src=blah.jpg alt=OneWord>
<!-- Spaces in an attribute, now quotes are needed -->
<img src=blah.jpg alt="Two Words">

Less ambiguity = less brain cycles necessary to understand the code which makes it easier to debug.

Hope that makes sense.

kornelski commented 9 years ago

Depends what you mean by ambiguous. It's definitely parsed exactly the same way by all user agents and there's no ambiguity about it in the spec.

For lists I actually think omitting </li> is more robust— makes certain cases of invalid DOM impossible:

<ul>
  <li>this is a list:
   <ul><!-- nested ok -->
   </ul>
</ul>

<ul>
   <li>this is a list:</li>
   <ul><!-- error -->

kornelski commented 9 years ago

However, nitpicking details aside, I think the general case is — what's the scope of Origami?

Does it define a standard for interoperability?
Does it define rules necessary to prevent errors?
Does it define what is good taste?

I think Origami is going far into territory of the point 3, and I don't like it. Things like "it's readable" and "intuitive" are subjective.

I'd like to avoid "must" around things that are just a subjective opinion and making "I like it that way" a MUST requirement for everybody.

samgiles commented 9 years ago

I don't think the spec should enforce a style unless interoperability is affected, but I do think all the examples should be presented in a consistent way; if that's XML style syntax because it's likely to be familiar or less confusing to a broader audience, we should go with that. As long as it's consistent.

kavanagh commented 9 years ago

This requirement was included in the spec so as not break XML parsers used in existing server-side components - mainly FT.com Render. Some origami services may output HTML that could end up being parsed by these strict/finicky parsers.

kornelski commented 9 years ago

I've discussed with Luke how integration with XML pipeline could look like, and we've come to conclusion that parsing of markup is not the best option for integrating with Origami services or components, e.g.:

Tweet Service gets tweet content from Twitter API.
Then Tweet Service uses tweet component to response to client with a document fragment containing the tweet formatted as origami XHTML
A server-side component such as FT.com Render consumes this service and (using XSLT) decorates the XHTML it receives with a couple of extra classes.

The problem with this is that XHTML output becomes an API. The client will end up relying on specific tags and classes being present in the markup, so the service can't change anything in the output without risking breaking somebody's XSLT somewhere.

If we were serious about parseability of Origami's XHTML we would have to have strict rules about presence of xmlns and add automated well-formedness checks to the buildservice/registry, because hand-written markup and Mustache templates don't care about well-formedness, so it's too easy for XML to rot.

Having services output JSON and consumers run Mustache themselves gives much stable and reliable API. So services should offer output format that can be parsed and customized, but XHTML is not a good tool for this job.

triblondon commented 9 years ago

My concern is literally just to write and present code in a way that offers the shallowest learning curve to developers. I don't think we commonly need to process HTML as XML, and no-one seems to be advocating that our markup should be valid XML, nor that we have any responsibility to make it parseable.

I don't see this as being polyglot syntax - I mean, you could say that <div>hello</div> is polyglot too since it's valid XML, and it would clearly be nonsensical to say that we should intentionally ensure that our code is never valid XML.

I like the convention, I think it's useful. For the same reason that I strongly disagree with not closing block elements simply because the parser will let you do it - it makes the code harder for me to understand.

triblondon commented 9 years ago

We discussed this at the Origami spec meeting today. While there aren't any opposing views here as strongly held as Kornel's is, there's a clear majority of opinion in favour of consistently using /> as one of a few rules extending the requirements of HTML5:

http://origami.ft.com/docs/syntax/html/#html-standards

So we'll keep these as-is for the moment.

kornelski commented 9 years ago

Thanks for considering this.

Financial-Times / ft-origami

Drop requirement to use polyglot syntax #296