- From: Michael(tm) Smith <mike@w3.org>
- Date: Fri, 7 Nov 2008 14:20:56 +0900
- To: public-html@w3.org
http://www.w3.org/2008/10/23-html-wg-minutes.html
* Topics
1. ISSUE-13 handling-http-401-status
2. ISSUE-20 table-headers
3. ISSUE-37 html-svg-mathml
4. ISSUE-41 Decentralized-extensibility
5. TAG joint meeting
6. table headers
7. HTTP Authentication
8. HTML integration point for HTTP authentication
* Summary of Action Items
_________________________________________________________
MikeSmith reviews agenda
Cynthia: unconference topic: implicit accessibility roles/topics
Lachlan: authoring guide
MikeSmith: exec4 is reserved for unconference sessions this PM
<mjs> ooh, implicit accessibility rules
<mjs> *roles
MikeSmith: re testing, I suggest we update the annotations on the
spec about which parts are stable, tested, etc.
<anne> they are inside the WHATWG version of the spec DanC_lap
<anne> in the sideline
there's some php interface to update them, yes?
<Hixie> perl, but yes
<Hixie> alt-double-click a section to update that section
<Hixie> you have to log in first (link at the top right) -- if you
don't have an account (most people who have sent feedback
automatically have one set up) let me know
hmm... one day I'm pretty sure I figured out how to just GET the
annotations
<anne> there's an API somewhere
<Hixie> DanC_lap:
http://www.whatwg.org/specs/web-apps/current-work/status.cgi?act
ion=get-all-annotations
http://www.whatwg.org/specs/web-apps/current-work/status.cgi?action=get-all-annotations
<Hixie> DanC_lap: i think there's documentation but i can't find it
at the moment. drop me a mail if you want me to hustle some up
the docs were sufficient last time I needed it
ISSUE-13 handling-http-401-status
<gsnedders> http://www.whatwg.org/issues/#WF3-httpauth
http://www.whatwg.org/issues/#WF3-httpauth
<pimpbot> Title: WHATWG Issues List (at www.whatwg.org)
Julian_Reschke: I saw discussion on the whatwg mailing list about
authentication...
<Hixie> http://www.whatwg.org/issues/#WF2-http-auth-login-logout
http://www.whatwg.org/issues/#WF2-http-auth-login-logout
<pimpbot> Title: WHATWG Issues List (at www.whatwg.org)
Julian_Reschke: web designers rarely used http authentication...
... if we could [missed], it might help
Hixie: I have a pile of mail on this authentication issue
<Julian_Reschke> http://www.w3.org/html/wg/tracker/issues/13
http://www.w3.org/html/wg/tracker/issues/13
<pimpbot> Title: ISSUE-13 - HTML Issue Tracking Tracker (at
www.w3.org)
Anne: it's probably important to handle logout at the same time
Hixie: this would make a good unconference session topic... I'd like
to brainstorm... I haven't seen a good transition strategy
AlGilman: want to bookmark some connection... [missed]
Hixie: while we're at it, we'd like people to use digest rather than
basic
Julian_Reschke: yes, there's a bit of a chicken-and-egg deadlock
between http protocol design and browser development
... co-chair WAI PF WG
ISSUE-20 table-headers
Al: issue summary: data presented in tables depends on context...
... in a visual scan, it's usually easy to scan to the top of the
column or start of row to get context
... we [WAI?] have been asking that the context be machine
readable...
... assistive technology provides a gesture for asking for this
context for a cell
... we've seen some proposals... we're interested in deployment in
browsers of some algorithms
MikeSmith: discussion supports the utility of the functionality in
general...
... the disagreement in the discussion is about whether the @headers
attribute may refer to <td> elements or is constrained to <th>
[refinements from LH/HS... too fast for scribe... can you guys write
them down?]
<anne> (From what I gathered during a PF meeting having headers for
headers would be enough.)
<Laura> Proposals: http://tinyurl.com/6phdwg
http://tinyurl.com/6phdwg
<pimpbot> Title: HTML/IssueTableHeaders - ESW Wiki (at tinyurl.com)
<anne> (Example why that is needed anyway:
http://lists.w3.org/Archives/Public/www-archive/2007Aug/att-0003
/offset-mess.htm )
http://lists.w3.org/Archives/Public/www-archive/2007Aug/att-0003/offset-mess.htm
<pimpbot> Title: layout height attributes on body and html elements
(at lists.w3.org)
AlG: some [hallway? PF?] discussion made progress... [something
about table header chaining]
MS: I'd like to have Josh before we get too much further in
Hixie: I'm about 86 messages behind on discussion of use cases for
this design issue
AlG: see "function and impacts" thread
<smedero> Al's email:
http://lists.w3.org/Archives/Public/public-html/2008Sep/0362.htm
l
http://lists.w3.org/Archives/Public/public-html/2008Sep/0362.html
<pimpbot> Title: function and impacts (was: scope and headers
reform) from Al Gilman on 2008-09-14 (public-html@w3.org from
September 2008) (at lists.w3.org)
AlG: see "function and impacts" thread for a re-cap and high-level
framing
MichaelCooper: the discussion around use cases seem more productive
than discussion of tags/attributes/conformance
<Zakim> MichaelC, you wanted to suggest the use cases need to be
further understood before getting into conformance rules
Hixie: quite. I always consider use cases before making markup
design decisions
MurrayMaloney: there's a lot of existing practice since 1994... why
not use that?
Hixie: we're re-considering design of many[all?] HTML details in the
light of another 10 years of experience
AlG: to recap this week's discussion briefly, there's room for
improvement... what's in the field is arduous for authors
MS: so I hear relevant parties are more likely to be available
tomorrow PM
AlG: but I'm not sure I have Josh tomorrow
ISSUE-37 html-svg-mathml
MS: SVG WG asked for more discussion before releasing a draft
including an earlier proposal
MM: and MathML?
MS: MathML advocates seem satisfied with current draft on MathML
integration
<smedero> SVG WG's counter proposal to the HTML WG is on their wiki:
http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html
http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html
<pimpbot> Title: SVG in text-html - SVG (at www.w3.org)
ISSUE-41 Decentralized-extensibility
<gsnedders> The current draft is
http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html
AFAIK
http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html
<pimpbot> Title: SVG and HTML (at dev.w3.org)
MS: the tech plenary discussion yesterday touched on this.
AlG: is the TAG session intended to cover this?
MS: given the time, the TAG expressed a preference to discuss
modularization. Some TAG members particularly interested in
distributed extensibility aren't here
<anne> http://lists.w3.org/Archives/Member/tag/2008Oct/0031.html
(Member-only)
http://lists.w3.org/Archives/Member/tag/2008Oct/0031.html
<anne> (in response to gsnedders)
<smedero> Julian_Reschke: didn't you say you found a new info on
ISSUE-54? That there was a similar problem with ASP.NET?
<Julian_Reschke> on issue 52: do we have a separate issue for other
issues for current HTML generators, such as wrt to new empty tags?
<Julian_Reschke> smedero: yes, the "xslt-compat" name is misleading;
it's needed for more content producers
no, I haven't seen a separate issue on new empty tags, though I'd
want to see a more concrete problem/issue before adding it to the
list
<smedero> Julian_Reschke: have you sent an email on that anywhere? I
was going to link that up to the issue... if not, nevermind.
<Hixie> we could change it to "legacy-compat" or some such
eek... "legacy-compat" sounds like a huge swap
<Hixie> that's the idea :-)
<Julian_Reschke> smedero: can't recall; maybe it was mentioned on
IRC somewhere
swamp, I meant
<Hixie> we need something that sounds bad so that people don't think
it's the more cool thing
MS: tomorrow at 2pm for SVG/HTML?
<anne> Hixie, maybe just "compat"
MS: how many ppl? 12-ish
"compat" with what? more specific, please
<anne> tools that can't generate <!DOCTYPE html>
+Joshue
ah. that suggest overlap with issue-4 "HTML Versioning and DOCTYPEs"
agenda/
<fantasai> ScribeNick: fantasai
Mike: Next major issue is modularization of the spec
... The TAG has concerns about this
Anne: Shouldn't we discuss other topics?
...
Mike: About the authentication discussion
Mike asks about scheduling
Mike: So from 4:45 until ... 5:30?
... For the authentication discussion
... So just before we take a break and before we have the TAG
members show up
... Does anybody have any thoughts on modularization?
... So the issue is .. we've had this discussion a lot ourselves
... I think there's general consensus to split out certain parts of
the spec
... The issue is do we have editors that are willing to work on
these separate parts. That's been the biggest blocking factor
... ... discussion with the TAG. That's where we're at as a WG with
the issue
... Any other thoughts on that before we talk with TAG?
?: Do you want to take a shot at explaining that?
MM: Whether there's one editor or three editors, there's still one
document or multiple documents
Hixie explains that the overhead of editing multiple specs is high
MM: That's not my experience
marcos: It is mine
<Julian_Reschke> nor mine
<DanC_lap> +marcos
Mike: We have had some discussions about modularization, but the
resolution -- or non-resolution -- was that we haven't had people
volunteer to take on other parts of the spec
... A specific example of this is ...
<DanC_lap> Marcos Caceres
Mike: A large part of the spec is the spec for the window object
... It used to be a separate spec
... And we agree it should be a separate spec
... But we didn't have an editor, so we merged it into the HTML5
spec
... There are lots of things in HTML5 that rely on it
... If we had someone to take over ...
Kai Scheppe: ...
Hixie: The window part is a big part of the spec
Mike: what about ..
Hixie: there's too much stuff that relies on it
... The remote event target would be a better choice. That's a
reasonably self-contained thing. i'd estimate 5 hours a week for a
few months and then 1 hour a week for a year
Cynthia: ... might get more people to volunteer if you have chunks
like 5 hours / week
Hixie: The more trivial sections are done
... Stuff like canvas etc. that are 40 hours a week for a year,
those are where we really need editors
... Particularly rendering view
... that really is a separate document
... The section that defines legacy attributes
Mike: If you look at the current spec, that section says "to come"
Hixie: It didn't really make sense to define it until about now.
Mike: What we expect from having a discussion with the TAG, one of
the tangible things we can talk about
... ... we do have time set aside tomorrow to go through and look at
the spec section by section and decide which parts of it are mature
and stable with an eye towards what we're ready to write test cases
for.
... But also look at what sections we can split out and look for
editors for
... Then we could make proposals about parts of the spec that could
be taken on by separate editors
... And if we have a concrete list, an assessment about which parts
and what level of effort would be needed to maintain that part of
the spec
Mike: Then we could maybe get more people interested in parts of the
spec
Hixie: I've been privately approaching people. Also someone from
Opera recently asked about working on the timer starts
... Some sections are marked "i'm looking for an editor"
... Even then it's taken me a year to find someone for timer
... Timer is a good example of how hard it is to estimate time
needed
... between the time when I first started looking for an editor and
now, the work tripled
... because the webapps group became looking at a next-generation
timing ...
... the problem we had with the window object was that we thought it
was very small, 2-line api
... And now it's a third of the spec, and the editor couldn't cope
with what became the scope of the work.
Hsivonen: Another thing is that the editor to do a good job needs to
have extended exposure to the bug database of a browser engine
Hixie: or preferably more than one
Hsivonen: And there aren't very many people with that kind of
exposure.
<DanC_lap> (seems like we could separate editing and
authoring/design more.)
Mike: So let's put together a list of what parts of the spec we
could split out and how much work we think they'll be
... but let's take a break and come back at 11.
BREAK
<mjs> DanC_lap, it's not clear to me that would improve matters; few
people are qualified to do the authoring/design, while the
mechanical edits are at the same time only a small fraction of the
work and also opportunities for introducing errors into the design
<Yves> 2
<dino> what is the whole camera thing?
TAG joint meeting
Mike: Next hour and a half discussion with TAG
Mike: A number of issues potential topics
Mike: Modularization of spec is top one
... Other topics are on the list as well.
<anne> celebrities at the table man
<anne> (re dino)
Mike: Since we have time and attention of TAG, we should try to
discuss those issue too
... But we start with modularization
... First I'd like to do a quick self-intro
<DanC_lap> Henry Thompson
<dbaron> Henry Thompson, U of Edinburgh
<DanC_lap> Norm Walsh
<dbaron> Norm Walsh, Mark Logic
<Norm> Norman Walsh, Mark Logic Corporation
<dbaron> Tim Berners-Lee
<dbaron> T. V. Raman, Google
<Norm> Ashok Malhotra
<dbaron> Ashok Malhotra, Oracle, Oracle
<dbaron> Noah Mendelssohn, IBM
<ht> ssohn/sohn/
<noah> Noah Mendelsohn, IBM
<dbaron> (and Dan Connolly)
<Norm> Missing from the TAG: Stuart Williams, Dave Orchard, Jonathan
Reese
Mike: So first topic is Modularization of the HTML5 spec
... I think best way to start discussion is for members of the TAG
want to discuss the problem they see here.
<dino> fantasai, there is a Castorama 10mins walk up the road. It
will have duct tape.
Henry: I care a lot about distinguishing about the definition of the
language as a formal artifact and the discussion of the behavior of
what browsers do with something that purports to be of that
language.
... There are two issues, one is whether the spec for the formal
language is a separate spec, the other is whether that is defined.
... Is there such an authoring spec?
Hixie: There has always been an intent to have that.
... There are two: one is a stylesheet applied to the spec, the
other is a non-normative guide.
Tim: ... the parts that define the valid document and that that
define error-recovery are separate and flagged differently.
<anne> (Simon being Simon Pieters)
Tim: ... synchronization with the spec
Hixie: Because the spec has a lot of churn, it would be hard to ...
Tim: Once it's been done once could one assume it would be simple to
add tags to the new content?
Hixie: I'd like to emphasize that the spec is not just for browsers,
but for all user agents
Noah: I'm coming from the same place that Henry is.
... I'd also like to say that the TAG as a whole has no opinion on
this. We're here to learn
... I'm speaking for me personally, not for the TAG.
... One lurking issue is to what extent you believe that over a
period of 5-10 years, most user agents will do pretty much what the
spec you're writing says.
Hixie: Over a period of 5-10 years either the browsers will change
to match the spec, or the spec will change to match the browser.
Noah: Browsers do crazy stuff. They will keep parsing through tag
soup, everything but the kitchen sink.
... What about parsers for other applications. Will they do the same
quirky stuff?
Hixie: Yes.
Noah: I think it's good to distinguish over time a clean HTML
format.
... And try to get people to write that.
... Over time that that becomes the language spec.
... It becomes a contract between authors and consumers
... The spec I would ideally like to see would be an HTML5 spec that
isn't mentally for authors, but is the language spec, that says this
is a table, this is ..
Hixie: That is the current spec minus the implementation stuff.
Noah: ... good, readable, well-ordered introduction to the language.
Hixie: we want the spec to be understandable and coherent.
... We have various options. We can use a CSS style sheet to hid
stuff. If that doesn't work, we could maintain a separate document
(which would be a maintenance nightmare), or do some kind of
transformation.
Noah: I want it to be good quality
Hixie: of course
Karl: The content.. of HTML5 is well-defined and stricter than that
in HTML4.01
<DanC_lap> (stricter... for example?)
Karl: The content inside the spec, is not parse-able, not readable,
for most people.
... An automatic translation with CSS or XSLT will not be enough
... So there is a need for a separate document.
Lachlan: Just wrt tools that parse HTML that aren't browsers and wrt
clean HTML spec
<marcos> +q
Lachlan: The spec needs to define an algorithm that parses all the
crap on the web.
<karl> DanC_lap, for example no align attribute
<DanC_lap> thanks.
<marcos> -q
Lachlan: The parsing section that handles the non-clean stuff is
very tightly integrated into the part that handles the clean stuff
... people who want to just parse an HTML table can grab an off-the
shelf library
<Hixie> DanC_lap: also much stricter rules for nesting interactive
elements, iirc
Lachlan: Having a tool that only accepts clean input does not seem
particularly useful.
<pimpbot> Title: HTML 5 And The Hear-Write Web - W3C Q Weblog (at
www.w3.org)
Anne: The spec does allow such an implementation.
<Zakim> timbl, you wanted to point out to Noah that in this case he
does NOT want to see the proposed contract as in that model it has
the full error recovery. In fact authors write who
Tim: When you asked for the contract document, I suspect in this
case you don't want it. Because in this case the contract is that
the reader will understand the clean stuff as well as the garbage
... You'll get the whole mess.
<MikeSmith> http://www.w3.org/html/wg/html5/#syntax
http://www.w3.org/html/wg/html5/#syntax
<pimpbot> Title: HTML 5 (at www.w3.org)
<MikeSmith>
http://www.w3.org/html/wg/html5/#conformance-requirements
http://www.w3.org/html/wg/html5/#conformance-requirements
<pimpbot> Title: HTML 5 (at www.w3.org)
Tim: ... generate a clean document without any quirks.
... But the browser language , which is what this group is working
on, ...
... but there's a separate language that is described as conforming
HTML5
... that's described in the spec
... but that's not the same as the contract for the browsers
<marcos> +q
Tim: ... ideally everything will be clean and won't have any quirks
... You appeal to the contract between the reader and the writer,
and the ...
Noah: What you call conforming HTML5 is what I call HTML5.
Tim: That has nothing to do with what the browser accepts. It's not
part of the contact.
Hsivonen: Two issues. One, for whom is this language spec intended.
Karl mentioned authors.
... Then there's the suggestion that there be a normative
description of the conforming language.
... These are two different things.
<Hixie>
http://www.whatwg.org/specs/web-apps/current-work/multipage/#wri
ting-html-documents
http://www.whatwg.org/specs/web-apps/current-work/multipage/#writing-html-documents
<pimpbot> Title: HTML 5 (at www.whatwg.org)
<Hixie> er,
http://www.whatwg.org/specs/web-apps/current-work/multipage/synt
ax.html#writing-html-documents
http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#writing-html-documents
<pimpbot> Title: HTML 5 (at www.whatwg.org)
Hsivonen: The Writing HTML section is a language-lawyer description
of the character streams that will go through the parsing algorithm
without hitting any error conditions
... ....
... But if you are a typical author, you don't want to read the
stuff in that section.
... Part of it is because it is written very strict. It lists all
the unicode characters, e.g.
<marcos> -q
Hsivonen: If we have this normative language spec, we don't get the
document Lachy was talking about.
... Using this language spec for parsing, because there are no
off-the shelf parsers that don't do error recovery
<Hixie> -q
Hsivonen: If you wanted something that only parsed clean conforming
HTML, then you'd have to write one. But to do error recovery you
have libraries.
Marcos: ... fixation on having clean markup.
... maybe because you want a tree that is serializable as XHTML
... You get a DOM tree anyway. You can convert to XML anyway.
Tim: Because your authors want to know how to write HTML, what
element to put for what.
Marcos: But that's what an authoring guide would be for.
... ...
Noah: Are you saying you don't feel any need for people to fix their
non-nested tags?
Marcos: Yes. Who cares?
Tim: There are two problems. In the short term it's confusing,
teaching someone they won't get it.
... In the book about how to build a web page you say inside the
body there are paragraphs.
... If you're somebody who has written all kinds of other documents
and has been asked to produce HTML5 output, then you want something
to point this programmer to
Marcos: There needs to be a balance between teaching people the
markup and how the DOM is created.
... If I write a paragraph and I write a doctype and the <p>
element.
... The <html> and <body> are auto-generated by the parsing
algorithm
Tim: ... if they're just going to script it, and not ...
... And it looks really cool .. to outputting documents they want it
visible and usable by people .. in 200 years time. they want to
produce something that is valid.
... There are a class of users that need to know what exactly ..
being able to roll up some documents .. DOM obviously it's much
easier spec to read
Marcos: The parsing already algorithm doesn't do what you say, it
inserts elements at random
laughter
Marcos: well not exactly at random
... The parsing algorithm of HTML5 already defines this.
Marcos tries to give an example
Mike: I'd like to interrupt, we're straying off-topic and other
people are on the queue
... we want to focus on the idea of having a separate spec for the
language.
Murray Maloney: We were drilling down into why we need such a spec
Tim: It might be useful to have two different documents. One
describes what you should send down the wire to get this result in
the DOM. The other is what you should send down the wire to make a
web page
<karl> is it just a matter of finding an editor for this document,
and then discuss later on about the requirements and conformance
options of this document
Henry: I'm perfectly happy for as many ppl out there as want to
never to use a strict parser as long as they don't mind I want to
use a strict parser.
<karl> I'm willing to write this document after November
Henry: I think the case today that the students in CS are told they
must submit HTML that passes the w3c validator. That's part of the
education process.
... There's a substantial history of curriculum development that led
us to want to do that.
<Hixie> MikeSmith, can i jump in here?
Henry: As long as you're fine with us doing that, then I'm happy for
you to use whatever parser you want to use.
... If the spec is going to discourage that, then I think we have a
problem here.
Hixie: The parser defined in HTML5 today allows any implementation
to abort on the first error.
Henry: That's good enough for me.
<Zakim> DanC_lap, you wanted to think out loud about the character
encoding detection algorithm
DanC: The spec modularization problems that I run into are things
like the character detection algorithm, which is e.g. used in some
other webapp spec
Tim: Sounds like a separate spec to me.
DanC: I think it's been copied into the webapps spec?
Marcos: we reference it?
DanC: Is the scheduling ok so that HTML5 will be done before you
need to advance through REC track?
Hixie: That section is very specific to determining character
encoding for HTML
... It's not like the URI spec which is independent
... this is literally part of HTML
<MikeSmith>
http://www.w3.org/html/wg/html5/#determining-the-character-encod
ing
http://www.w3.org/html/wg/html5/#determining-the-character-encoding
<pimpbot> Title: HTML 5 (at www.w3.org)
Hixie: It makes sense to refer to HTML to talk about HTML
DanC: Suppose they want to finish their spec before HTML5?
Tim: 2 groups use the same algorithm, then typical way of doing this
is to rip out that part and put it in a separate module
<MikeSmith> fantasai, I'll try to summarize after Tim
Tim: Because that piece is small, it gets reviewed by a bunch of
people who wouldn't look at HTML5
... i18n will pore over it
... and it'll go to REC fast and become a useful tool for the
community
MikeSmith: We already have a lot of other specs besides HTML5 that
already normatively reference or will need to normatively reference
parts of HTML5
<anne> I note that i18n and people from Unicode have in fact
reviewed those parts of HTML5
MikeSmith: HTML5 will block them
Hixie notes that the character detection depends on other parts of
HTML
<anne> Character encoding detection was e.g. discussed last year
with the i18n WG
MikeSmith: I don't want to split hairs on exact status details, but
if our spec is not mature enough and people need to depend on parts
of it, it would be easier to facilitate those references if those
pieces of the spec were separate specifications and were moved along
on a faster track.
Hixie: it depends on the rest of the language.
... So the character encoding determination section does it looks
for a <meta> element with a charset attribute
... While doing that it tries to skip comments and other syntactic
things.
Anne: there's hookbacks from the parser
Hixie: once you.. whole thing about scripts
... the idea that we have a charset attribute in HTML5. That's new.
We didn't have that on HTML4.
... we don't have agreement on that. It might change.
... until that gets accepted, then we can't move it forward.
Anne: Those other people are reviewing the draft. We had comments
from unicode and i18n last year.
MikeSmith: But we aren't communicating the changes.
... They aren't aware of our changes to that.
Anne: I don't entirely agree. When we publish a new working draft,
we list the changes.
Mike: I've been trying to do that, but the number of changes is huge
... It's good that we are improving the spec, but it's a large
number of changes. But expecting that the ppl outside the group will
be able to understand all those changes ...
Hixie: experience with CSSWG is that splitting the spec doesn't
work.
Hsivonen: I'd like to .. marcos about .disagree with parsing
algorithm
... I don't think author should have to figure out what kind of
crazy stuff can be done.
... I think we should say if you do this, it will work. Don't need
to explain all the other crazy stuff that could be done that would
also work
... If you want a strict parser the right way tot do it is to take
an existing one and register an error handler that the only thing it
does is throw an exception
... that gives you a strict parser
<DanC_lap> (bummer... the pointer to encoding tests from
http://lists.w3.org/Archives/Public/public-html/2007JanMar/0054.
html has gone 404...)
http://lists.w3.org/Archives/Public/public-html/2007JanMar/0054.html
<pimpbot> Title: Re: brainstorming: test cases, issues, goals, etc.
from James Graham on 2007-03-14 (public-html@w3.org from January to
March 2007) (at lists.w3.org)
Hsivonen: I think the discussion about stability and referencing,
might point out a problem in the Process.
... It's not only HTML5 that has this problem.
<DanC_lap> CURIEs
<karl>
http://www.w3.org/QA/2008/10/normative-references-conformance
http://www.w3.org/QA/2008/10/normative-references-conformance
<pimpbot> Title: Normative References to Moving Targets are
Dangerous - W3C Q Weblog (at www.w3.org)
Hsivonen: E.g. RDFa copy-pasted CURIEs
... So there's an instance of this problem in a case where the specs
are much more closer to each other.
... Then SVG 1.2 Tiny can't reference CSS2.1 and instead are
referencing CSS2.0 even though every implementor knows nobody should
be looking at CSS2.0 and should look at CSS2.1 instead
... Does it help anyone for the process to force these things?
<smedero> DanC_lap: I think you're looking for this:
http://html5lib.googlecode.com/svn/trunk/testdata/encoding/
http://html5lib.googlecode.com/svn/trunk/testdata/encoding/
<pimpbot> Title: Revision 1229: /trunk/testdata/encoding (at
html5lib.googlecode.com)
Hsivonen: In HTML5, if it's going to change in HTML5, we want
webapps to match that.
... The point is for the two to match, so you use the same code path
<shepazu> hsivonen, the parts of the CSS spec SVG references hasn't
changed between 2.0 and 2.1
<smedero> DanC_lap, (well and then the scripts that deal with
that... which have moved here:
http://html5lib.googlecode.com/svn/trunk/python/tests/)
http://html5lib.googlecode.com/svn/trunk/python/tests/)
<pimpbot> Title: Revision 1229: /trunk/python/tests (at
html5lib.googlecode.com)
Hsivonen: Even if webapps goes to REC, if the HTML5 encoding
detection changes then webapps wants to match that.
<timeless> /ignore #tpchat join
<DanC_lap> (smedero, I only see 4 tests there. is that how many
should be there?)
Hsivonen: If we're working around a problem in the process that
other WGs are facing to and the solutions aren't really helping with
implementing the specs, perhaps instead of working around the
problem we should solve the problem
Tim: The process is a tool, it's ours to use. The fact that there's
a two-step difference in level between something that you can
reference and something in your own level is unusual in the
standards world and
... ISO and IETF you could only reference a standard
... Or maybe something at the same level
<karl> That it is not the W3C Process which gives this requirement
Tim: Being able to reference something less mature is regarded as a
bug.
<karl> This is the transition document
Tim: There's a good reason. If you write code for a technology and
it meets the standard
... And then the less mature spec is changed, then your software
doesn't match the spec any more and stuff breaks.
<karl> Evidence that dependencies with other groups met (or not)
<karl> # Does this specification have any normative references to
W3C specifications that are not yet Proposed Recommendations? Note:
In general, documents do not advance to Recommendation with
normative references to W3C specifications that are not yet
Recommendations.
<karl> # Is there evidence that additional dependencies related to
implementation have been satisfied?
<karl> --
http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3
.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/t
ransitions.xsl&docstatus=pr-tr
http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=pr-tr
<pimpbot> Title: How to Organize a Recommendation Track Transition
(at www.w3.org)
<smedero> DanC_lap: comparing against the 1.0 branch, yes.
Tim: We could change the process, but that will only help us create
broken software.
... With something like this, where we have another solution --
which is to pull out this bit of technology and make it separate
spec
... It's got the ability to be stabilized well in advance, then you
can have an appropriate ordering between your specs
... And it'll all work. You don't need a cycle.
... It's when you have a cycle that you need to have this slack
between the two specs.
Noah: Picking up in part on what Tim said.
<Zakim> noah, you wanted to wonder if we're just disagreeing on what
should be normative
<DanC_lap> (interesting point, karl; ht, I don't find any
constraints on dependencies in the process document. As I recall
from discussions with Ian, we rely on reviewers to complain about
pointers to stuff that's not sufficiently mature.)
Tim: about language tutorials
Noah: I wanted to add up all the parts that everybody agreed on and
not
... part I heard agreement on is that the spec should go on the say
you're writing it. Maybe you should re-title it, but otherwise no
issue
... I think I heard everybody agree that there should be documents
that help novices learn to write HTML
<pimpbot> planet: Chris Wilson on Internet Explorer 8 and the W3C
HTML Working Group <11http://standardssuck.org/chris>
http://standardssuck.org/chris
Noah: I think I heard agreement that it should discourage improperly
nested tags
<Al> .. if there could be reference to a function call, we could
freeze the interface to that function call and there is not breakage
if the body of the function is definitized later
Noah: The part I didn't hear agreement on is .. defining a clean
language with no errors
Hixie: That already exists. I sent a link to it in IRC.
<ht> DanC, the (in)famous '2 steps back' rule comes from the XML
Plenary in San Jose in 1998 (?). Consistent with what you said, it's
a guideline -- other things being equal, the presumption is that 2
or less is OK, more than that is not, but it's only a presumption
Noah: Question is should it be a normative document
Hixie: It is. It's section 8.?
Noah: It seems to me there's a question whether you advertise to the
community conforming HTML5 that is a big deal
... The way XML is a big deal
... If you decide you don't want to do that the world becomes very
simple. You're just writing non-normative guides. Can write lots of
them. They may not be very consistent.
... If you do write this section then the question is how can you
write such that it is understandable for mere mortals
<Al> ht, what Chaals learned on researching this recently is that
any down-level reference will bring close scrutiny and demand for
"three good reasons". I don't presently think a two-level
presumption is safe.
Noah: My personal preference is that you do create such a spec. I
don't have a reason, just abstract intuition
... I'm curious if people ...
... The optional things are,
... Do you write one or more non-normative informative guides to
help authors write stuff.
... I heard that in general they should encourage the creation of
clean content
... The more controversial option is should you write a normative
and precise document that specifies only the clean language and its
semantics.
<pimpbot> Title: HTML 5 (at www.whatwg.org)
<Hixie> Philip: ^ see timbl's comment
Noah: I'm not using the term authoring guide, because it's not how I
think of it, but it seems that's what you're thinking of
Mike: One issue is the authoring language spec for HTML5
<Hixie> Philip: if you could set that up I can re-gen the spec
straight away
<Philip> Hixie, what would the page title be?
Mike: The other issue is the concern Dan brought up , of other parts
of the spec that don't relate to authoring conformance but refer to
browser implementation details
<Hixie> Philip, first h2, i guess
Mike: for which there is rationale to have separate specs
<anne> Philip, section title of 8.1 — HTML5
Mike: we do want to talk about both those things
... I want to go through the queue.
<Zakim> ht, you wanted to point out that there are two solutions to
Henri's point within the process
Henry passes
<Philip> Hixie, some pages don't start on an <h2>, but I suppose I
could just use the first heading
<Zakim> karl, you wanted to mention that it is not part of W3C
process
<Zakim> Al, you wanted to say that Henri's point about managing
dependencies of concurrently progressing modules shows that Henry's
emphasis on declarative spec introduces problems.
<Philip> Hixie, (though it'll be a bit misleading on pages that have
multiple significant sections)
Karl: The discussion about normative references was not about
process document requirements, but transition document
<zcorpan> Philip: "8 The HTML syntax - HTML 5"
Al: I'd like to +1 what Tim was saying earlier, that there's the
contract involves two levels of strictness
... The contract includes the ideas that the consumer has the
support of a browser which processes strings of several varieties
<Hixie> Philip: yeah, but it'll be better than nothing
Al: While the author gets instructed in how to be strict in what
they emit
<gsnedders> Philip: Why can't we just have one major section per
doc?
Al: This is what makes the Web interoperate today. Is that we have
both statements.
... This is what the HTML5 spec tends to do. I want to say that's
valuable.
<anne> Philip, alternatively you give us an API so we can make up a
title per page and such :)
Al: That's how you make large systems interoperate. You have some
space between these two.
Hixie: I'd like to encourage people that want a document that
defines a "clean language" to read section 8.1
... and see if that's what they mean.
<MikeSmith> http://www.w3.org/html/wg/html5/#semantics
http://www.w3.org/html/wg/html5/#semantics
<pimpbot> Title: HTML 5 (at www.w3.org)
Hixie: I'm not sure that document is useful to authors. Because it
wouldn't be something they'd understand.
... And that's where a non-normative authoring guide comes in.
... I don't think that splitting sections out of the spec to keep
them more stable will work.
<MikeSmith> http://www.w3.org/html/wg/html5/#the-a-element
http://www.w3.org/html/wg/html5/#the-a-element
<pimpbot> Title: HTML 5 (at www.w3.org)
<noah> What I have in mind is a document would be a document that
would include the syntax, as well as the normative definitions of
what a table is, a paragraph, etc. Ideally, I would then NOT repeat
those semantics in the "larger" user agent spec.; I would have the
user agent spec refer to the language spec for that.
Hixie: The problem isn't that HTML5 isn't stable,the problem is that
the part that changes is the part that we want to split out
... I don't have a solution to that.
Mike: I'd like to talk about specifics.
... We seem to have consensus that we should have an authoring spec.
... Several parts of the spec talk about authoring conformance
criteria
<marcos> +q
<DanC_lap> "8.1 Writing HTML documents"
Mike: There's 8.1
... But there are also parts on semantics
<Zakim> ht, you wanted to suggest we look at the URI issue
Mike: We should go to that part of the spec and see if it has what
we think needs to be there
Henry: I'd like to back you up and move on to another issue..
modularization
... IA different spin on it. It really is a matter of "spheres of
influence"
... That's the URI/URL parsing section
... It did feel to the TAG at least at first blush that this looked
like
... A misjudgement wrt serving the web community
... That people need to have a consistent picture of identifiers for
web resources
... It's not up to the HTMLWG to decide what that string looks like
... At the very least the IETF has a stake in this. They own the
relevant specs
... I'd like to see if there's a willingness to look at refactoring
that discussion at least.
Lachlan: Wrt splitting the spec, I'm a bit curious about who exactly
we're targetting this other spec for.
... there are a whole range of .. that use HTML5.
... Each of those need different overlapping sections of the spec.
<anne> XMLHttpRequest currently refers to the HTML5 URL concept...
<Lachy> Authors, markup generators, authoring tools, validators,
generic consumer tools, browsers.
<Lachy> Each needs a different set of overlapping sections of the
spec.
<Lachy> Authors: semantics, conforming syntax
<Lachy> authoring tools: semantics, conforming syntax, parsing,
sometimes rendering
<Lachy> validators: parsing
<Lachy> consumer tools: parsing, DOM/tree
<Lachy> search engines: semantics, parsing
<Lachy> browsers: semantics, parsing, rendering
Lachlan summarizes his notes above
<hsivonen> validators need a lot more than parsing
Lachlan: The problem is who exactly are we trying to target with
this split spec, given that there are so many overlapping needs?
<marcos> -q
Marcos: Lachlan said my point
<CynthiaShelly> @MikeSmith: are the "semantics sections" sections 3
and 4?
<pimpbot> cshelly: Huh?
Hsivonen: On URIs what the spec does it takes the IRI RFC and
defines the delta of what you need on top of the RFC.
?: It states what rules you need to change in the RFC to parse
<karl> http://www.w3.org/TR/qaframe-spec/#implement-principle
http://www.w3.org/TR/qaframe-spec/#implement-principle
<pimpbot> Title: QA Framework: Specification Guidelines (at
www.w3.org)
Henry: Why do you need a delta at all JR:
Hsivonen: Suppose I'm writing a browser. There's existing content
out there that was written before the IRI spec
... If you have a form and you input characters, and the you submit
that form using GET.
<MikeSmith> cshelly, basically just section 3
<Philip>
http://www.whatwg.org/specs/web-apps/current-work/multipage/synt
ax.html
http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html
<pimpbot> Title: 8 The HTML syntax HTML 5 (at www.whatwg.org)
<MikeSmith> cshelly, plus the first part of section 8
Hsivonen: You encode the unicode characters in the form fields to
bytes using the character encoding that the document itself was
labelled as when it was parsed.
<Philip> MikeSmith, you still need to fix pimpbot entity handling
:-p
<Philip> s//'s/
Hsivonen: And this is required for backwards compatibility,
otherwise servers will receive form submission that they didn't
expect and they will break.
<Hixie> woohoo, nice work Philip
Hsivonen: there's another eq that flows from this one. If you have
on an html page a URI that has a query string
<karl> http://www.w3.org/TR/spec-variability/#spec-cat-cop
http://www.w3.org/TR/spec-variability/#spec-cat-cop
<Hixie> timbl_, multipage spec version is updated to have better
<title>s now
hsivonen: You are linking to a form submission such as the one I
describe
<pimpbot> Title: Variability in Specifications (at www.w3.org)
<MikeSmith> Philip, patches welcome
<timbl_> If the form submission has non-ascii then you can't encode
it a la IRI encoding.
Hsivonen: The kind of string path's in href, if it has non-ascii in
it to get an ascii-only URI you need to use the encoding of the
document to encode those characters into bytes and then do the %
encoding on those bytes and then give the result to the HTTP library
<timbl_> You have to use the encoding which the document itself was
parsed with.
<anne> timbl_, it would be URI percent encoded afaict
Hsivonen: Sites are depending on this behavior. So browsers are.
<gsnedders>
http://www.whatwg.org/specs/web-apps/current-work/multipage/infr
astructure.html#resolve-a-url
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#resolve-a-url
<pimpbot> Title: 2 Common infrastructure HTML 5 (at www.whatwg.org)
Julian: : We all know that and we are in total agreement that the
spec needs to do that.
<gsnedders> That defines what hsivonen is summarizing
Hsivonen: So we've established that browsers need to do that.
... I'm writing something else. The image .. of validator.nu
... It's not a browser, but it deals with content browser deal with
... I can't implement the IRI and then find out later that it won't
work
... The RFC doesn't give me a spec for that
... The .. library that implements 6 different profiles for IRIs,but
doesn't implement the most common profile -- href links in HTML
<MikeSmith> ?
Hsivonen: if IETF isn't providing then, then I want to have a spec
that I can write to and not have to reverse-engineer anything.
... I want to use the reverse-engineering that Hixie did
... If that's not in the IETF, then it should be somewhere. HTML5
Mike: ... whether we should do that in a normative W3C REC
... we need to come back to what specifically we need to get to
<Julian_Reschke> all the stuff that Henri said is correct, except
the conclusion that it needs to be done the was it is done right now
<ht> Henri, Stipulate that the RFC is broken, why not fix the RFC,
instead of starting a turf war?
TV: The meta issue is that there's an RFC for IRIs and browsers
violate that IRI. Meta-issue is do we need to codify that violation
fo the IRI spec?
Mike: So maybe we need to clarify that this is a big public issue
that is open
<hsivonen> ht, the IETF wasn't cooperative when doing that was
suggested
TV: The meta-issue here isn't about bits and bytes, but about
whether this WG should be codifying existing violations of existing
RFCs.
Tim: ... go into another RFC.
<ht> Henri, did you raise it through the W3C-IETF liaison call?
Murray: modularization, goes to IETF
LarryMasinter: It's not clear to me that forms submission properly
with in the domain of HTML to define how HTML define form submission
... the IRI spec doesn't say how HTML does form submission
... ... URI specification...
Larry: It may be that if you see a URI in a form and you have query
string that you take that URI and then you transform that URI and
then you do the submit on that URI
Larry: It's not changing the IRI spec. It's doing some weird
processing before.
... It might solve the issue to rewrite the spec so to define this
behavior as pre-processing the IRI string.
... ... and maybe submitting this back to IETF would also be a good
idea.
... back to authoring spec.
... I think rather than thinking about browsers and authors, since
most content today is created by other software.
... You should use terms producers and consumers
<ht> HST likes Larry's suggestion, because it's consistent with the
fact that IRIs are generic, but the query-string format we're
talking about is 'http:' specific, I believe
Larry: I think that will help with the discussion.
<DanC_lap> (I disagree. authors are humans that need nice
successive-elaboration documents.)
<karl> what Larry just said is part of the list of class of products
- http://www.w3.org/TR/spec-variability/#spec-cat-cop
http://www.w3.org/TR/spec-variability/#spec-cat-cop
<pimpbot> Title: Variability in Specifications (at www.w3.org)
Hixie: Before IRI section was drafted, I joined the relevant IETF
group and asked if I could create a spec there
... they told me they weren't interested in doing this.
... So then I put this section into HTML5.
<anne> interested parties weren't interested, nice
Hixie: If anyone wants to edit that section, I'm happy to pull it
out into a separate spec.
Tim: ...
... My understanding was that if you want what henri said.
... A string with non-ascii characters and then encodes it ...
<DanC_lap> (the algorithm takes not just a URI reference, but also
the encoding fo of the document it came from.)
Tim: That URI string will have % in it, but if you interpret it as
IRI ..
... So it would be inappropriate to hand it over to IRI
Anne: Isn't IRI a superset of URI?
Henry: Suppose your doc is encoded in 1252
... Larry's suggestion is that the HTML spec says take that string,
and re-encode it in unicode and the it is a URI and you can apply
the escaping algorithm to it
Hsivonen: You get the wrong URI if you do that.
Mike talks about lunch and AC meetings
Mike: we have a time constraint
<DanC_lap> (Julian, we were close? close to what? is it something
you could write on a line or two?)
Mike: Let's move beyond the specifics and talk about how we can move
forward , what can we do after today to continue the discussion.
... If everybody can agree to hang around for an extra 15 min that
gives us time to get through the queue and try to talk about moving
forward
<Zakim> DanC_lap, you wanted to note that after review of the URL
stuff, I found it acceptable, but I haven't "sold" others. the IETF
has right of review, and I think we have an
<Julian_Reschke> for the record: Larry's proposal does work; we just
need to use ASCII to encode the characters that we don't want the
IRI processing to map the wrong way
<MikeSmith> q/
DanC: So the URL stuff, I figured out what it was saying and
harumphed over it a lot and made my peace with it
... But as go around to other people, the trick is.. since this
deals with URI and IRI stuff
... It's good to get consensus with them
... They say it would be ok if you rewrite it
... With the technical design, I see no way out of this local
minimum
... People that are interested to take a whack at rewriting
<Zakim> noah, you wanted to ask whether the issue is the use of the
term URI or IRI for something that doesn't conform to the RFCs
Noah: This may actually relate to paper consensus / durable
consensus
... I may be misinformed, but I believe an issue is in the draft
spec it refers to things as URIs that are not URIs, that are the
input to this process or the output
... If there are such things, and it contributes to stable
discussion, to change that. It would be nice to have convenient
terms
<Al> content negotiation for href; can we do server sniffing as a
way to serve the
Noah: but whatever. Call it an HTML URI. Write your spec that way
<Al> .. serve the 'right' URI transcription as per IRI RFC?
Noah: Then in the informal guides you can call it whatever you want,
URIs, URLs
... I think being strict with the terminology will help
Hixie: the term that's used in the spec is URL, but I agree it's a
conflict. The reason we used that
... even when we used URI or IRI, a lot of people said what the
heck's a URI, or what's a IRI
... It was a compromise I came to by balancing the people who would
be confused about this term vs that term
... The actual section, if you give it a valid URI or IRI it gives
you a valid URI or IRI.
... the only thing it defines is how you handle invalid URIs and
IRIs
Hsivonen: What he said isn't exactly correct. It's correct if your
document is encoded in UTF-8 or doesn't have query strings
... I don't think it's a good idea to give an ugly name.
Noah: no, come up with a nice name
Tim: I'm happy saying at the top of the document we redefine URL as
used in this specification.
Philippe: We do this in a lot of specs that use URI where they
really reference IRI.
Mike: So at a high level we're all here because we want to produce a
W3C REC for HTML5
<Julian_Reschke> problem: there's also an important distinction
between "URL" and "valid URL".
argument about whether TAG can prevent this, or whether it's only
the Director
Mike: Anyway, W3C can block this if there are parts of the spec that
conflict with Web Architecture and they're not ok with that.
<anne> hsivonen, that's not exactly correct, UTF-16 is also fine
Mike: There are parts of the spec that it wouldn't be possible to
move forward unless we work through these issues.
<DanC_lap> (this seems like a negative way of saying: a goal of W3C
is to get consensus on specs)
<hsivonen> anne, true
Mike: We could wait until CR, or we could try to resolve these
issues now.
<noah> I don't think anyone prefers to defer the process of working
through issues.
Mike: I've gotten a list of things Roy Fielding plans to formally
object to
... It is to the benefit of all of us to try to get resolution
sooner rather than later.
<pimpbot> Title: HTML WG -- 23 Oct 2008 (at www.w3.org)
Tim: Whether Roy or others are on the TAG has got nothing to do with
how much we should listen to their opinions
<pimpbot> Title: HTML WG -- 23 Oct 2008 (at www.w3.org)
<smedero> ahh
<smedero> olivier: thanks
Tim: .. nor should you look at this as what should we do to do the
least procedurally to get this to rec. You want to look at what's
going to make this the best spec.
Larry: Let's move away from thinking about personalities
... And consider whether there are communities whose needs are not
met by this specification.
... maybe the HTML5 spec doesn't meet the need of the community that
builds web servers
... I'm more representative of the parts of my company that make
authoring tools
... ...
<DanC_lap> (I think "needs" is a strong terms; there are communities
whose _wants_ are not satisfied; some of them get dissuaded by
discussion tactics before they finish learning whether their actual
needs are met.)
<Hixie> s/more/a poor/, i think
Larry: I look at it from the pov that there are some communities
that have a lot less time to spend on this, but have requirements
that might not be addressed as well
<Hixie> but i could be wrong
Mike apologizes for wording
<gsnedders> Hixie: You're right
Mike: .. I'm really glad Roy is paying attention
... This work has been going on for 4 years
... For a lot of that time people weren't paying attention
... Now they are
<DanC_lap> TimBL notes development of HTML goes back 18 years and 6
months
Mike: I think it's good that we have more people paying attention to
this work now and we ant to make it possible for them to facilitate
the discussion going forward.
... So again, where are we going to continue this discussion? We
have public-html
... but only members can post to it
<DanC_lap> (only members of the wg can post to public-html? I don't
think that's so
<DanC_lap> )
TV proposes copying public-html and www-tag
<gsnedders> DanC_lap: anyone can, but it's covered by the patent
policy, so it's kinda non-obvious
<Hixie> i just wanted to mention that i work with people from the
apache foundation, and that google also writes web servers, and i
try my best to address their needs and desires
<Hixie> but no need to say that out loud i guess
Tim: modularization or URI stuff?
Henry: There is a w3c IETF liaison call
... Query strings in their particular formulation as they're used in
HTML ...
Danc: Henry please, this is a technical question, right?
Mike: I would like we don't leave today with hanging on where to
continue discussion?
... How can we move forward with discussion with TAG with these
issues?
... Specific issues are authoring spec, and modularization --
splitting pieces out, and whether we should have normative
definitions for some stuff like URI
<anne> email message to uri@w3.org from Hixie:
http://lists.w3.org/Archives/Public/uri/2008Jun/0002.html
http://lists.w3.org/Archives/Public/uri/2008Jun/0002.html
<pimpbot> Title: Error handling in URIs from Ian Hickson on
2008-06-24 (uri@w3.org from June 2008) (at lists.w3.org)
<ht> HST was going to ask if there was agreement that the core of
Henri Sivonen's summary only applies to http: URIs
MM: I would've thought it'd be up to the WG to discuss what they've
just heard from TAG
... And sort out what they think they've heard, and what they think
they should do about it
... and then tell the tag
<DanC_lap> fantasai, meet Murray Maloney. Murray, fantasai.
MM: and then the TAG can say that's great
TV wants to CC www-tag
MM: Do you want to follow the whole discussion or just the
conclusion?
Mike: So action is on me to bring this back to HTMLWG and to
communicate back to TAG what we want to do about these issues.
MM: What are the other three issues we wanted to talk about?
<gsnedders> What email?
TV: They were listed in the email, we should talk on email
Mike lists the issues, someone please paste the email
Mike: I'll just repeat what I just said, action item is on Chris and
me to bring back to the group
... come to resolution on what we plan to do and communicate back to
the tag
Tim: I'm wondering from TAG pov whether we should also ...
<gsnedders> The email anne mentioned earlier that's member only and
therefore people like me can't actually see it?
Tim: from discussion last couple days, one thing that comes up often
when people see HTML5 spec for first time
<DanC_lap> ACTION: Mike lead HTML WG to response to TAG discussion
and report back to TAG [recorded in
http://www.w3.org/2008/10/23-html-wg-minutes.html#action01]
<trackbot> Created ACTION-77 - Lead HTML WG to response to TAG
discussion and report back to TAG [on Michael(tm) Smith - due
2008-10-30].
Tim: they look at the spec and they say that's not what I mean by a
spec.
... I wonder whether the TAG could write something to point out
there's two ways of doing this
... E.g. TAG's done work on versioning.
... ....
... If the HTML5 folks could say what we're making is one of these
and point to the TAG's writeup
... Would working at the meta-level be helpful. Maybe useful to IETF
and understanding HTML5 as opposed to language specs as
traditionally written
Mike: Maye a summary from the TAG perspective on what we discussed
today, that would be very helpful
TV: It looks like Tim signed up to write such a thing. :)
Tim: I'll nominally take an action item.
<scribe> ACTION: TimBL write up a description of the kind of spec
HTMLWG is writing for TAG [recorded in
http://www.w3.org/2008/10/23-html-wg-minutes.html#action02]
<trackbot> Sorry, couldn't find user - TimBL
BREAK FOR LUNCH!
yay
bye everyone
RRSAgent: make logs public
RRSAgent: make minutes
<pimpbot> Title: HTML WG -- 23 Oct 2008 (at www.w3.org)
<gsnedders> hiho
<timbl> ericp?
<karl> ac
<timbl> phenny, tell ericP Does your query pipeline system support
Sparql DESCRIBE ?
<gsnedders> Do we have a scribe?
<Lachy> I can
<Lachy> try
<timeless> ScribeNick: Lachy
Steven: I can find someone to say something about Forms
MikeSmith, The most significant change is the integration of web
forms 2 into current draft
<Steeeven> Forms=architectural consistency part
<Steeeven> there is a separate task force for that
<oedipus> no longer - expired in July 2008
Hixie: I'm still responding to feedback. Around start of sept, I
started merging HTML4 forms and WF2 changes into HTML5
going through old feedback since 2004
<myakura>
http://www.whatwg.org/specs/web-apps/current-work/multipage/form
s.html
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html
<pimpbot> Title: 4.10 Forms HTML 5 (at www.whatwg.org)
<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/Forms
http://esw.w3.org/topic/PF/XTech/HTML5/Forms
<pimpbot> Title: PF/XTech/HTML5/Forms - ESW Wiki (at esw.w3.org)
Hixie: Not everything made it through, e.g. repetition model
MikeSmith: so that's kind of the last missing semantics that was
missing?
Hixie: Aria is the other
MikeSmith: We need to prepare a summary of what's changed
<gsnedders> Lachy: colons and ...
MikeSmith: Doesn't need to be as detailed as the last time
<pimpbot> Title: HTML WG -- 23 Oct 2008 (at www.w3.org)
MikeSmith: We need something a little less detailed.
... anne put together a bulleted list of the changes, but we need
something a bit between that and the detailed change list
... The forms stuff was integrated based on the WG survey
... We had forms TF for a year. The TF did not do anything
<oedipus> meeting: HTML face2face TPAC 2008 Day 1
Anybody else have any questions or concerns?
<karl> Meeting: HTML WG - TPAC - October 2008
<DanC_lap> (anybody got a pointer to that msg?)
<pimpbot> Title: HTML WG -- 23 Oct 2008 (at www.w3.org)
Nick_Van_den_Bleeken: Someone sent an email with some question
regarding the integration of forms into html5 was sent to the forms
tf list, but no-one responded
MikeSmith: Please find a pointer to that message
... We also asked for feedback on the WF2 proposal from the Forms
WG, but they didn't provide any
<anne> might be
http://lists.w3.org/Archives/Public/public-forms-tf/2008Jun/0000
.html
http://lists.w3.org/Archives/Public/public-forms-tf/2008Jun/0000.html
<pimpbot> Title: Re: Status update from Keith Wells on 2008-06-02
(public-forms-tf@w3.org from June 2008) (at lists.w3.org)
Charlie Wiecha: [talking about Ubiquity XForms on Google code]
<oedipus> my comments to the HTML WG on the forms survey & forms in
general:
http://esw.w3.org/topic/GregoryRosmaita/FormsFeedback2008-07
http://esw.w3.org/topic/GregoryRosmaita/FormsFeedback2008-07
<anne> http://code.google.com/p/ubiquity-xforms/
http://code.google.com/p/ubiquity-xforms/
<pimpbot> Title: GregoryRosmaita/FormsFeedback2008-07 - ESW Wiki (at
esw.w3.org)
<pimpbot> Title: ubiquity-xforms - Google Code (at code.google.com)
Charlie: The main thing is to take some of the attributes on the
data model and project those up to the controls.
Kai Scheppe: Is the entire WF2 spec taken into HTML5?
Hixie: About half made it in. Some sections dropped: Repetition
model, forms pre-seeding, XML serialisation mode,
... a few other minor issues as well
... mostly in response to implementer feedback
<Hixie> (or implementor apathy)
<anne> http://www.whatwg.org/specs/web-apps/current-work/notes
has an informative list at the end of features from WF2 not included
in the spec
http://www.whatwg.org/specs/web-apps/current-work/notes
MikeSmith: we have public-html-comments@w3.org
... anyone can post to that
... public-html@w3.org is intended for the WG, but anyone can still
post to it
<DanC_lap> comments archive:
http://lists.w3.org/Archives/Public/public-html-comments/
http://lists.w3.org/Archives/Public/public-html-comments/
<pimpbot> Title: public-html-comments@w3.org Mail Archives (at
lists.w3.org)
MikeSmith: The other thing is that the group is open to anyone
... Anyone can be an Invited Expert
<CharlieWiecha> Link to Forms-A internal working document on
attribute-oriented forms notation, i.e. non-MVC authoring:
http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/streamlin
ed/index-all.html
http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/streamlined/index-all.html
MikeSmith: Need to agree to the patent policy
<pimpbot> Title: Forms-A: Streamlined Expression of Data-Rich Web
Applications (at www.w3.org)
<DanC_lap> (for reference, this is a patent policy FAQ:
http://www.w3.org/2003/12/22-pp-faq.html#lists Can
non-participants subscribe to a mailing list of a Working Group
under the Patent Policy? )
http://www.w3.org/2003/12/22-pp-faq.html#lists
<pimpbot> Title: Frequently Asked Questions (FAQ) about the W3C
Patent Policy (at www.w3.org)
<PIon> + MathML would be happy to know what happened in this
morning's discussion?
MikeSmith: Any other issues?
<nick> Last e-mail from Keith
http://lists.w3.org/Archives/Public/public-forms-tf/2008Jun/0000
.html
http://lists.w3.org/Archives/Public/public-forms-tf/2008Jun/0000.html
<pimpbot> Title: Re: Status update from Keith Wells on 2008-06-02
(public-forms-tf@w3.org from June 2008) (at lists.w3.org)
Neil Soiffer: We had a discussion about questions we had
<nick> e-mail I sent on 22th of May
http://lists.w3.org/Archives/Public/public-forms-tf/2008May/0003
.html
http://lists.w3.org/Archives/Public/public-forms-tf/2008May/0003.html
<pimpbot> Title: Re: Status update from Nick_Van_den_Bleeken on
2008-05-22 (public-forms-tf@w3.org from May 2008) (at lists.w3.org)
Neil: The first issue is namespaces
... If you have a namespace attribute, what happens to it in the
DOM?
Hixie: This may change, but the current proposal is that if you have
MathML in the document, the xmlns attribute will be in the DOM, but
must have MathML namespace
... the DOM nodes will be in MathML namespace
<CharlieWiecha> Link to Forms-A document with controls in the XForms
namespace:
http://ubiquity-xforms.googlecode.com/svn/branches/webforms-a/_s
amples/Loan/xforms-webforms-a-loan.html
http://ubiquity-xforms.googlecode.com/svn/branches/webforms-a/_samples/Loan/xforms-webforms-a-loan.html
Neil: Often people put in private attributes
<CharlieWiecha> The above form should load (FF3 at least) directly
from SVN
Hixie: The non-mathml stuff will appear in no namespace, non-mathml
xmlns declarations will be ignored
... There are constraints with what we can do with namespaces.
<CharlieWiecha> Form in HTML namespace (though this one seems to
have trouble loading, pls use as syntax example for now):
http://ubiquity-xforms.googlecode.com/svn/branches/webforms-a/_s
amples/Loan/webforms-a-loan.html
http://ubiquity-xforms.googlecode.com/svn/branches/webforms-a/_samples/Loan/webforms-a-loan.html
<DanC_lap> <math> <special:stuff /> </math> <-- special:stuff goes
in the mathml namespace, if I'm following
Hixie: main aim is to support MathML, not other proprietary things
<gsnedders> DanC_lap: correct
Neil: There is a problem related to Open Math
<gsnedders> DanC_lap: with a localName of special:stuff
hsivonen: open math is not supported
<DanC_lap> <math> <mx special:attr="abc"> </math> <-- special:attr
goes in no namespace, if I'm following
<gsnedders> DanC_lap: Again, correct
Neil: The issue is not the browser support, but the ability to
copy-paste and maintain the semantics
hsivonen: non-mathml content will end up in no namespace
<anne>
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree
-construction.html#parsing-main-inforeign has details
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inforeign
<pimpbot> Title: 8.2.5 Tree construction HTML 5 (at www.whatwg.org)
Hixie: Because of the constraints, if we wanted to support open
math, we would have to explicitly include that in the spec
<DanC_lap> hmm... that last example with
presentation/semantics/content ... I'd like to see an example. I
don't think I can cook one up
Hixie: The line was drawn at HTML, MathML and SVG
Neil: People want to style the text they have inside <mtext>
<anne> hsivonen, it seems "semantics" is not supported
Neil: What are the rules inside of <mtext> and you encounter an HTML
element, when does it revert to MathML ns?
<anne> hsivonen, that is, what you're saying about semantics is not
what happens
<anne> hsivonen, it's true for <mtext> though
Hixie: <mglyph> will be in the MathML ns, other things will be
assumed to be HTML
... [other technical details]
<hsivonen> anne, sorry. it's <semantics-xml>
Neil: there is legacy MathML designed to work in IE with plugin
... I sent an email about a year ago, what's the status of dealing
with this legacy?
<anne> hsivonen, doesn't change anything unless I'm missing
something in the parsing algorithm
Hixie: if there are no prefixes, it should just work
Neil: IE requires the prefix
hsivonen: That doesn't seem to match my testing with MathPlayer
Neil: The way IE binds it is when the namespace is seen, invoke the
activex control
<oedipus> http://www.w3.org/Math/DOM/
http://www.w3.org/Math/DOM/
<pimpbot> Title: The MathML DOM Bindings (at www.w3.org)
<anne> timeless, http://www.dessci.com/getmp
http://www.dessci.com/getmp
<pimpbot> Title: MathPlayer: Download and Installation (at
www.dessci.com)
Neil: [saying the prefix is needed for IE]
... There are real websites that have used prefixes
Hixie: We could explicitly support it, but it'd be weird
Neil: We need to warn content sites that prefixes will go away in
the future
MikeSmith: We have time for SVG WG tomorrow
... you're welcome to be there for that
Neil: Everything else looks great
HarryHalpin: GRDDL WG
... People are happy with the ability to get the browsers to
implement a singular DOM across real world HTML
... From the perspective of GRDDL, the issues are related
... The fundamental problem is that when the WGs were chartered,
HTML5 wasn't on our radar
... We designed with compat with XHTML
<myakura> http://www.w3.org/TR/grddl
http://www.w3.org/TR/grddl
<pimpbot> Title: Gleaning Resource Descriptions from Dialects of
Languages (GRDDL) (at www.w3.org)
<pimpbot> Title: Google (at google.com)
<oedipus> http://www.w3.org/2001/sw/grddl-wg/
http://www.w3.org/2001/sw/grddl-wg/
Harry: We want to figure out how our technology remain compatible
with HTML?
<pimpbot> Title: W3C GRDDL Working Group (at www.w3.org)
<oedipus> http://www.w3.org/TR/grddl-primer/
http://www.w3.org/TR/grddl-primer/
<pimpbot> Title: GRDDL Primer (at www.w3.org)
Harry: Seeing mild uptake with Drupal
<oedipus> http://www.w3.org/TR/grddl-tests/
http://www.w3.org/TR/grddl-tests/
<pimpbot> Title: GRDDL Test Cases (at www.w3.org)
Harry: The first thing to talk about is <link rel="">
<oedipus> http://www.w3.org/2007/08/grddl/
http://www.w3.org/2007/08/grddl/
<pimpbot> Title: W3C GRDDL service (at www.w3.org)
Harry: GRDDL uses it. Takes a DOM, gives you a graph
... Also a concern of POWDER WG
... If you're a new WG, and want to have something like a
stylesheet, we want to know how
... the problems are with the values that are allowed in the rel
attr
<DanC_lap> (since we're in france, we shouldn't treat "bis" as some
secret code. it's french for 2nd, yes?)
Harry: We need a rel value registry
<DanC_lap> http://www.w3.org/html/wg/tracker/issues/27
http://www.w3.org/html/wg/tracker/issues/27
<pimpbot> Title: ISSUE-27 - HTML Issue Tracking Tracker (at
www.w3.org)
<oedipus>
http://esw.w3.org/topic/HTML/AbbrAndInitialisms#head-2df84342c22
a995e35980b4adb3b3573040f8c2d
http://esw.w3.org/topic/HTML/AbbrAndInitialisms#head-2df84342c22a995e35980b4adb3b3573040f8c2d
<pimpbot> Title: HTML/AbbrAndInitialisms - ESW Wiki (at esw.w3.org)
Harry: Could try to combine the list for HTML and Atom and other
specs
<DanC_lap> bummer... tracker doesn't use the issue name for the
title. it's rel-ownership @rel value ownership, registry
consideration
<oedipus> proposed use of RDF-type resource for reuse site-wide for
abbreviated forms
<Hixie> DanC_lap: "bis" is a fancy way of saying "again", i believe
<Hixie> (in french)
hsivonen: the Atom, XHTML2 and HTML5 all have ways of using full
URIs as rel values, but they do it differently
<DanC_lap> ok
hsivonen: GRDDL can go the WHATWG wiki and document their rel values
<gsnedders> DanC_lap: second is deuxieme
hsivonen: You can use a full URI, but there are limitations that
tokens are compared case sensitively
PhilArcher: [Chair for POWDER] I talked with Mark Nottingham
<DanC_lap> (Bis, a musical term and a little-used Interlingua word
meaning "encore", "again", or "twice" --
http://en.wikipedia.org/wiki/BIS )
http://en.wikipedia.org/wiki/BIS
<pimpbot> Title: BIS - Wikipedia, the free encyclopedia (at
en.wikipedia.org)
Phil: The WHATWG wiki is one possible way. The IANA solution is
another
... Microformats has another
... Everyone does it differently. Can we have one
I don't think it should be one groups wiki, I don't think it should
be difficult to use
scribe: Need some sort of control over it
<Steeeven> RDFa allows a CURIE
<anne> From Murray Maloney:
http://xml.coverpages.org/maloneyRelationships.html
http://xml.coverpages.org/maloneyRelationships.html
<pimpbot> Title: Hypertext links in HTML (at xml.coverpages.org)
<oedipus> why not in w3.org space?
scribe: I believe that W3C would be willing to operate such a
registry
... If it is possible to come to consensus, then we could take it to
the appropriate people and move forward
<fantasai> ... it could be a wiki at w3.org
<fantasai> ... it would have to be in agreement with IANA / IETF
MikeSmith: We're not chartered as a WG to make binding decisions at
face to face meetings
... But we could discuss what would be the best way to proceed
Julian: The goal from Mark's draft is to unify the meanings of
relationship names
... Needs to be more formal than a wiki, but I'm not going to defend
IANA's registry
hsivonen: I'd be ok with sharing the short values with Atom
... with the caveat that I haven't reviewed the Atom values to check
for conflicts
... If you use a short name, then you compare it
ASCII-case-insensitively and try to get them on the same list in
Atom and HTML
<pimpbot> Title: XPointer Registry (at www.w3.org)
<smedero> DanC_lap: :-/
hsivonen: I can understand why w3.org is preferred over whatwg.org
<hhalpin> +1 on Henri's algorithm for comparison
<DanC_lap> xpointer registry. boo. hiss. I'm _still_ against
registries at W3C.
Philippe: Traditionally W3 have been against registrys, but we have
one
<Steeeven> +1 to DanC
Philippe: there's a process involving mailing some list and waiting
a couple of weeks
<Julian_Reschke> I don't care a lot where the registry lives, at
long as it is one, not just a Wiki.
Philippe: if no-one objects, it's yours
<Zakim> plh, you wanted to mention
http://www.w3.org/2005/04/xpointer-schemes/
http://www.w3.org/2005/04/xpointer-schemes/
<pimpbot> Title: XPointer Registry (at www.w3.org)
<oedipus> there should be one central place to which people can
turn, and w3.org is the most logical and shortest
<DanC_lap> issue-27: note also
http://www.w3.org/2005/04/xpointer-schemes/
http://www.w3.org/2005/04/xpointer-schemes/
<trackbot> ISSUE-27 @rel value ownership, registry consideration
notes added
<pimpbot> Title: XPointer Registry (at www.w3.org)
Harry: There's one registry to rule them all approach, or different
registries. We don't care too much as long as standards people know
where to go and who to ask to update it
... IANA might make it harder. If it's W3C, then I'm ok with a wiki,
or a human edited web page, with requests sent and responded to by
email
<gsnedders>
http://www.ietf.org/internet-drafts/draft-nottingham-http-link-h
eader-02.txt — Mark Nottingham's Link header draft (I don't think
there's been a link yet)
http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-02.txt
Julian_Reschke: One things is that there's already an IANA registry,
then if it can be used, we should
<DanC_lap> (ah. I wasn't sure whether it existed yet.
http://www.iana.org/assignments/link-relations/ )
http://www.iana.org/assignments/link-relations/
<pimpbot> Title: IANA | Atom Link Relations (at www.iana.org)
Julian_Reschke: XHTML2 puts CURIEs into the rel attribute, which
concerns me a lot
... We need to be careful with the question about whether a link
relation can be an IRI
... It gets tricky when you want to use it in the HTTP Link: header
... Can map IRIs to URIs, but transformation doesn't round trip
Murray: There's rel values as might be recognised by browsers. Next,
prev, TOC, etc.
<pimpbot> planet: Misdirection
<11http://intertwingly.net/blog/2008/10/23/Misdirection>
http://intertwingly.net/blog/2008/10/23/Misdirection
Murray: It seems to me that it would be useful for there to be a
list of all these that a commonly supported by browsers
... The second issue is rel values that are used by other types of
agents
<oedipus> murray, do you mean something like:
http://www.w3.org/1999/xhtml/vocab/
http://www.w3.org/1999/xhtml/vocab/
<pimpbot> Title: XHTML Vocabulary (at www.w3.org)
Murray: The way that HTML was designed early on is that the <head
profile=""> was meant to contain a list of URIs, which could be used
as the place to look for the rel value
... Used for GRDDL
... Use it to link to a profile document, look it up and find the
ones you want to operate on
<pimpbot> Title: HTML WG -- 23 Oct 2008 (at www.w3.org)
Murray: It's suboptimal because there could be conflicts among
multiple URIs
... Would be helpful to use a URI as rel value
... Maybe we should have a new attribute like rel-uri or something
to declare teh URI onthe element
<oedipus>
http://www.w3.org/TR/html401/struct/global.html#adef-profile
http://www.w3.org/TR/html401/struct/global.html#adef-profile
<pimpbot> Title: The global structure of an HTML document (at
www.w3.org)
<myakura> xhtml2 defines rel=profile if i remember correctly
Richard Ishida: I wanted to clarify that you can round trip between
IRIs and URIs, but not IDNs and URIs
<hhalpin> I think that adding new attributes unless absolutely
needed is a bad idea.
<oedipus> "This attribute specifies the location of one or more meta
data profiles, separated by white space. For future extensions, user
agents should consider the value to be a list even though this
specification only considers the first URI to be significant." (HTML
4.01)
Julian_Reschke: [example of a IRI that won't round trip]
... We would need to specify the comparison rules
... In general, the rule has been to do a plain string comparison
<hsivonen> anne, sorry, my MathML is rusty:
<semantics><annotation-xml>...
<anne> hsivonen, neither seems to be considered by HTML5 at this
point though, am I missing something?
Steven: We need to plan for a future where everything uses IRIs
<oedipus> myakura, @profile is currently not in the XHTML2 draft:
http://www.w3.org/MarkUp/2007/ED-xhtml2-20071024/attributes.html
http://www.w3.org/MarkUp/2007/ED-xhtml2-20071024/attributes.html
<pimpbot> Title: XHTML 2.0 - List of Attributes (at www.w3.org)
Phil Archer: I understand that HTML5 is happy with an absolute URI
being a rel value
Hixie: Yes
<myakura> oedipus, i meant the rel value "profile," not the
attribute
anne: I don't want to be able to write everything as a URI. e.g.
rel="stylesheet" shouldn't have an equivalent using a full URI
<gsnedders> This is how Atom works too, FWIW
Phil Archer: If you see a string that isn't a URI, it is taken as a
relative URI in the HTTP Link header draft
<DanC_lap> ("stylesheet" isn't registered at
http://www.iana.org/assignments/link-relations/ )
http://www.iana.org/assignments/link-relations/
<pimpbot> Title: IANA | Atom Link Relations (at www.iana.org)
<gsnedders> http://www.iana.org/assignments/relation/alternate
and alternate are identical @rel values in Atom
http://www.iana.org/assignments/relation/alternate
<Julian_Reschke> DanC: because currently it's atom only
scribe: We need a way to have a token that can be normalised, but be
short. URIs can be long
<anne> having a token registry is fine with me
<anne> e.g. the WHATWG wiki :)
<DanC_lap> (I was just clarifying, since I heard phil say "...
stylesheet, which is registered")
DanC_lap: I prefer one registry, but don't like the W3C for that
gsnedders: The only problem I can see with absolute URIs is using
current relations like "stylesheet" is that you can't express them
as absolute URIs without breaking backwards compatibility
<Julian_Reschke> See
http://tools.ietf.org/html/draft-nottingham-http-link-header-02#
section-4.1 for registrations for existing HTML link relations
http://tools.ietf.org/html/draft-nottingham-http-link-header-02#section-4.1
<pimpbot> Title: draft-nottingham-http-link-header-02 - HTTP Header
Linking (at tools.ietf.org)
Harry: The RDFa discussion was unclear to me, not sure what the
technical issues were. Could someone please explain what the issues
are?
<Hixie> MikeSmith, i believe you can just type "ack" to get the next
speaker
hsivonen: I was vocal in that discussion against taking RDFa as-is
... A lot of it revolves around the way RDFa uses XML namespaces
<gsnedders> (my comment was meaning using URIs in the same way Atom
does)
<DanC_lap> (Anne made the same comment, gsnedders . or pretty close.
but maybe the scribe missed it the first time)
hsivonen: You have to know the namespace mapping context from the
lower layer, that you then use as an RDF property
... It's confusing for authors to have to deal with these namespace
mappings
... there's a problem for implementers ...
... [something about parsing and namespace mapping issues]
<DanC_lap> (hmm... I wonder if the TAG finding on qnames in content
brings up that dynamic/scripting concern.)
hsivonen: We have a case where the DOM consistency principle is
violated
... xml:lang in the XML namespace, the lang attribute in no
namespace. This has caused a lot of bugs
... That's why I object to using XML syntax
... The other objection was related to people who aren't in the RDF
community having to pay the "RDF tax"
<pimpbot> Title: HTML WG -- 23 Oct 2008 (at www.w3.org)
hsivonen: [example of having to compare local name and namespace for
an element]
... every time I have to do that, it causes me to do something
costly that doesn't really solve a problem
... RDF has similar complications
<anne> From Murray Maloney: Murray is the only person in the world
who voted against namespaces in XML
hsivonen: I'd like a solution similar to GRDDL. People who want it
can, but doesn't cause problems for people that don't
<Hixie> ack
<Hixie> aw, i was wrong
Steven: CURIEs aren't namespaces, they're just shortened URIs
... Similar things appear in e.g. Wikipedia
... The other thing is that RDFa works in HTML now.
... People use JavaScript to extract it
... I don't see what the problem is
... If you don't want it, don't use it
Harry: We generally have consensus that maybe the way XML
implemented namespaces is kind of crazy
... But it's interesting that CURIEs as just one string, unlike
prefixes/localnames. It's simpler
... 2 issues
... How can we use these URIs in attribute values? Is there a short
version of the URI?
... This is a problem for people who want to use RDF
... Maybe all that needs to happen is that RDF technologies need to
be clear about how they fit within HTML5
... as long as there's a way that RDFa can signal the use of CURIEs
hsivonen: It would be objectionable if the mechanism for associating
the base URI with the prefixes were different for HTML5 and XHTML5
Harry: XHTML5 just uses xmlns?
hsivonen: Currently there is no defintion of RDFa in XHTML5
... You don't have a property attribute in XHTML5 today, it's not
specified how to do RDFa now
<Steeeven> <meta name="prefixes" content="xhtml
http://www.w3.org/1999/xhtml foo http://example.net/foo" />
http://www.w3.org/1999/xhtml
http://example.net/foo
hsivonen: The RDFa community assumes you would do it in XHTML5 the
same way as XHTML 1.0
<pimpbot> Title: XHTML namespace (at www.w3.org)
Harry: Would HTML5 be willing to sort out some way to use short
CURIE like values
hsivonen: I think the indirection of prefixes is a bug
... If the URIs are so long that you don't want to deal with them,
then that suggests a problem with the RDF naming scheme
I suggestion you use a registry, and concatenate the short values
with a base URI
<MikeSmith> ack
<hhalpin> I'd just like to note that instead of a religious war, it
appears the delta between *some* usable form of RDFa and HTML5 is
relatively small.
Julian_Reschke: What hsivonen just proposed seems like a harder
indirection mechanism
<hhalpin> +q
hsivonen: yes, but the "RDF tax" is only paid by the RDF community
<MikeSmith> ack
<anne> Steeeven, note that technically the xmlns attribute from an
HTML parser is different from an XML parser (the latter has a
namespace)
<anne> Steeeven, same for xmlns:* of course
<hhalpin> anne - so, unknown attributes though, such as a unknown
non-namespaced xmlns, would still be in the DOM and thus serialized
by XHTML5.
<MikeSmith> http://intertwingly.net/blog/2008/10/23/Misdirection
http://intertwingly.net/blog/2008/10/23/Misdirection
<pimpbot> Title: Sam Ruby: Misdirection (at intertwingly.net)
<anne> hhalpin, actually, xmlns couldn't be serialized back
<anne> hhalpin, though maybe it indeed depends on the serializer
+Raphael
<anne> so is table delayed?
+Silvia Pfeiffer
<MikeSmith> anne, in 5 minutes
Sylvia: [About <video>]
... We're talking about fragment identifiers applying to media
resources, like video
e.g. video.ogg#time=5,12
scribe: also query strings like &track=1,2,3
... For video, audio and images
<Hixie> RB: Please don't use an ampersand!
scribe: The effect it might have on the <video> and <audio> element
in HTML5
Hixie: start and end attributes will be removed. They overlap with
this stuff
... We're simplifying the looping attributes
Raphael: Establishing the communication between the UA and server
... through HTTP headers
... The UA will still know that they only got a fragment of the
resource
<anne> Hixie: we'll replace looping attributes with a simple loop
boolean attribute
Raphael: Please join the Media Fragments working group if
interested. It's open, public mailing list
table headers
JoshueOConnor: The issue is how to mark up complex data tables,
header associations
<Joshue> this is scary url
http://esw.w3.org/topic/HTML/IssueTableHeaders#head-4e755761c919
4f726c62cf815b251a464e9c4635
http://esw.w3.org/topic/HTML/IssueTableHeaders#head-4e755761c9194f726c62cf815b251a464e9c4635
<pimpbot> Title: HTML/IssueTableHeaders - ESW Wiki (at esw.w3.org)
<raphael> Media Fragment Home:
http://www.w3.org/2008/WebVideo/Fragments/ and public mailing
list: http://lists.w3.org/Archives/Public/public-media-fragment/
http://www.w3.org/2008/WebVideo/Fragments/
http://lists.w3.org/Archives/Public/public-media-fragment/
<pimpbot> Title: W3C Media Fragments Working Group (at www.w3.org)
<Joshue> These are also relevant
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822#c14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822#c14
<pimpbot> 115822: gez.lemon, P2, NEW, 13The headers attribute should
be able to reference a td
Al Gilman: The operational requirement from the consumer is
associating an arbitrary cell with any other cell that provide
context for interpreting the data
<mjs> Hixie, fragments in the media URI aren't really replacements
for start/end/etc timing control attributes, because you can't
readily change them through API
scribe: Chained headers
... Multiple tiers of context information within tables
<Joshue> Gez's complex table example
http://juicystudio.com/wcag/tables/altcomplex.html
http://juicystudio.com/wcag/tables/altcomplex.html
<pimpbot> Title: Child investment portfolios (at juicystudio.com)
scribe: It doesn't work in HTML4 because you can't have a TH that is
a header for a TH
<mjs> Hixie, you have to parse and reassemble the URI to do it
<mjs> Hixie, and I think doing so would per the spec require the
video to be reloaded as well
<Hixie> mjs, join the media fragments wg and let them know :)
<Hixie> (or send feedback)
AlGilman: There has been dispute on the mailing list, people using
many different terms.
<mjs> Hixie, I don't see how the media fragments WG can address
HTML5-defined DOM APIs....
<mjs> Hixie, are you saying you want them to take over the
HTMLMediaElement interface?
AlGilman: There are 2 ways to do it: 1. Have a TD cell be a target
of a headers attribute.
<Hixie> mjs, maybe their use cases aren't relevant, or won't apply
to html5, and that would be good for them to know
AlGilman: 2. Allow TH to reference another TH with a headers
attribute
<Joshue> some more background on a proposed solution using existing
header/id combinations which is well supported in current AT
http://esw.w3.org/topic/HTML/Action72Headers
http://esw.w3.org/topic/HTML/Action72Headers
<pimpbot> Title: HTML/Action72Headers - ESW Wiki (at esw.w3.org)
AlGilman: We would certainly like to make scope more effective
<mjs> Hixie, I'm giving you feedback on your minuted statement that
"start and end attributes will be removed. They overlap with this
stuff"
<Joshue> Smart span algorithm
http://lists.w3.org/Archives/Public/public-html/2008Mar/0075.htm
l
http://lists.w3.org/Archives/Public/public-html/2008Mar/0075.html
<pimpbot> Title: Smart span algorithm for table cells from James
Graham on 2008-03-10 (public-html@w3.org from March 2008) (at
lists.w3.org)
<Hixie> mjs, oh they'll be removed regardless of this
AlGilman: But we need to come together on a proposal for what all of
the markup features are, including the headers attribute, algorithm,
etc.
<Hixie> mjs, (probably)
<mjs> Hixie, why?
<Hixie> see recent feedback to the list
<Hixie> there aren't good use cases
AlGilman: We still have to work out details
<mjs> for audio there are
<mjs> playing a fragment of an audio clip is easier than editing the
actual audio file
<sicking> mjs, but do you want to change that fragment?
<MikeSmith> ?
<Joshue> +q
Joshue: There are a couple of solutions
<darobin> mjs, as we say in French, absent people are always wrong
Joshue: about half way down the wiki page
<mjs> sicking, let's say you are writing a web app that lets you
select a range from an audio or video clip and then play that
Joshue: Smart headers algorithm, TH referencing TH, etc.
<nessy> mjs, media fragment URIs allow you to do just that: play a
fragment
Joshue: Smart Headers is a good algorithm
<Hixie> mjs, for that use case, you'd use javascript anyway, so no
need for anything but the existing js api
Joshue: Allowing headers="" to reference a TD element
<mjs> nessy, but they don't let you change what fragment is referred
to without having to construct a new URI
Joshue: is also an elegant solution
... headers="" is widely supported by screen readers
... lets see if we can come to some kind of concensus
<Joshue>
http://esw.w3.org/topic/HTML/IssueTableHeaders#head-fc23268c19f6
b7ad3dbde901743900ab1053b433
http://esw.w3.org/topic/HTML/IssueTableHeaders#head-fc23268c19f6b7ad3dbde901743900ab1053b433
<pimpbot> Title: HTML/IssueTableHeaders - ESW Wiki (at esw.w3.org)
<nessy> mjs, what's the difference between changing a URI in a href
attribute and changing the start and end attributes?
<mjs> Hixie, so you don't mean to remove the equivalents of this
stuff in the JS API?
BenMillard: At the moment, Firefox doesn't do anything with scope or
headers
<Hixie> mjs, i wouldn't suggest removing curentTime and the cue
range API, which is what you'd use for this.
AlGilman: But it's all in the DOM, even though it doesn't do
anything special with them
<mjs> nessy, creating a specially formatted string is a sloppy API
design
<Hixie> mjs, seek to the start, cue a pause at the end, and play
<mjs> Hixie, that doesn't let you actually change the range that the
play controls reflect
<Hixie> mjs, nor do the existing attributes
Michael Cooper: A lot of accessibility is done through the
accessibility API and would require the UA to do a mapping from the
HTML DOM to that API
scribe: But it's also done through the DOM for web content
<mjs> Hixie, what do you mean? I would expect if start and end are
specified, the little slider thing goes between start and end, not
the full time range of the underlying media item
<Hixie> mjs, what if loopend is after end?
<Hixie> anne: i'm not scribe, it doesn't matter if i have a colon
<anne> s/mjs:/mjs,/g
<mjs> Hixie, the loop attributes make things more complicated,
presumably you need the union of {start, end} and {loopstart,
loopend} to be presented
Joshue; it's important to bear in mind the limited support for
scope="" in current UA and AT
<mjs> Hixie, I tentatively agree that fine-grained loop control is
probably more complex than justified
<Hixie> mjs, i don't really understand the use case you are
presenting, but i really should pay more attention to the room
<mjs> Hixie, although "just do it in script" is not a good solution
for looping
MikeSmith: Is there a time line for when you'll get to the remaining
table headers feedback?
<nessy> mjs, we will have a boolean loop attribute
Hixie: I'll get to it when I get to it, but I can prioritise it if
there are vendors that need me to
<nessy> mjs, that's an independent issue
<mjs> nessy, a string syntax is not a substitute for a proper API
(though an ok way to specify things declaratively)
AlGilman: This is not an urgent matter, because in the short term
people can still use headers="" in HTML4
<nessy> mjs, there already is an API to control media resources
<mjs> nessy, you don't talk to real media APIs by formatting special
strings to tell them what time range to play and how many times
<nessy> mjs, the start and end attributes don't provide you with an
API
AlGilman: I'd like us to work with Ben to tune the algorithm, and
getting that into HTML5 and implemented in browsers
<mjs> nessy, I am talking primarily about the HTMLMediaElement
interface
<nessy> mjs, so am I
<mjs> nessy, not the content attributes
Hixie: It sounds like sooner rather than later would help, so I can
help with that in the next few months
<mjs> (unfortunately the word "content" is ambiguous)
<Joshue> +q
<mjs> nessy, the start and end attributes in the HTMLMediaElement
interface certainly do provide an API
<nessy> mjs, we should take this offline from this room
<smedero> karl: ben doesn't have a laptop so I'll jump in: mozilla
AlGilman: If you only have headers="", then it's grotty for authors.
But we should move forward with change to improve that
<nessy> mjs, there will be more discussions on the mailing lists
MikeSmith: Does that timeline work for you guys?
Joshue: I can't speak for any vendors, but it would be nice
<karl> smedero, I hope it is enough for him to be doing that
correctly without making his "life at risk".
Hixie: The remaining ~2000 currently in the queue should be dealt
with within a year or so
hsivonen: There's an open moz bug about exposing table relationships
to accessibility APIs
... I encourage you to keep an eye on the mozilla bug, especially if
the Smart Headers algorithm will be going in the spec
... It would be a shame to have them implement what's in the current
spec, and then have it updated in the spec later
BenMillard: Al mentioned tuning the proposal. I wouldn't want to
kind of shortcut the proposal
<anne> "hixified"
BenMillard: I think that the algorithm in James's inspector should
be "Hixified" into the spec
... I think an Action item would be to document the diff between the
spec and Smart Headers algorithm
Joshue: One of the things that came out in the PF meeting was that
we were all talking about the same thing, using different names
... We should know what we're talking about
... get on the same page
<Zakim> MichaelC, you wanted to ask if it's not more efficient to
get a round of feedback from implementers before putting a proposal
in the spec
MichaelC: It might be more efficient if there is a round of feedback
from implementers before it's in the spec
<hsivonen> Hixie,
https://bugzilla.mozilla.org/show_bug.cgi?id=441445
https://bugzilla.mozilla.org/show_bug.cgi?id=441445
<pimpbot> Bug 441445: was not found.
<Joshue> From the PF meeting we found an issue around the use of
terminology in this issue. Conceptual headers, chained headers,
nested headers etc are all essentially the same. I would like to see
the terminology tied up so we are all on the same page. This could
help the process all round.
AlGilman: What we want to do in face time, we've done
<mjs> anne, do you recall the title of the thread?
<anne> mjs, i'll look for you
hsivonen: I heard that there was direction of consensus on the
validation side that headers would point to th, be valid and point
to td might not be valid
<anne> mjs, "video tag : loop for ever "
<MichaelC> Just to clarify, since it needed verbal clarification, I
do not advocate implementation of proposals, but was suggesting
implementers might have worthwhile insights on a proposal (but
should not implement it until it matures)
AlGilman: The current practice doesn't use HTML5 validation yet, we
don't need to trouble you now
<anne> mjs, people from Apple have been involved in the thread, e.g.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October
/016692.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016692.html
<pimpbot> Title: [whatwg] video tag : loop for ever (at
lists.whatwg.org)
MikeSmith: We could talk about HTTP auth
<mjs> that's a long thread
Julian_Reschke: OK
HTTP Authentication
<anne> scribe: anne
<Lachy> MikeSmith: Lachlan will not be scribing tomorrow because
he's done such a great job today
AG: the Web Security Context WG deals with the look and feel
... of authentication dialogs
[scribe is unclear if this was actually said]
[apologies]
[MS describes topics for tomorrow]
[Topic discussed now will be HTTP authentication integration with
HTML]
HS: will unconference sessions be integrated into this schedule
MS: we need to talk about the authoring guide
HS: 11:45 AM will be about implied ARIA semantics
MS: that is until 12:30 PM
<Hixie> AM is 00:00..11:59 and PM is 12:00..23:59
HTML integration point for HTTP authentication
Julian: issue is that user agents put up a primitive user interface
that authors cannot style
... originally the idea was that the response would actually return
HTML with a login form, but that never happened
... user agents only pop up this dialog which is one reason user
agents are not using authentication
... there are other issues: e.g. i18n
... these are not being solved because of chicken / egg problem
<MikeSmith> can somebody please find and post the link to the
related discussion for this that was on the WHATWG list recently?
<MikeSmith> aaron schwartz e-mail, I mean
JR: AvK mentioned that another missing piece is the logout button
... I don't have a personal agenda. Just noticed there was an old
proposal 1999? where the same issue was described
<Hixie> http://www.whatwg.org/issues/#WF2-http-auth-login-logout
http://www.whatwg.org/issues/#WF2-http-auth-login-logout
<pimpbot> Title: WHATWG Issues List (at www.whatwg.org)
JR: simple form that the user agent would know that there's a user
name and password and use that
Hixie: I was wondering why we want HTTP auth to succeed
JR: it's not necessarily HTTP authentication, but form based login
works very badly if the user is not a person
Hixie: there are other ways as well, with tokens and cookies
JR: what specs?
Hixie: cookies, HTTP, etc.
JR: you need out of band information to realize the server requires
authentication
<Philip> MikeSmith,
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October
/016742.html ?
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016742.html
<pimpbot> Title: [whatwg] fixing the authentication problem (at
lists.whatwg.org)
Hixie: you need that anyway
JR: there's a framework for that; not sure we should get rid of it
Hixie: it's not clear we should make it better if it's not needed
JonasSicking: whenever we work on widgets, "we want to style this
form widget"
JR: that's the issue I want to get fixed
<Philip> (in which the problem is that people don't want to use the
proper solution (HTTPS), and instead use the worst possible solution
(sending passwords in the clear) because the compromise (HTTP
Digest) is ugly)
Hixie: not sure that's the right answer, but not immediately obvious
why it isn't
<Philip> (or at least that's how I might interpret it)
JS (sicking): HTTP auth is broken in many many ways
scribe: I have 50 different passwords to remember; if one of these
sites start failing, I'm hosed
... the form based login is really bad. Teaches phishing and such.
... we need to rid of passwords entirely
... OpenID, infocards, LiveID
... should we go directly for that, or should we try to make
incremental changes on the mechanisms that exist today
... e.g. making HTTP auth secure (digest does clear text)
... and fix the styling issue so people will use it
... should we go for ID management or should we try to do some fixes
CWilso, that's not what he said :p
Hixie: The way to solve the problem is not to assume HTTP auth is
the solution
<adrianba> anne, he said Microsoft Passport
JR: the HTTP auth framework does in theory support other
authentication schemes
... e.g. OAuth
... one example, portal project where document management was
through the browser and webdav clients
... the automated clients need HTTP authentication to work
... servers start sniffing user agent string or even method name
<hhalpin> Although I am technically outside, and would like things
like LiveID/OpenID and OAuth pushed, I am not sure if they should be
put in HTML5.
adrianba, right, so the correction was wrong, doesn't matter though
scribe: etc. need nasty workarounds with the current situation
HS: one of the important things for adding something to the platform
requires a rollout strategy that cannot be blocked by a browser
vendor
... e.g. ARIA, the way it was defined it could not be ignored;
though it did end up being implemented by all four in record time
... how do you see the rollout strategy where you use OpenID for
browser authentication and OAuth for servers
JR: I don't know; I thought brainstorming would be good
SP: I had a chat with TBL last night; he didn't like OpenID but he
had some ideas for a new authentication scheme
... maybe someone should have a chat with TBL about this
JS (sicking): I'm not sure what he didn't like about OpenID
SP: complexity; going to another website, extra steps, etc.
JS (sicking): I think with having OpenID in the browser will solve
that problem
JS (sicking): the redirect is needed because they innovate within
the browser box
JS (sicking): as vendors we can change the browser
scribe: we had issues, not sure what the issues were
... people have voiced security concerns with OpenID
... my ultimate point was having ID management rather than password
management
AG: ... working with captchas(sp?)
... we want to encourage single sign on
... the PFWG is reopening our note regarding captchas
... the state of the art is that these tests that the commercial
botnot businesses can't crack, people can't do either
... it's more rationale to use a single sign on service
... for more of these transactions and we'll be pushing people in
that direction
HH: nobody disagrees with single sign on and that it should be put
in the browser
... there are several solutions in this space
... should HTML5 endorse one solution or provide a hook
... or will the true solution arrive in a year or two, maybe wait it
out a bit
... really important, should be done
AG: does this sound like a requirement for security API between the
browser and the protocols
HH: not sure how to design such a hook
... I would like to see some statistics on various ID mechanisms
AG: we should live with the redirects for longer is what you're
saying
HH: get some stats, see what's out there;
sicking: I think HTML5 should be completely silent on this
... I think that should be a separate work item
<hhalpin> this is really important, someone should eventually sort
this whole identity thing out.
sicking: we're sure to get something better eventually
... there might be some API that is needed but in general you'd like
to have the security features separately designed
HS: I have a question about what candidates are out there other than
OpenID, SAML
<hsivonen> SAML WebSSO
<Adam> http://en.wikipedia.org/wiki/SAML
http://en.wikipedia.org/wiki/SAML
<pimpbot> Title: Security Assertion Markup Language - Wikipedia, the
free encyclopedia (at en.wikipedia.org)
<hhalpin> also, note that I recommended some tight liasoning with
people from id and security fields.
AB: MS has introduced infocards
<hhalpin> I always thought it was OpenID/Liberty Alliance and
LiveID/Passport were the two big options in this space.
<hhalpin> There may be other experimental ones.
<hhalpin> +1 that HTML5 is interested in these issues.
ThomasRoessler: no particular input right now
MS: where do you think we are?
<hhalpin> Has Microsoft adopted OpenID anywhere? I thought it was
possible, would HTML5 endorsement make a difference?
JR: I wished we would have made some progress on that, but it seems
we need more research
MS: maybe discussion needs to continue in Web Apps?
Hixie: depends on the solution, not clear what the requirements are
sicking: is it a W3C matter?
JR: IETF is waiting for W3C; it's a user agent issue
<CWilso> Actually, my understanding is infocards interoperates
w/OpenID if desired
sicking: depends on the technical solution probably
... I think it should be an effort solely concentrated on security
<CWilso> (And it's called CardSpace now, not infocards)
<adrianba> infocard/cardspace =
http://msdn.microsoft.com/en-us/netframework/aa663320.aspx
http://msdn.microsoft.com/en-us/netframework/aa663320.aspx
<pimpbot> Title: Windows CardSpace (at msdn.microsoft.com)
ThomasRoessler: in principle that makes a lot of sense. (TR says he
missed bits of the discussion) The one thing I'm wondering what
problem you are looking at?
Jonas: I don't see how headers solve the problem
JR: the issue is as follows. you do a GET request. server wants you
to authenticate. can do a 200 with HTML form
... works extremely badly with clients that are not HTML clients
... or you can use 401 and then you've got a problem in HTML agents
that they pop up a dialog most designers and people running servers
don't like
... both are bad
... you really don't want to reply with 200 OK if you require login
Hixie: there's also sites where you can either login or not login
ThomasRoessler: the current HTTP auth mechanism are no longer state
of the art (to be polite)
... there is a question of what HTTP auth should look like
... there is also something like client certificates e.g. SSL
<hhalpin> CWilson - that was my understanding as well, but I was not
sure if that had ever happened yet. Thus my point that if HTML5 gets
in this space, then maybe asking some advice from experts from
LiveID, Passport, Liberty, OpenID, etc. and some data is the way to
go. Also, could this activity, which sounds large, be done at HTML5
or somewhere else that integrates with HTML5?
ThomasRoessler: [..] this is a rather large ocean. in the CABForum
they are trying to find out what the obstacles are with client side
PKI
... is assuming a working PKI; problems with e.g. business and
social interaction
... there is a member submission from 1999 along these lines; might
be useful
... assuming this will solve auth problems on large scale would be
naive
... assuming it would solve phishing is massively naive
... this is a HARD problem
... the 1999 document is not solving that problem, I suggest to not
rathole in this topic in this WG
... don't think this is the right community (no disrespect)
... one solution to look at is OAuth
... using HTTP and HTTP auth to pass authorization tokens around
... this you use to e.g. upload your Flickr photos
... will be discussed at IETF meeting in Minn... in the US
<adrianba> hhalpin, cardspace does work with openid - i have my
openid in an infocard, it does require the site to do something
extra to enable cards though
ThomasRoessler: I won't be there, pay attention at the IETF though
... they're attacking a useful problem; not saying it's attacking
the all the problems discussed here
<Julian_Reschke>
http://www.w3.org/TR/1999/NOTE-authentform-19990203
http://www.w3.org/TR/1999/NOTE-authentform-19990203
<pimpbot> Title: User Agent Authentication Form Elements (at
www.w3.org)
AG: the HTML processor in the browser is going to see an API
... going to be disconnect point so you can't change schemes
... you can annotate on that
... would be easier if we had an XForms model
... what's defined is what you can style
... scheme by scheme you get controls that the web author then can
style
... so first IETF, then HTML so you get the style
ThomasRoessler: one problem with usability of passwords; password
managers can log what passwords are entered when you login
... what can be useful is to distinguish the password fields for
registration
... the user agent can take control and help out
<Hixie> you can set pattern="" on type=password already in html5
<Hixie> there's no way to say it's for a new password though
HS: if you have passwords you can use these from any browser
... in countries were banks want some weird auth scheme, e.g. Java
... if you have a full browser but no binary plugins on a phone, you
cannot get authenticated
... it's important that new mechanisms work on mobiles as well
... e.g. native OpenID support in the UA; but fallback for mobiles
ThomasRoessler: in order to compat phishing we need to [...]
... one way out of that would be to help people out in the
interaction
... just taking the UI out will not solve that problem
... e.g. Google wants to style their logins forms to the pixel
AB: at boeing it would be really good if we got single sign on
... lots of different APIs that could make use of that
ThomasRoessler: you should point people to boeing presentations
given at various concordia workshops
<karl> http://projectconcordia.org/index.php/Main_Page
http://projectconcordia.org/index.php/Main_Page
MS: we are adjourned for the day
Summary of Action Items
[NEW] ACTION: Mike lead HTML WG to response to TAG discussion and
report back to TAG [recorded in
[100]http://www.w3.org/2008/10/23-html-wg-minutes.html#action01]
[NEW] ACTION: TimBL write up a description of the kind of spec
HTMLWG is writing for TAG [recorded in
[101]http://www.w3.org/2008/10/23-html-wg-minutes.html#action02]
[End of minutes]
--
Michael(tm) Smith
http://people.w3.org/mike/
Received on Friday, 7 November 2008 05:21:57 UTC