Should a consecutive run of dashes (-) be allowed in root and property class names?

[Zegnat]

Brought up by @sknebel:

h------

This looks to me to be valid, but maybe it shouldn’t be.

[Zegnat]

It would also be an option to only allow single dashes when there is another symbol both before and after. This means a name cannot start with it (as in p--starts), end with it (as in p-ends-), or have multiple consecutives (as in p-multi--ples).

This basically only allows them as strict delimiters. Possibly encouraging semantic class names.

[kartikprabhu]

+1

Implemented in https://github.com/kartikprabhu/mf2py/tree/experimental

[gRegorLove]

+1 for not parsing roots/properties with leading or trailing multiple dashes.

Neutral for multiple dashes in the middle, though I could easily be convinced of that for simplicity. Contrived example: if someone published u-in-reply--to would it be better debugging for it to show up in the parsed result?

php-mf2 currently parses:

<div class="h-entry h-----">
<p> <a href="http://example.com/post" class="u-in-reply--to">http://example.com/post posted:</a> </p>
<span class="p-name">Too many dashes</span>
<span class="p--acme-leading">leading dash</span>
<span class="p-acme--middle">middle dash</span>
<span class="p-acme-trailing-">trailing dash</span>
</div>

        {
            "type": [
                "h-----",
                "h-entry"
            ],
            "properties": {
                "name": [
                    "Too many dashes"
                ],
                "-acme-leading": [
                    "leading dash"
                ],
                "acme--middle": [
                    "middle dash"
                ],
                "acme-trailing-": [
                    "trailing dash"
                ],
                "in-reply--to": [
                    "http://example.com/post"
                ]
            }
        }

@kartikprabhu's dev version of mf2py parses:

        {
            "type": [
                "h-entry"
            ], 
            "properties": {
                "name": [
                    "Too many dashes"
                ]
            }
        }

[Zegnat]

Contrived example: if someone published u-in-reply--to would it be better debugging for it to show up in the parsed result?

I personally think I would be more likely to spot a missing property, than one with an extra dash typo. But this is an interesting question to ask.

Disallowing consecutive dashes may also get rid of some improper matches from CSS frameworks. E.g. the OOCSS pattern encourages using -- to create hierarchies. I’m not sure if we have encountered issues with that before.

[kartikprabhu]

I agree that I would be more likely to spot a missing property than go fishing for "typos". So this seems like a good reason to exclude all consecutive hyphens.

[gRegorLove]

👍 Ok, I'm on board with that reasoning.

[tantek]

Consecutive dashes were never intended in microformats2 class names, only as separators between [a-z] segments per original microformats naming principles: http://microformats.org/wiki/naming#Some_Details

I’ll make edits to capture this succinctly along with issues #27-30 (comments forthcoming), assuming no objections.

(Originally published at: http://tantek.com/2018/079/t1/)

[kartikprabhu]

+1
cc: @tantek

[Zegnat]

Spec was updated to only allow dashes as separators.