search

w3c / imsc

TTML Profiles for Internet Media Subtitles and Captions (IMSC)
https://w3c.github.io/imsc/
Other
31 stars 17 forks source link

Permit CSS font matching and font-face mapping #517

Closed nigelmegitt closed 4 years ago

nigelmegitt commented 4 years ago

Closes #516 :

Preview | Diff

css-meeting-bot commented 4 years ago

The Timed Text Working Group just discussed Permit CSS font matching and font-face mapping imsc#517, and agreed to the following:

The full IRC log of that discussion <nigel> Topic: Permit CSS font matching and font-face mapping imsc#517
<nigel> github: https://github.com/w3c/imsc/pull/517
<nigel> Pierre: I have one last editorial comment.
<nigel> Nigel: Also Glenn raised more substantive comments, let's do those first.
<nigel> Glenn: 1. On the font-face issue, we didn't actually discuss the font-face matter at the last meeting as
<nigel> .. far as I recall. It doesn't make any sense at all as far as I am aware to even mention font-face because it
<nigel> .. has no relevance to us because there is no way to refer to font-face in our context whatsoever.
<nigel> .. We don't have any way to put font-face in our content, syntactically, so any use of it would have to be
<nigel> .. completely out of the scope of TTML or IMSC unless I'm missing something.
<nigel> Nigel: We did discuss font-face and the intent here is to say that using the font-face algorithm is compatible with
<nigel> .. the TTML font matching semantics which are implementation defined.
<nigel> Glenn: The font-face rule describes a syntax. I thought from last week we were only talking about CSS Fonts §5.1
<nigel> .. The first paragraph, by itself, is perfectly fine and is exactly what I thought we agreed last week, and I think it is
<nigel> .. sufficient. Anything else is extraneous. The implementation can decide all the details.
<nigel> .. It's going overboard by putting extra hints on what the implementation might do.
<nigel> .. You're saying "implementor, here are other things you might think about", but I don't see that as a necessary hint.
<nigel> Nigel: I thought it is unclear what we mean unless we explain the mapping.
<nigel> Glenn: I think implementers will find it obvious so the table is not necessary.
<nigel> Pierre: Just for my own clarification, which paragraph are you referring to?
<nigel> Glenn: I'm suggesting deleting the paragraph about the font-face rule, and just leaving the first new one
<nigel> .. that says the font matching algorithm in place.
<nigel> Pierre: That would address my comment as well.
<nigel> .. My question was why have those two paragraphs disconnected.
<nigel> .. From an implementer it was weird that I could use one without the other.
<nigel> .. If the conclusion is the first one is sufficient then it would be good to keep just that one.
<nigel> Glenn: In the note, the first sentence is already written into the text of the spec, so it isn't needed.
<nigel> Nigel: You think the second sentence works without the first one?
<nigel> Glenn: OK if we just remove the last sentence we could keep this.
<nigel> .. For locality of reference, put it after the new paragraph about the font matching algorithm.
<nigel> Nigel: That works for me.
<nigel> Glenn: Thank you for accommodating me.
<nigel> Nigel: Not at all, feedback very welcome.
<nigel> Pierre: That change would address my comments too.
<nigel> Nigel: Okay, I will implement that in the pull request.
<nigel> SUMMARY: @nigelmegitt to amend pull request taking into account feedback from today's discussion.
nigelmegitt commented 4 years ago

Some notes for the record, not requesting any further change now:

I'm happy that we seem to have reached consensus here on at least this edit (allowing for future objections of course), but want to note for the record that in my view it does not fully address #516 since we are left with no normative language stating that an implementation that creates CSS properties and rules for presenting IMSC content can do so by mapping font elements to @font-face rules directly, and passing those rules to a CSS processor.

The discussion during yesterday's call included assertions along the lines that this is obvious from the text in this pull request and we can leave the rest to implementers. I'm not completely convinced about that yet but am prepared to leave this as is for now and see if a stronger need arises to be more explicit about it later.

So far, nobody has produced any technical argument to say that mapping font elements to @font-face rules would not be conformant as an implementation strategy.