| 00:13 | <zcorpan> | Hixie: isn't it possible to put e.g. U+000C characters in the DOM? |
| 00:19 | <Hixie> | in the text? |
| 00:19 | <Hixie> | i guess it is |
| 00:19 | <Hixie> | is that non-conforming these days? |
| 00:20 | <Hixie> | why do people have such problems with control characters, sheesh |
| 00:20 | <zcorpan> | it's a well-formedness error in xml 1.0 iirc |
| 00:20 | <Hixie> | i think i should start a non-profit that campaigns for equal rights for control characters |
| 00:20 | <zcorpan> | :) |
| 00:20 | <zcorpan> | that was what i referred to by "illegal characters" |
| 00:21 | <Hixie> | yeah |
| 00:21 | <Hixie> | i thought you mean in XML names |
| 00:21 | <Hixie> | i'll add it to the list |
| 00:21 | <Dashiva> | We need ASCII5 |
| 00:21 | <Dashiva> | maybe UTF5 too |
| 00:21 | <zcorpan> | Unicode5 |
| 00:21 | <zcorpan> | oh, there already is a Unicode 5.0 |
| 00:22 | <Dashiva> | Just map all those pesky control characters to NOP |
| 00:22 | <Dashiva> | (And then people start using them to go past content filtering, hilarity ensues) |
| 00:26 | <zcorpan> | nn |
| 00:37 | <Hixie> | so apparently control characters are fine in xml 1.1 |
| 00:37 | <Hixie> | that's one of the few changes |
| 00:37 | <Hixie> | that's why i thought it was ok :-) |
| 00:38 | <Hixie> | i've made the spec cover this case, anyway. |
| 00:43 | <KevinMarks> | so we can send BEL to lynx users? excellent |
| 00:44 | <Hixie> | nothing says they have to render as a bell, but yep |
| 00:47 | <Hixie> | hm, a request for outerHTML |
| 00:49 | <Hixie> | hsivonen: yt? |
| 00:49 | <Hixie> | or anyone, in fact. any opinions on how to define how many unconvertable bytes should be converted to FFFD? |
| 00:50 | <Hixie> | say you have a sequence of non-UTF-8 bytes in a UTF-8 stream |
| 00:50 | <Hixie> | how many FFFDs do you get? |
| 00:50 | <Hixie> | hm |
| 02:11 | <Hixie> | > [...the html5 draft] does not attempt to |
| 02:11 | <Hixie> | > define how user agents MUST signal whether they prefer text/html or |
| 02:11 | <Hixie> | > application/xhtml+xml. |
| 02:11 | <Hixie> | hm |
| 02:19 | <Hixie> | wow you can really confuse IE's tokeniser if you're not careful |
| 02:19 | <Hixie> | e.g. <p title=x=" b > y> hello </p> |
| 02:32 | <jruderman> | that's a strange use of the all-caps MUST |
| 02:35 | <karlUshi> | yep |
| 02:35 | <karlUshi> | they MUST, but we do not know what |
| 02:35 | <karlUshi> | it doesn't work |
| 02:38 | <Hixie> | html5lib people -- i mislabeled one of my checkins just now, my bad. it affects you. (r901) |
| 07:17 | <zcorpan> | http://simon.html5.org/temp/selectors-case.txt -- my proposal for inclusion in the Selectors spec, any comments? |
| 07:44 | <annevk> | why XML attribute names? |
| 07:45 | <annevk> | and are you sure CSS is ASCII case-insensitive? |
| 07:45 | <zcorpan> | becase xbl2 uses xml attribute names for the selectors namespace declarations |
| 07:45 | <zcorpan> | or perhaps rather, it uses xml namespace declarations |
| 07:46 | <zcorpan> | no, i didn't look it up... |
| 07:46 | <hsivonen> | Hixie: Re: rev 894: You didn't mention text nodes containing forbidden characters. |
| 07:47 | <hsivonen> | Oops. that was addressed in email |
| 07:48 | <zcorpan> | forbidden characters can appear in other places other than text nodes, right? |
| 07:48 | <hsivonen> | zcorpan: in XML, the forbidden characters can't appear anywhere |
| 07:49 | <hsivonen> | zcorpan: additionally, element and attribute names have further arbitrary restrictions |
| 07:49 | <zcorpan> | yeah |
| 07:49 | <zcorpan> | perhaps it should be more catch-all and say any node that doesn't match the relevant production |
| 07:49 | hsivonen | sees that rev 896 mentions illegal characters |
| 07:50 | <annevk> | maybe just drop the last column? |
| 07:52 | <zcorpan> | annevk: yeah, done |
| 07:53 | <annevk> | zcorpan, re: entities, I think we should just fix our implementation |
| 07:53 | <annevk> | the spec makes many things conforming that are not actually supported |
| 07:54 | <zcorpan> | i think compat with legacy implementations is good |
| 07:54 | <annevk> | <datagrid> |
| 07:54 | <zcorpan> | what about it? |
| 07:54 | <annevk> | I think incentives to fix legacy implementations are good |
| 07:55 | <zcorpan> | oh sure |
| 07:55 | <zcorpan> | don't not fix your implementations :) |
| 07:56 | <zcorpan> | even if we don't care about compat with legacy implementations, making the ; optional makes errors harder to spot and makes the code less readable |
| 07:56 | <annevk> | depends on the particular construct |
| 07:56 | <annevk> | if whitespace is following... |
| 07:57 | <zcorpan> | true |
| 08:03 | <hsivonen> | hmm. looks like the tokenization spec will have changed by the time my impl passes unit tests. :-) |
| 08:05 | <hsivonen> | Hixie: my implementation currently relies on the java.nio.charset.CharsetDecoder notion of bad byte sequence grouping |
| 08:05 | <hsivonen> | Hixie: I'll get back to you about how it groups stuff. |
| 08:06 | <hsivonen> | Hixie: IIRC, for UTF-8 a plausible first byte of an UTF-8 sequence starts a new run of bad bytes |
| 08:07 | <hsivonen> | Hixie: I'm rather unsympathetic to defining it precisely if the definition disagrees with what Sun and IBM ship. |
| 08:08 | <zcorpan> | why does it matter how many replacement characters there are? |
| 08:08 | <hsivonen> | zcorpan: dunno. over eager "interop" consistency I guess |
| 08:09 | <annevk> | the suggestion is to leave the decoding charistics up to the decoding specs |
| 08:09 | annevk | thinks that make sense |
| 08:09 | <zcorpan> | we should know when to stop... :) we probably can't get 100% interop anyway, and going there might cost more than it's worth |
| 08:10 | <hsivonen> | jgraham: did you already take a look at doing both error reporting and recovery at the same time using Python codecs? |
| 08:10 | <annevk> | zcorpan, we should get a reasonable baseline implemented |
| 08:11 | hsivonen | notes that getting both error reporting and recovery at the same time required a custom replacement for java.io.InputStreamReader and the code becomes hairy fast |
| 08:11 | <annevk> | and continue our quest from there |
| 08:11 | <zcorpan> | annevk: agreed |
| 08:11 | <annevk> | for the holy grail of interop |
| 08:12 | <zcorpan> | actually, now that i've drafted that text, i think http://lists.w3.org/Archives/Public/www-style/2006Oct/0140.html is more appropriate |
| 08:12 | <hsivonen> | annevk: I don't have an AtheistParseError and the html5lib tests don't appear to have it. Can we remove it from the test format spec? |
| 08:13 | <hsivonen> | annevk: AtheistParseError was reporting />, right? |
| 08:13 | <annevk> | yeah |
| 08:13 | <annevk> | lets kill that joke |
| 08:13 | hsivonen | edits the wiki |
| 08:14 | <jruderman> | i missed an atheism joke? darn |
| 08:15 | <hsivonen> | so there are 13 JSON implementations for Java and I didn't find even one where I couldn't detect some suckiness straight from the docs |
| 08:18 | <hsivonen> | I mean why oh why do they wrap a Sun-provided collection class behind a getter instead of making the wrapper implement the corresponding collection interface and delegating to the wrapped collection? |
| 08:18 | <hsivonen> | bah. |
| 08:20 | <othermaciej> | hi everyone |
| 08:20 | <hsivonen> | hi |
| 08:21 | <othermaciej> | how's the exciting world of HTML? |
| 08:25 | <hsivonen> | othermaciej: turns out that tokenization changed substantially while I was away :-) |
| 08:26 | <othermaciej> | hsivonen: well that's exciting :-) |
| 08:31 | <hsivonen> | annevk: fwiw, it appears that the html5lib test case format ignores attributes on the end tag after all |
| 08:31 | <annevk> | the tokenizer tests? |
| 08:31 | <annevk> | could be |
| 08:31 | <hsivonen> | annevk: yes |
| 08:32 | <annevk> | I guess we're "dropping" them in the test harness |
| 08:32 | <annevk> | which makes the tests more reusable I suppose |
| 08:32 | <hsivonen> | I implemented reporting attributes on the end tag token |
| 08:33 | <hsivonen> | I guess attributes on the end tag are sufficiently rare that I shouldn't bother writing branches for omitting them in the tokenizer |
| 08:33 | <hsivonen> | I have a general empty attributes optimization anyway |
| 08:36 | <Hixie> | i agree that we shouldn't define it beyond what is there now, for the FFFD cases |
| 08:41 | <annevk> | "I've looked at how Safari renders shadows - the spec should probably define something similar, since it works and it's not insane or anything." :) |
| 08:44 | <zcorpan> | an implementation that is not insane, wow, that's not too common ;) |
| 08:48 | <annevk> | hmm |
| 08:49 | <annevk> | so what happens when I do createElement("isindex") and insert it and then request innerHTML |
| 08:49 | <annevk> | they may be macros, but they can be inserted by other means than the parser... |
| 08:49 | <annevk> | same for "image" and "keygen" |
| 08:50 | <Hixie> | if you createElement isindex you get nothing useful |
| 08:50 | <Hixie> | same as createElement('bogus') |
| 08:50 | <Hixie> | same with image and keygen |
| 08:51 | <annevk> | so you get <image>foobar</image> (if I created some child node "foobar") back from innerHTML for instance? |
| 08:51 | <annevk> | I suppose that's fine |
| 08:51 | <Hixie> | what do browsers do? |
| 08:52 | <annevk> | not all browsers treat these things as parser macros |
| 08:52 | <annevk> | so I expect them to differ a lot |
| 08:52 | <othermaciej> | you can't createElement a keygen element? |
| 08:52 | <othermaciej> | I think you can in Safari |
| 08:52 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20HTML%3E%3Cbody%3E%3Cscript%3Edocument.body.appendChild%28document.createElement%28%27image%27%29%29%3B%3C/script%3E |
| 08:52 | <othermaciej> | dunno about isindex or image |
| 08:52 | <Hixie> | image seems to turn into img in all but firefox |
| 08:53 | <othermaciej> | yeah, I get an img there |
| 08:53 | annevk | too |
| 08:53 | <othermaciej> | createElement('keygen') also does the expected thing |
| 08:53 | <annevk> | Can someone please submit a spec for "keygen"? |
| 08:53 | <zcorpan> | firefox returns <image> for innerHTML, not <image></image> |
| 08:53 | <othermaciej> | annevk: we just reverse-engineered it as best we could from Firefox and their docs |
| 08:54 | <othermaciej> | annevk: a full spec has to reference ASN.1 formats for the cert to submit and such :-( |
| 08:54 | <annevk> | you mean those Netscape docs on the web? |
| 08:54 | <othermaciej> | yeah |
| 08:54 | <annevk> | those are pretty terrible |
| 08:54 | <annevk> | IE7 gives <img> |
| 08:55 | <annevk> | <keygen></keygen> in IE7 |
| 08:55 | <annevk> | <isindex> with nothing rendered |
| 08:55 | <Hixie> | ie7 doesn't do keygen |
| 08:55 | <othermaciej> | in Safari I get <keygen> with three <option> elements in it |
| 08:56 | <annevk> | oh, I forgot to type "obviously" there |
| 08:56 | <zcorpan> | othermaciej: same as firefox |
| 08:56 | <annevk> | othermaciej, interesting :) |
| 08:56 | annevk | thought Firefox used XBL |
| 08:56 | <othermaciej> | for 'isindex' I get the <isindex> element itself, but that's not what happens when we parse it directly |
| 08:56 | <zcorpan> | except firefox has two options |
| 08:56 | <zcorpan> | firefox uses xbl for isindex |
| 08:57 | <Hixie> | well anyway |
| 08:57 | <othermaciej> | in that case we get "<hr>This is a searchable index. Enter search keywords: <isindex type="khtml_isindex"><hr> |
| 08:57 | <othermaciej> | which is retarded |
| 08:57 | <Hixie> | not really worried about these three elements much |
| 08:57 | <othermaciej> | actually, all that wrapped in a <div> |
| 08:57 | <othermaciej> | <keygen> is used on some vaguely critical sites |
| 08:57 | <othermaciej> | we didn't add it just for entertainment |
| 08:57 | <annevk> | yeah, <keygen> is important |
| 08:58 | <othermaciej> | though it's true that it is not commonly used overall |
| 08:58 | <zcorpan> | those sites use activex for ie, right? |
| 08:58 | <othermaciej> | yes |
| 08:58 | <annevk> | yup |
| 09:00 | <Hixie> | i'm happy to do whatever for <keygen> if someone can spec it |
| 09:01 | <Fuzzy76> | just Google "keygen", you're bound to find something useful ;) |
| 09:01 | <annevk> | not really ;) |
| 09:01 | <Hixie> | sadly not |
| 09:02 | <othermaciej> | http://devedge-temp.mozilla.org/library/manuals/1998/htmlguide/tags10.html#1615503 |
| 09:02 | <annevk> | the most useful documentation are the implementations of WebKit and Gecko I'm afraid (because they're open source) |
| 09:02 | <othermaciej> | but it's hard to interpret the details of how the key is encoded |
| 09:03 | <othermaciej> | in WebKit, some aspects of how the generated cert is encoded are not open source (not because we consider them top seekrit but because they use private interfaces to Apple libraries, to our chagrin) |
| 10:26 | <annevk> | People want the <s> element in HTML5 to be conforming |
| 10:27 | <Hixie> | they do? |
| 10:27 | <annevk> | Use case given: "Marking up the implied meaning by striking out has gotten very popular in the past two years among <s>lazybones and exhibitionists</s> bloggers and diary posters." |
| 10:27 | <annevk> | I got an e-mail from someone from Russia and apparently it's quite popular there |
| 10:27 | <Hixie> | isn't <del> better for that? |
| 10:27 | <annevk> | Yeah, I guess |
| 10:28 | <othermaciej> | does <del> have a default presentation of strikethrough? |
| 10:28 | <othermaciej> | (looks like yes) |
| 10:30 | <annevk> | There's also <strike> |
| 10:45 | <annevk> | nice response on molly.com BenWard |
| 10:45 | <BenWard> | Thank you :) |
| 13:17 | <annevk> | "<s> does not mean that content is subject for removing. The content was |
| 13:17 | <annevk> | marked up with <s> at the same exact moment it was created; it was |
| 13:17 | <annevk> | purposedly marked up like that. It's like when you say "A, err... I mean |
| 13:17 | <annevk> | B", and you said A not because you have mistaken, but because you were |
| 13:17 | <annevk> | really wanting to say it like that - a, err..., i mean b." |
| 13:18 | <annevk> | I think it's sort of a valid use case |
| 13:18 | <annevk> | It would also apply to the earlier given example |
| 13:18 | <zcorpan> | i think del should be defined to be appropriate for such cases... :) |
| 13:19 | <annevk> | That would work too |
| 13:21 | <Lachy> | bugzilla uses <s> for marking up links to bugs that are resolved (at least it did last time I checked) |
| 13:21 | <annevk> | yeah, there <del> would not appropriate I think |
| 13:22 | <zcorpan> | title="Resolved" |
| 13:22 | <zcorpan> | [title=Resolved] { text-decoration:strike-through } |
| 13:22 | <annevk> | no backpat? |
| 13:22 | <zcorpan> | what's the compat problem? |
| 13:22 | <annevk> | legacy UAs |
| 13:22 | <zcorpan> | that don't support attribute selectors? |
| 13:23 | <annevk> | for instance |
| 13:23 | <zcorpan> | the information is still there, if you hover the link you will get a tooltip |
| 13:24 | <Lachy> | looks like bugzilla has since been updated to use <span class="bz_closed"> and other similar classes |
| 13:24 | <zcorpan> | using a class could solve the attribute selectors limitation |
| 13:25 | <annevk> | using <s> could solve all problems simpler |
| 13:26 | <zcorpan> | perhaps, but it doesn't really mean "resolved", does it? |
| 13:26 | <annevk> | it means "less relevant" |
| 13:26 | <zcorpan> | a reader could figure it out though |
| 13:27 | <zcorpan> | ok |
| 13:27 | <annevk> | or something in that direction |
| 13:27 | <Lachy> | if we add <s>, then who wants to volunteer to handle the huge backlash from those same people that object to <b>, <i>, etc? |
| 13:27 | zcorpan | doesn't |
| 13:29 | <zcorpan> | btw, i discussed with cerbera the other day about html5's suggested markup for different kinds if user input is very verbose and seems to be semantics for semantics' sake |
| 13:29 | <zcorpan> | nested kbd/samp doesn't help the reader understand the text better |
| 13:29 | <zcorpan> | and UAs probably can't do anything useful with the information |
| 13:29 | hsivonen | nods |
| 13:30 | <zcorpan> | i've tried to style the proposed markup with css but even that doesn't really help. for styling it is better to have a class on the outermost element |
| 13:31 | <Lachy> | zcorpan, yeah, that sections really just more like suggested conventions for authors, rather than something useful for consumers |
| 13:31 | <Lachy> | that's why we need parent selectors! ;-) |
| 13:32 | <zcorpan> | in the wild, <kbd> is already used for at least keys that the user is to press |
| 13:32 | <hsivonen> | Lachy: why are the conventions useful for authors except for self-congratulation about semantics? |
| 13:32 | <Lachy> | hsivonen, I never said they were useful |
| 13:33 | <hsivonen> | Lachy: ah. just conventions :-) |
| 13:34 | <zcorpan> | perhaps kbd can be defined to mean any kind of user input, e.g. text that the user is to type, or keys the user is to press, or menu items the user is to follow |
| 13:34 | hsivonen | checks out molly.com and is surprised |
| 13:35 | <Lachy> | in general, coding conventions are useful, particularly in collaborative environments, but when it comes to purely semantic conventions with little practical purpose, doesn't seem useful at all |
| 13:35 | <zcorpan> | indeed |
| 13:35 | <zcorpan> | <kbd><kbd><samp> is just extremely verbose |
| 13:36 | <Lachy> | <kbd><kbd>Alt</kbd>+<kbd>F4</kbd></kbd> is a useful convention since it allows for easy styling of individual keys |
| 13:36 | <zcorpan> | <kbd>Alt</kbd>+<kbd>F4</kbd> |
| 13:36 | <zcorpan> | seems enough to me |
| 13:36 | <annevk> | hmm |
| 13:37 | <annevk> | you might want to style them as block... |
| 13:37 | Jero | agrees with zcorpan |
| 13:37 | <Lachy> | it depends if you want your stylesheet to distinguish between text to enter and sequences of keys to press |
| 13:37 | annevk | follows the spec already |
| 13:37 | <annevk> | so I'm prolly biased |
| 13:38 | <zcorpan> | Lachy: perhaps. though classes can be used |
| 13:38 | <Lachy> | e.g. giving instructions like this to users: "Enter "<kbd>format C:</kbd>" and then press <kbd><kbd>Enter</kbd></kbd>. |
| 13:38 | <hsivonen> | here's something for a potentially rathole sematic debate: If you have a file system path or a URI on a Web page, should it have specific markup and if yes, which? |
| 13:39 | <hsivonen> | semantic |
| 13:39 | <Lachy> | hsivonen, I use <code> for both |
| 13:39 | annevk | uses <code> for URIs |
| 13:40 | annevk | isn't sure why |
| 13:40 | <Lachy> | ... just to get a monospace font |
| 13:40 | <zcorpan> | tt, anyone? :) |
| 13:41 | <Lachy> | one could possibily argue that <a>http://...</a> is the right markup |
| 13:41 | <annevk> | without href? |
| 13:41 | <annevk> | hmm |
| 13:42 | <annevk> | that'd be wrong actually |
| 13:42 | <Lachy> | either with or without. It depends i |
| 13:42 | <Lachy> | yeah, it'd be wrong with the current HTML5 definition |
| 13:49 | <Jero> | hmm, why should an HTML5 parser close the first a element right after the closing tag of the first table element with test #30 on http://jero.net/lab/ph5p/tests.html ??? |
| 13:49 | <Jero> | that's what html5lib does anyway |
| 13:50 | <Jero> | http://hasather.net/html5/parsetree/parsetree?source=%3Ca%3E%3Ctable%3E%3Ctd%3E%3Ca%3E%3Ctable%3E%3C%2Ftable%3E%3Ca%3E%3C%2Ftr%3E%3Ca%3E%3C%2Ftable%3E%3Cb%3EX%3C%2Fb%3EC%3Ca%3EY |
| 13:51 | <annevk> | it needs to reopen because it hits some other <a> element |
| 13:52 | <zcorpan> | you mean why does it result in "...</table></a><a><b>..." as opposed to just "...</table><b>..."? |
| 13:53 | <Jero> | exactly |
| 13:53 | <zcorpan> | perhaps it's a bug in html5lib -- what does the spec say? :) |
| 13:55 | <Jero> | can't find anything in the spec, but doesn't seem very logical to close an a element after a table element or before a b element |
| 14:05 | <zcorpan> | Cerbera: welcome :) |
| 14:05 | <Cerbera> | hi :) |
| 14:06 | <Cerbera> | (Opera's IRC is much prettier than mIRC) |
| 14:08 | <zcorpan> | Cerbera: see logs from 14:37 for the kbd discussion |
| 14:09 | <Cerbera> | zcorpan: I read from <http://krijnhoetmer.nl/irc-logs/whatwg/20070615#l-294>; |
| 14:10 | <Cerbera> | In making websites, I have yet to need more than one level of <kbd> for styling or any other purpose |
| 14:11 | <zcorpan> | yeah |
| 14:11 | <Cerbera> | I think styling is the only purpose for that element, in practise. |
| 14:12 | <zcorpan> | good enough reason to keep it around :) |
| 14:13 | <Cerbera> | yes, me too. but it doesn't need to be nested in practise |
| 14:13 | <hsivonen> | gaah. I chose a JSON impl that can take a byte stream so that it could handle encodings per spec. Does it? Nooo. |
| 14:14 | <zcorpan> | hsivonen: bad luck :) |
| 14:16 | <Cerbera> | so if <kbd>foo</kbd> is adequate for styling purposes, why make its semantics more specific so they require extra levels? |
| 14:16 | <Cerbera> | as I said to zcorpan yesterday: "it's not like double-clicking styled text is going to start up an external application and perform that action" |
| 14:17 | <hsivonen> | jgraham: what's the logic in tokenizer test character coalescing? |
| 14:18 | <zcorpan> | Cerbera: you wanna summarize the information here and send to the list? :) |
| 14:18 | <hsivonen> | Why are there two tokens here: |
| 14:18 | <hsivonen> | Expected tokens: |
| 14:18 | <hsivonen> | ["ParseError",["Character","&"],["Character","f"]] |
| 14:18 | <Cerbera> | zcorpan: yeah |
| 14:19 | <Cerbera> | zcorpan: although I'm supposed to be doing work :P |
| 14:19 | <zcorpan> | me too :) |
| 14:24 | <Cerbera> | so then: 1) UAs can't do anything with the information. For starters, the application it's for isn't declared. |
| 14:25 | <Cerbera> | 2) a single level of either <kbd> or <samp> is enough for common styling needs |
| 14:27 | <Cerbera> | 3) it's much more convenient to write '<kbd>File</kbd> > <kbd>Exit</kbd>' than '<kbd><kbd><samp>File</samp></kbd> > <kbd><samp>Exit</samp</kbd></kbd>' |
| 14:28 | <Cerbera> | 4) fiddly markup inevitably causes confusion and is written wrongly (is that a legitimate comment?) |
| 14:29 | <Cerbera> | (case in point: my example was wrong! missing > at the end of a </samp>) |
| 14:34 | <zcorpan> | that about sums it up, although it's good to put forward the counter arguments too (allows for different styling) |
| 14:35 | <Cerbera> | 5) people can nest the elements if they like (e.g. for more complex styling) without this being required |
| 14:40 | <Cerbera> | are there any there any other arguments for keeping it? |
| 14:42 | <zcorpan> | not afaict |
| 14:43 | <Cerbera> | perhaps some feel it adds clarity to the intention markup by being more specific? |
| 14:46 | <zcorpan> | only for people who have read the spec and is peeking at the source code when reading a web page |
| 14:47 | <Cerbera> | yeah, like content authors. I'm havn't seen it suggested, though. |
| 14:48 | <Cerbera> | the context of the sentence would make clear what type if input is being talked about, I suppose |
| 14:48 | <zcorpan> | yeah |
| 14:48 | <Cerbera> | ok, looks like 1-5 sums it up (perhaps better written) |
| 17:45 | <met_> | XXXHTML5 is comming http://kecy.roumen.cz/roumingShow.php?file=titstag.jpg |
| 17:59 | <Jero> | <fake/> |
| 19:10 | <csarven-> | what is the plan for replacing (if at all) <acronym> ? |
| 19:10 | <Hixie> | it's gone |
| 19:10 | <Hixie> | <abbr> replaces it |
| 19:12 | <csarven-> | aren't abbreviation and acronym different things? is acronym a subset of abbr? |
| 19:15 | <Hixie> | there are many things similar to abbreviations and acronyms, with overlapping definitions |
| 19:15 | <Hixie> | it depends on the language, on the culture |
| 19:15 | <Hixie> | and there seems to be no really good reason to have more than one element |
| 19:15 | <Hixie> | so we have just one element that covers the concept "one piece of text standing for another piece of text" |
| 19:16 | <csarven-> | gotcha |
| 19:16 | <csarven-> | although i dont see this approach being applied to the new spec |
| 19:16 | <csarven-> | at least not entirely |
| 19:17 | <Hixie> | any specifics in mind? |
| 19:17 | <csarven-> | <m> |
| 19:18 | <Hixie> | <m> is an interesting one, in that there are other elements that could arguably have the same presentation, but they don't really have the same semantics |
| 19:18 | <Hixie> | <b>, for instance |
| 19:18 | <Hixie> | (we added <m> before we added <b>) |
| 19:19 | <csarven> | i never understood the 'semantics' behind <m> when it acts nothing more then a <span> for instance |
| 19:20 | <Hixie> | the semantics are "highlight this part of text", for example highlighting the search keywords in google cache |
| 19:21 | <csarven> | <span class="highlight"> ? (im not fully uptodate, so correct my if im wrong but are predefined classnames gone?) |
| 19:21 | <bewes1> | they are gone, yeah |
| 19:21 | <Hixie> | <span class="highlight"> is the same, semantically, as <span> |
| 19:21 | <Hixie> | which is the same as not having anything at all |
| 19:22 | <Hixie> | don't forget stylesheets are optional, if you're using a stylesheet to convey meaning, you're doing it wrong |
| 19:22 | <csarven> | how would <m> render on a UA that supports no stylesheets? |
| 19:22 | <Hixie> | e.g. lynx could render it as black text on a yellow background |
| 19:23 | <othermaciej> | some non-CSS UAs still have default presentation for various elements |
| 19:23 | <csarven> | isn't that also conveying information by presentation? |
| 19:23 | <Hixie> | all information is conveyed by presentation |
| 19:24 | <Hixie> | at the end of the day |
| 19:24 | <Hixie> | the key is that the _exact_ presentation doesn't matter |
| 19:24 | <csarven> | how would a screenreader interpret <m> ? |
| 19:24 | <Hixie> | e.g. it could be a blue background. or yellow text. or italics. or it could sing a jingle before and after. |
| 19:24 | <Hixie> | it could be louder, it could play an audio icon |
| 19:25 | <Hixie> | or it could not render them differently at all, but allow the user to jump to each <M> |
| 19:25 | <Hixie> | which might be more helpful |
| 19:27 | <Hixie> | the point about stylesheets is that the meaning should be conveyed to the _browser_ without forcing a particular presentation, and then the _browser_ can make the presentation choice |
| 19:27 | <Hixie> | in the case of CSS browsers, that choice might be based heavily on the provided stylesheet |
| 19:28 | <Hixie> | but it doesn't have to be, e.g. CSS browsers make <h1> bigger than <h2> even if you don't tell them to |
| 19:28 | <csarven> | i think i see it a bit more clearer now.. originally i had doubts about <m>. if i understand you correctly, the purpose of <m> is to show a relationship between an action that was taken previously in context of the current document |
| 19:28 | <Hixie> | well, specifically it just marks a run of text as being marked or highlighted, it doesn't constrain the reason for that marking or highlighting |
| 19:29 | <Hixie> | the use case that was primarily in mind when we added it was the way google cache (e.g.) highlights search terms, or the way many scripts highlight google search terms when you go to their site |
| 19:30 | <csarven> | right but it goes beyond that and to highlight any text in the document. originally this was the part i couldn't quite agree with as highlighting can be done in various ways depending on context and the semantics behind it |
| 19:30 | <annevk> | If people start using them for anything but search terms I wonder if <m> will still be useful... |
| 19:30 | <Hixie> | the use of the word "highlight" in the spec may be a poor choice, i'm not sure exactly what term to use |
| 19:31 | <csarven> | signify/outline? |
| 19:31 | <Hixie> | it may also be that <m> isn't different enough from <strong>, and we may have to remove it |
| 19:32 | <Hixie> | (e.g. another case for highlighting is when you're revising material and you want to highlight the key parts of the text -- but are the key parts of the text not just the "important" parts? meaning <strong>?) |
| 19:32 | <csarven> | right.. for instance, wouldn't non-css UAs be able to jump to each <strong> (regardless of a search result) |
| 19:32 | <Hixie> | well, they could, but would it work as well? i don't know |
| 19:32 | <Hixie> | maybe i should use the term "key parts of the text" to define <M> |
| 19:33 | <csarven> | then i suppose knowing the real difference between <m> and <strong> would be noteworthy |
| 19:33 | <annevk> | "within a specific context" too |
| 19:33 | <annevk> | they're only key parts if you previously searched for them, for instance |
| 19:33 | <Dashiva> | And what happens if there's an <m> in the text already? |
| 19:33 | <csarven> | in the case of a action taken previously i can understand 'within a specific context' but if used to 'highlight' a part of the document, im not sure if its accurate |
| 19:34 | <annevk> | Dashiva, that and hiliting "foobar" in "foo<a>barbaz</a>" are interesting questions |
| 19:47 | <jgraham> | annevk: There's two n's in Connolly (Re: HTML4/HTML5 differences) |
| 19:49 | <jgraham> | Also, I think that instead of just lists of dropped elements / attributes it would be good to say what they are replaced with (where relevant) and group them if appropriate |
| 19:50 | <jgraham> | e.g. The following elements are dropped because they are presentational and CSS should be used instead: big, center, etc. |
| 19:52 | <jgraham> | I should really mail this sort of thing... |
| 19:54 | <Hixie> | woah, IE parses entities in attributes and in content differently |
| 19:57 | jgraham | cries |
| 19:58 | <jgraham> | Really? |
| 19:58 | <jgraham> | Fun... |
| 20:44 | <Hixie> | wow |
| 20:45 | <Hixie> | http://lists.w3.org/Archives/Public/public-xhtml2/2007Jun/0014.html |
| 20:45 | <billmason> | Oh, this is going to be good. |
| 20:45 | <Hixie> | "Just to clarify, we firmly believe that Iraq has Weapons of Mass Destruction." |
| 20:45 | <billmason> | lol |
| 20:47 | <Hixie> | or "Just to clarify, we do not believe that Guantanamo Bay is terribly different from any other jail. And it does not use a different legal system." |
| 20:47 | <billmason> | And here I was thinking that the fight over who gets to keep their name wins -- XHTML5 or 2 -- was going to be the hard part. |
| 20:47 | <Hixie> | this whole discussion is somewhat moot |
| 20:48 | <Hixie> | it doesn't matter if XHTML2 uses the HTML namespace |
| 20:48 | <Hixie> | it's not like there's ever going to be XHTML2 content to clash with the HTML5 content |
| 20:48 | <Hixie> | in fact, making them use the same nameaspce is the most effective way to guarentee that, since it makes it practically impossible for browsers to implement both |
| 20:49 | <Hixie> | and it's not like they can't implement HTML |
| 20:49 | <Hixie> | the name is also somewhat academic. it's clear to anyone not involved in XHTML2 that the XML version of HTML5 should be called XHTML5. |
| 20:50 | <Hixie> | just stands to reason |
| 20:50 | <Hixie> | anyway |
| 20:50 | <Hixie> | i'm sure this will all be resolved without my having to get involved |
| 20:50 | <billmason> | I don't disagree. It just seemed like it would be just the thing to hit that emotional chord of debate endlessly. |
| 20:50 | <Hixie> | so i'll get on with the real work that matters :-) |
| 20:51 | <Hixie> | hey if it distracts people from camplaining about the spec :-P |
| 20:51 | <billmason> | heh :) |
| 20:52 | <Hixie> | lunch time |
| 20:52 | <Hixie> | bbl |
| 20:57 | <Dashiva> | Maybe they're trying to make it impossible so they can say "It's not our fault, the browsers refused to implement" |
| 20:57 | <webben> | XHTML for HTML5 has never made sense to me, not least because I don't recall anybody being able to explain what the X stands for. |
| 20:58 | <webben> | whereas I at least understand what the X stands for and means in the case of XHTML2 |
| 20:58 | <webben> | (being related to XHTML modularization) |
| 20:59 | <webben> | I can't see any gains to reusing the name to the HTML-next effort. |
| 20:59 | <webben> | It just courts controversy and will clearly cause confusion. |
| 21:01 | <webben> | even in XHTML2 didn't exist, i don't think XHTML5 would be an especially helpful name |
| 21:01 | <webben> | I'd say a helpful name would actually have "XML" in. |
| 21:07 | <Dashiva> | XHTML means "HTML as XML" in any practical context |
| 21:08 | <webben> | Dashiva: "HTML as XML" isn't normally a "practical context". |
| 21:09 | <webben> | And in so far as it's a useful context, it's precisely because of extensibility not faciliated by HTML (viz. mixing XMLs: XForms, SVG, MathML) |
| 21:10 | <webben> | (generally speaking) |
| 21:12 | <webben> | While the idea that XHTML2 is similar to XHTML1.1 may appear odd at first sight, elements in the existing namespace actually do seem to have similar semantics: http://www.w3.org/TR/xhtml2/elements.html |
| 21:12 | <webben> | same with: http://www.w3.org/TR/xhtml2/attributes.html |
| 21:12 | <webben> | Like the HTML5 draft, XHTML2 also introduces loads of new stuff. |
| 21:13 | <webben> | but without any particular commitment to backwards compatibility |
| 21:13 | <webben> | i'm not sure how backwards compatibility with UAs relates to the same with namespaces however |
| 21:14 | <webben> | and there are now DTDs for including role and property in XHTML1.1 |
| 21:14 | <webben> | (which are one of XHTML2's more controversial introductions) |
| 21:15 | <othermaciej> | what's property? |
| 21:15 | <othermaciej> | there's a property attribute? |
| 21:15 | <othermaciej> | please tell me you're kidding |
| 21:16 | <webben> | Dashiva: It's perhaps also important to note that in so far as it is used, XHTML is largely served as text/html ... and usually wouldn't validate as XML |
| 21:16 | <webben> | othermaciej: http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_property |
| 21:16 | <othermaciej> | great, as if the terms "property" and "attribute" weren't confusing enough |
| 21:17 | <webben> | othermaciej: http://www.w3.org/TR/aria-state/ |
| 21:17 | <webben> | Dashiva: I therefore in "practical contexts" XHTML doesn't mean HTML as XML. |
| 21:19 | <webben> | othermaciej: Feel free to suggest a less confusing alternative name to such a generic attribute, but property already has implementations. |
| 21:30 | <othermaciej> | webben: my level of interest in "role" and "property" is pretty low, so no thanks |
| 21:38 | <Hixie> | webben: XHTML means "XML serialisation of HTML" |
| 21:38 | <webben> | Hixie: In what sense of "means"? |
| 21:39 | <webben> | (and for who?) |
| 21:39 | <webben> | it doesn't stand for that, and doesn't mean that in the world of the everyday web |
| 21:40 | <webben> | plus the XHTML 1.0 specification allows XHTML that wouldn't parse as XML |
| 21:41 | <webben> | when serving as text/html |
| 21:41 | <webben> | thanks to the general craziness that is Appendix C |
| 21:41 | <Hixie> | webben: "stands for" |
| 21:41 | <Hixie> | webben: "is short for" |
| 21:42 | <Hixie> | (i'm talking about XHTML5 and HTML5, specifically) |
| 21:42 | <Hixie> | i don't think the XHTML 1.0 specification _allows_ XHTML that wouldn't parse as XML |
| 21:42 | <Hixie> | i think it has encouraged it, but it's still not _allowed_ |
| 21:44 | <webben> | ah okay, that sounds round |
| 21:44 | <webben> | *right |
| 21:45 | <webben> | still, it does make the acronym stand for something new |
| 21:45 | <webben> | and it doesn't really help people trying to understand what it is |
| 21:46 | <webben> | (which is what names should ideally do) |
| 21:46 | <Hixie> | i don't think the expansion really matters to be honest |
| 21:46 | <Hixie> | it's just a label |
| 21:46 | <webben> | acronyms are pernicious |
| 21:46 | <Hixie> | put it this way |
| 21:47 | <Hixie> | if XHTML2 didn't exist, we wouldn't even be having this discussion |
| 21:47 | <Hixie> | so the name XHTML5, in and of itself, is fine |
| 21:48 | <Hixie> | it's only the existence of this new language, which is similar to XHTML1 but is not a direct descendant of it, which is causing any naming issues at all |
| 21:48 | <webben> | well, it's opaque ... it's just that the existence of the label already with a different (and confusing already) meaning makes one question whether the label is a good one in the first place |
| 21:49 | <Hixie> | what do you think XHTML stands for? |
| 21:49 | <webben> | Hixie: Not only. The fact that a lot of the web is pseudo-XHTML is equally important. |
| 21:49 | <webben> | extensible |
| 21:50 | <Hixie> | how is XHTML1 extensible? |
| 21:50 | <webben> | XHTML1 isn't. XHTML is (through modularization). |
| 21:50 | <webben> | but the point isn't whether XHTML is a good name for what is currently called XHTML |
| 21:50 | <webben> | (it isn't in practice, probably) |
| 21:51 | <webben> | but whether adding yet more confusion to the mix helps clear things up |
| 21:51 | <othermaciej> | XHTML1 is in theory extensible via content in non-HTML namespaces |
| 21:51 | <webben> | (which it doesn't, it seems to me) |
| 21:51 | <othermaciej> | (I guess that is a possible sense of "extensible") |
| 21:51 | <Hixie> | i don't understand how m12n does anything to make XHTML extensible. also XHTML existed and was named long before xhtml m12n existed. so i don't buy that that's what it meant. |
| 21:51 | <webben> | othermaciej: Then it wouldn't be XHTML1 anymore, I think. Though it might use the XHTML namespace. |
| 21:51 | <Hixie> | webben: it's not clear to me that calling it something else would cause any less confusion. |
| 21:51 | <othermaciej> | the XML serialization of HTML5, whatever you may call it, needs to use the same namespace as XHTML1 for compatibility |
| 21:52 | <othermaciej> | XHTML2 does not have compatibility as a goal, so they have no need to use the same namespace |
| 21:52 | <webben> | othermaciej: compatibility with what? |
| 21:52 | <othermaciej> | and indeed putting an incompatible language in the same namespace is bogus |
| 21:52 | <webben> | othermaciej: surely anyone worried about that sort of compatibility would use the text/html serialization? |
| 21:52 | <othermaciej> | webben: deployed application/xhtml+xml content |
| 21:53 | <webben> | othermaciej: Ah. I see what you mean. |
| 21:53 | <Hixie> | othermaciej: see that e-mail i cited, it's what they're doing |
| 21:53 | <othermaciej> | which is a small amount but not 0, and I see no good reason to break it |
| 21:53 | <webben> | othermaciej: Why not just handle that with error correction? |
| 21:54 | <othermaciej> | webben: I don't see how the differences between XHTML2 and XHTML can be handled by error correction |
| 21:54 | <webben> | othermaciej: no ... i meant XHTML5 could use a different namespace, and the WHATWG spec could define how UAs should handle XHTML from the original namespace |
| 21:54 | <webben> | (as part of its general error handling) |
| 21:55 | <Hixie> | that doesn't fit our backwards compatibility design constraints |
| 21:55 | <webben> | othermaciej: I'm not really talking about XHTML2 ... I don't understand why they even want the same namespace. |
| 21:55 | <Hixie> | (our design goal is that you be able to take any existing content, and add stuff to it, and have that stuff work, without having to worry about changing namespaces, syntax, doctypes, whatever) |
| 21:56 | <webben> | Hixie: It's fine for reading existing content, and the spec discourages creating new XHTML content, /and/ anyone who cared about backwards compatibility would be using text/html, wouldn't they? |
| 21:56 | <webben> | which would mean they're already relying on error correction |
| 21:56 | <Hixie> | actually it doesn't discourage that anymore |
| 21:56 | <Hixie> | iirc |
| 21:56 | <webben> | oh |
| 21:56 | <othermaciej> | webben: if ECMAScript code in the page depends on the XHTML elements being in the XHTML namespace, I don't see how we can fix that with "error correction" |
| 21:57 | <webben> | othermaciej: I don't see why one would want to. |
| 21:57 | <Hixie> | want to what? |
| 21:57 | <Hixie> | it's not clear to me what you're proposing |
| 21:57 | <Hixie> | anyway |
| 21:57 | <Hixie> | time to reverse engineer DOCTYPE parsing |
| 21:58 | <webben> | fix ECMAScript depending on XHTML elements being in the XHTML namespace to not depend on XHTML elements being in the XHTML namespace |
| 21:58 | <webben> | sounds like a job for the authors of the original scripts to take up if they happen to want to |
| 21:59 | <Hixie> | well if we didn't do that, but we changed the namespace, the scripts would break |
| 21:59 | <webben> | Hixie: Why would you need to change the namespace for existing content declared to be in the old namespace? |
| 22:00 | <webben> | one might as well respect namespace declarations |
| 22:00 | <Hixie> | so why are we inventing a new namespace? |
| 22:00 | <Hixie> | i'm very confused as to what you're proposing |
| 22:00 | <webben> | I guess I'm very confused as to why folks thing XHTML2 reusing the existing namespace is bad, and XHTML5 reusing it is good. |
| 22:01 | <webben> | *why folks think |
| 22:01 | <gsnedders> | webben: XHTML2 breaks backwards compatibility. XHTML5 does not. |
| 22:01 | <Hixie> | if XHTML2 was going to actually be used, then it would be bad to reuse the namespace because it defines elements as having entirely different conformance rules |
| 22:01 | <othermaciej> | webben: how are they supposed to know which namespace to use? |
| 22:02 | <othermaciej> | document.createElementNS("http://www.w3.org/1999/xhtml";, "div") |
| 22:02 | <webben> | othermaciej: who is they? |
| 22:02 | <gsnedders> | webben: as XHTML5 is backwards compatible with XHTML1, XHTML1 parsers can cope with XHTML5 (to a certain extent) |
| 22:02 | <gsnedders> | webben: implementations |
| 22:02 | <othermaciej> | what's the version of that that works when processed as XHTML1, or under a hypothetical new XHTML5 namespace? |
| 22:02 | <Hixie> | e.g. if <input> in XHTML1 is an HTMLInputElement DOM node, and <input> in XHTML2 is an XForms <input>, then there's no way a browser could know what to do when it found an <input> element |
| 22:02 | <webben> | gsnedders: I can't understand why that would be useful though. |
| 22:03 | <gsnedders> | webben: I can create an XHTML5 document that will work with already existing XHTML implementations. |
| 22:03 | <gsnedders> | webben: I don't need to wait for implementations to be updated. |
| 22:03 | <webben> | gsnedders: But why are you creating an XHTML document in the first place? |
| 22:03 | <webben> | is this for use of MathML? SVG? |
| 22:04 | <othermaciej> | gsnedders: implementations are going to handle existing application/xhtml+xml content that's authored as XHTML 1.0 or 1.1 in the future as XHTML5 |
| 22:04 | <othermaciej> | gsnedders: scripts in those documents need to keep working |
| 22:04 | <othermaciej> | gsnedders: therefore the namespace URI needs to be the same |
| 22:04 | <gsnedders> | othermaciej: I know. |
| 22:04 | <othermaciej> | er |
| 22:04 | <othermaciej> | I meant htat for webben |
| 22:04 | <othermaciej> | webben: see above comments |
| 22:04 | <gsnedders> | othermaciej: I thought so :) |
| 22:05 | <Philip`> | I created an XHTML document once, because I had an XML serialiser available and I was too lazy to write an HTML serialiser, though I've not encountered any more compelling reasons myself |
| 22:05 | <webben> | othermaciej: I don't really see why the namespaced element creation is a problem. |
| 22:05 | <webben> | Philip`: My point was mainly that existing implementations don't do a good job of supporting the other XMLs that can be used with XHTML anyhow. |
| 22:06 | <jgraham> | There are people who actually use MathML and SVG, so this problem is not theoretical |
| 22:06 | <webben> | e.g. Mozilla and IE support MathML with extensions; the Mozilla one at any rate only supports presentational MathML. Opera doesn't support MathML except in the form of a user.js (and again only presentational.) |
| 22:06 | <gsnedders> | FWIW: http://digg.com/programming/HTML5_differences_from_HTML4 |
| 22:07 | <othermaciej> | webben: existing documents will expect an "img" in the xhtml1 namespace to be an HTMLInputElement with associated presentation and semantics |
| 22:07 | <jgraham> | Mozilla MathML is built in (but you need fonts) |
| 22:07 | <othermaciej> | webben: I don't see how you can say it doesn't matter |
| 22:07 | <jgraham> | XForms is an extension |
| 22:07 | <othermaciej> | webben: unless you think all the elements should exist in both namespaces |
| 22:07 | <webben> | jgraham: Oh wait sorry. Yeah, you're right. |
| 22:07 | <othermaciej> | webben: in which case, dynamically constructing a document and serializing it would result in a frankenstein mish-mash of two different namespaces for the same elements |
| 22:08 | <Philip`> | (Oh, actually I've created at least two XHTML documents, and one could be considered XHTML5 since it had <canvas>, though the only reason for doing that was so that it'd break in IE and I still didn't have any actual good reasons to use XHTML) |
| 22:08 | <webben> | othermaciej: I'd have thought existing docs would expect an img with associated presentation and semantics defined by XHTML1 if they're using that namespace. |
| 22:08 | <webben> | othermaciej: not any new aspects defined by XHTML5 |
| 22:09 | <gsnedders> | webben: yes, but XHTML5 is compatible with XHTML1. |
| 22:09 | <othermaciej> | webben: so you think existing application/xhtml+xml documents should be processed as XHTML1 instead of as XHTML5? |
| 22:09 | <Hixie> | webben: the rules in XHTML5 are a superset of the rules of XHTML1, the rules in XHTML2 are an overlapping set that contradict some of XHTML1's requirements. |
| 22:09 | <othermaciej> | and all the XHTML1 elements should be in two different namespaces? |
| 22:09 | <gsnedders> | webben: there's no mention of any version in the namespace anyway |
| 22:10 | <webben> | Hixie: Not even the elements in XHTML5 are a superset of those in XHTML1. |
| 22:10 | <webben> | (and same for XHTML2) |
| 22:10 | <Hixie> | webben: anything not yet defined in XHTML5 that is in XHTML1 will be defined in due course (though maybe not as part of the conforming language). anything in XHTML5 that *contradicts* XHTML1 is an error. |
| 22:10 | <gsnedders> | how many groups do namespace URIs goes through before being assigned? |
| 22:10 | <webben> | Hixie: I see. |
| 22:11 | <gsnedders> | (that is w3.org namespaces) |
| 22:11 | <Hixie> | gsnedders: just the director, i think |
| 22:11 | <webben> | Hixie: So XHTML5 will define semantics for <acronym> equivalent to those in XHTML1? |
| 22:11 | <othermaciej> | I don't think there has been a namespace priority dispute before |
| 22:11 | <gsnedders> | Hixie: what I thought. Which may mean whichever group applies to use it may get it. |
| 22:12 | <jgraham> | (see e.g. http://golem.ph.utexas.edu/~distler/blog/archives/001254.html for a IMHO good use of XHTML+SVG+MathML) |
| 22:13 | <webben> | jgraham: I'm not discouraging the use of XHTML+SVG+MathML or saying those things aren't used. |
| 22:13 | <Hixie> | webben: it'll define *processing requirements* for <acronym> equivalent to those in XHTML1 (and indeed already does) |
| 22:13 | <Hixie> | webben: however, it doesn't define "semantics" to elements that are not conforming |
| 22:14 | <webben> | Why not? |
| 22:14 | <Hixie> | gsnedders: in this particular case, it doesn't matter, since the namespace is already minted |
| 22:14 | <webben> | Hixie: Doesn't that mean implementors have to consult other specs/non-specs to find out what elements actually mean? |
| 22:14 | <jgraham> | " anyone who cared about backwards compatibility would be using text/html, wouldn't they?" - sort of implies people won't care if their XHTML breaks in the future |
| 22:15 | <gsnedders> | Hixie: namespace assignments is one section of the process I barely know. What happens when a WG wants to use an already minted one? |
| 22:15 | <Hixie> | webben: i guess we could briefly define semantics (as opposed to processing requirements, which is what browser vendors need) for elements that aren't conforming. |
| 22:15 | <Hixie> | gsnedders: they use it |
| 22:15 | <webben> | jgraham: I wasn't proposing WHATWG make breaking existing XHTML1 content a requirement of conforming to the HTML5 spec. |
| 22:15 | <gsnedders> | Hixie: shit. |
| 22:16 | <Hixie> | gsnedders: there really is no problem with xhtml2 using the xhtml namespace |
| 22:16 | <gsnedders> | Hixie: yes, but that's only due to the lack of implementors |
| 22:16 | <Hixie> | gsnedders: it's actually better than them using their own namespace, as it removes any doubt that someone might implement the spec (since it'd be impossible to implement both) |
| 22:16 | <gsnedders> | I'm more worried for the next time it happens, with two standards, both with major companies backing it and implementing it. |
| 22:16 | <webben> | Hixie: assistive UAs need semantics since they do much more interesting things with semantics than typical GUI UAs |
| 22:17 | <webben> | and in practice that means GUI UAs often need the semantics in order to work out how to expose content to accessibility frameworks |
| 22:17 | <Hixie> | gsnedders: groups that are actually competent at language design wouldn't make that mistake |
| 22:17 | <gsnedders> | Hixie: true. |
| 22:18 | <Hixie> | webben: i don't think it would make the slightest difference to TAs if we included the one-line definition of <acronym>'s semantics or not, in practice |
| 22:18 | <webben> | Hixie: It depends on how self-sufficient the spec is meant to be. |
| 22:19 | <webben> | and how much implementors are meant to continue to try and guess from existing content and other implementations and old specs |
| 22:21 | <webben> | Hixie: certainly helpful to people like Rosmaita and Raman writing their own aural CSS |
| 22:22 | <webben> | (or me, in fact, trying to design some kind of interface for Orca to simply define speech behaviours for different roles ... if I weren't familiar with HTML) |
| 22:23 | <Hixie> | webben: in practice, treating the elements that aren't conforming as having no semantics is fine from an accessibility point of view. so i'm not convinced it matters. the only elements i can think of off-hand that have non-trivial semantics and that aren't conforming are <dir> and <acronym>. |
| 22:23 | <Hixie> | webben: and in practice you can just treat them as the spec will say (handle <dir> like <ul> and <acronym> like <span>) |
| 22:23 | <webben> | Hixie: how does it make any sense to handle acronym like span?!? |
| 22:24 | <Hixie> | webben: you make the title="" attribute accessible and you're done. |
| 22:24 | <webben> | at the very least it should be handled like abbr |
| 22:24 | <Hixie> | webben: it's not like there are many pages using it. |
| 22:25 | <webben> | Hixie: Given the microformats people are trying to work out if they could use span with title to get around the accessibility problems of dumping data into abbr's title, that doesn't sound like a great idea at all. |
| 22:25 | <webben> | Hixie: And given that ATs have special handling for abbr and title, different to their handling for span and title. |
| 22:25 | <Hixie> | show me evidence that it'd be a problem and i might be convinced, but the evidence i've seen is that it wouldn't actually maatter |
| 22:26 | <Hixie> | note that many things that are problems in theory end up being non-issues in the real world |
| 22:26 | <webben> | Hixie: Usually because even bigger problems occlude them, |
| 22:26 | <webben> | Hixie: What about the afore-mentioned difference in behaviour? |
| 22:27 | <webben> | is evidence of that evidence that it would be an issue or not? |
| 22:27 | <Hixie> | my stats suggest <acronym> is used rarely enough that the blind would not lose out if the definitions for some of the acronyms on the web went from being treated like acronyms to being treated like arbitrary titles. |
| 22:28 | <Hixie> | note that i'm not saying it should be illegal to handle <acronym> like <abbr> |
| 22:28 | <Hixie> | just that it's not a big enough deal to warrant its own set of conformance criteria |
| 22:28 | <webben> | How do you quantify that? |
| 22:29 | <webben> | Hixie: Are you basically saying whether an element is worth describing depends on how common it is? |
| 22:30 | <Hixie> | it's certainly one of the considerations |
| 22:30 | <webben> | Well what are the other considerations that bear on <acronym>? |
| 22:31 | <Hixie> | i don't understand the question |
| 22:32 | <webben> | Oh. Hmm. You said frequency of current use is one of the considerations for whether an element is worth describing. So there must be additional considerations. I'm asking what those are. |
| 22:32 | <webben> | (talking here of elements that already exist) |
| 22:33 | <Hixie> | how it's used, how it's implemented, what happens to the content that uses it if the element is just ignored, etc |
| 22:33 | <Hixie> | everything that goes into language design |
| 22:33 | <webben> | Hixie: How far is abbr over-represented in the statistics thanks to abuse by microformats? |
| 22:33 | <Hixie> | that's another example of something to consider |
| 22:34 | <Hixie> | (in practice microformats is hardly on the radar) |
| 22:35 | <webben> | Hixie: Do your statistics attach any particular importance to quality of content and the importance of its accessibility? |
| 22:35 | <Hixie> | i can't really discuss the details, but that is something i am able to track to some extent, yes |
| 22:35 | <webben> | e.g. a qualitative study might (for argument's sake) find the acronym is well-used to introduce special acronyms in well-authored documents |
| 22:35 | <Hixie> | it might |
| 22:35 | <Hixie> | it might also find it's used for selling viagra |
| 22:36 | <Hixie> | who knows |
| 22:36 | <webben> | even though it's not used to mark up every acronym in the documents |
| 22:36 | <webben> | Hixie: My point is that frequency of use isn't particularly meaningful for the utility of preserving <acronym> |
| 22:36 | <Hixie> | i argue that it is |
| 22:36 | <webben> | since it's not necessarily an element one would expect to be used often |
| 22:37 | <Hixie> | however i don't argue it's the only measure |
| 22:37 | <Hixie> | one must take all aspects into account |
| 22:38 | <webben> | Hixie: How disproportionate is its usage to what one would expect its usage to be based on the HTML 4.01 specification? |
| 22:39 | <webben> | And without qualitative studies, how have the other aspects been taken into account? |
| 22:39 | <Hixie> | it's usage is about what one would expect |
| 22:40 | <Hixie> | to answer your second question, i have extensive experience with HTML, having worked for two separate browser vendors and worked with two others, and a number of other people in the community are very experienced as well. we bring our experience to bear on such matters, augmenting our experience with qualitative studies. |
| 22:41 | <webben> | Hixie: No I meant wrt to acronym specifically. |
| 22:41 | <webben> | There's been a lot of argumentation about whether one can replace acronym and abbr with just abbr. |
| 22:41 | <Hixie> | i forget, i mean we decided that three years ago |
| 22:41 | <Hixie> | god only knows what our reasoning was |
| 22:41 | <webben> | But that's quite different to just pretending one of them is a meaningless signifier. |
| 22:42 | <Hixie> | it's very clear (to me at least) that having more than one of these elements is dumb |
| 22:42 | <webben> | Hixie: Like I said, that's a completely different issue. |
| 22:42 | <Hixie> | we can kill both and add a new one, or reuse one of the existing ones (they have about the same usage). |
| 22:42 | <webben> | That's more like: do both <i> and <em> need to be conformant. |
| 22:42 | <Hixie> | killing both and adding a new one seems dumb |
| 22:43 | <Hixie> | so that leaves killing one and keeping one |
| 22:43 | <Hixie> | if we are to do that, it seems like we should keep the one with the more generic name |
| 22:43 | <Hixie> | that's pretty much all there is to it, as far as i can see |
| 22:43 | <webben> | Hixie: Yes ... I don't see why "killing one" involves pretending the other has no semantic. |
| 22:43 | <Hixie> | it doesn't have to |
| 22:43 | <webben> | exactly |
| 22:43 | <Hixie> | i already said that we could mention what <acronym> means in the ua-only part of the spec |
| 22:44 | <Hixie> | i don't think it'd make the slightest difference to the world one way or the other |
| 22:44 | <webben> | Hixie: Yes but then you said it should be treated as <span>. |
| 22:44 | <Hixie> | i think allowing it to be treated as span (and making that the minimum requirement) causes minimial harm |
| 22:45 | <webben> | Hixie: How does it cause /less/ harm than treating it as the new <abbr>, which can be used for marking up acronyms too? |
| 22:45 | <Hixie> | it doesn't cause less harm |
| 22:45 | <webben> | because it seems obvious that it in fact causes more harm |
| 22:45 | <webben> | even if the harm is small |
| 22:45 | <Hixie> | 0.000001 harm units is minimal harm, even if it is more harm than 0.0000001 harm units. |
| 22:45 | <Hixie> | the total harm caused is not the only concern |
| 22:46 | <webben> | No. Minimal means least. |
| 22:46 | <Hixie> | no it doesn't |
| 22:46 | <Hixie> | but whatever. i think allowing it to be treated as span (and making that the minimum requirement) causes little harm. |
| 22:47 | <webben> | Hixie: Shouldn't it be an objective of the spec to cause "least harm"? |
| 22:47 | <Hixie> | no |
| 22:47 | <Hixie> | not to the exclusion of all else |
| 22:47 | <webben> | What's the counter-acting objective? |
| 22:47 | <webben> | (in this case) |
| 22:47 | <Hixie> | implementation simplicity in 50 years when no content using <acronym> exists any more |
| 22:47 | <Hixie> | implementation simplicity for non-TA user agents |
| 22:47 | <Hixie> | simplicity in the spec |
| 22:48 | <webben> | Hixie: non-TA user agents are precisely the agents that cannot afford such simplicity, since they are responsible for exposing content to ATS |
| 22:48 | <Hixie> | like i said, nothing *prevents* them from doing better than the minimum requirement |
| 22:48 | <webben> | effectively, there's not really any such thing as a non-AT user agent ... there's just user agents that break the usability conventions of the host OS |
| 22:49 | <webben> | (e.g. opera treats its current failure to work with windows AT as a bug; ditto webkit) |
| 22:50 | <kingryan> | /away |
| 22:50 | <kingryan> | whoops |
| 22:50 | <webben> | Hixie: What makes you think people are going to convert existing content? |
| 22:51 | <webben> | rather than just archive it? |
| 22:51 | <Hixie> | webben: people aren't going to. but it will be overwhelmed by new content in time, to the point where <acronym> is rarely if ever met by users. |
| 22:51 | <Hixie> | anyway, gotta go. meeting. |
| 22:51 | <webben> | okay, thanks for talking about this :) |
| 22:51 | <webben> | have a good meeting |
