See also: IRC log
<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
<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)
<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)
<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
<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.
<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
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
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
<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
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)
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]
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
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>
<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
<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)
<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.]
<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[End of scribe.perl diagnostic output]