element 06:18:27 <Lachy_> Zeros: probably because mail clients don't pay any attention to the title element anyway 06:18:31 <myakura> thinking that it's enough w/ Subject:? 06:19:35 <Zeros> myakura, HTML requires a <title> anyway 06:19:46 <Zeros> I was just thinking of ways to use it 06:20:35 <myakura> ah, yeah. totally fogotten about that.. 06:34:31 <Zeros> mjs, is there a way to get Mail.app to groups threads on the subject line? 06:35:40 <Zeros> People are forking the discussion and changing the subject and mail still groups them, so I have 63+ email long threads that weave in and out of topics. 06:36:10 <mjs> Zeros: it does have thread grouping, but I don't believe there is a way to customize what rule it uses to put things in a thread 06:38:03 <Zeros> ah okay 06:38:46 <heycam> heycam has joined #html-wg 06:46:59 <karl> Zeros: the thread grouping is made on subject line and not on the References: and In-Reply-To: headers 06:47:02 <karl> unfortunately 06:47:24 <karl> which means if a few people are sending mails which are completely unrelated with the same subject: 06:47:28 <Zeros> karl, In Mail.app its not grouping on the subject line for me 06:47:31 <karl> Mail.app groups them 06:47:41 <Zeros> karl, its grouping on something else 06:48:02 <karl> huh 06:48:42 <Zeros> karl, http://services.ath.cx/inbox.png is the kind of thing I'm getting 06:48:45 <mjs> Zeros: I usually see a new thread when someone changes the Subject line 06:48:53 <Zeros> its pretty weird 06:49:25 <mjs> I totally don't see all that stuff in the innerHTML thread 06:49:26 <karl> oh no then it does in-reply-to AND subject 06:50:09 <Zeros> I wonder why mjs's is different 06:50:12 <karl> I see why for simple users how it could be useful. 06:50:29 <mjs> mine seems to be strictly Subject 06:50:29 <karl> I wish it does only in-reply-to 06:51:25 <karl> I also wish I could configure my Smart Mailbox with more options (rule A and rule B) and NOT rule C 06:51:43 <karl> or (rule A or rule B) and NOT rule C 06:52:06 <karl> or more filtering on headers 06:52:14 <karl> anyway it is kind of off-topics ;) 06:52:15 <mjs> you can make more than one rule that has the same result 06:52:27 <mjs> though that's admittedly a pain sometimes 06:52:45 <Zeros> Rules can't move into a smart mailbox I don't think 06:53:01 <karl> rules and Smart Mailbox have differents UI 06:53:20 <Zeros> I wonder if its something gmail is sending that is causing the grouping this way mjs 06:53:39 <loic> loic has joined #html-wg 06:53:53 <karl> basically my mail is in a imap dated space, and all my *topic* mailboxes are smart mailboxes 06:53:56 <tylerr> tylerr has joined #html-wg 06:54:50 <marcos> marcos has joined #html-wg 06:55:55 <Voluminous> Voluminous has joined #html-wg 07:15:56 <karl> <HTML> 07:15:56 <karl> <BODY> 07:15:56 <karl> <HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV>Hi,</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="font-size: 13px; 07:16:00 <karl> etc. 07:16:10 <Zeros> yep 07:16:15 <Zeros> not valid 07:16:33 <mjs> what's invalid about that? 07:16:35 <myakura> no <title> either 07:16:40 <Zeros> mjs, missing the title 07:17:00 <Zeros> html, head and body are all optional, but title is required 07:17:33 <mjs> a <title> is of dubious value for a Mail message, but I suppose it could put an empty one or use the subject line 07:18:25 <anne> anne has joined #html-wg 07:18:30 <karl> or it could put the subject of the message itself maybe 07:18:55 <anne> morning 07:19:45 <Zeros> karl, have you looked at the css limitations for outlook 2007? 07:20:24 <Zeros> http://msdn2.microsoft.com/en-us/library/aa338201.aspx 07:21:04 <Zeros> raises a lot of questions for how useful HTML is going to be; Mail.app in leopard adds html templates, but Outlook 2007 supports rather limited subset of css 07:21:05 <karl> if I tried to validate forcing the doctype to be HTML 4.01 Transitional 07:21:09 <karl> i have 12 errors 07:22:08 <karl> no alt on images, and the missing doctype and title create problems 07:22:48 <mjs> The doctype and title would be easy to fix (if it does not make other mail clients barf) but adding a made-up alt value would probably do more harm than good 07:23:11 <mjs> (as would forcing the user to type something whenever they paste an image) 07:23:12 <karl> mjs: yes for the title it requires more UI modification. 07:23:25 <mjs> so probably the alt requirement is not appropriate for HTML email 07:23:32 <karl> it's why I'm always interested by authoring tools requirements 07:23:59 <karl> s/title/alt/ 07:24:04 <mjs> since the value of making my email to my friends theoretically more accessible is surely outweighted by the cost of typing alt values 07:24:58 <karl> mjs it depends on the type of friends you have. But it would be better to ask someone who has real needs for accessibility and using mail app 07:25:24 <sbuluf> does any mail app generate not just html, but also easily separatable css? (to an external stylesheet, or to easily editable UI) if not, shouldn't they? 07:25:25 <mjs> karl: if I were sending personal email to a blind friend I probably would not include photos 07:25:55 <karl> sbuluf: the css is put on each element not in a style element 07:26:01 <Zeros> Or describe the photo yourself below it mjs 07:26:12 <mjs> and if I had both visually impaired and normally visioned friends that I wanted to Cc on the same email, I'd include the photo and a description in the text 07:26:29 <mjs> alt seems unlikely to be good for email unless you are mailing a pre-existing web page 07:26:29 <karl> yes it seems a fair approach 07:27:10 <karl> mjs: which seems to make the point that there is different class of products with different requirements even for renderers 07:27:49 <mjs> karl: this seems more like a content generation issue than a rendering issue 07:28:23 <karl> the HTML document would not be valid in the end if no alt. 07:28:27 <mjs> you have to either have multiple conformance classes for documents (maybe private vs. public?) or accept that HTML email won't be conforming HTML 07:28:46 <mjs> or you give up on alt being mandatory 07:28:46 <karl> I vote for 1. 07:28:52 <Zeros> mjs, adding a doctype, title and alt="" would make that valid 07:29:02 <karl> different conformance requirements depending on the products 07:29:13 <Zeros> Outlook already adds an empty title and a doctype 07:29:18 <mjs> Zeros: well, adding alt="" would be, in my opinion, more harmful than helpful 07:29:29 <Zeros> mjs, how does that differ than no alt at all? 07:29:29 <mjs> while it satisfies the letter of the rule, it surely does not satisfy the spirit 07:29:33 <karl> conformance requirements are not things to enforce but more a guide on what you need to implement depending on the circumstances. 07:29:43 <mjs> it's like cargo cult conformance 07:30:03 <mjs> having an empty-valued alt attribute gives you none of the benefits 07:30:12 <Zeros> mjs, it prevents inconsistencies. If we don't think alt should be required then it shouldn't be required. 07:30:36 <Zeros> Adding special markup rules for every type of renderer just makes implementing a HTML UA harder 07:30:45 <karl> Zeros: I think alt="" would be harmful in this case as mjs says 07:31:03 <Zeros> I still don't see where its harmful 07:31:12 <karl> specifically if the mail goes from mail user agent to Web pages. 07:31:15 <Zeros> no alt and alt="" give the same meaning 07:31:34 <anne> no it doesn't 07:31:35 <karl> alt="" means "ignore completely the image" 07:31:40 <edas> edas has joined #html-wg 07:31:41 <anne> alt="" means no content 07:31:52 <anne> no alt means there's no alternative content for the image 07:31:52 <karl> usually used for spacer and things of this type 07:32:13 <karl> ooops I have to catch a train. 07:32:15 <Zeros> anne, how does no content and no alternative content differ? 07:32:17 <mjs> hmmm 07:32:26 <Zeros> you just added the word alternative 07:32:34 <mjs> if empty alt is allowed, then no alt should probably be allowed as well 07:32:53 <mjs> the point of requiring alt is supposed to be to encourage accessible authoring, but adding alt="" doesn't satisfy that goal at all 07:33:17 <mjs> anyway, would be good for someone to capture these thoughts on the mailing list 07:33:23 <Zeros> The validator could still warn, and the spec could encourage its use without making it invalid to not use it. 07:33:31 <mjs> is <title> the only mandatory element? 07:33:44 <anne> Zeros, it means that the user agent can tell the user there's an image but no alternate content was provided for it 07:33:55 <anne> Zeros, for instance, it could read out the URL used to retrieve the image 07:34:03 <Zeros> anne, it could do the same for alt="" 07:34:12 <anne> Zeros, that would be non-conforming 07:34:41 <Zeros> anne, the spec says alt is required. Not having at all is non-conforming. 07:35:13 <mjs> Web Apps 1.0 allows alt="" but not missing alt, and says missing alt should be treated same as empty-valued alt 07:35:30 <Zeros> :) 07:35:56 <anne> That makes the distinction pretty useless 07:36:13 <mjs> it says empty alt should mean: "In such cases, the image could be omitted without affecting the meaning of the document." 07:36:33 <mjs> I don't think that will be true for end-user-authored HTML emails that contain images 07:36:46 <mjs> so adding empty-valued alt would technically be nonconforming 07:37:02 <mjs> perhaps the alt requirement should be omitted for content generated by a WYSIWYG editor 07:37:14 <Zeros> mjs, how does that apply to dreamweaver then? 07:38:02 <Zeros> I'm not sure HTML's rules for conformance should be dependent on who's generating it. 07:38:03 <mjs> I don't think dreamweaver is the sort of thing intended to be covered by the wysiwyg exception for <font> tags 07:38:54 <Zeros> mjs, what's the issue with style attributes for fonts? 07:39:22 <Zeros> in a context where a style block isn't possible I guess, and the font needs to be encoded right there 07:39:35 <mjs> Zeros: I actually think style should be retained as a global attribute but I haven't heard a lot about the arguments for removing it 07:39:53 <mjs> the <font> element in HTML5 is the only thing allowed to have a style attribute 07:40:06 <mjs> and is meant to be used for presentational inline styling done by WYSIWYG editor 07:40:06 <mjs> s 07:40:18 <Zeros> mjs, that invalidates a whole lot of existing web content that uses style 07:40:54 <mjs> yes, it does 07:41:05 <mjs> (though presumably the rendering section will say UAs must support it on everything) 07:41:17 <Zeros> I can't say I agree with undeprecating <font> 07:41:50 <gorme> gorme has joined #html-wg 07:42:23 <anne> It's undeprecated for WYSIWYG editors as it appears they need it 07:42:42 <mjs> well, having an official way to do presentational markup seems like the best way to handle the classes of content generators that need to make presentational markup 07:42:43 <anne> However, that whole section is in its very early stages at this point 07:43:07 <anne> marcos, contenteditable / designMode geneates it 07:43:10 <anne> generates* 07:43:22 <marcos> k, that makes sense then 07:43:38 <Zeros> contenteditable in safari generates spans IIRC 07:44:24 <Zeros> mjs, what's to prevent all the content on the web from ending up full of font tags again if its created with in browser WYSIWYG editors? 07:45:06 <mjs> Zeros: I doubt the front page of cnn.com will ever be made that way 07:45:25 <Zeros> mjs, blogs probably would be, news sites? wikis? 07:46:11 <sbuluf> what about spans with only predefined css classes? would that be an improvement? 07:46:18 <mjs> Zeros: well, you can't get WYSIWYG editors to make purely semantic markup, since the very concept of such a thing is presentational 07:46:24 <anne> <span class=red> 07:46:36 <anne> maybe in amount of bytes... 07:46:44 <mjs> <span class="-user-style-1"> 07:47:04 <anne> however, <font color=red> interoperates better 07:47:48 <Zeros> And makes restyling the page from a content editor's perspective a nightmare 07:48:05 <Zeros> anyone saving the source of that document is going to get older styles if they override it too 07:48:17 <Zeros> font[color=red] { color: blue; } 07:48:22 <mjs> html mail clients have special requirements, since they have to generate markup that can be handled by a wide variety of really bad layout engines 07:48:33 <gorme> \o Whats the rationale behind the header and footer element ? 07:48:43 <mjs> the html engines in many popular mail readers are far worse than popular browsers 07:48:58 <mjs> gorme: a lot of web documents have a header and a footer 07:49:25 <Zeros> mjs, How does that come into play with Mail 3.0's HTML templates? Do they cater to those old clients? 07:49:40 <Zeros> Seems like Apple is pushing HTML mail and MS is fighting it 07:49:41 <mjs> for instance on http://amazon.com/ you can probably pick it out 07:50:19 <mjs> Zeros: I can't talk about Mac OS X features that haven't shipped yet 07:50:54 <mjs> Apple is pushing the possibility of rich text email, because people like to communicate with more than just plaintext 07:51:24 <Zeros> mjs, Well from your personal perspective. If you were writing a mail client with html templates for users, what audience of UAs would you be targeting and where would you draw the line on support? 07:51:24 <mjs> I think Outlook switching to the Word engine to compose and display HTML email isn't necessarily a vote for or against HTML email 07:51:33 <Zeros> Like, would you use <center>? 07:51:33 <mjs> thogh it is certainly a vote against standards compliance 07:51:58 <mjs> Zeros: I can't really talk about it at that level of detail, sorry 07:52:08 <Zeros> alright 07:52:35 <Zeros> I can see the point of needing some kind of control, but at the same time HTML5 lets you put <style> elements in the body of the document 07:52:53 <Zeros> So why can't a Visual editor generate that instead? 07:53:08 <sbuluf> <span class="foreing term> would allow to define another font, another colour, size, and what not. but wouldn't the difference with a font tag be that all those rules can be moved from the middle of the text to an style element, or even to an external stylesheet, hence keeping presentational data separated from content? 07:53:08 <Zeros> or line styles I guess 07:53:17 <Zeros> inline* 07:53:41 <anne> sbuluf, you don't know what you're marking up 07:54:08 <anne> Zeros, <style scoped> is a pretty new feature 07:54:10 <mjs> sbuluf: but users don't pick "foreign term" from the Font menu 07:54:16 <mjs> they pick Italic 07:55:05 <Zeros> anne, even if it wasn't scoped. Provided the generated content is bound by an id you could target that specific chunk of the document 07:55:05 <sbuluf> msj, what if you allow users to define classes (a bunch of style rules), and let them name them with semantic names, and then pick those names from a drop down? 07:55:13 <Hixie> someone should mail the img/alt thing to the whatwg list so i don't forget about it 07:55:29 <mjs> Hixie: I was gonna 07:55:31 <Hixie> it does make sense to me to have different rules for e-mails than web content 07:55:52 <mjs> does email need different rules than WYSIWYG-generated content in general? 07:55:55 <mjs> (not sure a priori) 07:56:17 <mjs> so is <title>

00:00:28 and as you well pointed, we can't quite keep adding more and more specs, indiscriminately, without thinking on the most precius resource in the whole web: grandma's mind. 00:00:51 html? css? xml? rdf? xslt?...how many? 00:01:33 *who* really ensures that this does not get out of control in grandma's head? 00:01:59 I think most people consider grandma to be the business of the editor creators 00:02:16 blogs and such make it trivially for people to start contributing content 00:03:04 dashiva, your very sentence worries me. no ofense, no problems, but...see? who is really more important here? 00:03:50 anne, partially true. not trivial. and incomplete. but are you going to call our conversatrion "silly" after a while? if so...should i keep talking? 00:04:29 sbuluf, heh 00:05:06 sbuluf: I'm not sure I can agree. This WG deals with markup, the very markup grandma is not supposed to see. We are completely abstracted away from her world. 00:05:11 again, no ofenses intended. really. i hope you can see it. 00:05:40 I don't really have an opinion on end users. It's hard for to imagine at what level they'd interact with HTML. I tend to think it would be completely abstracted away from them. 00:05:52 for me* 00:06:15 *on end users in the context of the HTML language 00:06:32 so what Dashiva says I think 00:07:02 dashiva, partially true, i'd say. on one hand, we could allow standard makers to just say )as usual) "is someone else's problem. comfy, isn't it? but the end result is this "as of 12007, grandma is in trouble" So should we not start questioning the wisdom of all this? again, who ensures gloabl coherence? 00:07:09 what does "end users" mean in the context of the HTML specification? 00:07:30 sbuluf: But how are we supposed to help grandma? W 00:07:37 people browsing the web? 00:07:51 yeah 00:08:03 dashiva, on the other hand...does it not affect the spec? are you sure we could do wymiwyg editors, with today's spec? have you considered the problem? particularly, a UI? 00:08:31 As much as I've considered the problem, I consider it practically impossible regardless of the spec 00:08:39 whatever editor there will be, it has to export to HTML at some point 00:09:54 dashiva, a fair enough answer. but...have we devoted concerted time to explore possibnilities? shouldn't we, at least? i might add i mihgt have some ideas about it. i'm no expert, however, can't do it alone. 00:10:20 anne...something not too far away from xopus, might perhaps work. i can expad too. 00:10:36 *expand 00:10:38 I think a wymiwyg editor is a close cousin of the semantic web 00:10:51 They might be possible, but the users form an apparently unsurmountable obstacle 00:11:13 dashiva...yep, somehow. do you think that is bad, though? 00:11:29 I have no faith in the semantic web, myself 00:11:33 noty trivial, dashiva, right. 00:12:31 dashiva, is very questioned, and qwuestionable, right. we could discuss it, anytime. i think at least some ideas are sound, or at least desirable, myself. 00:13:16 I'll leave the discussion to the pros. Until they make some breakthroughs, I'll remain a grumpy young naysayer :) 00:13:37 i'm no expert either =P 00:14:04 kingryan has left #html-wg 00:14:59 yeah, until someone has made a non-wysiwyg editor that's actually widely adopted by "typical" end users there's not much point in debating it I think 00:15:39 and afaik people have tried to do that and failed 00:16:22 the problem might be impossible with today's scpecs. they were not thought with that idea as a design goal, precisely. 00:16:34 but i talked too much here already, so i'll shut up. one last thought: unless wymiwyg edtors, beware of including words about caring about end users. 00:16:43 Then the semanticists need to get on the soapbox and tell us what we need to change 00:17:12 end users care about wysiwyg typically 00:17:28 identical results everywhere and such 00:17:33 (visually) 00:17:46 (i could answer...i just do not want to abuse) 00:18:33 I think we all agree it's a noble cause, we just have different degrees of hope 00:19:35 (I also don't think the problem is with the HTML specification. Editors not contrained by HTML also haven't really solved this problem.) 00:20:49 anne, we could discuss it, if you wanted. something not to far away from xopus *might* work 00:21:20 gavin has joined #html-wg 00:21:40 feel free to e-mail public-html, www-archive or some other list I follow with persuasive arguments 00:23:06 good night (i tried that, unfortunately, last time tim berners lee himself ignored me) 00:31:31 http://lists.w3.org/Archives/Public/www-tag/2006Nov/0077.html <--for those curious, this is me asking timbl for w3c to make a browser (wymiwyg, or similar, perfect code generation, semantic web ready, etc) 00:32:26 DanC_lap has joined #html-wg 00:32:51 hope you do well, danc. we heard. 00:33:02 hi. thanks. 00:34:10 myakura has joined #html-wg 00:34:59 I thought the influx of new WG members would die off a bit after hixie's blog post, but it's been weeks and they continue to come in at about the same rate 00:35:03 yes. on 3 discussions on 3 channels 00:35:26 have you sent anything to www-html@w3.org, karl? I don't think I ever did 00:36:17 hmmm... you mean recently? 00:36:23 since March 7 00:36:43 hmm I guess one or two mails. 00:36:43 RRSAgent, pointer? 00:36:43 See http://www.w3.org/2007/04/11-html-wg-irc#T00-36-43-1 00:36:57 was either of them an announcement about the new HTML WG? 00:37:07 I don't think 00:37:10 let me check 00:37:16 RRSAgent, make logs world-access 00:38:13 http://www.w3.org/Search/Mail/Public/advanced_search?keywords=&hdr-1-name=subject&hdr-1-query=&hdr-2-name=from&hdr-2-query=karl%40w3.org&hdr-3-name=message-id&hdr-3-query=&index-grp=Public__FULL&index-type=t&type-index=www-html&resultsperpage=20&sortby=date 00:38:35 3 messages and not announcements about HTML WG 00:39:52 the last message was a message about someone asking about HTML 4.01 00:40:01 so I said to contact the public-html. 00:40:05 but that's all 00:40:22 do you want me to announce the HTML WG on www-html? 00:40:32 umm... yes, I'd like that. 00:40:56 ok. on my todo pile for today 00:41:59 * 305 group participants, 00:41:59 * 305 in good standing, 00:41:59 * 44 participants from 16 organizations 00:41:59 * 261 Invited Experts 00:42:10 I have some people queued for today too. 00:42:26 I wish we had more Authoring tools developers, and CMS as well 00:42:39 yeah... 00:42:56 just to improve the ecosystem, having more diversity and variety of inputs. 00:43:05 any volunteers to write rousing blog articles to encourage CMS folks to join the WG? 00:43:35 I could do that on QA Weblog or maybe I wonder if WASP could help on this. 00:43:43 perhaps a message to public-evangelist@w3.org would help? 00:44:12 wonder what is the best strategy 00:44:43 I lean toward the shotgun approach: use all of the above 00:44:44 maybe QA weblog and asking the community to promote the information and to ask people to bug their favourite tool developers to join 00:45:24 better if we can give reasons why joining will help the CMS vendors. nobody likes to be bugged 00:47:21 I have vague impressions that there are accessibility concerns around