W3C

- DRAFT -

Future of HTML (TPAC)

28 Oct 2015

See also: IRC log

Attendees

Present
paulc, Charles McCathieNevile, Doug Schepers, Adrian Bateman, Karl Dubost, Mike Champion, Paul Cotton, Anne Van Kesteren, Travis Leithead, Philippe Le Hégaret, Léonie Watson, Ted O'Connor, Jeff Jaffe, James Graham
Regrets
Chair
Chaals
Scribe
LJWatson

Contents


CMN: This is one of many discussions about the future of HTML at W3C.
... The Web Platform (WP) WG has been created.
... HTML continues to exist, but the HTML spec is in scope for WP now.
... The question is - What do we do with HTML?
... The last couple of years were focused on shipping 5.0.
... Then we fell out of the habit of working on HTML.
... There is a draft 5.1 spec.
... It's produced through a painful process. Editing the spec is hard work, and we'd like to change that.
... Other questions - What's broken in HTML? What's missing from HTML?
... What bugs need to be fixed?
... The answer is that quite a bit is broken, like some of the forms stuff introduced to 5.0.
... There are bugs with features like accesskey.
... There may be new things we want to add, like the draft proposal for panels.
... We want to hear from you what you think we should be doing?

DS: We need documentation so people can understand how new features get added to HTML.
... What can be accomplised, what the constraints are etc.

CMN: You need to show that there is interest in your proposed idea.
... The Web Incubator (WICG) has been created to do this.
... There are constraints. You have to have stuff that's in scope, but it's a broad scope.

AB: The charter for WP explicitly calls out that new proposals should go through some incubation, either in WICG or somewhere else.
... As a rep for Microsoft, one thing we want to see in HTML is a place for us to identify and discuss issues that we see affecting real websites - causing browser interoperability problems.
... We want a venue to discuss these issues.

KD: We're doing the same thing as Mozilla.
... We're noticing differences in implementations, sometimes bcause properties are not well described in the spec.
... From our stats, if we don't use vendor prefixes (for CSS transitions for example) things break.
... We've created a compatibility project on Github.
... So we can bring these issues to the WG.

CMN: We need to do bug fixing, and ship that.

DS: It's clear implementors are interested in talking about existing features especially those that cause problems.

<karl> https://github.com/whatwg/compat/

DS: Other people in the room are interested in proposing new work, like panels.
... What can we do to get new work?

CMN: Something like Web Components make it possible to prototype and test proposed implementations.
... If we identify common features being created in Web Components, it signals patterns that could be made native to HTML.

MC: To answer Doug, you take a new idea hopefully with prollyfill prototypes, convince people it's valuable. Go through the intent to migrate form to document the business case for the proposal.
... At that point the proposal enters the queue to enter the WG.

DS: But what is the thing that will convince people to do that?

MC: The deciders of whether it'll go into the HTML spec is the WP WG.

a

CMN: If you come up with a good idea but there is no implementor interest, you'll have a hard time making the case for it.
... There are other paths. If there is a widely used code pattern that may be enough to make the case to implementors.
... One of the constraints is that the proposal has to be relevant.
... Adding a new feature is notably harder than fixing a bug where something is broken.

Paul: When I was developing mobile game content in HTML5 there were problems. Even same device and same OS, but different display, there were bugs.
... There are device comparability issues at the moment.
... Device manufacturers should also take an interest in the HTML spec.
... As the mobile industry is growing, analytics tell us that a lot of mobile development is platform native.
... Can HTML5 overcome that?

<Hax> What do u think about ppk's view?

CMN: Will HTML5 gain market share over native languages on mobile?
... Who knows? The market share will shift, but it doesn't seem that HTML is going to disappear.
... It isn't our job to owrry about what the mobile platforms do. We can look at those platforms to see what's working well, and ask why.
... In HTML we stay away from saying how things should look/be displayed.
... So the question about some device display issuesis - where are those issues happening?

MC: Do you plan to document a workflow for this?
... If a developer is wrestling with an issue, how do they engage with the WG?

CMN: We do plan to document it.
... There is some, but it's still in development.
... The HTML WG historically had a heavy decision making rocess.
... It was easier in WebApps because they were smaller documents and specs. HTML cannot be called small.
... We're also learning as we go.
... We would like to release a version of HTML within the current charter (10 months).
... Not with major changes, but with bug fixes for identified issues.
... Having a better spec is useful.
... Possible timetable would be the middle of next year.
... Whether it's HTML5 with fixes, or HTML6.0 with new features is a question, and along the way we'll learn more about working with HTML.
... Last year at TPAC we discussed modularising the HTML spec.
... Thinking was that it was a god idea. But it didn't get done. The publication machinery didn't work with the concept.
... Do we want to continue to look at modularisation? Add modules only for new features? We don't know.

PC: An important question is whether you'll include extensions in the spec, or treat them as separate things.

CMN: That's a question for the group.

PC: Extensions releases the pressure of needing all the box-cars on the same train.

CMN: It's useful to have a concept of what HTML is currently. Instead of the living standard model.
... If we release a spec every 10 years that would be a failure. If we release a spec every 10 days it gets harder for developers to have a version of the spec they can work with. Somehwere in between is the sweet spot.

AVK: Why?

CMN: Translation is time consuming and difficult.
... W3C works with the idea specs need to be stable. There are editor's drafts for the updates as they happen.

DS: Any thoughts on the future of HTML, rather than the process?

<paulc> Open HTML5 bugs (231): https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=HTML5%20spec&list_id=60457&product=HTML%20WG&query_format=advanced&resolution=---

TL: It would be nice to start fixing the bugs.
... Is there anything to stop someone from proposing a fix? If not, where do I send the proposed fix?

CMN: We have machinery to generate the HTML spec.

<paulc> HTML 5.1 setup: https://lists.w3.org/Archives/Public/public-html/2015Feb/0009.html

CMN: You can make a fix using the current publication process. It's my belief the current process is too heavy to be convenient.

PLH: How do you propose fixing bugs?

<paulc> Open HTML.Next bugs (30): https://www.w3.org/Bugs/Public/buglist.cgi?list_id=60458&product=HTML.next&query_format=advanced&resolution=---

CMN: We can change the current process, or we could look at the current process and we may find it isn't as difficult as we think.

DS: Can you own a bug?

CMN: Yes, and you can submit a fix - by writing a patch or even by writing an email with the information in (for small bugs).

TL: Then PLH ill fix it?

PC: we need to fix the process. There are 250+ bugs, plus others in different components and stil more in the WHATWG repo.
... We don't know how important those bugs are.
... We need to figure out which bugs are causing interoperability problems, and which are valid in other ways, rahter than start an enforced bug fixing march.

CMN: There won't be a forced march because we don't have anyone to force!

MC: For the last three years there was a full time person who was the HTML editor.
... Right now there is a handful of volunteers.

CMN: We need to make the editing process easy for those editors.

<paulc> Karl, thanks.

<karl> it's not complete but it could be a start.

TL: Do we need to be concerned about having the document diverge from the WHATWG copu?

TO: I've been splitting bugs in WHATWG and that propagates to W3C.

CMN: The issue with the mechanism is that it makes editing the W3C spec difficult.
... Also raises the question of whether we want to copy WHATWG at all?
... One option is that we stop doing that.
... The specs already diverge.
... Do we take the hit that the specs drift slightly more apart?

TL: That would break Ted's approach?

CMN: It would.

<paulc> I encourage people to read Robin's plan http://darobin.github.io/after5/html-plan.html that the HTML WG Chairs presented to the W3C AB in January.

TO: Right now the mechanism works.

PC: What works for HTML5 which has a large interested community, is making sure you identify the imortant questions that need to be answered - then get people's opinions.
... The link ^^ is to Robin's HTML plan. It considers many of these questions.
... Should we be date driven?
... It is a tar ball of complexity!

JJ: Responding to Travis' question.
... What would implementor's like us to do? we have people from Google, Mozilla, Apple and Microsoft here.
... Editor's drafts that track/update daily/weekly/monthly? A 5.1 release?

TL: At MS we tend to go to the WHATWG spec because it's current, and that's what you want when fixing interoperability bugs.
... Don't have an opinion on the publishing process. But it can be grief.
... The WHATWG version feels like an editor's draft.

JF: Why not bring those into the W3C version?

TL: anything that makes the task of putting the spec through IPR more difficult is not good.

KD: The WHATWG repo (link ^^) is a good place to track issues only for broken stuff. Contributions are more than welcome. And it's small..

CMN: Yandex is a browser vendor and content producer. We don't really care about spec divergence all that much.
... We wnt the spec to reflect reality though.
... For some of what we do the WHATWG spec is terrible - it's difficult for someone who uses HTML but doesn't write specs to understand.

<karl> s/link ^^/https://github.com/whatwg/compat /

CMN: We think IPR is important.
... We like the idea of smaller pieces.

zakim queue?

CMN: How do people look up HTML info?

JJ: Want to hear from others in the room.

JG: At Mozilla we tell developers to look at the WHATWG spec, because otherwise they'll update something that's out of date.

JV: It's welcome to hear MS looks at the WHATWG spec.
... We also think the IPR W3C offers is valuable, but it needs to move faster.

CMN: We hear from WHATWG that they want us to stop copying from them.
... Do people here feel we should copy because there is value in IPR?
... Are you encouraging us to copy it, or asking us to provide IPR without using the text we want protected, or something else?

JV: There is spec work outside W3C that allows normative references.

CMN: If you reference the IPR doesn't cover.

MC: One way forward would be for WHATWG to operate in a way that created stable snapshots that could be put through IPR.
... Consensus is also something to consider.
... Do we have to revisit this philosophical divide?

CMN: One option would be for WHATWG to come and work inside W3C. Tht seems unlikely.

TL: It would be good if we could reach agreement with WHATWG.
... I would like to contribute. I don't, but want to.

PLH: What stops you?

TL: I don't want to give away IP protection for work not covered by W3C IPR.

CMN: I would like to contribute, butmy experience is not easy to contribute to - evne in comparison to HTML at W3C.

TL: You can get work done.

MC: Was that a reference to the previous editor of WHATWG, or the current editorial team?
... The process of working on the spec is easier in WHATWG.

JG: With the new process we've tried to get new contributors involved.
... When they've found problems the WHATWG documentation is updated.

PC: Hate to remind people of history... the reason Robin's orting system is so broken is because of the differences between the two spec versions.
... You can't just pul the WHATWG spec into W3C because it would break years of HTML WG consensus.
... It may be feasible, but if so it should be done intentionally.
... The tooling also makes editing the 5.1 spec essentially impossible.
... Ted have you ever checked a fix submitted in WHATWG to see that it makes it through to 5.1?

TO: Most recently I've done things on canvas, so not sure.

PC: so that's separate from the HTML spec.

JJ: Seems we agree on a lot of things.
... We want a very responsive publication process. We want patent protection. We want to solve portaility problems.
... I'm hearing tha... We don't have a plan to get done what we all want to get done.
... Suggest the chairs and team try to bring together the right set of people to build that plan. What are we waiting for?

CMN: We wanted to listen to what people think.
... Yes, we need to develop a plan.

NS: There are differences but most developers don't know and don't care.
... browser developers in China also don't know.
... It's a problem inthe process that should be resolved.
... What developers need is a snapshot.

CMN: Let's adjourn this and keep talking.

MC: When will be in the same room. Worth continuing the conversaion now?

JJ: What about the AC meetings in March?

PC: Not everyone will be there.

CMN: Retuning to the question of snapshots... what we should be publishing is what reliably works in HTML.

PC: The WG that produces the spec wasn't willing to take web cace out.
... So taking a knife and removing things sounds easy, but getting consensus is actually hard.

JJ: So why not move it to a module?

PC: That makes modules a second class citizen - we'l make modules out of the bad things.

JJ: I meant that if you're making modules anyway.

PC: I think it's a serious mistake.

CMN: Yes, it's difficult to get consensus. Sometimes it includes throwing things away.
... Right now the WG has a mechanism for sitting down and looking at interoperability.
... We can say a feature works on 10 mobile devices, 6 desktop browsers... that's a data driven view on HTML and provides information that's useful to devlopers.

PC: Can someone name me five features we got wrong?

CMN: I'm not saying things didn't meet exit criteria. Just that the criteria are different things to different people.

TL: This is sort of the approach that the Web IDL spec is taking.
... We want to publish levels that describe behaviours and features that are widely implemented.

MC: To Adrian's earlier point about what MS wants to see happen in WP WG.
... Find out where bugs are actually happening? In the spec? In the browser?
... Trying to be data driven about what works/doesn't work is something I like.
... Having a common HTML subset.
... The real HTML that works reliably on some TBD criteria.
... It resets the conversation between WHATWG and W3C.

PC: There are asperational things in WHATWG.
... So does W3C.
... Perhaps we go back to that minimal set that works.
... No-one has given me an example.

CMN: Not saying that the process is wrong. Saying that it worked. Things can be implemented interoperably.
... For example summary/details didn't go into 5.0 because although it was demonstrated that it could be implemented interoperably, it wasn't certain there would be enough.

PC: Two implementations isn't enough? It should be higher?

CMN: The criteria could be all common browsers.

PC: W3C and the community has a tremendous amount invested in brand HTML5.
... suggest you don't publish 5.1 that's smaller, but publish a profile of 5.0 that has broader and wider interoperability.

TL: Yes, we publish it with a different name - HTML common subset or something.

MC: We've talked today about getting real world developers into these conversations.

CMN: We're over time. Meeting adjourned.

<myakura> ljwatson, thanks for scribing!

<scribe> scribenick: LJWatson

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/29 00:47:31 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/W WG/WP WG/
Succeeded: s/AK: Why?/AVK: Why?/
Succeeded: s/diting/editing/
WARNING: Bad s/// command: s/link ^^/https://github.com/whatwg/compat /
Succeeded: s/to track issues/to track issues only for broken stuff. Contributions are more than welcome. And it's small./
Found ScribeNick: LJWatson
Inferring Scribes: LJWatson

WARNING: No "Topic:" lines found.

Present: paulc

WARNING: Fewer than 3 people found for Present list!

Got date from IRC log name: 28 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/28-html-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


[End of scribe.perl diagnostic output]