Breakout: After (HTML) 5 - Web Standards Ecosystem in 2024 -- 29 Oct 2014

<scribe> scribenick: koalie

Art: welcome. Robin, Marcos and Brian will give intros
... and then discussion
... my intro
... been a member of the w3c community for many years; many roles
... delighted to be here and looking fwd to this afternoon's symposium
... W3C mostly operates as designed 25 years ago
... interested in feedback on how the consortium can do to move forward
... there are sample questions in wiki

<koaliie> wiki: TPAC2014/session-after5

Marcos: Involved with w3c for 7 or 8 years
... most recently, and related to this, was the work myself and others did to standardise the Picture element
... there is a number of interesting challenges we encountered
... there are good take-aways there
... understandings we can bring to the w3c standardisation process

Brian: I work for the Apollo education group

<tantek_> present since 10:44 - been trying to join IRC since

Brian: I represent jquery foundation in the CSS WG
... we'd like to change things
... I didn't write an article about web 2024
... we're not where we should be, how do we get there?
... I believe the extensible web manifesto lays down a vision
... EWM: standards are developed in a room like this, with people like this
... we take a while to deliver and sometimes the value isn't great
... there are thousands of things developers need they don't get
... dictionaries don't invent words
... it may take a news caster, or a magazine to broadcast and get noticed
... I believe it takes employing developers to do some of that work and finding ways to make that work

Robin: WOW
... this room is packed. People care.
... I've been editor of the HTML5 spec for 2 years
... the idea is that we've been driven by this ship ship ship approach
... what do we do after that?
... what can we improve?
... we can improve
... I'm not attempting for w3c to change top down
... we can change pretty much everything

<ArtB> Robin's After 5 article/blog

Robin: despite what you may have heard
... there are properties we want to keep
... like patent policy
... but we're fluid
... also, a lot of us have professional @@ that we're changing things by talking
... I wish for us to change things by doing.
... I invite pull requests
... fork it, make the changes you think are good, pull request
... it's the general idea that we should change by doing things rather than talking too much about them
... so, a lot of what I've been writing here stem from my experience for the past 15 years
... also, the experience with HTML I've found much instructive
... technologies are hard, standards are hard, but at least, we can lift some barriers and make things easier
... in terms of Standards Developement, we can learn from software development
... this is not rocket science, this is something we have been doing for a long time
... we don't need monster documents that are impossible to manage
... also, practices from open source community
... when I started, it was considered bizarre

<tantek> On the record: I'm skeptical about looking at "software development" as an example. Software dies faster than *successful* standards.

Robin: back then, you could download source, get it out somewhere, but if you wanted to change, you needed to cvs co
... somehow the patch could get lost over e-mail
... got a bit better with svn
... cost to contribution was slightly better

<tantek> I do agree with the problem of "didn't get lost over email". Email lists is where rational discussion goes to die.

Robin: then we got git and mercurial
... very simple
... especially if you benefit from tooling which integrate
... we've learned at lot
... today this is natural
... at conference, people sometimes don't understand there was a different world before
... what I would like to do forward for HTML and other specs, is move to that model
... you see a bug? fork the repo, change, pull request
... or share your idea and write a spec
... run a script to create the spec
... not necessarily direct access to W3C

<tantek> In general I'm in favor of lowering the barrier to suggesting (or just doing) minor fixes to specs to a broader set of folks. E.g. via git, or even better via wiki.

Robin: but a way to learn from experience of RICG

PaulCotton: We have marcos here
... picture element was used as an example
... can we use this to benchmark?

MarcosCaceres: Yes and no. Maybe

<tantek> marcosc references https://wiki.mozilla.org/WebAPI/DesignGuidelines

MarcosCaceres: what we've done at Mozilla: we gathered people
... we came up with a set of use-cases, and needs
... we put together detailed use-cases
... we showed in code that JS doesn't help you here
... not Web components either
... we exposed all the limitations of the platform
... and started talking about solutions
... having the guidelines Robin mentioned was helpful
... the bar needs to remain high
... and frame the discussion properly

MikeChampion: several conflicting themes

<marcosc> Mozilla's guidelines: https://wiki.mozilla.org/WebAPI/DesignGuidelines

<tantek> marcosc: yup referenced it above

<marcosc> tantek: thanks!

MikeChampion: who has to be in the loop to get a good spec? will there be bottlenecks?

Robin: my plan is to steal Marcos' documents :)
... Marcos talked about mentoring and I think this is key
... I think that by bringing people to the table, and they get mentoring, then we can help foster the creation of new editors

Brian: We talk about who can write a good spec
... danger of writing specs that nobody can implement
... I think we have a tendency to make things a binary line
... part of what marcos is saying we need more mentoring
... the other thing: what makes standards valuable has nothing to do with quality, but the fact that they're standards
... I would like to throw out there too that this isn't something that happened here first

<Zakim> tantek, you wanted to ask if anyone here is actually publishing HTML with the <picture> element on their own site *today*, and if so, please share the URL. Anyone?

Brian: a standard that you can't get implemented is no good and a huge waste of time

TantekÇelik: good segue Brian

scribe: who has published the picture element?

Marcos: you're asking the wrong crowd
... Building it into WP @@

Tantek: There are pollyfills
... republish the picture element and consider this a success

MarkVickers: We have had success in having dozens of changes made

<tantek> I'm shocked that ZERO people in this room use the <picture> element on their own site.

MarkVickers: it hasn't been easy
... working with W3C and WHATWG

<dka> One data point on this: we have a responsive image on the TAG home page (http://w3.org/tag) though we are using srcset. The plan is to move that to the picture element.

<marcosc> tantek, the use case for picture is for art direction - it's not that common.

MarkVickers: it takes an incredible commitment from the organisation
... Second thing: I liked all in Robin's presentation
... question: How does it all come back to the platform?
... We have to make sure that as an application paltform we don't branch and end up with several webs

<tantek> so apparently there is zero dogfooding of the <picture> element?

Robin: the idea (subject to change and discussion), a proposal is listed as such,
... when you have tests and implementations you move that to the develop branch

<marcosc> tantek, a lot of the time you don't need it. You actually need a site with images (and not just background images, for which you use CSS image-set()).

<tantek> bkardell_: re: your calling bullshit on standards, I'm calling bullshit on proposals without public real world live examples by those proposing them.

Robin: and once you have a test suite that is rough and shows interoperability, it moves to the @@ branch
... mergability is an important idea here

<tantek> marcosc: my point is without live examples, we should not believe that a proposal is actually workable and satisfies the use-cases it is supposedly designed/proposed to solve.

Robin: There is a way to bring that back and avoid fragmentation

<marcosc> tantek: http://responsiveimages.org/demos/

Art: Do we have some people from PSIG?

<tantek> marcosc: I did specifically ask for non-test/demo pages.

<tantek> *deliberately

<marcosc> tantek: microsoft.com

GeoffreyCreighton: what caught my attention: no direct mentoring on how to write specs capability of a W3C draft recommendation
... open process but not accessible?

Robin: Mmmm... no
... I'd distinguish the platform and publication process

<tantek> marcosc: http://viewsource.in/microsoft.com - no <picture> element found

<marcosc> tantek: search for data-picture=""

Robin: I don't think this contradicts in any way the process

<marcosc> tantek: it's prollyfilled

Robin: This all fits with consensus and things from the process

SimonSapin: co-editor on two specs, and I don't know what I'm doing

<tantek> marcosc: one instance of data-picture="" - doesn't look like any actual use of anything resembling.

SimonSapin: when Brian mentions mentoring, I want to know how to do it

<tantek> paulc_: expresses support for modularity idea

PaulCotton: What really worked in HTML Wg was breaking the work into smaller pieces

<dka> +1 to modularity!

<tantek> I also agree with modularity as a path forward

PaulCotton: Mentoring people is a compelling part of your proposal

DanAppelquist: +1 to modularity
... devil in the detail is re: IPR associated to contributions
... how do you track that?
... does it mean we need to change the process?

<marcosc> tantek: I can get you a list of sites easily if you want.

<marcosc> tantek: but after this thing

DanAppelquist: when somebody turns the crank and a module ends up in TR space and we can trace IPR as we have been with the W3C RF process up till now

Brian: At least as happy as we've bene in the mailing list

<tantek> marcosc: there should be a simple URL (perhaps on w3.org/wiki/Picture ) that lists those sites - no need to "get" such a list to me.

<tantek> marcosc: this I see as a failure of <picture> advocates to document their work

Robin: This is an improvement: not only can we trace back with contributions.md

Dan: somebody needs to write the version of that for the process

Robin: my understanding (IANAL) is that it's process compliant

<marcosc> tantek: that's like saying X Element in HTML is a failure because not everyone uses it on their site.

Robin: I'd be happy for actual lawyers to review that

<astearns> I'd suggest changing "failure of" to "suggestion for", tantek

SteveFaulkner: I'm trying to understand how that's going to work

Marcos: if you're going to fork more things, how do you convince mozilla and the webkit folks etc.?

Robin: this is not meant to be a hostile project
... the way I've been thinking about it is you want to make a spec, or a module, links could go both ways
... we could reference the WHATWG spec

Marcos: It's not about hostility
... how are we going to manage @@difference?

Robin: This is up for discussion
... e.g. sortable tables

BrianKardell: I want to be careful we don't narrow it to HTML only or github only

<tantek_> marcosc: I do think that *numerous* new elements in HTML5 are a failure because there is zero or nearly zero real world consumers of them besides styling them as special divs or spans.

BrianKardell: don't break the web is a hard problem
... we have new challenges: how do we evolve thousands of developers
... I want to ask the broader questions.

TantekÇelik: there is the myth of the Extensible Web Manifesto, my point is that the picture element does not even follow that path

<brutzman> Web3D Consortium is evolving X3D Graphics international standard into v4 to fully align with HTML 5. Keen to keep declarative 3D content architecturally synched/complementary/aligned while 1000 hacks bloom.

DonBrutzman: Web3D consortium
... How do we stay inline, in sync, and compatible, that's our concern
... we'll be looking for stability, still

PaulCotton: I'd feel way more comfortable as a chair knowing where the changes are coming

<tantek> what Paul said

<tantek> PaulCotton++

PaulCotton: chairs are supposed to make sure they understand the provenance of changes

<dka> +1

<marcosc__> tantek: see, http://usecases.responsiveimages.org/#limitations-of-current-techniques

<marcosc__> tantek: in particular: http://css-tricks.com/which-responsive-images-solution-should-you-use/

<MarkVickers> +1

PaulCotton: let's find how to change the process to use this model

<Zakim> tantek, you wanted to agree modularity++ and strictly so - all additions (new features) to HTML5 should be done as HTML5 Extensions and the only updates to HTML5 should be

TantekÇelik: +1 Paul

scribe: I want to add to "be more modular" to take a bold step

<dka> Does “more modular” mean that we don’t issue a HTML 5.1?

scribe: draw a hard line
... bug fixes and errata only, and let's say there will not be an HTML 5.1
... now is the opportunity to make that decision

Robin: I agree and that's my natural inclination
... the only drawback I've heard is
... that it's the problem of knowing what parts of CSS 2.1 have been superseded

DanielGlazman: you end up with specialised groups you cannot take the discussion to the main group
... it helped the CSS WG survive to use modularisation

DanAppelquist: the world is looking
... and might ask when HTML 5.1 is coming
... it might require some marketing
... e.g people are still talking about CSS3

<Zakim> rubys, you wanted to suggest the need for a 5.1: to address the technical debt that we have with a monolithic spec

SamRuby: I agree, but: we need a 5.1 to address the technical debt

Robin: Yes, there is a technical debt
... when a bug is big enough, does it justify a new extension?
... we'll need to figure it out

MikkoThero: I recommend or support the wise decision to fix HTML5 and go to modular

MarkVickers: getting off a ladder can be done [gives example of intel pentium]

PaulCotton: Huge extension, featured in HTML5 today, "applicable spec"
... we have the hook in the spec today that we need to add new modules

<tantek> paulc++ "we have the hook that we need in HTML5 today to add new modules, new extensions"

<marcosc__> +q

PaulCotton: we need to find the right candidates and figure out how to use that hook.

<tantek> paulc: "we have the facility to do the modularity. we need to find the right candidates, in the HTMLWG in particular, and figure out how to use that hook."

<marcosc> -q

<Zakim> tantek, you wanted to reply to Sam re: "split that spec up" It's a trap!

TantekÇelik: danger of modules never getting done

scribe: I'd recommend to talk to those who have been burned.
... talk to me

PhilippeLeHegare: Plenty of other WGs are working on HTML at W3C
... it would be nice that extension fit in

<tantek> koalie: specifically danger of modules of breaking up HTML5 itself

MarcosCaceres: I would expect specs to fail. that's ok

<tantek> agrees on both of marcosc points.

<tantek> or all three ;)

tantek, if you've got them, please, write them down

<marcosc> MC: spec is hard to extend because it's self referential

<tantek> marcosc: said: 1) ok that specs fail, 2) HTML spec is heavily interwoven, 3) appears to be [job] security for Hixie

BrianKardell: Talk to me, I'd be happy to say more. Including in a bar.

Marcos: Let's try this new model!

RobinBerjon: Thank you
... heartening to see so many people interested
... donut be scared! come at the table we'll figure it out

<tantek> I would be ok with an HTML 5.1 if it was a *strict* subset of HTML5. I am ok with an ever shrinking core HTML5.x spec and the rest spun out into modules.

- DRAFT -

Breakout: After (HTML) 5 - Web Standards Ecosystem in 2024

29 Oct 2014

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output