<MikeSmith> .t gsnedders

<phenny> Thu, 05 Nov 2009 00:15:22 GMT

<gsnedders> MikeSmith: That's no Europe/Stockholm

<gsnedders> *not

<MikeSmith> gsnedders: ah, yeah, I forgot you had relocated

<MikeSmith> .t gsnedders

<phenny> Thu, 05 Nov 2009 01:19:13 CET

<gsnedders> There we go.

<gsnedders> I really ought to try harder at this whole sleep thing ;P

<MikeSmith> gsnedders: sleep is for the weak

<gsnedders> :)

<MikeSmith> .t Linköping

<phenny> MikeSmith: Sorry, I don't know about the 'Linköping' timezone.

<MikeSmith> .t Linköping

<phenny> MikeSmith: Sorry, I don't know about the 'Linköping' timezone.

<MikeSmith> .t Linköping

<phenny> MikeSmith: Sorry, I don't know about the 'Linköping' timezone.

<MikeSmith> phoo

<Philip> .t Linköping

<phenny> Philip: Sorry, I don't know about the 'Linköping' timezone.

<MikeSmith> python

<MikeSmith> this is an a config file with magic encoding comment to give the encoding as UTF=8

<MikeSmith> UTF11-8

<MikeSmith> do I still have to do the u'' thing?

<Philip> Probably

<Philip> (assuming Python 2.x)

<MikeSmith> .t Linköping

<phenny> MikeSmith: Sorry, I don't know about the 'Linköping' timezone.

<MikeSmith> .t Linköping

<phenny> Thu, 05 Nov 2009 02:51:53 EET

<MikeSmith> https://bugs.webkit.org/show_bug.cgi?id=21288

<pimpbot> Title: Bug 21288 Implement HTML5's sandbox attribute for iframes (at bugs.webkit.org)

<pimpbot> planet: HTML 5 Doctype? <11http://stackoverflow.com/questions/1677974/html-5-doctype>

<battletoads> hi

<battletoads> hello?

<Olivers> Hi all.

<pimpbot> planet: ugly hack for some weird html5lib thing I can't fix right now <11http://hg.diveintohtml5.org/hgweb.cgi/rev/8be36ef7c1a47b97e0bc3cda872c7d3e11d91f11>

<Olivers> Any one here ?

<pimpbot> planet: HTML 5 Doctype? [CLOSED] <11http://stackoverflow.com/questions/1677974/html-5-doctype>

<thugbot> 04[localhost] MikeSmith: I can't reach bugzilla

<hsivonen> it seems to me that Content MathML wants to be Lisp

<jgraham> All W3C technologies keep adding features until they are lisp with angle brackets?

<jgraham> Doesn't really have the same ring to it

<hsivonen> that is, I don't remember if symbols are app-global or not

<hsivonen> does Lisp have Namespaces?

<hsivonen> the word "namespace" doesn't appear in the index of SICP

<pimpbot> bugmail: [Bug 8197] New: This design might work for JavaScript, but it won't work well in static-typed languages like Java or C#. Instead of overridding "namedItem", a better design would be to add a new method called "allNamedItems" which always returns an HTMLCollection. "nam <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0050.html>

<annevk> anything happening so far? I overslept as well...

<paulc> Currently 8:43 PT and 20 WG present

<paulc> Awaiting co-chairs and will start soon

<paulc> Meeting outline is at http://lists.w3.org/Archives/Public/public-html/2009Oct/1032.html

<pimpbot> Title: HTML WG meeting at TPAC - unconference style from Maciej Stachowiak on 2009-10-28 (public-html@w3.org from October 2009) (at lists.w3.org)

<Julian> Manu, no we don't

<manu> Thanks, Julian. :)

<Julian> Manu, but we'll log things to the IRC channel

<manu> oh, so the TPAC meeting is being logged to IRC?

<Julian> We are encouraged to self-scribe what we're saying

<Julian> We can also relay back your feedback into the room

<manu> groovy... thanks to the TPAC scribes/relays :)

<Julian> ...Paul Cotton is explaining the logistics...

<Julian> ...joint meeting with TAG at 2pm...

<Julian> ...2 more joint sessions tomorrow...

<Julian> ...W3D consortium 9am...

<Julian> ....joint meeting with TC39 later on...

<Julian> ...X3D at 10 pm...

<Julian> am

<Julian> ...we'll start 9am tomorrow...

<Julian> ...introductions...

<MikeSmith> Joe Williams

<Julian> ...collection suggestions for breakout sessions...

<Julian> Cynthia: HTML semantics vs Aria

<Julian> Frank: Accessibility and Canvas

<Julian> Sylvia: video accessibility

<annevk> RRSAgent is here

<Julian> Mike: testing

<Julian> Tony: decentralized extensibility

<Julian> Nikunj: client-controlled caching

<MikeSmith> @bug 8152

<pimpbot> MikeSmith: 11http://www.w3.org/Bugs/Public/show_bug.cgi?id=8152 contributor@whatwg.org, P3, NEW, 13Consider removing the <progress> and <meter> fallback magic

<Julian> Ian: progress and meter

<Julian> Joe: <object>

<Julian> Brian: client-side push

<Julian> ...: local storage concurrency problems, possible solutions

<MikeSmith> Julian: profile attribute

<Julian> Julian: profile attribute

<Julian> Julian: RDFa vs microdata (what should be in the base spec)

<Julian> Paul points out this may overlap with TAG session

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

<Julian> Joe: author/UA duties for the two mime types

<Julian> Steve F.: canvas in or out?

<Julian> Tantek: predefined vocabularies and coordination with other standards groups

<Julian> Mike: authoring material

<MikeSmith> or materials aimed at authors

<Julian> Patrick: HTML and MathML together

<Julian> Paul: mentions WG thread on MathML feedback

<MikeSmith> close action-157

<trackbot> ACTION-157 Request two smaller rooms (big enough for 10-12 people) for breakout sessions closed

<MikeSmith> action-127?

<trackbot> ACTION-127 -- Paul Cotton to establish process for "official WG response" to other WG's RFC on LC drafts -- due 2009-10-01 -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/actions/127

<pimpbot> Title: ACTION-127 - HTML Weekly Tracker (at www.w3.org)

<Julian> Paul: mentions cross-wg review of other specs

<Julian> Ian: MathML XML entities

<Julian> ...character entities...

<fantasai> Is anyone taking minutes?

<fantasai> ookkay

<inserted> scribe: fantasai

Proposed topics

1. Cynthia - HTML vs Aria semantics

2. Accessibility in Canvas

3. Accessibility in video (A11y? video?)

4. Kris - Testing

5. Tony - DCE

6. Nikunj - Caching

<MikeSmith> action-130

<MikeSmith> action-130?

<trackbot> ACTION-130 -- David Singer to review status of video codec positions -- due 2009-11-05 -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/actions/130

7. Ian - 8152-progress in metering (?)

<pimpbot> Title: ACTION-130 - HTML Weekly Tracker (at www.w3.org)

<timely> s/xunj/kunj/

8. Joe - Object tag

9. Connectionless push

10. Local storage recurrency problems, possible solutions

<MikeSmith> scribe: fantasai

11. Profile attribute (part of DCE?)

12. Next steps on RDFa + microdata

13. Authors vs browser responsibilities

14. Status on canvas - inout?

15. Pre-defined microdata vocab (tantek)

16. Authoring materials (mat. aimed @ authors)

17. HTML + MathML together

18. MathML update - XML character entities

19. Video codecs (ACTION-130)

20. HTML Media type (Issue-53)

<ArtB> ACTION-130?

<trackbot> ACTION-130 -- David Singer to review status of video codec positions -- due 2009-11-05 -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/actions/130

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

<pimpbot> Title: ACTION-130 - HTML Weekly Tracker (at www.w3.org)

Paul notes that the HTMLWG should review Last Call for ??, and that several members have volunteered to review the draft

Suggests that we collect comments and send them, not worry about trying to get consensus on a WG position

<annevk> ISSUE-53 is deferred to after CR

<annevk> "PR blocker"

Suggests that the HTMLWG should remember to review drafts of related WGs, not be too introspective into the work of this WG only

There are 15 open slots

<annevk> maciej enters

<Julian> Anne, but there's a controversy about what to do, and we should talk about that.

<Julian> yes

Paul asking whether it's worth breaking out

Paul: Shoudl testing be a break-out session?

some comment about parallelization, free slots might be only 6

Maciej takes over

Maciej: We had space for a total of 15 break-out sessions, there are 20 suggested topics
... Does anyone think any of these could fit into a half-size time slot (45min)?

Ian suggests 7 and 18

Anne suggests 17

?: 10 is half-size

??: 9 as well

Maciej is skeptical

Tantek: 15

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

<pimpbot> planet: Will Visual Studio 2010 support HTML 5? <11http://stackoverflow.com/questions/1682180/will-visual-studio-2010-support-html-5>

Maciej: So we've got 5 half-slot sessions, that takes away 2 slots
... that's still 18 / 15

???: If we can discuss the object topic 8 in context of decentralized extensibility..

Julian, Tantek: 11

Maciej: So 11, 5, 8 all one sesssion

<tantek> fantasai - that was julian

<Eliot_Graff> i do not think there's a phone bridge

<tantek> that mentioned the profile attribute

Maciej: We may have some extra time since it seems we might finish early with this session
... Today we have 7 slots plus 1 slot that is a joint session with the TAG

Maciej draws out the schedule slots

There are 8 slots in two columns on the board right now

<prolix> wil there be a phone bridge or no?

Maciej draws another slot table for Friday

<prolix> thanks, gseddrs

Maciej suggests putting the combination sessions into the longer slots

Slots for today are 11-12:30, 14-15:30, 16-17, 17-18

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

Friday slots are 9-10, 10-12, 13:30-15, 15:30-16:30, 16:30-17

TAG is today at 14:00

TC-39 tomorrow at 10

current proposals: 15+17 tomorrow at 10, 9+10 tomorrow at 13:30, 5+8+11 tomorrow at 13:30

1 today at 11

2 at 16:00

Topic 3 has been renamed to Video

Sylvia suggests merging with codecs and putting in a longer slot

Tantek: The 5811 session will be one of the hardest sessions that we have. I suggest doing it sooner rather than later while everyone is fresher
... Also many other things might depend on the outcome of that

MikeSmith: We might also want to discuss that before the TAG joint session

Tantek: It'd be helpful to have consensus on some things before talking with TAG

5+8+11 moved to 11am today

4 slotted for 16:00 today

4 is moving

to ...

<Eliot_Graff> 9 am tomorrow

15: 30 tomorrow

<Eliot_Graff> and then moved to 15:30 tomorrow

6 slotted for 16:00 today

<annevk> http://spreadsheets.google.com/ccc?key=0Apvkq1IRZaQVdEFieXBXVHVkVWZaWlFNVDJpU1I2eGc&hl=en

<pimpbot> Title: Welcome to Google Docs (at spreadsheets.google.com)

7+17 assigned 13:30 tomorrow

12 for 17:00 today

Joe: Seems like there's a tipping point between text/html and application/xhtml+xml. The author and browser have different responsibilities

7+15 at 13:30 tomorrow

opposite 9+10

20 for 16:30

17+18 for 15:30

open slot at the end of the day friday

Maciej: Anyone forsee any bad conflicts, anything you want moved? We have some slack in the schedule

14 and X30 for 9am tomorrow

Maciej has scheduled 15+17 twice

open slot at 10am Fri

3+19 (Video) placed opposite TC-39 at 10am tomorrow (2hr slot)

Maciej: Any other comments/

20 moved to 14:00 today

Joe: X3D has a use of canvas that will blow your mind, might be some interest between those parts

Maciej swaps 14 and 12

14 at 17 today

12 at 9am tom

Maceij: Ok, we'll go with this. We can move things around later if necessary

<myakura> do we have a slot for authoring materials?

Tantek proposes less time for 20 - HTML Media Types

it is now swapped with 2

Maciej writes out the schedule

Today:

11-12: 30 AM

<Julian> Anne, you're keeping this up-to-date right?

Session A: HTML vs ARIA semantics

<annevk> Julian, several people are

Session B: DCE , Object , Profile

<Julian> great

14-15: 30 (2 PM)

A: Canvas Accessibility

B: TAG

16-17 (4 PM)

A: HTML Media Types

B: Caching

<annevk> here is a published version of the schedule that is updated as people make changes: http://spreadsheets.google.com/pub?key=tAbypWTudUfZZQMT2iSR6xg&output=html

<pimpbot> Title: htmlwg schedule (at spreadsheets.google.com)

17-18 (5 PM)

A: Canvas Status

B: Author vs Browser Responsibilities

16, authoring materials, slotted for 16:30 tomorrow

2nd track in this room (track with TAG), and 1st track in another room

other room is called suite 1243?

Maciej starts the break early

since there is nothing left to discuss for the schedule

suite 1243 sessions will be in #html-wg2

<oedipus> thank you VERY much fantasiai

<oedipus> er, fantasai

HTML vs ARIA will be in their own task force channel

<cshelly> HTML + ARIA session will be on IRC channel #aapi at 11 PST (in 42 minutes)

<silvia> we'll have #video for the video discussion

<Lachy> krijnh, can you log #html-wg2 ?

<Hixie> myakura: it's a great example of DCE

<Hixie> no central authority to synchronise the names

<Hixie> no conflicts in practice

<Hixie> usable

<Hixie> intuitive

<myakura> heh

<oedipus> anne, could you add the IRC channel to the google spreadsheet?

<oedipus> thanks

<pimpbot> planet: point to external html5.js script for validation oddity <11http://hg.diveintohtml5.org/hgweb.cgi/rev/c1d7d5e7b3e0a0c4956745c8a24d278ea61e90da> 4** What are unusual and creative usages of html5 canvas <11http://stackoverflow.com/questions/1599792/what-are-unusual-and-creative-usages-of-html5-canvas> 4** html5 canvas element and svg. <11http://stackoverflow.com/questions/1650415/html5-canvas-element-and-svg> 4** Firefox 3.6 Beta 1 is now

<annevk> the alternate room is not monterey it is room 1243

<tantek> alternate channel is #html-wg2

<Julian> starting with overview of extensibility points

Pre-HTML5 approaches

<annevk> Joe Williams: [draws on whiteboard]

<annevk> <object> was preceded by <embed>

Joe: Then Netscape came up with <embed>
... Adobe working with them were able to get the flash player running with embed

<annevk> #aapi iirc

Joe: Plus being able ot respond to that nested context with some interfaces with the dom

<annevk> silvia1, ^^

Joe: Later <object> Was worked into the spec, MSFT came up with a good impl
... Shortly thereafter, all browsers
... began recognizing <object>
... To me tha twas one of the great signs that the browser wars were over. All the browsers did <object>
... That was great for people that wanted to build these nested objects in
... The thing about <object> is the type="mime"
... The browser looked at that, and then knew how to start up the object
... The second important thing is <param>
... The params give the opportunity.. for one thing, whatever the browser's context is, should have a negotiated live interface
... E.g. if I have a param named src, and the context recognizes it, then I should be able to send the DOM name and the param name and have an active exchange.
... These params should be I/O live
... I can have a running object here
... I can have live I/O, listeners listening to the dom
... So I have a nested context thing
... THe second most importan thing here is that <object> has fallback.
... If it doesn't recognize the mime type, it'll drop into the HTML inside. It could be another <object> tag with another mime type or just some HTML
... A lot of people put <embed>.
... Which really isn't necessary anymore
... Its interface was a long string....
... Anyway
... What happens when a browser encounters an <object> tag is a nother thing that should be consistent.
... Nowadasy the browser wants to ask about security. It may be in an environment that doesn't look at <object>
... But anyway, how we develop the context here and get the extensibility we need
... We have a virtual engine in there that we can talk to

Tony: You mentioned that you have some existing concerns about existing browser behavior

Joe: Some of it's from the plugin side.

<cardona507> thanks for scribing fantasai

Joe: From X3D for example, we have some initialization and runtime inputs that we'll accept. Not all the plugins willa ccept that
... From the other side there's a data attribute, and several other attributes, that will either name a specific runtime
... or ... but data's not a live param
... If you want to change the source file or ? , you have to rewrite your whole object tag
... because of the security that's built up around there,
... data gets checked differently in IE
... There are those kinds of inconsistencies

<tantek> not AFAIK - IE6 does support some object data=

<tantek> as did IE5/Mac

Joe: ... Should be just a friendly consistent cycle that users can depend on
... If SVG is adopted and put in inline, how does the browser recognize that it's calling into another runtime? Or is it built into the browser and the author doesn't really care

?

Maciej: A lot of the behavior of the object tag you described, at least in browsers that use NPAPI, the API only has the ability to send params to the plugin when it is started up
... If you try to resend params, the browser will either ignore it or restart the plugin

<pimpbot> planet: Will Visual Studio 2010 support HTML 5? <11http://stackoverflow.com/questions/1682180/will-visual-studio-2010-support-html-5> 4** A sexy new name for the Open Web Stack? <11http://www.brucelawson.co.uk/2009/a-sexy-new-name-for-the-open-web-stack/> 4** What are the boundaries or scope definitions of HTML5 development? <11http://stackoverflow.com/questions/1659386/what-are-the-boundaries-or-scope-definitions-of-html5-development> 4** HTM

Maciej: I believe all browsers that have NPAPI also have ?? that gives you a real API on teh object itself
... So you don't have to do it through <param>
... Because of limitations of NPAPI you can't have what your'e asking for
... It's something that could be revised in future versions of NPAPI

Joe: In the IE API, that is a real live trusted object in the document.
... The Netscape API doesn't quite treat it like that
... It's more like the embed thing, and the IE is more like the <object>
... ...
... What happens if you encouter an X3D link
... or another extensibility link?
... Just something friendly and consistent that we can play with. Thank you.

Anne: Did you read the spec for <object>? It says that changing the data attr will reinstantiate the object.

Joe: First of all, you want to get the thing running. You want to know when it's ready to accept the context argument. Then you know what you've got
... ...

?: The <object> is crippled for ...

Hixie: Why can't we expose an API?

Joe: Bring out a context, operate on it in the DOM..

Hixie: You can instatiate a plugin that doesn't have a data. To load a file there, you'd call the API for it
... The solution is to ...

Maciej: You could expose a load method for example, or you can even expose things that appear as custom JS properties
... So you could even have.. snce object convenient doesn't have src itself, you could assign src and the plugin then magages that

Joe: In IE I think the plugin passes the bag of params, and they negotiate that

Maciej: That's similar with NPAPI. You initially get a dictionar of the param values
... But in addition to that you can expose a direct scripting API
... I'm sure with Activex you can expose a direct scripting API as well

Tony: I don't think there's anything specific as far as HTML5 is concerned.

Joe: I'm continuing to look at the object element description
... Last time I looked the operation with the data paramter was more complete
... also things like what happens when you change the type
... ... It's just that, a uniform way to do it

Anne: The data attribute is about an external resource. The browser may need to fetch the resource, and in a lot of instances this determines what type of plugin to instantiate, which is why it's reinstantiated

Jeo: Whether or not the browser is the best one to decide whether the file is correct, is a question

Hixie: THe concern is makin sure that given a particular state of DOM, there needs to be consistency with whether you load again the state, ro mutate to that state

<tantek> FYI #html-wg2 is logged at: http://www.w3.org/2009/11/05-html-wg2-irc

Hixie: Suppose you have a plugin that supported flash and QT
... ...
... But hten you go to a user that supports one but and claims to support th eother, but only when changingit
... ...

Joe: I don't want to nail what object does with x3d or any kind of extension
... It remains a basic part of extensibility

Tony: Let' smove on

Julian: Profile there are several aspects to that discussion.
... First of all the descriptionin the HTML4 spec was broken wrt multiple profiles
... I spent a few hours to write precise erratum for HTMl4
... I'm not sure what to do with that
... Manual has started work on a separate work that takes advantage of the clause in HTML5 that allows other specs to define things base don profile
...
... The current proposal is to define a linke relation called profile
... Has the advantage of not using the profile attribute, but the disadvantage of existing things needitng to be updated not to us eht profile attr
...

Tantek: There have only been a few efforts that take advantage of the profile attr
... Dublin Core is one, but hasn't gotten much uptake
... Microformats then started, and they're pretty popular
... rel value was introduced in HTml2, and now we have a separate microformats
... People can pick a specific rel vocab with the profile attribute
... Whatever HTMl5 does with profile, it's a good design .... ...
...
... There are 2 different specs.

Julian: ??? Behaviorial spec
... Droppe dversion
... Now only describing profile attr and profile link relation
... So manual's profile only specifies link profile inherit
... There's opportunity to make it work on <a> element as well
... And potentially also on <link>s outside <head>

Tantek: Microformats encourages <a> but allows <link>

<weinig> [Are there links available for the specs being mentioned?]

Tantek: Recommends use of rel="profile" to link to theprofile inline, to better match authoring CMS patterns wher epeople work on different sections of the page

Julian: I think we should continue to discuss that on the mailing list
... Some people wonder about replacing profile with link rel=profile, why are we doing that if the functionality is exactly the same
... If we do so it makes a lot of sense to look into options to make it more useful
... Then there's the quesiton of should it be a separate spec, or should we put back into the main spec

<weinig> [Perhaps http://html5.digitalbazaar.com/specs/html5-epb.html ?]

<annevk> can people put some links into IRC?

<pimpbot> Title: Extended Processing Behavior in HTML5 (at html5.digitalbazaar.com)

Maciej: rel="profile" doesn't need to be in the spec because it uses the rel extension registry

JuliN: That reminds me of a topic we forgot about, where doe the ? for HTMl5 live

Julian: Is this particular attribute something that should live in the base spec
... wiki page

Tantek: I'm proceeding with the assumption that the current mechnanism in the HTML5 spec is sufficient and using microformats from there
... There is one impl currently of rel=profile that processes it
... It processes it either strict mode or ? mode
... In strict mode it requries the profile uri string, in loose mode authros are rcommended to use it
... It's called Cognition

<Hixie> is toby inkster here?

Hixie: Would be interesting to hear what the authors of that think the use is

Joe: So this is an example of extending by giving a uri

Tantek summarizes the HTML4 definition of profile and its relation to rel

<hsivonen> as I understand it, Cognition doesn't use @profile by default

Tantek: 2003 I wrote XMDP to create a profile format

<hsivonen> it isn't much of an endorsement-by-implementation to have it off-by-default

Tantek: To date there have been a few processors that use it, but mostly as a validation checking thing.
... Some use it for transformation to RDF/GRDDL

Julian: .. he said that if there's conensensus that this is the right way he has no problem doing so

<tantek> XMDP: http://gmpg.org/xmdp/description

Julian: Talk if authors are willing to migrate away from that. I can take that to DCH

<pimpbot> Title: XMDP: Introduction and Format Description (at gmpg.org)

Julian: Tantek is here, he knows the right thing for microformats

<tantek> rel-profile: http://microformats.org/wiki/rel-profile

Julian: Don't know aht other specs use profile

<pimpbot> Title: rel profile � Microformats Wiki (at microformats.org)

Maciej: Would our goal be to get these specs updated to use rel=profile?

Tantek: I think so. I'm working with microformats to do that

Joe: These vocabs aren't necessarily related to processing the DOM

Tantek: They don't contribute to the DOM, they are already part of existing attr
... e.g. class attribute is space-separated tokens. Microformats makes use of that
... There are some browsers, e.g. ff, that can parse that and create a dom interface out of microformats.
... but that hasn't been propsoed for standardization
... Side note, I know tha tbinding things as URIs is not totally agreed on and not often used
... There are nontrivial communities that do think it's important and do want that ability
... Just talking with TIm, it would be helpful with linked data

Tony: Tantek, would you be willing to talk more about how mf take advantage of HTML syntax today?

tantek: MF takes advantage of rel and class
... HTml spec has language to allow that

Tantke: XFN in 2003 took advantage of that

Tantek: In addition modern web designers have been using class attr for their own uses, e.g. class="header' class="footer"
... MF takes advantage of that existing pattern of creating semantics with classes,
... often takes existing vocabs as class names, e.g. with hCard

Julian...

Julian: Ressurects the Link header from HTTP spec
... It allows exposing link relations in HTTP headers
... useful if you want to declare a link relation isn't HTML
... That spec suggests IANA registry fro shortnames
... Web Linking spec
... That spec is past IETF Last Call
... Mark Nottingham is here today
... might be able to talk to him

<annevk> http://tools.ietf.org/html/draft-nottingham-http-link-header

<pimpbot> Title: draft-nottingham-http-link-header-06 - Web Linking (at tools.ietf.org)

Julian: I think also about the media parameter

<hsivonen> what would it mean to use rel=profile on the HTTP level for a non-HTML HTTP response?

Julian: There's a potential conflict between the rel value registry that HTML5 spec currently defines and the IANA registry the IETF is proposing
... Don't know whether we canr esovle that conflict or whether it's significant
... Anything used outside HTML might wind up in both registries

<Julian> http://tools.ietf.org/html/draft-nottingham-http-link-header-06

<pimpbot> Title: draft-nottingham-http-link-header-06 - Web Linking (at tools.ietf.org)

Tony: In terms of ppl being able to add extneions into HTML, custom attributes is something frameworks tend to make use of
... IF you don't care about validation you could do this in browsers for years
... It's a concern for frameworks whether their declarative markup validats in terms of whether customers are willing to use it
... data- gives us that

Anne: When we added attrs for WF2, it broke some stuff

Hixie: As we extend HTML we run into conflicts with these names
... We've had to rename some things
... kind of sad, because w can't use these attrs on form elements for example
... THere's a distinction between attrs that are site-specific thing to hook into scripts
... e.g. in HTML5 spec I annotate elements for cross-references
... that's a closed environment where I'm extending the language in some way
... then there are more broad extensions like <canvas> and <marquee>

<Julian> (which means there are still open issues to resolve)

Tony: Distinguish extnesions you make for your homepage or JS framework, and ... roundtripping of metadata that we've supported
... For a page author embedding data in their own page data- gives them a safe path forward.
... We don't have to worry about name clashes going forward
... it's not clear whether that's available to frameworks or not
... And what authoring best practices are

Talking about data-svg-?

and SVG library writen in JS

data-path is too general, likely to conflict

Hixie: If your bunch of content is self-contained, and self-consistent, it's fine
... It's only aproblem when the content expect something from outside itself, e.g. the browser, to interact with it that we get a problem

Maciej: Frameworks are part of the page, they're just also reusable
... They don't create a situation where you're using data- to publish information to be consumed by others

Tantek: Once people start using the same data- attributes with the same libraries across sites, you'll start getting de-facto standards

Hixie: ...
... We should use MF to encode data for wider usage

Tantek: Can we give some guidance in the spec, warning don't go further than this

Tony: Do we want to have a distinction between a single page author's stuff vs. script librarie's stuff?

<hsivonen> the author controls which libraries to include

<hsivonen> so in that sense, the author is in control of the libs, too

Hixie: There's a difference between what I use on my page and Dojo, but these are opposite ends of a spectrum. It is a spectrum.
... things will migrate across the spectrum
... and there's no clear transition pointt

Maciej: If you use data- attrs, you should use some kind of prefix
... While data- stops clases with future standardds or browsers, might be useful to give some guidance over avoiding clashes amongst themselves.
... don't want Dojo and JQuery fighting over attr names

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

Anne: x- usually means experimental

Joe: Or extensible

Tony: Perhaps something else, but would that be worthwile. Do I want data-jquer-* for all my widgets?

Maciej: Well ? are already unbelievably long

Hixie: We don't have any control over this. We can just give advice
... If i write a page that uses one attribute and only I use it, I'm not going to write data-x-hixie-foo

<hsivonen> IIRC, dojo already puts "dojo" into its custom attributes that predate data-*

Hixie: We can and should give guidance for framworks etc

Tony: For the people sitting on that edge, we're hitting into very long attr names
...
... The longer the names are the less chance of name collisions, but also they become more unwieldy

<hsivonen> gsnedders|work, I see dojoType at http://dojocampus.org/explorer/#Dojox_Widgets_Color%20Picker_Customized

Tantek: I think we should go with Maciej's proposal to add prefixes if you're writing a library, and if there's pushback, deal with it then

<pimpbot> Title: Dojo Campus - Feature Explorer (at dojocampus.org)

Tony: One other use case was metadata for non-browsers UAs in terms fo roundtripping
... I think microdata was intended for that purpose

<hsivonen> (it's a very bad idea to use a capital 'T' in dojoType, though)

Tony: I was wondering what the consensus is on whether it's sufficient

Hixie: I'd be surprised if we had consensus that it's insfuficient, it's basically RDF model

Maciej: ...

Julian: Is it sufficient, I think it is. There's an open discussion on typing
... More interesting question is whether we want microdata to be part of the HTML5 spec

Tony prefers to hold that one off for other session

Tantek: 9am tom
... One thing that would help with q of what should editors do, is more documentaiton on the use cases
... More documentation for editors on decentralized extensibility use cases

<scribe> ACTION: Tony to write that on the wiki (decentralized extensibility use cases for editors) [recorded in http://www.w3.org/2009/11/05-html-wg-minutes.html#action01]

<trackbot> Sorry, couldn't find user - Tony

<hsivonen> it's not clear that it's good for editors to dump a lot of product-specific stuff into files

Tony: Knowing that a lot of frameworks and MF use class names to perform typing, is there value in letting them have their own elements.

<hsivonen> Dreamweaver even has a feature for "cleaning up" Word HTML

Tantek: don't understand what you mean

Tony: Adding semantics so that it's more than just a div

Hixie: use case?

Tony: Do you feel there's value in being able to have a more concise syntax such as an element name

Tantek: I see anti-value

Hixie: big problems with new element is that UAs that don't understand it is that you fall back to the semantics of nothing.

Hixie; With class, if you have a subclass of paragraph, you at least fall back to paragraph

Tony: I'm talking about context of page author or script library, the opt-in mechanism of the script library or author adding semantics

Hixie: Adding meaning is fine, this isn't that

<hsivonen> see also http://intertwingly.net/blog/2006/11/15/Open-Source-Duke#c1163662129 in the context of Illustrator SVG output

<pimpbot> Title: Sam Ruby: Open Source Duke (at intertwingly.net)

Tantek: space-separated class names allows MF to layer multiple semantics onto a single element: very concise, rich semantics
... If they were elements, it'd be weird, bloated, and you'd get weird tree problems

Maciej: The tree format choices are a problem. It's hard to add semantics without affecting the DOM, scripts, styling, etc.
... Also things that are extensions right now might become standards later
... It's easy to put two dfferent attrs on an element,
... but you can't combine elements

Tantek: Elements are bad because they make it more difficult ot overlay semantics
... Lose fallback semantics

<hsivonen> the downside is that classes can't affect the DOM interface of the element for "extensions" that later become native

Tantek: Make migration to standards more difficult

[3 reasons]

Hixie; If apple inventing invented d-apple-canvas, and mozilla did d-moz-canvas, then you could put them both on the same div

Maciej: and once standardized, you could put both on <canvas> element
... UA etensions tend not to migrate to standards, but other names do
... Script libraries it's harder to have the script library turn itself off when it's not needed (..?)

Tony: We wouldn't want to standardize on the extended syntax anyway, bc it's reserved for extension
... i see that for most common cases attrs would be more usefl
... I dont think we need to talk much about prefixing anymore

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

Tony: One of my biggest ocncerns here isn't about name collisions, it's about consistency
... GOing to HTML5 as it exists today, doesn't jive for me
... Namespaces are all over the place. used to describe so much of what HTML5 is and what it does
... but it's all implicit, I can't access it

Hixie: I'd like to remove it all
... namespaces are hidden as much as possible, but unfortunately not complete possible.

Tony: rolled SVG and MathML specs

Hixie: We def don't want arbitrary vocabs to be included in HTML

Tony: Have to wait for HTMl6?

<cardona507> html6 next year?

Hixie: It's happened twice in 19 years?
... HTML6 starts next year anyway

Tony: ... same tag name across different name spaces. If I reshuffle these in the DOM, I can't reserialize anything

Hixie: You can reserialize anything that is conforming
... I agree it's a probelm having all this namespace stuff in HTML
... e.g. you want to XHR an XHTML document and just import those nodes... I think it'll be a nonstarter to as SVG to remvoe their namespaces
... It's unfortunate, but we're past the point where we can chagne it

Julian: THe opposite, to actually allow prefixed names in HTML, would be worse

Tony: Why do you feel that way?

Hixie: There are different aspects of namespaces, different types of disasters. ANy particular ones I should talk about?
... A lot of them are prefix-specific.
... If we remove those and have names being tuples
... We have the same name that means different things. And people don't typically use the full long names, they use the short ones.
... ppl find namespaces very confusing

Maciej: People use prefixes without namespace decl
... and you end up with this mechanism where theoretically you have these URIs but in reality you're tied to these prefixes

Hixie: ? made interesting observation after writing book on XForms
... 80% of the emails he received were asking him on namespaces
... this is a book on xforms, not even about namespaces

Maciej: XForms isn't namespace heavy

Hixie: And yet of the whole of XForms, which is a massively complicaed language, 80% of questions were about namespaces

Julian: Many ppl have bad experiences with namespaces, maybe some have good experiences

Hixie: I doubt it. I guarantee there are namespace problems in the WebDAV space as well
... I've been involved with ppl invovled with the design of WebDAV that dont' get it

Maciej: It's not just that some people have problem understanding namespaces
... it's also that some people haveing trouble with it throws off everything else
... If they start using namespaces wrong then we start a dependency cycle where processors and authors use namespaces wrong
... If ppl just got confused and caused themselves problems, that'd be bad, but if they get confused and cause other people problems, that's worse

Tony: ..
... If youre content just didn't display, you'd know there's a problem

Maciej: People don't publish content with problems if the browser doesn't behave as they expect

as often

Tantek: People tend to fall into 2 camps. 1. They see namespaces, it looks confusing, and run away

<hsivonen> (the XForms book author Hixie referred to is Micah Dubinko)

Tantek: 2. Or they think they understand it, use copy&paste, and have trouble with it
... Unless you live and breathe namespaces, you're like to get it wrong
... We see this problem even at w3c
...

Rob: Some of the criticism of namespaces while still allowing ...

Rob likes Liam Q's unobtrusive namespaces

Tony: I don't know all the syntax he's looking for, but the intend and what he was trying to achieve.

<hsivonen> more than once on W3C-related occasions, I have had to explain Namespaces to people who work on specs that purport to build on Namespaces

Tony: There was the idea of having external file that auto-binds element names

<hsivonen> Namespaces are too hard even for people who work on specs at the W3C

Tony: and can have switches for descendent elements
... Basically generalizing what HTML5 does
... ...
... So you can write different files, mix in something new either osmething broadly standardized or something local that only you use
... You can have HTML processing, don't have explicit namespaces in your document

Rob: Let's say someone wants ot add a new feature, then if that gets adopted it becomes part of HTMl6
... Fixes some of the migration issues

Julian: Problem with that is that then the semantics of your page depend on this external file
... you have this external resource, you have something similar to the DTD fetching problem
... Also we're saying already that the indirection of namespaces is too complicated, and we're making it even more indirect

Tony: I don't know that it's indirection. What it allows is for authors to to think about just the element.s
... Authors can reap the advantages of mashupws without being exposed to their complexities
...
... createElementNS and createElement is already a problem

Maciej: No reason we can't extend createElement to handle this the same way as the parser
... Classic XML namespaces bind a prefix to a namespace URI. THat's a level of indirection, and that also has certain nesting rules.
... This would bind namespaces to an actual tag name.
... There's definitely potential for confusion there, where if you communicate with someone that's not using the same predefined namespace file
... But you don't have the problem of having an arbitrary token used just for indirection

Julian: But it's na external file. can we put this in the head somehow?

Maciej: would be too long

Tony: ... [not really b/c of nestign bhavior]

Maciej: It's different in the sense that authors could themselves use the same behavior for their own vocabularies
... and in the future could be ...
... If the logical model is that there's a predefined model, doesn't mean the UA has to fetch it each time.
... If you wanted to do it for custom elements, then you'd have tlink it and read it

Tantek: That sound isomorphic to DTDs. I don't see the difference.

Anne: Having a file you have to load to parse it is not a good idea.

Julian: Well, you could parse it, but not do anything beyond that
... I think we should consider that we may be able to come up with a clever way to use namespaces, but it will be a different way from XML
... I'm skeptical that we can make it friendly or that it will be less confusing. I think by creating a second way to do the same thing we're adding to the confusion
...

<Hixie> http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html#issue-namespace-handling

Lachy: I don't think we should be develping a solution for adding namespaces to HTML if XHTML will work fine in the future (once we have support in IE)

<pimpbot> Title: WebDAV Mini-Redirector (MRXDAV.SYS) Versions and Issues List (at www.greenbytes.de)

Carlos: It seemed like Tim was pretty passionate about this. Anyone have an idea what exactly?

Maciej: He loves namespaces

Joe: Aren't we saying that..
... I see this as two sides, the text/html side
... and then there's the XHTML side

<Julian> notes that this is a problem of a client that properly handles prefixes, just not default namespaces

Joe: And on the HTML side the browser is covering my but

t

Joe: It's not a validating parser, it's got fixups, it's got makeups, ituses tables, doesn't care about dtd. Just cares about what it has hard-coded
... In XHTML the browser is stupid, it doesn't know anything at all. I tell it what it's got to do. It learns in an entirely different way than in text/html
... I'm saying that to have text/html be extensible, I've got to change
... In XHTML I just give it a new namespace, and a new schema
... It's easy to extend XHTML, hard to extend HTML
... On one side I deal with the browser's built-ins, on the other I have extensibility

Tantek: it sounds like there are multiple proposals for adding some form of namespaces to HTML

Anne: The basic idea of XML5 is to add some of the error-recovery ideas of HTML to XML. It would still have extensibility and namespaces and stuff. Authors could then use that

Maciej: The idea is to have a second way of handling application/xml that handled conforming documents the same, but for nonconforming documents handled errors in a well-defined manner that didn't catch fire

<hsivonen> about the Microsoft proposal: would MS implement it across all modes of IE (including the IE 5.5 mode) if it were adopted into a W3C spec?

Maciej: THe interesting thing about htis proposal is it would provide the people that want xml namespaces with athe ability to have lenient error-handling

<hsivonen> that is, does Microsoft believe it's compatible enough with existing content to be implemented across all modes?

Maciej: The disadvantage si that the people that want the draconian error handling can't get that anymore

<hsivonen> I think doing XML5 would be more sensible than bending text/html into the requirements of the XML community

My personal opinion is that XML parsers in browsers shouldn't bail on the whole document on errors, they should just close all tags and then abort

obvious error, but you get at least something usable

if you're just a reader

Meeting closed

<MikeSmith> ACTION: Steve to bring question to group: Do we want changing of element handler and role semantics via attributes to be deprecated? [recorded in http://www.w3.org/2009/11/05-html-wg-minutes.html#action02]

<trackbot> Created ACTION-158 - Bring question to group: Do we want changing of element handler and role semantics via attributes to be deprecated? [on Steve Faulkner - due 2009-11-12].

MikeSmith: I can't minute TAG

MikeSmith, It's in the afternoon, I'm not available this afternoon

<MikeSmith> fantasai, OK

<tantek> lunch

<pimpbot> planet: Distributed Extensibility <11http://dbaron.org/log/20091105-distributed-extensibility>

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

<pimpbot> bugmail: [Bug 8207] Change definition of URL to normative reference to IRIBIS <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0052.html> 4** [Bug 8207] New: Change definition of URL to normative reference to IRIBIS <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0051.html>

<rubys> hsivonen: ping?

<annevk> we're still somewhat stuck in the security room

<annevk> hopefully this is rounded up within 5 minutes

<annevk> (not hsivonen btw, he's at home :) )

<gsnedders> annevk: security room?

<MikeSmith> I suspect hsivonen may be sleeping by now

<annevk> yeah, because of the fire earlier

<MikeSmith> .t hsivonen

<phenny> Fri, 06 Nov 2009 00:00:07 EET

<gsnedders> annevk: fire? what?

<Philip> gsnedders: It's the room with all the CCTV displays so they can snoop on the other attendees

<rubys> For hsivonen to ponder at some later point: http://intertwingly.net/blog/2009/11/05/Web3D#c1257458545

<pimpbot> Title: Sam Ruby: Web3D (at intertwingly.net)

<paulc> TAG and HTML WG joint session: http://lists.w3.org/Archives/Public/public-html/2009Nov/0161.html

<pimpbot> Title: TAG and HTML WG joint meeting discussion topics from Paul Cotton on 2009-11-05 (public-html@w3.org from November 2009) (at lists.w3.org)

joint meeting with TAG

<annevk> Paul Cotton is giving an intro

<annevk> note to TAG members on IRC: scribing is adhoc

<annevk> anarchy-like

<DanC> ok... i.e. if you want it recorded, record it

<annevk> yup

<paulc> noah giving an intro to the TAG

<paulc> TAG charter: http://www.w3.org/2001/07/19-tag

<pimpbot> Title: Technical Architecture Group (TAG) Charter (at www.w3.org)

<paulc> Starting discussion with http://lists.w3.org/Archives/Public/public-html/2009Nov/0161.html

<pimpbot> Title: TAG and HTML WG joint meeting discussion topics from Paul Cotton on 2009-11-05 (public-html@w3.org from November 2009) (at lists.w3.org)

<paulc> Possible topics:

<paulc> a) text/html media type

<DanC> maybe we could skip the (rest of) the read-thru and start discussion?

<paulc> b) URI/IRI/WebAddr

<DanC> my mental stack is about full

<tantek> Noah is summarizing the Discussion Topics

<paulc> c) Embedding data in HTML Documents

<paulc> d) Language reference/authoring specification

<DanC> scribe: DanC

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

text/html media type

<annevk> (Larry was in the security BOF; thought he would come here.)

PaulC: do you have proposed text re polyglot documents?

Hixie: not yet; the bug came in yesterday or so...
... the intent was to [sorry, missed]; there's a small intersection between HTML and XML, called polyglot documents...
... the text [did something wrong in that case]; I expect to fix that.

TimBL: perhaps the intersection is small by count of strings, but it's a valuable language with a community of practice around it

<Zakim> MikeSmith, you wanted to ask about current wording of definition of "XHTML" in the spec

Hixie: so I hear; could you elaborate on why you value it?

TimBL: if you use XML tools, [it's nice]

MikeSmith: meanwhile, HTML5 parsers are being slotted in where XML processors have been, e.g. on the front of XSLT engines.

HTMLXSLT, from Henri Sivonen

MikeSmith: another point: the definition of XHTML... at some point, the spec defined it as "a document served with an XML media type"... I lost track of where it is now...
... people objected to it; people don't want to be told that the document they call XHTML can't be served as text/html. I have some empathy [sympathy?] for this position.

Hixie: yes, if you constrain yourself to the intersection...

<ht> +1 to mjs

<Zakim> noahm, you wanted to ask whether we don't already have a good resolution

Maciej: I observe the difference in opinion between TimBL and Hixie about whether polyglot documents are valuable/good; I suggest the spec remain neutral on this.

Hixie: yes, text that editorialized on this has been removed... or will/should be

<tantek> Noah: perhaps a problem is the use of the phrase "XML document" without hyperlinking it.

Noah: a general suggestion that bears on this case... the term "XML document" is used in a what that's not clear; a hyperlink would likely clarify...
... perhaps a parallel effort could audit the spec for hyperlinks to add

<Zakim> Hixie, you wanted to mention you need a special outputter anyway to do this

Hixie: in the case where you're outputting an XML document that you want to ship as text/html, you do need a special serialzer; e.g. to avoid <div />

<Zakim> ht, you wanted to mention cocoon, XProc, docman tooling in general

<annevk> other examples are <br></br> turning into <br/><br/> at the DOM level

HT: there's a community of practice, esp in document management, that switched to all XML ~4 years ago...

<Philip> MikeSmith, can't you sign HTML documents exactly like you'd sign any arbitrary stream of bytes?

<annevk> and <p><table></table></p> becoming <p/><table/><p/> at the DOM level, etc.

HT: e.g. spec-prod [?]
... we don't use a special serializer; we've just learned to be careful

<Zakim> Kai, you wanted to ask, naively, what this would mean for our XHTML pages, served as text/html, our hundreds of partner companies and basically the whole structure of an XHTML

Hixie: wouldn't it be better for the tools to do that?

HT: I don't think so, in particular because we want to continue to process the output with generic XML tools

[ETOOFAST]

<tantek> Kai: all we have is XHTML that we serve as text/html

Kai: all we at Deutsche Telekom have is text/html... could someone explain the issue at a high level?

<annevk> there is http://wiki.whatwg.org/wiki/HTML_vs._XHTML

<pimpbot> Title: HTML vs. XHTML - WHATWG Wiki (at wiki.whatwg.org)

<annevk> mostly written by people outside the polyglot community, but it should be accurate

<annevk> DanC, ^^

<MikeSmith> DanC: any volunteers, among in the community of people who want to write polyglot documents, who volunteer to write a document describing how to do this correctly?

<MikeSmith> karl, URL for your draft about polyglot documents?

<tantek> Maciej: definition of the sliver matters

Maciej: it's not enough to just match both syntaxes; you have to avoid things that cause unexpected results...

<tantek> some just say conforming to both syntaxes

<tantek> others also want same tree (e.g no implied tags)

<Lachy> DanC, my HTML5 Reference also covers writing polyglot documents. There's a whole section devoted to it.

Maciej: so one challenge to [writing this up] is explaining the motivation for it [?]

oh. I guess I forgot that, Lachy

<Zakim> MikeSmith, you wanted to note that the case of drop-in HTML5 parsers in XML toolchains doesn't work for documents that need to be signed (because we have an XML document signing

<annevk> (Pure polyglot fails with the first tag by the way. <html xmlns=...> ends up differently in the DOM.)

MikeSmith: if you're using signed documents, you're not going to be able to process them with HTML5 parser frontend on an XML toolchain

<ht> Without going on the queue, can someone confirm that e.g. <div>Hello world is not legitimately servable as text/html ?

<MikeSmith> http://www.la-grange.net/2009/07/05/html5-xhtml5/ <- HTML 5 and XHTML 5 - one vocabulary, two serializations

<pimpbot> Title: HTML 5 and XHTML 5 - one vocabulary, two serializations (at www.la-grange.net)

<Zakim> timbl, you wanted to mention tidy and to protest against a doubling the toolsets

<karl> MikeSmith, you have been quicker than me

<annevk> ht, yes, <!doctype html><title></title><div>Hellow world</div> would be needed

TVR: years ago when work on XHTML started, there was an expectation of smooth evolution toward cleaner markup; we can engineer HTML 5 to make it grow or shrink

<annevk> ht, you need a DOCTYPE and the title element is also still required

<ht> Thanks anne, that's fine

Hixie: we're trying to make it grow; with HTML 4, it was empty. HTML 5 makes it significantly larger

TimBL: I use tidy to make XML... making an empty <blockquote /> or <div /> isn't something I do as a matter of course...

<ht> I was just checking that expected error recovery "doesn't count" as far as legitimate use of the media types is concerned

<MikeSmith> Larry has arrived

TimBL: and the insertion of <thead> between <table> and <tr> doesn't bother me because I'm not doing scripting/xpaths.
... so for lots of ordinary documents, it [polydocument document] is fine
... some shops have all sorts of content management with XML doing lots of things, one of which is the web site.
... so I wouldn't want them to have to double their toolset [i.e. adding HTML 5 parsers] just to parse, e.g. HTML descriptions of people in HR systems

<rubys> http://www.w3.org/TR/html5/infrastructure.html#extensibility => http://intertwingly.net/blog/2009/11/05/Web3D

<pimpbot> Title: 2 Common infrastructure HTML 5 (at www.w3.org)

<Zakim> timbl_, you wanted to talk about defining (a) a polyglot set of constrains and (b) the properties they have

SR: with years of practice in this space, it's [remarkably difficult] and the tools I develop show that people [mess it up in an amazing variety of ways]

<pimpbot> Title: XHTML 1.0: The Extensible HyperText Markup Language (Second Edition) (at www.w3.org)

PaulC: the point about staying neutral makes sense, as does the request for somebody to write up how to write polyglot documents

<Lachy> http://dev.w3.org/html5/html-author/

<pimpbot> Title: HTML 5 Reference (at dev.w3.org)

Lachlan: a draft I'm working on has a section on how to write polyglot documents

text/html media type registration and IETF compatibility guidelines

<Julian> it's related to http://www.w3.org/html/wg/tracker/issues/53

<pimpbot> Title: ISSUE-53 - HTML Weekly Tracker (at www.w3.org)

<MikeSmith> note that karl's document uses the term "versatile documents" instead of "polyglot documents"

<Lachy> These documents are also useful for understanding polyglot documents http://wiki.whatwg.org/wiki/HTML_vs._XHTML http://wiki.whatwg.org/wiki/Validator.nu_Useful_Warning_Requests#Polyglot_Document_Checking

+1 "versatile"

<pimpbot> Title: HTML vs. XHTML - WHATWG Wiki (at wiki.whatwg.org)

PaulC: where are we on the text.html media type registration?

SR: lots of discussion; little in the way of concrete proposals

<pimpbot> bugmail: [Bug 8209] New: The term "XML document" needs xreffing throughout. <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0054.html> 4** [Bug 8208] New: The data-* attributes need to be clearer about their applicability to JS libraries, and in particular should have some suggestions about using unambiguous attribute names like data-dojo-range or data-jq-selector or whatever. <11http://lists.w3.org/Archives/Public/public-html-bugzil

<Julian> http://tools.ietf.org/html/rfc2854

<noahm> FWIW, my comment was that "XML document" was an example of what may be many terms that would benefit from hyperlinks leading to definitions or clarifications.

Masinter: [missed some]... IETF media type guidelines prohibit changing a media type registration so as to invalidate content that was previously valid

<annevk> specifically: http://tools.ietf.org/html/rfc4288#section-9

<pimpbot> Title: RFC 4288 - Media Type Specifications and Registration Procedures (at tools.ietf.org)

<annevk> "When review is required, a change request may be denied if it renders entities that were valid under the previous definition invalid under the new definition"

LMM: When Dan C. and I worked on the text/html media type RFC, we noted practice such as writing to specific implementations, with plugins, etc. ....
... that seems valuable text to keep
... [something about which version of HTML features were introduced in.] This history is useful.
... updating a media type registration requires going thru the same process that created the original. [scribe is losing the thread]
... a document that says "there were these versions of HTML; now there's a new one: HTML 5"
... would be good.

Paul: I hear you saying (a) there's historical material in the text/html media type spec that shouldn't be removed

[scribe missed (b)]

annevk: "When review is required, a change request may be denied if it renders entities that were valid under the previous definition invalid under the new definition" -- RFC 4288

LMM: it's not only that old valid content should stay valid, but that old specifications as a whole are still relevant.

PaulC: so your suggestion is...?

<Hixie> ack

<Hixie> Zakim: ack

<annevk> lets play HTML5 the movie

LMM: I asked that the media type registration be taken out and handled [later? after PR?]

<Zakim> Hixie, you wanted to point to section 1.4

Hixie: I think section 1.4 of the current HTML 5 spec subsumes the history from the registration

<pimpbot> Title: YouTube - HTML5 trailer - Find your Hero (at www.youtube.com)

TimBL: as Director, I point out that mime type registration should be *inside* the spec, not separate, to prevent inconsistencies.

PaulC: noted.

Embedding data in HTML Documents

<timbl> It seems to me that Larry is asking for the MIME-type registration information to include the history of the previous specs. I think that also the spec says that it reckons to be back-compatibl anyway to a large extent. It seems reasonable to put the history in an appendix.

<Julian> TimBl, the spec does not define things that were valid before, for instance @profile

NM paraphrases "General concern with inclusion of data capabilities ..." from http://www.w3.org/2001/tag/2009/11/TAGHTMLTopicsList.html

<pimpbot> Title: Discussion Topics for HTML / TAG working group meeting at TPAC 2009 (at www.w3.org)

for reference:

issue-53?

<trackbot> ISSUE-53 -- Need to update media type registrations -- RAISED

<trackbot> http://www.w3.org/html/wg/tracker/issues/53

<pimpbot> Title: ISSUE-53 - HTML Weekly Tracker (at www.w3.org)

Lachlan: use case for data-* : it's for data in a document for use by scripts.

NM: does it come in the source? or is it synthesized by scripts?

LH: both... [complicated?]

NM: to what extent do RDFa and data-* overlap?

<timbl> timbl+ to mention name/clash/space issues from the TP debate

MJS: they do overlap somewhat, as well as microformats...
... all these mechanisms provide data for consumption by 3rd parties...

[script got the above wrong, evidently...]

MJS: the use case for data-* is for private-use data...
... we found that script libraries made up invalid attributes to store data in...
... so data-* is a way to make that usage conforming.
... but could someone use this to publish data? well, sure, but that's not the intent. <p> can be abused too, of course.

<Zakim> timbl, you wanted to mention name/clash/space issues from the TP debate

TBL: so let's take FBML as an example... with <fb:my-friends>...
... that's extending the language... it's part of the meaning of the page.
... they're using script libraries to invent new elements [?]
... it's private in the sense that it's not specified by the HTML spec, but from the point of view of someone using the extended language, they're [ETOOFARBEHIND]

Hixie: that would be abuse of data-*; other mechanisms serve that use case significantly better

<MikeSmith> it seems likely that a not-insignificant number of authors will in fact misuse the data-* attributes; at least it seems more likely that authors will misuse data-* attributes than that they will restyle a <p> element to become a list item [Maciej's example]

<Zakim> tantek, you wanted to mention practical experience of microformats FAQ re: use of data-* attributes.

Lachy, I missed what you said; help?

<noahm> If we move on from this question, I think it's useful to agree on whether we have a direction that's likely to lead to consensus. Right now, I

<noahm> I'm afraid I'm not hearing it.

tantek: after a small amount of initial confusion, the microformats community has learned not to misuse data-*

<noahm> I hear Hixie et. al. saying "not to be used this way". Tim saying it will.

<Lachy> I said the difference between data-* and microdata/RDFa/microformats is that the latter provides shared vocabularies with shared semantics, whereas data-* attributes are completely private with no shared semantics

tx

Paul: so I hear "what are the plans for factoring microdata?"

MJS: we have a tracker issue and a change proposal to take it out; next step is a change proposal to keep it in

issue-76?

<trackbot> ISSUE-76 -- Concerns about Microdata section and inclusion/exclusion of RDFa -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/issues/76

<pimpbot> Title: ISSUE-76 - HTML Weekly Tracker (at www.w3.org)

NM: to TAG members, would it suffice to split out the microdata spec?

PC: could you give some argument/rationale for splitting it out?

TimBL: modularity...
... it'll be easier for people to read the smaller bits

<Hixie> ack

Julian: a split out spec could still be normatively referenced...

MJS: noone is advocating that

<paulc> moving on to the URI/IRI/WebAddr item

NM: how about data-*... does the same argument re factoring out apply?

[lack of response...]

DanC: I don't think so

URI/IRI/WebAddr

NM: I note LMM's change proposal, acknowledged in the HTML WG bug tracker

LMM: the technical issue I'm persuing is: does what browsers use for URLs match what other applications use? ...
... if they don't match, [something about normative references; help?]

PC: is the intent in HTML 5 that they match?

Hixie: [carefully worded answer; help?] they're designed to be a superset. [?]

PC: [some question that prompted LMM to answer...]

LMM: I think I answered that in my msg [www-tag/2009Nov/0005] ...
... we're trying to set up some confidence about the future; if we charter an IETF WG to meet some requirements, [ETOOFAST]
... I'd like to treat those [design differences between HTML 5 and IRIBIS?] as bugs...
... you can't deadlock one behind the other [?]

<MikeSmith> TimBL had to leave

<Hixie> IH: HTML5's definition of URL was intended to be a superset of IRI, and its definition of "valud URL" was intended to be exactly equivalent to the definition of IRI where their processing would be equivalent

"To what extent is Web Address being moved into IRI-bis?"

PC: it's in progress

"is the timeline for IRI work consistent with the timeline for HTML 5?"

MJS: eventually, yes, IRIBIS has to be done before HTML5 goes to REC...
... but we can make a lot of orthogonal progress on HTML 5 before then.

"Are there pieces that need to stay in HTML 5?"

[what I heard was: we hope not.]

PC: we'll find out

IH: yes, we'll figure out the boundary at some time.

LMM: I'm happy for the HTML WG issue to be closed and the remainder to be handled as bugs

<mjs> scribe mjs

<mjs> Scribe: mjs

<Hixie> ScribeNick: mjs

Language Reference / Authoring Spec

NM: I think having a good spec to a language is important
... the authoring spec is better than my worst fears
... not sure this is the best we could do, compared to something handwritten
... will this be a major deliverable with close review?

IH: first - there are two other documents we have being developed
... Lachlan's informative author's reference

<MikeSmith> my draft is at http://dev.w3.org/html5/markup/

<pimpbot> Title: HTML 5: The Markup Language (at dev.w3.org)

IH: Mike's markup spec draft

<noahm> http://dev.w3.org/html5/markup/

<noahm> http://dev.w3.org/html5/html-author/

<pimpbot> Title: HTML 5 Reference (at dev.w3.org)

<noahm> Hixie's authoring version: http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author

<pimpbot> Title: HTML5 (at www.whatwg.org)

IH: as far as my document - I haven't done as much quality assurance on the authoring annotations

<tantek> DanC - the authoring specs have been very useful to those not familiar with reading typical W3C spec-ese.

<tantek> (in my experience in talking/working with web designers)

IH: there has been some (Philip and I have both spotted errors)

<DanC> tantek, have you looked at the authoring view that hixie has come up with?

NM: what I'm hearing is that you are treating this deliverable seriously, whether or not it meets my taste

<DanC> do you know if others in the design community like it?

<tantek> BTW re: data-* attributes and microformats community understanding - here is the URL we send folks that seems to convince them to avoid data-* for data interchange: http://microformats.org/wiki/html5#data_attributes

<pimpbot> Title: html5 � Microformats Wiki (at microformats.org)

IH: one of the things I'm not sure of is who the target audience is
... I don't know of people who would are at high enough level to understand the spec, but aren't familiar with browsers

<MikeSmith> a static view of the author view of the spec is at http://dev.w3.org/html5/spec-author-view/

<pimpbot> Title: HTML5 (at dev.w3.org)

NM: one thing I noticed is many UA requirements are imperative, are there a lot of cases where that remains in the author view, or is it more declarative?

<DanC> I haven't updated that for a while, MikeSmith ; have you?

IH: fixed some cases of that, continuing to improve it

NM: thanks for the status report. let's open this up

<MikeSmith> DanC, it's automatically updated each time Hixie commits a change

PC: Henry was concerned that you couldn't create a good authoring spec from the current spec without adding more material

<DanC> ok; thanks, Mike

PC: It sounds like you *have* added some material in the process, and are willing to add more
... it sounds like we should feed that back to Henry and ask him to state what's missing

DC: are you closer to done on the authoring guide?

<Zakim> DanC, you wanted to swap Lachlan's document back in

LH: there's lots of stuff, but much more is needed

PC: I've had many people approach me saying they could use a spec like this for software that generates HTML, and is not a browser

NM: maybe more BNF

IH: there is more BNF. I think this audience is somewhat different than what I have been targeting

<annevk> should we change the media types slot now it has already been dealt with here?

IH: on second thought, maybe emitting HTML does

<Zakim> Hixie, you wanted to say duplicate normative; reason for two types of content

IH: but to validate you need parts of both

annevk, perhaps we should - not sure there is more to discuss about it

IH: I don't think that we as a working group should publish two documents that both claim to be normative for the same thing

<DanC> (I disagree with Hixie on the "multiple normative documents" issue. I've done it successfully in OWL, SPARQL, and GRDDL)

BS: we view it very favorably, our product plans for HTML5 will benefit

<DanC> (but those were quite orthogonal; i.e. spec and test-suite-document)

LM: one thing that's important for creators of documents that use scripting is the programmer view of the API as opposed to the implementor view

<Hixie> BryanSullivan: radio buttons are at the top right of http://whatwg.org/html5

<pimpbot> Title: HTML5 (at whatwg.org)

LM: example: image width

<DanC> what was the "it" that Bryan was referring to?

LM: explained implementation details, was not so clear for someone trying to use the API rather than implement it

<annevk> silvia, maybe you should make it another video slot :)

DanC, he didn't exactly specify but I assume BryanSullivan was referring to the authoring-focused specs

<BryanSullivan> Correct

<DanC> hm

<BryanSullivan> But the guidance is appreciated

<DanC> the TAG isn't of one mind on this.

<DanC> non-normative is fine for me.

<annevk> (having said that, it seems like I'll attend the bit on caching)

MS: I want to propose an action for the TAG: would it be acceptable to produce a language reference as a non-normative document?

NM: to ask for clarification, which document do you mean?

MS: I mean if there's a document that is not a view in the spec, just a definition of a conforming document

NM: I will put any proposal before the TAG that you can describe

<DanC> I think of Mike's document as "a schema-based description of HTML 5" and I'd be happy to see it published non-normatively.

MS: specifically I mean my H:TML document, aimed at producers only

NM: for me personally, that's ok, and I'm willing to put that before the TAG

<Kai> If the difference between these two documents is so subtle, it probably is not such a good idea. If it can be made clear what the diff is, then yes.

SR: would be useful to have the input because then we can decouple and execute

<hober> I'm all for MikeSmith's document being published non-normatively. Mike, have you changed your mind since http://krijnhoetmer.nl/irc-logs/html-wg/20081118#l-207 ?

<pimpbot> Title: IRC logs: w3c / #html-wg / 20081118 (at krijnhoetmer.nl)

<MikeSmith> hober,I change my mind all the time

<hober> :)

adjourned

Caching

<MikeSmith> scribe: MikeSmith

URL for Nikunj's slides?

<annevk> http://dev.w3.org/SVG/modules/param/master/Invisible_Pink_Unicorn.svg?color=deeppink

<pimpbot> Title: Invisible Pink Unicorn (at dev.w3.org)

Nikunj walks us through his slides

slide - Desired Offline Data Features

<Zakim> masinter, you wanted to ask about about writing API calls vs. implementing API calls

ask MikeSmith

BryanSullivan: is the datacache on the device?

Nikunj: yes

jr: could just be the HTTP cache on the UA?

Nikunj: the key part is that the cache can be controlled programatically

<Zakim> MikeSmith, you wanted to respond

BryanSullivan: so you want to make it transparent as possible?

Nikunj: Yes, to make it seamless

??: how's that different from normal HTTP cache or offline-apps ApplicationCache mechanism?

<Lachy> MikeSmith, huh?

<Lachy> MikeSmith, I didn't say that

???: feel free to fix it

<Lachy> I don't know who said it

NM: [discusses use case of off-line photo album]
... efficiency of updates is a concern
... [explains HTML5 ApplicationCache]

BryanSullivan: is the datacache going to act like a local server?
... or not really
... so you want controlled cache lifetime
... application control

<pimpbot> bugmail: [Bug 8210] New: Add drawFocusRing(x,y,w,h,element) which, if element is focused, draws a system focus ring at x,y,w,h. <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0055.html>

cardona507: is there a spec'ed limit on the size of an HTML5 application cache?

Hixie: no, [because the practical limit is device-dependent]

NM: [discusses off-line attachments use case]
... [discusses use case of offline data format conversion]
... [use case of blog client]

<tantek> regarding the Off-line data format conversaion use case of converting to iCal - I know a few things about that ;)

<tantek> e.g. http://h2vx.com/ics/ will convert pages with hCalendar to iCal format so that the events can be added to a native calendar application.

<pimpbot> Title: H2VX: hCalendar to iCalendar (at h2vx.com)

<tantek> also, in Firefox, it has already parsed the hCalendars on the page, so you could have a javascript: hyperlink extract that information from the DOM and redirect to a data: URL of type text/calendar with the iCal data inline.

<Bert> (I think the name of the proposal is wrong. It's not a cache, it's data replication.)

<Julian> it would be a proxy that allows offline work

<tantek> Bert, I think cache is correct because he is implying ephemeral expectation of data availability, rather than reliable replication

BryanSullivan: so you are saying, "I am programatically queuing up data that will be sent to the server once you get back online?"

Julian: I have a problem understanding how that will work in practice [for particular cases]

NM: what URI gets minted is up to the application
... [use case of co-existence and error recovery]
... you want the user to be alerted _before_ the sync cycle is complete
... reporting errors earlier reduces the problems with recovery
... [discussing offline authorization use case]
... DataCache API spec is in FPWD in WebApps WG

http://dev.w3.org/2006/webapi/DataCache/

<pimpbot> Title: DataCache API (at dev.w3.org)

<Zakim> tantek, you wanted to mention that Firefox + Operator solves the offline iCal format generation problem.

tantek: in practice this is one in a couple different ways
... client-side plugin is one -- like Firefox Operator extension
... other way is to do is on the server side
... so how is this proposal better than existing mechanisms [that already address these use cases]

NM: effectively you can think of it as a portable local server that can respond to network requests

tantek: so it's like Opera Unite?

annevk: this is in the context of the Web application, whereas Opera Unite is a user-controlled mechanism

<inserted> cardona507: [asked if there was a similar network and fallback mechanism similar to appcache: NM responded, Not currently]

NM: it is possible to bypass the datacache, by the user.. and possible to bypass by XHR

Hixie: I agree with all the use cases
... and Google has many more use cases [for client-side caching]
... I think it fits pretty well with ApplicationCache, but I think it's too early to consider adding this [DataCache] to the platform

mjs: I agree with Hixie that we should be careful about how to stage the addition of new features
... AppCache has been shipping for more than a year
... people are building businesses around it
... and building serious stuff on top of it
... I would like to see two solid implementations of AppCache that we can demonstrate are interoperable
... then look at the pain points that developers who are using AppCache have run into [and consider adding additional features to address those]

annevk: [discusses a case of how to handle a page with an image that gets removed from the cache]

Hixie: yeah, it's not yet bug-free.. which is why I worry about [putting new features into it now]
... [points out that existence of a draft spec can sometimes cause features to get implemented prematurely]

mjs: some features are of the kind where implementing the first 80% is pretty straightforward to implement, but last 20% is much more problematic

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

[Nikunj completes his presentation ]

<pimpbot> bugmail: [Bug 8211] New: HTML 4 defined these as entities &name; where the ";" wasn't part of the entity name, and there wasn't a variation that some names don't have ";". If this is an example of error recovery, valid HTML should require the ;. <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0056.html>

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

<pimpbot> bugmail: [Bug 8212] New: gggfgfgfgfgfgfg <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0059.html> 4** [Bug 8210] Add drawFocusRing(x,y,w,h,element) which, if element is focused, draws a system focus ring at x,y,w,h. <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0058.html> 4** [Bug 8211] HTML 4 defined these as entities &name; where the ";" wasn't part of the entity name, and there wasn't a variation that s

<hsivonen> was it pointed out to the TAG that "XML document" in HTML5 means a tree while in XML 1.0 it means a stream?

<mjs> hsivonen: their complaint was that the term "XML document" was not linked to a definition, so I'm not sure citing different definitions would have helped

<pimpbot> bugmail: [Bug 8212] gggfgfgfgfgfgfg <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0063.html> 4** [Bug 8216] New: editorial: Hide "The name must be one that is terminated by a U+003B SEMICOLON character (;)." and relevant rows in the entity table from the author view. [sp] <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0062.html> 4** [Bug 8211] HTML 4 defined these as entities &name; where the ";" wasn't par

<pimpbot> bugmail: [Bug 8218] New: No, this algorithm cannot be aborted, as there are no synchronous events from which to call load() <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0064.html>

<myakura> http://spreadsheets.google.com/ccc?key=0Apvkq1IRZaQVdEFieXBXVHVkVWZaWlFNVDJpU1I2eGc

<pimpbot> Title: Welcome to Google Docs (at spreadsheets.google.com)

<Hixie> thanks!

does anybody recall who proposed the RDFa and Microdata session?

we need somebody to chair the session

<brutzman> X3D slides (in wiki form) available at http://www.web3d.org/x3d/wiki/index.php/X3D_and_HTML5_Summary

<pimpbot> Title: X3D and HTML5 Summary - Web3D.org (at www.web3d.org)

<cardona507> good morning everyone

<brutzman> X3D slides (in wiki form) available at http://www.web3d.org/x3d/wiki/index.php/X3D_and_HTML5_Summary

<pimpbot> Title: X3D and HTML5 Summary - Web3D.org (at www.web3d.org)

<paulc> Handing out Web3D DVDs

<Kai> +1 to mjs

<annevk> Kai, we're using #html-wg2 ;-)

<pimpbot> bugmail: [Bug 8210] Add drawFocusRing(x,y,w,h,element) which, if element is focused, draws a system focus ring at x,y,w,h. <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0065.html>

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

<timeless_mbp> ACTION: Kai to document use cases *ON A WEB PAGE*, or you talk to Ivan and request that he document the use cases on a web page [recorded in http://www.w3.org/2009/11/05-html-wg-minutes.html#action03]

<trackbot> Sorry, couldn't find user - Kai

<PIon> http://www.web3d.org/x3d/ X3D for Developers Page

<pimpbot> Title: X3D for Developers (at www.web3d.org)

<plh> video talks on #video now

<Travis> scribe: Travis

<scribe> scribeNick: Travis

JN: [presents tentative TC39 agenda]

weinig: Brief overview of WebIDL
... Intent of WebIDL is to give unitified place for DOM + other specs a JavaScript binding.
... want to give it as much clarity as possible
... vs. previous IDLs which were more ambiguous
... now it defines how prototypes interact...
... getter/setters for collections (not same as accessors)
... extra property semantics (e.g., [Replacable])
... would like to take it to Last Call ASAP, but understand there are more concerns.

MJS: discussed webidl in the WebApps WG meeting earlier this week.
... decided to first move existing semantics over to ES5 semantics.

AWB: Some TC39 concerns with current draft: ES binding is not what is classicly considered a language binding.

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 06 Nov 2009 (at www.w3.org)

MJS: maps to host object extensibilily

AWB: could be interpreted as colliding with ES language definitions.

weinig: Also key idea is to define what behaviors allready exist in browsers

MM: TC39 understands that for things that already exist we do need a formalism for these things...
... TC39 has been trying to narrow the gap between host objects and native objects.
... HTML5 has used the WebIDL spec to spec things that are in the gab. Many of these things are considered bad practice (name getters)
... Would like to have design contraints to see what should be avoided in future specs.

weinig: Discussed earlier this week, and decided to split out some of these "bad practices" into different parts of the spec (or make them clear)

AWB: Ideally, useful features that are host object extensions should come back into the native language.

MJS: Goal at a high level is to ultimately converge. By extending ECMAScript on one hand, and carefully control what behaviors are availble in new specs (and what shouldn't be used).
... WebIDL can be the bridge to what is considered appropriate.

paulc: Coming back to building an agenda.

MJS: Would like to add topic on Binary data and pushing it into core ECMAScript.

<weinig> annevk: you have a proposal?

<annevk> mjs has :)

<weinig> annevk: oh, you meant, "•annevk wants His binary data proposal"

paulc: Last call on the agenda?

<annevk> weinig, no, I just want to have an object in ECMAScript so I can use it :)

<annevk> responseData (or whatever) on XHR

WebIDL (10 min)

paulc: Was some agreement on trying to mark the features that are not well liked...
... Not wanting to use the word "deprecated". Call for discussion.

MM: Came up with a four-part classification for "to be avoided"

paulc: Four classes for all features or just the ones we don't like.

MM: Four categtories to mark all features (like, not like 1-3)

MJS: Possible dimensions:is this a legacy feature not recommended
... May be features in WebIDL that are highly experimental

AWB: List is: (5 items)
... "Good parts"
... "De Jour for legacy support"
... "Deprecated" (like last one, but expectation of future removal)
... "ES5's appendix B (normative (if you implement, it must be implemented as such))
... "Things considered, but rejected and why?"

MJS: Think it's worth documenting but not in WebIDL

paulc: I call this "out of scope"

AWB: I like "rejected" from IDL.

paulc: "rejected" category does not apply to anything in the WebIDL right now?

MM: If there is some feature in the current WebIDL, by inspection, we could mark such a feature right now.

AWB: Also, something in one browser but not all, that thing might be considered in WebIDL, but was rejected even though it had an implementation.

paulc: Have we applied the 5 category taxonomy to the current WebIDL?

AWB: Not yet.

MJS: Might be more useful to wait to do this until after we've recast the current WebIDL spec into ES5 parlance.
... I think distinction between "Requred for legacy" and "Deprecated" is not really sufficiently different.

paulc: Agreement on 1) recast in ES5, then 2) apply taxonomy.

MM: Let's not be too ridgid about it.. but we should get both of them done.

JO: Are there questions about what the semantics should be (currently are using internal hooks to ES specs)
... May want to get agreement in this room?

BE: Use the list

paulc: [recap main points]

MM: Was a recent shift in WebIDL where some things moved from annotations into the main grammar
... Was intended [the grammer] to be the language independent semantics; yet some of those things didn't actually apply to Java...
... Should be careful to make the syntax more language independent

MJS: Design Principle: Language independent should be in the core syntax, other things should be extended attributes.
... does this make sense Sam?

weinig: It can be fuzzy depending on the language (some have getter/setters, other don't)

Binary data in ECMAScript (15 min)

MJS: Goes to the sketchpad
... Design goals were influenced by Web APIs that would like to use binary data.
... In one case the UA has data in an internal buffer
... Would like to achieve cross-thread transfer of data.
... Approaches both point to having an immutable data store (makes it easy to transfer handles safely without copying data)
... Some mutable tricks are possible but not necessarily thread-safe or performant.

JO: Examples?

MJS: XHR to retrieve binary data.
... Would be nice to have a shared buffer

WH: What is needed over and above strings?

MJS: 1st point: lack of conceptual clarity
... Binary data is a byte, others are unicode chars
... Would be nice to not have to raise that question.

<pimpbot> bugmail: [Bug 8220] New: Remove microdata <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0066.html>

MJS: Also, not having to use a 16 bit sequence to represent octet data.
... Also ability to get immutable data out.
... to base64 encode could be hard [clarification needed]
... Other design point in my proposal was to get to the bare-minimum set of functionality

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 06 Nov 2009 (at www.w3.org)

MJS: Didn't want to have a cumbersome interface (e.g., with transcoding, hash computations, base64 encoding)
... Would like to leave that stuff out because we don't know what's needed yet.

<dmcallis> is there a pointer to this oft-mentioned proposal?

WH: I see base64 encoding as necessary.

AWB: I like what you're suggesting--providing the right primitives and allowing libraries to extend.

MJS: Most primitive conversion would be toUTF16 and back.

MM: First rollout would allow libraries to use, then see what libraries find useful then roll those things back into the standard.

WH: Must be careful--providing the wrong set of primitives could lead to bad performance problems...

MJS: Given three design proposals, what problems are left (that I see)?
... Choosing the name (not trivial)
... want to stay away from names that include the specific underlying data store...
... If you think of these as a sequences, they are octet sequences (bytes)

AWB: Some scenarios may consider these 16-bit floats, other as larger sets.

OH: focus has been mostly on String/Binary
... WebGL defines byte array, int array, etc.
... Without the underlying data store, you have to use strings to transfer the data around.

MJS: Second issue: Immutable vs. Mutable.

<scribe> ... Done via freeze() or via two types?

UNKNOWN_SPEAKER: preference is to have two types. Should have continued discussion on the list.
... Final issue, what operations are built in?
... Byte level read/write, read (immutable), memcopy
... Also see character transcoding, etc. that may be part of the initial set.
... Would like to be more strict in the initial release.

WH: How would equality work?

MM: Equality--are these primitive types or object types?
... If the data object is more like the string object, then it should be a value object (than a primitive type)

paulc: [moving on to next topic]

ECMAScript preventExtensions() and DOM objects

OH: Brought up on the list before.
... DOM objects should not support this.
... If they do not support it, then they "cannot" support it (no partial support)

MJS: Soley from a WebIDL interface, could mark it as supporting (or not) prevent extensions.

<fantasai> ScribeNick: fantasai

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 06 Nov 2009 (at www.w3.org)

?: We're not talking just about preventExtension, we're also talking about (?)

Mark Miller: readonly doesn't imply immutable. The host can change it

??: On the readonly question, in my rough translation of WebIDL to ECMASCRIPT5, most of the DOM properites become accessors sot hat the changeability of the underlying data ...

Travis L: on principle, I would really rather see a clearly defined way to preventExtensions work across all ... and not restrict it to [?]

Travis L: Web developers expect to see a consistent view of the world

MJS: You would have to have ECMASCRIPT objects prevent state changes completely unrelated to ECMASCRIPT

Waldemar: We would .. preventExtensions and prevent Freeze

Paul interrupts

JasonO: I agre that it's better to have a language semantics that applies to all objects in the lang
... I think it's possible, and the ECMAScript committee should take that on. DOM is one of our major usecases
... Freeze on an object may not prevent new prop from appearing on the obj, but it certainly can apply to properties added by script

Waldemar: Part of what's freeze and friends do in ECMAScript is they ... which it throws, you can cache it. And you can do security analysis on it, if these things can change .. breaks

<annevk> dsinger, wrong room?

Waldemar: We have additional issue swe have other issue.s For getters and setters ... what do these do if you call them something else ... consciously say that's not part fo the spec

Jason: I disagree that freeze by itself provides these invariants.
... The ES5 spec says what freeze does. DOesn't say that there's an end-to-end variant that freeze causes to be true

disagreement

Jason: prototype vs itself
... Given stat eo fDOM right now, calling reeze on dom obj, even if you call recusrsively on prot chain, it's not well-define

Mark Miller: It's well defined what the invariants are

Jason: The behavior of getters and setters can depend on mutable state that's not visible anywhere else except on the object.
... Calling it freeze if you don't know the impl of the getters and setters isn't predictable

MJS: ...

Waldemar: Freeze freezes the object. If an obj has getters and setters .. API. There asre still objects that can return different things
... this is a non-issue

somebody says something

OH: The getter itself is the only thing that's guaranteed to be constant

Mark: ... the local properties are unchanging
... If the obj has getter bhavior that it chooses to describe as data behavior, it has the choice of either frezing its describe its bheavior or rejecting the attempt to freeze
... If it accepts the attempt to freeze, then it can't describe as data prop

Jason: I object that freeze freezes the state of the obj in a very general sense

Allan: My inter of your points is that you're copying at different levels of abstraction

Allen Wirfs-Brock: It's about the meta state

scribe:

??: If I have a nodelist w/ a linked property

??: do I represent it as .. that's writeable, or do I expose as a getter

Oliver ... guarantee quality of that getter.. may vary from one obj to another

Allan: I think that q falls into domain of ES binding. That's the decision you make when defining a lang binding

Allen: Do all prop with these charactersics behave this way

Brendan: Do you have a problem with trying to propose a freeze that ... or .......

:/

?: My op is that we take on the effort of ...

Brendan: Need to spec that if you freeze what happens
... .. netapi tells you about DOM properties

?: I think that spec goes to web apps

?: I believe those issues have to be addressed in the conversion

Travis: I am satisfied with the discussion

??: By defining how attributes in general work, whether they rep getter on the obj itself or on the prototype is something that's going to be intrinsic in converting to ES5. That concept wasn't in ES3, couldn't be desc in ES3. Once we have that tool we'll have a better understanding of interaction with these meta-apis wil lbe

Sam: Without this new desc ,.. part of defining new desc will be talking with browser impl about ..
... There may be downsides to impl attributes as getters and setters

Paul: Seem to have anchored plan w/ webidl

<Travis> scribe: Travis

<scribe> scribeNick: Travis

Differences in Policy

JN: Secretary Genearl of ECMAScript should sit down with W3C contact and work out issues in IPR, other legal issues.
... These are way outside of my pay grade.
... We wanted to point out that we have these issues before we work really closely.

paulc: Are there any issues going on today that are upsetting?

JN: No, no joint ventures today.

paulc: We do work, throw it over the fence, and this seems to work for now.

AWB: Hasn't necessary been the working model up until today.
... In the past there was little to no communication between our groups.

paulc: Web developer expects to have symmetry

AWB: Many of us are associated with both affiliations (TC39/W3C)

PLH: Thanks TC39 for accepting our invitiation to join.
... We are a technical organization. We can hand off any/all documents needed (e.g., IPR)

IS: One of the issues is the IPR policy. W3C IPR policy is very well known. Also should be royalty-free.
... ECMAScript has current IPR policy--will be gettting a new one very much the same as the old.
... going to royalty free.
... Intention is to do something that matches W3C policy
... May not need memoriandum of understanding.
... Current status is not to sign such a memoriandum.

PLH: We offer the full spectrum of arrangements

IS: ECMAScript can disclose its policies (are archived already)

paulc: sounds like nothing further is needed (in this group) regarding IPR policy.

<annevk> plh-salonA, the "IPR book" is a printout of HTML5? :)

JN: We have a discussion list (es-discuss) for all things "Harmony" (3 years out probably)
... All work is going on that list

<rubys> https://mail.mozilla.org/listinfo/es-discuss

<pimpbot> Title: es-discuss Info Page (at mail.mozilla.org)

<plh-salonA> annevk, yes :)

<annevk> ouch

BE: Current work related is being cross-posted to public-script-coord

<plh-salonA> the printout is the html5 spec as of Oct 9, 2009.

<rubys> http://lists.w3.org/Archives/Public/public-script-coord/

<pimpbot> Title: public-script-coord@w3.org Mail Archives (at lists.w3.org)

BE: public-script-coord is for info related to WebIDL binding issues, but exact lines of deliniation are murky.

<sylvaing> might want to add a new spec status: "Critical Mass"

paulc: Should describe what lists are for what.

MM: Binary discussion should move to es-discuss.

MJS: Should go mostly to the es-discuss list. Not a lot of open issues in the scenarios/use cases.

paulc: participation issues?

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 06 Nov 2009 (at www.w3.org)

JN: Where some members are not also in W3C, there are some pariticpation issues.
... personally, I stayed away from plenary day because I knew I couldn't get in.
... we have at least one other member that can't really participate.

paulc: to be clear--is this because of the IPR policy of the organisation?

JN: Just concerned if we get into a relationship where we are jointly building a specification.

paulc: can't imagine doing that with out a memoriandum of understanding.

<plh-salonA> Don Bruztman, Web3D

DB: X3D graphics seems to have re-hashed some of these issues. Perhaps some of our learnings can be shared.

paulc: Summary
... Agreed upon an oral plan: Recast WebIDL in ECAMScript 5 and in parallel, describe taxonomy.
... Also address issues of preventExtensions, etc.
... Lies mostly on WebIDL delivery and specifically on weinig.
... Binary data discussion to continue on es-discuss
... Regarding Policy issues, moving to joint work will require more formalism (current ad-hoc and mailing list coordination seems OK)
... So, what are a future plans for coordination?

JN: TC39 meets every other month (F2F) mostly in the bay area.
... Try to get up to Redmond in July (it's nice there)
... Next meeting TC39 is next January, then every other month.

PLH: One point of information is that next TPAC is in November in Europe (location pending)

AVK: WebApps have some targeted meetings for specific topics.

I like F2F. Can we set something else up for next year (given that TPAC will be in Europe)?

paulc: I will leave the final decisions up to WebApps WG and TC39.

PLH: AC meeting in March may be an option. If the TC39 and WebApps wanted to meet around that time, we could arrange some extra rooms.

JN: Doesn't have to be in the bay area, but would like to keep the every-two-months heartbeat meeting if possible.

rubys: Plenty of companies in bay area that could host.

paulc: I think we're done. Thank you all!

<dmcallis> bye

JN: Please send minutes to TC39

<pimpbot> bugmail: "[Bug 8220] Remove microdata" (2 messages in thread) <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0068.html>

<pimpbot> bugmail: [Bug 8223] New: Won't this Doctype trigger Quirks Mode? <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0069.html>

predefined Microdata vocabularies

<MikeSmith> scribe: MikeSmith

tantek: [asks if anybody in the room has tried out Microdata]

tc is tantek

tc: so we are not discussing the Microdata syntax or processing during this session
... instead we're covering the related predefined vocabularies
... which are now in separate specs
... which Hixie has requested to be published as WDs
... those are: vcard, vevent, license
... these are not new inventions
... vcard and ical came from IETF specs
... around 2004 I proposed creating hCard and hCalendar
... which defined a way for representing vcard and ical in HTML
... (while the definitions of the semantics remain in the IETF specs)
... so Hixie based Microdata's vcard and vevent on hcard and hCalendar
... in the mean time, we have been working on making bug fixes to hCard and hCalendar
... so the original vocabs remain the same, and the rest of this is based on those
... but we had existing bugs, which Hixie replicated into Microdata's vcard and vevent
... so those bugs in the Microdata vocab specs need to be fixed to address those bugs

<Hixie> that last line made no sense

<Hixie> need to be fixed?

Hixie, yep

thx

<Hixie> is there a uri to documentation on those bugs in the microdata vocabs?

<Hixie> (bugs, or e-mails, or something?)

tc: the bugs are documented on the Microformats side

<Hixie> i'm in paticular interested in how they were ported over

tc: the Microdata vocabs should reference the 1.01 versions of the hCard and hCalendar instead of duplicating them

<Hixie> i didn't really look that closely at hcard when writing the vcard vocabulary, i was mostly just porting the RFC straight over

<Hixie> so i'm surprised that i ported bugs over from hcard also

<Hixie> unless they're in the vcard rfc too :-)

tc: I am behind on an action item to provide feedback to the group about this

Hixie, I think Julian said that the RFCs have been updated also

<gsnedders_> They are currently being revised, IIRC

<Hixie> oh certainly the rfcs are being updated yes

Julian: Tantek, would you be interested in publishing the hcard and hcalendar specs as work products of the HTML WG?

tc: I would be fine with that, but maybe others would object. I guess it's a question that needs to be taken to the group.

<gsnedders_> Hixie: It's a questioned of updated/revised :)

<gsnedders_> s//being/

<Hixie> that's a very confusing regexp

tc: perhaps the larger question is whether the W3C should be publishing spec for these types of vocabs at all

<Hixie> and i expect it'll confuse rrsagent no end

tc: I personally am neutral on the question of whether these type of vocab specs should be at W3C or not

<gsnedders_> it's a magic-exactly-what-I-mean-IRC-regexp :)

Julian: the text that was in the HTML5 spec previously repeated or rephrased parts of the RFCs
... so my complaint was that if the wording of those RFCs was not adequate or was incorrect, then the feedback should go to the editors of those RFCs
... so the RFCs could be updated

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 06 Nov 2009 (at www.w3.org)

tc: vcard 4 is a new version with a ton of new features
... it also has a number of bug fixes
... there are a couple of places where I diverged from the RFCs
... because the RFCs did not match the use cases
... an example of a bug/deficiency in the RFCs where Web publishing differed from the schema restrictions in the iCalendar RFC
... specifically, the RFC restricts events to having only one URL associated with them
... and when Hixie made Microdata vEvent vocab, he replicated that same restriction that's out of sync with real-world use cases of Web publishing of events
... whereas in hCalendar, we had made a change to allow an event to be associated with multiple URLs

<Hixie> yeah i just followd the rfc exactly

<Hixie> i'll fix it when the rfc is updated

<Hixie> which i understand is happening

tc: so, we are already tracking the RFCs and making decisions about where to diverge from the RFCs to bring them into closer alignment with real-world use cases
... so I would like for the HTML WG to hold off on publishing the Microdata vocab drafts until the hCard and hCalendar specs get updated
... which will either be a matter of days or weeks
... I would like to get it done in days rather than in weeks [but it will depend on how much time I can free up]
... specifically, I'm talking about the 1.01 versions
... I think the vCard 4 and iCal 5545 drafts are not enough yet to be depended on
... though iCal 5545 might be
... but, no offense to the vCard folks, but I think there's just too much new stuff in vCard 4 that it's too early to be depending on it

Julian: so another part of the perspective here is just that in general the HTML WG should avoid stepping on other peoples' specs
... I am worried about cases where other specs diverge from the RFCs

tantek: so we do diverge, but we do so in a way that enables 1-to-1 conversion back to the format specified in the RFCs

Julian: the revision of the iCal draft was published just two months ago
... the vCard draft is all well along -- can still submit bug reports about it, but it's perhaps just a matter of 6 months away from being published as an RFC
... my concern is that it's not clear that Hixie has had any communication with the vCard and vCalendar editors

http://dev.w3.org/html5/mdvcard/

<pimpbot> Title: Microdata vocabularies: vCard (at dev.w3.org)

http://dev.w3.org/html5/mdvevent/

<pimpbot> Title: Microdata vocabularies: vEvent (at dev.w3.org)

<Hixie> the vcard microdata vocab is just a direct port of the rfc, so it's not clear what communication is necessary

<Hixie> same with vevent

http://dev.w3.org/html5/mdwork/

<pimpbot> Title: Microdata vocabularies: Licensing Works (at dev.w3.org)

we move on to discussion of the "work" (license) vocab

<Hixie> (i'll be over for <progress>/<meter> discussion in 15min)

<Hixie> we're moving on to web storage here

tc: at a minimum, you have to define a processing model for cases where authors omit content which the spec says is required
... in 2000-something, a CC RDF rel vocab was created
... then in 2004 a microformat rel-license mechanism was created, and subsequently a CC rel-license
... I think that the state of things around license vocabs is not mature enough yet
... and I propose that the HTML WG should not at this point be publishing the works vocab spec at all

Julian: usually the page that you read in a browser and the feed that you read in a feed reader are generated from the same source (by a CMS or whatever)
... so as far as the Microdata Atom spec, I'm not sure that there's any problem that it's really solving
... my proposal is either fix the language in the spec to say that if you don't have sufficient information in the document to be able to generate a valid/conformant Atom instance, then the spec should say, just don't.
... or the spec should just be dropped completely
... so one specific problem is that if you don't have IDs in the HTML source document, then you can't generate stable IDs in the Atom output

mjs: the Atom spec seems to only require that ID remains stable within the Atom document instance itself

Julian: so the concern is not the case of generating the Atom output from exactly the same HTML document, but instead generating it from *almost* the same HTML document

mjs: there does not actually seem to be any conformance constraint in the Atom spec that states the requirement you're expressing

tc: there are numerous "must" requirements in the Atom spec that a problematic
... in hAtom we are going to make all those "must" fields optional (because there are many cases of existing content that lack them)
... and we will define an algorithm for generating content for them when the source lacks them

annevk: the Atom spec only talks about Atom documents
... it does not express requirements for documents from which Atom documents might be generated

Hixie: the reason it's a "should" in HTML5 is that we know it's not always possible to output a valid Atom document

Julian: so one way to address this is to remove the whole section about generating Atom output

Hixie: I think it's good to have a solid mapping from HTML to Atom (though "solid" isn't exactly the best word)

tc: but you don't really have a solid mapping

Hixie: I'm happy to add text to the spec to put out the problem
... inclusion of this in the spec was driven by use cases that were expressed in the discussions that led up to Microdata

<pimpbot> Title: HTML WG face-to-face in Santa Clara -- 05 Nov 2009 (at www.w3.org)

mjs: there are two possible reasons why this doesn't need to be in the spec
... one is whether any other part of the spec relies on this section
... second is that there is more than one possible way to generate Atom output from an HTML document
... and currently the spec makes it seem like there is only one valid way to do it
... so it seems like there may not be a strong reason for keeping it in the spec
... instead of having one or more specs layered on top of HTML5 spec (because there are multiple ways to generate Atom output from HTML docs)

Hixie: my rationale for including it in the spec is that it addresses use cases that were expressed in discussions

<inserted> mjs: because it's targeted at a different conformance class than other conformance classes in the spec, it could just as well be published as a separate draft

progress/meter

<Julian> Hixie: fallback options

<Julian> Hixie: problem with formatting of values

<Julian> like delimites after thousands

<Julian> TC: may need require <number> element

<Julian> TC: isomorphic to time element

<Julian> Hixie: progress has 6 numbers attached to it

<Julian> mjs: is updated by script anyway

<Julian> mjs: meter may be different, because there are cases for static use

<Julian> adrian: worried about fallback breaking

<Julian> adrian: testing will be costly

<Julian> Hixie: consensus to remove fallback?

<Julian> TC: <number> would be useful in many microformats

<Julian> TC: is the one missing type element

<Julian> Hixie: wanted to do <time> first

<Julian> Hixie: <time> can come without content, and then the UA is required to generate a localized

<Julian> version

<annevk> time { content:local-time() }

<annevk> (or something like that)

<Julian> there seems to be consensus in the room not to have "magic fallback"

<pimpbot> bugmail: [Bug 8225] New: Make it clear that the Atom generation section is not the only such algorithm (e.g. hAtom is fine too). <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0071.html> 4** [Bug 8224] New: Mention that it's possible for the Atom section to generate invalid Atom if there's not enough data (e.g. missing authors). <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0070.html>

<pimpbot> bugmail: [Bug 8226] New: inline review is goddamn annoying <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0073.html> 4** [Bug 8223] Won't this Doctype trigger Quirks Mode? <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0072.html>

<cardona507> here are the minutes from the <video> meeting http://www.w3.org/2009/11/06-video-minutes.html

<pimpbot> Title: HTML WG face to face, Santa Clara - video session -- 06 Nov 2009 (at www.w3.org)

MathML

<annevk> Patrick Ion: I hope this is a non-issue

<annevk> Patrick: we're grateful for the comments

<annevk> Patrick: not sure there's much that amounts to problems for us

<annevk> Patrick: the CSS color issue is because of backwards compatibility

<annevk> AVK: Isn't the CSS color module a superset?

<annevk> Tantek: I want to know!

<annevk> Patrick: we'll look into it

<annevk> Patrick: we reference Recs and not otherwise

<annevk> Patrick: that's why we don't mention HTML5

<annevk> Tantek: why would you need to mention HTML5?

<annevk> Patrick: there is some difficulty about embedding HTML in MathML

<annevk> Patrick: it has been a principle to underspecify

<annevk> AVK: I think in this specific case there was a request for better specification because it's not clear how the CSS and Math layout model interacted

<TabAtkins> The answer is "not at all", which is why MathML is profiling a subset that can use CSS Layout.

<annevk> Patrick: there has been a lot of switching between xlink:href and href

<annevk> Patrick: you can use both if you want; if there are two ways to markup links we have to admit that this is the case

<annevk> Patrick: we are specifying or describing situations we do not really control

<TabAtkins> http://twitter.com/search?q=%23csspickuplines

<pimpbot> Title: Twitter (at twitter.com)

<annevk> MJS: Shelley and one other person replied to Paul Cotton's request for initial feedback on MathML

<annevk> MJS: earlier today Shelley emailed comments (possibly collected from the list) to the Math WG without review from the HTML WG

<annevk> MJS: you should not assume these comments have consensus with the HTML WG

<annevk> Patrick: you can now send comments by November 11 to www-math

<annevk> Patrick: mention "last call" in the subject line

<annevk> Patrick: similarly for our other drafts

<annevk> AVK: I'm interested in how you ended up with xlink:href and href?

<annevk> Patrick: we tried to cover both faces

<annevk> AVK: which?

<annevk> [Explanation of how xlink:href in text/html work followed.]

<annevk> [Explanation of how XLink is not ideal followed as well and how Math probably needs to decide between Xlink and using plain attributes rather than keeping both.]

entities

<PIon> http://www.w3.org/2003/entities/2007doc/

<pimpbot> Title: XML Entity definitions for Characters (at www.w3.org)

<Hixie> html5 uses the 'html5' and 'mathml' sets from http://www.w3.org/2003/entities/2007xml/unicode.xml

<Hixie> and adds http://whatwg.org/specs/web-apps/current-work/entities-legacy.inc

<paulc> log TAG discussion on authoring specs: http://krijnhoetmer.nl/irc-logs/html-wg/20091106#l-140

<mjs> HTML5 is actually the first markup language in which I have written a correct document from scratch with no copy/paste

<paulc> rubys: this session may finish early

<cardona507> tabatkins - did you have any slides or urls from your css gradients talk?

<paulc> rubys: we may get to the closing session early

<TabAtkins> cardona507: If you have a recent (as of yesterday, 6-11-09) nightly of Firefox, my demo is at www.xanthir.com/etc/gradient.html. Otherwise, no, as the session wasn't recorded. I gave the talk again earlier today in front of a video camera, and we'll be publishing the video near future.

<cardona507> sweet - thanks - please send the video around the public html when you get it

<TabAtkins> It'll show up on twitter and such. I'll ensure that it shows up on public-html too.

<TabAtkins> gsnedder1: A girl, a camera, and three other dudes. It was hawt.

<cardona507> haha

<paulc> Wrap up section is starting

<paulc> a) Philipe - licensing

<paulc> b) Paul - AC/AB report

<paulc> c) Michael - Accessibility TF

<paulc> d) Meeting schedule

<paulc> e) Beer

action-29?

<trackbot> ACTION-29 -- Philippe Le Hégaret to follow up on the idea of a free-software-compatible license for a note on HTML authoring -- due 2009-11-05 -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/actions/29

<pimpbot> Title: ACTION-29 - HTML Weekly Tracker (at www.w3.org)

<cardona507> e) +1

11beer

<pimpbot> bugmail: [Bug 8224] Mention that it's possible for the Atom section to generate invalid Atom if there's not enough data (e.g. missing authors). <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0075.html> 4** [Bug 8225] Make it clear that the Atom generation section is not the only such algorithm (e.g. hAtom is fine too). <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Nov/0074.html>

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/lcoal/local/
FAILED: s/xunj/kunj/
Succeeded: s/cunj/kunj/
Succeeded: i/Proposed topics/scribe: fantasai
Succeeded: s/Chair/Paul/
Succeeded: s/The chair notes/Paul notes/
Succeeded: s/????/Julian/
Succeeded: s/sit/site/
Succeeded: s/Tony/Joe/
Succeeded: s/time/type/
Succeeded: s/Monterey/suite 1243/g
Succeeded: s/prifl/profil/
Succeeded: s/That spec passed IETF Last Call/That spec is past IETF Last Call/
Succeeded: s/ei/ie/
Succeeded: s/?/Rob/
Succeeded: s/friend/friendly/
Succeeded: s/MikeSmith:/MikeSmith,/
Succeeded: s/[some example; help?]/HTMLXSLT, from Henri Sivonen/
Succeeded: s/think so/think so, in particular because we want to continue to process the output with generic XML tools/
Succeeded: s/[who?]/at Deutsche Telekom/
Succeeded: s/[missed; help, Mike?]/process them with HTML5 parser frontend on an XML toolchain/
Succeeded: s/Mainter/Masinter/
Succeeded: s/on this/on the text.html media type registration/
Succeeded: s/HT/PC/
Succeeded: s/DanC:/DanC,/
Succeeded: s/hober: /hober,/
Succeeded: s/tlr/jr/
Succeeded: s/Lachy: /???: /
Succeeded: s/Lachy: how/??: how/
Succeeded: i/it is possible/cardona507: [asked if there was a similar network and fallback mechanism similar to appcache: NM responded, Not currently]
Succeeded: s/gab/gap/
Succeeded: s/?/Mark Miller/
Succeeded: s/??/Travis L/
Succeeded: s/??/Travis L/
Succeeded: s/???/Waldemar/
Succeeded: s/?/Mark Miller/
Succeeded: s/??/OH/
Succeeded: s/Allan/Allen Wirfs-Brock/
Succeeded: s/??/Oliver/
Succeeded: s/?/Travis/
Succeeded: s/teh/the/
Succeeded: s/??/Sam/
Succeeded: s/??/Sam/
Succeeded: s/PL/PLH/
Succeeded: s/spoec/spec/
Succeeded: s/not to be/need to be/
WARNING: Bad s/// command: s//being/
Succeeded: i/progress/mjs: because it's targeted at a different conformance class than other conformance classes in the spec, it could just as well be published as a separate draft
Succeeded: s/faces?/faces/
Found Scribe: fantasai
Inferring ScribeNick: fantasai
Found Scribe: fantasai
Inferring ScribeNick: fantasai
Found Scribe: DanC
Inferring ScribeNick: DanC
Found Scribe: mjs
Found ScribeNick: mjs
Found Scribe: MikeSmith
Inferring ScribeNick: MikeSmith
Found Scribe: Travis
Inferring ScribeNick: Travis
Found ScribeNick: Travis
Found ScribeNick: fantasai
Found Scribe: Travis
Inferring ScribeNick: Travis
Found ScribeNick: Travis
Found Scribe: MikeSmith
Inferring ScribeNick: MikeSmith
Scribes: fantasai, DanC, mjs, MikeSmith, Travis
ScribeNicks: fantasai, DanC, mjs, MikeSmith, Travis

WARNING: No "Present: ... " found!
Possibly Present: AVK AWB Allan Allen Anne Arron ArtB ArtB_ BE BS Bert Brendan Brian BryanSullivan Bryan_Sullivan Carlos Cynthia DB DC DanC Eliot_Graff Frank HTML Hixie IH IS Ian JF JN JO J_Voracek Jason JasonO Jeo Joe JonathanJ JuliN JuliaN Kai Kai_ Kangchan LH LM LMM Lachlan Lachy Laura MM MS Maceij Mark MichaelC MichaelC_ Mike MikeSmith NM Nikunj Noah OH Olivers PC PIon PLH Patrick Paul PaulC Philip ROBOd ROBOd2 Rob SCain SR Sam Stevef Sylvia TBL TC TL TVR TabAtkins TabAtkins_ Tantke TimBL Title Today Tony Travis VagnerW3CBrasil Vladimir WH Waldemar XMDP Yves adactio adrian adrianba alexmog an annevk aroben azunix based battletoads brutzman bugmail but cardona507 cardona507_ chaals cnilsson cshelly cyns dbaron deltab dmcallis document dom drogersuk drunknbass_work dsinger ed_work eric_carlson eric_carlson_ fantasai frankolivier gavin glenng gsnedder1 gsnedder2 gsnedders gsnedders_ gurra hober hsivonen ht html-wg https inimino inserted jallan jeanne jgraham joined jorendorff jr jun karl kawata kford kohei krijnh krisk left maciej manu marcin masinter mattmay mduran mechanism mjs mjs_ mnot mth myakura noahm not oedipus of oliver oliver_ pererik phenny pimpbot planet plh-salonA portals prolix rel-profile rubys samth satoshi scribeNick shelleyp shepazu shiki shiki_ signing silvia silvia1 soonho specifically sylvaing tH tantek thugbot timbl_ timeless_mbp timely tlr tobyx trackbot tross veosotano w3org webspinner weinig wendy wonsuk world xover yfukami
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 05 Nov 2009
Guessing minutes URL: http://www.w3.org/2009/11/05-html-wg-minutes.html
People with action items: kai steve tony