Meeting minutes
font enumeration API
Vlad: started roughly aroundthe same time as IFT in CSS wg
Vlad: they developed it too something that was then presented for review but the whole effort was stalled.
Vlad: wanted to check if there is interest in the group
Skef: to clarify, we're raising this as an independent effort to IFT for the WG?
Vlad: yes, if there is an interest we may be able to influence css working group to take action.
Skef: IFT issue related to this
Skef: there's all this access to webfonts in terms of getting at the bytes which we don't have for desktop fonts.
Skef: so web clients can do their own shaping
Skef: I'm not sure that we've thought that much about clients doing their own shaping with IFT.
Skef: for example if clients are caching data and then the fonts are changed by IFT.
Garret: not sure if this is to big of an issue, I think this use case is probably specialized and they likely also control the fonts being used.
Skef: suggestions when the font changes we updated it's ID or something like that.
Garret: spec is not really touching on this at the present. Likely intersects with css font api changes which are currently outside of the IFT spec.
Skef: so maybe we need to look at making changes to font api.
Garret: I've always thought we would likely eventually make changes to the css font api, but later on.
Skef: worried that we might break clients that aren't expecting font changes.
Vlad: font will always have sufficient data to render content.
Skef: implication is some clients are looking at bytes, maybe storing offsets
Garret: I think this is probably a pretty niche issue and clients where this is the case will have control over the fonts, so if they choose to use IFT they will need to be aware and act appropriately.
Vlad: Topic: Local font access API<br> there was a comment added to the recharter proposal if the fonts wg could consider taking up the effort for local font access api.
Vlad: this is not a formal objection.
Vlad: one option wg finishes IFT then decides to take on local font access api.
Vlad: second option is that we decide it's not really webfonts related.
Vlad: and instead make a new working group.
Skef: spec is stalled and looking for someone to take over. Implying that someone will take it into existence.
Skef: main reaction after a skim is that the privacy and security considerations is at best anemic. Relative to the concerns that have been expressed around IFT.
Vlad: before fonts group became a reality. Microsoft and monotype had a tech that was developed, embedded open type. Design for enabling compressed font data to be transmitted.
Vlad: the submission was heres the tech heres the spec lets make it a recomendation and establish the working group.
Vlad: establishing this group is a useful effort but rubberstamping as is wasn't in interest of community at large.
Vlad: developed something similar (WOFF1)
Vlad: then web fonts which was considered to be nice was widely used and because of that WOFF2 was developed.
Vlad: but used components from embedded open type.
Vlad: woff2 was reincarnation of embedded open type.
Vlad: all I'm saying is even if this proposal is taken up, we don't need to keep it as is.
Vlad: eg. we could drop parts that are considered privacy issues.
Vlad: something we might be interested in the future or maybe a new working group.
Garret: my opionin is we should just wait and watch, wouldn't want it to be a distraction to the IFT effort.
Skef: spec is talking about two separate things and maybe they could be separated out.
Skef: would be weird without also looking into the javascript apis for font loading.
Skef: looks like this is part of incubator group WICG, it might be the case that this is just something looking for a home and someone recognized that and raised it as a comment.
Vlad: incubator group can't produce standards document. So now they're looking for a working group to pick it up (existing or new)
Vlad: will need to be part of WG charter.
Skef: could be entirely formal, just looking for a home.
URI templates
Garret: concerns raised about complexity of our choice of URI templates. Few options: 1. restrict our usage to only level 1 (very simple), 2. write our own syntax. 3. Use URL patterns (not yet ready)
Garret: my opinion we should do 1 and say we're open to switching to 3 once its ready.
Skef: seems like there was concerns around percent encoding.
Garret: yes, the uri template spec isn't clear on whether to use lowercase or upper. We need to clarify that on our side.
Garret: also concerns about which specific codepoints are encoded or not, but after investigation I don't think that's aproblem.
Skef: the concern seems to be a mistaken understanding about the technology, more like WOFF2
Garret: I'll make the recommended spec changes and see if there are any further concerns.