| 02:42 | <MikeSmith> | HughP: in general about name values for the meta attribute, there’s really never any discussion about them. Instead, it’s a free-for-all: People use whatever they, with no coordination/collaboration |
| 02:43 | <MikeSmith> | ... so there’s a lot of known redundancy, and a lot of values that people are using that are effectively private values that nobody else in the world cares about |
| 02:45 | <MikeSmith> | And that’s why the spec was changed (several years ago) to no longer require meta[name] values to be registered. So any name value you choose to use is valid now — without you needing to register it |
| 02:48 | <MikeSmith> | so IMHO at this point there’s not any real value in practice to adding any name values to the https://wiki.whatwg.org/wiki/MetaExtensions page |
| 02:49 | <MikeSmith> | nobody’s curating that page — and as you’ve found out, it has the big disadvantage that you need to have somebody create an account for you in order to add anything new to it |
| 06:03 | <HughP> | MikeSmith Thank you for pointing out https://html.spec.whatwg.org/multipage/semantics.html#other-metadata-names That was really helpful, and indeed I have seen some meta values in the wild which are not listed on that wiki page. I was wondering if this was an "every man for himself" sort of world. All the same the living standard still says that it |
| 06:03 | <HughP> | is good to consult the wiki page you reference as that is there to "advertise" that one is using such a tag. So, there should be some method for following through with the recommendation in the standard. |
| 07:33 | <noamr> | Hi Domenic! I have done some research work regarding tooltip/top-layer (https://github.com/whatwg/html/issues/4633). I have some bandwidth and I want to advance that work (I work on this on behalf of wikipedia) |
| 07:33 | <MikeSmith> | HughP: Yeah we originally anticipated that more actual coordination/collaboration would emerge around meta names, but it never ended up happening at all |
| 07:47 | <annevk> | MikeSmith: are you saying browsers shouldn't use new <meta name> values? Is that what's happening in practice? Otherwise it still seems useful to register, at least to inform implementers as to what values might step on someone else |
| 08:13 | <HughP> | annevk What I have seen in practice is that name_spacing is occuring. The case I am thinking about is that I have seen some meta tags which I presume are part of Webtrends Parameters package. http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf they take the form wt.xxx which |
| 08:13 | <HughP> | seems to be the way that they are name spaceing their tags. |
| 08:13 | <annevk> | That seems fine |
| 08:14 | <HughP> | that is I have seen some wt.xxx tags which are not in the documentation or the wiki |
| 08:15 | <annevk> | It still does seem somewhat useful to me if those are registered. Also for people trying to figure out what they might mean. But those names are also unlikely to clash with anything a browser might add. |
| 08:16 | <annevk> | Perhaps we should move https://wiki.whatwg.org/wiki/MetaExtensions to a Markdown page on https://github.com/whatwg/html so it can be easily PR'd by anyone with a GitHub account |
| 08:16 | <HughP> | yea, I really don't have a problem with that at all. It makes sense. I'm initially asked my question because I wanted to know if anyone had implemented DCMI's endorsement of the MARC relator vocabulary, as a refining element of the DC.Creator tag. I have seem some examples in XHTML but nothing in html5. |
| 08:17 | <HughP> | +1 to using github and PRs |
| 08:46 | <annevk> | noamr: it sounds like TabAtkins will take a look or is there something you still need from me? |
| 08:48 | <annevk> | andreubotella: I guess I should review your questions before merging... |
| 08:50 | <annevk> | andreubotella: I like the idea of run pushing end-of-queue |
| 08:52 | <annevk> | andreubotella: maybe even make Process do it |
| 08:52 | <annevk> | andreubotella: as that does all the pushing to the queue already |
| 08:54 | <annevk> | andreubotella: I'm not sure what to do about the fatal error case; I lean towards not pushing end-of-queue in that case but I suppose I could go either way |
| 08:59 | <annevk> | andreubotella: left a variant of this thought process on the PR |
| 08:59 | <noamr> | annevk: TabAtkins took a look, and said that the decision was made regarding orientation/same-origin... What I ask from you is to understand whether we can now unblock the conversation about resolution based on that decision |
| 09:00 | <annevk> | noamr: so the decision is still the same and the compat concerns do not carry weight? |
| 09:01 | <noamr> | that's what TabAtkins said earlier. |
| 09:02 | <annevk> | It would be good to see some signs of implementers committing to that, but I guess I can take a look at things assuming that's all in order... |
| 09:03 | <noamr> | annevk: in either case, the recent conversation about resolution has progressed in a way where it doesn't expose resolution to the embedder |
| 09:03 | <noamr> | and unlike orientation, it carries a significantly smaller baggage in terms of web compatibility |
| 09:05 | <annevk> | noamr: so I don't understand the same origin check before processing the metadata |
| 09:05 | <annevk> | noamr: I thought the plan was to always process the metadata, but hide it to certain APIs, depending |
| 09:05 | <noamr> | annevk: right, I haven't posted a new PR yet. I meant in the comments. |
| 09:06 | <MikeSmith> | annevk: the meta[name] values that browsers use get added directly to the spec, right? not to the wiki page |
| 09:06 | <noamr> | the idea was to change the behavior of srcset when EXIF resolution exists, so that you can't detect the EXIF resolution with it |
| 09:06 | <annevk> | MikeSmith: once browsers tell us, yes, but what I'm saying is that it would still be nice if browsers could check their new idea doesn't clash with an existing thing |
| 09:07 | <MikeSmith> | ah I see |
| 09:08 | <annevk> | noamr: I think the better way would be to let the image decode process take care of using and stripping EXIF data in case it's an opaque image, so we don't have to change all the callers |
| 09:09 | <noamr> | annevk: yes that makes sense. If srcset is not an issue, almost all the code for this can be an image-decoder implementation detail |
| 09:09 | <annevk> | noamr: anyway, iterating on this doesn't seem blocked to me; but I do think we need to get a bit further with resolution (including bugs filed and some intent to follow through) to be certain |
| 09:10 | <annevk> | noamr: if the image decode process did that you couldn't tell with srcset, right? Or am I missing something? |
| 09:10 | <noamr> | annevk: correct. |
| 09:10 | <noamr> | the reason why this was leaking outside of the image decoder was for srcset |
| 09:10 | <annevk> | MikeSmith: the other thing we could maybe say about <meta name> is that if you want to make shit up, consider using a character outside a-z |
| 09:11 | <noamr> | it would need to leak again for non-opaque images if we implement css image-resolution |
| 09:11 | <annevk> | MikeSmith: [a-z-]+ is what I would expect browsers to use for eternity |
| 09:11 | <MikeSmith> | annevk: yeah, that is a concrete idea worth pursuing |
| 09:12 | <annevk> | noamr: for non-opaque images we wouldn't make the EXIF built into the image data so that should be fine; for opaque images it would always appear to be missing |
| 09:13 | <MikeSmith> | annevk: but I also wish browsers would no longer use meta[name] to add anything. Next time it comes up, I hope an alternative is used. Before it becomes too late again |
| 09:14 | <MikeSmith> | the past pattern has been that browser projects have just unilaterally added their own meta[name] things, and then we ended up retroactively speccing it |
| 09:14 | <annevk> | MikeSmith: I have the feeling Apple and Microsoft and maybe Google as well do that thing on the regular |
| 09:14 | <MikeSmith> | iirc |
| 09:14 | <MikeSmith> | well I wish we could convince them to stop doing that |
| 09:14 | <MikeSmith> | it’s an abuse, IMHO |
| 09:16 | <annevk> | Not much disagreement there, depends a bit on how impactful it ends up being, but not really sure how to move the needle on that |
| 09:16 | <MikeSmith> | yeah |
| 09:22 | <noamr> | thanks for now annevk, I'll come up with a PR soonish |
| 09:22 | <annevk> | 👍🏻 |
| 10:56 | <andreubotella> | annevk: So I'll go ahead and not push end-of-queue on the failure case if that's okay |
| 10:57 | <annevk> | andreubotella: yeah that sounds good |
| 10:57 | <andreubotella> | ok |
| 10:57 | <annevk> | andreubotella: as I mentioned there, for the streaming fatal case we'll need a new hook anyway |
| 11:02 | <annevk> | andreubotella: perhaps that also means we should be a bit more restrained with where we add outparams for output |
| 11:02 | <annevk> | meh, I guess it's okay |
| 11:03 | <andreubotella> | my intention was to make all hooks usable for streaming if the output param was given |
| 11:04 | <andreubotella> | otherwise, `output` is created empty and eventually an end-of-queue is pushed to it before it gets returned |
| 11:04 | <andreubotella> | which btw, I'd appreciate some review on the optparams, since the infra PR is still under some discussion |
| 11:04 | <andreubotella> | Domenic? |
| 11:52 | <annevk> | jgraham: do you know offhand if Python 3 removed Error()? |
| 11:52 | <annevk> | Is Exception() basically equivalent? |
| 12:39 | <jgraham> | I don't think Error is a Python thing in Python 2? |
| 12:39 | <jgraham> | What are you trying to do? |
| 13:09 | <annevk> | jgraham: refactor a script that does raise Error(), but I'm not sure the path is ever triggered |
| 13:13 | <jgraham> | In [1]: raise Error() |
| 13:13 | <jgraham> | --------------------------------------------------------------------------- |
| 13:13 | <jgraham> | NameError Traceback (most recent call last) |
| 13:13 | <jgraham> | <ipython-input-1-630691b4ad4f> in <module>() |
| 13:13 | <jgraham> | ----> 1 raise Error() |
| 13:13 | <jgraham> | NameError: name 'Error' is not defined |
| 13:13 | <jgraham> | (python 2.7) |
| 13:13 | <jgraham> | So yeah, that should be Exception |