See also: IRC log
Alexey: I call you about the
organization chart
... I want to project the IANA slide that I think was skipped
yesterday
(setting up projector)
(IETF and IANA is projected)
Alexey: IANA manages registries,
and there are multiple entities that affect what IANA
does
... If IETF adopts a procedure or defines a policy, IANA is
required to follow it
... IANA does give input on what the policy should be
... IANA follows what IETF says in RFCs
... the other entity that affects IANA is the IAB (Internet
Architecture Board) - talks to IANA about policy decisions like
licensing
... IESG approves RFCs and so defines the formats, IAB controls
the policy experts
... If people are unhappy with IANA policies they should not
blame IANA - except in the case where IANA is slow in updating
something
AVK: can blame them about format, URL persistence
Alexey: there is a document,
RFC5226 which defines standard procedures for registries
... IETF can make any format that it wants, but there is a
typical format for registries
... registries can have different policies, templates, levels
of restrictiveness
... most permissive level is first come first serve
... examples include vendor names
... on the other end of the spectrum, the strictest ones
require a standards track RFC
... in the middle is a procedure called "specification
required"
... requires a stable specification from an IETF-recognized
standards organization
HS: Is there an official definition of what is a recognized standards organization? there are different opinions
Alexey: no, it's not defined;
people don't want to fix the list
... general criteria are: long established, stable document
HS: why is stability a requirement? if the software moves faster than the registry, then the registry is out of date
Alexey: depends on the registry -
many registries are for developers
... for example, as a developer you may want to find all the
link relations
AVK: but as a developer, I find
current IANA registries useless
... wikipedia is a better reference for URI schemes than IANA
is
... vetting by experts makes registries incomplete and
inaccurate
HS: you said not just software
implementors or others
... for years, image/svg+xml wasn't in the registry
... when Apple shipped MPEG-4, the type wasn't in the
registry
... I can't think of any constituency for whom the registry
says all that they want to know, or even close
AVK: apart from pedants, maybe
Alexey: a couple of comments on
this
... different registries have different policies
... at the time when the registry was established, there was
IETF consensus that this was the desired policy
... as time goes on, it may be that reality shows that a
particular policy was too strict (or too permissive)
... maybe part of the answer is to revise the policy
HS: in the days of classic MacOS
when Carbon was still used a lot, and you needed four char type
and creator codes, it seemd that the value for those codes was
smaller than the space for MIME types
... so you'd think you'd have a greater need than for MIME
types to limit who can get what, but Apple operated a registry
on first-come first-serve basis and nothing bad came out
<anne> MJS: you mentioned that it is possible to change the policy
<anne> ... assuming that some of the folks here are interested in a much more permissive policy
<anne> ... what would be the process to get the IETF to change
<anne> Alexey: talk to the AD and talk to other people to initiate discussion
<anne> Alexey: I'm happy to help with the progress
Alexey: the other half of the
answer
... there is a reason there are expert reviews for some of the
registries, like MIME types
... people do make stupid mistakes in MIME types, so there is
an opportunities to fix this
HS: one of the supposed mistakes is using the text/* subtree for a lot of stuff, and there I would claim the mistake on the IETF side
AVK: what proportion of MIME types are not in use when they are registered? it seems like most of them already are deployed by the time you go to register them, so it might be too late to fix
Alexey: in the ideal world, people should ask experts up front
<Julian> !
Alexey: one example is that you can't use UTF-16 of textual types
HS: that's bogus
AVK: still insisting the case now is misguided
JR: one thing that Anne mentioned
- some registries have a provisional system
... but not MIME types
Alexey: vendor prefix ones are first-come first-server
JR: other question -regarding the
media type registration RFC, Larry has started discussing
revising it in the TAG
... for example, people sniff for types - we could make that
more robust
HS: I want to complain more about
CR/LF
... the history of CR/LF restriction and the fact that text/*
defaults to US-ASCII in the absence of charsets...
... this is an artifact of a leaky abstraction from SMTP
... US-ASCII default is a theoretical most prudent default from
the time when in email there wasn't an obvious default
... but neither of those considerations apply to HTTP
... HTTP can send text that has line breaks that are not
CR/LF
... in fact for HTML, LF-only is preferred
... it makes no sense to say that all these types like HTML,
JavaScript and CSS are "wrong"
... instead it would make more sense to say that CR/LF does not
apply to HTTP
... for some types, for historical reasons we need to default
to Windows -1252 or UTF-8
... pretending these need to be registered under the
application/* subtree doesn't help anyone
... it only serves the RFC canon that HTTP and SMTP match, but
that doesn't help authors or implementors
... line breaks should be based on transport protocol
... types themselves should be able to define their default
charset
JR: if you look at the thing that
Larry brought to the TAG about MIME on the Web...
... he mentions all these problems
... line break thing doesn't make sense on the Web
... HTTP appears to use MIME, but doesn't, and doesn't need
to
... charset is also an issue for HTTP
... conflict between MIME, HTTP and XML types on text/*
HS: I actually implement
RFC2023
... I have a checkbox for saying ignore it
<anne> (There's a t-shirt saying "I support RFC 3023")
HS: if I shipped the validator without the "ignore it" box, people couldn't use the validator
JR: what's the default?
HS: defaults to supporting it
Alexey: comment on Web vs email -
this needs to be discussed in IETF
... if Web requires modified version of MIME, let's do it
... there is a new WG in applications area
<anne> APPSAWG
<weinig> http://datatracker.ietf.org/wg/appsawg/charter/
HS: it feels frustrating to
actually have to discuss this
... that people don't believe what they see on the web
AVK: the feeling is that the IETF
is so much behind, and then we have to get in and tell the old
timers what the new world looks like
... we're not sure it is worth our time
... we have moved on
Alexey: it is occasionally
helpful to talk to people who designed the original
... especially when it comes to character set - I think there
is agreement from the original author
AVK: I talked about some of the
discussion about moving away from text/plain drafts, and people
there express fear of Unicode....
... W3C is kind of slow too, but at least we think HTML and
Unicode are ok
HS: well, W3C isn't ready to publish HTML5 as HTML5 yet
JR: IETF thinks HTML and Unicode are fine, just not for their documents
Alexey: there is provisional registration
AVK: for header fields, you need
spec even for provisional
... person guarding the header field registry was too
conservative
JR: does header name registry
have a public mailing list
... registry lists should be public
Alexey: can you draw cases like this to my attention? it might be implementation of process failures
AVK: but if we look at URI schemes..
Alexey: it's hard for me to
defend the people who designed the procedure
... there was a discussion about relaxing registration of
certain types of URIs
... so we could register things like skype or yahoo IM
AVK: we are trying to register
about: - there should be some registration pointing to the
draft
... and for many headers, browsers have to know about them even
if they are unregistered
... difficulty of using registry causes incentive to use X-
names and just not registry
JR: one thing we should look at
is accountability - there needs to be a public mailing list for
header registration
... also Larry will join us to talk about IRI
AVK: I would rather just get rid of IANA and have a W3C registry, with a community-managed wiki
HS: to consider how the XHTML2 WG
was doing things - at some point it was obvious that just
giving feedback wasn't going to change the way they did
things
... so instead of trying to change the way they did things,
another group did something else, and that became the group
people paid more attention to
... there is a feeling that fixing IANA is so difficult that it
would just be easier to set up a wiki
AVK: we could just compete
Alexey: this is not helpful
AVK: I would like a registry that
would tell me X-Frame-Options exists
... I don't think this will ever fly at IANA
HS: I have no experience of registration, but the language tag registry is a very positive role model
Alexey: when I talk to IANA, they listen
AVK: I think the problem is the process
Alexey: I can help you initiate changing the process
AVK: not sure I am interested in helping to fix the process if there is an easier path
HS: we should mention willful
violations of the charset registry
... it would be useful for the main charset registry to be the
place to go to find out what you need to implement
... the thing is that ISO-Latin1 should actually be interpreted
as Windows-1252
... another example is that instead of Shift-JS you need to use
the Microsoft tables not the ISO tables
LM: I note that my draft covers many of these issues
HS: not in this much detail; I will give feedback
<Julian> http://tools.ietf.org/html/draft-masinter-mime-web-info-01
LM: I hope in the cases where there are willful violations, that the right thing to do is to fix the registry
AVK: in the case of the charset registry, there might be a need for separate registries for Web clients vs other clients
HS: for example the Java platform
uses the IANA names for charsets with their real meaning
... it would not be good to change Java, so the registry should
include both sets of info
... JAva could add an API for Web content decoders
LM: I think this is a three-phase
process
... (1) identify the problem
... (2) identify which things need to change (w/o being
explicit about how)
... (3) then there needs to be action on the change
... I would like to identify the problem and the kinds of
changes first
... only then decide whether to make a wiki, change the
process, etc
AVK: if you are already working on this, then that's great
LM: I would be happy to have co-authors
Alexey: at minimum we should talk
LM: I think we should bring it
into a working group or take it up as an action item
... MIME is a part of the Web architecture that we have adopted
without adopting it
JR: we talked earlier about text/html and encoding
LM: again I think we should
describe the problem first
... same thing might be said for URI schemes
HS: given last call schedule
(1H2010), how realistic is it that changes of these magnitude
could go through the IETF
... seems unlikely
LM: my view is that a W3C
document entering LC can make reference to documents at similar
or behind level of maturity
... they don't need to be final until you go to REC
MS: (explains W3C process)
HS: one reason I'm skeptical
about the rate of change at IETF is the URL thing
... we had rules in the HTML5 spec abut transforming href
values to IRIs
... it was argued that IRIbis was supposed to solve it
... I remember there was a schedule
LM: it's quite off
HS: at the date when there was
supposed to be a deliverable, they haven't even started
... we shouldn't send things to the IETF to die
... I was really annoyed when I wanted to fix a bug relating to
URL handling in Firefox and the spec did not have what was
needed
... I think that for URLs the process has had it chance and
din't deliver
RI: the original schedule was very aggressive and we never really expected meeting it
LM: it was wildly
optimistic
... the problem with most standards activities is that there's
nobody home except for people who showed up
... if you look at the archives, there was really a fallow
period, but since then it is picking up
... meeting next week in beijing
... people who care about URLs in HTML should show up
online
HS: there is also the problem that if people are already showing up in some venue, then moving the work to a different venue and then complaining that people didn't show up in the other venue is not productive
LM: the problem really is that
what was in the HTML document before was wrong
... unfortunately there is complexity due to need to coordinate
with IDNA and bidirectional IRIs
HS: you need something that takes
a base IRI, a relative reference as UTF-16, and a charset, and
you get a URI/IRI back
... my point is that the HTML spec doesn't need to deal with
rendering any kind of address
... it just cares about resolution / parsing
... nothing about how to render an IRI
... what is required is someone writing down the real-world
algorithm for this resolution thing
... and it needs to be somewhere that you can reference it
RI: if it were in the IRI specification would it be ok for you
HS: what I am annoyed about is
that we had something that was right or fixable, was removed or
delegated, and now we have to rewrite it
... I am now betting on Adam delivering it
JR: I would like to say one
thing
... we need to find the right separation between things that
are just part of the attribute and things that are part of the
the resolving algorithm
... I think whitespace discarding is not part of the
resolutions
... there might be a step before resolving that is part of
extracting from an attribute
AVK: in the running code, whitespace stripping happens at the resolving end
LM: it would be nice if you could copy from the location bar into other apps
HS: we are not talking about the location bar
JR: what about space-separated lists of URLs
AVK: this is a different case
LM: motivation for trying to
start the work in the IETF was to make sure that URLs in HTML
and in other apps weren't different
... it is true that the work has been delayed, but activity has
been restarted
Alexey: you need to open bugs
LM: Adam was at the last
meeting
... there is an IETF document of how to do IETF document
HS: it's great the kinds of URLs
that the web uses were the same as what other things use it,
that would be great
... but the Web is constrained
JR: this was very useful, which I'm not sure was expected; we have another point about link relations, which is on the agenda
ack
MS: in the future, we shouldn't delete things until the replacement is ready
LM: chairs from IRI working group are prepared to add an additional charter item
AVK: Adam is a bit reluctant to go back to the IETF
<anne> (that was my impression)
RI: it seems like there are discussions coming up in beijing where we need to be talking between the HTML WG and IETF
LM: editors will be remote, so
remote participation might be good
... how about file: URLs
HS: they are not really on the
Web
... best thing to do for USB key is relative URLs
<r12a> whether it's beijing or not, i think we need to find a way to pursue this dialog with HTML5 folks and chairs/editors of the IRI spec
RI: is something gonna
happen
... action items?
LM: don't be skeptical - if you believe it will work
<scribe> ACTION: Henri to give feedback to Larry on MIME etc draft [recorded in http://www.w3.org/2010/11/04-html-wg2-minutes.html#action01]
<scribe> ACTION: Anne to give Alexey info about registry problems [recorded in http://www.w3.org/2010/11/04-html-wg2-minutes.html#action02]
<MikeSmith> started lunch break?
MikeSmith, we're about it
<MikeSmith> k
er, about to
session adjuourned
<anne> fwiw, testing was half an hour delayed
<anne> not sure if anyone is actually in the other room yet
<anne> but since you just signed in...
<Julian> isn't testing at 5pm (50 mins from now?)
<anne> no
<anne> it's a double block
<Julian> oh
<anne> yes
<anne> we are setting up
<anne> dbaron, ^^
<hsivonen> dbaron, we are in Rhone 3b
<hendry> scribenick hendry
<oedipus> scribenick: hendry
me: to find the connection type, it's not slow or rather blocking is it?
it's a fast operation Andrei: yes, we fire online when the type changes
type just caches last seen connection type
[ scribe apologies for pasting in wrong buffer ]
maciej: how to particpate in tasks tf, testing framework
<plh> kk: and goals for LC
kk: the TF meet every two
weeks
... there is a wiki with schedule, there is a server with
hg
... philippe has mirrored that work at http://dvcs.w3.org
<plh> --> http://dvcs.w3.org/hg/html/ HTML test suite repository
kk: same content on both servers
<plh> --> http://test.w3.org/html/ HTML Testing Area
kk: asking what to test ...
localstorage, x-domain messaging, doing spec analysis
... looking at features which are shipping
... submitted some canvas tests
<plh> --> http://test.w3.org/html/tests/submission/PhilipTaylor/ Canvas test suite
kk: getElementsByClassname tests
from Opera
... distinction between approved and un-approved tests
<plh> --> s/Philipp Taylor/Philip Taylor/
kk: bugzilla to process the test
<plh> --> http://test.w3.org/html/tests/harness/harness.htm Test harness
jonias: what is the harness ?
anne: same as XHR
kk: tests run automatically
... video tests is hard to automate
... self-describing test
... some exceptions that you can't poke in the OM and you can't
test it
hsivonen: can you do some REFerence tests ?
jonas: yes, there are some things
kk: there are some things you can't test with REF tests, for e.g. Audio
hsivonen: multi-testing question
plh: some tests are manual and some tests are automatic
kk: existing tests not using the testharness, it might not be worth re-writing them
plh: it's a bug, it shows the buttons, though its automatic
kk: waits for 5 seconds before going to next test
maciej: this UI is broken
kk: can we get all the
requirements up front ?
... esp we need a plan with REF tests
maciej: propsed categories;
script driven, ref test, manual test
... too awkward with 100k tests ... takes too long to run
plh: the test can indicate itself, if it's manual or automatic
anne: if the test loads the test harness, we know it's an automatic test ( no need to categorise )
hsivonen: just have 3 directories
dbaron: you can harness the harness
kk: we should do it in one file
hsivonen: the easier way is to use directories
jonas: i don't care
maciej: text file is harder to maintain than a directory, not big deal either way
<plh> scripts/
<plh> reftests/
anne: we want directories for *types* of tests
<plh> manuals/
dbaron: painful to use dirs as metadata, as you may need to move them around
kk: maybe we will come up with a new dir in some months time, prefers a text file as it wont change location
jonas: bigger problem to have a function call when the test finishes so we don't have to wait 5 seconds after each one loads
anne: there is logic in the harness to handle this & async tests
hsivonen: [ didn't quite understand your implicit mochi test comment ]
<dbaron> plh: need a way to copy all the additional files that tests depend on
<hsivonen> I find that I almost always have to use the explicit finish function for scripted tests, so it's not a win to finish tests implicitly on onload
jonas: we need to somehow markup dependencies
sweinig: in the common case there will be no deps
hsivonen: should we decide whether to allow data URLs ?
anne: common resources makes sense
hsivonen: you want to use data URLs for near 0 load times
[ why does jonas use data URLs? didn't get his argument ]
kk: ie9 supports dataURIs
... might be a problem that browsers do not support
dataURIs
jonas: we need to list our deps
and assumptions
... can we assume browsers have ES5, foreach is nice
maceij: we should not use ES5 until it's widely implemented
jonas: queryselector test cases were held up by WebIDL
kk: e.g. of WebIDL false positive in canvas read only thing
jonas: do we have any existing docs of assumptions?
kk: there is just the source
code
... can someone take an action to document them?
anne: read the XHR tests :-)
<krisk> testing wiki http://www.w3.org/html/wg/wiki/Testing
jonas: these tests are already in directories
kk: suggests documenting the tests in the wiki
hsivonen: ... something about re-writing the "mochi tests" ??
anne: i'm fine with re-writing / using another harness
kk: first anchor test is very simple, it's not hard to migrate to james's harness
jonas: make some requirements for making the tests portable between harnesses [ IIUC ]
hsivonen: something about integration layer, which allows reporting into your own system (thanks anne)
<plh> --> http://dvcs.w3.org/hg/html/ mercurial
plh: you can commit a test if you have a W3C account
dbaron: might need to be aware with hg's push caveats [ to plh ]
<plh> ACTION: plh to work with systeam to make sure we keep track of hg push [recorded in http://www.w3.org/2010/11/04-html-wg2-minutes.html#action03]
maciej: not great security, since hg trusts the client's config WRT who wrote the patch
dbaron: you might want logs
... Mozilla have a tool called push-log for this problem
jonas: i can see now the tests are seperated by directory
<dbaron> The source for pushlog is in this hg repository: http://hg.mozilla.org/hgcustom/pushlog/
jonas: is there a description file ?
<anne> http://test.w3.org/html/tests/
<anne> http://test.w3.org/html/tests/harness/approvedtests.txt
kk: see http://test.w3.org/html/tests/harness/approvedtests.txt
... we will add extra info
jonas: remove domain so it's not
server specific
... we have a test file per dir
... i want to walk this from the cmdline
... i want relative paths
kk: we might need some absolute stuff
jonas: i'm pulling via hg
kk: there is no absolute need for absolute urls
hsivonen: mochi-tests point to localhost
jonas: something clearly
identifiable for a search & replace to get the tests
working
... you can get different types of relative paths
... it's important that we can accomodate them in a "search
& replace"
... we need to scale
... it's not workable to ban absolute paths
hsivonen: we need to document the "clearly identifiable" bit, like test.w3.org and test2.w3.org
jonas: we have to say it's OK to use abs paths
hsivonen: worried about some dir
namespace collision
... get rid of prefixes
jonas: OK
<krisk> That is fine
kk: how to delimit the file ?
jonas: i don't care
... though, since it's hand-written, make it easy & little
to type
sam: is there a preferred
lengthmicroformats.org with CSS tests there was a wide
range
... bad = long test & lots of permutations
hsivonen: we know a bad test when we see it
maceij: there is a fuzzy boundary
jonas: io bound if we have a million tests ... we need to keep it somewhat reasonable
sam: there are examples of tests that can be merged
adrian: there is a review process
kk: you could file a bug, raise issues
adrian: of course if it's approved, it doesn't mean it can't change again
sam: if all the tests pass, then the bugs are in the specs
kk: tests do content negotiation (canPlayTypepermanence) WRT choosing a codec the runtime supportS
hsivonen: mochi tests that we (mozilla) use, requires server side javascript
plh: was a lot of trouble already to support PHP for security reasons
sam: we have tests that use python, php, curl for certain load tests
<dom> (we evoked this in WebApps the other day; we can probably consider more server-side stuff at some point, but we need to need to have requirements documented earlier rather than ater)
<dom> (and please consider limiting the number of needed languages/platforms as much as possible)
jonas: we can generalise "slow
load tests" so it doesn't neccessarily require PHP
... some security concerns here
plh: we need to review PHP files before they become live
jonas: we need it one the same server for same origin type cases
<dom> if same server == test.w3.org, that's part of the plan
hsivonen: we need a mechanism to load things slowly for example
<dom> (use a DTD for that)
hsivonen: avoid echo, we should return existing (approved) files
jonas: is there sensitive data WRT XSS-ing
plh: should be fine
<anne> safest might be w3test.org or some such
kk: what happens if 10 million tests are in the Q to be approved
dbaron: biggest risk is a test that claims to test something, but doesn't actually test it
sam: we should only accept tests
that use the new harness
... the tests here are about testing regressions
kk: worried about approval rate, esp. if only he does it
plh: if a subset of tests are passed by everyone, they are probably good
anne: 1) is it good enough hsivonen 2) ... [ didn't get that ]
maceij: lets do a cost benefit analysis
<adam> Accidentally testing something that is not a requirement at all
maceij: 1st category testing
undefined behaviour
... 2nd -- testing something contrary to a requirement
... -- at least one browser will fail this
[ can someone write what maceij said pls ? ]
scribe: 3rd cat testing something
where it doesn't actually test it
... review should catch them all
... almost certain something will be wrong
... how much time should be spent on review versus
benefit
... test approved == matches what the spec says
dbaron: from exp within CSS, review is more work than writing to test... so its not worth doing for an existing contributor
s/writing to test/writing the test/
dbaron: figure out why the test
is failing sooner than later
... imp report: 1) run all tests 2) bug in test suite or in
browser (v. time consuming)
... figure out WHY tests are failing
hsivonen: we should flag tests
that fail in all browsers
... we can't assume the spec is neccessarily 100% correct
<hsivonen> we should flag tests that fail in 3 engines
maceij: low skilled tests don't need to be approved, better if everyone is just running them [ IIUC ]
anne: we should distribute the testing
maceij: don't have ref test when
you could have a script test
... distributed test is more likely to succeed
hsivonen: do we have any way to feed the test info to the WHATWG HTML5 section info box things
kk: could be an admin problem if links change
<krisk> see http://test.w3.org/html/tests/approved/getElementsByClassName/001.htm for an example of a script based test
<freedom> nobody in 3B yet? there will be an EPUB related meeting right?
<oedipus> according to the agenda, EPUB discussion in 3B starting 8:30 french time http://www.w3.org/html/wg/wiki/TPAC_2010_Agenda#Room_3B__.28IRC_.23html-wg2.29
<mgylling> Reads 09:00 to me
<mgylling> To anybody who is physically there: does 3B have call-in facilities?
<oedipus> guess the first half hour will be spent in common again then breakout to 3B
<freedom> seems not
<freedom> I am in 3B physically now
<mgylling> freedom, thanks.
<MichaelC> scribe: Julian
ms: markus to give overview
mgylling: (remotely)
<mgylling> www.idpf.org
mgylling: epub standard for
ebooks, around for several years, expanding in popularity,
large adoption
... idpf.org
... based on xhtml, subsets defined
... current ebpub 2.0
... uses XHTML1.1 mod
... is a fileset, ZIP container, different document types
... container called OCF
<freedom> http://www.idpf.org/specs.htm
mgylling: some of the formats in
epub defined by w3c
... some of the metadata formats owned by epub itself
... is undergoing rev to 3.0
...charter: update & alignment with modern web standard
s
use HTML5 as grammar
is not allowed by current specs but already happening
need to formalize & stabilize
on HTML5 vs XHTML5: epub decided to use X*
based on requirement for existing reading systems to be upgradeable
MS: asks about design
philosophies
... drive spec based on what current UAs already can do?
mg: docs used to be static
... <script> SHOULD/MUST be ignored
... but scripting is going to be added
... problems with legacy readers
... and non-browser-based impls
... it's clear that this will be needed in the future
MS: devices coming to market with have full browser engines
Julian: usability of spec for being referenced
?
mg: not a problem yet
... we're not forking
... defining profiles and extensions, follow the HTML5
style
Julian: how does ext work for you?
mg: XHTML5 is supposed to allowed namespace-based extensibility
ms: feedback on this is
welcome
... epub I18N requirements -> CSS WG -> vertical text
support
... does not seem to affect HTML though
... is there something the HTML WG need to do?
mg: books / ebooks slightly
different domain
... missing semantics for books
... distinguish node references and nodes
... skippability
page breaks
have looked at role attributes for extensibility
mjs: extending role not
recommended because owned by aria
... needs coordination with PFWG
... maybe dedicated elements
or attributes
what affects rendering should be in HTML
mg: book semantics, chicago manual of style
in transcript, replace "node" by "note"
MC: asks about roles
MG: uses custom attributes
<MichaelC> Role attribute extensibility: http://www.w3.org/TR/role-attribute/#extending-the-collection-of-roles
MG: fastest way for now (own NS)
MC: role module *does* allow extensibility
<MikeSmith> RRSAgent:, make minutes
MC: PF and HTML need to coordinate on r@ole
@role
<Zakim> MichaelC, you wanted to discuss role extensions, future aria, etc.
MG: ownership of @role
mjs: HTML defines @role by refererence to ARIA spec
MC: aria defines on HTML to define @role
<MichaelC> s/aria defines/aria depends/
mg: request to clarify the HTML spec wrt role extensibility
<fantasai> RRSAgent: make minutes
mg: on metadata in epub
... NCX doesn't have metadata at all anymore
<MichaelC> ARIA on host language role attribute
mg: core metadata will continue to come from outside HTML/head
<mjs> -> role attribute in HTML5: http://dev.w3.org/html5/spec/Overview.html#annotations-for-assistive-technology-products-aria
mg: reading systems need to get the metadata from the package file
HS: on role attribute
<fantasai> hsivonen: ARIA spec defines aria- attributes, but does not define role attributes
<fantasai> hsivonen: requires that a host language define a role attribute with certain characteristics
<fantasai> hsivonen: HTML5 tries to do this
<fantasai> hsivonen says something about tricky wordsmithing
<fantasai> hsivonen: Way forward would be to figure out roles that current AT vendors need (?) and define tokens for them, and have ARIA promise not to conflict
<fantasai> hsivonen: The role module spec relies on CURIEs for extensibility
<fantasai> hsivonen: ... not good for EPUB
<fantasai> hsivonen: I don't expect web engines to support CURIEs, relies on namespace stuff ... lookup DOM L3
<fantasai> hsivonen: Best way forward is to ask PF to set aside the names that you expect to use
<fantasai> hsivonen: Doesn't make sense to pretend different groups dont' know about each other
<fantasai> hsivonen: We're communicating, so let's coordinate.
<MichaelC> ARIA taxonomy
<fantasai> ?: I'm ok with approach Henri is suggesting, but coordination with PF is important sooner rather than later
<fantasai> MichaelC: Everything would have to fit into our taxonomy
<fantasai> hsivonen: Implementations don't care about the taxonomy, that's only to help out with spec design
<fantasai> hsivonen: If PF promises that this set of names is not going to be used, and picks different names if it decides to expand in that area, then we don't have to worry about all this extensibility stuff
<mjs> ack q+
<fantasai> MichaelC: For author understanding, we want to pick tokens that match the most appropriate terminology
<Zakim> MichaelC, you wanted to say if you want to follow the approach Henri suggests, should coordinate with PFWG sooner than later and to say ARIA roles are part of a taxonomy
<fantasai> hsivonen: They're just tokens, it doesn't really matter
<fantasai> mjs: Instead of debating in the abstract, let's just send the list of suggested roles to PF asap
<hsivonen> DOM 3 namespace lookup doesn't work for CURIEs in text/html DOMs, so don't expect browsers to implement CURIEs
<fantasai> mjs: If they don't like the tokens proposed, then they can respond about that.
<fantasai> mjs: I don't think this meta-conversation is getting us anywhere
<Zakim> Julian, you wanted to let Mike speak
<fantasai> hsivonen: I'd like to add a note about why CURIEs are bad idea in this space
<fantasai> hsivonen: So, frex, how Gecko exposes roles to interface to JAWS, Gecko picks the first role it recognizes and exposes that as the MSAA role
<hsivonen> IAccessible2
<fantasai> hsivonen: And then exposes the entire value of the role attribute as the xml-roles property in the iAccessible2 interface
<fantasai> hsivonen: It follows that the namespace mapping context of the CURIE binding context is not exposed at all
<MichaelC> scribe: fantasai
hsivonen: If you wanted to do
something with CURIE, you wouldn't do CURIE processing.
... You would wind up exposing to JAWS the prefix and local
name
<freedom> IAccessible2, http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2
hsivonen: Therefore I advise against relying on the mapping context, because the existing ... doesn't expose the mapping to IAccessible2 and therefore to JAWS
markus: Does Gecko expose the roles regardless of whether it recognizes it?
hsivonen: Yes. All the data is
passed through, in case JAWS wants to violate ARIA and look at
things itself.
... Gecko doesn't police whether JAWS follows ARIA spec
MikeSmith: I just wanted to state
where things stand.
... It's not inconceivalbe that the language features you need
for EPUB could be considered as native elements and attriutes
to be added to HTML5 itself. It's not too late for that.
... It's not too late to ask, anyway.
... I'm sure we're going to get LC comments asking for new
elements and attributes.
... There will be a lot of people who haven't looked at the
spec yet, or want opportunity to have their request
considered.
... Proper way to change the spec is file a bug against the
spec.
... Cutoff for pre-LC was Oct1. Everything after that date will
be considered an LC comment.
... I don't think that you should self-censor, and just assume
there's no chance of getting any new language feature requests
for native elements and attriutes considered.
... That's not what we want
... I don't want to say you have nothing to lose, because
there's cost in time to everyone
... But something for EPUB to consider, whether you want to
make requests for new elements/attributes.
<hsivonen> Gecko exposes the value of the role attribute to JAWS but not any kind of CURIE prefix mapping context, which mean using CURIEs wouldn't really work with the URL and you'd end up hard-coding a known prefix and the resolution to an absolute URI would be fiction
MikeSmith: Not mutually exclusive: could also pursue extensible approach, too
<hsivonen> thus bad idea to use CURIEs
MikeSmith: It's a good idea, although some things we need are likely to be considered out-of-scope for HTML5
Markus says something about e.g. notes
fantasai asks if that wouldn't be <aside>
mjs: Just want to reinforce
Mike's comment that we would definitely like to hear all the
requests, even though we are late in the game and probably
aren't going to add major new feature.
... But requests that are modest in scope and important for a
particular use case will be considered
... We're not 100% frozen yet, but in a few months we will be.
So better to get those requests in now rather than later.
... Any other comments?
fantasai: Wouldn't notes be an <aside>?
Markus: Notes would be a subclass of <aside>
Markus says something about an href role
mjs: Talking about footnotes and end notes?
Markus: Yes. Need to distinguish those for formatting
MikeSmith: Don't we have a bug open on having more roles for <a>?
mjs: If particular semantic of linking to footnote or endnote might be more appropriate as a rel value
hsivonen: Maybe have a CSS pseudo-class detecting the note type from what the <a> points to instead of requiring author to specify
Markus: Reponse from EPUB authors
say that overall, it's really good. There are a number of
additions from XHML1 that we love.
... We're already very close to having it work for books, only
a few minor concerns.
... So not looking for any major surgery here.
fantasai: I think they should define a microformat for subclassing notes.
hsivonen: HÃ¥kon and Bert already defined a microformat for books, although I don't think they addressed notes.
Bert: yes. A lot of that has been added to HTML5, though: <article>, <section>, etc.
mjs: HTML5 just recommends a plain <a>, with no distinguishing markup
hsivonen: footnotes are a thorny
issue in CSS. Prince supports something, but it's not
optimal
... I was reading Dante's Inferno in HTML5. It doesn't make any
sense to read it without footnotes.
mjs: Yeah, I read a Terry Pratchett book that was supposed to have footnotes, but they were all endnotes and it didn't work so well
<Bert> Boom! (BOOk Microformat)
hsivonen: I think we should
figure out the CSS layout model first, then fit the markup to
that.
... If we come up with markup first, and it doesn't fit the CSS
layout model, making it work in layout could become very
complicated, involving many pseudo-classes, etc.
meeting closed?
<Bert> (Contrary to what I remembered, BOOM *does* have footnotes, not just sidenotes: <span class=footnote>)
discussion of role attributes
mjs: You need centralized extensibility for accessibility, so the a11y technology understands the roles
hsivonen: If you're on Windows, what FF can do is more than with the AS api on Mac
<MikeSmith> http://code.google.com/p/epub-revision/w/list
hsivonen: So maybe it's a bad
idea to design stuff with the assumption that you have
IAccessibible2 on Windows
... Alternatively, could consider it a bug that AS doesn't have
this feature
<hsivonen> s/AS/AX/
anne: The only case you'd notice it is JAWS was updated before voiceover
hsivonen: I'm guessing the upgrade rate of JAWS is a non-issue in practice
<MikeSmith> http://code.google.com/p/epub-revision/wiki/Annotations
Julian: You might not believe how backwards some people are in upgrading their browser
hsivonen: Big parts of ARIA have been designed with the assumption of an enterprise stuck with IE7 for years after ARIA has been deployed in JAWS
<MikeSmith> http://code.google.com/p/epub-revision/wiki/DesignPrinciples
hsivonen: Design decisions make assumptions about which part of the system will be upgraded first. Might not have been the best design decisions.
<MikeSmith> http://code.google.com/p/epub-revision/wiki/HTML5Subsetting
fantasai: So is EPUB subsetting HTML5?
MikeSmith: not sure
mjs: Engines are unlikely to enforce any subsetting
fantasai: True, but such content
could be non-conformant for EPUB 3.
... Not all EPUB implementations are based on browser
engines
?: Are there many that are not?
fantasai: I know of at least
two
... and I haven't actually looked into the issue
<kennyluck> fantasai: When I was at Tokyo, I found a EPUB implementation that implements CSS but not based on browser
<kennyluck> .. I also found one EPUB implementation that's not based on browser at all
<kennyluck> ... yet it renders vertical text quite nicely
<kennyluck> ... (It does not support CSS)
fantasai: uses effectively a UA stylesheet only
hsivonen: Are the CSS implementatiosn any good/
fantasai: Don't know, haven't done any testing
discussion of converting HTML5 to EPUB
would need to split into multiple files for EPUB impl's tiny brains :)
<mgylling> Yes, splitting files is done a lot due to memory constraints in certain handhelds
<mgylling> A popular one has a 300k limit IIRC
<MikeSmith> 12 minutes to caffeine
<freedom> which means EPUB doesn't encourage authors to write long chapters?
<mgylling> hehe, yes, need to keep it short ;)
<mgylling> I expect these max file size recommendations to be gone soon, just another generation shift needed in devices
<freedom> mg: do it, my iPhone 4 has 512MB now
<mgylling> freedom, right. Note that this is not spec restrictions; these are conventions that has arisen in the ecosystem
<freedom> OK, bad implementation, not bad spec
<scribe> ScribeNick: fantasai
mjs: Subtopics include
... Idea of using microformats
... another is that we have a number of specific issues
<mjs> http://www.w3.org/html/wg/tracker/issues/124
<mjs> http://www.w3.org/html/wg/tracker/issues/127
<mjs> http://www.w3.org/html/wg/tracker/issues/118
<mjs> http://www.w3.org/html/wg/tracker/issues/119
mjs summarizes the open issues
mjs: Does anyone else have other subtopics?
<adam> *u must be dozing off*
<anne> no kidding
<Zakim> MikeSmith, you wanted to show XPointer registry and to discuss potential need for a role registry similar to need for a rel registry
MikeSmith: Somehow I ended up the
one responsible for registering all link relations for
HTML5
... So, I guess I can put some kind of report on that? What
should I be doing.
Julian: Let's start with a
description of .. right now
... I'll summarize where IETF is right now.
... It all started with realization that HTTP has a Link header
that's supposed to be equivalent to Link element in HTML
... And that there are documents on the web which are not HTML
and for which it would be useful to expose linking
... Lots of people think it would be a good way of expressing
link semantics independently of HTML
... So Mark Nottingham started on the work of writing a new def
of Link in HTTP
... And establishing a registry that could be used in HTML as
well, but would not necessarily be used in HTML
... The IANA registry also includes the link relations registry
that was established for the Atom feed format, which is similar
but not identical to HTML.
... So there are overlapps, but it included syndication-related
things and not everything that HTML has
... So there was lots of discussion on procedural things, and
licensing of the registry.
... Can talk about that later.
... Took a long time for spec to come out, but has finally been
published.
<Julian> http://greenbytes.de/tech/webdav/rfc5988.html
Julian: That's a very old style: you send an email to an IETF list, and a group of designated experts to register that or ask questions.
<Julian> http://paramsr.us/link-relation-types/
Julian: Mark has started making this more modern by, first of all, providing a web page explaining how to register, has a template to help with you write the registration and submit for you to the mailing list
<Julian> http://paramsr.us/tracker/
Julian: The designated experts
now also has an issue tracker
... So people can watch where there registration requests are
progressing
... Makes the IANA process a bit more pleasant
<Julian> http://www.iana.org/assignments/link-relations/link-relations.xhtml
Julian: Here's the registry riht
now
... This contains link relations defined in Atom, Atom
extensions, and HTML4
... and some parts for HTML5
<Julian> https://www.ietf.org/mailman/listinfo/link-relations
hsivonen: ? has been recognized
as an entity that has reasonable ? measures in place
... It seems that the domain name is owned by ???
... as an individual
... And whatwg.org is also owned by an individual
Julian: I'm not sure how that affects our impression of whether microformats.org is stable or not
<MikeSmith> s/???/Rohit Khare/
mjs: My biggest disappointment
about the RFC is that it doesn't have provisions for individual
registrations
... It would be useful to have a central repository where all
of these can be listed so people know what's in use, even if it
doesn't have a formal spec
... I think Mark should make a provisional registry.
... Mark said the registry would be so lightweight it wouldn't
be necessary
... But that has not proven to be true.
<hsivonen> moreover, even proven to be false
Julian: We have provisional registries in other IANA things, and nobody's used them.
<MikeSmith> http://www.ietf.org/mail-archive/web/link-relations/current/threads.html
mjs: I think if you find something that's almost never used, then creating something that has higher barrier to entry, then creating something with a higher barrier to entry isn't going to increase use
Julian: People don't use provisional registries because they don't care enough.
mjs: microformats.org list has even lower barrier to entry, and it is used
Julian: One difference between
IANA registry and wiki page is that wiki is completely HTML
focused
... So they don't consider relations among other formats other
than HTML
... They don't think about use on PDF or video
mjs: Most people invent link
relations for HTML. I don't think it makes sense to force them
to address these abstract link uses that may or may not be
practical.
... It makes more sense to me to provisionally register the
link relations, and then encourage them to think about
generalizing to other formats.
hsivonen: It might be not about
people not caring, but about provisional registration being
dysfunctional
... I also agree with mjs that in some cases people don't care
about nonHTML use cases. In that case we should just do
HTML.
Julian: we talked about ...
provisional registry [that hsivonen mentioned] yesterday, and I
totally agree this problem needs to be investigated.
... I think we try.
... I think we should try to encourage people to think of link
relations applied to non-HTML content
mjs: I think encouragement is fine. But if encouragement fails, what happens? Should the link relation then be undocumented because encouragement was unsuccessful?
Julian: ... nobody's mailed a link relation and asked designated experts to help make the link relation more generic
mjs: You've raised the barrier by tring to make it generic, the person doesn't care about making it generic, so it ends up being unregistered
anne: You don't need that to get it in the registry, but to get it endorsed
hsivonen relates hixie's experience with trying to register a link relation
hsivonen: If what hixie wrote wasn't enough, then I think we have a problem.
Julian: My point of view was that
he didn't seriously try. He wanted to prove it didn't
work.
... I don't think it will be productive to continue on this
path.
mjs: When I looked at the
original templates hixie submitted and compared them to what
the RFC said, I couldn't see any mechanical procedure that
determined they failed to qualify
... So it seems anyone trying to register would require
multiple email go-around
... Same problems result in failure to register MIME types and
URL schemes
MikeSmith: I have been going through the process of making requests using the mandated procedures
<MikeSmith> http://www.ietf.org/mail-archive/web/link-relations/current/threads.html
MikeSmith: You can see there the
discussions about the registry
... It does take multiple go-arounds in email for these.
... One is for some of the link relation names or types, they
are already being used in other contexts
... One of those was 'search'.
... If you look at that, it was specified somewhere else.
... Regardless of how you do this, there has to be some
discussion about what this description should say
... I don't see any way to get around that, if you have
multiple ppl want to define the same thing.
... Other issues were with how it's defined in the spec
itself.
... 'up' is one of those. Had to go back to WG and get a
resolution for it
... .. Maciej... having to change the description of the link
relation so that it's more generic, and less about HTML
... I'm not thrilled with that.
... Don't really care about doing that at this point in the
procedure.
<hsivonen> (one of the top Google hits for the metaphor is from one of our co-chairs: http://intertwingly.net/blog/2005/05/11/Fetch-Me-A-Rock )
MikeSmith: I think many ppl are
not going to be thrilled about changing what they think is a
perfectly reasonable discription of their use case to handle
some speculative use cases
... That's alwasy going to be a troublesome thing for someone
to do
s/disc/desc/
MikeSmith: In the spirit of going
through the procedure and taking it to the end to see if it
ends up being something it works or not
... But I do think we have to keep open the possibility that we
decide that it doesn't work.
... I don't think it's a given that just because it's an RFC
and the registry exists, that we've commited to this is how we
do it.
<MikeSmith> http://www.w3.org/2005/04/xpointer-schemes/
MikeSmith: I think it's still a
possibility that this isn't working the way we would like it to
work, let's try something else.
... There is something else, plh asked me to point out.
... Is the xpointer registry.
<anne> +1 to W3C doing web registires
MikeSmith: This is another way of registering something that is similar
<anne> s/registires/registries/
MikeSmith: I think the biggest
... difference between things that have been successfully
regsitered
... and those that are still being reviewed
... i.e. provisionally registered
... All you need to do to request a provisional registration,
you just start by typing in a name of some kind
it gives you a form asking for a description, and optionally a spec URL
MikeSmith: This is a middle ground between a wiki page
and
<hsivonen> This looks good to me
MikeSmith: At least it's got a
form-driven interface
... I think this is a good middle ground
... If the IANA registry provided a way of doing this, I think
that would be something we could agree on
Julian: IANA registry has
something very similar
... The only thing is that instead of being automatically
registered, it gets sent to the email list
... If we made a provisional registration out of the sumission,
that would be the same.
<Julian> http://paramsr.us/tracker/
<anne> The requirements for XPointer are first-come-first-serve
Julian: and then someone on the mailing list to the tracker page
<anne> This is not at all the case for the link registry
<anne> well, the one the IETF/IANA uses
hsivonen: How do you know the tracker issue is filed and where that is?
Julian: You don't
?: Why can't you do a web-based form?
Julian: Can't do that in IANA.
IANA doesn't have web-based forms. Lives in last century.
... The form that posts to email is a compromise.
hsivonen: So why does HTMLWG/W3C want to deal with an organization that lives in the last century
<weinig> s/?:/Sam
hsivonen: Instead of using xpointer registry code?
Julian: It depends on whether you think the link relations should be synced with other formats or not
sicking: Why couldn't you let W3C do the syncing to IANA?
MikeSmith: Before ? pointed out xpointer, I didn't know we did registries
mjs: Sounds like building a registry along the lines of xpointer would be a great idea
<MikeSmith> s/?/PLH/
mjs: Any volunteers to do
that?
... write it up as a Change Proposal?
... It's a little past deadline, but since we have new info on
the W3C registry option, would be a good thing to do
MikeSmith: Guess I should talk to plh about this.
hsivonen volunteers
MikeSmith: plh asked me to point
out the open issue about Role
... We talked about it this morning. Similar potential need to
have a role registry
... plh isn't sure xpointer way is the right way to go, but
wanted us to be aware that it exists
anne: I think we should do role more centralized, because it affects implementations directly.
hsivonen: In last meeting I asked EPUB to ask PF to set aside some tokens for them once getting commitments from AT vendors that they will support these roles
mjs: Other things in HTML5 might
benefit from this
... e.g. <meta> names
... There was a third thing
Julian: canvas context?
mjs: Seems more like role, in that it has implementation implications and should therefore be centralized
hsivonen: Yes. for role, e.g. you
need coordination among AT vendors and browsers etc.
... Not good to have a registry. Rare to make a new role.
... PF should be able to set that aside without a formal
process.
anne: Other one is meta
http-equiv, which has a different namespace than meta
name
... And canvas context, you do sorta need a place that says
which are the contexts and which are compatible with
which.
... Currently all are incompatbile, so not an issue now, but
might change.
hsivonen: New canvas context is even rare
r
?: Still need a list of them
??: No, could just be defined by the specs that define them
hsivonen: I don't see this as being a problem right now.
<kennyluck> s/??/mjs/
hsivonen: There are three canvas contexts in the world, and one is proprietary
anne: we're removing them, 'cuz
features have been added to 2d
... Might want a variant of WebGL that is compatible with
2D
... But still it's very limited
mjs: There's probably only a single-digit number of these, and should all go through HTMLWG anyways
fantasai: For link relations,
seems like the idea is to have a provisional xpointer
registry
... What about if someone wants to port a provisionally
registered link rel to IANA, for more general use?
discussion
hsivonen: Dont't think we want to hijack Atom registrations
Julian: If we decide not to go with IANA registry, need to decide whether we want to continue with registration of HTML5 link relations in IANA
mjs: I think registering HTML5
link rels in IANA is unrelated to progress of HTML5
... It's not a requirement for us. It just makes the IANA
registry more complete.
mjs expresses that he doesn't care whether MikeSmith finishes the registration since it's not required for HTML5
MikeSmith: It's not a lot of work, think it makes sense to finish offf.
mjs: what about the ones where the designated experts require changes to the definitions
MikeSmith: filed issues on that
mjs: For us, the importance of a registry is as an extension point.
sicking: Seems to me that the
best caretakers of the link registry so far has been the
microformats people
... So I want whatever solution we choose here to work for
them.
mjs: Idea of using page on
microformats wiki was proposed, but nobody's written up a
change proposal for that either.
... Anyone want to volunteer to write that up?
sicking: Ok, I'll do it.
mjs: So post to the mailing list
and say how long it will take you?
... I think we should make an exception here, because we have
new information that will help us make a better decision
Julian: Microformats.org is not a new idea
sicking: New information is our experience with IANA
Julian: Half have gone through. A
number are held on bugs being fixed in HTML
... Then we have to review the updated spec.
mjs: If the spec isn't updated, what happense?
Julian: We'd probably accept the registration anyway.
mjs: So why is the registration being held up?
Julian: If the description is updated at HTMl5, then the IANA registration would have to be updated multiple times.
hsivonen: Why is updating IANA registry multiple times a problem?
Julian: I don't think it makes a big difference either way
fantasai: Then I suggest you ask the IANA registers to finish the registration for any link relations that will be registered with the current text, and then update the registry when the problems they've pointed out have been addressed with updated text.
<scribe> ACTION: Julian to Ask the IANA designated experts if this would be an acceptable model [recorded in http://www.w3.org/2010/11/04-html-wg2-minutes.html#action04]
<Julian> http://www.w3.org/html/wg/tracker/issues/127
ISSUE-127
Julian: ... Means in theory the semantic of the link relation can change depending on whether it's on <link> or <a>
<MikeSmith> trackbot, associate this channel with #html-wg
<trackbot> Sorry... I don't know anything about this channel
<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
<MikeSmith> issue-127
<MikeSmith> issue-127?
<trackbot> Sorry... I don't know anything about this channel
Julian: I think the link relation
should be defined the same for both, and the usage affect
details like scope
... I think the section should be revised to not imply that rel
values on <link> and <a> could be substantially
different
... The IANA registry has an extension point so that each
registration can have multiple columns
<MikeSmith> issue-127?
<trackbot> Sorry... I don't know anything about this channel
<kennyluck> trackbot, associate this channel with #html-wg
<trackbot> Associating this channel with #html-wg...
Julian: That was requested by Ian
<MikeSmith> issue-127?
<trackbot> ISSUE-127 -- Simplify characterization of link types -- raised
<trackbot> http://www.w3.org/html/wg/tracker/issues/127
Julian: E.g. to have a column that says whether the linked resource is required to be loaded, or just informational relation
<MikeSmith> ACTION: Julian to Ask the IANA designated experts if this would be an acceptable model [recorded in http://www.w3.org/2010/11/04-html-wg2-minutes.html#action05]
<trackbot> Created ACTION-196 - Ask the IANA designated experts if this would be an acceptable model [on Julian Reschke - due 2010-11-12].
mjs: It seems that in practice the spec does what's requested, so it's more an editorial issue
Julian: This distinction applies
both to the spec and also to the registry
... I don't think having the distinction in the registry is a
good idea.
... We don't seem to have any good cases for that.
... The observation is, we currently have a table in the spec
that has columns for effect on <link> and effect on
<a> and <area>
... In this table, both are exactly the same
... except for two values, which in one column it's listed
they're not allowed
... And in these case there are bugs on whether that
distinction is a good idea.
fantasai: Setting stylesheet on <a> doesn't make sense to me
mjs: 'stylesheet' and 'icon' would have no effect outside <a>, even if we add them
Julian: ...
... We'll have to make a decision on that no matter where we
put the registry. Defining things such that it's possible for
relations to have a different deifnition on different elements
is a bad idea.
mjs: ok
<kennyluck> s/<a>/<link>/
<Julian> http://www.w3.org/html/wg/tracker/issues/119
Julian: This is about the 'up'
relation.
... Someone thought it would be nice to change the definition
to allow repetition of 'up'
... to e.g. have 'up up' mean grandparent
mjs: That wouldn't work very well given the DOM api for rel, which lists unique tokens
fwiw, I agree this seems like an ill-fitted idea...
<Julian> http://www.w3.org/html/wg/tracker/issues/118
<anne> HTML5 says something different from HTML4?
<Julian> this is about navigational link relations that changed in HTML5, potentially changing existing content
hsivonen: fwiw, I think we should
get rid of the up up up thing.
... It won't be supported in UI very well anyway
Julian: The use case given was to
build a navigation tree in the UA
... But I think there are better ways to address that use
case
hsivonen: When a browser user
experience team wants to implement something, and asks for
syntax for it, then we should conside rit.
... but at this point it just seems a theoretical idea
... So I would propose to just drop it
Julian: I'd like to ask the chairs to bundle the timing for these issues so they don't get too spread out
mjs: Could put them all
together
... have been staggering them so you don't have to write
proposals all at once
http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html
meeting closed
RRSAgent: make minutes
RRSAgent: make logs public
<anne> scribe: anne
MJS: Lets make a testcase in this
session and submit it
... in the later half of this session
JS: I am willing to coming up
with a format for tests
... and write a harness
<mjs> ACTION: sicking to design a file format for describing tests, and to write a harness that will run the automated tests [recorded in http://www.w3.org/2010/11/04-html-wg2-minutes.html#action06]
<trackbot> Sorry, couldn't find user - sicking
<mjs> ACTION: Sicking to design a file format for describing tests, and to write a harness that will run the automated tests [recorded in http://www.w3.org/2010/11/04-html-wg2-minutes.html#action07]
<trackbot> Sorry, couldn't find user - Sicking
trackbot, this is HTML WG
<trackbot> Sorry, anne, I don't understand 'trackbot, this is HTML WG'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
<dbaron> trackbot, status
<trackbot> This channel is not configured
KK: I can update the wiki
<MikeSmith> trackbot, associate this channel with #html-wg
<trackbot> Associating this channel with #html-wg...
<scribe> ACTION: kris to update the wiki [recorded in http://www.w3.org/2010/11/04-html-wg2-minutes.html#action08]
<trackbot> Created ACTION-199 - Update the wiki [on Kris Krueger - due 2010-11-12].
<scribe> ACTION: Sicking to design a file format for describing tests, and to write a harness that will run the automated tests [recorded in http://www.w3.org/2010/11/04-html-wg2-minutes.html#action09]
<trackbot> Sorry, couldn't find user - Sicking
<scribe> ACTION: jonas to design a file format for describing tests, and to write a harness that will run the automated tests [recorded in http://www.w3.org/2010/11/04-html-wg2-minutes.html#action10]
<trackbot> Sorry, couldn't find user - jonas
<sicking> gaah, i don't exist
<sicking> i irc, therefor i exist
KK: What about XSS issues?
PLH: I agree we cannot solve the
XSS issues
... My goal is that we do not set up services on these
domains
... so there is no problem, effectively
AVK: as long as w3.org does not document.domain we are fine, otherwise it might be safer to use w3test.org
MJS: There might be a problem in the future; everything should be safe if we do not use a subdomain
JS: I have an idea for
non-automatible tests, but we can discuss that later
... The way I would like us to do new things is write tests in
the new format if it is compatible with our features
MJS: We have a requirement for landing new features and we could require them to be written in the HTML format
AvK: We have used this format
successfully already
... e.g. for server-sent events and XMLHttpRequest
MJS: one thing we might need to
do is identify features in the specification which are not new
but still need tests
... there is an HTML4 test suite
AvK: I do not think we should start from that
[people agree]
HS: How does updating work?
JS: We will have to figure it out
HS: for html5lib WebKit first lands in WebKit, I land first in html5lib
[HS implements for Gecko]
SW: We are not opposed to change
AvK: I think if the test contributor is known the tests should just get in
JS: I do not agree, I think we should have a staging area
KK: I think so too
MJS: I think it makes more sense that the testing in browsers happens later and that tests should get automatically in
[scribe misses out on discussing Mozilla specifics]
KK: Basically you have a set of tests, and wait for them to be approved
MJS: What do you want the approver to actually do?
KK: cursory review
AB: I think it might be worth
having almost automatic approval process
... for tests that pass in multiple user agents
MJS: why does there need to be this approval step? it will happen in distributed form anyway
AB: to increase the level of quality
MJS: it does not seem to happen now
AvK: agreed
DB: I am not sure that a approval process is good for known contributors
MJS: It seems like a waste of
time of people to require people to manually run the tests in
every browser before it is approved
... there will also be cases that fail in all browsers
DB: it seems you want a staging
area because you want a known good set of tests
... an alternative approach is to ship a release, rather than
delay on trunk
HS: not having a lot of process helped html5lib to move forward faster
MJS: with a release you know it does not get worse
KK: the idea of approved is that is done
AvK: so far that has not worked I think
MJS: I think you will always get more tests and with releases you know the delta and can review whether that is ok as you already know the previous release was ok
[something about multiple vendors contributing tests being awesome]
MJS: problematic tests can be removed from the release
<hsivonen> fantasai: Microsoft testa a lot of value combinations. Mozilla tests tricky edge cases.
<fantasai> fantasai: Different vendors take different approaches to testing, and thereby cover different aspects of the features.
<fantasai> fantasai: By putting them together you get a more comprehensive test suite
JS: if the release process does not work we can revise it
KK: i like to lock things done
DB: if browsers import the tests they will report the problems more quickly
KK: in the current model the test can be pulled right away
[mercurial haz magic]
JS: If I find something wrong should I fix the test and mail the list
KK: currently mail the list
... and open a bug
MJS: I think people who report the bug should be allowed to fix the test
AvK: you want to optimize for the case that is most common, and most common the bug reporter will be correct I think
DB: you should notify the person who wrote the test
JS: I am fine with attaching patches to bugs
http://www.w3.org/html/wg/wiki/Testing
<plh> --> http://lists.w3.org/Archives/Public/public-html-testsuite/2010Feb/0014.html Mercurial server
<dbaron> hg clone http://dvcs.w3.org/hg/html/
http://tc.labs.opera.com/apis/EventSource/eventsource-close.htm is an example of a test following the non-written guidelines
<dbaron> default-push = https://[USERNAME]@dvcs.w3.org/hg/html/
<dbaron> is a line that you'd want to add to .hg/hgrc after:
<dbaron> [paths]
<dbaron> default = http://dvcs.w3.org/hg/html/
http://annevankesteren.nl/2010/08/w3c-mercurial
<hsivonen> let's make one of these: http://ted.mielczarek.org/code/mozilla/mochitest-maker/
<hsivonen> that is, we should have a tool like that for the W3C harness
<krisk> see http://test.w3.org/html/tests/
<hsivonen> I'm already annoyed by having to wrap stuff in test()
<hsivonen> so I can't do ok(false, "FAIL!"); in scripts that aren't supposed to run
<plh> ACTION: Kris to add reftest handling in the test harness [recorded in http://www.w3.org/2010/11/04-html-wg2-minutes.html#action11]
<trackbot> Created ACTION-200 - Add reftest handling in the test harness [on Kris Krueger - due 2010-11-12].
<krisk> http://test.w3.org/html/tests/approved/getElementsByClassName/001.htm uses a relative path
<hsivonen> https://developer.mozilla.org/en/Mercurial_Queues
<hsivonen> you'll really want to use MQ
Media Queries ftw
<krisk> http://www.w3.org/html/wg/wiki/Testing
<weinig> sicking: http://www.w3.org/html/wg/wiki/Testing
<plh> a reftest: http://test.w3.org/html/tests/submission/W3C/bidi-markup-export/html5-html/
<dbaron> trackbot, associate this channel with #html-wg
<trackbot> Associating this channel with #html-wg...