See also: IRC log
<trackbot> Date: 13 April 2011
<scribe> scribe: John_Boyer
Steven: At multilingual web conference organized by several in Pisa last week. Got opening slot on first day to give technical background e.g. content negotiation. Explained how to do it with generic XForms
Dan: slides available?
Steven: top link on my current home page
<Steven> http://www.w3.org/2011/Talks/04-04-steven-i18n/
Steven: Other announcements. CSS
2.1 is at Proposed Rec now, so it's now just a matter of member
voting.
... We can now reference it in our specs
Steven: Seems we don't have consensus on needing this as a feature
Erik: Yes. Some people want to
specify this cross-platform, but others don't agree (including
me).
... delay seems unclear to users. John also mentioned that we
want this to be settable once in a form for consistency
Steven: You're saying that the delay should just be automatic, batching changes and showing them as the processor opportunity arises
Erik: Yes, in submission case, if a submission is still in progress, then the following submission will just not go through
Steven: The competing issue is just that we have two implementations so we may as well standardize
Alain: Yes XSLTForms and
Chiba
... Problem is with a first submission; we know it might take a
while so we don't want it to go too quickly
... Need to wait a bit because once first submission is in
progress, a subsequent one with meaningful data is prevented
from running
Steven: What about Erik's suggestion that processor heuristics can be used rather than form developer having to specify
Alain: that's complex. If form developer knows a delay is needed, why can't he just specify it
Steven: Understood, but why can't processor just do that without needing the form developer to code it
Alain: the form developer may have to tune the form based on the server it is contacting
Steven: Erik, you don't see the need for it, so what if it were defined as an optional feature, not required?
Erik: It seems it would be worse
to say exactly what this attribute does
... Is it a minimal delay or a maximum?
Alain: minimum delay
Steven: looking for consensus on an optional feature with a definition that everyone can live with
John: seems that tuning would be specific to assumption of server, network AND client. that doesn't seem like it would be as generally useful
Steven: But two implementers suggests there is still a use case
Alain: my big issue is with an initial delay because there is no data to start with
John: But why doesn't processor just wait a bit until there is some data?
Steven: Let's put a real use case to it. You're typing a string and you want to gather a few characters at least before doing a submission
Alain: Yes but we don't know how many characters. Maybe it's when the user stops typing briefly
Steven: In that case you're really waiting for a pause
alain: yes
Steven: I'm just trying to compare that with similar experience from the past. We didn't trigger a value-changed until there was a pause. We had an internal definition of the puase
Erik: This is exactly how we
implemented. It makes sense to not dispatch events while the
user is actively typing.
... And if you keep typing for 3 minutes, then we can still
override and do a submission.
... There are multiple kinds of delays, a maximum delay, a
pause delay, a minimum delay.
... It would become very complicated to specify them all.
Alain: Also may not be the same
for all controls.
... For some controls we need a minimal delay, for others not,
for others a different minimal delay due to differences in the
actions.
Erik: Some incrementals we want to fire after every keystroke, others we want on a pause, etc.
John_Boyer: if we squat on the name delay, even as optional feature, then we limit the possibility to define the other kinds of delays later
Steven: I'd rather do it heuristically, but was also hoping we could do an optional feature that enables what implementers have already done
Erik: Seems like we don't like optional features
Steven: True although optional
features help build consensus
... We do have some optional features
John: Like appearance
<ebruchez> just got dropped, calling back in
Steven: looking for a consensus?
John_Boyer: Any thought toward naming it differently, e.g. mindelay so we don't squat on the name for other delay types?
Steven: May not solve the problems; current implementations use delay
<nick> zakim pointer?
Kurt: I don't think we should change the name from delay, used by current implementations
Steven: Proposal we adopt delay as optional feature
Proposal: Adopt optional feature delay attribute that specifies minimal delay in milliseconds with implementation specific default
anywhere you can use incremental
RESOLUTION: Add delay attribute to all form controls that support incremental, optional to implement, defining minimal delay in milliseconds with implementation-specific default
<scribe> ACTION: Steven to help Alain get to his action items [recorded in http://www.w3.org/2011/04/13-forms-minutes.html#action01]
<trackbot> Sorry, amibiguous username (more than one match) - Steven
<trackbot> Try using a different identifier, such as family name or username (eg. steven, spembert)
<scribe> ACTION: Pembo to help Alain get to his action items online [recorded in http://www.w3.org/2011/04/13-forms-minutes.html#action02]
<trackbot> Created ACTION-1789 - Help Alain get to his action items online [on Steven Pemberton - due 2011-04-20].
<scribe> ACTION: Alain to create wiki spec for min delay attribute for XForms 1.2 [recorded in http://www.w3.org/2011/04/13-forms-minutes.html#action03]
<trackbot> Created ACTION-1790 - Create wiki spec for min delay attribute for XForms 1.2 [on Alain Couthures - due 2011-04-20].
<dmccreary> http://www.w3.org/MarkUp/Forms/wiki/Annotations
dmcreary: A couple of
implementations have extended textarea to allow richtext, html,
bold italic etc.
... Some want to go deeper into text annotations.
... Not just a simple tag added to textarea.
... By adding some tags, a textarea could handle mixed content.
A tag to get richtext is not that hard, and there are several
implementations.
... Interested in consistency across implementations and
extending beyond just richtext.
... Everyone familiar with TEI? Standard for encoding people,
places, dates, geolocations. A vocabulary for annotations, over
500 tags. Profiles for which tags to use depending on what
you're annotating (scripts, plays, etc.)
<Steven> Sounds as if it is related to RDFa
dmcreary: Some want to improve
faceted search over the content by enabling annotations.
... open source, several humanities interests are
adopting
... does this have merit? Several weeks ago, members agreed it
has merit but lives outside of XForms and overlaps other W3C
interests
... how to configure an editor to have a toolbar to allow
selecting text and applying an annotation
John_Boyer: Can the alternate content be characterized by a mimtype or mediatype?
dmcreary: Good question, not entirely. several profiles apply to content type
John_Boyer: What about if you include a mime parameter, e.g. text/html; profile="blat"?
dmcreary: that could work. people are just saying that they want to provide the schema and build an editor around it
John_Boyer: Reason I ask is that attaching mediatype attribute to textarea is typically used to indicate what extension content it will edit, and if the TEI profiles could be identified by mime parameter, then it would be easier to create custom extension editors around a textarea
dmcreary: that would work for 90% case
Steven: The more complex cases sound a little like research
dmcreary: I agree
Steven: Looks like HTML editing is a clear and present use case
dmcreary: Has anyone seen difficulty of interoperability between html text editing based on various richtext controls?
Erik: We used to use CKEditor and
now use YUI editor
... Just the default toolbar of the editor is provided
Steven: so just paragraph, bold,
italic, links, etc but not complicated stuff like iframe
etc.
... Dan, are you saying that if we said we could edit HTML with
a textarea that we would have to specify what specific HTML is
allowed?
dmcreary: Yes, that's the quagmire we have now
<ebruchez> Here is the default we have: http://twitpic.com/4kelog
John_Boyer: We found we had to define a strict profile of HTML so we could get content interoperability across multiple rich text editing controls.
<scribe> ACTION: dmcreary to create strawman proposals for how to deal with enriched content for textarea and for profile of HTML [recorded in http://www.w3.org/2011/04/13-forms-minutes.html#action04]
<trackbot> Sorry, couldn't find user - dmcreary
<nick> list participants
<scribe> ACTION: Dan to create strawman proposals for how to deal with enriched content textarea and for profile of HTML to be supported [recorded in http://www.w3.org/2011/04/13-forms-minutes.html#action05]
<trackbot> Created ACTION-1791 - Create strawman proposals for how to deal with enriched content textarea and for profile of HTML to be supported [on Dan McCreary - due 2011-04-20].
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: John_Boyer Inferring ScribeNick: John_Boyer Default Present: [IPcaller], +1.952.931.aaaa, Steven, dmccreary, alain, ebruchez, +44.782.483.aacc, pfennell, John_Boyer, unl, +1.443.837.aaee, Kurt, Nick_van_den_Bleeken Present: [IPcaller] +1.952.931.aaaa Steven dmccreary alain ebruchez +44.782.483.aacc pfennell John_Boyer unl +1.443.837.aaee Kurt Nick_van_den_Bleeken Regrets: Leigh Agenda: http://lists.w3.org/Archives/Public/public-forms/2011Apr/0011 Found Date: 13 Apr 2011 Guessing minutes URL: http://www.w3.org/2011/04/13-forms-minutes.html People with action items: alain dan dmcreary pembo steven WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]