See also: IRC log
RRSAgent: start logging
<SimonSapin> Lachy: ping
RRSAgent: make minutes public
RRSAgent: make public
RRSAgent: make logs public
RRSAgent: make minutes
<darobin> rock and roll
[Showing humerous "under construction" themed spec on screen.]
fantasai: we are gathered here
today to bring the W3C spec styling up to date
... this is what our current drafts look like.
… header information is part of the official boiler plate, but it's not consistent.
… Well, it's slightly more consistent than the status section/
… here's a status section, the TOC, conformance section, acknowledgements
divya: some specs have a list of changes
fantasai: some people find this
... the point of this is that there's a lot of junk here. Our goal is to cut the junk and hand it off to a designer
rigo: I have a suggestion. I'm a fan of the Opera bork browser. When it hits the Microsot site, it changes everything to "bork bork bork"
… We could hae CSS to change the status section to this :-)
… Seriously, we coul dhave sections that collapse and expand as needed
fantasai: so tantek and I got togethet and said, what metadata needs to go into the spec?
… this is the list we came up with.
… e.g. W3C logo, which WG, title,
… Pub date. Needs to front and centre, so you know how recent it is.
olivier: you don't really need the WG.
fantasai: Status. CR, WD, etc.
… status disclaimer. It's long, no-one reads it. But we need something to say that it's a work in progress.
r12a: are you saying we need to have them at the beginning or anywhere in the document?
fantasai: we need them to be easy to find.
rigo: Sometimes there is text for the "Cover Your Arse" case. Rephrasing is not an option. [Legal reasons]
… the question is, how can we maintain a kind of a hint to the "bla bla" that is kind of sufficient, that a court say someone can't have overlooked it.
robin: We have ideas for that.
fantasai: hopefully there will be a standard place for that.
… some disclaimer for people new to specs
… We need a copyright, patent policy, where to find disclosures, errata, issues list, FAQ link.
… Something that not all specs would have, but a common desire.
… the at-risk list, discussion fora (mailng list), editor's draft.
… we'll talk about dealing with the editors draft issues later.
… test suite link, who are the editors. Important for directly contacting them rather than via mailing list.
… translations and other formats (PDF, etc.)
fantasai: then there's prose things that are common. The TOC, intro and background sections. Some specs have this.
… Example, use cases and requirements. Transition criteria is needed somewhere.
<dom> Meeting: ReStyle W3C specs break out
… References, indexes, glossaries, etc.
Tobie: It would be great to have a link to the source of the spec.
… Community groups are often putting their specs on github. It would be useful to link to that from the spec.
MikeSmith: Do you have change logs in that list?
fantasai: We should have that.
MikeSmith: separate links directly to source and change log
tobie: similarly a link to the bug tracker.
MikeSmith: do you have the thing for filing the bug?
<fantasai> ACTION: fantasai to add changelog link, spec source link [recorded in http://www.w3.org/2012/10/31-restyle-minutes.html#action01]
larry: I've been going to meetings in the IETF. Some people are proposing that the IETF specs should be in HTML.
MikeSmith: sounds radical.
larry: many people are producing
specs with an XML DTD
... There's been some tooling development. interesting one: A tool tha adds all the boiler plate. Is there any overlap in the tooling for producing RFCs, vs W3C specs.
… particularly, biblio
… One thing I like about tooling is that it's has a property of being idempotent. There is some input format, it populates it with the boilerplate, but that output is suitable for the input.
… I thought it might be useful for sharing some of the tooling
… That group is meeting to consider their rules for allowing RFCs in HTML. There's been a long discussion and requirements document.
Robin: There's a different session later about the publication process. This is more about styling.
r12a: You've got index/glossay. Why are they together?
fantasai: They are separate, but there's a whole bunch of different types of indexes, glossaries, etc.
… can't list them all.
is there something that we've missed?
<fantasai> ACTION: fantasai to add changelog link, spec source link [recorded in http://www.w3.org/2012/10/31-restyle-minutes.html#action02]
<darobin> Lea_: http://www.w3.org/wiki/SpecProd/Restyle/Content
dom: It's not something we currently put in W3C specs, but appears in WHATWG specs. Implementation status
… that might be a bit out of scope.
… Not something most specs do nowadays, though
larry: There's a topic that has come up in the TAG re the relationship of specs that normatively reference each other.
<fantasai> ACTION: fantasai to Add item for upcoming/previous versions of the technology (if any) [recorded in http://www.w3.org/2012/10/31-restyle-minutes.html#action03]
… references to the latest version, specific version, work in progress version, etc.
… If you're making a normative reference to something in the same group, you might want to check that things don't break when a spec updates.
… but referencing work from an external group requires a bit more collaboration to ensure things don't suddenly break with normative changes to the referenced spec.
robin: At least where it concerns W3C specs, We're going to do QA tools that will spider things to notice that you're doing things that aren't a definition.
matt: Deadlines are important.
robin: Last call needs deadlines
… I don't think we need to find every last peiece of information. We have a lot of high level stuff, we should move on.
<fantasai> matt: Also some specs have not just editors, but also authors, contributors
olivier: there's a number of things that we want to think of in terms of content. Where and whether do we need to list things like IDL, definitions. Is that out of scope?
robin: We will look at that eventually, but not today. This is more focussed on restyling the header and layout.
olivier: I have learned to completely skip that section and go to the "meat" of the spec.
fantasai: the goal is to make sure we have all of the content that we want to have in the boiler plate, and then how to mock up that design.
… brainstorming of what we want to design to be like, but not the specific design.
… that will take about 10 minutes
… we're not going to do any visual designs.
fantasai: mike is bad at
... karl dubost took some ideas and produced a sample mockup of what it could potentially look like.
fantasai: this isn't to say it's what it's going to look like, just to show some possibilities.
… this is a blog where someone took boarding passes and started to make them more useful.
… there's a lot of creativity that is not present at all in our concept of what the spec should look like
… but if we provide the parameters, then someone can go and do that.
<matt> [[That spec design with ED/WD/LC/etc at the top reminds me: I saw some other orgs specs where they showed what status it was at by listing all status and putting a big X through other statuses, made it very clear. Also appeared to be in (rough?) order, which was nice.)
larry: People like things like seeing a graph of dependencies. Looking at the broader collection of specs, in a group, is useful
fantasai: that's the job of the TR index, not individual specs.
rigo: first of all, I believe on patent policy. It's ok to say there is no incident or there is incident.
… but if there was incident, you need to link to the PAG report.
… Apart from that, it's already sufficient to send this table to the designers and let them unleash the creativity.
… what's missing is the concrete markup that is used for each of these sections. Relevant to the selectors used in CSS.
… If you do the restyle, please check that there is supportive markup for all sections.
robin: that's not going to be a
... We're going to reinvent styling and do it right.
rigo: styling has a semantic aspect.
fantasai: Robin and I sat down, took karl's design as a starting point and try and put it together as a rough design. Here's an example of the speech module where we tried to do that.
fantasai: the markup and CSS in this file is really horrible. It needs improvment.
rigo: you can't just show some "bork bork". You should show all of it
dom: Yes you can
<matt> rigo: bork bork bork
rigo: You have a sentence that takes a lot of realestate, but no colour difference.
divya: this is just a proof of concept.
<rigo> matt, better bork bork than nothing
robin: We made this to show that it was possible to take the information. But it's not a design.
fantasai: we're going to throw this out. This is just showing the information in a differnet way as a prototype.
rigo: Why do you have this note and not others?
robin: it's a design decision.
dom: You can find the other "bork bork" information later on in the document. This was a design decision based on importance.
<masinter> there's a workflow for spec development, have you done the right steps to support the workflow
<rigo> I question that importance of text is a design decision (and agree what dom said)
<matt> lachy: It's useful to be able to display the information quickly, via icons, etc, like Creative Commons, which expresses large parts of legalese in a small set of icons.
fantasai: there's a history section, feedback,
… Licensing is under paraphernailia because we couldn't find a better name
… We tried to group these things to make them easier to find, without putting lots of text right up front.
… Lots more stuff, ending with copyrights and acknowlegements
<olivier> If I can be a bit of a party pooper, a misc section is a bit of a cop-out though
<matt> [[I think that might also be under a label that is perhaps just not the best for now olivier]]
tobie: Could it be possible to have different views for different audiences?
dom: More importantly, if you have different views, not all the content will be seen by everyone. No-one will see a lawyer specific view
Lachy: The WHATWG spec tried this.
robin: That creates problems for review. We found in the HTML spec that there were incorrect annotations about what was for authors and what was for implementers
dom: Developers don't read specs.
fantasai: when we redesigned the CSS WG homepage, which is not live, divya came up with a fantastic design. The designer asked the CSSWG how we want the design to feel. Came up with 5 adjectives.
… I want to do the same thing here. Come up with 5 adjectives for specs
Larry: The formatting should be reviewable.
… form follows function
divya: everyone in here should join spec-prod mailing list
RRSAgent: make minutes
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/otu/out/ Succeeded: s/XXX/Tobie/ Succeeded: s/importants/importance/ Succeeded: s/Carrine/Carine/ Succeeded: s/Creative Comments/Creative Commons/ Found ScribeNick: Lachy Inferring Scribes: Lachy Present: fantasai divya rigo tab simon oliver richard Lachy Robin Matt Dom Larry_Masinter Tobie Tobie_Langel Carine sangwhan Got date from IRC log name: 31 Oct 2012 Guessing minutes URL: http://www.w3.org/2012/10/31-restyle-minutes.html People with action items: fantasai WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]