Meeting minutes
<addison> trackbot, prepare teleconference
Agenda
Action Items
<addison> https://
action-925?
<trackbot> action-925: Addison Phillips to Update string-meta to include json-ld changes, etc. -- due 2020-07-09 -- OPEN
addison: started on that
action-946?
<trackbot> action-946: Addison Phillips to Create definition of 'ltr'/'rtl'/'auto' that can be referenced by other specifications in string-meta -- due 2020-09-03 -- OPEN
done by addison :)
close action-946
<trackbot> Closed action-946.
action-1017?
<trackbot> action-1017: Addison Phillips to Send wpwg list of specs that implement lang/dir -- due 2021-04-22 -- OPEN
addison: pending
action-1031?
<trackbot> action-1031: Addison Phillips to Document the state of payment-request -- due 2021-06-03 -- OPEN
addison: sent note to chairs, will keep action open until the github issue is update
action-1032?
<trackbot> action-1032: Richard Ishida to Propose text for html 4814 (datalist find/string search) -- due 2021-06-03 -- OPEN
richard: pending
action-1033?
<trackbot> action-1033: Addison Phillips to Create skeleton of "best practices for manifests" -- due 2021-06-10 -- OPEN
addison: done
close action-1033
<trackbot> Closed action-1033.
Info Share
Radar
<addison> https://
addison: css counter styles, richard responed to fantasai
… is "in review", is deeper review needed?
richard: did not see anything that is a concern for us
… small editorial thing has been fixed
… review is done, nothing to report
… we can move this to "done"
addison: any volunteer to read counter styles? just move it to done
xfq: I will have a look
richard: hope that this will be published as rec
xfq: chris and I go through all CSS specs, see what should be re-published
… need to look at the tests for counter styles
addison: so some period after CR publication will be available
xfq: last CR was 4 years ago
richard: the review I did is an update of the current spec
… not 4 years old, brand new again
addison: will go through normal CR & PR process
atsushi: resource timing and user timing, is completed, part of the agenda
… there is no issue for resource timing
addison: so I move the doc to completed?
atsushi: yes
addison: will do
… performance timeline is incoming
atsushi: will take this
xfq: closely related to timing specs
Review comments for timing specs
<atsushi> https://
atsushi: from level 2 to level 3, one feature was added
… convert to timestamp function
… in their ticket, "storing match" is defined as match
richard: what does a timestamp look like?
atsushi: something from page load, a numeric value
xfq: millisecond value
addison: since epoc, or millisecond lapsed?
atsushi: from epoch, I think
… but could be both, per implementation
atsushi: used to measure the marks between two points
… output from the two marks is important
richard: is the spec saying that they produce human readable output?
atsushi: user can define mark or @@@
<atsushi> https://
atsushi: see performance mark with text label
… each label can be defined by a developer
addison: developer can name them, but these are just IDs, the rest is just numbers (time of milliseconds)
atsushi: yes
atsushi describing various process options
addison: using "is" is a good use of this, because otherwise they do not define matches
<Bert> +1
addison: any objections about this comment? Other observations?
+1
<xfq> +1
addison: atsushi, please file the comment
… I will move the doc to "awaiting comment resolution"
CSS Counter Styles
<r12a> https://
<addison> https://
richard: there is a new version on TR
… xfq published the doc
… I published more docs yesterday
… counter styles changes are:
<r12a> https://
<r12a> https://
richard: section 1.1: we got examples about suffixes and prefixes
… seemed to me that it would start to make the doc very large
… so I say: we define the base algorithm
… and we say: we used the common default, and a note saying "these are common ways to do the affixes"
… so we have notes instead of dublicating the styles
… a section shows how to have a different separator, using the "extends" keyword
… andrew cunningham is still clarifying things, with a delay due to the situation in Myanmar
<addison> https://
<r12a> Alternative prefix/suffix styles
<r12a> https://
richard: I changed Myanmar, it used to have default space suffix
… parenthesis is more common, it seems
richard: moved japanese and korean stuff into "japanese and korean" section
… added bunch of other stuff
<r12a> https://
richard: we are in good position with the doc, I think
… also went through tests in the test suite and the gap analysis
addison: very cool!
… should this be a "statement" in the new process?
richard: no
… we update this regularly, once we get more information
<xfq> https://
richard: you can use whatever keyword you want
… so there is no "normative" recommendation, just stuff you may want to use
… also no intend to cover all things you need, or limit things
addison: ok
String-Meta
<addison> https://
addison: pull request has bidi keywords in it
… I added small subsection
… xfq commented that basically ltr and rtl refers to CSS, auto refers to definition in HTML
… question whether I should bring definitions here or put them by reference
… started to indicate difference between ltr and cases to bring in auto
… open the floor to comments
richard: there might places where you need to use metadata, which resolves through other rules to left-to-right
… if the direction of content is not known, you should use auto rules
addison: if there is no direction, you use auto
richard: you use auto
addison: that is UBA
richard: auto says: use the UBA
… if you do not have auto, things are up to the application
<addison> <p dir=ltr>dldld <span dir=auto>...</span>.... </p>
richard: discussing section 2.4 ... that is "auto"
addison: my thinking is two-fold:
… if you send s.t., you should indicate the direction
… if you do not know the direction, "auto" is not helpful
richard: agree
addison: if you do not know the direction, do not send it
… if you define e.g. HTML, you need all three values
r12a: some of the formats for which we wrote this document
… we do recommend auto
addison: we recommend the auto heuristics, but not necessarily the auto keyword
… two things
… first is define the direction, the dir attribute
… under what situations you will allow those values and consume
r12a: is there a problem if somebody uses the auto label?
addison: i think i have enough information to do some more edits
… do we want to draw specific distinctions or recommendations for when to use direction and when to use dir
r12a: I read that and I had the same question
addison: i could be less prescriptive and just leave that aside
… we would be super sad to see both
r12a: you could have lang and language
addison: it's the same problem
r12a: language is usually used for metadata
epub: https://
Publication Manifest: https://
<addison> "property" not "data value"
addison: i'll take another whack at it
bert: i like it
AOB?
addison: developing localizable manifests
… i used respec to create the draft
… i used i18n-draft as the home
… r12a do you suggest we should just make a new repo?
r12a: it may end up being a very short note
… if it's going to be an article it should be in an article format
xfq: If we are writing for spec developers, a note might be better
r12a: if we decide to make it into an article we don't want it to be in a repo
addison: i'll move it to temp and we'll discuss whether it should be a note
r12a: it depends on whether we're going to have mustards in it
addison: it's a best practice document
r12a: mustards are not normative, they are recommendations
… a way of getting the message across
… it wasn't to say these are the normative bits
… even in charmod fundamental
addison: if you have comments on the text
… that would be super useful
… i'll email the list
<atsushi> I had the same issue for today's another meeting...