01:29:32 Lachy has left #xhtml 01:34:59 Lachy has joined #xhtml 13:51:12 RRSAgent has joined #xhtml 13:51:12 logging to http://www.w3.org/2007/11/09-xhtml-irc 13:51:21 rrsagent, make log public 13:51:46 Meeting: XHTML2 WG FtF, Cambridge, MA, USA< Day 2 13:51:55 Chairs: Steven/Roland 13:52:02 Chair: Steven/Roland 13:52:11 s/USA>/USA,/ 13:52:35 Present: Steven, Roland, Rich, Nick vd Bleeken 13:53:19 Hi there Oedipus 13:53:26 Present+Gregory 13:59:27 Roland_ has joined #xhtml 14:02:54 Present+Tina 14:04:23 rrsagent, make minutes 14:04:23 I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven 14:04:29 Scribe: Steven 14:05:53 s/USA Topic: role 14:07:23 Rich; There is the issue of whether we are OK with the role attribute being chameleon 14:07:31 \s/;/:/ 14:07:34 markbirbeck has joined #xhtml 14:07:35 s/;/:/ 14:07:44 Present+MarkB 14:07:48 hi Mark 14:08:21 Roland: Why wouldn't we? 14:08:44 Steven: Well, it's just that modularization says you can't 14:08:57 Roland: So then we have to change that rule in modularization 14:08:59 Hi everyone. 14:09:01 :( 14:09:53 Steven: I don't think I feel strongly either way. Class is similar in some senses. It is in other specs, and it 'means' the same, and it is spelled the same 14:10:48 Roland: I was actually suggesting that we create role outside of modularization, and then create a modularization module that imports that 14:11:56 So Oedipus, was that frowny to mean that you don't support chameleon role? 14:12:17 i'm intrigued by roland's suggestion 14:12:39 Well, people want to have it in their spec without having to namespace it 14:13:02 rather than 14:13:25 the frown was because modularization said we couldn't, but what would changing that rule in modularization entail -- ramifications? 14:13:27 Roland: So people have the choice of which of those two forms they care to use 14:14:06 Well, Roland is suggesting just changing it for role 14:14:10 ok 14:16:00 Rich: So what can we do? 14:16:12 When @role appears without a namespace in another language, it is because that language has added it to its own language. Just like @class in SVG is *not* @class in HTML, but they have given it the same semantics to make it easier for people to use. 14:16:15 Roland: We just put it back through last call with the change made 14:16:24 Steven: Short three weeks. 14:16:31 ROland: THe question is, one spec or two? 14:16:42 So all we have to do is what we discussed the other day--remove the restriction that "you can't use our stuff unless you namespace prefix it". 14:16:50 gut feeling is one 14:17:01 It's your language...you do what you want with it, is the point. 14:17:05 Steven: I would prefer just one, with an ENglish sentence "Rule 2.5.1 of modularization does not apply to this attribute" or somesuch 14:17:08 Roland: GOod 14:17:11 yes 14:17:15 +1 from GJR 14:17:33 Let's solve this for all of our modules, though. 14:17:55 Present+Christina Bottomly 14:18:09 Steven: This is our newest member, Christina 14:18:18 ... she is going to help with our specs and tutorials 14:18:31 Christina: I am based in New York, and work for STC 14:19:29 What was the question "one spec or two" about? 14:19:46 Whether to have a non-modularization role, and a modularization role 14:19:59 s/GOod/Good/ 14:20:53 http://www.w3.org/TR/xhtml-modularization/xhtml-modularization.html 14:22:07 http://www.w3.org/TR/xhtml-modularization/xhtml-modularization.html#s_conform_document_type 14:22:13 Rule 5 in that 14:22:23 s/2.5.1/3.1.5/ 14:22:38 "The schema that defines the document type may define additional elements and attributes. However, these MUST be in their own XML namespace [XMLNAMES]. If additional elements are defined by a module, the attributes defined in included XHTML modules are available for use on those elements, but MUST be referenced using their namespace-qualified identifier (e.g., xhtml:class). The semantics of the attributes remain the same as when used on an XHTML-namespace eleme 14:23:05 Steven: So it is the last MUST that changes 14:23:31 Steven: Not sure how Shane feels about this change 14:24:12 Steven: So change the MUST to a SHOULD? 14:24:19 [General nodding][ 14:24:27 s/][/]/ 14:24:49 Roland: We did this with xml:id 14:25:32 Steven: But exactly the other way round 14:27:01 Steven: So the reason we went for xml:is is that it was generally processable WITHOUT knowing anything about the enclosing language 14:27:25 ... what we are doing is now the opposite: you have to know the language to know whether @role is our role or not 14:27:30 ... so it is worse really 14:27:38 ... it is less generally applicable 14:28:05 s/xml:is/xml:id/ 14:28:23 ROland: But they have the choice to do the right thing or not 14:28:48 so would MUST to SHOULD be a "best practices" convention -- you don't have to, but you really probably should, unless you're lazy, ignorant or just don't give a damn? 14:29:54 I think so oedipus, yes 14:30:27 Roland: THere is enough rope for people to hang themselves with 14:30:32 s/TH/Th/ 14:30:48 hmmm... well my catagorization covers some cases we already know about... 14:31:10 Steven: So M12N is on the brink of transition, so do we make that change before the transition? 14:31:25 Roland: Yes. It is a relaxation, so it won't break anyone's software 14:31:48 +1 -- i think that may be a MUST not a SHOULD 14:32:49 I don't quite understand what you are saying Oedipus 14:32:54 Here is the old text: 14:33:08 "The schema that defines the document type may define additional elements and attributes. However, these MUST be in their own XML namespace [XMLNAMES]. If additional elements are defined by a module, the attributes defined in included XHTML modules are available for use on those elements, but MUST be referenced using their namespace-qualified identifier (e.g., xhtml:class). The semantics of the attributes remain the same as when used on an XHTML-namespace eleme 14:33:15 and here is the proposed new text: 14:33:25 "The schema that defines the document type may define additional elements and attributes. However, these MUST be in their own XML namespace [XMLNAMES]. If additional elements are defined by a module, the attributes defined in included XHTML modules are available for use on those elements, but SHOULD be referenced using their namespace-qualified identifier (e.g., xhtml:class). The semantics of the attributes remain the same as when used on an XHTML-namespace ele 14:33:58 i think we need to add the new text before M12N transition 14:34:04 (one word has changed MUST => SHOULD) 14:34:10 OK, right 14:34:26 Steven: So it looks like we have agreement here, modulo Shane 14:34:33 Let me ping him now 14:37:28 We should change M12N, for the following reasons: 14:37:35 ACTION: Shane to change 3.1.5 in Modularization 1.1 14:38:03 Steven: Does this mean role has to go through last call again? (I think so) 14:38:03 Above, this was said: "... so it is worse really ... it is less generally applicable", referring to @role v. @xh:role. 14:40:28 I think the big problem with the way XML in general has been used, and M12N in particular is that we've assumed that all languages are the same. But it's obviously not true. Some document architecture that transfers bank details around and blends items form many different sources as transactions pass through the system is very different to mark-up used to create web-pages, and which could even be hand authored. So the fact that in HTML or SVG you have 14:40:51 The 'bank transaction' super-language can still use @xh:role. 14:41:30 ends at "or SVG you have " 14:43:01 Yes Mark, that is true, but you can't write a generic 'role' processor; it has to know which langauges import @role where 14:43:15 whereas before, you didn't need that information 14:43:27 You could just depend on seeing the xhtml namespace 14:44:00 Steven: I see that we do need to change the role module: 14:44:08 ... http://www.w3.org/TR/xhtml-role/#docconf 14:45:35 "If the host language is not in the XHTML namespace, the document MUST contain an xmlns declaration for the XHTML Role Attribute Module namespace" 14:45:48 Steven: SO we have to change that too 14:46:08 ACTION: Shane to change http://www.w3.org/TR/xhtml-role/#docconf to match 14:46:21 ACTION: Steven to put role through last call again 14:51:25 Steven: Iwas pleased to hear that the WAI ARIA stuff works in Dojo already 14:51:35 ... so I don't see the issue really 14:51:40 ... it works fine 14:52:13 the dojo examples work much better than the current mozilla samples (been doing QA on ARIA test materials for PF) 14:53:05 Steven, my point is that we don't have generic role processors on the client anyway. The only generic processing we have is server-side XSLT translations. So there's little point in gearing everything around something that hasn't happened. 14:53:17 So I'm *very* glad to see this change. :) 14:53:43 Well, role is so new. But we are putting hurdles in the way of role processors by making role harder to identify 14:54:04 Now we *can't* have generic role processors 14:54:17 but it used to be possible 14:54:26 But it wasn't. 14:54:27 so the situation has got worse not better 14:54:47 There was no architecture in place for that generic processor to hook into. 14:54:52 It was possible. You only need to know if there was a role attribute in the xh namespace 14:55:00 Exactly. 14:55:07 now you have to know the list of languages that have a role, and which elements use it 14:55:10 Like I said "there was no architecture...". :) 14:55:29 In today's technologies, how do you find something in the XHTML namespace? 14:55:42 It's circular. 14:55:58 Present+Masataka 14:56:15 You end up trying to invent a 'hook', like 'aria-' or 'xh-' to indicate it. 14:56:16 alessio has joined #xhtml 14:56:48 hallo 14:57:32 In short, as long as the biggest consumer of XHTML is actually an HTML browser, you have a problem. 14:58:18 Masataka Yakura joins the meeting 14:58:44 The fact that we can't have a generic role processor is so insignificant a problem when compared to the enormous problem created by that disjuncture...sorry to say. :( 14:58:59 Masatka: I represent Mitsue-Links Co., Ltd. 14:59:08 ... we build sites using XHTML and CSS 14:59:24 ... I am joining both this and the HTML5 working groupsd 14:59:31 s/sd/s/ 15:00:36 ShaneM has joined #xhtml 15:01:06 rrsagent, make minutes 15:01:06 I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven 15:02:04 Steven: At the TP on Wednesday, we tried to identify XHTML2 as an authoring language, you write your site once, and direct it to different devices, with accessibility, personalization, device independence all for free, or low cost 15:02:09 Present+Shane 15:02:12 Ho Shane 15:02:17 Hi 15:02:24 rrsagent, make minutes 15:02:24 I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven 15:02:41 Shane, you might like to look at the minutes, and scream and yell, or as you see fit 15:02:45 ShaneM has joined #xhtml 15:03:17 hi steven :) 15:03:31 s/Masatka/Masataka/ 15:03:49 Roland: So now we have the discussion about role, the same question applies to access 15:03:56 Steven: Should it be chameleon? 15:03:59 ROland: Yes 15:04:05 s/RO/Ro/ 15:05:26 myakura has joined #xhtml 15:05:34 http://www.w3.org/MarkUp/2007/ED-xhtml-access-20071030/ 15:05:38 http://www.w3.org/MarkUp/Drafts 15:07:46 Steven: I happen to know that the Internationalization people are talking with SVG about keys today 15:07:52 .... (key="s") 15:08:22 ... (as a side issue) 15:08:49 So shane, can you live with the decision to make @role chameleon? 15:08:57 s/shane/Shane 15:09:15 few things this group could possibly do would ever effect my ability to live. 15:09:16 ... and change the MUST into a SHOULD 15:09:22 lol 15:09:40 especially if you don't come to meetings ;-) 15:09:52 alessio has joined #xhtml 15:10:02 but could they affect your will to live :-) 15:10:02 Present+Alessio 15:10:10 rrsagent, make minutes 15:10:10 I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven 15:10:14 note that making this change to M12N will require our returning to last call 15:10:40 the thinking was 3 weeks LC, right? 15:10:42 Are you sure? 15:10:59 because it won't invalidate any software or documents 15:11:13 am I sure that changing the requirements of M12N so that any attribute in the xhtml namespace can be magically imported into any other namespace with the same semantics rquires a new last call? oh yeah. 15:11:33 it changes the requirements for behavior on xhtml family user agents 15:11:50 in that they MUST recognize attributes that look like XHTML as being XHTML all the time. Somehow. 15:12:07 But M12N only defines syntax, not behaviour 15:12:59 Roland: If Shane is right, and it means a new last call, then I think we should only do it for role, and say that rule 3.1.5 doesn't apply only in that spec 15:13:15 no it defines the behavior of xhtml family user agents - see section 3.5 15:13:42 oh wait... interesting. 15:14:27 http://www.w3.org/MarkUp/2007/ED-xhtml-modularization-20071002/conformance.html#s_conform_user_agent 15:15:38 Steven: I don't see it 15:15:51 question: if I extend XHTML 1.1 with my own elements and I want to use role on those elements, current M12N says I MUST reference role as 15:15:59 ... why this change would affect any XHTML conformant software or documents 15:16:00 orr we develop two specifications, 1) Role attribute that defines an unnamespaced attribute, 2) An XHTML Role Attribute Module that incorporate the "Role attribute spec" into a very similarly named XHTML Module. Just lots of work which we can hopefully avoid. 15:16:34 yes, and we are now saying that is fine 15:16:50 or at least, OK< though the other form is preferable 15:16:58 okay, then that is a conformance change on conforming user agents 15:17:05 It is like everyone has @class, which is actually the same one 15:17:17 spelled the same, has the same effect 15:17:28 but in different namespaces 15:17:31 because of section 3.1 clause 5. 15:17:54 yes 15:17:57 a current conforming user agent will not expect that "role" == "xh:role" semantically 15:18:04 we want to change the MUST there into a SHOULD 15:18:36 Well, it can't identify it syntactically, it has to use other knowledge to identify that they aqre the same 15:18:46 I understand. I dont care - I am just pointing out that this change is a conformance change for user agents because they were not previously required to interpret them as the same. 15:18:58 that is why xh:role is preferable (there is no doubt it is the same) 15:20:57 In reality thoughm anyonecan create a language with the element 15:21:09 and just *say* it is the same as the XHTML role 15:21:17 "because we say so" 15:21:31 so all we are doing is accepting that 15:21:37 anyone can say so 15:21:40 yes. and that's why chameleon namespaces are BAD. 'cause they can also say "it is NOT the same" and an ARAI aware browser would have no way of knowing the difference 15:21:56 Yes, you are right there 15:21:56 but whatever. you all do what you think is best. I will happily implement it. 15:22:08 I hear the magic words 15:22:17 RESOLUTION: allow role to be chameleon 15:22:25 "The bar is open" ? 15:22:29 lol 15:23:04 Steven: do we agree that M12N does not need to go through last call again? 15:23:29 ... we are required to say what has changed since the last transition 15:23:38 ... so the change will be pointed out 15:23:56 I agree. 15:24:02 to what? 15:24:16 I see 15:24:21 that we don't need to go to last call 15:24:22 good 15:24:52 ok 15:25:03 Roland: Does the same apply to the access element 15:25:08 s/element/eleent? 15:25:14 it doesn't affect XHTML-based user agents, since they can already use @role, and it doesn't affect non-XHTML based user agents, since they will be using @xh:role. But going forward, it allows SVG to use @role, and say that it's the same as @xh:role. 15:25:19 s/eleent?/element?/ 15:25:29 (My comment is in relation to LC, not access.) 15:25:33 yes 15:25:47 Roland: Let us leave as is now and see who screams 15:25:55 ... publish as-is 15:25:55 Leave what, as is? 15:25:59 Access 15:26:14 don't change the M12N rules for access (yet) 15:26:29 err.... 15:26:41 It should be usable in other languages without a prefix, if that's what people want. 15:26:50 if we are changing M12N, then we perforce are changing all modules. role, access, whatever. 15:26:59 +1 to Shane. 15:27:06 we have only changed the rules for attributes today 15:27:22 We're fundamentally changing our philosophy, after all. 15:27:56 we could 15:28:31 is there an equivalent rule for elements? 15:28:36 The logical ramification of this change is that in ANY XHTML HOST LANGUAGE any non-xhtml elements can use attributes from XHTML Attribute Collections in an unqualified form. 15:28:49 I don't think we have the same rule for elements 15:28:58 Maybe someone can point me to it 15:30:08 actually XML has that rule. we dont need one 15:30:36 elements are in a namespace. Whatever the default namespace is dictates the form of elements referenced in a document. 15:31:05 But do we have a rule that says that elements defined here MUST be in the XHTML namespace? 15:31:16 I don't see that rule anywhere, but I may have missed it 15:31:27 (I see it for attributes) 15:31:56 If not, then we don't need to discuss it 15:32:11 karl has joined #xhtml 15:32:23 OK, so what is it that we actually want to allow? Once we agree on that we cxan decide which rules need to be added/changed/deleted. 15:32:53 Roland, if you use a module, that you can import it into a different namespace 15:33:22 ie that the definition of the namespace is not hardwired in the module 15:33:38 For elements too? 15:33:38 Roland: FIne with me 15:33:49 Shane, yes, that is the discussion 15:34:45 s/cx/c/ 15:35:39 It was absolutely the intent that XHTML M12N module elements are in the xhtml namespace. 15:36:16 Yes Shane, but does it *say* that? 15:36:30 We may have intended it, but not required it 15:37:08 Steven: Looking at the time, and that we have a session with the HTML WG at 11, maybe we should break for coffee now 15:37:26 Well - in fact we may explicitly permit the opposite. See section 3.3. clause 5 15:37:34 Question - we want to talk about future meetings; who will be around later to join that? 15:37:50 http://www.w3.org/MarkUp/2007/ED-xhtml-modularization-20071002/conformance.html#s_conform_module 15:38:57 I suspect this was to permit the SVG use of "a" and "p" but I dont remember 15:40:37 We are breaking for coffee, and html wg session 15:40:43 watch this space 15:40:56 The implication of this text, to me, is that XHTML Family Modules define their elements (and attributes) in a namespace, but that other modules are permitted to import them into another namespace as long as the content model remains the same or expands. 15:40:57 ok 15:42:24 steven, do you intend also future FTF's? 15:43:33 because I would like to propose a possible FTF in Venice, Italy 15:46:11 maybe with PF and GRDDL WGs 15:57:29 You are probably all out having fun, but I'd like to make two comments on the 'M12N modules in other languages' discussion, ready for your return. :) 15:58:39 The first is that, when I did my work on the M12N schemas, I was using XForms, MathML and SVG as my 'case studies' in order to get things 'right'. Some of the changes that myself and Shane then made to M12N were based on this experience of trying to mix languages, and I don't think there were any severe limitations that would prevent us from taking a much more 'mix and match' approach. 16:00:19 Second, over in RDFa-land we've been having discussions with the Open Document people, and they are keen to incorporate RDFa into ODF. They are going to import the attributes into their own namespace, as we've just been discussing, but we should do everything we can to ensure that they can use 'our' modules. 16:01:10 Note that the schema implementation of XHTML M12N uses "late binding" to define the namespace, just to accomodate this. 16:01:12 (I.e., as opposed to having to 'copy' the modules, in order to get round limitations imposed by the modularisation framework.) 16:01:19 Yes. 16:02:25 It's a shame that it's 'the modularisation of XHTML', because what we really have is a 'modularisation framework', and then a bunch of modules defined in the XHTML namespace. But other people could create a module in a different namespace, and make it 'modularisable'. 16:05:01 myakura_ has joined #xhtml 16:05:47 GJR +1 to f2f in venice with PF and GRDDL -- perhaps add devs of EARL, ERT (http://www.w3.org/WAI/ER/) -- been good interaction between EARL and GRDDL, but don't know if each is aware of the other's progress 16:05:59 and many people have, Mark 16:06:59 also RDFa, gregory... 16:07:11 yes, good point, alessio 16:08:29 seriously, your remarks about a modularization framework are quite rich food for thought... 16:08:49 Shane...who has? 16:09:47 mathml? svg? jabber? 16:10:22 xforms 16:13:55 our framework was ALWAYS intended for use by other groups. we were chartered to create a pluggable architecture long before there was a CDF group 16:16:43 myakura has joined #xhtml 16:18:24 karl has left #xhtml 16:24:55 we are back 16:27:24 CSB has joined #xhtml 16:27:47 CSB=Christina Bottomly (new WG member) 16:29:54 hi! 16:30:24 Shane, but the pluggable architecture is for XHTML-based languages. 16:31:04 Rich has joined #xhtml 16:31:05 My point is that the architecture should be for *any* language that one might want to create. 16:31:47 +1 to architecture applying to ANY language 16:31:48 (We may be agreed that this is a desirable goal. :) I'm just saying that at the moment that isn't what XHTML M12N does...it's currently 'the modularisation of XHTML'.) 16:32:23 In fact, we did produce a general modularization architecture, but we were only *chartered* do do it for XHTML, hence the name 16:32:35 but indeed, the intention was to use it for any markup at all 16:32:47 It is only our *modules* that carry the XHTML Namespace 16:33:04 SO you can use M12N for *any* namespace 16:33:10 Mmm...I think you might be reading history backwards. But it doesn't matter. :) 16:33:11 as has been pointed out by and to the TAG 16:33:31 It was a CYA that we named it XHTML Modularization 16:33:52 we long discussed whether we should call it XML Modularization 16:34:03 and decided against it for political reasons 16:34:18 +1 to Venice Alessio 16:34:22 all for it 16:34:30 no better place on earth for a FtF 16:35:39 so, we strip out the ML-specifics and deliver a note/WD of XMod - The Extensible Modularization Module? 16:36:09 Well Oedipus, if you look, that is already there 16:36:25 Originally there were two specs - the modularization architecture and the modules 16:36:33 we decided eventually to merge them 16:36:42 but the split is still in the document 16:36:48 Ah, sorry :-S 16:37:20 Roland: Let us not get bogged down on the mechanisms 16:37:26 ... let us focus on the deliverables 16:39:09 Roland: I think there should be a more generic structure 16:39:15 thx steven 16:39:16 ... like head and body everywhere 16:39:30 ... and a foot 16:39:44 ... so a doc can have all three, a table can 16:40:11 ... so not head body and thead tbody, but just use head and bosy 16:40:22 Steven: So our elements should depend on context 16:40:25 Roland: Yes 16:40:32 Rich: That is good for accessibility 16:41:51 Roland: I don't know how we do that in Schema, but it doesn't matter 16:42:01 STeven: That has never been a constraint 16:42:25 ROland: ANyway, I think we need a class of structure element more than block and inline 16:42:31 s/Ro/Ro/ 16:42:41 s/STeven/Steven/ 16:42:48 strong +1 to roland's class of structure 16:43:11 s/AN/An/ 16:44:47 Steven: In the past things like meta everywhere has been blocked for us by IE that puts meta in the head regardless of where it is in the source 16:45:02 ... but that is Not Our Problem (NOP) now 16:45:50 Roland: THis structure idea makes embedding much easier 16:45:55 s/Th/Th/ 16:46:37 ... because then you can compose documents much more easily 16:47:15 Steven: Yes! For instance our spec authoring system has separate files for chapters, but if each chapter is an html doc then you can't easily compose them 16:47:27 +1 to roland for me too 16:47:28 ... this would make composability a doddle! 16:47:43 [Roland steps to board] 16:48:25 Steven: And if each chapter is only an html fragment, you can't load them into html editors 16:48:32 Roland writes: 16:48:36
16:48:40 16:48:49 Heading for section 16:48:52 16:48:57 16:49:01
16:49:54 ignore last two lines of example 16:50:01 16:50:04 .... 16:50:16 16:50:19 16:50:22 16:50:27 16:53:50 Steven: What is the semantics of foot? 16:54:10 Roland: Think of tfooter, and then generalise 16:56:01 Steven: If we focus on composability, I think that will help us focus on what we are trying to achieve, and help answer questions as they arise 16:56:35 Steven: I wonder if this will affect how RDFa defaults @about 16:56:35 +1 to Venice Alessio 16:56:36 all for it 16:56:36 no better place on earth for a FtF 16:57:20 pardon, irc window is joking 16:57:23 Steven: Since currently it defaults to the document, but this might require it to default to the unit of composability (need to think about this) 16:59:01 roland, it seems like a generic , semantically could it be a sort of closing
? 16:59:29 Alession, yes, I think so, but with possible extra semantics 17:01:23 Rich: You see a lot of dics used this way now, they clearly need structure 17:01:39 s/dics/divs/ 17:02:04 Steven: Yes, though they use divs because they are completely presentation free. If there were a way to turn off all existing presentation on an element, I'm sure people would use more meaningful structure 17:02:14 ... maybe this is a comment we should send to CSS 17:02:39 ... please make it easy to unset all properties on an element, so I have complete control of the presentation 17:02:51 I understand, it should have a definite role for content, more than a possible
17:03:01 Yes Alessio 17:03:08 e.g. 17:03:09
17:03:09 17:03:09 17:03:09 17:03:11
17:03:13 17:03:15
17:03:17 17:03:19 17:03:21
17:03:23 17:03:25 17:03:27 17:03:31
17:03:33 17:03:37
17:03:39 17:03:39 People also tend to use DIVs because they don't understand the concept of semantic-bearing elements. This is a sad fact even in 2007. That's why it is, among other things, important NOT to use DIVs as example elements if semantics is involved. 17:03:41 17:03:43 17:03:45 17:03:47 17:03:49 17:03:53
17:04:26 many many uses for foot - pagination information for online text books, for example; things that users will either want to know are there, inspect/read, or want to skip, need as much context as possible to make decision, so like specificity 17:04:28 Present+Tina 17:04:31 Hi Tina! 17:04:48 Agree Tina 17:04:53 developers often use divs to design boxes and so on 17:05:20 yes,
is the hold all for web developers 17:05:28 the catch-all container 17:05:31 Rich: DO we really need the body tag? 17:05:38 Roland: It makes it explicit 17:05:39 so these elements have de facto replaced old in tableless layout 17:05:42 s/DO/Do/ 17:06:04 without a real semantic use 17:06:08 "" that's kinda how I understand it 17:06:39 Hello again, Steven. Sorry about late, it's what you might call a very traditional Swedish november weather out here, and it is playing merry hell with my schedules. 17:07:00 rrswagent, make minutes 17:07:05 rrsagent, make minutes 17:07:05 I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven 17:07:25 I would very much like to see us, atleast, avoid constructs where additional semantics - ie. semantics beyond "nil" - is attatched to DIV elements, in particular as examples. 17:09:14 Steven: On the other hand I wouldn't want this discussion to delay putting XHTML2 out as a WD now 17:09:29 Roland: Well, we should look to see if there is anything we can take out, like h1-6 17:09:33 Steven: Oh yes 17:09:33 agreed, tina, i'd rather have than
or rather than
17:09:46 Steven: And what about hr? :-) 17:09:55 ;) 17:10:08 oedipus, but don't forget RDFa and role 17:10:18 true 17:11:52 but it is strange to assign a role to something that isn't intended to convey that role, and have it function as that role not because the element contains the construct, but because a role="" has been applied... 17:12:19 oedipus: I think we ALL do! 17:12:35 RESOLUTION: We will reopen the hr discussion at a future date 17:12:55 thus overriding the previous resolution on this issue 17:14:41 TIna, I agree 100% about not using div for anything but *very* vanilla purposes in our examples 17:16:29 ROland: Oh! 12:15, lunch calls 17:16:38 s/ROland/Roland/G 17:16:48 We are breaking now 17:16:55 back at 1.30 17:17:03 (1hr 15 mins from now) 17:17:32 Alessio, Mark, how late can you stay? 17:17:42 Just so we can make sure you areound for the meeting discussions 17:17:54 future FtF, call times etc 17:18:16 I can rejoin later, because here are 6.30pm ca. 17:18:24 OK 17:19:20 have a good lunch :) 17:43:36 Some comments on the above: 17:43:47 At xx:44, it is FF that moves , not IE. :) 17:44:14 At xx:48, on composability: agree with goal (of course I would...I've been blogging about it for a long time). But a few things to say. First, ensure consistency; at xx:48 use instead of <h>, for example. Second, I'd actually come at it the other way up, and allow the <html> element to be used in other places. This means that HTML could be embedded in Atom, SVG and MathML, by using <html> but it also means we could create modular documents real 17:44:25 <markbirbeck> On yy:02...changes to CSS. :) You have to be kidding, right? 17:45:06 <markbirbeck> At yy:04, I wouldn't get too worked up about semantic and non-semantic divs; that's the kind of discussion that will keep our box of tricks irrelevant for another 5 years. We have a 'philosphy' that what we lacked in the past was not a bunch of elements, but a good set of extension points. Now we have @role and RDFa as great ways to extend documents; why now go back to adding elements? Sure, create modules that have extra elements in like <video> and < 17:45:28 <markbirbeck> s/philosphy/philosophy/ 17:59:51 <CSB> CSB has joined #xhtml 18:14:21 <myakura> myakura has joined #xhtml 18:22:49 <CSB> CSB has joined #xhtml 18:35:28 <Roland_> rrsagent, make minutes 18:35:28 <RRSAgent> I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Roland_ 18:43:34 <Steven> Agree about html element Mark 18:44:55 <Steven> Agree about adding elementsw, and that's what I said a little further down 18:51:43 <Steven> Topic: Documents 18:52:00 <Steven> Christina: We have talked about a tutorial, and a white paper 18:52:11 <Steven> Roland: We have talked about our change of emphasis 18:52:32 <Steven> ... and about developing material to explain that story to some audience or another 18:52:50 <Steven> ... we should think about who we want to address 18:53:04 <Steven> Christina: Is it time to start now, or do we need to wait? 18:53:28 <Steven> Roland: Not today, but soon, after we have worked out what and to whom 18:53:34 <CSB> so who would be the target readers? 18:54:13 <Steven> Roland: Over time we need a number of documents, for content providers, for tool producers, for pipeline makers 18:54:24 <Steven> ... to explain the possibilities for adaptation 18:54:47 <Steven> CSB: We want one to compare XHTML and HTML4/5 I suppose 18:54:59 <Steven> Roland: Showing the differentiation 18:55:39 <Steven> CSB: Showingwhat is involved, and how the transformations work\ 18:55:56 <Steven> CSB: So this is something or the next 6 months? 18:56:02 <Steven> Roland: Definitely 18:56:55 <oedipus> work with EOWG (WAI Education & Outreach) to promote adaptation/cognizance among assisstive technology vendors that this is where the future of the web lies, not in a buttoned-down non-extensible ML 18:57:16 <Steven> Steven: And I think a fresh pair of eyes on the XHTML2 spec would be advantageous 18:58:17 <Steven> Roland; The point of the abstract markup is to achieve amazing effects without changing the base; think CSS Zen Garden as example 18:59:43 <Steven> CSB: So the main audience is enterprise? 19:00:00 <Steven> STeven: But bear in mind that there are a lot of eyes on us 19:00:18 <Steven> Roland: Sure 19:00:41 <Steven> CSB: SO what features are these people interested in? 19:00:45 <Steven> s/SO/So/ 19:00:54 <Steven> Roland: I think we need to work that out. 19:00:57 <Nick> s/STeven/Steven/ 19:01:56 <Steven> CSB: Do we have anyone in this space? 19:02:04 <Steven> Steven: Well, ROland has worked in this area 19:02:19 <oedipus> entities such as those listed in yesterday's minutes? http://www.w3.org/2007/11/08-xhtml-minutes.html 19:02:23 <Steven> STEVEN STeven StEvEn 19:03:04 <Steven> s/RO/Ro/ 19:03:34 <ShaneM> ShaneM has joined #xhtml 19:03:36 <Steven> CSB: SO we need a paper that addresses what is XHTML2 and what are the differences 19:03:42 <Steven> s/SO/So/ 19:04:07 <Steven> CSB: WHo wants to nominate themself as subject expert? 19:04:12 <Steven> Steven raises his hand 19:04:19 <Steven> s/WH/Wh/ 19:04:38 <Steven> Roland: THis would be an excuse to start a wiki 19:04:53 <ShaneM> we have had a wiki action for like a year. we dont need an excuse. 19:05:35 <Steven> Steven asks systeam about status of mediawiki 19:05:41 <Steven> hi Shane 19:06:21 <Steven> CSB: Can I get a first round of features that would be compared? 19:07:11 <Steven> Roland: I would like to see the distinction between the view source principle and ease of authoring 19:07:41 <alessio> alessio has joined #xhtml 19:08:12 <Steven> Roland: But you could still provide a link to do a view source even when transformed 19:08:17 <Steven> Steven: I would like that 19:10:09 <Steven> Roland: Even if you have transformed, you can still let people see the source 19:10:27 <Steven> Steven: Yes, it doesn't have to be physically on the client machine unless asked for 19:13:24 <oedipus> but it does need to be there when asked for -- the source is the course of last resort according to the User Agent Accessibility Guidelines -- it may be needed to trigger events in an AT, such as change of voice, pitch, etc. 19:14:15 <oedipus> UAWG has an outstanding issue on this -- what does "make document source available to user" mean in mashups? 19:14:17 <Steven> Oedipus, I think that DanC has the mantra of View source for learnability rather than last-resort accessibility 19:15:02 <markbirbeck> markbirbeck has joined #xhtml 19:24:40 <Steven> http://www.w3.org/2006/Talks/05-16-steven-XHTML2-XForms/ 19:29:28 <Steven> Steven expound principles behing the design 19:29:40 <Steven> * Device independence 19:29:44 <Steven> * Accessibility 19:29:49 <Steven> * International 19:29:56 <Steven> * User experience/usability 19:29:59 <Steven> * Structure 19:30:04 <Steven> * Composability 19:30:08 <Steven> * Semantics 19:30:13 <Steven> * Separation of concerns 19:30:21 <Steven> * Extensible 19:30:26 <Steven> * Declarative 19:30:40 <Steven> Roland: The most important person is the user 19:32:55 <Rich> Rich has joined #xhtml 19:36:16 <ShaneM_> ShaneM_ has joined #xhtml 19:38:12 <Steven> Wiki requested 19:38:25 <Steven> s/expound/expounds/ 19:38:50 <Steven> Topic: Roadmap 19:39:33 <Steven> http://www.w3.org/MarkUp/xhtml-roadmap/ 19:40:14 <Roland__> Roland__ has joined #xhtml 19:41:14 <Roland__> Roland__ has joined #xhtml 19:46:57 <Steven> http://www.w3.org/2007/03/XHTML2-WG-charter 19:47:19 <Steven> Roland: So let's update the roadmap, and make sure it matches the charter 20:00:23 <alessio> steven I agree totally with principles 20:00:55 <alessio> ...what about "modularity"? 20:02:00 <Steven> Steven: We should pin transitions to FtF meetings 20:02:18 <Steven> Roland: Suppose we were to have three instead of four FtFs,when would that be then? 20:02:36 <Steven> Steven: End Jan, June, and then Mid Oct for the TP next year 20:02:55 <Steven> Roland: So LC for Access after the June meeting, and deal with LC comments in Oct 20:07:45 <Steven> Roland: XFrames 20:08:28 <Steven> Steven: I think modulo some editorial fixes it can go (need to check the DB though) 20:08:34 <Steven> Roland: Implementations? 20:09:01 <Steven> Steven: XSmiles has an implementation of one draft, the guy who was doing XForms in Flash, and Daniel Austin did it in Javascript 20:09:04 <Steven> ChrisL: 20:09:11 <Steven> Present+ChrisLilley 20:09:22 <Steven> ChrisL: Does it have a separate media type? 20:09:25 <Steven> Steven: Yes 20:09:38 <Steven> Chris: SO it would be easy to do with a Firefox extension 20:09:41 <Steven> Steven: Good point 20:09:46 <Steven> s/SO/So/ 20:10:13 <Steven> Steven: Why not make last call in Feb, after the next FtF? 20:12:13 <Steven> Roland: XML Events 20:12:44 <Steven> Rich: Is XForms looking at this 20:12:52 <Steven> Steven: The ideas do come from XForms 20:13:25 <Steven> ChrisL: SVG Tiny 1.2uses XML Events 1.0, and previously had an extended version 20:13:40 <Steven> ... let me get those extenstions to you, to get them in to the spec 20:14:42 <Steven> ACTION: Steven to get XML Events extensions for SVG Tiny 1.2 from ChrisL 20:15:01 <Steven> Shane? 20:15:12 <Steven> ShaneM_? 20:16:11 <Steven> Roland: WHat is the outlook for LC on Events2? 20:16:20 <Steven> ... we have a window of Feb or June 20:16:41 <Steven> Mark? 20:18:36 <Steven> ChrisL: Is there a dependency on DOM3 Events? 20:18:39 <Steven> Steven: Yes 20:18:59 <Steven> Chris: There is news -- the key stuff is being stripped 20:19:07 <Steven> ... and the rest is going forward 20:19:35 <Steven> Steven: Didn't that happen with DOM2 Events as well? 20:19:42 <Steven> (rhetorical question) 20:20:11 <Steven> Roland: We can return to that 20:20:19 <Steven> Roland: XHTML2 20:21:37 <Steven> Steven: Shane is jumping up and down to get this out 20:21:54 <ShaneM_> I am here 20:22:19 <Steven> Roland: Let's say December for a new WD, and then look to a serious rev for the next FtF 20:22:38 <Steven> Shane, we were missing the latest ED of Events2 on the drafts page 20:22:57 <Steven> (we were sure there was a later version than the public draft) 20:23:14 <ShaneM_> checking 20:23:59 <ShaneM_> no there has not been 20:24:18 <Steven> I could have sworn that you had said there was a rev ready to go public 20:24:24 <ShaneM_> its that one 20:24:36 <Steven> in TR space? 20:25:17 <Steven> http://www.w3.org/TR/2007/WD-xml-events-20070216/#section-eventhandlers 20:26:14 <ShaneM_> there have been no changes since then. 20:26:25 <Steven> ack 20:26:30 <ShaneM_> nor were there any comments since then as far as I remember 20:26:39 <Steven> SO ready for last call then? 20:26:43 <Steven> s/SO/So 20:26:48 <ShaneM_> looking 20:27:05 <ShaneM_> btw I think it is insane to wait a year for a last call on access. there's nothign thre. 20:27:39 <Steven> We can do it earlier, we're setting milestones here 20:27:57 <ShaneM_> okay. there is an xml events 2 comment from john boyer int he issue system 20:27:58 <ShaneM_> from 10 August 20:28:15 <Steven> Rich and ChrisL are about to send comments too 20:28:15 <ShaneM_> two actually. we need ot address those 20:28:32 <oedipus> i for one would like to hear access go to last call in a shorter time-fram 20:28:45 <Steven> ok, great 20:29:18 <ShaneM_> I have moved the event issues into the event bucket. let's see what ChrisL and Rich have to say 20:29:44 <ShaneM_> anything else you need from me? I have some errands to run with my kids (no school here today for some odd reason) 20:29:53 <Steven> So move forward to February then OK? 20:30:18 <ShaneM_> xml events 2? works for me. 20:30:26 <Steven> no that was access 20:30:31 <Steven> now done 20:31:17 <Steven> So, if we get the new comments for EVents2, do you think we can get to LC in Feb? 20:31:25 <Steven> s/So/Roland: So 20:31:32 <Steven> s/EV/Ev/ 20:31:50 <Steven> Steven: Dunno, Shane? 20:32:43 <ShaneM_> if we get the comments soon, sure. 20:32:45 <Steven> 5 mins break to get coffee, we will drink it here as we talk, brb 20:33:49 <Roland__> work on the assumption that we get all comments by end of November 2007 20:36:08 <Steven> thanks Shane! 20:36:21 <Steven> rrsagent, maek minutes 20:36:21 <RRSAgent> I'm logging. I don't understand 'maek minutes', Steven. Try /msg RRSAgent help 20:36:27 <Steven> rrsagent, make minutes 20:36:27 <RRSAgent> I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven 20:43:33 <Steven> Steven: For the RDFa schedule see http://www.w3.org/2006/07/SWD/wiki/RDFa#RDFa_schedule 21:02:22 <Steven> Topic: Role for object 21:02:48 <Steven> Alessio: I think we can put role to good use on the object element 21:03:00 <Steven> <object role="audio" type="application/x-shockwave-flash"> 21:03:22 <Steven> Alessio: Becauserole is contextual 21:03:28 <Steven> s/role/ role/ 21:04:16 <Steven> Steven: This is because several mediaformats you don't know if it is video or audio etc? 21:04:22 <Steven> Aleesio: Yes, exactly 21:05:34 <Steven> Alessio: I don't like the use of all these new elements. 21:05:48 <Steven> s/Alees/Aless/ 21:06:22 <Steven> Steven: I'd like to think longer, but it looks convincing 21:06:32 <Steven> Alessio: You can do the same with images 21:07:01 <alessio> object -> role -> type 21:08:42 <Steven> Alessio: I was looking for a solution for identifying media 21:09:41 <Steven> Steven: I'd like Mark, as implementer, to comment on this as well (he's not here at the moment) 21:10:37 <Steven> ACTION: Alessio to send a message about identifying media using role 21:12:16 <oedipus> +1 to alessio's role for object idea 21:19:55 <Steven> sort of wrapping up Shane 21:20:00 <Steven> Talking about future meetings 21:20:09 <Steven> rrsagent, make minutes 21:20:09 <RRSAgent> I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven 21:27:48 <Steven> Roland: So I propose we meet three times a year 21:28:07 <Steven> ... and break the link with the Forms WG, in order to make the locations easier for this group 21:28:52 <Steven> Alessio? 21:29:20 <Steven> Roland: So maybe Venice in February 21:29:48 <Steven> Steven: I had pencilled in June for Amsterdam 21:31:01 <Tina> Late Feb, in such a case, if possible :) 21:31:35 <Steven> If you promise to come :-) 21:32:21 <Steven> Roland: Then we have three European meetings in a row 21:32:53 <Tina> Ah, promise ... that'll be difficult. Depends on my better half :) 21:33:56 <alessio> here I am 21:34:21 <Steven> Roland: So where could we go for June? (In the USA?) 21:34:27 <Steven> Steven: New York? 21:34:32 <Steven> CSB: A bit hot 21:34:45 <Steven> Steven: Google? 21:34:52 <oedipus> ah, but then i can accomodate a few people at my place... 21:35:03 <Steven> Where oedipus? 21:35:11 <oedipus> NYC 21:35:32 <alessio> mmmm... in venice usually february is still "burning" for carnival :) 21:35:32 <Steven> Steven: There is a certain value to clustering where people are based 21:35:42 <oedipus> i live 15 miles from central park in new jersey (a.k.a. joisey) 21:35:52 <Steven> Carnival is early this year right? 21:36:01 <alessio> yes 21:36:13 <Steven> So when is Venice restful again? 21:36:27 <alessio> surely it will be full of people 21:36:39 <alessio> what about venice in june? 21:36:52 <Steven> A bit hot in June surely? 21:37:14 <oedipus> warmer than amsterdam, though :-) 21:37:44 <alessio> roberto (scano) has told me that may/june should be good 21:41:14 <alessio> anyway, from second week of february it could be more "human" to organize 21:42:01 <alessio> if you plan to make june's FTF in US 21:43:12 <Tina> Basically I am in London for business likely first and second week of feb. 3rd and 4th I should be avail. for Venice, if all goes well and my clients do not panic. 21:43:57 <Tina> June, now, that's abit too far to plan! :) 21:46:55 <alessio> carnival is from january 25th to february 5th 21:48:36 <Roland__> how about week beginning 11 Feb? 21:48:43 <Steven> ROland: How about this: Venice Feb, New York/Boston in June, and France in October 21:49:24 <Steven> s/ROland/Roland/G 21:50:06 <Tina> Although the later in Feb the better. 21:50:52 <Roland__> then how about Feb 18-20? 21:51:00 <Steven> Sounds like a plan Alessio 21:51:02 <alessio> better 21:51:33 <Steven> * 18-20 Feb Venice 21:51:56 <Steven> * Mid June NY or Boston 21:52:39 <alessio> good, so we can propose it to PF and RDFa too if you agree... 21:52:43 <Steven> * s/Mid/16-18/ 21:53:00 <Rich> Rich has joined #xhtml 21:53:07 <Steven> * October France 21:53:29 <Nick> http://www.w3.org/2008/10/TPAC/Overview.html 21:56:12 <Steven> So we need a volunteer for hosting in June 21:56:27 <Steven> s/So/Roland: So/ 21:56:36 <Steven> Steven: Hmm, Shane maybe ;-) 21:56:44 <Steven> Bye Tina 21:56:47 <Steven> Thanks for being here 21:56:53 <alessio> goos night tina :) 21:58:00 <alessio> s/goos/good/ 21:58:17 <myakura_> myakura_ has joined #xhtml 22:02:06 <Rich> Rich has joined #xhtml 22:09:42 <Steven> ADJOURNED 22:09:51 <Steven> rrsagent, make minutes 22:09:51 <RRSAgent> I have made the request to generate http://www.w3.org/2007/11/09-xhtml-minutes.html Steven 22:10:11 <oedipus> goodnight ladies and gentlemen, it was a pleasure... 22:10:56 <alessio> have a good night, gregory :) 22:11:05 <oedipus> you, too, alessio! 22:11:38 <oedipus> thanks steven for being so open to remote participation -- i greatly appreciate it 22:12:04 <alessio> me too, really 22:12:08 <Steven> It worked! Thanks for being here 22:12:33 <oedipus> my pleasure -- THIS is a WG i look forward to working with when i boot my PC! 22:12:54 <Steven> That's what I like to hear! 22:13:08 <Steven> We have had a lot of good comments from people here in the halls 22:13:26 <alessio> great! 22:13:42 <Steven> Bye all! 22:13:44 <oedipus> yeah, that's the bit i miss very much -- i'll probably type/talk to you tomorrow at the (final?) ARIA meeting 22:16:55 <alessio> bye all... ciao a tutti! 23:10:41 <sbuluf> sbuluf has joined #xhtml