| 00:00 | AryehGregor | started to comment in that discussion, but thought better of it. |
| 00:00 | <annevk> | yeah, I failed |
| 00:01 | <annevk> | it's probably the short vacation |
| 00:01 | <annevk> | makes me naive |
| 00:10 | <hober> | I sometimes find myself contributing to such threads, thinking "this way, people with more important things to do won't have to." |
| 00:10 | <hober> | Afterwards, I wonder, "why did I feed the trolls again?" |
| 00:12 | <annevk> | yeah... |
| 00:12 | <annevk> | time for my awesome book |
| 00:12 | <annevk> | and then some sleep |
| 00:12 | <annevk> | nn |
| 00:16 | <TabAtkins_> | Philip`: 24fps is only visually acceptable because we're so used to it. It's visually distinguishable from the 60fps that camcorders get. |
| 00:16 | <TabAtkins_> | (That's why "motion blur" is a visual option for Mass Effect - to make it blurrier so it looks more like a movie rather than a game.) |
| 02:05 | <skm> | need a bit of help on shared workers & workers |
| 02:05 | <skm> | i thought what i wanted to use was nested workers but this isnt implemented anywhere and im thinnking sharedworkers might do what i need |
| 02:06 | <skm> | i want one worker that selects from websql (200,000) rows, then multiple (aybe 5) other workers handling the processing |
| 02:06 | <skm> | is this something sharedworkers can do/are intended for |
| 02:06 | <skm> | or mainly for sharing tasks between pages/tabs |
| 02:46 | <boblet> | just tried <dt>…<dd>…</dd></dt> but it’s unhelpfully corrected by browsers. I can select a sibling dd with .class + dd-style selectors, but not once there’s more than one dd. basically forced to apply classes to every dt & dd in a description list ;( |
| 02:47 | <boblet> | lack of name-value association wrapper element also means any script that wants to manipulate more than single associations needs to implement the association algorithm |
| 03:13 | <boblet> | mikesmith Hixie ping me if you have a moment. would like to discuss if it’s possible to add an exception for <div> to “If a dl element contains non-whitespace text nodes, or elements other than dt and dd, then those elements or text nodes do not form part of any groups in that dl.” |
| 03:22 | <Hixie> | boblet: not sure what you mean |
| 03:24 | <boblet> | Hixie: have had a couple of ppl mention <dl> is hard to use with CSS or JS because name-value associations don’t have a wrapper element. |
| 03:24 | <Hixie> | yeah, that's a bug in css |
| 03:24 | <Hixie> | we should fix it in css |
| 03:25 | <Hixie> | we could provide an array of DocumentFragment or something to make it easier in JS |
| 03:25 | <Hixie> | not clear what the use case is in JS |
| 03:25 | <boblet> | Hixie: aah. what about for JS? just implement the dl parsing algorithm in scripts? |
| 03:25 | <Hixie> | parsing? |
| 03:25 | <Hixie> | finding groups in JS is trivial |
| 03:25 | <Hixie> | you just collect nodes until you hit a dd then collect nodes until you hit a dt |
| 03:26 | <Hixie> | and that's one group |
| 03:26 | <boblet> | well, the logic of dl (how multiple <dt> and <dd> are associated) |
| 03:26 | <Hixie> | then you repeat |
| 03:26 | <Hixie> | but depending on what the use cases are for manipulating <dl>s in script, we might be able to provide much better APIs for it |
| 03:26 | <boblet> | ok. need to follow up with that person coz not sure I understood fully (Japanese tweet, so brevity+language working against me :) |
| 03:27 | <boblet> | will find out use case and report back |
| 03:27 | <Hixie> | k |
| 03:28 | <boblet> | CSS selector won’t be any time soon tho huh, with Selectors Level 3 already proposed recommendation |
| 03:28 | <Hixie> | no idea, i'm not up on what the csswg is doing |
| 03:28 | <boblet> | k, will email www-style. thanks |
| 03:31 | <boblet> | Hixie: oh re: what I meant, wrapping name-vale associations in <div> lets me style enclosed <dt> and <dd>, but I understand that quote to mean that anything inside <div> would then not be part of the <dl> — correct? |
| 03:32 | <boblet> | so I was wondering if “or elements other than dt and dd” could become “or elements other than dt, dd and div” until CSS selectors catches up |
| 03:33 | <Hixie> | http://wiki.whatwg.org/wiki/FAQ#HTML5_should_group_.3Cdt.3Es_and_.3Cdd.3Es_together_in_.3Cdi.3Es.21 |
| 03:33 | <Hixie> | it comes up quite often :-) |
| 03:33 | <Hixie> | it's clearly not _that_ much of a problem since nobody has done anything in the csswg about it |
| 03:34 | <boblet> | hah :) so I’m guessing that using <div> in the meantime is not recommended right? |
| 03:35 | <boblet> | (note to self, check FAQ before asking q) |
| 03:37 | <Hixie> | well it's non-conforming |
| 03:37 | <Hixie> | so not so much "not recommended" as "not allowed" :-) |
| 03:38 | <boblet> | heh. puts the kibosh on that idea then |
| 03:44 | <Hixie> | i updated the faq with a bit more on that question, fyi |
| 04:04 | <Hixie> | wow, fielding really lives in his own world |
| 04:32 | <wirepair> | does anyone have any links to browser layout/security testcases? |
| 04:32 | <wirepair> | i think chromiums src tree comes with a bunch |
| 04:33 | <wirepair> | but i'd be interested to see more |
| 04:33 | <MikeSmith> | wirepair: I think it depends on what you are looking for |
| 04:33 | <MikeSmith> | but Adam Barth would be a good person to chat with |
| 04:34 | <MikeSmith> | abarth on #webkit |
| 04:34 | MikeSmith | re-reads wirepair question |
| 04:34 | <wirepair> | hehe |
| 04:34 | <MikeSmith> | what are "layout/security" testcases? |
| 04:35 | <wirepair> | well they call them LayoutTests in chromium, even though they clearly include testcases for security |
| 04:35 | <wirepair> | such as same origin policy checks |
| 04:35 | <MikeSmith> | ah, that |
| 04:35 | <wirepair> | make sure xhr doesn't follow redirects, that kind of thing |
| 04:35 | <MikeSmith> | yeah, that's just a name |
| 04:36 | <wirepair> | so adam would be good then huh? |
| 04:36 | <MikeSmith> | yep |
| 04:36 | <MikeSmith> | definitely |
| 04:36 | <wirepair> | he on irc a lot? |
| 04:36 | <MikeSmith> | he's around on #webkit usually |
| 04:37 | <MikeSmith> | I guess he's there mostly to talk with other webkit devs about build issues and such |
| 04:37 | <wirepair> | ah cool i'll try to ping him next time he pops in |
| 04:37 | <wirepair> | i just finished the infrastructure for my browser testing system and starting on building testcases |
| 04:38 | <wirepair> | figured i should see how other people are doing tests |
| 04:38 | <MikeSmith> | what kind of infrastructure? |
| 04:38 | <wirepair> | http://sh0dan.org/wbts/ |
| 04:38 | <wirepair> | fake dns server, vhosts, ssl |
| 04:38 | <wirepair> | all for testing security |
| 04:38 | <MikeSmith> | automated? |
| 04:38 | <wirepair> | thats the plan |
| 04:38 | <MikeSmith> | cross-browser? |
| 04:38 | <wirepair> | ;> |
| 04:38 | <wirepair> | thats the plan |
| 04:38 | <wirepair> | hehe |
| 04:38 | <MikeSmith> | do you know about browsertests? |
| 04:38 | <wirepair> | nope |
| 04:39 | MikeSmith | goes to find a URL |
| 04:39 | <wirepair> | browsertests.com? |
| 04:39 | <wirepair> | .org? heh |
| 04:40 | <MikeSmith> | http://code.google.com/p/browsertests/ |
| 04:40 | <MikeSmith> | it's worth taking a look at |
| 04:40 | <wirepair> | thanks, looking now |
| 04:40 | <wirepair> | ah yeah looks like www.browsertests.org is an instance of it |
| 04:41 | <MikeSmith> | http://code.google.com/p/browsertests/wiki/Installation |
| 04:41 | <MikeSmith> | it's pretty easy to install |
| 04:41 | <MikeSmith> | we also have a #testing channel on irc.w3.org where you might want to hang out |
| 04:41 | <MikeSmith> | port 6665 or port 80 on irc.w3.org |
| 04:42 | <MikeSmith> | the guy who developed browsertests is usually there |
| 04:42 | <MikeSmith> | syp |
| 04:42 | <MikeSmith> | Sylvain Pasche |
| 04:42 | <wirepair> | great will do |
| 04:50 | <wirepair> | yeah ok these look the same as the ones in the chromium source tree (http://www.browsertests.org/tests/search/?file=security) |
| 05:06 | <MikeSmith> | the prose of the MathML specs don't ever seem to actually define the content models for many elements |
| 05:06 | <MikeSmith> | e.g., http://www.w3.org/TR/MathML3/chapter3.html#presm.mi |
| 05:20 | <Dashiva> | MikeSmith: It seems RelaxNG is the conformance basis, the prose expands on that |
| 05:21 | <Dashiva> | "A valid MathML expression is an XML construct determined by the MathML RelaxNG Schema together with the additional requirements given in this specification." |
| 05:22 | <MikeSmith> | Dashiva: OK |
| 05:22 | <Dashiva> | Seems like an inconvenient arrangement for authors |
| 05:22 | <MikeSmith> | yeah |
| 05:23 | <MikeSmith> | but specs really aren't for authors anyway |
| 05:23 | <MikeSmith> | I can see from reading back to http://www.w3.org/TR/MathML3/chapter3.html#presm.tokel that there is something of a prose definition there |
| 05:24 | <MikeSmith> | but that really seems like and suboptimal way to do it |
| 05:25 | <MikeSmith> | "With the exception of the empty mspace element, token elements can contain any sequence of zero or more Unicode characters, or mglyph or malignmark elements" |
| 05:26 | <MikeSmith> | but then it never even explicitly defines what "token elements" are |
| 05:26 | <MikeSmith> | oh wait |
| 05:26 | <MikeSmith> | it does in the next paragraph |
| 05:26 | <MikeSmith> | "Token elements represent identifiers (mi), numbers (mn), operators (mo), text (mtext), strings (ms) and spacing (mspace)." |
| 05:26 | <MikeSmith> | sorta |
| 05:27 | <MikeSmith> | though no hyperlink for "token elements" or dfn markup or anything there |
| 05:28 | <Dashiva> | A bit weird that mspace is a token element when it isn't allowed to contain tokens |
| 05:29 | <MikeSmith> | yeah |
| 05:31 | <MikeSmith> | anyway, I'm just trying to figure out of having validator.nu allow HTML markup in mi and mn and mo violates MathML semantics |
| 05:32 | <MikeSmith> | I think I'll just try having it allow HTML markup within any "token element" |
| 05:33 | <MikeSmith> | if hsivonen is OK with that |
| 05:34 | <MikeSmith> | but that means also allowing it within mtext |
| 05:34 | <MikeSmith> | and within the ms element |
| 05:34 | <MikeSmith> | whatever that is |
| 05:34 | <MikeSmith> | "An mtext element is used to represent arbitrary text that should be rendered as itself." |
| 05:35 | <MikeSmith> | I guess an HTML <img> of text could be considered to "represent" text |
| 05:36 | <MikeSmith> | 「The ms element is used to represent "string literals" in expressions meant to be interpreted by computer algebra systems or other systems containing "programming languages".」 |
| 05:37 | <MikeSmith> | but 「Note that the string literals encoded by ms are made up of characters, mglyphs and malignmarks rather than "ASCII strings".」 |
| 05:37 | <MikeSmith> | so I say we are OK there, too |
| 05:39 | <MikeSmith> | anyway, restricting it to allowing HTML phrasing content seems reasonable |
| 05:39 | <MikeSmith> | that is, allowing HTML phrasing content within any MathML "token element" |
| 05:39 | <MikeSmith> | as far as validation goes |
| 05:40 | <MikeSmith> | hmm, yeah, and that seems to align with the HTML5 parsing algorithm too |
| 06:44 | <annevk> | remind me to take an afternoon nap |
| 06:44 | <annevk> | falling asleep at 2 and waking up at 7 is not fair |
| 06:46 | <annevk> | oh look |
| 06:46 | <annevk> | we're not publishing after all |
| 06:46 | <annevk> | quelle surprise |
| 07:04 | <Hixie> | i love the way some people think the w3c version of the html spec is somehow more normative |
| 07:08 | <annevk> | in the end what matters is what gets implemented and used by authors |
| 07:08 | <annevk> | that has not really changed in the past fifteen years |
| 07:09 | <Hixie> | yup |
| 07:39 | <annevk> | American political ads are great |
| 07:46 | <annevk> | "Regardless, if you're thinking that the WhatWG will pull out of the HTML5 effort, and doom it by their lack of participation, think again: the WhatWG organization is not a legal entity. It is an informal group of a handful of individuals, half of whom became disillusioned with the effort years ago and have not participated since." |
| 07:47 | <annevk> | 1) She clearly is missing something. 2) What is with the "WhatWG" spelling? |
| 07:49 | <Hixie> | the whatwg has more participants now than at any time in its history, and more than 3 times more people than the htmlwg... who are the people who left? |
| 07:49 | <Hixie> | we should send them flowers or something, asking them to come back |
| 07:52 | <Hixie> | mpt and Matthew Raymond haven't posted in a while |
| 07:52 | <Hixie> | maybe she was referring to them |
| 08:25 | <annevk> | oh hey, Firefox landed WebM |
| 08:25 | <annevk> | way to go |
| 09:13 | <MikeSmith> | hsivonen: please ping me if/when you have time ... I want to ask about a change to the (X)HTML+SVG+MathML v.nu schemas to make it valid to have HTML phrasing content in MathML "token elements" (mi, mo, mn, ms, mtext) |
| 09:14 | <MikeSmith> | I made the changes experimentally in my workspace and pushed to http://www.w3.org/html/check for testing |
| 09:25 | <zcorpan_> | hidden="" is widely implemented? |
| 09:45 | <MikeSmith> | zcorpan_: who said it is? |
| 09:49 | <zcorpan_> | http://www.w3.org/mid/4C0F4FCE.6000304⊙kc |
| 09:57 | <Hixie> | hidden="" is newer than ping="" and implemented in fewer browsers, if i'm not mistaken |
| 09:59 | <hsivonen> | I think Jirka is confusing hidden="" with type=hidden |
| 10:04 | <hsivonen> | w00t. Youtube in WebM works great in Minefield trunk |
| 10:04 | <hsivonen> | however, the context menu doesn't work right |
| 10:05 | <hsivonen> | it worked right after Google I/O |
| 10:06 | <hsivonen> | is something broken in Minefield or did YouTube deliberately break the context menu to discourage people from saving video |
| 10:07 | <zcorpan_> | i thought google had a <div> overlay to break the context menu |
| 10:07 | <zcorpan_> | s/google/youtube/ |
| 10:07 | <hsivonen> | zcorpan_: ok |
| 10:08 | <hsivonen> | what a great way to give every browser an incentive to work on optimizing overlay compositing |
| 10:09 | hsivonen | wonders who is going to be the first to write an independent implementation of VP8 |
| 10:10 | <Philip`> | Is it independent if you copy-and-paste the chunks of C that the specification is (apparently) largely made of? |
| 10:10 | <hsivonen> | Philip`: not really |
| 10:11 | <hsivonen> | Philip`: it's independent if Hixie expresses those chunks in English and then someone carefully implements the English spec in C again |
| 10:12 | <Hixie> | not gonna be me! |
| 10:20 | <MikeSmith> | hsivonen: I made an experimental change to the (X)HTML+SVG+MathML v.nu schemas to make it valid to have HTML phrasing content in MathML "token elements" (mi, mo, mn, ms, mtext) |
| 10:20 | <MikeSmith> | made the changes in my workspace and pushed to http://www.w3.org/html/check for testing |
| 10:21 | <MikeSmith> | good change? bad change? |
| 10:21 | <hsivonen> | MikeSmith: sorry, I had a bit of a situation with the tinderbox earlier |
| 10:21 | <MikeSmith> | no problem man |
| 10:21 | <hsivonen> | MikeSmith: is the change supported by any spec? |
| 10:21 | <MikeSmith> | well, the HTML spec... |
| 10:22 | <MikeSmith> | the parsing algorithm allows HTML in those elements |
| 10:22 | <hsivonen> | MikeSmith: that's parser behavior only, right? |
| 10:22 | <MikeSmith> | right |
| 10:22 | <MikeSmith> | only that |
| 10:22 | <MikeSmith> | the MathML spec says nothing about this |
| 10:22 | <MikeSmith> | not as far as I can tell at least |
| 10:22 | <hsivonen> | Hixie: when you made the parser allow HTML in MathML tokens, what was your plan about speccing? |
| 10:22 | <MikeSmith> | reading the MathML specs is like reading a foreign language |
| 10:22 | <hsivonen> | MikeSmith: does layout work as expected in Gecko? |
| 10:22 | <Hixie> | hsivonen: i provided hooks so that MathML could say what was allowed |
| 10:22 | <zcorpan_> | MikeSmith: that's why it's called 'foreign content' |
| 10:23 | <hsivonen> | zcorpan_: lol |
| 10:23 | <Hixie> | hsivonen: (and used hooks that SVG provided to make it defined for SVG) |
| 10:24 | <hsivonen> | Hixie: oh was the motivation for allowing HTML actually allowing SVG to support Jacques Distler's use cases without annotation-xml? |
| 10:24 | <hsivonen> | Hixie: oops. sorry, I read your lines in reverse order. scratch that |
| 10:24 | <Hixie> | not sure what that question meant :-) |
| 10:24 | <hsivonen> | Hixie: has anyone pinged the Math WG pointing out that they could now allow this? |
| 10:25 | <Hixie> | not to my knowledge |
| 10:25 | <Hixie> | they've been busy with mml3 and i've been busy with html5 |
| 10:25 | <Hixie> | so it hasn't been a priority for anyone to get together on this and hammer it out |
| 10:25 | <MikeSmith> | hsivonen: layout works as expected in Gecko as far as I can tell |
| 10:26 | <MikeSmith> | for this case |
| 10:26 | <zcorpan_> | using annotation-xml to embed svg or html in mathml seems like an ugly hack, maybe we shouldn't support it at all and require use of <mn> et al instead |
| 10:26 | <MikeSmith> | zcorpan_: that'd be fine by me |
| 10:26 | <MikeSmith> | though I did already raise a spec bug about it |
| 10:26 | <MikeSmith> | but I raised that just to get the question answered |
| 10:27 | <MikeSmith> | not because I think necessarily that answer should be to allow html in annotation-xml |
| 10:27 | <zcorpan_> | commented on the bug |
| 10:28 | <MikeSmith> | and true what Hixie says about MathML WG being focused on getting MathML3 out |
| 10:28 | <MikeSmith> | as far as I can tell |
| 10:28 | <MikeSmith> | anything related to MathML 2.0 is a low- or non-priority for them at this point, I think |
| 10:29 | <zcorpan_> | so does mathml 3 allow html and svg in <mn>? |
| 10:29 | <MikeSmith> | but David Carlisle did help much recently by providing a good MathML 2.0 schema |
| 10:30 | <MikeSmith> | zcorpan_: mathml 3 doesn't say anything more about it that 2 did, afaict |
| 10:30 | <MikeSmith> | not the spec prose |
| 10:30 | <MikeSmith> | nor the RelaxNG schema for 3 |
| 10:31 | <hsivonen> | MikeSmith: my take is that I like the idea, but it would be nice to be able to be able to point to a draft of some kind as justification |
| 10:32 | <hsivonen> | MikeSmith: that is, this isn't the kind of thing where validator developers just have to overrule the specs for sanity |
| 10:32 | <MikeSmith> | hsivonen: OK, I can try to get the attention of the Math group and see if I have any success |
| 10:32 | <hsivonen> | MikeSmith: I guess I'd be OK with it anyway if it's accompanied by an email to the Math WG |
| 10:32 | <hsivonen> | MikeSmith: ok |
| 10:33 | <Hixie> | it's a very easy fix for them -- they just need to say that the content model of their <mn> element is whatever it is plus phrasing content and reference the HTML spec. |
| 10:34 | <Hixie> | and so on for the elements that accept text |
| 10:35 | <MikeSmith> | yeah, I would hope so at least |
| 10:35 | <MikeSmith> | I wonder if they use W3C bugzilla |
| 10:35 | MikeSmith | goes to check |
| 10:36 | <MikeSmith> | hmm, looks like not |
| 10:36 | <MikeSmith> | anyway, I will get an e-mail message out to the group at least |
| 10:36 | <MikeSmith> | or to their comments list |
| 10:38 | <MikeSmith> | but for now I have to drop off |
| 10:38 | <MikeSmith> | back on later |
| 12:22 | jgraham | notes that the polyglot spec is a set of inferences rather than a definition |
| 12:29 | <Lachy> | TimBL suggestion that the polyglot spec be made normative is misguided. It must stay entirely non-normative because it doesn't specify anything beyond what HTML5 itself specifies, it just describes the requirements in a way targetted towards authors wanting to write polyglot documents |
| 12:31 | <jgraham> | Lachy: I just said something similar on the list |
| 12:31 | <Lachy> | also, I don't see the point of it. It just duplicates much of what will go into my HTML5 Reference and HTML5 Guide. (I'm hoping I will be allocated some time to work on that soon too) |
| 12:32 | <Philip`> | It has the advantage of not always being in the future tense |
| 12:32 | <Lachy> | I don't have a problem with it being published though, I just think the work should have gone into contributing to the HTML5 Reference, rather than being separate |
| 12:33 | <Lachy> | Philip`, yeah, that's true. It's just that I've been allocated to so much other QA tasks rather than spec work. |
| 12:34 | <MikeSmith> | it normatively specifies what an "XHTML/HTML polygot document" is |
| 12:35 | <jgraham> | MikeSmith: The only normative text needed to do that is "an XHTML/HTML polygot document is a document that conforms to all the authoring requirements of HTML and XHTML" |
| 12:36 | <Philip`> | jgraham: That's not a useful definition, since you want polyglot documents to act similarly when processed as XHTML and HTML |
| 12:37 | <Philip`> | which means you need more restrictions, based on subjective views of what is similar enough behaviour |
| 12:38 | <jgraham> | Philip`: documenting things that cannot be strictly inferred from either spec seems fine |
| 12:38 | <Lachy> | Philip`, there's no need for there to be a normative definition of what's considered to be polyglot anyway. There only needs to be guidelines. |
| 12:39 | <jgraham> | So maybe "can't be normative" is wrong |
| 12:39 | <jgraham> | er |
| 12:39 | <jgraham> | Not that I said that |
| 12:40 | <jgraham> | So it is OK to have the parts that can't be infered from other specs considered normative |
| 12:40 | <jgraham> | I wouldn't bother myself, but there we go |
| 12:40 | <Lachy> | Although there are certainly some things authors need to do for strict polyglot documents that can't necessarily be implied purely from the conformance requirements of either HTML or XHTML, there is no reason for those to be normatively specified. |
| 12:41 | <Philip`> | jgraham: Do you think most of the HTML5 spec's syntax definition should be non-normative, because it can be inferred from the parsing definition? |
| 12:41 | <jgraham> | Philip`: It can't |
| 12:41 | <Lachy> | besides, most authors aren't really interested in writing strict polyglot documents anyway. They just want to use certain talismans for what they perceive as cleaner markup. |
| 12:41 | <jgraham> | Strictly speaking |
| 12:43 | <jgraham> | (they are independent in the sense that one applies to authors and one applies to UAs. Of course there has to be some common ground to make the definitions useful, but you can't infer what the common ground is without normative author requirements) |
| 12:44 | <Philip`> | jgraham: You could derive e.g. the syntax for start tags from the relevant fragment of the parser definition (avoiding cases that are parse errors), I think, so the spec doesn't need to define the syntax again in terms of all the angle brackets and spaces |
| 12:44 | <Philip`> | (It would just need to add a few extra requirements about not including ` in unquoted attribute values etc) |
| 12:46 | <Philip`> | The list of omittable tags could be omitted, and derived from examining the parser for tags that can be omitted without errors and without changing the DOM, etc |
| 12:48 | <jgraham> | Philip`: Yeah, I suppose that could theoretically work. Making seperate normative author/UA requirements still feels rather different to expressing the same author requirements in multiple places |
| 12:48 | <jgraham> | all with the same normative status |
| 13:13 | <hsivonen> | I think a the polyglot doc should be a set of inferences and, therefore, non-normative |
| 14:03 | <Lachy> | hsivonen, what do you mean by "ignoring the CDATA section exposure domain modeling error in the DOM itself"? |
| 14:03 | <Lachy> | are you referring to the fact that CDATA sections are exposed through the DOM API? |
| 14:05 | <Lachy> | or to the fact that things like <script><![CDATA[ ... //]]></script> inherently parse differently in HTML and XHTML, but which should be ignored for polyglot checking purposes? |
| 14:21 | <hsivonen> | Lachy: I mean that CDATA nodes should be considered equivalent to being next nodes and then adjacent text nodes should be coalesced before comparison |
| 14:21 | <hsivonen> | Lachy: since the HTML parser in foreign content generated text nodes, not CDATA nodes for <![CDATA[...]]> |
| 14:24 | <Dashiva> | http://twitter.com/jirkakosek/status/15764226697 |
| 14:24 | <Dashiva> | Isn't the answer to this obviously yes? |
| 14:24 | <Dashiva> | The problem with XML isn't the use cases, it's the XML. |
| 14:28 | <micheil> | what's with the two data framing formats for websockets? |
| 14:37 | <jgraham> | micheil: Hixie claims that using a sentinal marker makes it less likely that server authors will screw up by counting characters rather than encoded bytes, and makes content of unknown length simpler |
| 14:37 | <jgraham> | + sending |
| 14:37 | <micheil> | Hixie: has the data framing for client-sent messages changed between 75 and 76? |
| 16:04 | <micheil> | Hixie: also, when is the high byte variant likely to occur? |
| 16:16 | <jgraham> | micheil: Binary websockets will happen just as soon as the web platform supports binary |
| 16:17 | <jgraham> | i.e. has a bytearray type or so |
| 16:17 | <micheil> | okay, so, for now, probably best not to wrory about them? |
| 16:17 | <jgraham> | Yeah |
| 16:17 | <jgraham> | Though hopefully there will be progress |
| 16:17 | <jgraham> | soon |
| 16:17 | <jgraham> | the WebGL people want it, the ES people want it, the File people want it and the WebSockets people want it |
| 16:18 | <jgraham> | so the demand is there |
| 16:18 | <jgraham> | They just need to agree on something (or let implementations make their decisions for them) |
| 16:19 | <micheil> | I'm just finding some parts of the spec confusing, as I don't yet know how to fully read the spec's.. like the lingo and such |
| 16:23 | <micheil> | jgraham: under high-order use case: http://www.whatwg.org/specs/web-apps/current-work/complete.html?slow-browser=1#data-framing |
| 16:23 | <micheil> | after step 4, b doesn't change. |
| 16:24 | <micheil> | oh. fuck. wait. |
| 16:24 | <micheil> | missed an important point. my bad. |
| 16:35 | <annevk> | lol |
| 16:35 | <annevk> | Shelley is now claiming there was no agreement between Opera, Mozilla, and Apple |
| 16:36 | <annevk> | guess she missed the deadlock way early on and the recent announcement on the WHATWG list |
| 16:38 | <TabAtkins> | boblet: Selectors 4 will be started at some point this year. |
| 16:39 | <boblet> | TabAtkins: oh ho! good news |
| 16:39 | <boblet> | TabAtkins: if you’d like to see what the style complaints were: http://oli.jp/temp/dl-for-meta.html |
| 16:41 | <boblet> | basically floating dt and dd right reverses order, and you have to know width to display them inline. first 2 from Niels, the rest me trying to get something that did what he wanted. can send you the email background if you’re interested |
| 16:41 | <daedb_> | TabAtkins: Is there a list of expected new selectors in Selectors 4 available somewhere? |
| 16:41 | <Philip`> | annevk: Baseless claims of legal uncertainty are great because you can say anything you want and the best case is that people believe you and the worse case is that someone points out facts and you can say "IANAL" and then make more claims |
| 16:41 | <Philip`> | s/worse/worst/ |
| 16:46 | <TabAtkins> | boblet: Yeah, I understand all the cases for <di> or ::di or ::wrap(dt,dd+dt) - I've agitated for them too. ^_^ |
| 16:46 | <TabAtkins> | And no, no list. |
| 16:47 | <neitcho> | hi, is this channel about html5? |
| 16:47 | <annevk> | ::di would prolly make the most sense even though Hixie claims it's a generic problem... |
| 16:48 | <annevk> | or maybe some simple predefined XBL templates |
| 16:48 | <Philip`> | neitcho: Yes |
| 16:48 | <annevk> | neitcho, sure is |
| 16:48 | <boblet> | TabAtkins: heh, as long as someone is agitating :) to tell the truth once CSS3 support catches up I think we’re gonna take quite a while to work out how to use everything together anyhow |
| 16:48 | <TabAtkins> | Yeah, I think the generic solution should exist too, but HTML can, itself, specify a ::di to make this particular common case very easy. |
| 16:49 | <neitcho> | Do you know any method or program to make dynamic tutorials? maby somethin that uses html5 and video tag |
| 16:49 | <annevk> | Philip`, yeah, fortunately it is easily discovered; now I don't have to read the rest of it :) |
| 16:49 | <annevk> | neitcho, JavaScript? |
| 16:49 | <boblet> | hixie was saying the generic solution would also address implied sections — would that mean outlining algorithm implicit sections? |
| 16:50 | <neitcho> | <annevk> maybe I don't know where to start, I know I dont want flash |
| 16:50 | <TabAtkins> | boblet: Yeah. |
| 16:51 | <neitcho> | want like a clickable video |
| 16:52 | <boblet> | TabAtkins: cool, thought so |
| 16:54 | <annevk> | neitcho, if you don't want to learn JavaScript you could take a look at http://jquery.com/ I suppose |
| 16:54 | <annevk> | neitcho, there's prolly tutorials for slideshow / interactive like things |
| 16:55 | <neitcho> | <annevk> I'll have a look. Thanks! |
| 16:56 | <boblet> | nn |
| 16:58 | <mikekelly> | I'm behind you Ian. |
| 17:18 | <drclue> | OK folks , I saw this question float by the other day, but I had not gotten so far as to observe it. Chrome now reaches an "open" state after my handshake response , but than immediately closes. Any idea what thats about? |
| 17:24 | <drclue> | Is this IRC channel logged somewhere that I might go look at yesterday's conversations? |
| 17:26 | <drclue> | Never mind that last , I see the link at the top of the screen |
| 17:31 | <Hixie> | drclue: you might be sending an extra byte after the handshake that chrome doesn't recognise |
| 17:32 | <drclue> | @hixie Thanks. That is the theory I'm working with now. Not sure where I might have picked it up , but none the less it seems a valifd thought |
| 17:41 | <micheil> | Hixie: do you know of any working draft76 & 75 servers for websockets other then the Go one? |
| 17:45 | <Dashiva> | http://www.flickr.com/photos/pixer/4681732186/sizes/o/ |
| 17:45 | <Dashiva> | Geolocation might be an even stronger contender to HTML5-but-not-really than CSS3 :) |
| 17:54 | <jgraham> | It isn't in the colour palette things at the bottom though |
| 17:54 | <jgraham> | So the author is confused |
| 17:56 | <jgraham> | I love how the bar charts correspond not-at-all to the colour swatches |
| 17:57 | <miketaylr> | that's a feature |
| 17:58 | <jgraham> | miketaylr: ? |
| 17:59 | <miketaylr> | (sry, just being facetious) |
| 17:59 | <jgraham> | Ah |
| 18:00 | <jgraham> | Maybe it is designed to highlight the intellectual vacuousness of statements like "Opera is 72% HTML5 ready" |
| 18:01 | <Dashiva> | I didn't know all current browsers had messaging |
| 18:03 | <miketaylr> | yeah i didn't realize ie8 had postMessage either |
| 18:04 | <AryehGregor> | Heh, so true: http://en.wikipedia.org/w/index.php?title=Portable_Network_Graphics&diff=prev&oldid=366885637 |
| 18:04 | <Dashiva> | Is there a "Best of Wikipedia Diffs" community, I wonder |
| 18:06 | <AryehGregor> | http://en.wikipedia.org/wiki/WP:BJAODN |
| 18:20 | <Hixie> | micheil: there's the one i wrote in perl: http://damowmow.com/playground/demos/websocket/ |
| 18:20 | <Hixie> | micheil: is the new handshake causing you issues? |
| 18:21 | <micheil> | some, but I'm trying to work out how to correctly handle the messages right now |
| 18:24 | <Hixie> | ah |
| 18:24 | <Hixie> | that hasn't changed |
| 18:24 | <Hixie> | but the demos above should give you an idea if the spec isn't clear enough |
| 18:27 | <TabAtkins> | Hm, this is the first time I've ever actually seen <nobr> in the wild. |
| 18:27 | <TabAtkins> | But this site is a morass of bad design. |
| 18:27 | <volkmar> | There is a reason why input.min and input.max are DOMString and not float ? |
| 18:28 | <Hixie> | volkmar: they take dates when type=date |
| 18:28 | <volkmar> | Hixie: ok, thanks |
| 18:29 | <micheil> | Hixie: my main problem is that the data I get in isn't just a socket I read() off, but rather an unmutable buffer. |
| 18:32 | <Hixie> | ah |
| 18:35 | jgraham | thinks caniuse.com would be more useful if you could select n browsers that you care about and get a list of features supported by all n |
| 18:35 | <TabAtkins> | Go yell @Fyrd. |
| 18:36 | <gsnedders> | Loudly. |
| 18:36 | <micheil> | Hixie: I think the way my parser has to work is by using two nested while() loops. |
| 18:37 | <jgraham> | TabAtkins: On twitter? I don't really do twitter |
| 18:37 | <TabAtkins> | Well, do twitter. |
| 18:37 | <jgraham> | No |
| 18:38 | <gsnedders> | jgraham: You're just a grumpy old man. |
| 18:38 | <TabAtkins> | I sent him the suggestion for you. |
| 18:39 | <jgraham> | gsnedders: No, I just don't want to end up sounding like you |
| 18:39 | <jgraham> | It's bad enough that people confuse us in real life |
| 18:39 | <jgraham> | If it started happening on the internet... |
| 18:39 | <gsnedders> | I sound old? Cool. I mean, all teenagers want to be older. ;P |
| 18:40 | <gsnedders> | jgraham: It's already happened, I think. Though by people who confuse us in real life. |
| 18:40 | <jgraham> | gsnedders: No, I would sound like a teenager :p |
| 18:41 | <jgraham> | TabAtkins: Thanks |
| 18:41 | <gsnedders> | jgraham: You do anyway. |
| 18:43 | <jgraham> | gsnedders: Well no need to do so in a more multimedia way then |
| 18:43 | <drclue> | @hixie - Maybe I'm staring at things too hard and missing something obvious in constructing my handshake response. I've been looking for a stray byte to explain the "open" followed by "disconnect" problem , but I just don't see it. Heres a link to my handshake class (PHP) if anyone feels like taking a peek and pointing out my folly. http://www.drclue.net/class.webSocketHandshake.inc |
| 18:43 | Hixie | looks (though i don't know php, so...) |
| 18:43 | <Hixie> | i get an error message |
| 18:44 | jgraham | to |
| 18:44 | <jgraham> | o |
| 18:46 | <erlehmann> | is there some RDFa -> microdata converter one of you can recommend ? my gsoc project went faster than expected, and why not add microdata. |
| 18:47 | <jgraham> | erlehmann: Not that I know of |
| 18:47 | <jgraham> | (what was the project?) |
| 18:49 | <erlehmann> | i am generating RDFa-enriched license markup. demo here: http://gsoc2010.dieweltistgarnichtso.net/?p=1 |
| 18:49 | <erlehmann> | note the awesome CSS i wrote :D |
| 18:50 | <erlehmann> | you can extract the RDF using http://www.w3.org/2007/08/pyRdfa/#distill_by_uri |
| 18:52 | <Hixie> | rdfa to microdata is not a trivial conversion |
| 18:52 | <Hixie> | it's probably only usefully possible on a vocabulary-by-vocabulary basis |
| 18:53 | <erlehmann> | Hixie, i will then have to write it by hand, my use case is limited anyway. |
| 18:55 | <gsnedders> | Gah. Why did I start looking at lenses again? So bloody expensive. |
| 18:55 | <erlehmann> | Is there a way to have both RDFa and Microdata in the same markup ? (I may have asked this question months ago, but forgot the answer.) |
| 18:56 | <gsnedders> | As tempted as I am by the Canon EF 70-200 f/2.8 Mark 2, it's a bit expensive |
| 18:59 | <micheil> | Hixie: how does your perl server handle when someone does something like: for(var i=0; i<10000; i++){ conn.send("t"+i); } |
| 18:59 | <micheil> | conn being a client instance of WebSocket |
| 19:00 | <Hixie> | erlehmann: yeah, they don't overlap at all so you can easily include both |
| 19:00 | <Hixie> | micheil: why would that be a problem? |
| 19:01 | <micheil> | well.. currently I notice that it gets sent in multiple blocks |
| 19:02 | <micheil> | so, I get something on my server like: 0xFFtest0x000xFFtest0x00 |
| 19:02 | <micheil> | although, it seems to arbitrarily get split |
| 19:03 | <Hixie> | you should get [0x00]test0[0xFF][0x00]test1[0xFF][0x00]test2[0xFF][0x00]test3[0xFF][0x00]test4[0xFF]... |
| 19:04 | <micheil> | rather, yeah |
| 19:04 | <micheil> | but something keeps killing my parser.. |
| 19:04 | <micheil> | I guessing while(true) loops are not the way to go. |
| 19:05 | <Hixie> | seems to work fine: open http://software.hixie.ch/utilities/js/websocket/ then put in ws://damowmow.com:11111/demo and press the "Spam 100 packets" button |
| 19:05 | <Hixie> | (if you're using chrome, ignored the "undefined", which is due to a bug in chrome) |
| 19:05 | <jgraham> | gsnedders: IS? |
| 19:06 | <gsnedders> | jgraham: yeah |
| 19:06 | <jgraham> | That's insanely expensive |
| 19:06 | <gsnedders> | jgraham: OTW, I'm thinking of the 70-200 f/4L IS |
| 19:06 | Hixie | wonders what julian would consider adding something not "silently" |
| 19:06 | <gsnedders> | jgraham: But I really want a telephoto that quick |
| 19:06 | <jgraham> | Like way more than is worth paying unlerss you atre a pro |
| 19:07 | <jgraham> | gsnedders: for what? |
| 19:07 | <jgraham> | I think yagni applies |
| 19:07 | gsnedders | reminds jgraham that photography is effective at wasting money |
| 19:07 | <jgraham> | I know :) |
| 19:08 | <jgraham> | but pragmatism gets you more nice stuff for the same amount of money |
| 19:09 | <gsnedders> | I'm not entirely sure the f/4 has a field of depth small enough |
| 19:09 | <micheil> | okay.. got the parser working.. not to figure out wtf to do with broken packets. |
| 19:10 | <jgraham> | gsnedders: If you typo depth of field as field of depth yagni^2 applies |
| 19:10 | <micheil> | Hixie: this is what I mean about broken packets: http://gist.github.com/431901 |
| 19:10 | <jgraham> | gsnedders: More to the point: for what? |
| 19:10 | <gsnedders> | But well, theoretical concern. I'm not buying the f/2.8 |
| 19:10 | <micheil> | Hixie: that was generated from google chrome, 5.0.375.70, mac os x 6.02 |
| 19:10 | <gsnedders> | jgraham: Hah. I really haven't been speaking English properly all week. |
| 19:11 | <micheil> | erm, 10.6.3, not 6.02 |
| 19:11 | <drclue> | Since there might be somebody here now that has had this issue before , has anyone run into a situation where chrome accepts the handshake , goes to "open" and then immediately closes? |
| 19:11 | <gsnedders> | jgraham: (Like, how much of the time when you last saw me did I make sense?) |
| 19:14 | gsnedders | digs around and finds the f/4 lens is nowhere near as deep as he was expecting |
| 19:18 | <tom547> | Hi all. I am reading about HTML5/XHTML5 and it mentions that either html or xhtml should be used where appropriate, but can someone kindly explain to me how one decides which is more appropriate to learn and use. I am not comprehending the faq. |
| 19:21 | <AryehGregor> | tom547, use text/html for normal web pages. XHTML5 is not very interesting to typical web authors. |
| 19:25 | <tom547> | out of curiosity what does xhtml5 turn pages into? |
| 19:26 | <AryehGregor> | Giant man-eating cougars. |
| 19:26 | <AryehGregor> | . . . No, really, what does that question mean? They're XHTML5 pages. |
| 19:27 | <tom547> | lol. I am trying to figure out what the difference is, I keep on reading abuot it yet don't understand what the heck the fuss is about. |
| 19:27 | <AryehGregor> | XHTML is XML. text/html is its own idiosyncratic format. |
| 19:27 | <Dashiva> | Just pretend XHTML5 doesn't exist |
| 19:27 | <AryehGregor> | Reasons to use text/html: IE doesn't support XHTML before IE9, and XHTML fails fatally on syntax errors. |
| 19:27 | <erlehmann> | tom547, xml has very few and clear rules. it is also easy to get wrong. |
| 19:27 | <AryehGregor> | Reasons to use XHTML: ??? |
| 19:28 | <AryehGregor> | There are a couple of reasons to use XHTML instead of text/html, but they're mostly theoretical and massively outweighed by the disadvantages for normal authors. |
| 19:28 | <Dashiva> | XHTML and lojban, freinds for life |
| 19:28 | <erlehmann> | tom547, in contrast, html has an arcane, convoluted and not intuitive synthax, but recovers from pretty much all errors. |
| 19:28 | <AryehGregor> | Also works in all browsers. |
| 19:28 | <AryehGregor> | (interoperably if you stick to valid markup, mostly) |
| 19:28 | <Dashiva> | That's not exactly true, erlehmann |
| 19:29 | <Dashiva> | The arcane syntax is SGML, not HTML. |
| 19:29 | <erlehmann> | Dashiva, not ? |
| 19:29 | <tom547> | ok so it's just a different format of coding? |
| 19:30 | <erlehmann> | tom547, i'd suggest you write according xml rules (close every element, the final slash should not be a problem for html5 parsers) and send that as text/html |
| 19:30 | <erlehmann> | why ? because it is easy to remember. |
| 19:31 | <jgraham> | gsnedders: Let's try science http://www.cambridgeincolour.com/tutorials/depth-of-field.htm |
| 19:31 | <jgraham> | gsnedders: the calculator in particular |
| 19:31 | <AryehGregor> | Hixie, do you expect anything positive to come of starting a flame war with the HTMLWG chairs? |
| 19:34 | <AryehGregor> | I mean, truth and justice are nice and all, but I don't see them as being good for the web in this case. |
| 19:35 | <Dashiva> | If nobody speaks up, nothing will change |
| 19:35 | <micheil> | Hixie: if binary messages over websockets always send their lengths, then why not do the same for utf8 messages? |
| 19:35 | <AryehGregor> | And if someone speaks up, something will change, maybe. Will that change be for the better? |
| 19:36 | <AryehGregor> | I don't see any likely outcome except the WHATWG being polite to the W3C, or the two of them splitting apart completely and no longer collaborating on HTML5. |
| 19:37 | <AryehGregor> | The latter would mean that implementers would have to choose which spec to follow, and I doubt that they'd all choose the same one. |
| 19:37 | <AryehGregor> | Well, or the WHATWG could be impolite to the W3C, the W3C could ignore the WHATWG and remove all references to it from its drafts, and the status quo otherwise remain unchanged. That doesn't sound like a big improvement either. |
| 19:39 | <Dashiva> | That seems like the old-fashioned view of specs dictating reality |
| 19:39 | <AryehGregor> | Which part? |
| 19:39 | <Dashiva> | "implementers would have to choose which spec to follow" |
| 19:40 | <Dashiva> | The spec is a tool for interoperability, it is not a goal in itself |
| 19:40 | <gsnedders> | jgraham: Oh, wait. Now I feel really dumb. My confusion was failing to account for the fact that although the depth of field is larger, the background is likely further away, so the fact the depth of field is bigger is irrelevant |
| 19:40 | gsnedders | fails at physics |
| 19:40 | <gsnedders> | Well, not really at physics. My physics was fine. Just applying the physics. |
| 19:40 | <AryehGregor> | It doesn't serve that goal if there's a conflicting spec, and some vendors follow one and some the other. |
| 19:41 | <Dashiva> | But that's an improbable outcome |
| 19:41 | <Dashiva> | The actors involved don't have the right motivations |
| 19:42 | <AryehGregor> | What's a probable outcome that's better than the status quo? |
| 19:42 | <Dashiva> | HTML5 exists in the first place because the vendors themselves wanted interoperability |
| 19:42 | <AryehGregor> | You mean, the vendors other than Microsoft, which never joined until the HTMLWG formed. |
| 19:42 | <AryehGregor> | And has basically never acknowledged the existence of the WHATWG as far as I know. |
| 19:43 | <Dashiva> | Yeah, and they aren't using acid3 in their progress reports or anything |
| 19:43 | <Dashiva> | It's not about specs and organizations, it's about actual results in the field |
| 19:44 | <drclue> | Finally got my handshake working again. It appears that last little twist of close on open was simply me being tired and including the wrong server harness code from my code piles. So anyone who needs a handshake class for PHP , please feel free to steal a copy. http://www.drclue.net/class.webSocketHandshake.inc |
| 19:44 | <AryehGregor> | Getting actual results in the field requires getting all the major implementers to agree on a spec to follow. |
| 19:45 | <Dashiva> | No, it requires them to implement the same behavior. The spec is a tool to make that easy (or at least easier). |
| 19:45 | <jgraham> | I'm not sure implementors are the biggest problem here |
| 19:45 | <jgraham> | They can work things out amongst themselves, and WHATWG promises to follow implementations |
| 19:45 | <jgraham> | (assuming two competing specs) |
| 19:46 | <AryehGregor> | Dashiva, Microsoft doesn't seem to treat it that way. I've seen multiple cases where they implement clearly wrong behavior by following specs to the letter. |
| 19:46 | <AryehGregor> | I would predict that there's a good chance they'd follow the HTMLWG spec no matter what. If the HTMLWG version is no longer edited by Hixie and is no longer clear or sane, this is bad for the web. |
| 19:47 | <jgraham> | But authors are a problem because two competing language definitions causes confusion |
| 19:48 | <AryehGregor> | That's true too, although not a huge deal, since most authors don't care about specs anyway. |
| 19:48 | <Dashiva> | Authors are going to use a (possibly non-conforming) subset anyway |
| 19:49 | <drclue> | What would be nice is if we are going to be developing code against an evolving spec that chrome and other releases don't just cut off the old implementation but leave one old and one new so that work does not have to come to a screaming halt while folks adjust bottleneck code like WebSockets. |
| 19:50 | <Dashiva> | We most certainly do _not_ want to entrench outdated support |
| 19:51 | <drclue> | No , not entrench outdated support , but rather allow that some folks might be working on other things , while someone is updating to the newest spec. |
| 19:52 | <AryehGregor> | The code is considered experimental at this point, so people aren't supposed to be using it for production stuff unless they're willing to keep up. |
| 19:52 | <AryehGregor> | Maybe the Chrome developers could make this clearer. |
| 19:52 | <Dashiva> | Remember how much fun autoplay and autobuffer was |
| 19:53 | <jgraham> | Authors may not care about specs but they care about perceptions of specs |
| 19:53 | <jgraham> | If there are two competing versions of the "same" spec, the added complexity may cause them to avoid both |
| 19:55 | <drclue> | A willingness to keep up is not the point. We all know that sooner or later the spec will settle and there will be a stable version of WebSockets , and so we are developing applications that will use it. It would simply be nice to have the last version available so that other folks can keep going on their bits , while those in the "keeping up" department do their thing. |
| 19:55 | <AryehGregor> | drclue, #chromium might be a better place to complain. |
| 19:56 | <drclue> | I'll pop over there and suggest it. |
| 19:57 | <Dashiva> | If you desire a frozen support set, you could always just freeze the browser version |
| 19:57 | <AryehGregor> | By the way, my original remark to Hixie was about his response to Sam's request to halt heartbeat publication of HTML5. I didn't see the later thread at that point, which looks like it might actually be productive. |
| 19:58 | <AryehGregor> | Explicitly saying in the WHATWG draft that sections are missing from the W3C draft because of politics is not productive. |
| 19:58 | <jgraham> | AryehGregor: FWIW I tend to agree with that |
| 19:58 | <jgraham> | Even though I think what is said in the WHATWG draft is largely accurate |
| 19:58 | <AryehGregor> | I somewhat agree. |
| 19:58 | <AryehGregor> | But it doesn't help anything to put it there. |
| 19:58 | <jgraham> | Indeed |
| 19:59 | <Dashiva> | Does it help anything to complain about it being put there? |
| 19:59 | <AryehGregor> | No, but I stand less chance of convincing the W3C than I do of convincing Hixie, I think. |
| 19:59 | <Hixie> | AryehGregor: I'm not trying to start a flame war. I'm trying to get coherent editing guidance to edit the W3C draft and I'm trying to answer questions people have asked me in the WHATWG draft. |
| 20:00 | <Dashiva> | People keep complaining about the lack of rationale, but these chair decisions aren't exactly helping |
| 20:00 | <Philip`> | Remove the paragraph from the WHATWG draft for a few days, get the W3C snapshot published, then put it back into the WHATWG draft - easy solution |
| 20:00 | <AryehGregor> | Hixie, on the latter point, you could answer them without explicitly stating anything that's derogatory toward the W3C. |
| 20:01 | <AryehGregor> | The former point I'm fine with. |
| 20:01 | <Dashiva> | It's a shame the truth has to be such as dirty thing |
| 20:01 | <Hixie> | AryehGregor: if the truth is derogatory, the problem isn't with the statement saying the truth. |
| 20:03 | <AryehGregor> | Hixie, saying the truth directly instead of indirectly is often not productive or wise. Just because something is correct doesn't mean it's pragmatically a good idea to say it. |
| 20:03 | <AryehGregor> | You can rephrase things so as to be still true but less hostile. |
| 20:03 | <drclue> | @Hixie I tend to both agree and disagree. The truth is the truth , but packaging makes a lot of difference in how long it takes to resolve an issue |
| 20:04 | <Hixie> | AryehGregor: people are asking me why the drafts are different. Can you give me text that is (a) true, (b) accurately answers the question, and (c) isn't beating around the bush? |
| 20:04 | <Hixie> | s/accurately/accurately and usefully/ |
| 20:04 | <Dashiva> | Besides, it's only derogatory if you agree politics is a bad thing |
| 20:04 | <Dashiva> | Shouldn't you then be more concerned about bad things running the show? |
| 20:05 | <Fyrd> | jgraham: Re: Your suggestion for caniuse.com - So like http://caniuse.com/#agents=gecko,webkit_chr but not showing any feature with red in it? If not, could you elaborate? |
| 20:05 | <AryehGregor> | Hixie, "I don't know. Here's a link to the decision that made me remove the text, but I don't understand it." |
| 20:05 | <Hixie> | Dashiva: i am, hence my question about editing guidance |
| 20:05 | <drclue> | Politics sucks , and often has little to do with achieving the best results , but same is a fact of life |
| 20:05 | <Hixie> | AryehGregor: you think that would be less upsetting? |
| 20:06 | <AryehGregor> | Hixie, yes. You aren't accusing them of anything, you're just saying you don't understand them. |
| 20:06 | <Hixie> | AryehGregor: the current text doesn't accuse anyone of anything either |
| 20:06 | <Hixie> | it just states a fact |
| 20:06 | <AryehGregor> | "The W3C version omits a paragraph of implementation advice for political reasons" accuses the W3C of removing that paragraph for political rather than technical reasons, which is not a characterization they'd agree with. |
| 20:07 | <AryehGregor> | Linking to the actual decision rationale rather than summarizing it in a way that its authors disagree with would not only be more politic, it would also be more accurate. |
| 20:07 | <jgraham> | Fyrd: Yes, and working for any number of UAs, not just 2 |
| 20:07 | <Hixie> | AryehGregor: it's also not really true -- i understand the reason for the change, the reason is that the chairs made a political decision instead of a technical one and then tried to bury that fact in a pseudo-technical description of their decision |
| 20:07 | <Dashiva> | The decision process itself is pretty clear that it's a political process |
| 20:07 | <drclue> | That is some harsh text , not sure how much forward motion one would hope for out of that , no matter how true it was |
| 20:08 | <jgraham> | FrOh, wait, it is the comparison thing that only works for 2 |
| 20:08 | <jgraham> | Fyrd: ^ |
| 20:08 | <Fyrd> | Right. |
| 20:09 | <Fyrd> | So maybe if I added a "hide features with missing support" checkbox, would that work? |
| 20:09 | <AryehGregor> | Hixie, incorporating that interpretation into the actual text of the spec does not help anything substantial and does harm something. Namely, the chairs will apparently require that the W3C version of the spec not contain links to the WHATWG version. |
| 20:09 | <jgraham> | Fyrd: Well I was imaging something more like the comparison thing, but with N > 2 browsers and no table, just a list of supported features |
| 20:10 | <Fyrd> | Hmm...okay. |
| 20:10 | <Fyrd> | I think I've wanted that before myself, actually. |
| 20:10 | <Fyrd> | Will look into it. |
| 20:10 | <jgraham> | Fyrd: The use case was someone who has to su[port specific browsers wondering what tech they can use |
| 20:11 | <Fyrd> | Ah, gotcha. |
| 20:11 | <Fyrd> | Specific browser versions then too, yeah? |
| 20:11 | <jgraham> | Yeah |
| 20:11 | <drclue> | @AryehGregor That's why I have a drafts folder , so I can be as "truthful" as I want , and then once I cool a bit I can gift wrap |
| 20:11 | <Fyrd> | Alright, I see now. Thanks for the suggestion, jgraham. |
| 20:12 | <Fyrd> | Anyone else have any caniuse.com suggestions while I'm here? |
| 20:13 | <Dashiva> | An option for what jgraham suggested where it also has a list of features you can't use |
| 20:14 | <Fyrd> | Dashiva: Hm, alright. |
| 20:14 | <Dashiva> | http://lists.w3.org/Archives/Public/public-html/2010Jun/0242.html |
| 20:15 | <Dashiva> | Funny how JF worries about the users when it's the W3C that refuses to accept design principles such as priority of constituencies |
| 20:15 | <drclue> | If there are features one cannot use , why not just have a CSS class for them so that they can stay structurally in the same place and when they evolve the CSS for them can be changed |
| 20:19 | <TabAtkins> | Hixie: Take sicking's advice and just rename Microdata to RDFa5. |
| 20:20 | <Hixie> | TabAtkins, meet AryehGregor. He's trying to get me to _reduce_ the political friction. :-P |
| 20:20 | <Dashiva> | TabAtkins: 5 is too controversial |
| 20:20 | AryehGregor | hits TabAtkins with a stick |
| 20:20 | <Dashiva> | Maybe RDFa 4, followed by 4.01 |
| 20:22 | <drclue> | I would probably keep my powder dry with the w3.org types and save the debate for things that really matter. (Unless one really thinks this is a big deal) |
| 20:23 | <Hixie> | can anyone remember why we added a reference to second WCAG to the w3c html draft? |
| 20:23 | <Hixie> | a second reference to |
| 20:23 | <Hixie> | not a reference to second |
| 20:24 | <Hixie> | i can't find the relevant e-mail |
| 20:24 | Hixie | is trying AryehGregor's suggested approach of citing e-mails rather than referring to things as political |
| 20:25 | <AryehGregor> | Dashiva, see, I told you I have more chance of convincing Hixie. |
| 20:25 | <AryehGregor> | Now I just have to convince him that legacy presentational markup shouldn't be lumped into the same category as things like parse errors and <image>. |
| 20:26 | <TabAtkins> | AryehGregor: If you ever come down to the bay area, I visited a great kosher restaurant last night. Slow service, but food was quite good. |
| 20:26 | <drclue> | The lost art of winning by not having your opponent loose |
| 20:26 | <AryehGregor> | TabAtkins, what was it called? |
| 20:26 | <Hixie> | apparnetly the answer is http://www.w3.org/Bugs/Public/show_bug.cgi?id=9241 |
| 20:26 | <TabAtkins> | The Kitchen Table, iirc. |
| 20:26 | <jgraham> | TabAtkins: That description got worse as it went on |
| 20:26 | <jgraham> | from great -> slow -> quite good |
| 20:27 | <jgraham> | well I guess slow is worse than "quite good" |
| 20:27 | <Dashiva> | AryehGregor: You haven't actually solved the problem, though |
| 20:27 | <TabAtkins> | Yes, it is. |
| 20:27 | <jgraham> | but neither really sums to "great" |
| 20:27 | <TabAtkins> | "quite good" can be equivalent to "great". |
| 20:27 | TabAtkins | doesn't impose a total ordering on his comparitives. |
| 20:28 | <AryehGregor> | Dashiva, not yet. |
| 20:28 | <jgraham> | No, great is strictly better than quite good |
| 20:28 | <TabAtkins> | Fine. |
| 20:28 | <Dashiva> | AryehGregor: If anything, it might get worse, since now more people will be exposed to the full insanity of the decisions |
| 20:28 | <TabAtkins> | s/food was quite good/food was OMGWTFBBQORGASMIC/ |
| 20:29 | <jgraham> | You get orgasams at BBQs? That must be socially akward |
| 20:29 | <TabAtkins> | That's just how we texans roll. |
| 20:29 | <Philip`> | Dashiva: People can easily block out insanity when it's disguised with sufficient waffle |
| 20:29 | <TabAtkins> | We're quite serious about our bbq. |
| 20:29 | <jgraham> | Mmmm waffles |
| 20:30 | <Dashiva> | Philip`: Now why did you have to bring up waffles. Now there'll be a waffle war. |
| 20:30 | <Philip`> | Dashiva: so you just need to be careful not to summarise the decisions in a single sentence, because that will expose people to it unfairly |
| 20:30 | <jgraham> | Is that like a beef war? |
| 20:31 | <jgraham> | Or more like a food fight? |
| 20:31 | <Hixie> | AryehGregor: how is the new text at http://www.whatwg.org/specs/web-apps/current-work/#is-this-html5? ? |
| 20:31 | <Dashiva> | It's when I point out that American waffles are horrible dry things with no taste |
| 20:32 | <TabAtkins> | Dashiva: How can anyone disagree, though? |
| 20:32 | <Dashiva> | I don't know, but they still do |
| 20:34 | <AryehGregor> | Hixie, I suggest you remove "redundant and inconsistent". (If it's redundant and inconsistent, why didn't you say that in the bug you linked to?) Other than that, you'll have to ask the chairs, I guess. |
| 20:35 | <AryehGregor> | TabAtkins, a restaurant that claims to be kosher but doesn't mention on its website who certifies it as kosher strikes me as extremely suspicious. |
| 20:35 | <TabAtkins> | AryehGregor: They mentioned the certification on their menu, though I didn't pay enough attention to it to remember who it was. |
| 20:36 | <AryehGregor> | TabAtkins, it's very possibly some rabbi that no one's heard of and no one reasonable would trust. |
| 20:36 | <TabAtkins> | Hixie: CSS should probably be a part of that last section. |
| 20:36 | <TabAtkins> | AryehGregor: Sure, that's possible. |
| 20:36 | <TabAtkins> | There were plenty of jews there, though, so you can at least get some assurance from the crowd. |
| 20:37 | <Hixie> | AryehGregor: i didn't say it in the bug because it wasn't worth my time to whine about it |
| 20:37 | <AryehGregor> | Hixie, but it's worth your time to whine about it in the WHATWG draft? |
| 20:37 | <zcorpan_> | Hixie: then why whine about it in the spec |
| 20:40 | <drclue> | "The W3C version includes a second reference to the WCAG document, with the two having some inconsistancies" |
| 20:41 | <AryehGregor> | That's poor grammar. |
| 20:41 | <drclue> | OK , fix the grammar , but the idea is to ditch the blame fest |
| 20:42 | <AryehGregor> | You're still saying they're inconsistent. Just ignore that. If it's worth pointing out, point it out in the W3C and make sure your link to the reasoning includes that objection. |
| 20:43 | <AryehGregor> | No one will complain if you link to a discussion that happens to include objections, they'll complain if the spec text actually endorses one of those objections. |
| 20:43 | <AryehGregor> | (I mean, some people might complain, but I don't think anyone important will complain.) |
| 20:43 | <Hixie> | AryehGregor: it's not whining, it's just explaining that they're different |
| 20:44 | <drclue> | Why even call it an objection? Perhaps a need to consolidate or something. |
| 20:45 | <AryehGregor> | Hixie, I think it will needlessly aggravate people. My advice is to not include that wording in the spec. That section only serves to highlight the differences, it doesn't need to include all the reasoning inline. |
| 20:45 | <Hixie> | the section serves to answer the question "why are they different" which i'm getting asked a lot |
| 20:46 | <Hixie> | zcorpan_: what should i link to, re CSS? |
| 20:46 | <zcorpan_> | maybe it should be in a wiki page instead of in the spec |
| 20:46 | <AryehGregor> | Then say "because of a request by XXX", like with the decision link. If you want to say why you didn't implement it in the WHATWG draft, maybe say it in the bug. I don't know. |
| 20:46 | <zcorpan_> | Hixie: CSS? |
| 20:46 | <AryehGregor> | TabAtkins, most Jews aren't religious at all, and many of those who consider themselves religious wouldn't be considered religious by most Orthodox Jews, so it's not really helpful to say that there are other Jews there. |
| 20:47 | <Hixie> | zcorpan_: oops, that was tab's idea |
| 20:47 | <TabAtkins> | Okay. |
| 20:47 | <Hixie> | TabAtkins: what should i link to, re CSS? |
| 20:47 | <drclue> | I would think Hixie is right in pointing out disparities , it just needs to be in a neutral tone |
| 20:47 | <TabAtkins> | http://www.w3.org/Style/CSS/current-work ? |
| 20:48 | <AryehGregor> | The proper place to criticize the W3C's decisions is in the places the W3C has set up for that purpose, not in the official spec text of an organization that's supposed to be cooperating with the W3C. |
| 20:48 | <TabAtkins> | That page describes itself as "the place to start" if "you want to follow the development of CSS3". |
| 20:48 | <Hixie> | AryehGregor: k, reload? |
| 20:48 | <Hixie> | TabAtkins: k |
| 20:49 | <drclue> | My point exactly! The declaration needs to be phrased as other than criticism , but none the less it is worth mentioning. |
| 20:50 | <AryehGregor> | Hixie, that looks much better to me. I suggest you ask the chairs if they're okay with it. |
| 20:50 | <Hixie> | k |
| 20:50 | <AryehGregor> | (and by "the chairs" I mean Sam, since Maciej is reportedly on vacation and Paul participates about as much as any Microsoft employee) |
| 20:50 | <AryehGregor> | (marginally more, I guess) |
| 20:50 | <zcorpan_> | Hixie: 'WebSRT' didn't get xreffed |
| 20:53 | <Hixie> | zcorpan_: yeah, that'll get fixed in due course |
| 20:59 | gsnedders | wonders what it is about him using words incessently like "normally" last week (esp. Saturday) and "inevitably" this week |
| 21:04 | TabAtkins | just took the W3C copy of Microdata and did a simple search-and-replace for "microdata"->"RDFa5". It reads astonishingly well. |
| 21:05 | <zcorpan_> | TabAtkins: you should publish a FPWD |
| 21:05 | <AryehGregor> | I'm pretty sure the RDFa WG would object. |
| 21:05 | <TabAtkins> | For real. |
| 21:06 | <AryehGregor> | Hixie has trouble understanding other people's points of view if they don't seem logical to him. You just like causing trouble. |
| 21:07 | <TabAtkins> | That's not true. |
| 21:07 | <AryehGregor> | I wasn't really serious. :P |
| 21:07 | <TabAtkins> | I genuinely think that many people's objections to Microdata are that it doesn't contain the string "RDFa" in its name. This is an easy fix. |
| 21:07 | <AryehGregor> | Okay, so I take it back, you aren't good at understanding other people's points of view either. |
| 21:08 | <AryehGregor> | Come on, you really think that? |
| 21:08 | <AryehGregor> | People's objections are that they and all their work got sidestepped. |
| 21:08 | <AryehGregor> | It's not the name. RDFa 2 is based on RDFa 1.1, and made by basically the same people. That's the difference. |
| 21:08 | <drclue> | Hixie suffers from having an actual IQ, and the natural impatience that can bring on in certain situations |
| 21:09 | <TabAtkins> | AryehGregor: I'm not talking about the people who worked on RDFa. |
| 21:09 | <TabAtkins> | I'm referring to the sideline commenters. |
| 21:09 | <AryehGregor> | They objected for the same reasons, because they see it as one person engaging in a pattern of marginalizing those he disagrees with. |
| 21:09 | <AryehGregor> | Which in other cases includes them, typically. |
| 21:09 | <TabAtkins> | I think you're imputing far too much thought to most of the positions held. |
| 21:10 | <zcorpan_> | Hixie: 404 - http://www.whatwg.org/specs/web-apps/current-work/complete/Essays1743.ttf |
| 21:10 | <AryehGregor> | I think that if you refuse to accept that people you disagree with have actual motives and aren't just acting randomly out of stupidity, you're not going to get very far in any situation requiring compromise and discussion. |
| 21:11 | <TabAtkins> | Now you're imputing too little thought to my objection. ^_^ |
| 21:11 | <AryehGregor> | I didn't say this is what they consciously think, by the way. I said it's the reason. |
| 21:11 | <AryehGregor> | I mean, the reason for their actions. |
| 21:11 | <AryehGregor> | Also, they have the idea that the web data community has expertise, and microdata ignores that expertise. |
| 21:12 | <Hixie> | zcorpan_: oops |
| 21:12 | <TabAtkins> | Yes, they have that idea. Which is incorrect, of course, as Microdata is almost functionally equivalent to RDFa. |
| 21:13 | <AryehGregor> | The basic point is that the WHATWG supporters think Hixie is smart and does a good job of balancing different concerns against each other, and the W3C supporters think that it's better to get everyone to agree to compromises rather than having one well-situated person arbitrate. |
| 21:14 | <Dashiva> | You mean having three well-situated people arbitrate instead of one |
| 21:14 | <AryehGregor> | Yes, that's technically true, but everyone pretends it isn't. |
| 21:14 | <AryehGregor> | It's also not quite true in practice, because the chairs try to minimize objections, while Hixie tries to do whatever is best regardless of objections. |
| 21:14 | <zcorpan_> | four - first hixie arbitrates and then three people arbitrate if someone objects |
| 21:14 | <Hixie> | don't forget tim |
| 21:15 | <zcorpan_> | fine, so five |
| 21:15 | <Hixie> | (you gotta love a process where the more you escalate something, the less knowledgable in the subject is the person making the decision) |
| 21:15 | <AryehGregor> | Isn't that how most processes work? |
| 21:16 | <drclue> | I tend to at times suffer the same handicap of pushing for whats best, and it does get me into trouble some times. |
| 21:16 | <AryehGregor> | People with broader authority are automatically going to have less expertise in any particular thing. |
| 21:17 | <Hixie> | AryehGregor: it's not how the whatwg process works -- if you escalate from me, the people who decide are all even more involved in the web than i am |
| 21:17 | <AryehGregor> | There's no formal procedure to escalate to the steering committee, though, right? |
| 21:18 | <AryehGregor> | What it comes down to is that the steering committee is reps of major browsers, and if any of the major browsers object, then you can't put it in the spec anyway. |
| 21:18 | <drclue> | Sometimes even the folks heavily involved , sorta have blinders on. While I dutifully switched from tables to CSS tables , I'm glad to see the old tables back, so I have a choice. |
| 21:19 | <AryehGregor> | What old tables? |
| 21:19 | <TabAtkins> | Indeed, what? |
| 21:19 | TabAtkins | suspects drclue fell prey to some of the more misguided anti-table evangelism. |
| 21:20 | <drclue> | The table elements that went away for a while , or at least were strongly discouraged. I myself like tables |
| 21:20 | <zcorpan_> | http://chestofbooks.com/food/household/Woman-Encyclopaedia-4/images/Chippendale-occasional-table-with-gallery-and-carved-legs-T.jpg |
| 21:20 | <zcorpan_> | that's a pretty old table |
| 21:20 | <TabAtkins> | There is not and has never been anything wrong with tables, nor have they every disappeared. |
| 21:20 | <TabAtkins> | The problem is and has always been using tables as a page-layout tool. |
| 21:22 | <TabAtkins> | Some people read "don't use tables for layout" and heard "don't use tables", and then went crazy trying to design tables without using <table>s. Which was silly and ridiculous, and caused some harm to people who thought the standardistas must have known what they were talking about. |
| 21:22 | <drclue> | Well, yes , I agree that having long running open elements was bad on performance , but it actually got to a point where project specs strictly prohibited ANY tables. |
| 21:22 | <TabAtkins> | That's retarded. |
| 21:22 | <drclue> | I know it's retarded |
| 21:22 | <TabAtkins> | You use <table>s to mark up tables. You don't use them to mark up non-tables. |
| 21:23 | gsnedders | gets the point of buying lens, then realizes, "wait, I don't have enough money in this account, damned Swedes ot giving me a card I can use online" |
| 21:23 | <drclue> | I use tables for tabular data, and not much more |
| 21:23 | gsnedders | is not bitter or anything |
| 21:25 | <drclue> | Occasionally I bend my table rules , but only a little and never to the grand scale of abuse that seemed to give tables their bad rep |
| 21:26 | <drclue> | Of course I run into folks who get so rigid in their particular design rules that they would rather break a page than break a rule :) |
| 21:27 | <Hixie> | so btw do i win anything for being right about how shelley leaving the group would have no effect on her posting to the list? :-) |
| 21:27 | <AryehGregor> | That doesn't even count as a prediction. Hasn't she done it like four times already? |
| 21:30 | <Hixie> | filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=9894 on the process |
| 21:31 | <Dashiva> | Hixie: That bet was never valid in the first place, since she had "left" before |
| 21:35 | <AryehGregor> | Hixie, this is what banning legacy presentational markup results in. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/66500 |
| 21:38 | <Hixie> | AryehGregor: what am i looking at? |
| 21:39 | <AryehGregor> | "Replace <tt> by <code>, as <tt> is deprecated in HTML5" |
| 21:39 | <AryehGregor> | Followed by a diff that does a search-and-replace of <tt> for <code>. |
| 21:39 | <hober> | Hixie: no one took you up on that bet, right? |
| 21:44 | <Hixie> | AryehGregor: well so long as you're trying to convert a presentational language (wiki) into a semantic one (html), you're doomed |
| 21:45 | <AryehGregor> | Hixie, 1) The commit had nothing to do with wikitext. It affected only MediaWiki's wikitext-independent output; <tt> in wikitext still gives you <tt> in HTML output. 2) Wikitext is mostly just a macro language on top of HTML, and is no more or less semantic than HTML itself. |
| 21:46 | <Hixie> | oh, ok |
| 21:46 | <Hixie> | well |
| 21:46 | <Hixie> | r- |
| 21:46 | <Hixie> | "this is the wrong fix, please go and actually make sure you use semantics correctly" |
| 21:46 | <AryehGregor> | Yes, great, but that doesn't fix the fact that other authors will be doing the same thing for the same reasons. |
| 21:46 | <AryehGregor> | It's illustrative. |
| 21:47 | <AryehGregor> | Most authors don't understand semantic markup. If you tell them that the new standard says you can only use semantic markup, they'll just misuse it horribly. Or, at best, translate automatically to <span style="font-family:monospace">. |
| 21:47 | <AryehGregor> | Wordpress (AFAICT) gives you an italics button, which looks exactly like the italics button in Microsoft Word, which outputs <em>. |
| 21:48 | <AryehGregor> | And a bold button that outputs <strong>. |
| 21:48 | <Hixie> | yes, people misuse html |
| 21:48 | <Hixie> | news at 11 |
| 21:49 | <AryehGregor> | If you aren't designing the semantics to minimize misuse by authors, what's the point? If even the authors of really large web apps don't get it, who will? |
| 21:49 | <Hixie> | the problem is that authors write inaccessible pages |
| 21:49 | <Hixie> | whether they do it using <font> or misuse of <em>, the problem is the same |
| 21:50 | <AryehGregor> | No, because UAs will know that <font> is not semantic. They won't know that for <em>. |
| 21:50 | <Hixie> | i don't see how that's ad advantage |
| 21:50 | <jgraham> | The general statement of the problem is "a general purpose UA can't make use of inconsistent semantics" |
| 21:50 | <jgraham> | (or at least can't make optimal use) |
| 21:50 | <AryehGregor> | If authors are encouraged to misuse semantic elements for presentation, you get a <table> situation, where you can't infer any semantics because it's usually used for presentation. |
| 21:50 | <AryehGregor> | (encouraged as in they have an incentive to, not as in they're told to) |
| 21:51 | <jgraham> | (but allowing <tt> doesn't help much because people will still pick the wrong choice an appreciable fractio of the time) |
| 21:51 | <Hixie> | ok now sam is just treating me like a child |
| 21:51 | <AryehGregor> | If you treat <tt> the same as a parse error, that's a strong reason for authors to replace it with <code> (which is shorter and easier to type than <span style="font-family:monospace">). |
| 21:52 | <AryehGregor> | If the validator just says "maybe you could consider using semantic markup instead if possible", then you'll increase the signal-to-noise ration in semantic markup. |
| 21:53 | <Hixie> | we tried that in html4 |
| 21:53 | <AryehGregor> | And authors didn't use semantic markup. Okay, well, they aren't going to anyway. |
| 21:53 | <AryehGregor> | So nothing lost. |
| 21:53 | <AryehGregor> | Forcing them to either mass-convert their pages to a syntax that's (at best) logically equivalent, or just give up on validation, is not a win. |
| 21:54 | <Hixie> | bb in 20 |
| 21:54 | <AryehGregor> | <tt> will mostly either get converted to <code> (wrong) or <span style="font-family:monospace"> (no better than <tt>). |
| 21:54 | <AryehGregor> | Okay. |
| 21:54 | <AryehGregor> | I've been meaning to reopen the bug I filed about this, I'll argue more there. |
| 21:59 | <AryehGregor> | Hmm. It seems like the Nexus One engraving thing has a limited font selection. |
| 21:59 | <AryehGregor> | I'll have to rethink what I want to put there. Sigh. |
| 22:13 | <Hixie> | back |
| 22:15 | <Hixie> | AryehGregor: i'm certainly in favour of making sure validators give error messages that are more appropriate than just "not allowed" |
| 22:15 | <Hixie> | AryehGregor: hence the long section on obsolete elements and the advice for how to replace them |
| 22:15 | <AryehGregor> | It's the verdict that matters to most people, not the details. "Is this a standards-compliant document or not?" |
| 22:15 | <AryehGregor> | It's something that people have on their checklist for web application quality. |
| 22:15 | <Hixie> | well if they use presentational markup, it shouldn't be compliant |
| 22:16 | <Hixie> | because they shouldn't use presentational markup |
| 22:16 | <AryehGregor> | style="" is every bit as presentational as <tt>. |
| 22:16 | <Hixie> | yes, and i wanted to make that non-conforming too |
| 22:16 | <Hixie> | unfortunately it has a couple of valid use cases |
| 22:17 | <Hixie> | (as a rapid prototyping tool, and as a special-case override) |
| 22:17 | <Hixie> | it's non-conforming to use style="" in the same way as <tt> |
| 22:17 | <Hixie> | (though of course a validator can't easily report that) |
| 22:18 | <AryehGregor> | You can't make things not validate based on an idealized notion of what authors should do. Validation has to reflect reality. If it makes unreasonable demands, authors will ignore it or evade it. You have to look at whether a requirement will actually improve pages in practice, not whether it would improve pages if authors hypothetically followed it. |
| 22:18 | <AryehGregor> | In practice, by allowing <code> and <span style="font-family:monospace"> but not <tt>, you'll just encourage authors to move en masse from the latter to the former. |
| 22:18 | <Hixie> | it's not an unreasonable demand to make pages accessible |
| 22:19 | <Hixie> | seriously. semantic markup is not _that_ complicated. |
| 22:19 | <Hixie> | people do understand it once they try. |
| 22:19 | <AryehGregor> | That position does not reflect reality. Even highly competent authors rarely produce consistently semantic markup. |
| 22:19 | <AryehGregor> | None of the top websites consistently uses semantic markup, for instance. |
| 22:19 | <Hixie> | even highly competent software engineers write software with bugs, but we still expect them to try to not include bugs |
| 22:20 | <Hixie> | even highly competent doctors rarely have perfect track records in healing people but we still expect them to try |
| 22:20 | <AryehGregor> | The record shows that highly competent authors do not even try to consistently use semantic markup. |
| 22:20 | <Hixie> | nonsense |
| 22:20 | <AryehGregor> | Really? |
| 22:21 | <Hixie> | sure |
| 22:21 | <AryehGregor> | Have you looked at Gmail's HTML? Does that look like trying to use semantic markup? |
| 22:21 | <AryehGregor> | Or google.com's HTML? |
| 22:21 | <TabAtkins_> | That looks like machine-generated markup coming from a java application. |
| 22:21 | <AryehGregor> | Precisely. |
| 22:21 | <AryehGregor> | And it's purely presentational. |
| 22:21 | <Hixie> | the existence of counter-examples is not proof of a generalisation |
| 22:21 | <TabAtkins_> | AryehGregor: I assure you that we are trying our best to move to better markup. |
| 22:22 | <Hixie> | there are certainly large numbers of pages that are written poorly |
| 22:22 | <AryehGregor> | So then where are your examples in support of the generalization? |
| 22:22 | <Hixie> | look at how people have jumped on the new html5 elements |
| 22:22 | <TabAtkins_> | Though I doubt it matters to use exactly what the tags are called - we just want to reduce the massive numbers of wrapping <div>s and similar. |
| 22:22 | <TabAtkins_> | s/use/us/ |
| 22:22 | <AryehGregor> | I predict that the new elements won't be used correctly unless they provide tangible effects that make them differ practically from <div>s. |
| 22:23 | <Hixie> | there are plenty of languages that already exist if what you want is just a formatting language |
| 22:23 | <AryehGregor> | Yes, like HTML. |
| 22:24 | <AryehGregor> | Which has the advantage of being implemented in web browsers. |
| 22:24 | <AryehGregor> | Unlike, well, everything els. |
| 22:24 | <AryehGregor> | else. |
| 22:24 | <Hixie> | i find that to be a short-sighted approach: it's media-dependent, inaccessible without annotations, hard to maintain, etc. |
| 22:24 | <jgraham> | AryehGregor: Agreed, but they should if people implement the outlining algoritm |
| 22:24 | <jgraham> | (about tangible effects being critical) |
| 22:24 | <Hixie> | i'm interested in a language that is media-independent, accessible by default, easy to maintain, etc. |
| 22:24 | <AryehGregor> | You can write media-independent, maintainable HTML that's totally presentational. That's mostly a matter of CSS. |
| 22:25 | <Hixie> | CSS is an optional technology |
| 22:25 | <AryehGregor> | Not in practice. |
| 22:25 | <Hixie> | yes in practice |
| 22:25 | <Hixie> | i use browsers with no CSS support regularly |
| 22:25 | <Hixie> | and I rely on a user agent with no CSS support constantly (google search) |
| 22:26 | <AryehGregor> | It can still be media-independent and maintainable without using semantic elements significantly. |
| 22:26 | <Hixie> | not anywhere near as easily as if you just use semantic elements |
| 22:26 | <AryehGregor> | Sure, but the difference is clearly not enough that most authors care. You're left with the choice of telling those authors that they don't get a useful validator, or rethinking your approach. |
| 22:27 | <AryehGregor> | I think semantic HTML is great, and I use it myself wherever possible, but you have to take into consideration the practicalities of the matter. |
| 22:27 | <Hixie> | the practicalities of the matter are that it's time for authors to get with the programme |
| 22:28 | <jgraham> | Typically education doesn't work |
| 22:28 | <AryehGregor> | Then come up with an effective way of doing that. Saying their pages don't validate if they contain machine-detectably non-semantic markup just means they'll move to non-semantic markup that's not machine-detectable. |
| 22:28 | <Hixie> | jgraham: it's worked pretty well for banning tables-for-layout |
| 22:29 | <AryehGregor> | Tables-for-layout died because CSS usually works better, not because of evangelism. |
| 22:29 | <Hixie> | i don't buy that at _all_ |
| 22:29 | <Hixie> | css can't even do basic table layouts |
| 22:29 | <Hixie> | it's one of the things TabAtkins_ is working on |
| 22:29 | <AryehGregor> | Really? Table-based markup is a nightmare to maintain. |
| 22:29 | <Hixie> | yes! |
| 22:29 | <AryehGregor> | Mostly you don't *want* table layouts, is the thing. |
| 22:29 | <Hixie> | so is <tt>-based and <font>-based markup |
| 22:29 | <Hixie> | and <div>-based markup for that matter |
| 22:30 | <Hixie> | (i originally wanted to ban <div> too but sadly people found good use cases for it too) |
| 22:30 | <AryehGregor> | If that's really true, authors will move away from it by themselves. Few have. |
| 22:30 | <jgraham> | <em> and <i> seem roughly equally hard |
| 22:31 | <jgraham> | Which seems like the problem AryehGregor is concerned with |
| 22:31 | <jgraham> | (I know <i> is allowed) |
| 22:31 | <AryehGregor> | Provide them with a superior technology, one that they can clearly see is superior, and they'll use it. |
| 22:31 | <AryehGregor> | Validators never banned tables, and they disappeared regardless, because they were a pain to use. |
| 22:31 | <Hixie> | i don't expect all authors to get the finest points of the phrasing element definitions (though i certainly hope that html5's much clearer definitions will increase the understanding by orders of magnitude over html4's) |
| 22:32 | <AryehGregor> | Almost no authors read the spec, so definitions don't help much. |
| 22:32 | <AryehGregor> | Even very savvy authors don't read specs. |
| 22:32 | <Hixie> | the definitions spread to tutorials |
| 22:32 | <Hixie> | furthermore, using them results in more maintainable code than inline formatting, so i think it's a win already |
| 22:33 | <jgraham> | AryehGregor: I think you are wrong about <table> |
| 22:33 | <Hixie> | i don't really think it's the end of the world if people use <code> instead of <kbd> or <samp>, at least not to the extent that it's a problem if they use <table> instead of <aside> |
| 22:33 | <AryehGregor> | The point is that if you tell people they can't use <tt>, they'll port everything blindly to <code>. They won't move to semantic markup. You're getting rid of machine-detectable non-semantic markup in favor of non-machine-detectable non-semantic markup. |
| 22:33 | <Hixie> | similarly it's not the end of the world if they use <article> instead of <section> or vice versa |
| 22:34 | <jgraham> | Also, requiring locally better solutions doesn't work because the problems that are fixed are all exterialities from the author's point of view |
| 22:34 | <Hixie> | the finer grained semantics provide tools that the more adventurous authors can use to their advantage |
| 22:34 | <AryehGregor> | jgraham, what do you mean? |
| 22:35 | <Hixie> | AryehGregor: i don't think it's the end of the world if they use <code> instead of <tt> for a start. When they mature as authors they might start using <samp> where it's more appropriate, e.g. if they decide they want to style something differently (rather than using classes) |
| 22:35 | <jgraham> | AryehGregor: The advantage of using <code> in the correct place is typically not for the authors themselves but for some third party e.g. people using screen readers |
| 22:35 | <Hixie> | AryehGregor: if i were designing the language from scratch it's quite possible i wouldn't even bother with many of the current phrasing elements, they are quite fine grained and esoteric in some cases |
| 22:35 | <AryehGregor> | Hixie, but that elides a useful distinction: <tt> for "I don't have any opinion on the semantics, I just want it monospace" vs. <code> for "I want this monospace because it's code". |
| 22:36 | <Hixie> | AryehGregor: *shrug* |
| 22:36 | <AryehGregor> | To the extent that the semantics are useful, that's a significant difference. |
| 22:36 | <jgraham> | sleep++ |
| 22:36 | <AryehGregor> | Requiring authors to do this kind of porting will also add to the burden of emitting valid HTML5, which will encourage authors to just ignore validation. |
| 22:37 | <AryehGregor> | Hixie, well, okay. Just remember, I'm pretty sure I'm the first author who actually tried to port a major, heavily-used web app to HTML5. Consider this early feedback. |
| 22:37 | <AryehGregor> | (Valid HTML5, of course I mean, not just <!doctype html>) |
| 22:38 | <Hixie> | AryehGregor: this is not a new problem - people have been running into this porting from HTML4 Transitional to Strict for a decade or more now |
| 22:38 | <AryehGregor> | They had the option of not porting to Strict. |
| 22:38 | <Hixie> | AryehGregor: which everyone was _supposed_ to do years ago |
| 22:38 | <AryehGregor> | Which the large majority of web apps and pages took. |
| 22:38 | <Hixie> | AryehGregor: yeah, and look at how that went |
| 22:38 | <AryehGregor> | MediaWiki was explicitly XHTML 1.0 Transitional because converting to Strict would have been stupid and pointless. |
| 22:38 | <Hixie> | it's not stupid and pointless if done right |
| 22:39 | <AryehGregor> | I defy you to tell me one single appreciable advantage of rewriting <table cellpadding=""> in wikitext to use some kind of CSS. |
| 22:40 | <Hixie> | i thought we weren't talking about wikitext |
| 22:40 | <Hixie> | the main advantage is reduced file size |
| 22:40 | <Hixie> | assuming we're talking about actual data tables |
| 22:41 | <Hixie> | the second advantage is that once you do all the table styling in CSS, you can get _much_ prettier data tables. |
| 22:41 | <Hixie> | (the third advantage doesn't apply to wikitext, presumably: when editing a table by hand, it's much easier to maintain if there's no presentational cruft on every table) |
| 22:42 | <AryehGregor> | Well, okay. |
| 22:42 | <Hixie> | the fourth advantage is that it is less likely that people will use data tables if their tables can't have presentational markup |
| 22:43 | <Hixie> | (also presumably not applicable here) |
| 22:43 | <Hixie> | the fifth advantage is that it lets you change the padding on a media-by-media basis |
| 22:43 | <Hixie> | e.g. to make tables tighter on a mobile device than when printed |
| 22:43 | <AryehGregor> | Let's put it this way: MediaWiki's interface will probably become marginally more semantic to conform to HTML5. The real problem is that we have loads of legacy wikitext that was valid XHTML 1.0 Transitional but isn't valid HTML5. I guess this is idiosyncratic. |
| 22:43 | <AryehGregor> | Probably not that idiosyncratic. |
| 22:44 | <AryehGregor> | But you can make a GIGO argument here. |
| 22:44 | <Hixie> | sure, if you need to bring a legacy of bad code into the modern day, you'll have a lot of work |
| 22:44 | <Hixie> | that's certainly very true |
| 22:44 | <Hixie> | for presentational wikitext, it's work that would probably need to happen anyway to make the output more accessible |
| 22:45 | <AryehGregor> | An impossible amount, in this case. There are some tens of millions of pages, at least. |
| 22:45 | <Hixie> | yup |
| 22:45 | <AryehGregor> | What changes could be made in wikitext that would make the output more accessible, given editors who are clueless about accessibility? |
| 22:45 | <Hixie> | make wikitext just be semantic html -- semantic html is accessible by default |
| 22:46 | <AryehGregor> | Not if people misuse it. |
| 22:47 | <Hixie> | instead of http://en.wikipedia.org/wiki/Wikipedia:Tutorial_(Formatting) saying how to do bold, italics, and bold-italics, have the page say how to mark up the defining instances of terms on the page, how to mark up stress emphasis, how to mark up titles of works, etc |
| 22:47 | <Hixie> | people who can get to grips with how to write an encyclopedia can get to grips with how to write basic semantic markup |
| 22:47 | <Hixie> | it's not that hard |
| 22:47 | <AryehGregor> | We don't control that page. It was written by users based on what they think makes the best tutorial. |
| 22:48 | <Hixie> | yes, but if the markup language had been semantic, they'd think that the best tutorial would be to teach the semantics of the language |
| 22:48 | <Hixie> | we see that all the time |
| 22:49 | <AryehGregor> | I really think you're ignoring a lot of evidence that most people find semantic markup too much trouble to bother with, even if they actually understand it. A proper response is to figure out why they think that and try to fix it, not just figure they're all wrong. |
| 22:49 | <Hixie> | i'm open to suggestions, but "just let them write inaccessible pages" doesn't cut it |
| 22:49 | <Hixie> | why do people prefer to write presentational markup than semantic markup? |
| 22:49 | <Hixie> | how do we fix that? |
| 22:50 | <hober> | Have your employer de-index w3schools, that might help :/ |
| 22:50 | <AryehGregor> | For one thing, requests from non-programmer are almost always phrased in presentational terms. |
| 22:50 | <AryehGregor> | non-programmers |
| 22:50 | <Hixie> | hober: yeah, no kidding. |
| 22:50 | <AryehGregor> | The specifications for a web page are normally totally presentational. |
| 22:50 | <Hixie> | AryehGregor: indeed, but why? how do we fix that? |
| 22:50 | <AryehGregor> | Designers decide how they want it to look, then developers are asked to make it look that way. |
| 22:51 | <AryehGregor> | Because the overwhelming majority of (perceived?) users use web browsers that ignore the semantics of the documents. |
| 22:51 | <AryehGregor> | Normal web browsers don't distinguish between <tt> and <code>, so normal users don't care, so authors don't care. |
| 22:51 | <Hixie> | how do we teach to designers that a web page will be rendered on dozens of devices and could have a visual presentation, a braille presentation, a voice presentation, etc? |
| 22:51 | <Hixie> | with different device capabilities, etc? |
| 22:52 | <AryehGregor> | You can't get them to care about screen readers if they have a negligible number of blind users. |
| 22:52 | <AryehGregor> | You might be able to get them to care about, say, cell phones. Maybe. |
| 22:52 | <Hixie> | so what, screw the blind? |
| 22:52 | <zcorpan_> | make dreamweaver have multiple views of the document |
| 22:52 | <zcorpan_> | i think they've done that now |
| 22:52 | <AryehGregor> | No, just acknowledge that trying to mandate things that most authors won't listen to doesn't help the blind. Authoring requirements have to reflect reality just as much as implementer requirements. |
| 22:53 | <Hixie> | i strongly disagree with that later statement |
| 22:53 | <Hixie> | i think in the case of authoring requirements, conformance requirements have to _lead_ reality |
| 22:53 | <AryehGregor> | Why the difference? |
| 22:54 | <Hixie> | because authoring requirements don't affect interop |
| 22:54 | <Hixie> | they affect the success with which an author can convey meaning |
| 22:54 | <Hixie> | whereas UA requirements are intended to result in interop |
| 22:54 | <Hixie> | it's a huge assymetry |
| 22:55 | <Hixie> | it's the same reason why UA requirements have to cover every eventuality of author input, but author requirements don't have to cover every eventuality of UA output |
| 22:56 | <AryehGregor> | Reasonable. |
| 22:57 | <zcorpan_> | authors have to deal with actual UA output |
| 22:57 | <AryehGregor> | Nevertheless, you cannot preempt cost-benefit analyses by authors. If a business is making a website to sell a product that has effectively no blind users, then you are not going to be able to persuade them to expend nontrivial resources on making things accessible to blind people. |
| 22:57 | <AryehGregor> | Not unless you have more power over authors than standards bodies actually do in practice. |
| 22:58 | <AryehGregor> | The best you can do is hope people want their pages to validate, but that power becomes weaker with every additional requirement, because stricter requirements mean fewer people bother to comply. |
| 22:58 | <AryehGregor> | Ideally, HTML would be crafted so that it's really accessible with no effort involved beyond what it takes to get the page working right in a standard visual browser. |
| 22:58 | <AryehGregor> | Unfortunately, that's not possible. |
| 22:59 | <Hixie> | that's certainly true. It's why with HTML5 we've made a significant effort to remove requirements that are pointless (e.g. "ids can't start with a number") and make the actual requirements all have good reasons (like "doing this will disenfranchise the blind") |
| 22:59 | <Hixie> | ("that" being the thing about power becoming weaker with each requirement) |
| 22:59 | <Hixie> | i think with HTML5 we actually get pretty close to what you describe |
| 22:59 | <AryehGregor> | But the blind will be disenfranchised anyway. If you require alt text, authors will put empty alt text or lousy alt text. |
| 22:59 | <Hixie> | but obviously there are limits to what we can do |
| 22:59 | <AryehGregor> | Unless they care about the blind to begin with. |
| 23:00 | <AryehGregor> | Wikipedia didn't allow alt text on images until like last year, when I added the feature for basically idealistic reasons. I don't recall ever seeing a single complaint. |
| 23:00 | <AryehGregor> | If authors don't get complaints from actual users, they won't fix things. |
| 23:01 | <Hixie> | wikipedia images almost always just repeat what is already said on the page |
| 23:01 | <AryehGregor> | It's way easier to just trivially fix all the validator errors, than to actually test in a screen reader (which is what you really need to do to get a good website for the blind). |
| 23:01 | <Hixie> | so it's not a big deal for wikipedia images to not have alt text in many cases |
| 23:02 | <Hixie> | AryehGregor: for authors who don't care about making content accessible, the alternatives i see are them using purely presentational markup, or them using non-presentational markup that approximates their semantics by virtue of defaulting to relatively close to the presentation they want |
| 23:03 | <Hixie> | AryehGregor: neither is ideal, but the second option is mildly better. |
| 23:03 | <Hixie> | AryehGregor: and had the benefit that it might make them look things up. maybe. |
| 23:03 | <AryehGregor> | Shrug. |
| 23:03 | <AryehGregor> | I guess we'll see what happens. |
| 23:03 | <Hixie> | AryehGregor: for authors who _do_ care about making content accessible, but simply don't know that it's an option, the validator complaining about presentational markup will lead them to find out how to do it. |
| 23:04 | <AryehGregor> | Except when all the tutorials switch to using semantic-as-presentational markup instead of actually presentational markup. |
| 23:04 | <Hixie> | some might |
| 23:04 | <Hixie> | some won't |
| 23:06 | <AryehGregor> | I'd probably be more inclined to agree with you if I weren't faced with the fact that most Wikipedia pages will never validate again once we switch to HTML5. I'll just have to view that as GIGO, I guess. |
| 23:06 | <AryehGregor> | Maybe add an option to not allow the newly-invalid markup. |
| 23:07 | <Hixie> | there's definitely a dichotomy between newly created pages and legacy pages that are going to be ported |
| 23:07 | <Hixie> | i wish i had a good solution to that problem |
| 23:07 | <Hixie> | it's one we've fought with a lot |
| 23:07 | <Hixie> | most of the old "downplayed errors" and the current "obsolete but conforming" stuff are related to that problem |
| 23:08 | <AryehGregor> | If mechanical translation were used, do you think it would be better to do <tt> -> <span style="font-family:monospace"> or <tt> -> <code>? |
| 23:08 | <Hixie> | we need different validator behaviour for different pages, but without running into the HTML4 Transitional problem (where everyone writes new pages that claim to be legacy pages) |
| 23:09 | <AryehGregor> | Wikitext is really hard to parse, though, so we can't feasibly do mechanical translation of any kind on the source wikitext. |
| 23:09 | <Hixie> | because we don't have a good solution, i've tended to favour the needs of new pages, because there will be more new pages in the future than there are pages that will be migrated |
| 23:09 | <AryehGregor> | We could force everyone to switch by shutting off support for old elements/attributes, but that would break . . . everything. |
| 23:09 | <AryehGregor> | It's a headache. |
| 23:09 | <Hixie> | AryehGregor: i don't think you can successfully do a mechanical translation of presentational markup to semantic markup today without an intimate knowledge of the source document's typographic conventions |
| 23:10 | <AryehGregor> | If you could do reliable automated translation from presentational to semantic markup, semantic markup would not be needed. |
| 23:14 | <Dashiva> | Aren't most wikipedia images actually <figure> form? |
| 23:14 | <AryehGregor> | I guess your decision is reasonable, but it's a huge pain in the neck for me. |
| 23:14 | <AryehGregor> | Dashiva, yes, but we can't use that until IE8 is dead. Don't want to rely on JS hacks. |
| 23:15 | <Dashiva> | You don't have to use the element, but you can use its aria mappings |
| 23:15 | <AryehGregor> | Interesting idea. |
| 23:15 | <Hixie> | AryehGregor: i completely agree that it's a huge pain in the neck for anyone with legacy content |
| 23:15 | <Hixie> | AryehGregor: i have no good solution for that sadly |
| 23:20 | <zcorpan_> | http://forums.whatwg.org/viewtopic.php?t=4315 - feedback on rel=prefetch |
| 23:26 | <zcorpan_> | "BUT Is it CORRECT to put a NAV tag within a HEADER TAG? I have read in the specs that you can put non H or HGROUP tags within a header but it refers to those other tags as "metadata"... That makes me nervous." - http://www.sitepoint.com/forums/showthread.php?p=4613614#post4613614 |
| 23:46 | <Hixie> | jesus, i just got 6 copies of the BoF announcement -- and that's after deduping due to corss-posting |
| 23:48 | <abarth> | i think they're worried about it being last-minute |
| 23:51 | <Hixie> | face to face meetings like that are such a waste of time |
| 23:51 | Hixie | mumbles |
| 23:51 | <AryehGregor> | It's nice to meet people sometimes. |
| 23:51 | <AryehGregor> | Even if not much gets done. |
| 23:53 | <Hixie> | i'm all for people getting together for fun |
| 23:53 | <Hixie> | that's not what these things are |
