#ZegnatAll the rel parsing seems to be inside a single method, so it is a good way to get my toes wet with the php-mf2 project
#ZegnatOh, gRegorLove, you didn’t need to escape the hyphens in the regex for the new classes.
#ZegnatHyphens only have a special meaning within character classes ([]). Though it doesn’t hurt to escape them outside it is unneccessary.
#Zegnat(The regex looked like the one I wrote for KartikPrabhu, except for the ^ $ and the hyphen escapes, which is why I spotted them in the first place.)
tantek, [kevinmarks] and nitot_ joined the channel
#ZegnatGitHub confirms it, this is my first PR on the mf2 PHP parser. I almost can’t believe that. Guess my contributions so far have just been bickering about the spec itself.
[kevinmarks] and Garbee joined the channel
#KartikPrabhuZegnat: I think textContent should be specified more clearly in almost all places it occurs
#ZegnatYes, although for the parsing of values on hyperlinks, I think it is fine to at least specify “text content” as being the true textContent property of the element
#KartikPrabhusure but whether empty strings are allowed or not (and before/after leading space stripping) should be mentioned
#ZegnatAh, I didn’t bring up space stripping on that issue I believe
#Loqi[Zegnat] #32 Clarify attribute properties added to objects in rel-urls.
[manton] joined the channel
#ZegnatSince we are making some good process on the rel parsing now, it would be nice to get that clarified (and shipped) before the next stable versions
#Loqi[kartikprabhu] `text` should also specify the following
1. Is empty string checked before/after stripping leading and trailing spaces i.e. is `text: " "` considered valid?
2. Should child `<style>` and `<script>` elements be dropped before?
3. Should child `...
#ZegnatThanks KartikPrabhu! Updated my proposal :)
#KartikPrabhuZegnat: your alt and src rule is missing <img>
#KartikPrabhuit might be better in the spec to specify textContent in one place and refer it from others
#ZegnatHuh, that must have been a weird GitHub & HTML bug. I coped this from #17. Will fix in a second
#ZegnatI think bringing textContent out into its own chapter is something that must be done for #17, so I am willing to wait with that if we can get rel parsing clarified sooner
#ZegnatHa, when I click edit on my comment, the <img> shows! Well done GitHub Markdown. I’ll go put ` around it
#ZegnatI have that testing JS implementation. But actually writing it down into a implementable (and comprehendable) spec, rather than just pointing at that code, is a different matter
#ZegnatBasically I am saying “keep the first non-empty value”, rather than “keep the first value”.
#ZegnatPlease do comment with hesitations though! All is important :)
#gRegorLoveUnderstood. But it's discarding the first (empty) authored one. It "feels" like the parser's trying to fix a publisher mistake.
chrisaldrich joined the channel
#KartikPrabhuZegnat: which mf2py are you looking at for that?
#ZegnatI always look at your dev version these days KartikPrabhu
#KartikPrabhuhmm it really shouldn't discard the empty values!
#tantekindeed, consider the author perspective before any theoretical / academic / purity perspectives
#tantekif an author expliictly provides an empty attribute, they went to some work to do so, therefore there is likely some intent there
#ZegnatI was considering an empty title for a URL, followed in the same document by a specified title for the same URL, to be likely not worth keeping. Instead keeping the authored value.
#tantekI think you're overthinking it with a theoretical example
#tantekand IMO that's enough to reject that line of thinking
#tantekthat is, a theoretical example is insufficient to justify a change
#tantekwhereas I've just given you a theoretical *feature* that exists in the status quo. you provide no reason to remove it.
#tantekyou cannot make assumptions like "Clearly the empty string adds no information about the URL"
#tantekthe author's explicit authoring was considered, without any opinion about whether it adds information or not
#ZegnatExcept it does not add any information is this specific case. An empty string for `media` means nothing at all. While if the author specifies a correct media value later in the page we should probably tell our consumer about that useful information.
#Loqi[kartikprabhu] #65 rel-urls use last value instead of first one
#ZegnatBut please comment on the issue so the spec change proposal can be adjusted :)
#ZegnatThis isn’t arbitrary text like a p- property, we are talking about metadata on URLs. Empty meta data has no meaning. If the author doesn’t have the correct meta data to provide, just leaving the HTML attributes off is perfectly fine.
#ZegnatBut I am happy to revise the proposal again if I am the only one who thinks this
#KartikPrabhuactually from a debugging HTML point of view I would think an empty value would be more of a red flag
#ZegnatAnd, yes, gRegorLove. I do believe my patch will get `author` there
#tantekagain you cannot assume this: "Empty meta data has no meaning." it's like saying zero has no meaning.
#tantekZegnat "if I am the only one who thinks this" does not matter how many people agree on a theoretical
#ZegnatThe resource at URL is written in language "" and of type "".
#ZegnatI can say that because we are talking about very specific metadata here. What exactly does it mean when you say:
#ZegnatWhen the HTML provides us with a specific language and type later on the page, I would want to know about these. Because they only mean something when they are defined.
#ZegnatThat’s the point I am trying to make. We are talking about very specific metadata about URLs with specific relationships.
#KartikPrabhuZegnat: mf2 consumers are free to neglect that as meaningless but I think the mf2 parsed output should be closer to authored HTML
#ZegnatThen I propose it returns all the things it finds, if you want it to reflect everything authored in the HTML.
#Zegnatsource order definitely makes sense for title and text. I am wondering if hreflang, media, and type are unordered sets like rel or not.
#KartikPrabhuwhat was the consuming side use of the rel-urls properties again? They were added later
#ZegnatNo clue. I only ever use the rels property. Do not think I have ever consumed rel-urls. I was just working on the PHP parser for it and wanted to iron out some things I thought were inconsistent.
nitot joined the channel
#KartikPrabhu!tell aaronpk snarfed: do you guys consume the rel-urls from the parsed mf2?
#KartikPrabhuso [kevinmarks] would be the one to ask
#Zegnat“no need for array for "name"/textContent - since there is always only one at most” - I don’t understand this argument
#ZegnatThe spec incorporated adding more properties from links encountered later in the document. So it was already known that there could be multiple values.
#ZegnatShould add all of this to the issue later...
#[kevinmarks]The rel-urls use case was xfn where you have <a href="http://tantek.com" rel="friend colleague met" >t</a> and you don't want to ha even to walk the rels and collate urls yourself
#[tantek]KartikPrabhu the parsed rels were added afterwards, as kevinmarks notes, for specific use cases and real world examples
#[tantek]So I’m going to oppose all theoretical proposed changes to anything real related, especially if reasoned from a “consistencies in the [parser] code” perspective. That’s very bad pluming-centric reasoning
#[tantek]Seriously if you don’t have a real world example that you need to consume and the current parser spec is failing you, please stop proposing such changes. It’s a waste of time to pursue theoretical purity
#[tantek]That’s math/philosophy, not science. And here we are doing science
#[tantek](As any spec / code that deals with actual human published data / content should )
#KartikPrabhuok I am not very invested in this anyway. not my hill