| 00:00 | <TabAtkins> | Then why did you state something to that effect? |
| 00:02 | <Hixie> | i didn't |
| 00:02 | <Hixie> | my position was more subtle than that |
| 00:03 | <TabAtkins> | Obviously too subtle. ^_^ |
| 00:03 | <Hixie> | my point is that if the user clears cookies, the user agent should suggest to the user that if the goal is to prevent user tracking, that clearing the local storage, session storage, web database, flash storage, cache, and other such mechanisms is necessary to ensure the user's privacy |
| 00:04 | <Hixie> | how this happens is up to the ua |
| 00:04 | <Hixie> | whether it happens by just treating them all the same, or by having a complicated six-page explanation in a modal dialog, is up to the UI designer |
| 00:07 | <SamerZ> | what does the "I've read the changes!" button do? |
| 00:07 | <SamerZ> | on the tracker |
| 00:07 | <TabAtkins> | What you actually *said* was: "we have to make sure that clearing one clears the other". |
| 00:07 | <TabAtkins> | You did *not* say "We have to give users the option to clear both at once." |
| 00:08 | <Hixie> | clearing both at once automatically would be ideal, imho, yes |
| 00:08 | <TabAtkins> | Your words imply that it's a requirement that they are cleared together, rather than an option. |
| 00:08 | <Hixie> | but what _i_ want isn't relevant here |
| 00:08 | <Hixie> | as it's not what the spec requires |
| 00:08 | <TabAtkins> | Indeed. As it is, browsers can *choose* to make LocalStorage completely ephemeral, so we can't rely on it. |
| 00:09 | <Hixie> | they can also "choose" to make every click result in the computer exploding, but that doesn't mean we can't use <a href="">. |
| 00:10 | <TabAtkins> | Sure, but no one's suggesting that behavior is vitally important for the user's privacy. ("No one can violate your privacy if the computer's blown up!") |
| 00:11 | <TabAtkins> | On the other hand, *you* are suggesting precisely that wrt LocalStorage. |
| 00:13 | <Hixie> | i also think we should drop style="" and <div>, and that we shouldn't even allow xmlns="" in text/html. So? |
| 00:21 | <AryehGregor> | Dropping <div> without much better CSS support would be kind of insane. |
| 00:21 | <AryehGregor> | Possibly even with unreasonably good CSS support. |
| 00:21 | <Hixie> | like i said, what i want doesn't have much relevance here :-) |
| 00:22 | <AryehGregor> | How would you mark up the <h1> on http://aryeh.name/ without <span>? Maybe an <hgroup> with a few headings? |
| 00:23 | <AryehGregor> | With HTML 5, you can come pretty close to eliminating <div> and <span>, it's true . . . at least for fairly simple stuff. |
| 00:23 | <Hixie> | <span> is fine |
| 00:29 | <AryehGregor> | That's an interesting position. Why is <span> fine but <div> not? Do blocks inherently have more restricted semantics or something? |
| 00:30 | <Hixie> | <span> is fine if used with lang="" or dir="" or the like. |
| 00:30 | <Hixie> | my opinions on this aren't very logical, i should point out |
| 00:31 | <Hixie> | that's why the spec doesn't do what i want :-) |
| 00:45 | <AryehGregor> | Hixie, since when is speccing the result of invalid markup condoning it? |
| 00:54 | <Hixie> | AryehGregor: wasn't the request to allow it? The spec already says what the result is. |
| 00:55 | <AryehGregor> | Ah, okay then, never mind. |
| 00:55 | <AryehGregor> | I'm not an implementor, so thankfully I don't have to look at the parsing section very closely. :) |
| 00:56 | <Hixie> | :-) |
| 00:57 | <MikeSmith> | AryehGregor: I'm looking at http://bugzilla.validator.nu/show_bug.cgi?id=640 and may have a fix for it shortly |
| 00:57 | <AryehGregor> | MikeSmith, nice, thanks. |
| 04:25 | <amstan> | hello everyone |
| 04:26 | <amstan> | have you guys saw this? pretty cool and valid post: |
| 04:26 | <amstan> | http://www.webmonkey.com/blog/This_Spec_Has_a_Posse%3A__Superfriends__Suggest_Changes_for_HTML5 |
| 04:59 | <tantekc> | amstan - thanks for the URL |
| 06:01 | <MFen> | html5lib for python.. anyone in here connected to that? |
| 06:05 | <MFen> | how would i serialize a generic HTMLParser().parse() document instance? |
| 06:05 | <MFen> | HTMLSerializer apparently only works on this treebuilder thing which i don't want |
| 06:06 | <MFen> | and can i not just use it to parse xml? it seems to wrap an html document around everything |
| 06:15 | <MFen> | never mind. all it does is reproduce the broken api of some other thing |
| 06:15 | <MFen> | do i want no namespace support, no unicode support, or random_broken_stuff? i have the power to choose. |
| 07:08 | <othermaciej> | hi everyone |
| 08:09 | <hsivonen> | cursed Unicode normalizations! apparently I wont be able to nuke files on a Linux server over NFS from Mac OS X when the file names differ in NFC and NFD! |
| 08:13 | <hsivonen> | I wonder whose bright idea it was to make Mac OS X use something other than NFC for file names |
| 08:13 | <Dashiva> | Think different |
| 08:15 | <hsivonen> | Apple is violating the first rule of Unicode normalization |
| 08:15 | <hsivonen> | (always use NFC when you write to disk or to a socket) |
| 08:18 | <jgraham> | Something something, fight club reference, something |
| 08:26 | <Dashiva> | hsivonen: When do you use NFD? |
| 08:28 | <hsivonen> | Dashiva: when Mac OS X stringifies a file name, it converts it to an approximation of NFD |
| 08:29 | <hsivonen> | Dashiva: IIRC, it's NFD except NFC for Hangul |
| 08:29 | <hsivonen> | Dashiva: Apple just made stuff up there. it's not exactly NFD! |
| 08:29 | <Dashiva> | No, I mean, when should you use NFD? |
| 08:30 | <hsivonen> | Dashiva: in RAM when doing diacritic-insensitive searches |
| 08:30 | <Dashiva> | Oh, okay |
| 08:46 | <hsivonen> | AryehGregor: thanks for fixing the Wikipedia article on XHTML |
| 09:35 | <zcorpan_> | AryehGregor: send feedback about = in unquoted attributes |
| 09:36 | <zcorpan_> | AryehGregor: it's only disallowed to catch this authoring error: <p class= title=hello> |
| 09:37 | <zcorpan_> | AryehGregor: there are no compat issues with it |
| 09:38 | <zcorpan_> | AryehGregor: also see http://code.google.com/p/html5lib/issues/detail?id=92 |
| 09:39 | <zcorpan_> | AryehGregor: and http://code.google.com/p/html5lib/issues/detail?id=93 |
| 10:08 | zcorpan_ | witnesses another real-world case of <article><header></header><section>...</section><footer></footer></article> |
| 10:08 | <zcorpan_> | and headings in the page <footer> |
| 10:13 | <zcorpan_> | actually maybe we should drop <section> and rely on implied sections |
| 10:13 | <zcorpan_> | it would still do the right thing when you put content in <article> or <blockquote> |
| 10:14 | <zcorpan_> | people are clearly overusing sectioning elements in general and clutter the outline |
| 10:15 | <Hixie> | i think to some extent it's overcompensation |
| 10:15 | <Lachy> | maybe we make <section> without a <header>, <hgroup> or <h1> to <h6> invalid? |
| 10:15 | <Hixie> | we should just get out there with a bunch of articles talking about <article> and using a <div> for the main content |
| 10:15 | <Lachy> | Hixie, I'm in the process of writing an article about that |
| 10:15 | <zcorpan_> | Hixie: i really don't think evang will fix this problem |
| 10:16 | <zcorpan_> | Hixie: it's a problem with the spec; people are using the new elements the way they think they should be used, and the result is bad |
| 10:16 | <Hixie> | lachy: making a <section> without header invalid would break all kinds of use cases |
| 10:16 | <Hixie> | Lachy: cool, i look forward to it |
| 10:17 | <Lachy> | I really don't get how people are reaching incorrect conclusions about how they're meant to be used, since the structure was based on how people frequently used <div><h3>...</h3><p>...</div> |
| 10:17 | <Hixie> | zcorpan_: evang is what introduced this problem, i don't know why it wouldn't solve it |
| 10:17 | <Lachy> | what are the use cases for section without it's own heading? I've been struggling to think of any |
| 10:17 | <zcorpan_> | Hixie: what evang introduced this problem? |
| 10:17 | <Hixie> | open any random blog, there's all kinds of bits of the page that are sections without headings |
| 10:18 | <Hixie> | zcorpan_: "html5 has <article>!" |
| 10:19 | <Lachy> | so it seems that people aren't realising that both <article> is just a special class of <section>, and struggling to realise how to use both together properly |
| 10:19 | <Lachy> | s/that both/that/ |
| 10:19 | <zcorpan_> | maybe it should be <section type=article> |
| 10:19 | <Lachy> | that might work |
| 10:20 | <Lachy> | but makes styling in IE even harder without attribute selectors |
| 10:20 | <Hixie> | how hard can this be, really |
| 10:20 | <Hixie> | maybe i should rename <article> to <blogpost> |
| 10:20 | <Lachy> | Hixie, I didn't think it was hard |
| 10:20 | <Lachy> | I don't think renaming it would help |
| 10:20 | <Lachy> | since it's a structural problem, not a semantic problem |
| 10:20 | <zcorpan_> | Hixie: in this case, it was used for blog posts correctly |
| 10:20 | <zcorpan_> | Hixie: it's just <section> inside that's incorrectly used |
| 10:21 | <Hixie> | oh, then why <section type="">? |
| 10:21 | <zcorpan_> | Hixie: i.e. he wanted a <main> element |
| 10:21 | <Hixie> | i never thought we'd manage to wean people off <div> so fast |
| 10:21 | <Hixie> | i'm getting whiplash |
| 10:22 | <zcorpan_> | because <section type=article><h2/><section><p> *looks* wrong whereas <article><h2/><section><p> doesn't |
| 10:22 | <zcorpan_> | people don't realize <article> is a type of <section> |
| 10:22 | <zcorpan_> | <section type=article> would make it clearer |
| 10:22 | <Hixie> | that isn't the confusion |
| 10:22 | <Hixie> | if it was they'd be doing <article><section><h2/><p>... |
| 10:23 | <Hixie> | but they're putting the header in the article |
| 10:23 | <Hixie> | and then just putting the contents in a section |
| 10:23 | <Hixie> | it _has_ to be for styling, surely |
| 10:23 | <Hixie> | no? |
| 10:24 | <zcorpan_> | no |
| 10:24 | <zcorpan_> | it's not styled in any way |
| 10:24 | <zcorpan_> | no selector in the style sheet is based on the section |
| 10:24 | <zcorpan_> | it's just that they think it's the right thing to do |
| 10:25 | <annevk2> | funny, I think we should drop <article> |
| 10:25 | <Hixie> | i wish i understood how authors were coming to this conclusion |
| 10:25 | <Hixie> | is there some documentation somewhere that they're all following? |
| 10:25 | <jgraham> | I wonder what the "many use cases" are for untitled sections. Like how to they translate to UA features? |
| 10:25 | <Hixie> | is this problem really widespread? |
| 10:25 | <Hixie> | someone should study a random sample of sites from html5gallery |
| 10:26 | <zcorpan_> | Hixie: i've seen it several times with people trying to use html5 |
| 10:26 | <Hixie> | anecdotal evidence is often misleading |
| 10:26 | <Hixie> | i think we need hard data on this |
| 10:26 | <jgraham> | BTW I already tried the evangalism thing. Whilst the WHATWG blog might not be the best pulpit you might have thought it would reach early adopters |
| 10:26 | <jgraham> | AT least indirectly |
| 10:27 | <Lachy> | html5doctor and ALA seem to be among the best places to reach early adopters |
| 10:27 | <zcorpan_> | html5doctor did the exact same mistake |
| 10:27 | <Lachy> | I'm planning to get my sectioning article published on either or both of those places |
| 10:28 | <Lachy> | zcorpan_, yeah, I know. I suspect that might be where develoeprs are learning it from |
| 10:28 | <zcorpan_> | this guy sais he sees the structure of <article> the same as <table> |
| 10:28 | <Lachy> | which guy? |
| 10:29 | <zcorpan_> | a friend |
| 10:29 | <jgraham> | I think part of the fix has to be making UAs robust to failure. That means ignoring untitled sections when calculating nesting depth |
| 10:30 | <Lachy> | the question is, do they want the structure to be like a table, or is that just how he perceives it was designed? |
| 10:30 | <zcorpan_> | he says that since he framed the content in a <header> part and a <footer> part, it felt natural to frame the content part in some element too |
| 10:30 | <zcorpan_> | author of http://www.frojd.se/ |
| 10:30 | <Hixie> | sigh maybe we should just give people a meaningless <content> element |
| 10:31 | <annevk2> | s/article/main/ plus the appropriate changes to its semantics |
| 10:31 | <jgraham> | Hixie: I think that is a good idea. |
| 10:31 | <Hixie> | or heck, maybe the simplest solution is just to special-case a heading-less section in the outline as a direct child of another section |
| 10:31 | <Hixie> | that actually might be the better solution |
| 10:31 | <Hixie> | since if we introduce another element, it's bound to get misused even more |
| 10:32 | <zcorpan_> | makes sense |
| 10:32 | <jgraham> | I think there is a balance in the design process between things that are designed to transmit semantics and things that make authoring easy |
| 10:32 | <jgraham> | <content> would make authoring easier |
| 10:33 | jgraham | doesn't like the idea os special cases |
| 10:33 | <Hixie> | well it wouldn't make it any easier than an ignored <section>, right? |
| 10:33 | <Hixie> | how do we get people to use <content> instead of <section>? |
| 10:33 | <annevk2> | content { ... } section { ... } |
| 10:34 | <zcorpan_> | we say <content> is the elemetn to use between <header> and <footer> |
| 10:34 | <jgraham> | Hixie: It would because people seem to have a mental model of their content that splits it into distinct logical areas; "header", "content", "sidebar", "footer" |
| 10:34 | <Hixie> | i think we need hard data on how much of an issue this is, if we're going to add another element. we definitely don't want to be doing something quite as drastic if it's not a real problem. |
| 10:34 | <Hixie> | jgraham: pity we can't reuse <body> |
| 10:35 | <Hixie> | <sbody> (section body) |
| 10:35 | <annevk2> | Hixie, I think another look at some URLs of your 2005 webstats study could be sufficient |
| 10:35 | <Lachy> | Hixie, if we use the name <content>, then is the clash with the <content> element in XBL2 problematic as was suggested on the list? |
| 10:35 | <Hixie> | annevk2: i think we should take a random sample of html5gallery pages |
| 10:35 | <Hixie> | annevk2: and see how many do this wrong |
| 10:36 | <annevk2> | that also seems like a good idea, but checking what class=content is used for given http://code.google.com/webstats/2005-12/classes.html would also give a clue |
| 10:36 | <Hixie> | Lachy: yeah <content> is probably suboptimal. |
| 10:36 | <Hixie> | i kinda like <sbody> |
| 10:36 | <annevk2> | or class=main for that matter |
| 10:36 | <Hixie> | annevk2: i'm more interested in how big a problem it is, rather than how many sites used <div>s in this way |
| 10:37 | <zcorpan_> | i think <main> is a better name than <sbody> (unless header and footer are renamed to <shead> and <sfoot>) |
| 10:37 | <jgraham> | <sbody> isn't going to work. It will _really_ help if it is a simple english word that means "content" or "main" |
| 10:37 | <Hixie> | <main> doesn't work since there could be one per section |
| 10:37 | <jgraham> | I don't think that matters |
| 10:37 | <zcorpan_> | i think <content> is a better name than <sbody> too |
| 10:38 | <annevk2> | I'm not sure allowing <header> / <footer> anywhere else than <body> is a good idea either |
| 10:38 | <jgraham> | annevk2: I don't see why |
| 10:38 | <jgraham> | Why can't a blog post have a header? |
| 10:38 | <jgraham> | I agree that the <footer> content model should be changed to be the same as header |
| 10:38 | <Lachy> | annevk2, it is, because allowing sections to have additional introductory content in addition to the heading is useful |
| 10:39 | <jgraham> | In practice they are almost interchangable in the type of content they can contain |
| 10:39 | <Hixie> | <footer>'s content model has been the same as <header>'s for at least 30 minutes now |
| 10:39 | <zcorpan_> | jgraham: yes; frojd.se also has a "fat footer" |
| 10:39 | <Hixie> | keep up :-P |
| 10:39 | <zcorpan_> | oh |
| 10:39 | <Lachy> | cool |
| 10:39 | <Dashiva> | So RDFa doesn't actually use namespaces... yet they chose to use namespace-like attributes? |
| 10:39 | <jgraham> | Hixie: :p |
| 10:40 | <Dashiva> | Why would you do that |
| 10:40 | <annevk2> | to mislead the XML gods |
| 10:40 | <annevk2> | apparently it worked |
| 10:40 | <annevk2> | jgraham, the header of a section is way different from the header of a page |
| 10:40 | <annevk2> | jgraham, same for footer |
| 10:41 | <jgraham> | annevk2: Why? |
| 10:42 | <Lachy> | annevk2, they will obviously contain different content, but conceptually and structurally, they are analogous |
| 10:42 | <Hixie> | ok so plan of attack for this section issue is to look at html5galley, and if it shows more than, say, 50% of a random sample of blog-like pages are doing this wrong, then we introduce a new element that is allowed only as a direct child of sectioning content, and only if the sectioning content only contains <header>, <footer>, this element, and/or heading content. (assuming that makes sense given the errors we see) |
| 10:42 | <zcorpan_> | annevk2: maybe the content models of <header> and <footer> should be sensitive to whether they're in <body> or in a nested section? |
| 10:42 | <Hixie> | seem reasonable? |
| 10:42 | <Hixie> | i think y'all are way too eager to change things, btw. leave <header> and <footer> alone already. they're fine. :-) |
| 10:42 | <Hixie> | (now) |
| 10:42 | <annevk2> | jgraham, for a page it gives the title of the weblog, tagline, navigation etc. whereas for <section> you would not have something equivalent I think |
| 10:43 | <annevk2> | jgraham, maybe for <article> but even there it is quite different imo |
| 10:43 | <zcorpan_> | Hixie: we should allow the new element in <body> too |
| 10:43 | <Lachy> | zcorpan_, no, making the content models contextually sensitive would be confusing for authors |
| 10:43 | <zcorpan_> | Lachy: yeah, probably |
| 10:43 | <annevk2> | Hixie, to be frank I'm not sure we studied this problem in as much detail as e.g. the parsing algorithm |
| 10:44 | <Lachy> | and it also wouldn't make sense. What exactly would you want to restrict from one or the other? |
| 10:44 | <Hixie> | zcorpan_: yes, and <body>. |
| 10:44 | <annevk2> | Hixie, which is why I think not everyone is quite so sure about it being ok |
| 10:44 | <zcorpan_> | Lachy: i would allow nested sections in body <footer> but not other <footer>s |
| 10:44 | <Hixie> | zcorpan_: <article> elements should be able to have colophons |
| 10:45 | <zcorpan_> | yeah |
| 10:45 | <Hixie> | ok well i'm going to bed now. |
| 10:46 | <Hixie> | hopefully the data fairies will do the study on the html5gallery data so i don't have to tomorrow :-P |
| 10:46 | <Hixie> | nn |
| 10:47 | zcorpan_ | is not a data fairy today |
| 10:48 | <Lachy> | I will take a look later, no-one else does |
| 10:53 | <annevk2> | out of 8, I found 2 sites that used <section> in this way |
| 10:53 | <annevk2> | I also found one site that used <header> instead of <hgroup> |
| 10:53 | <annevk2> | and one site that used <article> instead of <section> |
| 10:54 | <Lachy> | we should drop hgroup anyway. It's unnecessary |
| 10:54 | <annevk2> | not sure I agree, but anyway, there are 142 sites and I don't have time right now |
| 10:55 | <annevk2> | if anyone starts I suggest a table in a wiki so it's easy for others to help out |
| 10:57 | <Lachy> | I've documented more of the polyglot checking issues. http://wiki.whatwg.org/wiki/Validator.nu_Useful_Warning_Requests#Polyglot_Document_Checking |
| 10:57 | <Lachy> | If anyone feels motivated to add more, feel free |
| 10:59 | <annevk2> | polyglot = boring |
| 10:59 | <annevk2> | (except when debated) |
| 11:00 | <Lachy> | annevk2, my reason for documenting all of this is so that when the issue is being discussed with people like Tantek and Zeldman who want the validator to check for such issues, we can point them there and get a concrete list of issues they want to have checked |
| 11:03 | <jgraham> | Sigh. The RDFa people are really trying to have their namespace cake and eat it too |
| 11:05 | <annevk2> | Mark Birbeck still does not understand either a) that we think ignoring the namespace of an attribute is wrong or b) that xmlns:<prefix> is in a namespace in XML |
| 11:05 | <annevk2> | And given that it has only been explained a 100 times before I guess that is perfectly reasonable... |
| 11:43 | <Lachy> | Hixie, http://www.w3.org/Bugs/Public/show_bug.cgi?id=7483 can now be resolved |
| 12:05 | <hsivonen> | Lachy: Making a section with foo invalid would be pain to WYSIWYG editors |
| 12:12 | <hsivonen> | I wonder if the RDFa TF was clear with the TAG that RDFa doesn't "use namespaces" |
| 12:13 | <Philip`> | getElementsByTagName+lookupNamespaceURI is "not standard DOM methods"? |
| 12:15 | jgraham | is bemused |
| 12:15 | <hsivonen> | Philip`: context? |
| 12:16 | hsivonen | sees it now |
| 12:17 | <hsivonen> | Philip`: fwiw, the way lookupNamespaceURI is defined makes it theoretically brittle for RDFa-in-XML |
| 12:17 | <hsivonen> | Philip`: in the case of synthetic DOMs |
| 12:18 | <Lachy> | hsivonen, yeah, I also realised it wouldn't catch many cases where authors do things wrongly anyway |
| 12:18 | <hsivonen> | Philip`: lookupNamespaceURI looks at frozen element node namespace/prefix bindings in addition to looking at namespace declarations |
| 12:18 | <Philip`> | (The getNamespaces method seems to be non-standard, but you don't need that to do lookups) |
| 12:18 | <hsivonen> | Philip`: W3C specs say the darnest things |
| 12:19 | <Lachy> | In what way does RDFa not use namespaces? |
| 12:20 | <Lachy> | what's the point of them using xmlns and prefixes if they don't? |
| 12:21 | <Philip`> | I guess the point is to be compatible with XML Namespaces syntax (and nothing else matters) |
| 12:21 | <hsivonen> | Lachy: http://krijnhoetmer.nl/irc-logs/whatwg/20090904#l-414 |
| 12:21 | <jgraham> | Lachy: Mark Birbeck's position appears to be that they use namespace syntax but must not be processed in a namespace-aware way |
| 12:22 | <Dashiva> | So why use the namespace syntax then? |
| 12:22 | <Lachy> | hmm, ok. Is that because they do that weird thing where they just prefix the namespace URI to the localname? |
| 12:22 | <Philip`> | jgraham: I don't remember anyone suggesting "must not", just "does not have to (but can if you've got a suitable API; it doesn't matter as long as you get the same result from the same syntax)" |
| 12:23 | <jgraham> | Philip`: "The original objection was that different processing is required for |
| 12:23 | <jgraham> | different DOMs, and I think we've shown that's not the case; all that |
| 12:23 | <jgraham> | is required is to iterate through the list of atttributes, and pull |
| 12:23 | <jgraham> | out those that begin "xmlns:"." |
| 12:23 | <jgraham> | As far as I can tell the only way to make sense of that would be to forbid using namespace aware processors |
| 12:24 | <Philip`> | jgraham: (Some) namespace aware processors let you iterate through the list of attributes and pull out xmlns:* |
| 12:24 | <hsivonen> | Lachy: the RDFa TF is programming with namespace-unaware tools (Mark Birbeck: IE, Shane: the perl lib, Ivan Herman: Python minidom) |
| 12:24 | <Philip`> | e.g. web browser DOMs do |
| 12:24 | <Philip`> | jgraham: so they still satisfy that requirement |
| 12:25 | <hsivonen> | Lachy: whereas people here are programming with libraries whose authors have drank the Infoset kool aid |
| 12:25 | <hsivonen> | Lachy: hence, diffent world views |
| 12:25 | <hsivonen> | *different |
| 12:25 | <zcorpan_> | we should see the light and stop caring about namespaces and namespace-aware APIs |
| 12:26 | <Dashiva> | I just don't get it. If they aren't using namespaces, why use the one set of attributes that cause trouble? |
| 12:28 | <jgraham> | Dashiva: Presumably because it scores brownie points with TAG |
| 12:28 | <Philip`> | Dashiva: Because it doesn't cause trouble |
| 12:28 | <Philip`> | (when you use namespace-unaware APIs) |
| 12:29 | <Dashiva> | jgraham: Nice order of constituencies :) |
| 12:29 | <Philip`> | and because it can reuse the normal xmlns processing model, rather than having to define its own that's almost identical but slightly different |
| 12:29 | <jgraham> | Philip`: Neither does a mechanism that doesn't cause trouble when you _do_ use namespace aware APIs |
| 12:29 | <Philip`> | (and thus avoid reinventing wheels) |
| 12:30 | <Dashiva> | processing model? |
| 12:30 | <Dashiva> | You mean doing a string split on :? |
| 12:31 | jgraham | isn't sure what Philip` means by "xmlns processing model" but Mark has explicitly stated that authors are expected to keep track of prefixes at the application level, independent of the ns machanisms |
| 12:32 | <Philip`> | jgraham: I just mean the definition of what namespace bindings are in scope at a particular element, which is (I'd hope) defined in the Namespaces spec and so RDFa just references that instead of redefining it (even if practical implementations will reimplement it) |
| 12:36 | <jgraham> | Philip`: It seems highly misleading to imply that processing happens per xmlns when in fact you are actually required to ignore xmlns and do your own prefix binding processing |
| 12:36 | <Philip`> | jgraham: You're not required to ignore it, you could do it with lookupNamespaceURI if you wanted |
| 12:37 | <Philip`> | and the result is equivalent to the normal proper xmlns processing |
| 12:38 | <Philip`> | (though it's sufficient (but not necessary) to just have an API that exposes a list of namespace-unaware attributes per element) |
| 12:39 | <hsivonen> | Dashiva: it's politically expedient in the W3C to use namespace-looking syntax. It gets you an applause even if you break the XML architecture all over. |
| 12:39 | <hsivonen> | Dashiva: remember the aria:foo debate |
| 12:40 | <Dashiva> | Will we ever learn? |
| 12:40 | Philip` | goes away |
| 12:45 | <Lachy> | This appears to be the first suggestion for renaming <sidebar> to <aside> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2005-March/003355.html |
| 12:45 | <Lachy> | I can't see much discussion about the name itself, but the next e-mail I found that mentions it simply refers to it as though it's already in the spec |
| 12:53 | <hsivonen> | FWIW, I thought <aside> was for callouts foremost |
| 13:00 | <Lachy> | hsivonen, it's primary usecase seems to have shifted. <sidebar> was introduced to address the common case of <div id="sidebar">, then adjusted to also address callouts as being tangentially related content |
| 13:00 | <Lachy> | and then renamed to <aside> based on that |
| 13:07 | <jgraham> | FWIW <header> <footer> <content> and <sidebar> make sense as "structural" elements to me. <aside> or <callout> seems more like <section> |
| 13:10 | <jgraham> | More specifically, I would expect <sidebar><nav></nav></sidebar> to increment the heading depth by 1 whereas I would expect <aside><nav> to increment the heading depth by 2 |
| 13:12 | <Lachy> | if we make <aside> inappropriate for page sidebars, then I would change it so that it's no longer a sectioning element |
| 13:13 | <Lachy> | and I would expect <sidebar> to be a sectioning element. |
| 13:15 | <jgraham> | Lachy: That is quite the opposite of what I would expect. Typically a sidebar doesn't have an overall heading but might contain several sections with headings e.g. <nav><h1>Archives <section><h1>Tags and so on |
| 13:15 | <Lachy> | so, e.g. on my site, I would do <sidebar><h1>Other Resources</h1> <section><h1>Friends</h1>...</section> <section><h1>HTML5 Stuff</h1> ...</section> |
| 13:15 | <jgraham> | Whereas a pullout box can often have a heading |
| 13:16 | <jgraham> | Lachy: Why not just use <nav> if it is purely links? |
| 13:16 | <Lachy> | because it's a sidebar. On my blog (when it was using the same template) it also contained the search form |
| 13:18 | <Lachy> | (maybe the individual <section> elements in what I wrote above could use <nav> though) |
| 13:19 | <Lachy> | if we fixed the sectioning algorithm as you previously suggested, so that sections without a heading don't affect the heading level, then it wouldn't be a problem. |
| 13:19 | <jgraham> | Lachy: True |
| 13:22 | <karlushi> | I have a tendency to classify elements like this: structure (p, ul, …) / semantic (q, cite, title, …) / functional (form, div, span, …) |
| 13:23 | <hsivonen> | karlushi: interesting categorization of div and span :-) |
| 13:24 | <karlushi> | hsivonen: yes, my reasoning is that their only purpose is that you need to attached something else to it which gives their intended meaning. |
| 13:26 | <karlushi> | The discussion around elements such as footer, header, etc. "bothers" me a little bit, because they seem awkward when things like <ads> or <logo> are not taken into account. But I'm not sure how to rationalize why it bothers me. |
| 13:26 | <erlehmann> | karlushi, is a list not semantic ? maybe you mean text-level-semantics ? |
| 13:26 | <erlehmann> | <ads> ahaha oh hwow |
| 13:27 | <karlushi> | erlehmann, a list can be of many types :) from shoping list to do list |
| 13:27 | <karlushi> | s/to do/to todo/ |
| 13:27 | <erlehmann> | i can see it coming "implementors MUST provide a config option to disable rendering of <ad> elements" |
| 13:27 | <karlushi> | erlehmann, ;) |
| 13:28 | <erlehmann> | karlushi, lists are inherently semantic. that is why we have ordered and unordered and definition lists, to cater to that. |
| 13:29 | <karlushi> | that would be a nice and interesting side effects on the whole system. A bit like in magazine in France where publishers have to flag ads which are written like articles :) |
| 13:30 | <erlehmann> | karlushi, you always have to take the real-world into account. while things such as @autoplay can be there just to disable them, no one would use <ad> elemetns. |
| 13:30 | <karlushi> | erlehmann, depends on the definition of semantics. :) let's change the terms: Structure (list, paragraph, headers, sections, etc.) and Meaning (poem, dialogs, quotes, etc.) |
| 13:31 | <karlushi> | real world is not a good argument as everything is always real. The rest is cultural, economic context. :) |
| 13:32 | <erlehmann> | karlushi, i dialog is a special type of ordered list. |
| 13:33 | <karlushi> | erlehmann: yes. ordered list: a text *structure* which can have the *meaning* of a dialog |
| 13:35 | <erlehmann> | karlushi, i dont get the finer points of your statements. speak easy |
| 13:43 | <Lachy> | Interestingly, the first suggestion for a <content> element I've found came from Hixie in 2004 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-August/002114.html |
| 13:44 | <hsivonen> | grr. that page triggers an elusive Necko bug |
| 13:45 | <Lachy> | Necko bug? |
| 13:45 | <Philip`> | hsivonen: "defer to the HTML5 rules for determining the language of a node" - http://html5.digitalbazaar.com/specs/rdfa.html#specifying-the-language-for-a-literal sounds like it's trying to defer to the HTML5 definition, so I don't think that's an especially controversial idea (though the details might be fuzzy in that spec) |
| 13:45 | <hsivonen> | Philip`: ah cool. Manu fixed the draft. |
| 13:46 | <Lachy> | hsivonen, what's the Necko bug? That page works fine for me in Minefield |
| 13:46 | <hsivonen> | Lachy: sometimes when reading WHATWG archives, Necko claims that the server sent bogus gzip data |
| 13:47 | <Philip`> | hsivonen: Hmm, I thought it always said that |
| 13:47 | <Lachy> | ah, like this "Content Encoding Error" I get in Minefield on this page? http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2005-April/003377.html) |
| 13:47 | <hsivonen> | Lachy: yes |
| 13:47 | <Philip`> | (i.e. since a few days ago when it was published) |
| 13:47 | <Lachy> | hsivonen, is there a bug filed about that in bugzilla? |
| 13:48 | <hsivonen> | Lachy: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-August/002114.html |
| 13:48 | <Lachy> | I think I've manged to track down sufficient information about the history of <sidebar> and <aside> now. Mail sent. |
| 13:49 | <Lachy> | hsivonen, yeah, that's the link I posted above. What about it? |
| 13:50 | <hsivonen> | Lachy: oops. sorry. clipboard problem. |
| 13:50 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=501953 |
| 14:10 | <jgraham> | I guess <figure>-as-<aside> might even make more sense than the current model |
| 14:10 | <jgraham> | Although I am increasingly unhappy with the whole sectioning root thing |
| 14:11 | <beowulf> | what bruce lawson describes as an aside seems to me tobe a section with a singular style in his design |
| 14:14 | <jgraham> | I think <figure>-as-<aside> would workj if you could do <figure><legend><h1>Box A</h1> and have it appear in the outline of the main document, but the complexity of that just made my head explode |
| 14:14 | <Lachy> | figure-as-aside doesn't make that much sense to me. I perceive <figure> for the kind of things that would typically be labelled "Figure #. Caption..." in a book, like images, tables, code fragments, etc. |
| 14:14 | <Philip`> | Can we just get rid of all these structural elements? |
| 14:14 | <Lachy> | no |
| 14:14 | <Philip`> | Hmph |
| 14:15 | <jgraham> | Lachy: Agreed that the name doesn't really work |
| 14:15 | <jgraham> | But the spec-wide definition does |
| 14:15 | <jgraham> | *wise |
| 14:16 | <Lachy> | I'd rather we keep <figure> as is, make <aside> for pullouts only, rather than sidebars, and introduce <sidebar> to replace the common cases of <div id="sidebar">, <div class="right">, etc. |
| 14:16 | <jgraham> | Lachy: I think that is my prefered solution too. But I could live with dual purposing figure |
| 14:16 | <jgraham> | (Note the definition is "The figure element represents some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document.") |
| 14:17 | <Lachy> | jgraham, if we dual-purpose <figure>, would you introduce <sidebar> or keep <aside> for that? |
| 14:17 | <lazymanc> | I'd prefer a defined list of roles and just using <div role="sidebar"> etc |
| 14:17 | <jgraham> | <sidebar> |
| 14:17 | <Lachy> | agreed. |
| 14:18 | <Lachy> | lazymanc, no, that makes styling more difficult for authors since it requires the less commonly used attribute selectors that not all authors are familiar with, and which IE still doesn't support. |
| 14:19 | <Lachy> | oh, actually, they were CSS2, so it might |
| 14:20 | Philip` | forgot to mention xmlns:xml and xmlns:xmlns in his latest email |
| 14:20 | <Lachy> | yep, IE8 does support them. |
| 14:20 | <lazymanc> | IE doesn't support <sidebar> <header> <footer> etc though |
| 14:20 | <Lachy> | there's a simple workaround to make IE parse those elements reasoanbly, and styling them isn't much of a problem |
| 14:20 | <Philip`> | Are there any more cases that are well-formedness errors in XML/Namespaces, where a non-XML processor would need special rules? |
| 14:21 | <lazymanc> | if you're writing a spec for the future obviously you've got to take into account backwards compat, but you're going to introduce stuff that's not supported by the vendors yet |
| 14:22 | <lazymanc> | I'd like to see textarea and select as input types |
| 14:22 | <lazymanc> | for consistency and ease of styling |
| 14:22 | <lazymanc> | obviously keeping the old tags for backwards compat |
| 14:23 | <Lachy> | lazymanc, not going to happen, and it's not clear how using <input> would make styling any easier for them |
| 14:25 | <lazymanc> | Lachy: well say you want to set a default font style / colour for all your inputs, input { // foo: bar; } is quicker and easier to remember than input, textarea, select { foo: bar; } |
| 14:26 | <Philip`> | How would parsing work? |
| 14:26 | <AryehGregor> | Same as it works now . . . |
| 14:26 | <Philip`> | <input type=text value=foo> vs <input type=textarea>foo</input> ? |
| 14:26 | <Philip`> | vs <input type=select><option>...</input> ? |
| 14:26 | <AryehGregor> | The philosophy in HTML 5 has generally been to not introduce new elements solely for greater future consistency. |
| 14:27 | <AryehGregor> | Hmm, that would make <input> a non-void element, you're right. |
| 14:27 | <lazymanc> | what's wrong with <input type="textarea" value="some content" /> |
| 14:27 | <Lachy> | Philip`, it wouldn't work for type=select, but presumably type=textara could just be limited to the value attribute, which isn't such a good idea anyway |
| 14:27 | <Philip`> | lazymanc: That's hard to use when you've got multiple lines of content |
| 14:28 | <AryehGregor> | lazymanc, it's identical to <textarea>. HTML 5 doesn't usually introduce new features that are identical to existing features for the sake of consistency. |
| 14:28 | <AryehGregor> | Arguably that would be a good move. |
| 14:28 | <Philip`> | since you'd have to encode newlines as 	 or something I guess |
| 14:28 | <AryehGregor> | Hmm, that's a good point. |
| 14:28 | <AryehGregor> | &#a;. :) |
| 14:28 | <AryehGregor> | In this case there's actually a good reason to not have it be <input>. |
| 14:28 | <lazymanc> | AryehGregor: I would argue that it should, we should fix the inconsistencies while we have the chance to benefit future content authors |
| 14:28 | <Philip`> | AryehGregor: 
 :-P |
| 14:28 | <lazymanc> | at least while it doesn't cause problems with BC |
| 14:29 | <AryehGregor> | Er, right, or . |
| 14:29 | Philip` | knows CRLF=0D0A, so he's not sure how he arrived at 	 |
| 14:29 | <Lachy> | lazymanc, we don't really have a chance to fix this now, and your proposed "fix" has already been demonstrated to be flawed. |
| 14:29 | <AryehGregor> | lazymanc, we could reasonably do something like require UAs to support the feature, but make it invalid markup. And then later, when all UAs support the feature, make the old feature non-conforming (but keep it specced). |
| 14:30 | <AryehGregor> | But it seems the important people don't want to do that. |
| 14:31 | <Philip`> | lazymanc: We can't remove support for old syntax, and can't remove old content that uses it (and tutorials and editors etc), so adding new 'consistent' syntax for the same features will just result in the language being twice as large and even more inconsistent |
| 14:31 | <lazymanc> | Lachy: i'm not saying that's the way it has to be done, i'm sure there are alternatives |
| 14:31 | <AryehGregor> | E.g., require UAs to support <style src="foo"></style>, but make it non-conforming. Then 15 years from now when all UAs anyone uses support that, make it conforming and make <link rel=stylesheet> nonconforming. |
| 14:31 | <AryehGregor> | Philip`, not in the long term, though. In the long term you could eventually make the old way of doing it nonconforming. |
| 14:31 | <AryehGregor> | Then the conforming part of the language would be just as small and more consistent. |
| 14:31 | <lazymanc> | I'm not suggesting removing <textarea> and <select>, just to have the option of <input type="textarea" and then maybe depreciating <textarea> at some point down the line |
| 14:32 | <Lachy> | lazymanc, you wanted a solution using the <input> element, and there isn't one. The only other alternative is to use another element, which we already do. So problem solved. |
| 14:32 | <Philip`> | AryehGregor: Then the conforming part of the language wouldn't correspond to existing content, or to existing tutorials etc, so it'd become even more confusing |
| 14:32 | <AryehGregor> | lazymanc, value="" is annoying for multiline input. |
| 14:32 | <AryehGregor> | Philip`, that's already the case. |
| 14:32 | <AryehGregor> | And will be whenever old content is made non-conforming. |
| 14:32 | <AryehGregor> | Hmm, well. |
| 14:32 | <lazymanc> | AryehGregor: agreed, is there a reason the input element cannot be optionally void? |
| 14:32 | <AryehGregor> | I guess HTML 5 actually doesn't tend to remove stupid things people were formerly advised to do. |
| 14:32 | <AryehGregor> | Like xmlns and /> and whatever. |
| 14:33 | <AryehGregor> | So scratch what I said. |
| 14:33 | <Philip`> | AryehGregor: Sure, but it's something that should be minimised, by avoiding making things non-conforming just for the sake of consistency |
| 14:33 | <AryehGregor> | lazymanc, no element in the HTML syntax is optionally void. |
| 14:33 | <AryehGregor> | Philip`, I see your point. It's pretty annoying, though. |
| 14:33 | <Philip`> | AryehGregor: HTML is pretty annoying :-) |
| 14:33 | <Lachy> | lazymanc, yes, because it would make parsing dependent on the value of an attribute, which means feeding back information from the tree construction to the tokenisation stage |
| 14:33 | <AryehGregor> | Just because we acknowledge that pragmatically we have to support old content, that doesn't mean we have to *totally* give up on making the language nicer in the long term. |
| 14:34 | <AryehGregor> | Lachy, c'mon, that's not half as horrible as a lot of things HTML parsers have to do anyway. :) |
| 14:34 | <Lachy> | actually, no, that's wrong |
| 14:34 | <Philip`> | I think the usual response to people wanting to make the language cleaner was "you should join the XHTML2 WG", but that response is not going to work any more :-/ |
| 14:34 | <AryehGregor> | But it would *decrease* consistency to have exactly one optionally void element. |
| 14:34 | <Philip`> | Parsing is already dependent on the value of an attribute |
| 14:34 | <AryehGregor> | Philip`, sure it will, it will be even more cutting! |
| 14:34 | <Philip`> | because of <input type=hidden> in foster-parented table content |
| 14:35 | <Lachy> | Philip`, in this case, I don't think lazymanc would like that anyway, since XHTML2 uses XForms, and they make the problem worse by replacing <input> with new elements for all new controls |
| 14:36 | <Lachy> | AryehGregor, the argument that HTML5 parsers already have to do a lot of horrible things is not a reason to make it do more horrible things |
| 14:36 | <AryehGregor> | Sure. |
| 14:42 | <lazymanc> | ok so I agree that there are problems with the suggested fixes, it's just annoying that with new input types being added, these two existing ones can't be bent into shape |
| 14:46 | <Philip`> | The language is like a paperclip |
| 14:46 | <Philip`> | It's bent, but if you try to bend it more to straighten it out, it'll end up with an infuriating little wobble in the middle instead of actually being straight, and if you try enough times it'll snap in half |
| 14:46 | Philip` | isn't sure this is the best analogy :-( |
| 14:50 | <lazymanc> | Philip`: it's pretty good |
| 14:51 | <lazymanc> | with regards to BC, will the new elements be ignored by older browsers without support? |
| 14:51 | <Lachy> | lazymanc, what are you using "BC" to stand for? |
| 14:52 | <lazymanc> | or will using html5 elements actually break the rendering? Lachy: backwards compatibility |
| 14:52 | <Lachy> | ah |
| 14:53 | <Lachy> | lazymanc, it depends what you mean by "break the rendering". If you're not careful, the elements won't have the correct default style. e.g. you need to specify display: block for the new sectioning elements |
| 14:54 | <Lachy> | and you also need to make sure you explicitly close <p> elements with </p> if it precedes one of the new sectioning elements like <section> |
| 14:54 | <Lachy> | but their presence in the DOM won't inherently break things |
| 14:54 | <lazymanc> | Lachy: ok thanks |
| 15:01 | <hsivonen> | Hixie: bz says the server for the WHATWG archives is buggy: https://bugzilla.mozilla.org/show_bug.cgi?id=501953#c10 |
| 15:08 | <Lachy> | hsivonen, should the second response from the server also be gzipped? |
| 15:10 | <hsivonen> | Lachy: I expect so |
| 16:38 | <Philip`> | annevk3: http://philip.html5.org/data/charsets-2.html exists though I have no idea how correct it is |
| 16:39 | <Philip`> | (Particularly the error percentages seem totally bogus) |
| 16:40 | <Philip`> | (and also there's no meta-sniffer data, because it took ages and the machine on which I ran the SSH session to the machine running the analysis died so it stopped halfway through) |
| 20:11 | <Hixie> | hah, now zeldman is claiming credit for the <footer> change |
| 20:11 | <Hixie> | even though it was made in response to unrelated feedback |
| 20:14 | <miketaylr> | Hixie: i saw that too |
| 20:20 | <Lachy> | hsivonen, yt? |
| 20:21 | <Lachy> | hsivonen, I found a bug in your HTML5 parser in Gecko relating to <textarea> followed by LFs |
| 20:21 | <Lachy> | I will file a bug shortly |
| 21:33 | <Lachy> | Hixie, was <footer> changed based on e-mails that were sent months ago? |
| 21:34 | <Hixie> | iirc it was based on an e-mail that was a reply to maciej's, influenced by the feedback from a few months ago, yes |
| 21:40 | <Lachy> | wow, I don't understand JF's latest complaint about IRC discussions |
| 21:41 | <Lachy> | the discussion he linked to from earlier today clearly didn't reach any conclusions or cause any relevant spec changes |
| 21:47 | <othermaciej> | Lachy: where is his complaint to be found? |
| 21:48 | <Lachy> | http://lists.w3.org/Archives/Public/public-html/2009Sep/0267.html |
| 21:57 | <Dashiva> | Lachy: Not to mention the IRC logs are posted publicly |
| 22:00 | <Lachy> | Dashiva, I think he's made the assumption that because there wasn't much discussion about the name change from sidebar to aside, that it must have occured on IRC |
| 22:00 | <Hixie> | wait, isn't JF one of the members of the html4all self-styled cabal? |
| 22:00 | <Lachy> | yes |
| 22:00 | <Hixie> | and he's complaining about us talking in public on irc? |
| 22:00 | <Lachy> | yes |
| 22:00 | <Hixie> | i'm gonna need a new irony meter |
| 22:01 | <Hixie> | my current one is just a consumer model |
| 22:01 | <Hixie> | i need the advanced "prosumer" version |
| 22:01 | <Hixie> | with the extended gague |
| 22:01 | <Hixie> | god i hate that word |
| 22:01 | <Hixie> | Cannot Spell Gague |
| 22:01 | <Hixie> | GAUGE |
| 22:01 | <Hixie> | GAH |
| 22:02 | <Lachy> | they're aware of the irony of the situation. I think they justify the secrecy so that they can discuss issues without worrying about anything they write being ridiculed in any way |
| 22:02 | <Hixie> | well it's a good thing we don't mind being ridiculed :-) |
| 22:02 | <Lachy> | I think that's why they stopped using their public html4all list and migrated to the private list |
| 22:03 | <Dashiva> | Let's make it <rouge> instead |
| 22:03 | <TabAtkins> | It sounds trite, but if you're afraid of being ridiculed, you're probably being ridiculous. |
| 22:03 | TabAtkins | has bad memories of all the rouges sneak-attacking people. |
| 22:04 | <TabAtkins> | It just embarassing when you get knifed by a *color*. |
| 22:04 | <Dashiva> | The upside is that nobody will get it wrong |
| 22:05 | <TabAtkins> | What, 'cause they'll all assume it was meant to be <rogue>, then mistype it as <rouge> anyway? |
| 22:05 | <Hixie> | hah |
| 22:05 | <Dashiva> | TabAtkins: That's half the users. The other half just know how to spell. |
| 22:06 | <TabAtkins> | Ah, clever. Get it from both sides. |
| 22:06 | <Hixie> | I'm writing an e-mail about <meter> |
| 22:06 | <Dashiva> | It's too bad the name has nothing to do with gauges |
| 22:06 | <Hixie> | and i've mistyped the word "gauge" about 50 times so far |
| 22:07 | <Lachy> | Hixie, Irony Level: <meter class="irony" min=0 max=1000 low=0 high=100 optimum=50>999%</meter> |
| 22:07 | <Hixie> | it's only in the e-mail about 5 |
| 22:07 | <Dashiva> | I don't get why anyone would typo gauge, though |
| 22:07 | <Dashiva> | Both pronounciations make it clear there's no u after the g |
| 22:07 | <TabAtkins> | I try to say guage all the time. Hixie keeps trying to type gague. |
| 22:07 | <Lachy> | Dashiva, how can gauge be pronounced in two ways? |
| 22:07 | <TabAtkins> | gahj, or gaej |
| 22:08 | <Hixie> | Dashiva: language="" was one of the most-typoed attribute names i found when doing the survey a few years ago |
| 22:08 | <TabAtkins> | langugae? |
| 22:08 | <Dashiva> | Hixie: No obvious failure |
| 22:08 | jgraham | guesses it can be pronounced in many more ways |
| 22:08 | <Dashiva> | jgraham: I had "the right way" and "the wrong way", are there more? |
| 22:08 | <Lachy> | if by gaej, you mean that it rhymes with "rage", then that's the correct pronunciation |
| 22:08 | <Hixie> | Dashiva: sure, but i'd rather avoid failures at all, even during debugging |
| 22:09 | <Dashiva> | Hixie: Better a typo failure than a conceptual failure, wouldn't you say? |
| 22:09 | <TabAtkins> | Lachy: Yeah, but I hear it rhyming with lodge sometimes too. |
| 22:09 | <Lachy> | wtf? |
| 22:09 | <Dashiva> | Isn't that gouge, TabAtkins? |
| 22:09 | <TabAtkins> | Because "au" sounding like "ae" doesn't make any sense. |
| 22:09 | <Hixie> | Dashiva: the conceptual failure would also be caught at debugging, no? |
| 22:09 | <Lachy> | what's the native language of people who pronounce it like that? It can't be english |
| 22:09 | <Philip`> | http://philip.html5.org/data/attr-count-total.txt - "96 langauge" |
| 22:09 | <TabAtkins> | Definitely English. ^_^ |
| 22:09 | <Philip`> | Doesn't seem very common there |
| 22:10 | <Hixie> | Philip`: it's a long tail thing |
| 22:10 | <Hixie> | Philip`: lots and lots and lots of misspellings of various kinds |
| 22:10 | <TabAtkins> | "au" is *supposed* to sound like "ah" or "ow". |
| 22:10 | <Hixie> | Philip`: all individually rare |
| 22:10 | <Dashiva> | Hixie: Only incorrect inclusion, not incorrect exclusion |
| 22:10 | <Dashiva> | If people skip using the element because they think it doesn't apply, it won't show up |
| 22:10 | <Lachy> | we can't worry about mispellings too much for elements that have a noticable effect if you get it wrong. |
| 22:11 | <Hixie> | languaje="" was one of the most common attributes on <script>, e.g. |
| 22:11 | <Dashiva> | And besides, <metre> will be there, I guarantee it |
| 22:11 | <TabAtkins> | Dashiva: No, 'gouge' sounds different entirely. |
| 22:11 | <AryehGregor> | <Lachy> Hixie, Irony Level: <meter class="irony" min=0 max=1000 low=0 high=100 optimum=50>999%</meter> <-- That would work out to a value of 9.99 out of 1000, wouldn't it? |
| 22:11 | <TabAtkins> | ...languaje? Seriously? |
| 22:11 | <Hixie> | Dashiva: one possible typo is better than however many <gague> has :-) |
| 22:11 | <Hixie> | <gauge>! |
| 22:11 | <Hixie> | gah! |
| 22:12 | <Hixie> | Philip`'s data also has 15 langage |
| 22:12 | <Lachy> | AryehGregor, I probably needed to include a value="999" attribute |
| 22:12 | <Hixie> | 13 languague |
| 22:12 | <Hixie> | 10 lanugage |
| 22:12 | <Dashiva> | Hixie: A typo is a typo, but a confusing name is forever |
| 22:12 | <AryehGregor> | Lachy, or do min=0 max=10 high=1 optimum=0.5 |
| 22:12 | <annevk3> | Hixie, there's no such thing as an IRI scheme |
| 22:12 | <Hixie> | Dashiva: people learn concepts, they don't get over hard-to-type names |
| 22:13 | <TabAtkins> | Dashiva: I totally don't think <meter> is confusing. |
| 22:13 | <annevk3> | Hixie, IRI is a syntax, URI is the thing |
| 22:13 | <Hixie> | annevk3: so julian told me |
| 22:13 | <Hixie> | annevk3: but he wants me to give the URI syntax |
| 22:13 | <annevk3> | Hixie, and he's right |
| 22:13 | <AryehGregor> | People spell "gauge" as "gague" because it really sounds like it should be spelled "gage", so "gag" comes out and then the "u" finds its way in later. Or something. |
| 22:13 | <Hixie> | annevk3: which seems to be incompatible with the idea of IRI having a syntax |
| 22:13 | <annevk3> | Hixie, no |
| 22:13 | <Hixie> | annevk3: so where do i say that if you use ws: IRIs, you can't give a fragment identifier? |
| 22:13 | <annevk3> | Hixie, somewhat wrong, but close enough: IRI is like HTML and URI is like the DOM |
| 22:14 | <AryehGregor> | It's definitely pronounced to rhyme with "rage", not "lodge". The latter is just wrong. |
| 22:14 | <Hixie> | annevk3: no, both URI and IRI define syntax |
| 22:14 | <Dashiva> | What about the people who pronounce it gawdje? |
| 22:14 | <Hixie> | annevk3: so if i'm to define the URI syntax subset for ws:, where do I define the IRI syntax subset? |
| 22:14 | <Dashiva> | That's not too far from lodge |
| 22:14 | <AryehGregor> | "XauXe" is pretty rare in English. I can't immediately think of another example. |
| 22:14 | <TabAtkins> | AryehGregor: "wrong" doesn't mean much. ^_^ |
| 22:14 | <AryehGregor> | Dashiva, definitely wrong. |
| 22:14 | <AryehGregor> | TabAtkins, "nonstandard" if you like. |
| 22:14 | <Dashiva> | "wrong" |
| 22:15 | <annevk3> | Hixie, all URIs are IRIs so you do not need to do that |
| 22:15 | <AryehGregor> | Disagrees with every dictionary I've checked. |
| 22:15 | <Hixie> | (i used to say gawje. now i say gayje.) |
| 22:15 | <TabAtkins> | Dashiva: I think we're hitting minimal-pair errors. In my accent the 'gawdje' and 'lodge' have the same vowel. |
| 22:15 | <AryehGregor> | Mine too, I think. |
| 22:15 | <Dashiva> | Well, most people don't check the dictionary when they see a new word |
| 22:15 | <Hixie> | annevk3: what? |
| 22:15 | <Dashiva> | They guess and go on until corrected |
| 22:15 | <annevk3> | Hixie, I guess you're right about my analogy being flawed, can't really come up with something better |
| 22:15 | <AryehGregor> | No, but the people who are confident in how to pronounce "gauge" will think "ha, this person is an ignoramus who doesn't know how to pronounce 'gauge'" if they hear you say "godge". |
| 22:15 | <Dashiva> | Now, assume you're in a place where nobody else knows how to pronounce it either |
| 22:16 | <Dashiva> | It proliferates fast |
| 22:16 | <AryehGregor> | So practically speaking, it's useful to stick to the standard educated pronunciation. |
| 22:16 | <annevk3> | Hixie, the parse URL already takes care of IRI -> URI |
| 22:16 | <Hixie> | annevk3: i want ws://example.com/©/ to be a valid ws: IRI |
| 22:16 | <Hixie> | annevk3: and i want ws://example.com/©/#test not to be |
| 22:16 | <TabAtkins> | AryehGregor: No? Generally, both sides will think the other one is wrong. It's only if one of them consults a dictionary that it matters. And I'll bet that the average English-speaker has *never* consulted a dictionary for the pronunciation of 'gauge'. |
| 22:16 | <Hixie> | annevk: if i say the syntax of ws: URIs is "hier-part query?", then how is the former valid? |
| 22:16 | <Dashiva> | AryehGregor: Besides, anything you say is moot until you guys decide on one pronounciation for tomato |
| 22:17 | <annevk3> | Hixie, after conversion it's valid |
| 22:17 | <AryehGregor> | TabAtkins, the nonstandard side will usually either a) not be as sure, or b) accept the other pronunciation as legitimate. The standard pronunciation is always at least common, even when it's not ubiquitous. |
| 22:17 | <Hixie> | annevk3: i want it to be valid before conversion. |
| 22:17 | AryehGregor | $ grep 'au..\?e$' /usr/share/dict/american-english |
| 22:18 | <Hixie> | annevk3: and i want the frag-id case to be invalid before conversion |
| 22:18 | <Hixie> | annevk3: or are you saying that IRIs can't be syntax-checked without converting them to UR |
| 22:18 | <Hixie> | Is? |
| 22:18 | <AryehGregor> | "applause", "because", "cause", "clause", "gauze", "mauve", "pause", "sauce". I think "gauge" is sui generis here, yep. |
| 22:18 | <annevk3> | Hixie, I think so, but now I'm no longer sure whether I'm right :/ |
| 22:18 | <TabAtkins> | AryehGregor, you have a bad conception of how people learn language. They stick with what they heard first, only changing with difficulty. I can assure that most of the people rhyming with "rage" did *not* develop their pronunciation by consulating a dictionary. |
| 22:19 | <Hixie> | i hate the uri/iri BS |
| 22:19 | <Hixie> | the whole space is a big giant mess |
| 22:19 | <annevk3> | Hixie, no disagreement there |
| 22:19 | <AryehGregor> | TabAtkins, no, they developed it by hearing other people speak. And a large percentage of people who use words like "gauge" in ordinary conversation will be using the standard pronunciation. |
| 22:19 | <Hixie> | they should scrap all those specs and do a proper job with built-in i18n, no ASCII nonsense, and defining error handling, etc. |
| 22:19 | <Dashiva> | Errors don't exist on the internet, silly Hixie |
| 22:20 | <AryehGregor> | Hixie, are there any application-level Internet standards other than HTML 5 that you think are done right? |
| 22:20 | <Hixie> | CSS does a reasonable job |
| 22:20 | <TabAtkins> | AryehGregor, large percentage != overwhelming percentage. The fact that I still hear it rhyming with 'lodge' plenty attests to that. |
| 22:20 | <Hixie> | Unicode is pretty good |
| 22:20 | <othermaciej> | according to timbl, even the original term "URL" came from the IETF's desire to rename his original term (UDI) |
| 22:20 | <Hixie> | XForms is pretty good |
| 22:20 | <annevk3> | of course everything around Unicode is pretty bad |
| 22:20 | <Dashiva> | I found out the other day that CSS doesn't place any restrictions on the length of a real number |
| 22:21 | <annevk3> | Dashiva, that's a feature |
| 22:21 | <Hixie> | SVG Tiny 1.2 is pretty good |
| 22:21 | <Hixie> | (XForms and SVG have their own issues, but we're just talking spec-wise here) |
| 22:21 | <Dashiva> | annevk3: A feature that leads to getting three different results from four browsers |
| 22:21 | <AryehGregor> | TabAtkins, thus everyone who's sure about pronunciation will accept "gage" as a valid pronunciation. Those who have checked in a dictionary, or heard it only from more reliably standard speakers, will not accept "godge" as a valid pronunciation. Thus you may as well use the standard one. |
| 22:21 | <AryehGregor> | FWIW, I've never heard anyone pronounce "gauge" as anything but "gage". |
| 22:22 | <Hixie> | (e.g. XForms failed hard at being relevant for the Web, and SVG is an overly-complex language and 1.2 introduces too many new features) |
| 22:22 | <Dashiva> | I've heard godge many times |
| 22:22 | <Hixie> | (but they are both written reasonably well, compared to the rest of the space) |
| 22:22 | <AryehGregor> | Anyway, it does matter what people think of your pronunciation if you're being interviewed for a job, etc. Not a completely trivial thing, in life. |
| 22:22 | <Dashiva> | If you say gauge during an interview, they might just think you're pretentious too |
| 22:23 | <AryehGregor> | In some jobs, that's a plus! |
| 22:23 | <TabAtkins> | AryehGregor: Then you're clearly in an abnormal area of the english-speaking world. ^_^ Again: dictionaries are *not* consulted in general. There is a sense of learning from people you perceive to be more 'correct', but that's half sawdust and lies anyway. |
| 22:23 | <AryehGregor> | (says the Ph.D. student) |
| 22:23 | <Hixie> | XHR is another good spec |
| 22:23 | <Dashiva> | Busted |
| 22:23 | <Hixie> | CORS, too |
| 22:23 | <AryehGregor> | TabAtkins, what's perceived to be "correct" is totally arbitrary, for sure. But it's worthwhile to go with it anyway, all things being equal. (Which sometimes they're not.) |
| 22:24 | <annevk3> | Dashiva, that's nothing, most features have six different results in four browsers |
| 22:24 | <annevk3> | cheers Hixie |
| 22:24 | <annevk3> | I kind of like HTML5 too |
| 22:24 | <Dashiva> | AryehGregor: You still haven't addressed the cases where there are multiple "correct" alternatives |
| 22:24 | <annevk3> | :p |
| 22:24 | <Hixie> | annevk3: :-P |
| 22:24 | <Lachy> | AryehGregor, the core of JF's argument was that decisions were being made on IRC. You should have defeated his argument by pointing out that no decisions were in fact made in the IRC disucssion he complained about. |
| 22:24 | <AryehGregor> | Dashiva, then use whichever you feel like. Why is that a problem? |
| 22:25 | <Dashiva> | Because some people will contest the correctness of some of them |
| 22:25 | <Hixie> | i think a big part of hte problem i that a lot of people writing specs started when the internet was basically a small community project, mostly military and academia |
| 22:25 | <Lachy> | (I almost responded, but decided not to as it wouldn't have been too constructive) |
| 22:25 | <TabAtkins> | AryehGregor: Not if you think it's wrong, which 'gauge'='rage' clearly is. ^_^ Your search through the dictionary for other uses of that vowel pair showed that it's a crazy outlier, and should be corrected in common use to increase consistency. |
| 22:25 | <Hixie> | or they learnt abotu specs from people who were already in that mindset |
| 22:25 | <AryehGregor> | Lachy, well, decisions like "that's unlikely to be added to HTML 5" occur here pretty regularly, which effectively halt changes that might otherwise have been pursued. |
| 22:25 | <AryehGregor> | I don't think it's a problem even if some decisions are made here. |
| 22:26 | <AryehGregor> | Dashiva, so life isn't perfect. Pick the least controversial or give up and don't care. |
| 22:26 | <Lachy> | which decisions like that are you referring to? |
| 22:26 | <AryehGregor> | Lachy, like that guy who came in here yesterday asking that <textarea> be rolled into <input>. |
| 22:27 | <AryehGregor> | We basically shot him down here. That's a decision of sorts, although it resulted in no change to the spec. |
| 22:27 | <Lachy> | that wasn't just decided yesterday. It was just explained to him why it wouldn't work |
| 22:27 | <AryehGregor> | TabAtkins, "correct" pronunciation signals your level of education and socioeconomic status, basically. It shows that you're the kind of person who actually does things like look stuff up in dictionaries if you're unsure. Take it or leave it. |
| 22:28 | <AryehGregor> | Lachy, sure. But it stopped the proposal from going forward. If you accept the premise that IRC is non-public, then it would have been more transparent if the reasons why his proposal wouldn't work were posted publicly on a mailing list. |
| 22:29 | <Lachy> | I don't accept the premise that IRC is non-public |
| 22:29 | <AryehGregor> | Nor do I, and that's what my post said. |
| 22:29 | <TabAtkins> | Indeed, but you're talking to a Texan who was raised with a healthy does of 'ghetto' pronunciation as well. My casual speech is already halfway-retarded to the sort of person who consults the dictionary for pronunciation. |
| 22:29 | <Lachy> | he didn't raise his issue on the mailing list, why should we bother everyone else with a response to an issue that wasn't even raised there and was easily explained to the guy that raised it where he raised it |
| 22:29 | <AryehGregor> | I think some decisions *are* made here. Not as important as the ones made on the mailing list, but some. Which is why I didn't make the point as you suggested. |
| 22:30 | <AryehGregor> | TabAtkins, while you're talking to a New York Jew who's a Ph.D. student, who was brought up in a house where dictionaries/encyclopedias/atlases/globes/etc. were and are routinely consulted during family meals to resolve arguments. Different perspectives, I guess. :) |
| 22:30 | <Lachy> | AryehGregor, the specific discussion he linked to, relating to the section/article/content element discussion, absolutely made no decisions |
| 22:31 | <AryehGregor> | Lachy, but others did, IMO. Or if not decisions, then at least things that should be public if we want a transparent spec development process. But they are public, since they're on IRC, so that's okay. |
| 22:31 | <Lachy> | anyway, doesn't matter. Best to just ignore the complaint anyway |
| 22:34 | virtuelv | responds to the fakepath thread |
| 22:42 | <cardona507> | the spec says "MOST elements that are categorized as phrasing content can only contain elements that are themselves categorized as phrasing content, not any flow content." - What phrasing content elements can contain flow content? |
| 22:44 | <TabAtkins> | Is <a> a phrasing content element? |
| 22:44 | <TabAtkins> | If so, that one. |
| 23:29 | <annevk3> | Hixie, I just read some more of that thread and if Addison Phillips is right, and that seems more likely than me being right, I was wrong above about there not being such a thing as an IRI scheme |
| 23:31 | <Lachy> | TabAtkins, I'm really struggling to understand your arguments. They just don't seem rational and it's not at all clear what you're arguing for |
| 23:32 | <Lachy> | (re the header/footer/sidebar discussion) |
| 23:32 | <TabAtkins> | Lachy: one sec, in a call at work |
| 23:32 | <Hixie> | annevk3: well fwiw, i'm struggling to understand any of that thread |
| 23:33 | <Hixie> | annevk3: i just wish people (especially julian) would stop whining about what the rules are and just say wtf they would like the spec to say to satisfy them |
| 23:33 | <annevk3> | Hixie, yeah, he's not always very constructive :/ |
| 23:36 | <TabAtkins> | Lachy: My point is that trying to draw semantic distinctions between header/footer/aside (used as website structure) doesn't do any good. If you can put some item in one of those locations, it's almost guaranteed to be attested in the other two across the web as well. |
| 23:37 | <TabAtkins> | So, semantically, header/footer/aside as *website structure* are very nearly the same (header being a slight exception, as it nearly always contains the site header). |
| 23:37 | <TabAtkins> | header/footer/aside used in an article carry very real and distinctly different meanings, of course. These are currently expressed in the spec. |
| 23:37 | <Lachy> | and as I tried to point out on the list, you're placing too much significance on the content alone, and ignoring the structural and contextual meanings conveyed by each |
| 23:38 | <TabAtkins> | What's the structural and contextual meaning of a blogroll being placed in the header as opposed to the footer or aside? |
| 23:38 | <Lachy> | when is a blog roll ever placed in a header? |
| 23:39 | <Lachy> | it's not introductory content, it doesn't belong there |
| 23:39 | <TabAtkins> | It's often not, because of (purely visual) size considerations. If you would like, just consider it in a sidebar or footer. What's th difference? |
| 23:39 | <Lachy> | it's not just visual consideration. It's structural and semantic |
| 23:39 | <TabAtkins> | Okay, look at, frex, http://www.igofigure.com. |
| 23:39 | <TabAtkins> | The heading area contains 6 distinct things. |
| 23:40 | <TabAtkins> | One of those is definitely appropriate for <header> (the site heading). One is possibly best in header (the main nav). The other four could be put anywhere equally well. |
| 23:40 | <TabAtkins> | Those four are placed in the heading area for purely visual reasons. |
| 23:41 | <cardona507> | is this worded correctly? "The value must be a short free-form string that giving the name of the Web application that the page represents. " |
| 23:42 | <TabAtkins> | cardona507: remove the "that" from "string that giving". |
| 23:42 | <cardona507> | its from the spec |
| 23:42 | <TabAtkins> | Then it's a spec bug. ^_^ |
| 23:43 | <Hixie> | file it using the bug filing widget please :-) |
| 23:44 | <cardona507> | its also in the W3C spec |
| 23:45 | <Hixie> | it's the same document |
| 23:46 | <cardona507> | for some reason I felt like the whatwg was "fresher" :) |
| 23:46 | <Hixie> | it is :-) |
| 23:46 | <Hixie> | i edit the whatwg one live |
| 23:46 | <Hixie> | then when i'm done with an editor, i run a script that commits it to svn and uploads it to the w3c with the w3c header on it |
| 23:47 | <Hixie> | er, done with an edit, rather |
| 23:47 | <Lachy> | TabAtkins, I'm not disagreeing that their is partial overlap in the kinds of content that could potentially be included in each. But by placing, e.g., the language/country selector in the header, the designers intended for it to be part of the introductory content so it is among the first things encountered in the site. |
| 23:47 | <Hixie> | (and then every few months the w3c make a snapshot of the document to copy to the /tr/ page) |
| 23:47 | <TabAtkins> | I'm the designer, btw. ^_^ |
| 23:47 | <Lachy> | While it could technically be placed in the sidebar or footer, placing it structurally near the beginning has a clear purpose |
| 23:47 | <Hixie> | (though i can't for the life of me work out why!) |
| 23:48 | <TabAtkins> | And it's placed in the heading area because the sidebar is already full enough, and putting more stuff in it would push down things that I want to be visible on pageload. |
| 23:49 | <TabAtkins> | There was no intention that it was introductory content. That blue bar up top is treated, for all intents and purposes, as an <aside> to me. |
| 23:50 | <TabAtkins> | And, given appropriate support from CSS, that totally *would* be an <aside>, placed somewhere else in the document. |
| 23:50 | <Lachy> | TabAtkins, why do you think it's most common for sites that include country/language selectors near the top of the page, rather than sticking them in sidebars or footers? |
| 23:50 | <TabAtkins> | Because you want to ensure it's seen on pageload, without taking up valuable sidebar inches. |
| 23:50 | <Lachy> | clearly, there has to be more than a purely asthetics reason for it |
| 23:50 | <TabAtkins> | It's a practical concern. |
| 23:51 | <cardona507> | hixie - is the bug filing widget the little arrow at the bottom right of the screen? |
| 23:51 | <cardona507> | on the spec that is |
| 23:51 | <Lachy> | right, a practical concern greatly affected by the chosen structure |
| 23:51 | <Hixie> | cardona507: yes |
| 23:52 | <TabAtkins> | It is, however, entirely tangential to the page itself, and certainly isn't introductory content. |
| 23:52 | <cardona507> | limited characters in the bug report widget? |
| 23:52 | <TabAtkins> | Lachy: It's only affected by the chosen structure because page layout is so impoverished on the web. |
| 23:53 | <Hixie> | cardona507: i don't think so |
| 23:54 | <TabAtkins> | Hixie: iirc, there's a limit. I was lucky that my last bug was *exactly* long enough to fit. One or two characters more would have done it in. |
| 23:55 | <Hixie> | huh |
| 23:55 | Hixie | checks |
| 23:55 | <cardona507> | 255 characters |
| 23:55 | <Lachy> | TabAtkins, personally, I probabaly wouldn't include that witin the header element itself anyway, but it would certainly near the top, either before or immeidately after the <header> |
| 23:55 | <Hixie> | huh, i wonder why i have a maxlength |
| 23:56 | <Hixie> | i've removed the maxlength |
| 23:56 | <Lachy> | I likely wouldn't include the <nav> within the <header>, but that doesn't matter so much |
| 23:56 | <TabAtkins> | Indeed, somewhere near the top. You want it exposed early on, even if it's not part of the page header. Hell, you may even want it as an <aside> appearing right in the beginning of the page stream. |
| 23:56 | <TabAtkins> | Lachy: Yeah, again, that's due to layout concerns. |
| 23:57 | <TabAtkins> | Given something appropriately powerful like Template Layout, the structure would be a goodly bit different. |
| 23:57 | TabAtkins | notes that that's the major reason he joined the CSSWG - so he can ensure that things like layout are driven properly. |
| 23:58 | <Lachy> | no, it's because I'd want it near the beginning, irrelevant of the design. It could just as easily be positioned at the bottom of the page with CSS |
| 23:58 | <TabAtkins> | Yo, Maciej. |
| 23:58 | <othermaciej> | hello! |
| 23:59 | <cardona507> | *bug filed |
| 23:59 | <TabAtkins> | Lachy: Ideally, I'd probably do something like <aside #lang-selector /><header /><nav #main-nav /><article /><lots of navs and asides> |
| 23:59 | <Lachy> | TabAtkins, for the same reason a lot of developers include the navigation structually after the main content, but style it to be at the top |
| 23:59 | <Lachy> | sure, that would be a reasonable approach |