MDN Web Docs & W3C

<scribe> scribenick: addison

(intros)

ali: explain the advisory board
... what it does now
... save time for discussion
... as MDN transitions to be canonical web stds doc
... makes sense to bring in other groups in industry
... content prioritization and such on MDN site
... formed board a year ago
... google, msft, samsung, broader internet
... w3c, mozilla
... added bocoup
... purpose was mostly prioritization
... represent browser vendors and others
... board puts feelers out into other communities
... for example microsoft, or google team to get more content into tools like lighthouse
... pull web paltform tests into documentation
... specifically with w3c
... work with andreas specifically
... talking to IMSC and epubs
... various specs and technologies
... good unforeseen effect
... areas we can make improvements in mdn
... have set of priorities personally
... "all have our own agendas" (nods to I18N)
... chinese use of mdn has grown exponentially
... 150-170% yoy growth
... want to better serve chinese community
... browser vendors but also users
... broadly internationalizing site more
... platform level stuff to make better experience than wiki editing

patrick: microsoft excited becayse like shared tests
... tabularized data at bottom or machine readible
... can have pop up that says "not supported in borwsers targetted"

alex: that's overview

dom: w3c, one perspective
... understanding how we creat closer coordination
... between spec dev and documentation
... make sure doc refers to the right one
... some standards not covered in MDN
... made interesting progress
... interested in getting feedback o nhow to create closer coord
... two faces of same coin

Boaz: work on PAB see canonical mapping of webdev features to standards
... MDN holds framing how devs talk about it
... talk about webplat in different terms
... at Bocou talk about standards in diff way

@@@: any JS standard reference has a link back to the specific thing

scribe: is there something beyond that?

Boaz: no, that's what I'm looking for
... might expose in a more like API

dom: first level, data about linking between specs

Joe: sort of
... only connection is table in MDN
... human readable not machine read

alex: we're puttinga plan together for next year
... things to support Machine read
... piecemeal migrating chunks
... code samples.
... scannable
... broadly helpful

patrick: way to note request?

alex: file issue

<alis> https://github.com/mdn/pab

Joe: connecting features to spec does not feel like a BCD

alis: put link to advisory board
... had all meeting notes
... also has issues

<dom> https://github.com/mdn/pab

MikeSmith: API requested, not getting soon?
... team has priorites set for a while
... best long term is API
... did some work, forked BCD, all of it
... write script to scrape MDN
... extract links to specs
... under w3.org in github which has all spec urls
... loriann schultz, one spec / BCD feature
... methods with mutliple signatures, how you document that in BCD without multiple spec URLS

<xfq> https://github.com/w3c/mdn-spec-links

<xfq> https://github.com/w3c/browser-compat-data

MikeSmith: talked about with xxx
... for each js feature
... has 4 refs
... don't care about spec archaoology
... one canonical spec

joe: sounds good in theory
... features covered by multiple currently active specs

MikeSmith: out of englightened self interest
... inject as part of build process
... inject from spec back to MDN
... 761 injected into HTML
... not just link to MDN
... but also the BCD table, support matrix not for every browser but for same subset
... biz benefits
... look at coverage
... next step takes bcd and make json file in 210 specs
... a lot using tools, bikeshed, respec
... open automation so users don't have to do anything
... tool uses data from bcd
... get from tools for free
... all without API
... built on scraping
... as up to date as the scraper
... don't know how long to get away with it

alis: encourage skunkworks

joe: have pinged mdn urls

alis: on resource side mostly solving that
... one thing we're looking at, how we fund mdn
... how we fund
... uping specifically how we get more machine-readable
... more mdn to github
... vs. wiki
... current wiki plaf is so unstable that everyone dedciated to keeping running
... getting an actual API to data
... have to get to a state
... by end of 2019 have big chunk of data

boaz: that's cool
... semantic linking
... invest in how to maintain reationships
... between specs and docs
... we do a lot, specs to tests
... specifically for js
... in test262
... lot of submit info
... have feature tags which would be good to interop be same as concepts in mdn
... not sure necessarily not just docs
... valuable diff spec and test writing entities
... this kind of mapping data set
... reflected in data set

rachel: one thing I do at MDN is update contact data
... do on specs I know about well or am working on
... some specs better than others
... great if in MDN change made because test update
... know about layout and do ones I know about less good than having relationship
... expose tests exists in MDN
... let devs know test exist, spur contribs

joe: doesn't just say T/F, but specific version
... webplat tests may not provide?

boaz: do collect that data

joe: want to talk offline

boaz: not in github, we have

joe: have similar tool
... confluence

<dom> https://web-confluence.appspot.com/

boaz: more existential tests, sees if API exists but not test surface area
... about 5-10% there

joe: chat offline

patrick: exposing tests
... hesistant, some have like 10K tests
... some have like 4 tests
... quality is all over map (general laughter)
... 10K but 9999 wrong or inconsequential
... as a non-chrome browser, hard to have a large red number
... when not sure what means

<Zakim> r12a, you wanted to discuss i18n/a11y stuff

patrick: wptfyi proxy as quality a concern

joe: known issue with confluence
... getting enormous number of false positive on chrome
... on chrome42
... traced to internal change in 42

boaz: can I respond?

dom: offline

alis: have conversation about webplat tests everyt ime we meet
... lot of infra work needed
... great offline topic

rachel: if something chagnes

patrick: make a note
... reach out on github
... if you're not on all the time

<r12a> https://www.w3.org/International/articlelist

<Zakim> r12a-fallback, you wanted to discuss i18n/a11y stuff

<r12a> https://www.w3.org/International/techniques/authoring-html

richard: lots of articles in I18N WG
... here's a list
... thing in second URL which is organized by task
... get lists of dos/don'ts
... docs we have (most that WE have)
... that help understand more

<r12a> https://www.w3.org/International/articles/vertical-text/index

richard: here's an example of how to vertical text in CJKM
... we think this is good
... MDN may be unaware of it
... some things could use more of it
... want to direct authors to it
... we think web for all important and need more expose
... point to our articles, we have a review process and think they are authoritative
... because a11y and i18n are things you should know about
... not jsut "some links you could look at"
... really should know
... s o have proposal

<r12a> https://github.com/mdn/pab/issues/1

richard: possible me making this go slow at moment
... it is issue #1 on your list (!!)
... like to set links on things like @dir and writing modes property
... and to do so in section that's recognizable like "web for all"

patrick: as separate section?

richard: having an extra box at bottom (penalty box)

patrick: concerned that it's be unexpaned
... had a11y recently and got lots of feedback
... relegated to weird corner not helpful

richard: want to make clear is can't put everythign in our articles into MDN page
... how do I do X or Y
... whether that's in body I'm open to discussion

alis: on one side, asked content lead to put i18n on roadmpa
... doc on RTL is terrible
... enough changes that it makes sense to reexamine
... scope piece to figure out

patrick: chris mills has more article like structure, good for posts on i18n
... more of a mindset rather than specifici api

rachel: did some guides on like CSS

alis: how to approach
... tutorials beyond just approach to specific specs
... so need multiple approaches not buried in one place
... get prioritized
... hack an MDN, did one in sept. for a11y

<rachelandrew> https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout guides linked from the sidebar

alis: schedule a year of small hack sessions at a11y confs
... one way to kickstart, actually schedule an i18n hacking weekened
... 2-3 days to get bones in
... plaf pieces, get relevant people in room to get start
... some is pre-work
... defining the theme works well to get fron theory to actual

patrick: having a contact point

<rachelandrew> another possibility, I've been doing a "CSS Layout Cookbook", quite nice for pulling together concepts based on real things people need to do https://developer.mozilla.org/en-US/docs/Web/CSS/Layout_cookbook

alis: chris and I will talk about this and early coord and content writing
... 2 people on MDN team

richard: initial contact is just me
... thx

patrick: lots of infra comments
... how to handle i18n versions

alis: don't want to sacrifice i18n while moving to github

@@u: few months ago worked with MDN team

scribe: experience super good helpful
... can also see resources are limited
... thought about how to amplify
... useful link for w3c to mdn
... lot of people can kick off
... does it make sense to give guidance or workshop?
... teach more people at once?

alis: good idea
... suspect some barrier is wiki itself
... it's challenging
... if you don't do MDN consistently it is daunting
... it's old and funky
... once moved to github we get vast increase in contribs
... also on code samples
... that's where people are comfortable
... shifting, one is machine read and two is contributaiton
... get more people, linking between w3c and MDN, if all using github easier

joe: those of us who have to keep track, the shift from handbuilt tables to json files in a github db
... I could quality check everyting
... fixed a lot of errors
... in MDN data this year

mikesmith: if we could talk about going forward
... ideas about how to formalize "responsibilities"
... have a lot of people, a few editing
... take CSS, small number of editors
... lots in WG who look to contrib
... want to mvoe work forward
... if we could get WGs to assign resources
... get people to work on MDN docs for WGs
... few characteristics that are better contrib oppty
... also work on web tests
... learning curve is very large
... and review process is really tough
... like writing test but even scares me away
... as a contrib, in MDN no review process, just post contrib
... with a like Chris Mills go fix something
... makes it easier
... editing a spec is a huge commitment
... chairing, writing tests, etc.
... have a lot of peope who could contri
... many people we could measure as a success metric
... comes down to webdevs using
... come to tpac and sit through entire session
... don't know how it'll solve
... but MDN can show how can actually use
... exploit oppts
... while learning, document
... many we can draw on

joe: one thing I'm doing to help quality
... involve engineers in writing/review of features
... more frequently than you like engineer who wants to editorialize

<alis> ali: for follow up or more questions/suggestions my contact info is aspivak@mozilla.com

boaz: feature policy and dev docs examples in spec
... echo that

alis: dropped contact info in IRC

dom: also happy to be a contact
... and Dan for TAG
... and patrick
... not end of conversation!