HTML Interim Face to Face -- 24 Apr 2013

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/6e3d038632054634da4b9a127a91a68ab306ce8d

<gitbot> 13html/06master 146e3d038 15steve faulkner: CSS style switcher script

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/ec9ab241c985dfc10aa23a3ca709cf9f0930c62b

<gitbot> 13html/06master 14ec9ab24 15stevefaulkner: Update header-w3c-html-core...

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/e9d4d4e54c6a323c69ea512ca1ea6e70156e7d41

<gitbot> 13html/06master 14e9d4d4e 15steve faulkner: moved CSS swap script

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/3c90ab886fe9c61f71b2966fbe451196d727abd0

<gitbot> 13html/06master 143c90ab8 15steve faulkner: W3C-ED dev view CSS

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/a4a72db3cc7676f20e9aee2d4a4d3c2ac7508f4b

<gitbot> 13html/06master 14a4a72db 15steve faulkner: removed css switcher files...

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/d4307f7aafaef10ff7233e621e17d2f3056d91d3

<gitbot> 13html/06master 14d4307f7 15stevefaulkner: Update header-w3c-html-core...

<stommepoes> zomg discovered "dirty flag values" in HTML... boy do I know little.

<paulc> http://www.w3.org/wiki/HTML/wg/2013-04-Agenda#Agenda_April_24

trackbot, start meeting

<trackbot> Date: 24 April 2013

<scribe> scribe: Josh_Soref

<scribe> scribenick: timeless

Polyglot document

eliot: i want to thank the chairs for adding Leif as an editor
... that's been a huge help
... we're down to three open bugs on polyglot
... we expect to hit 0 bugs in the next week or two
... given the history of discussion around polyglot
... especially around normative spec and around UCs
... i thought it'd be opportune to throw out
... the idea that we're getting close to a CfC about Status of Polyglot
... to ask the people assembled if there are areas of discussion
... and recommendations for the spec before we get to that point
... the three open bugs
... one is to drop XHTML from the title of the document
... leif has made a first edit on that
... we're waiting for a response if any before resolving that as fixed

<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=19925

eliot: my understanding is he was waiting to see if there was any response to his subtle change

<paulc> Leif's direction: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19925

paulc: the comment 16 has what he intends to do

eliot: and later he talks about

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19925#c16

paulc: larry was giving arguments for keeping it

eliot: two paragraphs earlier "i'll try to incorporate more comments"

<paulc> Title: «Polyglot Markup: A robust profile of the HTML5 vocabulary»

eliot: the other assigned to leif is 21174

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21174

eliot: he opened the bug
... and said what he's planning on doing
... and he said he'll work on this in the near future

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21174

paulc: item 6 here says something about the HTML5 spec

<paulc> Leif, When will bugs 21174 and 19925 be processed?

<eliot> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20197

eliot: on this one, i need to speak w/ rubys
... he said rubys described Polyglot as an applicable spec according to HTML5's terminology
... you had a should/could/had-to be an applicable spec

rubys: i believe i made that remark
... i didn't necessarily intend for a change to the spec

eliot: in my understanding
... there's no required definition of Polyglot as an applicable spec
... so we'll be down to two bugs

paulc: can we find the results of the first CfC?
... was it in December?
... - trying to take HTML, canvas, microdata to CR?

eliot: it was right after TPAC

paulc: we decided we'd do a Preference Poll after we got Objections
... we wanted to get down to 0 bugs

rubys: we assigned a new editor, that helped

paulc: you, rubys, built the survey

rubys: if it's Editor's intent to persue REC, then yes
... you need the Poll

<paulc> Rationale for keeping on Recommendation Track: http://www.w3.org/html/wg/wiki/PolyglotRecommendationRationale

<rubys2> https://www.w3.org/2002/09/wbs/40318/polyglot-status-preference-poll/

paulc: it's possible the rationales need to be updated

rubys2: the preference poll is not yet opened
... it references two rationales

<paulc> Statement why Polyglot should be informative: http://lists.w3.org/Archives/Public/public-html/2012Nov/0006.html

paulc: before we run this poll
... i think we should make sure both rationales still stand
... chairs should ask the rationale authors to see if they should be updated

rubys2: one of the rationale statement editors is here

paulc: could you and he, eliot, check to see if it needs to be updated?
... this is a case where we will ACTUALLY COUNT HEADS
... every for and against actually counts

rubys2: BY PERSON

paulc: i'm not sure what the preference poll actually says
... "Survey is by individual, not organization, simple majority wins"
... since this is a process, not technical
... we don't need to ask for additional statements
... we're assuming this is the definitive list

rubys2: once we get LeifHalvardSilli and eliot updating their statement
... and spec
... we will ask to see if anyone else wants to expand on hsivonen's comment

paulc: does the survey point at the Polyglot document?
... it doesn't appear to

rubys2: that (first paragraph/sentence of survey question) would be the place to do it

paulc: when we go to 0 bugs
... and do a survey
... if the doc isn't stable
... people bitch

eliot: ok, no changes during the survey

paulc: people say the document keeps changing underneath me

rubys2: Am updating it now

paulc: assuming Poll result is "Normative"
... then that would mean we'd publish as CR
... the reason some people think it shouldn't be normative because it's a subset
... we'd need exit-criteria for/from CR
... editors need to think about those
... but we won't process it until after the Poll
... just as a forewarning of how to get out of CR
... and the period of review

<rubys2> poll has been updated

Plans for Heartbeat publications

darobin: in terms of heartbeats, we haven't published in a little while
... we need to issue a bunch of new documents
... those we plan to publish as simple heartbeats
... are HTML5.1 with simple changes
... Canvas 2D level 2 with simple changes
... and Differences between HTML4.01 and HTML5
... that part isn't really contentious
... after that, we have documents we plan to discontinue
... documents which we'll publish as NOTE
... one is <main> which we've folded into HTML5.1 and are folding into HTML5.0
... - indicate that
... one is HTML5 for web authors
... - few authors actually use them
... we've been in touch with the webplatform.org people
... who might have a use for pieces
... other parts may be folded into HTML5

paulc: this sets precedent that an extension spec
... if it gets folded into some HTML version
... then we'd publish the extension spec as a WG NOTE with a SOTD indicating that we folded it into the HTML spec

darobin: to make it clear what happened

paulc: plh, do WG NOTEs show up directly on TR page?

plh: they do

paulc: template is different?

darobin: it says "NOTE" in the corner

<plh> example of discontinued item: http://www.w3.org/TR/webdatabase/

darobin: we're also discontinuing "HTML The Markup Language"

paulc: we can tell the room that's what we want to do
... we're resource constrained
... do we do a call for volunteers
... if we could have people edit them
... do we want them to continue
... or do we not think they should survive?
... or do we want a CfC w/ an anchor to the document of that time

darobin: if we had volunteers, we could talk about it
... but only one, and not both
... HTML for web authors is generated from the HTML spec
... it's complicated and tends to break
... if we were to keep one of them alive, i'd say it would be "HTML The Markup Language"
... but it would be a better fit for webplatform.org

<Zakim> MikeSmith, you wanted to saay

MikeSmith: both of those documents are generated
... HTML The Markup Language is generated from the Schema of the validator
... both of them have XSL Style Sheets
... anyone volunteering should be able to prove they can handle the pain
... or they could redo them
... the issue is there's not much demand
... not many who would miss them

paulc: are there bugs?

MikeSmith: they're mostly non-normative bugs

SteveF: what's the difference?

MikeSmith: source for HTML spec is marked up w/ class values w/ every paired ref and in some cases even spans of text
... e.g. that only apply to HTML UA implementers
... the build script drops the HTML UA sections
... the idea was so that you didn't have to do the style switching
... the spec has dfn's marked up w/ generated cross references
... in the source for the html spec .. in Hixie 's upstream version
... but the refs don't work across the multipage document
... if you click up a dfn term
... it shows a popup with everywhere it's used in the doc
... but you have to use the 6mb spec document
... when i wrote the build, i made it work across multipage for the author's version
... the other problem is that sometimes it references stuff
... even when you get a popup
... sometimes it references something only in the full spec version
... so i made the script distinguish between "in author edition"
... and "need to link to full version of spec"
... i don't care, and no one has filed bugs
... indicates no one is using it
... if someone was able to show they're serious about maintaining
... i'd say ok, let them do it

darobin: if we have someone we don't like
... and want them to spend time on it

MikeSmith: a honey pot

paulc: plh could handle it?

[ records stop ]

SteveF: with the style switcher, we get the author view w/o the pain

MikeSmith: yes
... also with HTML The Markup Language
... the spec has attributes w/ short descriptions
... so you don't have to go down to the core
... but Hixie did that to the upstream spec
... also, there are rules in HTML that people still are confused by
... and XML and HTML helped confuse people
... you can omit <body>, you can omit <html>
... there's a section in the spec (syntax) where the rules for omission are listed
... Hixie recently put the tag omission rules into the individual tag sections
... so now this added value is obsolete
... there are a couple of other style things we could migrate
... we don't need to worry about losing

paulc: sounds like we need emails to html-admin@
... "discontinued document X"
... with rationale heard here today
... with an explicit request that people who disagree please respond to the thread
... the emails should provide the positive reasons
... - that the base doc now satisfies these needs
... one of the editors should sign up to send these messages
... both you, MikeSmith ?

MikeSmith: yes, both me

paulc: do two separate messages w/ clear subject field
... first paragraph w/ executive summary
... why document will be discontinued
... publish as WG NOTE
... give story as you gave now

rubys2: make the default what you want
... that they go away

eliot: rubys2 you lost your projecting
... that's not why i'm on the queue
... to respond to darobin
... i reached out to shepazu
... he and i will look at the content and see where it makes sense to merge it over
... we're happy to take content

darobin: there are bugs in the publication system
... we're working on fixing them
... hopefully by the end of the week

paulc: editors need to publish the chairs
... for the three documents
... HTML5.1 heartbeat
... Canvas2D level 2 heartbeat
... HTML4.01 to HTML5 heartbeat
... you need to give stable versions of those documents
... we'll run a CfC together to get them published
... sound like a plan?
... we should try to publish those every 3 months

darobin: 3 months

paulc: <main> is in HTML5.1
... current activity is getting <main> in HTML5.0
... that doesn't hold up this heartbeat?

darobin: right, it's been in HTML5.1 for 2 months
... at some point i'd like to publish a FPWD of the Ruby Extension spec
... i'll talk to you about issuing a CfC on that

paulc: i think you sent a note to public-html@ about that spec
... did you get a response?

darobin: not on the list
... but i did get direct
... partly from implementers, "yeah, that looks good"
... and one from i18n people, they found a bug

paulc: you're putting something into HTML5.0
... stuff that overrides what's in HTML5.0?
... was that in the AT RISK list?

darobin: i don't think so

paulc: is it your intention
... you've spent a lot of time on this
... was your intention to get this spec caught up so it could fold into HTML5.0?

darobin: it would be nice
... but i don't think the implementation schedule lines up

paulc: the problem isn't tests
... it's implementations

darobin: hard to fold into spec without implementations

paulc: chaals and A11Y TF learned
... there are granular blocks of time between FPWD and LC
... no reason to wait to 0 bugs before FPWD

darobin: i just think it should be fixed first

paulc: darobin is on hook to tell chairs when he is ready w/ Ruby spec
... and we'd do a CfC on Ruby
... question to Process experts
... can you do FPWD and LC at the same time?

plh: yes

chaals: yes

paulc: do you have to wait for LC?

chaals: it's common to wait
... there's the 60 day timeout

paulc: is there any reason not to do FPWD and LC at the same time?

darobin: i'm happy to do them at the same time

paulc: seeing some people shake their heads
... i thought process and Patent Policy were written to encourage people to bring well formed work to Consortia
... so if it was a NOTE it didn't have to do multiple WDs before LC

chaals: in principle, yeah
... in practice
... FPWD and look for comments before LC
... isn't a bad idea
... if you do FPWD and LC at once
... you're more likely to get a second LC
... it's a social thing
... best not to have "LC" isn't "first in a series"

paulc: right
... you're saying if you do LC, it should really be _the_ LC

darobin: either way is fine
... if we do them together, we need a long LC period anyway

paulc: just wanted to consider possibility

rubys: what do you recommend we do in HTML5.0?
... i understand current target is 5.1
... ruby isn't marked as AT RISK
... what should happen to it?

darobin: it's a problem
... i didn't think about marking as AT RISK
... what's there is really buggy
... it doesn't make i18n people happy at all
... if this doesn't make it
... we should look into dropping what's there
... ideally we could get this in 5.0

rubys: if it doesn't make CR exit criteria
... it doesn't make sense to put in
... but it might make sense to drop the current ruby

darobin: the way the spec is written is very buggy

rubys: it's got an infinite loop

darobin: it doesn't really work

chaals: are they using what's in the spec
... or markup like it

MikeSmith: this isn't a candidate that's buggy enough to remove

darobin: the spec is really buggy

paulc: you collected all the bugs on ruby in the document
... and instead of attempting to fix the 5.0 document
... you put the suggested change in an extension spec
... what did you do for the bugs in 5.0?

darobin: we don't have a component, we could make one
... they're still left open, assigned to me

paulc: some of those bugs might not be sufficient grounds to take them out of

MikeSmith: i'd say they aren't
... i know the guy who implemented it in Chrome
... he didn't have a huge amount of trouble implementing it

darobin: he'd have to read between the lines
... as is, you get lots of infinite loops

hober: that's really where Ruby is, it's between the lines

[ Laughter, Applause ]

MikeSmith: i don't remember there being big problems
... it's in WebKit, Chrome, Blink, IE

paulc: saying it's being used didn't prevent us from removing
... <hgroup>

darobin: there's perhaps a way to fix part of it
... and the rest in extension

MikeSmith: main use is Japan
... they won't be happy if you remove it from the spec
... it's a waste of time to talk about removing it

darobin: hybrid approach, take fixes from extension spec
... migrate to HTML5 spec
... but w/o introducing new features

MikeSmith: sounds fine
... but yanking doesn't seem valuable

rubys: value in having in spec

darobin: we can split it
... extension spec adds features
... we can leave them out
... existing docs really doesn't work
... happy to look at webkit

MikeSmith: talk to roland

paulc: straw man
... darobin closes final bug on his Ruby spec
... that we publish FPWD
... would that by itself cause a storm of response?

MikeSmith: no, they'd be happy w/ that

paulc: darobin, does your draft enumerate the bugs it's trying to solve?

darobin: not as bugs, but it states the UCs

glenn: i'd like to have a FPWD and not do LC simultaneously

paulc: that's fine, i wanted to examine things
... but we agree that's rushing the horse out of the barn
... but, darobin, i'd like the status section to indicate the bugs it's addressing
... but agree w/ MikeSmith
... want to contact implementers

darobin: implementers read it and gave feedback

MikeSmith: would be nice to get input from Mozilla
... instead of not implementing

SteveF: sounds like there's some spec that should go back into 5.0
... and some to sit outside of 5.0
... why not put it in 5.1 spec for review
... bits we agree upon that could go back to 5.0?

darobin: i don't want to commit
... it's one big painful algorithm
... i'm not sure whether it's splittable or not
... into sensible pieces

SteveF: will it eventually sit in 5.1?

darobin: at some point
... but i'd rather not do the work of integrating just yet
... it's a fairly big delta

mjs: first step before backporting
... is to identify most critical
... if backporting doesn't work out
... maybe someone will be motivated to hotfix the most critical issues

darobin: you have to replace the entire algorithm

mjs: have you checked to see if the new algorithm matches the existing implementations

darobin: the new features...

mjs: ignoring those
... for the feature set people tried to implement

darobin: it partially matches
... except where i think they're wrong
... e.g. WebKit loses whitespace
... where i think it shouldn't
... it doesn't come up often
... only matters w/ Ruby on Latin languages
... but it matches most of the rest
... afaict

paulc: steps

darobin: 1. file bugs not currently filed
... 2. fix bugs in my alg
... 3. fix bug in extension spec
... 4. make SOTD point to actual bugs
... 5. talk to chairs about FPWD
... 6. see about backporting to 5.0

paulc: i'll assume MikeSmith agrees then
... i heard mjs asked
... double check to make sure your algorithm
... see how it matches existing code

darobin: in my view, it's part of backporting to 5.0 (#6)

[ #2 and #3 are the same, so there are really only 5 points ]

paulc: schedule has us talking about issue-194
... reconvene @ 10:35

Assigning a transcript to audio or video (ISSUE-194)(A11Y TF)

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/218c893c5bbd4767dd26579010ae1ac955c4cb6f

<gitbot> 13html/06master 14218c893 15steve faulkner: added style switcher files

JF: a recap of the issue formerly known as issue-194
... we have a longstanding issue
... to have a programmatically associated transcript to a video
... a group of us looked at UCs
... we went through a WBS survey
... got 4 responses
... this is sitting in limbo ASAP
... from an engineering perspective, it may not seem big
... but there's legislative ... that can...
... there was an idea of introducing transcript= and <transcript>
... the <transcript> element would be what contains the transcript
... and transcript= would take an idref to that <transcript>
... there could be a link to an external document, an embedded iframe/div
... or dynamic html
... you could get visual highlighting of words as they're spoken
... the definition of Transcript is very broad and very vague
... we looked at putting <transcript> as a child of <video>
... but the UCs for displaying it onscreen would be very messy
... we haven't gotten implementation by browsers
... this can't be mothballed [because of legislative consequences]
... we wanted to have a dialogue in this WG
... the group that worked on this was 5 or 6 people
... we need broader input

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/5af0b7eb875841e4a5f923ef596ee8927c1ab0e9

<gitbot> 13html/06master 145af0b7e 15stevefaulkner: Update Makefile...

MarkVickers: is there a time for when Regulations come into effect?

JF: it's complicated, it's an international question
... we don't have a specific date on a caendar
... there's the US Digital Communication Act
... the area of video accessibility on the web
... sooner rather than later
... legislation will probably lead demand

MarkVickers: there's a captioning requirement coming into effect in January

JF: we're hearing feedback when we talk to accessibility providers
... it would be huge when you have a Professor drawing a venn diagram on a blackboard
... in a University
... we have legislative requirements for this
... we need a standardized solution ... in HTML5, 5.1, or extension

hober: JF's description is pretty accurate
... we had an active survey on 2 proposals when Plan 2014 was adopted
... by adopting Plan 2014, we agreed people interested in pursuing this could proposal proposals
... i'm not aware of new technical issues
... i think we've talked about this a lot
... the next step is writing an extension spec

paulc: one or two?

hober: i'd expect 2, as there are two proposals
... unless someone leads to convergence

paulc: is that what you want, JF ?

JF: if that's the only feedback we get from the group
... we haven't gotten feedback from the implementers
... my perception is that this has been low under the radar
... as other issues have been dealt with
... but this could spike very quickly
... we need to actively engage on this

[ rubys projects Plan 2014 ]

paulc: "when you want cookies, don't go to the shoe counter"
... i understand you're coming here
... but this says the TF has the authority to produce specs
... the TF is encouraged to converge onto a single solution
... i'm a fairly regular attendee
... i don't think this item has been on the agenda
... this was a clear agenda from 2014
... wonder what happened to other items on this list

SteveF: when i first became co-chair of the TF
... i approached people involved
... including hober
... asking whether they'd be interested in developing extension specs
... i didn't get any positive response
... it hasn't been brought up since then

chaals: i'm chairing the next TF meeting
... i've noted it for the agenda

paulc: anyone can write an extension spec
... if we don't have volunteers to write them
... maybe we'll have two
... history of this was
... - two different approaches
... 1 lawyer in town goes broke, 2 in a town make a lot of money
... if you want convergence, write your extension spec
... that will probably get the other to come out of the woodwork
... until one occurs, not much will happen

JF: taking advantage of the people at this F2F
... the A11Y group has engineering holes
... we need help

paulc: hober do you remember if we asked

hober: i think we did ask

paulc: we have 2 proposals
... we tried to get some sense for what implementers would actually implement
... there's a bit of work to writing an extension spec
... but JF 's view is
... this is a piece of functionality which is really important
... if the implementers would say "yay, we want to do it one way"
... that would make it easier for us to work on it

chaals: we had preference for design A or B, in varying proportions
... but the margin of error was the biggest winner

hober: i could take an Action to find the results from that meeting

paulc: my only other suggestion

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/0a9e5b78ccac3d016b0be954cd8fb5ef7cafc8b1

<gitbot> 13html/06master 140a9e5b7 15steve faulkner: tweaked author CSS

paulc: once hober replays that
... perhaps chaals, we could get more people to the call on that topic
... failing that, if you want to add it as a topic to a WG meeting

chaals: i think, we raised the thing, noted the issue
... TF -- go write extension spec
... see if TF gets consensus
... if not, bring to WG, see which way we jump

mjs: any implementers want to express an opinion?

Web Performance WG issues related to HTML5

DanielAustin: we started talking yesterday about WebPerf on Media Status codes
... we met this morning
... we divided these errors into persistent errors and connection related errors

<DanielAustin> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html

DanielAustin: the spec we mentioned yesterday has been dropped into two drafts
... my proposal was that since we're doing error logging anyway

<DanielAustin> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceErrorLogging/Overview.html

DanielAustin: it might make sense to join forces
... between media status codes
... what we're trying to do is supplement the existing Navigation and ResourceTiming APIs
... we've cataloged a bunch of errors
... a bunch from the IANA registries and from the HTTP RFCs
... we added things for DNS
... but things wouldn't work if we couldn't handle media errors
... my proposal was to combine forces and have status codes standardized as part of webperf error logging activity

adrianba: the error codes
... and types of error
... that you're trying to support w/ these apis are focused on Networking
... is that true?

DanielAustin: networking and http
... but we spoke about CSS and JS errors
... if you're feeling it isn't necessary/don't want to do it now
... it occurred to me we're working in the same direction

adrianba: my feeling is we're not working in the same direction
... these things are orthogonal
... it's possible some communication errors that you're logging might occur during applications doing media playback
... in that situation, the resource error logging would already be in place
... should be using some aspect of the Media element, or XHR
... that would already be covered by the resource logging
... my question for WebPerf
... could you give us an example of something that wouldn't be handled by Resource Logging that we should consider?

DanielAustin: my thinking
... i have a page w/ Media and it fails
... and you return a status saying media file didn't start
... as someone reporting diagnostics, i'd want to say why did that fail
... i have two disconnected systems for logging
... and i'd have to try to correlate

adrianba: i don't think that's true
... for the places where that error would occur, i think the resource loading error spec would already cover that
... the resource loading in media would already be covered by the normal bit
... in MSE, the JS app is responsible for where it gets data
... it could be from network, some other api, file api
... whichever mechanism the app is using
... if it's loading using network, logging would catch that
... i don't think that's something not already covered
... if during WebPerf discussions you identify something

DanielAustin: we split Error Logging from Timing
... alright, if that's the sense of the group

<plh> http://www.w3.org/wiki/Web_Performance/Publications

plh: WebPerf WG...
... some of them are actually looking at extending the HTML language
... one is a resource priority specification
... right now you only have differ= attribute on elements
... we'd like to see if we can do more with that, for css, ...
... don't sue us
... the first draft came up last week
... it isn't complete of course
... i wanted to inform this WG

paulc: would this thing label itself an extension spec?

plh: it would be an extension
... but it might also refer to non html stuff
... resources linked from css

paulc: so it's a @webplatform extension spec?

XX: which we'd usually call a spec

plh: we'd probably come back to the html-wg when we figure out what we want to do

paulc: you're proposing to change the order in which html, css, js resources are loaded

plh: we're proposing to give control to the UA to change this order

paulc: is order defined in the spec?

plh: for <script> it is

adrianba: there's a processing order required

paulc: downloading is different

plh: we're talking about download

adrianba: clearly it makes sense to make sure things you need first
... you might download first
... but spec doesn't require you to download in some order

paulc: are you proposing that the page developer is smarter than the algorithms used today?

plh: yes

adrianba: yes

paulc: ok... alright
... surely it wouldn't be mandatory
... i assume plh that the markup would be advisory?
... right?

plh: i don't know

<paulc> An example of error codes in HTML spec: http://www.w3.org/TR/html5/single-page.html#error-codes

paulc: question for DanielAustin
... these are the error codes defined in 4.8.4.1
... trying to understand
... if you get media-error-aborted network-error-not-supported
... you want your logging interface to know which is returned

<adrianba> http://www.w3.org/TR/html5/embedded-content-0.html#error-codes

paulc: why wouldn't you go through the http spec the same way you went through the error codes?

[ DanielAustin had left the room ]

[ DanielAustin returns to the room ]

adrianba: these are the error codes you can get for media playback
... this is orthogonal
... primarily the resource error logging is about stuff that happened at the network layer
... this is things that happened primarily at the decode layer
... trying to mix those two things together may not make sense
... you get something saying that a network error occurred
... well, you could go to the network error logging
... this is a higher error together

DanielAustin: we mix layer 4 errors with layer 5 errors with ..
... - dns, ssl, http
... your spec has similar format to the ones i linked to in irc
... otherwise your object is a spitting image of the error object we have
... the error imagery is similar
... your next step is that you'd interrogate your error logging api

adrianba: and this is no different than for an <img>
... when an error fires on an <img>, that might be from an http source as well

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/674539907acd6ce3baff6bfc8624cf0513952da3

<gitbot> 13html/06master 146745399 15stevefaulkner: Update Makefile...

DanielAustin: are these similar

paulc: why didn't WebPerf look at the html5 spec?
... i found this by looking at the ToC

adrianba: i don't think it's a surprise
... i still think they're different

paulc: i'm asking WebPerf to do their work

Travis: at what scope do you want to collect these errors
... we could go deep
... for every parse error
... everything that throws an exception/error event
... you could try to catch that
... at some point you get diminishing returns

DanielAustin: i don't want to get every CSS error
... WebPerf wants HTTP, anything that's around performance
... we talked about errors from JS
... didn't do details
... it's a hairy monster
... if it isn't fully baked, i'm happy to take that back to the group
... but i think there's some scope for cooperation
... i'd like to hope to avoid multiple collections of errors
... with similar

paulc: we have lots of schemes
... the one to rule them all
... adrianba, you see nothing in conflict between what they're doing and what you're doing
... we're doing something at a higher level
... but the UA could provide this through the interface if it wanted to
... i don't see anywhere in the html 5 spec where we try to do what they're doing

adrianba: there are all kinds of parts of HTML5 spec and other specs
... that make requests from the network
... we don't specify
... once you get the URI for something
... exactly how you go and get that resource
... resource error reporting
... is at that layer
... it's different to what's in scope here

Travis: it's worth considering the lens at which you're considering
... does it affect perf
... Parser, it's going to parse the same way

DanielAustin: i'll take that back to the WebPerf WG
... and look through HTML spec
... all through, i think error logging is really important
... if everyone is defining an object similar to what's being defined here
... that's a duplication

Travis: i'd point you to WebRTC
... who have a bunch of other errors

DanielAustin: i'll take that back to WebPerf
... we'll talk about this

HTML WG Charter status

paulc: "The F2F discussed the charter."

[ minutes will be collated here later ]

<gitbot> 01[13html-tools01] 15darobin pushed 1 new commit to 06master: 02https://github.com/w3c/html-tools/commit/387fff26b78efcf334f38be823d89c177dcc8216

<gitbot> 13html-tools/06master 14387fff2 15Robin Berjon: copy over the switcher directory

W3C TPAC meeting, Shenzhen, China, Nov 11-15

paulc: note that the date of the meeting
... the original dates would be one week later
... but nov 17 has the largest IT conference in Shenzhen
... so the decision was made w/ W3C and the sponsor Tencent
... to move the week one week earlier
... location of a meeting affects who attends
... W3C is aware that having a meeting in China
... may decrease the number of usual suspects
... and increase the number of Chinese suspects
... it's not uncommon for chairs to get observers when we come to the Bay Area
... i want to make people aware of the fact that there are plans to have the meeting in Shenzhen
... it's 1 hour by train / subway, or ferry from Hong Kong

darobin: you want to fly to Hong Kong

<adrianba> http://www.w3.org/2013/11/TPAC/

paulc: i won't say who can get a special visa to enter the special administrative zone
... it changes all the time
... current assumption is TPAC like any other TPAC
... MT-ThF for meetings
... w/ Plenary on W
... intent here to put this item on the table
... to make people aware this is likely to be where this F2F will be
... the draft charter specifically permits the HTML WG to have 2 F2Fs a year
... this meeting here now is our first
... the second would be at TPAC

<Zakim> jeff, you wanted to comment on Visas

jeff: depending on where you're coming from / going to, your mileage will differ
... our Chinese host in BayHung University has graciously offered to issue Visa Invitations
... I can't speak for the Chinese government
... we've gotten assurances from our host and our sponsor that they can get people the visas they need

paulc: in most cases, the only way to do it is in your country of residence
... MS has rules as well on business visas
... because they generate a sponsoring letter
... in Ottawa, you go in a day, hand in passport
... get it back the next day
... don't know if anyone has any questions about this
... there was some question about internet connectivity
... laptop security
... those were discussed at the chairs meeting

jeff: on internet connectivity
... there's some successful record of when they host meetings such as this
... that even sites such as Facebook/Google are blocked
... they have a way of getting international visitors access for sites
... our hosts will work to get reasonably unfiltered internet connectivity
... on laptop security
... that's something that people have different levels of concern/worries about
... i've spoken to people who work for companies
... with no issue whatsoever
... i've heard other people who work for other companies who have some concern
... first advice is
... consult your corporate policies
... for W3 Team
... we've had conversation internally
... a lot of the W3 Team is headquartered at MIT
... MIT has a well defined policy for traveling with your laptop
... if you do these things, you should be comfortable traveling w/ your laptop anywhere in the world
... if not, you shouldn't be traveling with it anywhere in the world
... it's about hygiene of protecting your data
... if you want to travel w/ a "clean" laptop
... people are encouraged to do what they feel comfortable

paulc: that's fine
... whenever i talk about this meeting to anyone involved at W3, those items come up
... that and how to get in/out of the country
... in general, HTML WG meets ThF
... we coordinate w/ WebApps, which meets MT
... we presume we'd continue to do that
... i can't see any reason to change that
... sometimes people prefer to get away or arrive early
... i think we'd stick with what we have done in the past
... any personal/private questions, you can talk to myself or jeff

[ Lunch ]

Check status on other extension specs

paulc: i think we did that for longdesc= and Ruby
... and Polyglot, Microdata, and <main>
... we talked about heartbeat
... i think that's covered
... we did MSE, EME
... i believe that item is done
... so, we did all the items on our agenda for today

.Topic: review passive exit criteria

paulc: had we been in yesterday's room
... with round tables
... i'd have split us around the tables

[ paulc describes chairing a group on web services in Hawaii ]

paulc: i'd be tempted to take the HTML ToC
... and put it into a spreadsheet
... i don't know if darobin_ would be interested in doing that
... the goal is to make the test suite as small as possible
... it might be that the WG says we have interoperability
... and we have tests
... maybe someone should test the tests
... to see if we have partial proof of interop
... perhaps the tests are broken
... the Implementation, the Spec, and the Test can be broken

darobin_: even several at once

paulc: rubys put up the document

[ html/wg/drafts/html/master ]

krisk: you can skip section 1

darobin_: it might be better to just scan through the actual document
... sometimes the titles are deceptively simple

paulc: where do we start?

chaals: common microsyntaxes

krisk: there's a bit on character encoding in terminology
... but it's covered later

paulc: oh, your machine is thinking

[ Connecting to dvcs.w3.org ]

<chaals> http://www.w3.org/TR/html5/infrastructure.html#common-microsyntaxes

<paulc> http://www.w3.org/TR/html5/infrastructure.html#common-microsyntaxes

paulc: if you don't get floating point, or NaNs right
... you're already screwed

MikeSmith: there are differences
... the list of White_Space characters is different from everywhere else

darobin_: i'm sure if we write tests for corner cases for that, we'll find bugs
... are those corner cases important enough to make blocking for REC

paulc: to me, the test is, does it disturb the user's experience?

MikeSmith: bad White_Space will disturb user experience
... what's the target?

chaals: "pretty much works"

krisk: would be good to identify areas that are sensitive

<paulc> http://lists.w3.org/Archives/Public/public-html/2012Sep/0215.html

MikeSmith: seems to be "something that exposed to web content as a feature"

jeff: darobin_ asked about corner cases
... if we didn't use the permissive criteria, we'd have come up w/ tests
... anything corner cases we wouldn't need to think about
... anything that would be exposed by existing tests, we'd need to think about

[ ?? ]

darobin_: if we wrote all tests for this, w/o extreme detail

jeff: the typical thing

darobin_: would we catch those corner cases?
... i'm not sure
... catching corner cases would be rather deliberate
... i don't think we'll get errors unless we sought out to get them
... there's a difference between Space Characters and White_Space characters
... i'd be surprised if someone didn't get it wrong

jeff: normal testing of specs doesn't catch corner cases
... look at a spec
... if it's sufficiently used in the marketplace
... the marketplace has done "good enough", and thus we can skip this section
... talking about this spec

MikeSmith: as long as we're talking about this one

chaals: MikeSmith, there's a tension between shipping and perfection
... here's a pretty reliable spec, while we do the next version
... while we do fixes in next+1
... if we did perfection, it'd be useless
... people want to build interop
... people do things that are normal
... it's valuable to ship something that's, recognized not perfect, but will be fixed

MikeSmith: you don't find the pain points w/o testing
... entire platform is not corner cases

chaals: <p> elements work

<Zakim> darobin_, you wanted to ask that we not revisit the discussion we had yesterday

darobin: i agree, we need a wonderful test suite for the platform
... we're working on it
... we do need to ship
... i'd like the Patent Policy to apply to HTML5
... it'd be nice for the Patent portfolio to apply
... we can keep working on improving the test suite
... we don't have to have finished the test suite in order to ship
... we iterate, we ship 5.1 in a few years
... instead of trying to get the perfect test suite

<Zakim> MikeSmith, you wanted to say, because interoperability and to say, the entre Web platform is corner cases

MikeSmith: nobody is saying the goal here is perfect
... the goal is to find bugs, and expose them before they get exposed to users
... i understand what we're doing here
... the rhetoric isn't necessary
... we've set a deadline
... it doesn't sound like

chaals: sounds like what i said i was saying

MikeSmith: this isn't the right message to send to consumers of this specification
... it isn't perfect, but this is good enough
... that's not acceptable

paulc: the model i'd propose here
... may partially deal w/ your concern, MikeSmith
... i'd like to go through and identify sections for which we think no further testing is required
... and publish that list
... and say "this is a call for objection"
... if someone thinks there's a problem w/ whitespace, then they can object w/ a test case

MikeSmith: i'm not talking about whitespace

paulc: i'm talking about an algorithm

darobin: this is a way to find ...

[ cross talk ]

rubys: we need a micro-exit criteria for getting passed individual sections
... i was part of the discussion of the previous discussion
... we need a spec better than HTML4 and XHTML1
... "is this section better than HTML4 and XHTML1" or "do we need more testing to determine that"

<Zakim> jeff, you wanted to support Mike

jeff: i wanted to partly agree and partly disagree w/ MikeSmith

<tantek> the "well it's better than HTML4 and XHTML1" is not a particularly high bar

jeff: paulc started by saying "the objective here is to minimize the number of tests we have to create"
... the objective is to increase interoperability in a reasonable amount of time
... i wasn't suggesting ignore/not ignoring corner cases (as we spoke about whitespace)

<MikeSmith> there are about 5 testable assertions in the entire HTML4 spec

jeff: but what's our confidence level that a particular section is testing in the field
... to the extent that we'd have tested it internally

MikeSmith: that's an odd criteria to use, not one we've ever used
... it doesn't seem sound at a high level

jeff: we need some criteria
... when we go to the director
... we've tested these this way, and these that way
... the director will say "how did you decide"

<tantek> MikeSmith - to be fair, there are far more than 5 testable assertions in HTML4, more like dozens or hundreds: http://www.w3.org/MarkUp/Test/HTML401/current/assertions/assertions_toc.html

jeff: the point rubys made is "we should have some criteria"

<chaals> ["shipping is a feature"]

glenn: mjs expressed this well
... give a priority to timing
... over testing

<bryan_> +1 to the need for clear criteria and documented evidence per it, both for permissive passing and otherwise

glenn: the industry and consumers want everything
... timing, quick testing, interop
... we have to make choices
... we agree timing takes priority
... someone who wants to prioritize testing more, they should take onus
... --- we may diverge into a discussion on metrics

paulc: jeff, the criteria says
... "in any case where judgement is debatable
... it will be a WG decision on interop"
... chairs could ask WG for a decision
... anyone could have a different reason
... i find it ironic that i'm at a WG meeting and having a discussion w/ 3 members of W3 Team
... darobin, backing up

darobin: 2.5 "common microsyntaxes"

<Zakim> tantek, you wanted to ask if there are any criteria for minimum number of tests per feature/section?

tantek: there's a nontrivial amount on date/time formats
... i don't think there's a lot of interop
... they're pretty freshly new

paulc: using rubys 's criteria
... your point is 2.5.5 "dates and times"
... is possibly new and could be a target of testing
... that's a good critera, tantek, thank you

darobin: is it surfaced to be testable?

krisk: they're reflected, but not transformed

tantek: you could test it from a validation perspective
... handy for content authors and search engines
... wanted to call out this section v. html4
... and new for standards

krisk: propose that when we talk about sections
... we break it into is it "UA" or "validator"

darobin: in the interest of going through relatively quickly
... if someone is not comfortable, we get a quick sentence and add it to the test list

paulc: if we keep features at-risk in cache
... <input type=date> <input type=time> <input type=datetime> that are in at-risk

darobin: they're also used in <time>

paulc: one candidate, thanks tantek

rubys: 2.5.6 "Colors"

paulc: i can't see them often

[ rubys drives through ]

paulc: what do we do when HTML5 has a Normative reference to another spec

tantek: punt on testing to that normative spec

darobin: yes

paulc: trying to follow jeff 's suggestion, as we find patterns

krisk: Media Queries is done in CSS

paulc: tell Director, he approved it once, he should again

rubys: 2.6 "URLs"

darobin: bloody nightmare

krisk: needs more testing

paulc: what about it?

darobin: there's no interop on urls whatsover

[ krisk's statement is laughed at ]

chaals: dynamic changes to base urls is unlikely to be what it says

darobin: anne has tests for urls

krisk: masinter has tests

MikeSmith: chris webber has a bunch

paulc: are these URLs bad formed?

<tantek> for a good time some of the challenges that URLs present, I give you: http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces

paulc: and it fetches

darobin: it might fetch a resource, but not the one you want
... if you mix Unicode w/ URLs you get worlds of pleasure

paulc: darobin, if you know what's in the test suite, it'd be nice to know what's there

darobin: going sync for that will take forever

[ "Fetching Resources" ]

<tantek> here is an tweet containing a URL that is non-interop in a number of ways: https://twitter.com/codepo8/status/327070476977446914

MikeSmith: that's a WIP
... it will be split out

Travis: that other spec is not a W3 spec

paulc: it's not germane to our CR

darobin: getting an open license would maybe make it easier to re-import

<tantek> example of a real world URL that has interop problems: http://tsa.gov/tsa-pre✓™

paulc: does this need testing?

<tantek> (yes, with the checkmark and trademark symbols included)

rubys: we've lost control of the meeting

MikeSmith: end users / people developing web content
... don't see it as a feature
... they can fetch resources, but sometime it does get what they want

darobin: don't focus on testing fetch here
... we want to test it broader

paulc: there are subsections here

darobin: there's a reason it's being moved outside

paulc: would have been funny to mark Fetch AT-RISK

MikeSmith: it isn't that kind of feature to be tested

paulc: objection?

[ silence ]

[ "Common DOM interfaces" ]

darobin: reflecting i think is ok

chaals: +1

darobin: Transferable is there, but not test there

MikeSmith: odd place for Transferables to live

paulc: are they elsewhere?

MikeSmith: they're w/ WebWorkers

darobin: let's not rewrite the spec as we go
... or else we won't make it to section 3

krisk: there are tests for it

darobin: i don't want to test 2.8.6 "DOM feature strings"
... 2.8.7 "Garbage collection", i don't know what we'd test

bryan: Ben put up a page w/ assertions outline count
... i'd like a clear rationale for why we're skipping

darobin: i'm capturing it

paulc: that's why i have dual scribes (timeless, darobin)
... to give us some advice if we were at cross purposes
... i'm hoping darobin will give post first-traversal advice

rubys: and i'm hoping it will be posted

[ "Namespaces" ]

chaals: there are interop issues
... but people won't cry here

paulc: summary?

darobin: some tests, a bunch of non tests

paulc: URL part?

darobin: "Dates and Times" and "URLs"

[ "Semantics, structure, and APIs of HTML documents" ]

darobin: Document object, probably want to test
... execCommand will not be something interoperable
... title and cookie work
... last modified we probably don't have interop
... some things are more problematic

paulc: so, selective tests?

darobin: there are a bunch of event handlers
... not sure about onwait/onstall

rubys: another pass?

darobin: offline

paulc: detailed review

darobin: probably have some tests

[ "Security" ]

darobin: we can skip

"This box is non-normative. Implementation requirements are given below this box."

JF: this is why you don't only use color to distinguish things

darobin: 3.1 "Documents" is a test target

[ "Elements" ]

chaals: contentEditable

darobin: draggable
... needs tests

[ "Global attributes" ]

darobin: "translate=" is when you have a name and you want to say don't translate
... you say no
... not sure what to test for translate

krisk: could someone building a translator could use translate=

tantek: does google translate support translate=no?

chaals: some don't
... but some professional tools

rubys: will be there two tools that do it interoperably
... needs publicly accessible

darobin: xmlbase
... do we need to test dir=?

travis: those might be edge cases

darobin: propose we not test class= and style=
... test data-*=
... that * means something than the other *

[ "Element Definitions" ]

darobin: not normative

[ "Content models" ]

[ "Requirements relating to bidrectional-algorithm formatting characters" ]

krisk: should be tested, there's tests

[ "WAI-ARIA" ]

darobin: who cares?

SteveF: there are MUST for those sections

paulc: is this a reference, or usage?

SteveF: it says UAs MUST implement roles and

paulc: is some of this implemented today?

SteveF: yes
... no official tests

JF: they're going through it now

paulc: is their mechanism correlated to their ...

SteveF: yeah
... i pointed tobie to michael cooper

paulc: i know you could create tests/harnesses
... for the semantics in this section
... do we believe a item is implemented

[ "Strong Native Semantics" ]

krisk: i don't think we have ARIA tests in github

darobin: do we need validator tests?

MikeSmith: i have support, but no tests

krisk: you have to use a screen reader

rubys: is it broadly implementable enough to say it works

MikeSmith: the whole thing

darobin: needs tests

[ "Interactions with Path and XSLT" ]

darobin: not a high priority
... not all browsers implement document.evaluate()

[ "Dynamic markup insertion" ]

darobin: document.open, document.write
... we have a fair bit of tests
... "needs tests"

[ "The elements of HTML" ]

[ "The root element" ]

rubys: those probably work

[ "The base element" ]

-- the base element needs tests --

[ "The meta element" ]

krisk: character encoding needs tests

( the group agrees )

[ "Scripting" ]

darobin: "oh, there's nothing wrong with that"
... we need tests

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/611c964f3a03867f994dbbc861e6d8eec4cc1001

<gitbot> 13html/06master 14611c964 15steve faulkner: tweaked switch script

darobin: defer, async

krisk: there are tests for those

darobin: what about <noscript>?

Josh_Soref: NoScript and similar are used by "noisy" users who would thus test it

[ "Sections" ]

[ "The body element" ]

darobin: probably basic tests for new elements

rubys: minimal tests?

darobin: <article>, <section>, <nav>, <aside>, <header>, <footer>
... test that it's not implementing "HTML unknown elements"

krisk: and you can style it

rubys: and you can put elements inside it?

[ "The address element" ]

darobin: <address> should be ok

bryan: do we need to test new attributes?

darobin: testing global elements tests this
... "Creating an outline"
... may be at risk

paulc: Outline algorithm is a feature AT-RISK
... how do you put something as a feature at risk if you can't test it?

darobin: you're going to implement it in the validator, right?

MikeSmith: it's in the validator
... the section describes how to build an outline
... but there's no exposure to dom/scripts
... there's no way from a web document to generate an outline

adrianba: but two people can independently build tests

MikeSmith: there's no defined conformance class required to implement

rubys: don't need tests

tantek: non-normative,
... it's non-normative
... which means we don't need to test it
... but it doesn't mean we should ignore it
... we should still list it at risk

MikeSmith: ok, i remember why we put it at risk, i put it there
... logic
... if we have no implementation expected to support this
... we could drop it from the spec, because it doesn't need to be there

[ cross talk definition on "normative" ]

paulc: feature at-risk
... no tests for it
... no consensus on what it means
... then WG will have to decide whether to keep it
... i think i restated, MikeSmith 's rationale

SteveF: every <heading> in a <section> is an implied section

[ "Usage summary" ]

darobin: non-normative

[ "Grouping content" ]

[ "The p element" ]

chaals: i assert that works, sufficiently well

darobin: all good to dd
... but want tests on <figure> and <figcaption>

[ "Text-level semantics" ]

darobin: The <a> element
... the <abbr> shouldn't that be acronym? :)
... <time> needs tests
... not sure about <samp> and <kbd>
... <mark>

<MikeSmith> when we get to <ins> and <del> I guess we get Daniel Glazman on the phone to ask his opinion

darobin: <ruby> needs tests
... <rt>, <rp> need tests
... <bdi> and <bdo> need tests

rubys: <wbr> is new in a spec
... needs tests

[ "Edits" ]

Josh_Soref: <del> needs tests

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/46d77af9414a1cfd779e7c57dbf201b0068e4f39

<gitbot> 13html/06master 1446d77af 15stevefaulkner: Update header-w3c-html-core...

[ break ]

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/d8c4e1bb994ef0205959094ad9d63fd71cf671a6

<gitbot> 13html/06master 14d8c4e1b 15stevefaulkner: Update middle-author-mode-links...

[ "Embedded content" ]

darobin: i think <img> is roughly ok
... i think <iframe> needs tests for new stuff

travis: seamless

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/5713d99aa94628fb9367f37fddc769b22640b75b

<gitbot> 13html/06master 145713d99 15stevefaulkner: Update header-w3c-html-core...

darobin: <embed> and <object> ... probably need tests

travis: interplay between those two

krisk: a lot of content needs those

rubys: you probably need tests for <param>
... <video> and <audio> are new

darobin: and we have tests

rubys: <source> and <track>
... needs tests

[ "Media elements" ]

rubys: needs tests

[ "Canvas elements" ]

paulc: isn't that mostly the Canvas spec?

darobin: <canvas> needs to test getImageData/getImageURL
... <map>, <area>, <imgmap> ok
... <mathml> do we need tests?

krisk: we have tests

darobin: <svg> we might need tests
... but possibly covered by parsing

[ "Dimension attributes" ]

darobin: think we're fine

[ "Tabular data" ]

darobin: don't know where we stand on this
... used to be interop nightmare

rubys: thought to be ok

travis: html4 was underspecified
... a lot of crazy stuff was dropped in 5

chaals: to a first approximation, tables work properly on the web
... if you nest them properly

rubys: i've seen people use deeply nested tables

darobin: so, ok

[ "Forms" ]

rubys: intro, ok
... categories?

darobin: i don't think there's anything normative there

rubys: <form>

darobin: novalidate= isn't universally supported
... <fieldset>
... anything new?

rubys: i don't think so

darobin: i think the form= attribute needs tests
... <legend>, hope it's ok
... <label>, don't think there's anything new
... <input>

paulc: is this with the at-risk?

rubys: <input> has email which is not at-risk

darobin: need to test new ones (url, email, address)
... have some tests

rubys: <button> ?

darobin: probably ok
... <select> as well
... <datalist> is a target
... <option>, <optlist> probably again
... what did we do about <keygen>?

adrianba: spec says parsing is necessary, implementation of crypto piece is optional
... we can test parsing
... separately, while
... it isn't implemented and won't be implemented in IE
... and was made optional
... writing tests would be an option
... seems to be good interop for browsers that do implement

darobin: agree
... <output>, <meter>, <progress> -- need tests
... "Association of controls and forms" -- already flagged for testing
... "Attributes common to form controls"
... _charset_ and isindex - i don't think high priority
... "isindex" is a value of a name
... it's very easy to shoot yourself in the foot by using it
... if you map from a datamodel where something has an index named "isindex"
... you'll be surprised by the output for the form

travis: minimal testing? no testing?

darobin: none, i think it's interop too
... it wouldn't be there if it weren't for browsers

rubys: APIs for the text field selections

darobin: flagged as a target
... constraints -- needs testing

rubys: form submission

darobin: we know there are corner cases
... the brunt of it works
... no way we're going to solve all the corner cases, w/ encoding
... it's known broken
... and we're not defining it
... we'll get around to defining it at a some point
... we have sufficient interop
... "Interactive elements"
... - <details> and <summary> need testing
... - <command> should die

paulc: how do you know it won't be implemented?

darobin: i spoke to people

adrianba: no, we said put it at risk

MikeSmith: it's also dropped from WHATWG

paulc: that's a useful datapoint
... yesterday, we asked about republishing
... we agreed, one possibility was if we had an increased number of things to take out
... like <hgroup>
... this (<command>, <menu>) is another one?

SteveF: there's a command= somewhere
... there's a <menuitem> ?

paulc: you take <command> out of 5.0

chaals: these are "problems for the editors"

rubys: <dialog>

MikeSmith: this is a new <dialog> not related to the other old <dialog>

darobin: needs tests

SteveF: it's at-risk, isn't it?

paulc: it's at-risk

darobin: ok, good

paulc: please include nomenclature to bring the at-risk features into this table
... publicly stating which items are at risk, for which we need tests, for which we know we don't have implementations
... is a strong statement

darobin: i'll take an action to evaluate the impact

<Zakim> tantek, you wanted to speak briefly about republishing CR

tantek: it would be good to see heartbeat updates of the CR
... regardless of scope of changes
... CR announces "you should be implementing this"
... having that updated w/ minor updates, adds, drops, would be quite handy

paulc: useful to be discussed
... getting heartbeats for 5.1 documents
... get that done, get a few other things done
... chairs will bring up subject
... we've enumerated changes already made
... we did not drill as to whether the room had the same sentiment as you

rubys: "Links" ?

darobin: most do nothing

rubys: type=stylesheet probably does something

darobin: no conformance requirement on prefetch
... we can't automate <link type=icon> so i don't like that
... it's a hint, all in ui
... no conformance requirement
... i wouldn't test that
... i'm pretty sure it works
... "Common idioms without dedicated elements"
... by definition, stuff you can't test

rubys: "Selectors"

darobin: matching html elements using selectors

krisk: isn't this covered by CSS WG?

[ no ]

darobin: probably need to test this
...: enabled, :disabled, :inrange... need tests

tantek: case sensitivity
... and id's in html5 are more liberal, so worth testing

rubys: "Loading webpages"
... "Browsing contexts"

darobin: is it testable?

krisk: some things that can't be automated

darobin: need tests
... Window object
... - needs tests

<krisk> krisk: ...but still need tests

rubys: Origin?

darobin: document.domain could use tests

rubys: Sandboxing

krisk: needs, but there are tests

rubys: session history navigation
... - needs tests

darobin: yes, but hard to write

rubys: Browsing the web?

darobin: "multiplart/x-mixed-replace" lovely
... the browsing the web is probably buggy and needs tests
... AppCache (offline web apps) -- needs tets
... painful to test

rubys: "Web application APIs"

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/e5c4537602fa3a9877ca2bad7d7a9f4a4615d647

<gitbot> 13html/06master 14e5c4537 15stevefaulkner: Update middle-w3c-styles...

travis: a lot of this just works

darobin: things that don't work aren't necessarily testable

travis: Base64 utility methods are new

darobin: new in standard

rubys: Timers - probably work
... user prompts - probably work
... Navigator object -

hober: i'll write navigator.product
... tests

[ it always returns "Gecko" ]

darobin: we need tests for custom scheme and content handlers

chaals: dialogs implemented using separate documents - needs tests

darobin: we need to test manually releasing the storage mutex
... the external interface, that's lovely

Josh_Soref: probably works well enough, oddly enough

darobin: "User Interaction"
... "hidden attribute" is new, needs testing

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/e9f83561ade9ed89ef7e13cd36658fdf86ffcc25

<gitbot> 13html/06master 14e9f8356 15stevefaulkner: Update header-w3c-html-core...

darobin: Inert subtrees is only for <dialog> and <command>
... and if implementers haven't seen it, i wouldn't be shocked

SteveF: about selectors

darobin: we define some psuedo-selectors

SteveF: where do you use them?

darobin: it's complicated, we define them
... i agree logically, it could be elsewhere
... we're sticking to document units
... it makes our lives easier

SteveF: how many tests rely on tests using optional features

darobin: 99% of our tests rely on JS
... so w/o the optional JS
... you won't pass

travis: HTML4 suite hardly uses JS

darobin: Activation, we've all used .click
... focus, tabIndex
... -- either it's been broken forever
... i think we should test it
... it'd be nice if it finally worked

tantek: or even if the tests were used to fix the tests

chaals: accesskey needs tests

<tantek> to fix the spec

rubys: Editing/ContentEditable

darobin: Editing is another document
... it needs only a few tests initially
... we'll probably bring editing APIs in for 5.1

rubys: drag and drop needs tests?

darobin: yes.

rubys: HTML Syntax?

darobin: needs tests, have tests

rubys: XHTML syntax

darobin: sad thing is, it probably needs tests

mjs: parsing xhtml documents probably works interoperably
... serializing xhtml fragments/parsing xhtml fragments
... probably need tests

rubys: "Rendering"

darobin: does it have hard requirements?

mjs: it's unusual
... everything is a suggestion, not a requirement
... but there's a conformance class
... that requires implement everything in the section
... depending on the conformance class we pick as a target
... for a desktop browser, we could probably make it
... but for mobile browsers, probably not
... <details> / <meter> / <progress> - probably needs tests

darobin: elements that need tests, also need to test rendering

rubys: "bindings", if the element needs testing, the rendering needs testing
... frames and framesets, probably works?
... interactive media

darobin: probably works

rubys: print media

darobin: probably works

rubys: "unstyled xml" -- we won't hold up html5 for it
... "Obsolete features"

darobin: do we need to test obsolete features?

krisk: there are interop problems for the webidl bindings

rubys: say it isn't a priority

darobin: we don't need to test "IANA"
... we could test their registration system

tantek: we probably already have

rubys: Index
... References
... Acknowledgements

paulc: took 3 hours, minus coffee

darobin: it's not that big a spec

[ laughter ]

<tantek> nicely done team

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/505b4c046645c092ecae56da4d772ebb4ad2ab9a

<gitbot> 13html/06master 14505b4c0 15stevefaulkner: Update header-w3c-html-core...

paulc: in CR discussions
... we said we had two long poles
... testing
... getting implementations
... we have a lot of microdata here
... where we can indicate what's at risk
... but it'd be nice to say which items need implementations
... for things where we have implementations
... you'd think you'd want to write tests
... before writing tests where there are no implementations
... wonder if that's a criteria for considering the order of generating tests

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/7005b905b033debccf9eb8ed821cb11cc94045fc

<gitbot> 13html/06master 147005b90 15stevefaulkner: Update middle-w3c-styles...

darobin: in a lot of cases, we do have tests

paulc: chaals, a number of items were A11Y related
... should we ask the A11Y TF to look at darobin 's work
... to double check his items

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/18d188d7795ad256f054d13961e25fb1e56b95be

<gitbot> 13html/06master 1418d188d 15stevefaulkner: Update header-w3c-html-core...

paulc: a number of A11Y people are trying to get ARIA out of CR today
... to have them look at the list and see if we missed anything
... darobin, estimate for a cleaned up document

darobin: try to have it by monday
... i'm vacationing next week

paulc: figure out how to get WG (not all here)
... to give feedback
... on whether we can get consensus

rubys: we post it, and give people weeks, if not a month

paulc: darobin, when you post it
... you might encourage people
... if they want to push back
... for them to rename the thread
... otherwise you'll have an uberthread

darobin: this is testing, no one will respond

AOB

paulc: i tried to confirm we'd cleared the items of the agenda
... is there AOB?
... i think, we're adjourned
... we should thank Josh_Soref, the scribe

[ Applause ]

<krisk> darobin - bin has started a table here http://www.w3.org/wiki/Testing/Test_Management_TF/HTML5_Test_Coverage_Analysis

<krisk> ...that in theory could be used

paulc: thanks everyone
... i believe we're adjourned

jeff: Let's thank Daniel / PayPal for hosting

[ Applause ]

[ Adjourned ]

- DRAFT -

HTML Interim Face to Face

24 Apr 2013

Attendees

Contents