<sharon> agenda: Personalization Monday 27, July 2020
<JF> Presnt+
scribe+
Becky: I made a few suggestions to the two explainers and checked for differences.
<becky> https://raw.githack.com/w3c/personalization-semantics/explainer-compare/explainer.html
Becky: that URL I shows the changes I made
Lisa: I think the two actions we have here are long and should be addressed first.
Sharon: issues around data-
Lisa: we were going to add an
editors Note, but we need to know what we want instead of data-
and why.
... , I made a wiki page to collect our thoughts.
<LisaSeemanKest> https://github.com/w3c/personalization-semantics/wiki/Prefix-discussions
Lisa: , the prefix discussions
page.
... , it will take time to get to a consensus.
... , pros/cons for each idea.
Sharon: first option is no prefix at all. Lot of duplicate values we would have to address?
Lisa: I thought we got rid of the duplicates.
John: address, CC, Name etc. are
for data-purpose but the form inputs can only be used for
certain HTML inputs and we want to use them more
generally.
... , its not the same attributes, the values may be the same,
but the attribute must be different.
Becky: we discussed this with aui originally, maybe we can add to the list, and we did this and have this recorded.
John: I was going to say the same. we resolved this discussion, and curious why it came back up. data- for now and goal of non prefixed.
Lisa: we had this discussion last
week, we may want to prefix we may have issues getting all of
them through, much simpler to add more models etc. We can't go
through PR we must get it out of data- we must have an
alternative to go to PR.
... , do we want prefix or not and if we want a prefix which
one. Some similarities to the AUI discussions.
... , and comparisons to things like aria or some strange data
model.
<JF> +1 to Becky
Becky: I heard differently last week. we had to have a fallback model, you have an idea if you don't get what your first choice was.
Lisa: we know that, what are we asking for with or without a prefix.
Janina: that is a very different discussion.
Lisa: if we want a prefix we need to discuss it.
John: I thought we were going to
start with data- and once we have our proof we would use
non-prefix attributes, if they come back supporting all of
them, then we would ask what prefix should we use.
... , I support no prefix.
Janina: concerned that is a larger ask. if we don't get them all then we need to go with prefixed values. if we go with non-prefixed then we must come back with a couple more in a few years, its just easier to get it done with a prefix. I don't see it done prefix/no-prefix. I don't think we are shooting ourselves with a prefix.
https://github.com/w3c/personalization-semantics/issues/157
Charles: was this a results of this issue that was posted by Jeremy Keith?
Janina: I think we are using data- correctly but I need to read this issue.
Sharon: I though this is an issue going to PR?
Janina: We are looking at 2 CR one with CR and one without, and while in first CR figure out how to remove data-. and go to CR again.
John: I guess we just need to decide if we need to go with prefixed or non-prefixed values.
Lisa: should we take a straw poll from everyone (prefix or no prefix) to see where we are and is it a big deal.
Janina: Can someone explain the difference. with / without a prefix in actual use.
<JF> I'd like a situation similar to ARIA: some attributes (aria-label) are prefixed, others are not (role=)
<JF> action, destination, purpose
Becky: I don't think we are going to get main stream developers to do personalization. so the fact that its a prefix I don't think like publishers would know how to use it, we can't even get developers to do ARIA correctly.
John: I personally similar to AIRA aria-label but others like "role" is a fully fledged HTML attributes that all developers. SOme of the other things are specially used. I can see some of our proposed attributes that developers.
I suggest that we come up with our proposed attributes and then see what HTML will accept, and then some of the edge cases may have to be prefixed.
<Zakim> janina, you wanted to speak about the hybrid approach proposal
<Zakim> becky, you wanted to discuss time line for other modules
Janina: I see your point is a smoother where we can go to WHATWG with a small list of attributes like Action/Purpose/Destination and give examples to them on why this could be more generalized mainstream.
Becky: maybe we are we going to go and ask for 6 and do a quick review first.
<JF> helptype
John: going beyond our first module, right now in AGWG they working on persistanct help and we are proposing a help type. Not being prefixed is not just for new HTML for disabilities when we have a prefix.
Sharon: so where do we go from here?
Lisa: prefix/noprefix/hybrid.
<JF> Start with no-prefix, settle for hybrid
<JF> +1 to Janina
Janina: we know we need to put a note in CR. We have time to close on this. BUt I think we need to start engaging some of our allies and close friends. Contacts within the W3C and see if our thinking will fly, because we are putting an editors note in we can always do another CR.
Lisa: I think we need Michael to agree.
Janina: He already has in our
planning.
... we don't have to put a prefix in, we put data-.
... , we say we are using data- in our editors note and pointer
to the URI, we expect this to change to some assigned or may
become native HTML but has yet to be determined. All we are
telling implementers that what you are doing today will
change.
Becky: we put in the editors note, we are using data- why we are using it and we will before going to PR we will be looking to add additional attributes to HTML.
Janina: we may want to say they may be non-prefixed to avoid any knee-jerk reaction to additional attributes being suggested in HTML before we have those discussions with Browsers and the WHATWG.
<sharon> Are people comfortable with looking into a hybrid?
+1
<janina> +1
<LisaSeemanKest> +1
<sharon> +1
<becky> +1 but not sure we need to do that now
<Roy> +1
<JF> 0 Start with no-prefix, settle for hybrid
Lisa: it may be want to start looking for a prefix.
<JF> we have 20 potential attributes (Content Module - 6 attributes | Help and Support - 9 attributes | Personalization Tools - 5 attributes) or which easily 7 or 8 could go "mainstream"
Janina: I will draft an editors note.
JF: We show up with 20 attributes to show how it should all work, but we want decision makers in HTML (Getting WHATWG onboard) and then they will come back with maybe 6 or so, and then we ask them what the prefix for the others should be. SO we don't have to worry about any prefix, we go in with data- as defined, we know we can't maintain that and let them counter offer if they wont accept all of them.
Sharon: we need to get the Editors note written to go to CR.
<JF> +1 to Janina
Janina: when we have the CR we go to WCAG, we have some conversations over TPAC. THis is the technical bureaucracy that must happen.
Sharon: in your note Lisa I saw 2024 is that right?
Janina: yes this is strategic
planning.
... , we can look at the APA charter for the deliverables on
what the Personalization TF is scheduled to do.
... , CSS is moving fwd to media queries5 and low vision
concerns. So we should look into this.
<becky> https://www.w3.org/2018/08/apa-charter
Janina: , module 1 deliverable is in the APA Charter.
Lisa: metadata 1. digital
publishing additional value in accessible feature. 2. can we
standardized external files that it is linked to.
... , be a bit like a module. not sure if we want to add that
in. do we think its realistic we can do this in the next 3
years.
Becky: we are also behind where we said we will be.
Janina: that always happens
unfortunately.
... , there is management effort to help us get back on
track.
Becky: how we need to adjust these.
Janina: I don'' think we will be at TR before they need to approve the charter.
Lisa: should we do a straw poll on what modules we can do in the next 4 years.
Janina: I was thinking of just getting 1 though in 4 years is doable. but should we say we want all of them to get CR, or is it better to underpromise. I would like not to be prevented to move quickly. But this is a Roy/Michael to discuss this.
Lisa: Can we move modules beyond the charter. we can move things to editor draft/working draft.
Janina: other supplementary
documents, but its better if we can specify them.
... need to decide by January on what modules we want to
mention in the charter and what status they should be.
John: Note that the first module will take longer, discussions we need to have. The other two modules will go faster, but I think we should under promise and over deliver.
Lisa: we need to check that we can move these other modules to move to CR but don't want to be in conflict with the charter.
Becky: look at the two sections I did, I reorganized the bullets in the beginning, and the abstract seemed a lot more symbol focused and the one in the TAG explainer. We do have a lot more code/images in the TAG explainer than in the draft explainer. Just review that on the email. Do we want all those examples in the explainer, if we make it too big then people won't read it.
Janina: the abstract and intro and looking at those we can reuse that.
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/the charter needs/they need/ Present: LisaSeemanKest janina JF Roy CharlesL1 becky No ScribeNick specified. Guessing ScribeNick: CharlesL1 Inferring Scribes: CharlesL1 Found Date: 27 Jul 2020 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]