See also: IRC log
<tink> Meeting: HTML F2F Day1
<tink> Meeting information: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/17-03HTML.md
<tink> scribe: Léonie
<tink> CMN: We need to move HTML5.2 towards Recommendation.
<tink> ... We publish an update to the Working Draft (WD) in early April.
<tink> ... We need to get reviews from the accessibility (a11y), internationalisation (i18n), security and privacy groups.
<tink> ... The Accessible Platform Architectures (APA) WG does a11y reviews, and Léonie is a member.
<tink> ... The I18n group uses a label on our HTML repo which flags when issues are opened/closed etc.
<tink> ... Security and Privacy have Interest Groups (IG), but often we do not get responses because those groups do not have enoug people to get reviews done.
<tink> ... We also ask the Technical Architecture Group (TAG) for review.
<tink> ... We publish a changelog each time we update the spec, to help people review changes.
<tink> ... It would help if people could review those bits of the spec that are old and unchanged too, because they could be done better.
<tink> ... Parts of the spec are badly written and difficult for people to understand.
<tink> ... What we'd like is for those people to tell us when something is difficult to understand.
<tink> ... We also need to improve our documentation, to help other people work with us on the spec.
<tink> ... Over the next three days we will do maintenance.
<tink> ... Our work is mostly ixing issues and cleaning up the spec.
<tink> ... We think that for HTML5.3 we will start to see new features.
<tink> ... We will also need to decide how we fit the Web Components work in.
<tink> LW: If the WG decides to incorporate it.
<tink> CMN: That's the other question, yes.
<tink> ... We could also separate out chunks of the spec, Parsing is one possible candidate.
<tink> ... That takes a lot of work and we need people with the time to make it happen.
<tink> ... We have prospective changes/new features like the one in issue #774
<tink> JH: We try to use something and then some time later we figure out where it works/doesn't work.
<tink> CMN: Do you keep track of the bits of code you're going to need are?
<tink> JH: If we have a project with a difficult challenge we discuss it in our Slack channels until we find a solution.
<tink> PCJ: We do the same.
<tink> AD: We have the Web Platform Incubation Community Group (WICG).
<tink> ... You don't need t be a W3C member to join WICG.
<tink> ... There are ideas coming up, but unless they have a champion driving them, they tend not to move forward.
example of a proposal which not many people look at…
<tink> ... People don't understand that in standards you need to do work, you have to put the time in to make things happen.
<tink> ... That means the people who do work prioritise things that are important/interesting to them or the company they represent.
<tink> ... But The WICG was supposed to change that.
<tink> ... There is an idea of chapters around the world where people in different regions cold colaborate.
<tink> ... It hasn't happened though, because no-one is driving it.
<tink> SF: WICG seems successful at getting people involved.
<tink> ... I don't know how well those ideas are translating into standards or code yet though.
<tink> CMN: It's easy to write up an issue and post it there, than it is to research whether anyone has already done so.
<tink> AD: A lot of frameworks do data-binding for example, and they all do it differently.
<tink> ... So how do you find the commonality?
<tink> ... Finding a standard sounds good on paper, but the reality is that every framework would need to rewrite the way it does it.
<tink> ... W3C tries to be the interoperable standard.
<tink> SF: Testing is boring work.
<tink> AD: Yes, which is why it's hard to attract people to help do it.
<tink> JH: I had no idea it was easy to contribute.
<tink> SF: The opportunity to contribute has become much more open.
<tink> JH: When HTML5 was introduced it was a big thing.
<tink> ... It appealed to a lot of people.
<tink> ... But when people go to the site they see a lot of text.
<tink> ... But the HTML5 launch made it cool - the logo, t-shirts etc.
<tink> CMN: We need better marketing?
<tink> XW: We have a W3C course to learn HTML5.
<tink> LW: We do need better marketing, no doubt about it.
<tink> JH: Also you should make it better known how easy it is to contribute.
<tink> CMN: If you have ideas they are welcome.
<tink> HJ: An overview of specs would be good.
LJW: We have a starter for a
document on HTML5 extensions
... the things that extend HTML5 …
... maybe we can use that as a basis to help people understand
the different pieces and how they go together
... [hmm. hard to find…]
<tink> LW: https://github.com/w3c/html-extension
the collection of HTML extensions
SF: write a post and get it to somewhere like smashing mag instead of just W3C blog.
Johan: Now I know that WICG is there and that people can use it, but how do we tell more people about it.
AD: the first thing people meet when they look at the repo is instructions to install a whole set of tools to build the spec. That's not an easy welcoming introduction… should be restructured.
<tink> LW: Yes, the process is not itself difficult, but the documentation makes it seem more difficult.
<tink> LW: We have a newcomer Anne Colum, who is interested in helping with HTML. I'll ask her to take some notes on what she found difficult/what she could have done with in getting setup for the first time.
XW: I don't think the documentation is complete, and I might need to ask editors, but I can work on what people need to do to make changes.
<scribe> ACTION: Xiaoqian write up how to contribute. [recorded in http://www.w3.org/2017/03/28-html-minutes.html#action01]
AD: What was good about test the web forward was that we gave people t-shirts if they wrote stuff…
Paul: In Korea the problem is language - developers don't necessarily speak english.
AD: Testing is good like that because you just find something that doesn't *work*, and write the test to show what isn't working.
Paul: people who are not confident in english have difficulty expressing their opinon - so they like writing code but not documentation…
CMN: It works to have a developer file a test showing something doesn't work, and a one-line issue saying "section x.y doesn't match reality" - then you are a contributor, and we can get a spec editor to fix the spec documentation…
Johan: How do you tell the world that the 5.2 spec is released…
CMN: There is a press release, that of course everyone is waiting for and reading carefully…
[paul smiles…]
I'm looking for someone else to take this: Léonie?
input type="email" doesn't allow IDN. For discussion - needs browser implementation?
use a common code style. What to do with this?
Use active voice. same question…
rel values. Which ones should go into the spec. There are some related issues for specific values.
AD: Should we allow e.g. two different descriptions. Needs tests, but should this go to hte Working Group?
CMN: Absolutely should, but we may get silence. Anything from i18n?
AD: WHATWG has enabled this, no comment from i18n.
CMN: So what is the philosophical question?
AD: Makes sense, but there might be a different meaning in different languages.
CMN: Sounds like unless tests
show something breaks, I would suggest just do it…
... what uses meta description
... e.g. you search for a test case in multiple languages does
anything go wrong…
RESOLUTION: write tests, make the change to allow multiple descs
SF: Been around for a while not
sure what to do.
... think we should align with what WHATWG says. It isn't a
normative requirement, rendering is suggestions.
CMN: What do they say?
CMN: So the issue is that we suggest CSS to make it work, but in reality current browsers do it by magic?
SF: Yeah.
... Whatwg says the same as us.
CMN: Does it matter whether it works through unimplemented CSS or magic?
SF: Don't think so.
RESOLUTION: close wontfix
CMN: use active vs passive voice, and make code samples in a common style.
LJW: kill the active vs passive…
CMN: these are editorial conventions across the whole spec, can we move them to the editorial best practice?
LJW, SF, yes.
RESOLUTION: close 310, 487 and move the guidance to the documentation of editing practices.
XW: We should get a script to clean up invalid windows line breaks…
CMN: Do we *need* that?
CMN: Where there is behaviour that seems unfriendly, should we make non-normative recommendations for what happens, hoping that we will get implementation?
SF: Seems reasonable to make suggestions that are not requirements…
CMN: this is still only going to be "question for the wg"
AD: seems reasonable
LJW: We should set the expectation on the browser and show that they do it before we put it into the spec, since otherwise developers cannot use it, unless we indicate that it would not work, and then we're in tricky space.
AD: So where to we raise it for browser developers?
XW: can we raise issues for stuff that should be done…
AD: If we want the spec to reflect reality, we can't describe what isn't implemented. If we have issues raised in the community we should raise it against browsers…
CMN: So let's raise browser bugs against the issues and point them to the issues.
SF: If we don't push this somehow
we never get to where we're trying to go.
... if implementation isn't going to happen we can mark stuff
as at-risk for CR.
LJW: So what do we do - make a speculative text, or not?
SF: It is reasonable to put things into WD, if they are not implemented…
XW: Do we have a list for at-risk features so far?
CMN: As far as I know there
should be none, but we need to check carefully.
... So if we put something in we would mark it at-risk instead
of closing the issue?
XW: [nods]
CMN: So we can put advice about bugs in, if 1. they are marked at-risk, 2. There are browser bugs filed, 3. Anything not implemented is going to come out of the Recommendation, 4. we commit to actively reassess the issues for version.next
RESOLUTION: we can put advice about bugs in, if 1. they are marked at-risk, 2. There are browser bugs filed, 3. Anything not implemented is going to come out of the Recommendation, 4. we commit to actively reassess the issues for version.next
CMN: Spec says "a thead"
definesrow or rows of column headers. If you put a th anywhere
it is a header, but what happens for td that is in a thead - is
it a header?
... the only useful test I came up with was running a screen
reader to query column headers, and at least for VoiceOver td
in thead is treated as a header, whereas if it's just the first
row it isn't.
... Is that a useful approach to testing and are there other
uses of headers where we could test this.
AD: paginated printing tools like
PrinceXML might do it when they split a table across
pages.
... we had a product in Canon that would do that.
CMN: is there import to spreadsheets that picks up headers at all?
<scribe> ACTION: Chaals, find tools and test them. [recorded in http://www.w3.org/2017/03/28-html-minutes.html#action02]
SF: td in thead is not styled the same as TH
CMN: But Alex' point is whether the semantics of td in thead is different from th semantics…
SF: FF exposes td in thead as a cell not header in windows.
AD: A bit of controversy… logic says it is correct and browsers do it. It isn't what we say. The only impact is performance - you can get a re-layout so it's bad practice. Should we condone it? But 14% of major sites do this.
SF: Why do people do it?
AD: Works well with CDNs and aggregation.
CMN: Works and is common, so we should allow it, and point out the potential performance issue.
SF: Yep
RESOLUTION: make it conforming, add a warning about the problems.
XW: i18n people say they are not
convinced rbc element is necessary. We only have ruby element
in HTML, never got rtc supported.
... suggest we close the issue because nobody likes it, but
need to think about whether we update the ruby element.
... there is a ruby annotation Rec, updated in 2008.
SF: I think ruby is "all" in the spec.
XW: We have ruby annotation spec, CSS for ruby that isn't for us, and ruby in HTML spec. What do we update?
CMN: I suggest we remove it from
the HTML spec, update the independent Rec since it is in our
scope, and be done.
... add ruby annotation to the list of HTML extensions.
<SteveF> http://darobin.github.io/html-ruby/
<xiaoqian> https://www.w3.org/International/tests/repo/results/ruby-html
RESOLUTION: Remove Ruby markup from HTML, add it to HTML extensions and update the existing Recommendation to obsolete the old version.
XW: Do we need a FPWD?
CMN: Not if it was already a Working Draft. In any event, it is covered by the HTML 5.2 FPWD which has that content too…
Port referrerpolicy integration.
AD: requires fetch changes to the spec. It's like listing a bunch of pull requests for something we can't fix without rewriting to deal with fetch.
CMN: I would be happy if we rewrote to reference fetch spec, since there isn't another one…
AD: even though it is a moving target
CMN: yeah, ;( because thereisn't another one. If we find that the moving target nature is a problem then we deal with it.
XW: This is analogous to URL. Don't think it is a problem.
define formal behaviour for select
AD: Rodney Rehm has written a
bunch of tests. Browsers are a mess.
... and there is nothing specified.
CMN: can this all go to the selection API, or ?
AD: Not sure we can.
... not selections, select element.
CMN: oh. ;(
AD: Once we write tests, we will
need to select expected behaviour …
... should we specify the behaviour we expect?
CMN: Think we should specify what we think should happen - but as described above this would quite possibly be "at risk"
Mechanism for presenting descriptive information
SF: there is an aria 1.1 details
property. They seem to be asking for an HTML attribute that
allows styling of the details/summry widget, and provides the
state.
... I don't like adding an attribute for this.
... developers will immediately replace any default icon with
something else.
... developers can just key off the presence of aria to change
the default icon
LJW: Apple will object to it if there is no native indicator.
CMN: There is already
summary/details with the open attribute. We can suggest that
the default indicator can be changed, but explaining how to do
that is up to the CSS group.
... since it is implemented as a pseudo-element.
[issue archaeology]
SF: There is no clear proposal here…
LJW: There are a couple of
proposals - adding type attribute, your web-component
proposal,
... we need to get feedback from browsers on what they will or
won't do.
XW: Do we have a dpub label for issues?
CMN: Don't think so.
LJW: Browsers are not showing any
inclination to make ARIA useful to anyone except through the
accessibility API. That makes it a bad general solution.
... I think we can close this issue until someone thinks of
something better.
SF: I was floating an extension to the button element, so you could identify another element, with attributes to associate the button, and describe the state / control display.
LJW: So what do you do if you have, for example, description for a video or complex table? Do you just put the disclosure widget somethere handy?
SF: Yes. In a figure element, etc.
LJW: How do you associate the descriptive content back with the thing it describes?
SF: For non-AT users, how would the relationship manifest?
CMN: the common pattern today is that you have a disclosure widget near the thing described, and that produces something like a dialog, which you then dismiss and you are back where you were.
SF: Any visual cue we define will
be overridden by the web - or they will keep faking it with
JS.
... What would browsers need to implement, other than an
icon…
LJW: Dave Singer was suggesting that a browser creates a modal dialog…
SF: Want to understand the relationship between the button and the thing being described
LJW: So I know what is being described, by something better than "it was placed on top with some magic CSS, even though it's halfway across the document". Same question as label for form fields
SF: You can use the label element, around the thing being described, as a label for the description button.
LJW: We want to make an easy default - this doesn't seem to meet that bar
SF: They will routinely get it
wrong, but this approach will work and if they want to do it
right this isn't that hard and matches what we already ask
people to do.
... so this would work today, rather than trying to add more
stuff into a browser.
LJW: We have a lot of bits of solutions, but this doesn't feel like a properly robust capability.
[break]
RESOLUTION: Assign issue 561 to Léonie, to get a clearer problem statement and work out if its incubation or something we can solve faster…
SF: Came up because the
definition is circular...
... trying to find a clearer way to say this.
defitnition of the button element
scribe: This is almost editorial
CMN: Think it is entirely so.
SF: Made a PR after discussion, some more comments on the commit.
RESOLUTION: SteveF to find better wording
add link rel="serviceworker" and associated pieces
check what link rel values to add
CMN: There are rel values defined
in various places - µformats wiki, whatwg, various W3C specs.
We need to go through and find them, and put the ones that do
things into our spec…
... And should we continue to direct implementors to put rel
values they implement into µformats wiki?
XW: rel=preload has more than 2 implementations, we should take it in. For resource hints I think there is implementation in IE11 …
CMN: Should we suggest that people who want to define a rel value raise an issue on HTML?
SF: in order to?
CMN: Make it easier to find and more closely associated to the spec. We have seen specific comments from e.g. Dpub saying they feel uncomfortable putting their proposal in a wiki somewhere else. Not that I think we will avoid the need to go looking for these things, but it might minimise it.
XW: Should we do rel values in HTML extensions?
CMN: That doesn't tell us how to
find them. We might reference things from that spec…
... but I think it will make some developers more comfortable
that their proposal will be considered actively… we'll still be
looking at µformats wiki and at other specs or major
implementations to see if we should be adopting values.
AD: seems reasonable
SF: I was concerned in serviceworker about the scope - there are elements to be added, but they are not defined.
RESOLUTION: Assign to Sangwhan.
arronei, yt?
travis, yt?
valid IDN emails not allowed by the input type="email"
CMN: lots of valid addresses are not allowed in the email address selector. That seem b0rken
SF: how do they work elsewhere.
CMN: increasingly well. You can
send me mail @яандекс.рф and I get it…
... works in most email clients, and webmail systems often
won't use input type="email " so that they can handle such
addresses.
SF: Sounds like we should file browser bugs and change the spec…
AD: yep.
<sangwhan> We can, but there is a small can of worms that will be opened if we do this. I can explain tomorrow if needed...
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 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/HTML F2F Da1/HTML F2F Day1/ Succeeded: s/alrady/already/ Succeeded: s/te interoperable/the interoperable/ Succeeded: s/people/people who are not confident in english/ Succeeded: s/https/-> https/ Succeeded: s/REOLUTION/RESOLUTION/ Present: chaals stevef Léonie xiaoqian Changjin Teahwan Johan AlexD Regrets: Travis Arron Sangwhan No ScribeNick specified. Guessing ScribeNick: chaals Found Scribe: Léonie Got date from IRC log name: 28 Mar 2017 Guessing minutes URL: http://www.w3.org/2017/03/28-html-minutes.html People with action items: chaals how up write xiaoqian WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]