| 01:12 | AryehGregor | realizes that there was tons of public-html discussion about presentational markup that he missed before filing his bug -- oh well |
| 01:17 | <TabAtkins> | Hehe. |
| 01:18 | <AryehGregor> | I like how when people are using a Bugzilla that's not meant to track bugs in client software, it still auto-fills the platform field, so you can figure out whether everyone uses Windows/Mac/Linux. |
| 01:18 | <AryehGregor> | You'd think they'd make those fields disabled by default, since most Bugzilla instances surely don't need them . . . |
| 01:52 | <othermaciej> | Dashiva: if I missed one can you give me a URL for it? |
| 01:53 | <othermaciej> | Hixie: what's the benefit of being able to distinguish a text repacement from a non-replacement text description for an image? |
| 01:53 | <othermaciej> | Hixie: maybe the pragmatic thing to do is to loosen the definition of alt, rather than have complicated rules about what goes where |
| 01:53 | <TabAtkins> | A text replacement can be simply read as normal text, while a description can be denoted as such (rather than a seemingly-random bit of description in the middle of content). |
| 01:55 | <othermaciej> | I think screen readers typically distinguish both (there's no way typically to get it not to identify an image as such, even if it has alt text) |
| 01:55 | <othermaciej> | I suppose text-only UAs might treat them differently, though I am not sure they actually do anything with, for example, the title attribute |
| 01:55 | <othermaciej> | so it's hard to predict what they would do if they did |
| 01:57 | <othermaciej> | yowza, there's 178 open bugs |
| 01:58 | <Dashiva> | othermaciej: Maybe I just was confused, it seems the confirmed -> verified transition didn't generate bugmail |
| 01:58 | <Dashiva> | *resolved -> verified |
| 01:58 | annevk | is sleepy |
| 01:58 | <othermaciej> | Dashiva: yeah, it has to be done in two steps |
| 01:59 | <annevk> | btw othermaciej, will you be at the CSS get-together later today? |
| 01:59 | <othermaciej> | annevk: oh, I didn't know there was a thing today - I was considering coming for some of the meeting tomorrow and/or joining people for dinner during the week if there was a scheduled one |
| 02:00 | <annevk> | some people are meeting at 7pm at the hotel close to inf loop |
| 02:00 | <annevk> | not sure when the Apple organized dinner is |
| 02:01 | <othermaciej> | ah, doubt I can make it there in time (I'm in San Francisco) |
| 02:28 | <annevk> | it's on Tuesday per TabAtkins |
| 02:33 | <othermaciej> | cool |
| 02:50 | <JonathanNeal> | Ahoy! |
| 02:50 | <JonathanNeal> | TabAtkins, hhheyo |
| 03:49 | <Hixie> | othermaciej: the benefit is that for replacement text, you can forget that it was an image, and don't need to taunt the user with "image!" each time |
| 03:50 | <othermaciej> | Hixie: do any screen reader vendors do that, or plan to? |
| 03:50 | <othermaciej> | (VoiceOver does say "image" all the time; not aware of any plans to change) |
| 03:51 | <Hixie> | well i doubt any of them would plan to change unless we make the spec support that case |
| 03:51 | <Hixie> | currently it's a self-reinforcing race to the bottom |
| 04:03 | <Dashiva> | Not much to do about it as long as supporting Jaws 4 remains a requirement |
| 04:45 | <othermaciej> | does anyone have IE handy? |
| 04:45 | <othermaciej> | I am trying to determine whether any browser does what the spec says for <wbr> (rather than something essentially functionally identical to a zero-width space) |
| 04:49 | <othermaciej> | if anyone could save the text here into an HTML file and load it in IE, I would be much obliged: http://paste.lisp.org/display/97008 |
| 04:50 | <othermaciej> | in Safari and Firefox, wbr just seems to create a breaking opportunity if line breaks are allowed at all, rather than doing so regardless of the whitespace mode |
| 04:51 | <Hixie> | check for open bugs on <wbr>, i remember doign it then someone saying what the spec said was wrong but i don't recall if i already fixed it |
| 04:51 | <othermaciej> | ok, I'll look |
| 04:51 | <othermaciej> | Opera does not grok <wbr> (still) |
| 04:52 | <Hixie> | yeah that's why i added it, zcorpan (iirc) told me they needed it for compat |
| 04:53 | <othermaciej> | I really should get my Windows partition working, and VMWare or something installed so I can test IE myself on my laptop |
| 04:54 | <othermaciej> | I see, there's http://www.w3.org/Bugs/Public/show_bug.cgi?id=9097 |
| 04:54 | <Hixie> | i had windows 7 rc in a vm for a while but it expired |
| 04:54 | <Hixie> | i should get a real w7 license |
| 04:54 | <othermaciej> | I think Simon is correct that <wbr> does something essentially equivalent to a ZWSP, but I am not sure if it is equivalent in all details or all browsers |
| 04:55 | <othermaciej> | however, what the spec says now is definitely wrong: |
| 04:55 | <othermaciej> | "The wbr element is expected to override the 'white-space' property and always provide a line-breaking opportunity." |
| 04:55 | <othermaciej> | it provides a line-breaking opportunity but it does *not* (as far as I can tell) override the 'white-space' property |
| 04:55 | <othermaciej> | at least not in WebKit or Gecko |
| 04:55 | <Hixie> | well it definitely overrides <nobr> iirc |
| 04:55 | <Hixie> | no? |
| 04:56 | <othermaciej> | it doesn't override white-space: pre |
| 04:56 | <othermaciej> | let me try nowrap |
| 04:56 | <Hixie> | <wbr> and <nobr> are such a huge pain in the neck, i wish we could just get rid of them altogether (like <spacer>), rather than just obsolete them |
| 04:56 | <othermaciej> | ah, it does override nowrap |
| 04:56 | <othermaciej> | but not pre |
| 04:56 | <othermaciej> | so it's not the same as ZWSP |
| 04:57 | <othermaciej> | ZWSP doesn't override white-space nowrap |
| 04:57 | <othermaciej> | I proposed going the other way, since popular sites actually use them, and at least in the case of <wbr> there is apparently no other way to get the same effect |
| 04:57 | <Hixie> | popular sites use all kinds of crap |
| 04:57 | <Hixie> | doesn't make it a good idea |
| 04:58 | <Hixie> | there are plenty of ways of getting line breaking opportunities into text |
| 04:58 | <othermaciej> | "line-breaking opportunity" seems like a valid use case |
| 04:59 | <othermaciej> | I dunno, you can judge when you read my bugs about this |
| 04:59 | <Hixie> | it's what ZWSP is for |
| 04:59 | <othermaciej> | yeah, except ZWSP doesn't seem to quite match <wbr> in that it won't override white-space: nowrap |
| 04:59 | <miketaylr> | othermaciej: here's IE7/vista: http://miketaylr.com/post/865d1bfa.png |
| 05:00 | <miketaylr> | (alls i have on hand ATM) |
| 05:00 | <Hixie> | othermaciej: it's easy to turn off white-space:nowrap, so that doesn't seem like a problem |
| 05:00 | <othermaciej> | miketaylr: interesting - looks like in IE, both <wbr> and ZWSP override all white-space: pre |
| 05:00 | <miketaylr> | yeah |
| 05:01 | <othermaciej> | Hixie: sure, you could insert <span style="white-space: normal">​</span> instead of <wbr> |
| 05:01 | <Hixie> | well more likely you wouldn't do anything like that, you'd just do it all in css |
| 05:01 | <Hixie> | since where you want line-breaking depends on your styles |
| 05:02 | <othermaciej> | I don't see how you could do it all in CSS - line breaking opportunities, like hard line breaks, have to be places in specific places in the content |
| 05:02 | <othermaciej> | they depend on the content, not the style |
| 05:03 | <Hixie> | well it depends on what you're doing |
| 05:03 | <othermaciej> | miketaylr: would you mind trying a version of that with white-space: nowrap instead of white-space: pre? |
| 05:03 | <miketaylr> | sure one sec |
| 05:04 | <Hixie> | if you're strictly defining line-breaking opportunities without a particular style in mind, then sure, ZWSP is fine |
| 05:04 | <Hixie> | if you're actually trying to make headlines flow in various ways depending on the width of the page, or whatnot, then it's CSS |
| 05:04 | <Hixie> | sometimes it might be a mixture |
| 05:04 | <othermaciej> | at least one use case for <wbr> seems to be a very long run of text containing no whitespace; in many cases ZWSP will work just as well, is just more painful to type |
| 05:05 | <Hixie> | often though, <wbr> is used where you would have to move it if you had an alternative style sheet, and that indicates to me that it's not semantic |
| 05:05 | <Hixie> | and should be done in CSS instead |
| 05:05 | <othermaciej> | in the case of a run of text where you need to inhibit normal line breaking but want explicit break opportunities, then you probably need <wbr> (though I suppose you could replace all your normal whitespace with non-breaking space) |
| 05:06 | <othermaciej> | (an example I can imagine like that is pairs of words where you don't want to break in the middle of a pair, only between pairs) |
| 05:07 | <Hixie> | and &zwsp; seem like the right way to handle that. It'd even survive transferring to other mediums that use text but don't use HTML. |
| 05:08 | <Hixie> | (&zwsp; isn't valid though) |
| 05:08 | <Hixie> | (so you'd have to use the entity if you didn't have the unicode character inline) |
| 05:08 | <miketaylr> | ...and white-space:nowrap: http://miketaylr.com/post/5d157284.png |
| 05:08 | <karlcow> | what about " "? |
| 05:08 | <othermaciej> | does &zwsp; do anything? |
| 05:09 | <othermaciej> | like is it working but invalid, or just nonexistent? |
| 05:09 | <Hixie> | non-existent |
| 05:09 | <karlcow> | " " = 00A0 |
| 05:11 | <othermaciej> | so yes, ​ is a plausible alternative for <wbr>, though it doesn't do all the same things |
| 05:11 | <Hixie> | othermaciej: though you can use ‌ which is more or less the same as i understand it |
| 05:11 | <othermaciej> | as well as being way less fun to input |
| 05:11 | <Hixie> | i wouldn't be as opposed to <wbr> if it didn't come with a lot of legacy baggage -- it's more or less the same as <br> |
| 05:12 | <karlcow> | http://www.quirksmode.org/oddsandends/wbr.html |
| 05:13 | <othermaciej> | what's the legacy baggage? |
| 05:13 | <othermaciej> | just the special interaction with white-space: nowrap? |
| 05:13 | <Hixie> | othermaciej: all the weird rules of how it works |
| 05:14 | <othermaciej> | maybe I need to reverse-engineer it more thoroughly to understand the rules and figure out if they are truly weird |
| 05:15 | <othermaciej> | noninteroperable legacy behavior would definitely be a justifiable reason to make it nonconforming, since there is a close (if not identical) substitute |
| 05:22 | karlcow | is exploring the unicode table on macosx and discovering cool spaces |
| 05:25 | <othermaciej> | heh |
| 05:25 | <othermaciej> | yeah |
| 05:25 | <othermaciej> | see |
| 05:25 | <othermaciej> | the best thing about <wbr> is you don't have to be a master of the ludicrous number of whitespace characters to use it |
| 05:25 | <othermaciej> | anyway I guess it's best to let it set |
| 05:29 | <othermaciej> | Hixie: zwnj doesn't seem to create a breaking opportunity (in case you were curious) |
| 05:29 | <Hixie> | ah ok |
| 05:33 | <othermaciej> | I wonder if it would be compatible enough to just make <wbr> render as a zero-width space |
| 05:44 | <ap> | othermaciej: the main thing to test would probably be interaction with RTL text |
| 05:44 | <othermaciej> | ap: would you expect it to be different in that regard than zero-width space? |
| 05:45 | <othermaciej> | the main oddity seems to be interaction with different CSS white-space modes |
| 05:45 | <othermaciej> | (haven't found a browser yet that treats it any different under <nobr> than it would in any other white-space: nowrap context) |
| 05:46 | <ap> | othermaciej: I don't know. But all these spaces are subtly different, so it would be a coincidence if wbr matched it |
| 05:47 | <othermaciej> | ok, I'll try RTL |
| 05:49 | <othermaciej> | ap: seems like the only difference under RTL is same as LTR - it breaks even in white-space: nowrap |
| 05:49 | <ap> | othermaciej: how does it affect directionality of neutral text? |
| 05:50 | <othermaciej> | ap: how can I test that? |
| 05:50 | <othermaciej> | what I'm using as a test case is this: |
| 05:50 | <othermaciej> | "TheQuickBrownFoxJumpedOverTheLazyDog.<wbr>TheQuickBrownFoxJumpedOverTheLazyDog.<wbr>" |
| 05:50 | <othermaciej> | (repeated many times) |
| 05:50 | <othermaciej> | it seems to affect the period the same way ZWSP does, as far as I can observe |
| 05:50 | <ap> | othermaciej: that |
| 05:51 | <ap> | 's how I would test |
| 05:51 | <ap> | othermaciej: actually, I'd also try <p>.<wbr><RTL text></p> |
| 05:51 | <ap> | othermaciej: with no strong directionality characters on one side |
| 05:52 | <ap> | othermaciej: but again, I don't know RTL |
| 05:52 | <othermaciej> | I think that might be beyond my level of understanding |
| 06:41 | <JonathanNeal> | aloha |
| 06:53 | <hsivonen> | Hixie: do the fancy unicode tricks get out of the way in clipboard export in shipped browsers? |
| 06:53 | <Hixie> | nbsp does, at least |
| 06:53 | <hsivonen> | oh. I thought it didn't |
| 06:55 | <hsivonen> | for Farsi use cases, it would be weird not to export zwnj to the clipboard |
| 06:56 | <hsivonen> | I think we should allow wbr and nobr. we don't delegate br to the unicode layer, either |
| 06:56 | <Hixie> | i could buy <wbr> if it didn't have the weird behaviours |
| 06:56 | <Hixie> | but <nobr>? really? |
| 06:57 | <Hixie> | what's the use case? |
| 06:57 | <Hixie> | people use it far more inappropriately than appropriately |
| 06:57 | <Hixie> | i'm fine with having the few rare appropriate use cases use if only to discourage the use of <nobr> |
| 06:59 | <hsivonen> | Hixie: the use case is to avoid breaking at hyphens |
| 07:00 | <Hixie> | white-space: nowrap |
| 07:00 | <hsivonen> | i'm on a browsers without copy and paste, but google for jukka korpela nobr |
| 07:01 | <hsivonen> | Hixie: how is that plus a span with class more maintainable, compact or accessible |
| 07:01 | <Hixie> | why would you use a span and a class? |
| 07:01 | <Hixie> | just use whatever the current parent is |
| 07:03 | <Hixie> | anyway, bed time |
| 07:03 | <Hixie> | nn |
| 07:04 | <hsivonen> | Hixie: I guess one would need a study of the real-world usage of white-space: nowrap; to see what it gets applied to |
| 07:04 | <hsivonen> | nn |
| 08:55 | <othermaciej> | filing these bugs from the conformance study is making me learn more than I wanted to know about all sorts of stuff (now the tokenizer) |
| 08:55 | <othermaciej> | hsivonen: is tokenization inside attributes and inside text content similar enough to be useful right now? |
| 09:00 | <JonathanNeal> | After mapping out the default stylesheets for ie, I tried running one on Google Chrome. |
| 09:00 | <JonathanNeal> | Not only does it crash Chrome, it crashes all of Chrome's tabs. |
| 09:01 | <othermaciej> | JonathanNeal: tried running one of what? |
| 09:01 | othermaciej | wonders if that is a Chrome bug or a WebKit bug and whether it has been reported |
| 09:03 | <JonathanNeal> | Stranger, it only crashes when I run it on my localhost |
| 09:04 | <JonathanNeal> | http://sandbox.thewikies.com/html5-browser-stylesheets/style.php?b=ie6 |
| 09:06 | <JonathanNeal> | Here's a pic of the crash @ http://sandbox.thewikies.com/html5-browser-stylesheets/crash.png |
| 09:07 | <peol> | JonathanNeal: What version of Chrome/Chromium? |
| 09:07 | <JonathanNeal> | peol, 4.1.249.1042 (42199) |
| 09:09 | <peol> | JonathanNeal: Hmm, and it only crashes on localhost, is it consistent? |
| 09:09 | <JonathanNeal> | yeappers |
| 09:09 | <JonathanNeal> | only when I run the php file too. |
| 09:09 | <peol> | JonathanNeal: Heh, I wonder what could cause it to crash locally but not remotely =p |
| 09:10 | <JonathanNeal> | You can use http://sandbox.thewikies.com/html5-browser-stylesheets/style.php.txt to save the php file locally. |
| 09:13 | <peol> | JonathanNeal: It seems to do all right over here, both locally and remotely on 41671 |
| 09:14 | <JonathanNeal> | Yea, it's very mysterious. |
| 09:14 | <JonathanNeal> | Nevertheless, I have some nifty ie6, ie7, ie8 default stylesheets in there now. |
| 09:15 | <peol> | JonathanNeal: http://sandbox.thewikies.com/html5-browser-stylesheets/elements.ie.js seems to be broken too, doubt it's relevant though :) |
| 09:15 | <peol> | JonathanNeal: Yeah, did you extract them manually? |
| 09:15 | <othermaciej> | JonathanNeal: does the whole browser go down? |
| 09:16 | <othermaciej> | JonathanNeal: you might be crashing the app process, rather than the WebKit process |
| 09:16 | <JonathanNeal> | peol, no, only partially. IE will report the default styling of elements in some instances. The rest took many, many tests. |
| 09:16 | <othermaciej> | JonathanNeal: yeah, you did, from that screenshot |
| 09:16 | <JonathanNeal> | Discovering when it was using pt vs px vs em. |
| 09:16 | <othermaciej> | fwiw that page opens fine in Safari, but I dunno what was up with your local copy |
| 09:17 | <peol> | othermaciej, JonathanNeal: There might be something to it then, maybe in a newer build (or win32 only), I'm running under linux here without crashes |
| 09:17 | <JonathanNeal> | othermaciej, i can run it locally in safari all day without a crash, in chrome it takes but one refresh |
| 09:17 | <othermaciej> | definitely a Chrome bug, not a WebKit bug, then |
| 09:20 | <peol> | JonathanNeal: I bet it's the empty <object type="application/x-shockwave-flash"> that crashes it :) |
| 09:20 | <JonathanNeal> | Lemme check. |
| 09:21 | <JonathanNeal> | Okay, crashed it, now removing the object |
| 09:21 | <JonathanNeal> | oof, still crashes |
| 09:21 | <peol> | JonathanNeal: Or perhaps the empty source element in <video>, stuff like that could likely cause a crash in a daily |
| 09:22 | <othermaciej> | JonathanNeal: I would guess it's the filename crashing it |
| 09:22 | <othermaciej> | JonathanNeal: try renaming the file or moving it to a different path |
| 09:22 | <JonathanNeal> | Yessir, that was it, the <video> source element. |
| 09:22 | <hsivonen> | othermaciej: named character references currently tokenize the same way in attribute values and in element content |
| 09:22 | <othermaciej> | (just trying to guess things that would take down the Chrome UI process) |
| 09:22 | <othermaciej> | hah, wow |
| 09:23 | <JonathanNeal> | Yes, and I add it back in and it crashes. |
| 09:23 | <othermaciej> | hsivonen: whoah, are they officially called "named character references"? cause that would be hella confusing |
| 09:23 | <othermaciej> | (what with the "NCR" abbreviation) |
| 09:24 | <hsivonen> | othermaciej: the thingies formerly known as entities are now named character references |
| 09:24 | <othermaciej> | hsivonen: entity tokenization is the one thing that is very slightly different in quoted attribute values: http://dev.w3.org/html5/spec/Overview.html#attribute-value-double-quoted-state |
| 09:24 | <othermaciej> | (vs http://dev.w3.org/html5/spec/Overview.html#data-state ) |
| 09:24 | <peol> | JonathanNeal: Sweet, now we know how to crash chromium dailies :) |
| 09:25 | <JonathanNeal> | :) glad I could help in a way entirely unrelated to what I was trying to accomplish. |
| 09:26 | <hsivonen> | othermaciej: oops. sorry. I misread my code. |
| 09:26 | <othermaciej> | hsivonen: in fact, just making "=" be treated as an extra "additional allowed character" would do the trick |
| 09:26 | <othermaciej> | hsivonen: that being said, I amended the bug because I think my reasons to limit the request were misguided |
| 09:28 | <othermaciej> | hello Lachy |
| 09:28 | <Lachy> | hello othermaciej |
| 09:31 | <hsivonen> | othermaciej: the "additional allowed character" takes effect immediately after the ampersand |
| 09:32 | <hsivonen> | othermaciej: so it's too interesting |
| 09:32 | <othermaciej> | hsivonen: s/too interesting/not too interesting/ ? |
| 09:32 | <hsivonen> | othermaciej: oops. right |
| 09:32 | <hsivonen> | othermaciej: the actually interesting bit is this: "If the character reference is being consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON character (;), and the next character is in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z, or U+0061 LATIN SMALL LETTER A to U+007A LATIN SMALL LETTER Z, then, for historical reasons, all the characte |
| 09:33 | <hsivonen> | which I was trying to locate by reading code, but failed to see even though it was in plain view in my code |
| 09:33 | <othermaciej> | hsivonen: got cut off |
| 09:33 | <hsivonen> | If the character reference is being consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON character (;), and the next character is in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z |
| 09:34 | <hsivonen> | , or U+0061 LATIN SMALL LETTER A to U+007A LATIN SMALL LETTER Z, then, for historical reasons, all the characters that were matched after the U+0026 AMPERSAND character (&) must be unconsumed, and nothing is returned. |
| 09:34 | <othermaciej> | hsivonen: I guess it's still true that there is already a difference, I was just wrong that the additional allowed character isthe key one |
| 09:34 | <othermaciej> | I found it in the spec, no worries |
| 09:34 | <hsivonen> | othermaciej: yeah |
| 09:34 | <othermaciej> | I guess that is the list to add = to, as previously identified by zcorpan on the old thread on this I believe |
| 09:35 | <hsivonen> | putting = on that list would certainly remove a sharp edge from the language |
| 09:36 | <hsivonen> | do we have data gathered by intrumenting that particular point in the tokenizer? |
| 09:36 | <hsivonen> | instrumenting |
| 09:36 | <othermaciej> | not as far as I know |
| 09:37 | <othermaciej> | however, one of the emails I linked in the bug cites raw data |
| 09:45 | <hsivonen> | looks like the only real danger is indeed &= |
| 09:45 | <hsivonen> | it would be possible to special-case &= |
| 09:45 | <hsivonen> | even though I'm generally scared of heavy DWIM |
| 09:46 | <hsivonen> | ooh. crazy. I misread the data |
| 09:47 | <othermaciej> | I guess my bug is a dupe of http://www.w3.org/Bugs/Public/show_bug.cgi?id=9207 |
| 09:47 | <hsivonen> | indeed they seem to want &= to mean &amp= |
| 09:47 | <othermaciej> | Hixie did find at least one case where it seemed "&=" was meant to be "&" [sic] |
| 09:49 | <zcorpan> | othermaciej: i've added a new comment to that bug |
| 09:49 | <othermaciej> | zcorpan: yeah, that's how I noticed |
| 09:49 | <othermaciej> | trying to decide if I should dupe mine to that |
| 09:49 | <hsivonen> | I was such a bad idea to use an SGML special character as a special character in URLs, too |
| 09:49 | <othermaciej> | my bug makes a narrower request and has potentially useful comments, but I could always copy the comments |
| 09:50 | <othermaciej> | or I could cross-reference them and let Hixie decide whether it is a dupe |
| 09:50 | <hsivonen> | btw, is what the spec now says only for IE-compat and there are other browsers that don't expand ©= to the copyright sign? |
| 09:51 | <hsivonen> | old Gecko expands :-( |
| 09:52 | <hsivonen> | WebKit, too |
| 09:56 | <zcorpan> | going by train is great, because then i have time to analyze things like this |
| 09:58 | <othermaciej> | hsivonen: what the spec says now matches browsers better than the proposed changes, the motive for changing parsing is that it may fix more content than it breaks, in addition to removing a sharp edge |
| 10:03 | <zcorpan> | ®_nr= will still have the sharp edge |
| 10:06 | <othermaciej> | unless we add _ to the list too |
| 10:09 | hsivonen | wonders how & was added to URLs |
| 10:09 | <zcorpan> | yes but that would break some pages |
| 10:09 | <hsivonen> | presumably it wasn't part of TimBL's original design, because isindex doesn't need it |
| 10:09 | <othermaciej> | probably added whenever forms were added |
| 10:10 | <othermaciej> | it does seem like it would have been wise to pick a different separator |
| 10:10 | <hsivonen> | who was the first to add forms? Lynx? |
| 10:11 | <hsivonen> | http://people.cc.ku.edu/~grobe/early-lynx.html pointsto Lou Montulli |
| 10:12 | <othermaciej> | forms existed in HTML 2 |
| 10:12 | <othermaciej> | so at the latest by 1995 |
| 10:12 | <othermaciej> | Lou Montulli is personally responsible for a surprising number of completely broken things |
| 10:12 | <hsivonen> | http://www.montulli.org/lou |
| 10:12 | <othermaciej> | (not necessarily saying forms is one of them, but that's the context where I usually hear his name) |
| 10:13 | <hsivonen> | forms go back to 1992: http://lists.w3.org/Archives/Public/www-talk/1992NovDec/0212.html |
| 10:13 | <othermaciej> | cookies, server push, the blink tag, and animated GIFs |
| 10:13 | <othermaciej> | we get to enjoy all those things on the web thanks to him |
| 10:14 | <othermaciej> | I guess someone else gave us the wonder of framesets |
| 10:15 | <othermaciej> | so is there a record there of who decided & should be the field separator in URL queries? |
| 10:16 | <hsivonen> | w3.org doesn't have archives from 1993 and 1994, so the thread goes into unarchived territory |
| 10:17 | <othermaciej> | I wonder if any of the folks who were around back then remember |
| 10:18 | <hsivonen> | hmm. looks like served admins have accidentally knocked my personal site off the Web over the weekend |
| 10:21 | <othermaciej> | at least in 1993, forms were not in the Internet Draft for HTML: http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt |
| 10:22 | <othermaciej> | "HTML 3.0 did not succeed for several reasons. The draft was considered very large at 150 pages...." |
| 12:04 | <karlcow> | hsivonen: look at the bottom of http://lists.w3.org/Archives/Public/www-talk/ for archives in 1991 and 1992 |
| 12:04 | <hsivonen> | karlcow: yeah, but no 1993 or 1994 there |
| 12:05 | <karlcow> | ah yeah just realized you were talking about 93 94 |
| 12:05 | <hsivonen> | karlcow: the interesting thread started in Dec 1992 |
| 12:05 | <karlcow> | check here |
| 12:06 | <karlcow> | http://www.w3.org/Style/History/www.eit.com/www.lists/ |
| 12:07 | zcorpan | gets not found errors when trying to view emails |
| 12:07 | <karlcow> | there are also accessible there http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/ |
| 12:08 | zcorpan | finds http://1997.webhistory.org/www.lists/www-talk.1993q2/ |
| 12:08 | <karlcow> | and http://1997.webhistory.org/www.lists/ |
| 12:09 | <zcorpan> | http://1997.webhistory.org/www.lists/www-talk.1993q2/0557.html |
| 12:13 | <zcorpan> | http://1997.webhistory.org/www.lists/www-talk.1993q3/0810.html |
| 12:13 | <zcorpan> | http://1997.webhistory.org/www.lists/www-talk.1993q3/0812.html aha! |
| 12:13 | <zcorpan> | so Marc Andreessen is to blame |
| 12:18 | zcorpan | tests applying padding and border on <svg> and gets different results in all browsers |
| 13:16 | <zcorpan> | does <header> imply <body> in ie9? |
| 13:27 | <Philip`> | zcorpan: I'm fairly sure it's always treated the same as any other unrecognised element in IE9, and I vaguely remember that unrecognised elements don't imply <body> |
| 13:29 | <zcorpan> | ok |
| 13:30 | <Philip`> | (If there's a test in html5lib then the output is like in http://philip.html5.org/misc/html5lib-runner-ie9.txt) |
| 13:35 | <zcorpan> | ie9's result for Test 105 of 112 in data/tests1.dat looks weird |
| 13:35 | <zcorpan> | two head elements, a frameset and a body? |
| 13:38 | <Philip`> | Maybe it's one head element in two locations |
| 13:39 | <Philip`> | (Not that that'd be any less weird) |
| 13:39 | <zcorpan> | no, the output looks different in such a case |
| 13:39 | <zcorpan> | i think |
| 13:40 | <zcorpan> | or maybe not |
| 13:40 | <zcorpan> | the script only keeps track of the parent |
| 14:21 | <Philip`> | I dislike how Launchpad returns obscure error messages whenever you try to interact with it, if you have Referer headers disabled |
| 15:02 | <zcorpan> | foo.svg#svgView(viewBox(...)) seems awesome for image sprites |
| 15:03 | <zcorpan> | http://www.w3.org/TR/SVG11/linking.html#IntroFragmentsViews |
| 15:03 | <zcorpan> | seems to work in opera and chrome but not firefox |
| 15:04 | <zcorpan> | e.g. http://dev.w3.org/SVG/profiles/1.1F2/test/images/linkingCircle-f.svg#svgView(viewBox(64,227,72,72)) |
| 16:20 | <JonathanNeal> | Fun thing to do; make a <caption> in ie7, then alert(document.getElementsByTagName('caption')[0].currentStyle.padding); |
| 16:20 | <JonathanNeal> | "padding: 1px 300zzz 500zzz;" |
| 16:21 | <MikeSmith> | JonathanNeal: what effect does that have? |
| 16:21 | <miketaylr> | only IE7? |
| 16:21 | <JonathanNeal> | Well, they're sleepy pixels, of course! |
| 16:23 | <paul_irish> | JonathanNeal: did you find what from ie6's default css was crashing chrome? |
| 16:23 | <TabAtkins> | miketaylr: Yup, only ie7. |
| 16:23 | <miketaylr> | interesting. |
| 16:24 | <miketaylr> | s/interesting/wtf/ |
| 16:24 | <JonathanNeal> | paul_irish, we did ... but it was being triggered by a bizarre combination that was ultimately the <video> element's empty <source> |
| 16:25 | <JonathanNeal> | I never noticed till I applied ie stylesheets, but that on a php page in localhost would cause Chrome to consistantly crash until you removed the <source> in <video> |
| 16:25 | <TabAtkins> | miketaylr: Check out http://www.xanthir.com/etc/default-stylesheets.php, created from JonathanNeal's data. |
| 16:25 | <JonathanNeal> | TabAtkins, I've been meaning to tell you there are updated js files to reference for the browsers. |
| 16:25 | <TabAtkins> | Excellent. Gimme! |
| 16:25 | <miketaylr> | oh that looks great, TabAtkins |
| 16:25 | miketaylr | looks |
| 16:25 | <JonathanNeal> | Same place http://sandbox.thewikies.com/html5-browser-stylesheets/ |
| 16:26 | JonathanNeal | is not spamming, just re-referencing. |
| 16:28 | <JonathanNeal> | Actually TabAtkins I'll cue you in a minute when they're the latest latest. |
| 16:39 | <zcorpan> | blockquote[type=cite] { ...? what's this (from gecko's style sheet)? |
| 16:47 | <JonathanNeal> | TabAtkins quit :( |
| 16:51 | <Philip`> | He pung out, to be precise |
| 16:53 | <Philip`> | And so did you :-( |
| 16:55 | <smaug___> | zcorpan: seems like that has been there for ages http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/style/html.css&rev=3.216#90 |
| 17:07 | <Philip`> | http://homepages.laas.fr/felix/sky2c-data/mail/msg00044.html |
| 17:07 | <Philip`> | http://grouper.ieee.org/groups/1619/email/msg02384.html |
| 17:07 | <Philip`> | Is it the mailing list software generating the <blockquote type=cite>, or the mail clients? |
| 17:08 | <Philip`> | http://emperor.tidbits.com/webx?14@@.3cbfbb6d/45 too |
| 17:09 | <zcorpan> | i guess thunderbird uses that |
| 17:10 | <AryehGregor> | Is it just me, or does IE8 in standards mode drop support for things that aren't specced, but are interoperably supported among all browsers including IE7? |
| 17:11 | <AryehGregor> | Like <wbr>, or id's starting with a number . . . (both now specced in HTML5, of course.) |
| 17:11 | <AryehGregor> | That seems like it's a bad idea for interop. |
| 17:13 | <Xanthir> | http://www.xanthir.com/etc/default-stylesheets.php Newest version, with JonathanNeal's latest data. |
| 18:00 | <JonathanNeal> | Yay for Chrome. |
| 18:31 | gsnedders | wishes he had any clue about how TC-39 works |
| 18:33 | <othermaciej> | gsnedders: what clues do you lack? |
| 18:33 | <othermaciej> | gsnedders: I know some medium amount of stuff about it |
| 18:33 | <gsnedders> | othermaciej: Through what seemingly arbitrary process do things get into the spec? |
| 18:34 | <gsnedders> | As far as I can tell, it's easier to get things in that have already shipped (the point of the JS extensions in Gecko?), yet somethings like accessors end up spec'd in a way that is different to what is already implemented |
| 18:35 | <othermaciej> | gsnedders: I think you are supposed to make a "strawman" on the wiki, and it can eventually be upgraded to a "proposal" |
| 18:35 | <othermaciej> | the formal decision-making part is the part I least understand |
| 18:35 | <othermaciej> | not sure if it is consensus or voting or something else |
| 18:37 | <gsnedders> | othermaciej: Oh, and do you have any idea how it was decided what from ES4 got into ES5? |
| 18:37 | <othermaciej> | gsnedders: almost nothing from ES4 got into ES5, as far as I know... |
| 18:37 | <gsnedders> | Because that seems again tangential to what was already shipped by browsers |
| 18:38 | <othermaciej> | ES5 is largely based on what used to be in ES3.1 |
| 18:38 | <JonathanNeal> | Do you guys think the non-html5 elements listed in Rendering should be removed from the css presentational hints? |
| 18:38 | <othermaciej> | the only ES4 stuff that got in was stuff that was in bth |
| 18:38 | <gsnedders> | ES3.1 existed before ES4 was abandoned? |
| 18:40 | <JonathanNeal> | Also, instead of /* LTR-specific: use 'margin-right' for rtl elements */, could you [dir=rtl] ? |
| 18:42 | <AryehGregor> | "JonathanNeal> Do you guys think the non-html5 elements listed in Rendering should be removed from the css presentational hints?" What do you mean? |
| 18:43 | <AryehGregor> | [dir=rtl] is not the same as RTL, direction is inherited. |
| 18:43 | <annevk> | yeah, you'd need :rtl |
| 18:43 | <annevk> | which we might introduce in Selectors 4 |
| 18:44 | <JonathanNeal> | Regarding the first comment, @ http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-css-user-agent-style-sheet-and-presentational-hints elements like basefont, center, plaintext are mentioned. |
| 18:45 | <JonathanNeal> | I know it doesn't break anything, but it seems unnecessary to include them in this section. What do you think? |
| 18:47 | <JonathanNeal> | Also, when it says "The article, aside, nav, and section elements are expected to affect the margins of h1 elements", would this also apply to h2-h6? |
| 18:49 | <Xanthir> | JonathanNeal: default-css is updated. |
| 18:49 | <JonathanNeal> | Because I noticed that it seems to shift the margin and font-size for h1 down the scale of the h1-h6's. |
| 18:49 | <JonathanNeal> | It would seem fitting that the others would follow suit, or am I mistaken? |
| 18:50 | <annevk> | since user agents need to support the elements as per the rendering section it makes sense to include them |
| 18:50 | <JonathanNeal> | TabAtkins, groovy. I'll check it out now. |
| 18:51 | <JonathanNeal> | TabAtkins, did you use the latest js? border-color needn't show up on anchors |
| 18:52 | <TabAtkins> | JonathanNeal: Yes. |
| 18:52 | <TabAtkins> | Cache issues? Do you see the [dir=rtl] stuff at the beginning? |
| 18:52 | <JonathanNeal> | I discovered that a few of these colors are set by color: myColor;, so I check to see if they match and negate to mention them if so. |
| 18:53 | <JonathanNeal> | I did see that stuff, that was my interpretation of how the direction stuff would work, since I was testing by changing <html> to <html dir="rtl"> to see the affects in an unstyled ie. |
| 18:53 | <othermaciej> | gsnedders: yes |
| 18:53 | <TabAtkins> | (Sorry, my latency is high right now because I'm scribing for CSSWG) |
| 18:54 | <othermaciej> | gsnedders: before TC-39 settled on what is now ES5, there were two competing efforts - ES4 and ES3.1, driven by different subsets of the group |
| 18:55 | <JonathanNeal> | AryehGregor, annevk, should h2-h6 be affected by sectioning content elements like article, aside, nav, and section too? |
| 18:55 | <AryehGregor> | I'd assume so. Why not? |
| 18:56 | <JonathanNeal> | Well, may I recommend the spec be changed to reflect this? |
| 18:59 | <AryehGregor> | Post to whatwg or Bugzilla if you have a spec change suggestion. |
| 18:59 | <AryehGregor> | I haven't looked at the sectioning stuff, no idea how it works or why. |
| 19:07 | <TabAtkins> | JonathanNeal: I can explain the sectioning stuff in a bit. |
| 19:31 | <MikeSmith> | I just accidentally typed the word "equacally" in a bugzilla comment |
| 19:31 | <MikeSmith> | I kind of like it |
| 19:31 | MikeSmith | googles |
| 19:32 | <MikeSmith> | almost nothing |
| 19:32 | <MikeSmith> | I should lay claim to this word |
| 19:32 | <MikeSmith> | I'm just wondering what is should mean |
| 19:33 | <MikeSmith> | suggestions for the meaning of "equacally" welcom |
| 19:33 | <MikeSmith> | *welcome |
| 19:35 | <Dashiva> | "In a manner indistinguishable from a duck" |
| 19:37 | <MikeSmith> | heh |
| 19:37 | <MikeSmith> | that would be "equackally" I guess |
| 19:42 | <MikeSmith> | adequacally |
| 19:44 | <othermaciej> | heh |
| 19:44 | <MikeSmith> | in other news and fwiw, I added direct per-element links from the h:tml doc back to the HTML5 spec |
| 19:44 | <MikeSmith> | http://dev.w3.org/html5/markup/elements.html#elements |
| 19:45 | <othermaciej> | sweet |
| 19:45 | <MikeSmith> | the ⓘ symbol |
| 19:45 | <annevk> | btw, why is it in alphabetical order? |
| 19:45 | zcorpan | didn't know there was an ⓘ symbol |
| 19:45 | <MikeSmith> | also, on each element page; e.g., http://dev.w3.org/html5/markup/dt.html |
| 19:46 | <MikeSmith> | annevk: in alphabetical order because that's the least arbitrary way of ordering them |
| 19:47 | <MikeSmith> | is there an order that would be more useful? |
| 19:47 | <annevk> | html5 spec-order? |
| 19:47 | <annevk> | i.e. grouped by topic |
| 19:48 | <annevk> | then you could also have an introductory page per topic i guess... i.e. for forms or tables |
| 19:48 | <zcorpan> | http://simon.html5.org/html5-elements uses spec order but has a button to change the order |
| 19:48 | <MikeSmith> | that's pretty cool |
| 19:49 | <JonathanNeal> | equacally: describing something identical or equivalent to a well balanced compound water |
| 19:50 | MikeSmith | considers how to provide switchable order in the TOC |
| 19:50 | <gsnedders> | zcorpan: There's everything in a circle symbol with the COMBINING CIRCLE AROUND character |
| 19:51 | <MikeSmith> | JonathanNeal: "compound water"? |
| 19:51 | <JonathanNeal> | TabAtkins, still interested in hearing about the "sectioning stuff", which I think refers to my request to change the language @ "affect the font size of h1 elements", right? |
| 19:51 | <MikeSmith> | I don't know whether the circled "i" is the best choice here but I couldn't figure out what would work better |
| 19:51 | <MikeSmith> | there unfortunately is no circled-question-mark character |
| 19:52 | <JonathanNeal> | MikeSmith, in inorganic chemistry, aqua is a compound water. |
| 19:52 | <zcorpan> | gsnedders: aha, cool |
| 19:52 | <gsnedders> | (I think that's the Unicode name, at least, but such a combing character certainly exists) |
| 19:52 | <TabAtkins> | JonathanNeal: Yes, still minuting, give me a bit for a lunch break. |
| 19:53 | <JonathanNeal> | :D of course of course |
| 19:53 | <zcorpan> | MikeSmith: preload is not a boolean attribute |
| 19:53 | <MikeSmith> | oh |
| 19:53 | <MikeSmith> | zcorpan: then I think we must have it wrong in the schema |
| 19:53 | <MikeSmith> | TabAtkins: thanks |
| 19:54 | <MikeSmith> | oops |
| 19:54 | <MikeSmith> | make that: JonathanNeal, thanks (about aqua) |
| 19:56 | <JonathanNeal> | TabAtkins, I'd like to use the scripty you built for the ie default css tables to make something for w3c-html5.css too :) |
| 19:57 | <TabAtkins> | JonathanNeal: I'll send it to you. Simple php script. |
| 19:57 | <JonathanNeal> | Grooviness |
| 20:03 | <JonathanNeal> | Also, miketaylr may or may not steal my jokes... |
| 20:03 | <miketaylr> | WAT |
| 20:03 | <TabAtkins> | dsinger: We have agreement on *not* 2. |
| 20:03 | <TabAtkins> | argh, dammit |
| 20:04 | <miketaylr> | sorry, took the 10.6.3 update plunge...so your jokes are safe for now JonathanNeal |
| 20:05 | JonathanNeal | sends affirmation to miketaylr. |
| 20:10 | <AryehGregor> | othermaciej, for what it's worth, extending "don't cook a kid in its mother's milk" to "don't mix milk and meat" wouldn't be considered "building a fence around the Torah". In that particular case, the rabbinic interpretation is traditionally assumed to have been actually given to Moses orally on Sinai, not actually of rabbinic origin. An example would be the fact that I'm not supposed to own leavened goods right now, even though the Torah' |
| 20:10 | <AryehGregor> | s prohibition only begins tonight -- this way, I won't put it off till the last minute and accidentally violate the Torah prohibition. |
| 20:10 | <AryehGregor> | :) |
| 20:11 | <othermaciej> | AryehGregor: that's not what wikipedia said, but I admit that is not a reliable reference on religious tradition |
| 20:11 | <AryehGregor> | What article? |
| 20:12 | <othermaciej> | I believe some aspects of that prohibition, such as how many hours you have to wait after eating hard cheese, or the exclusion on chicken, are in the "building a wall" category |
| 20:12 | <AryehGregor> | Yes, that's correct. |
| 20:12 | <othermaciej> | (in meeting right now) |
| 20:12 | <AryehGregor> | There are rabbinic prohibitions surrounding nearly every Torah prohibition. |
| 20:12 | AryehGregor | wonders how othermaciej came to know of this |
| 20:12 | <Philip`> | I hope the Torah doesn't have any prohibitions related to chocolate biscuits |
| 20:12 | <othermaciej> | why would a culturally literate person not know these kinds of things? |
| 20:12 | <othermaciej> | I think what I read was http://en.wikipedia.org/wiki/Milk_and_meat_in_Jewish_law |
| 20:12 | <AryehGregor> | othermaciej, very few people know things in this depth. |
| 20:13 | <AryehGregor> | Philip`, not any in the Torah itself that I can think of. Of course, non-Jews don't have to follow the Torah anyway, so I'm pretty sure you're safe. |
| 20:14 | <othermaciej> | I am technically Jewish by matrilineal descent, but not observant or even brought up in the tradition |
| 20:14 | <AryehGregor> | Oh, really? Interesting. |
| 20:14 | <othermaciej> | however, this topic is one I have been at various times curious about |
| 20:14 | <AryehGregor> | I like this quote: HTML 5 intends to make all markup interoperable. One can argue that every markup is willfully used. Following that path, validators/conformance checkers are completely unnecessary. HTML 5 validator could respond to every document with "Congratulations! Your document is... meh, whatever!" |
| 20:14 | <othermaciej> | I have also studied catholic dogmas to some extent |
| 20:15 | <qFox> | hi |
| 20:16 | <qFox> | video has no getImageData, does it? |
| 20:16 | <qFox> | like canvas does... |
| 20:16 | <gsnedders> | qFox: No, but you can write a video to a canvas |
| 20:16 | <Philip`> | qFox: No, but you can do canvas.drawImage(video) and then canvas.getImageData |
| 20:16 | <qFox> | yeah |
| 20:16 | <qFox> | my question was just, why doesn't video have or get it too? |
| 20:16 | Philip` | curses gsnedders |
| 20:16 | <qFox> | because now you have to paint it to a canvas first |
| 20:16 | gsnedders | beat Philip`! |
| 20:17 | <qFox> | unneccessary overhead for an action that'll probably done more than one cares for |
| 20:17 | <qFox> | +be |
| 20:17 | <qFox> | for any kind of frame processing, this overhead can add up. especially when ticks count |
| 20:18 | <qFox> | so i'm just wondering whether this has been brought up at all, and if so, what hte reasoning was behind it |
| 20:19 | <Philip`> | qFox: It seems likely that any processing you perform on the image data would be much more expensive than an extra blit onto a canvas, so it's probably not worth the specification/implementation complexity of adding API directly to <video> to optimise that step |
| 20:19 | <qFox> | ah well, but is it? i imagine that a blit is costly |
| 20:20 | <qFox> | and if the browser can easily blit video, i imagine that a simple getImageData on the video element shouldnt be much of a problem, at that stage |
| 20:20 | <qFox> | (or for any element, for that matter ;) |
| 20:21 | <qFox> | it just seems silly to have to create bogus canvas elements just to copy the video to get its pixels |
| 20:21 | <Philip`> | If you want to convince people that it's worthwhile on the basis of performance, you'd probably have to provide some profiling data that shows it's a real problem (and that it can't be fixed simply by optimising the implementation of drawImage(video)) |
| 20:22 | <qFox> | i guess this is where i lack the knowledge of implementation details of browsers. but is it really such a giant step to implement? |
| 20:22 | <Philip`> | (Maybe the data will indicate that it is worthwhile - I don't really have any idea) |
| 20:22 | <Philip`> | It's probably just a little step, but there's a million equally little steps that could be implemented too |
| 20:22 | <qFox> | (or rather, my lack of that knowledge comes into play..) |
| 20:22 | <gsnedders> | It's not the implementation difficulty that's the concern |
| 20:23 | <Philip`> | e.g. someone might want getImageData on <img>, and on <svg>, and might want toDataURL on all those things, and maybe they'll want to be able to draw a bit onto it too |
| 20:23 | <qFox> | ah, well, if you're offering.. :p |
| 20:23 | <qFox> | yeah i guess i understand |
| 20:24 | <qFox> | i'll have to create some tests then |
| 20:24 | <Philip`> | The current approach seems to be to try to minimise the API surface by having all the pixel-related operations exposed by <canvas>, which keeps everything relatively straightforward |
| 20:24 | <qFox> | luckily it was an area i wanted to focus on anyways (benchmarking) |
| 20:24 | <qFox> | okay |
| 20:24 | <qFox> | that's the explanation i was kind of expecting |
| 20:27 | <Philip`> | Maybe the best way to optimise video processing is to use WebGL fragment shaders |
| 20:27 | <Philip`> | rather than trying to get the data into JS faster |
| 20:27 | <qFox> | how well does firefox implement those in 3.6? not at all, right? |
| 20:28 | <qFox> | well, from a complexity perspective you're correct. the paints aren't the main concern. but it is one obvious step that most likely to be expensive |
| 20:28 | <Philip`> | It's unstable and only for experimental usage at the moment |
| 20:28 | <Philip`> | (Not sure which browsers (if any) have shipped experimental support yet) |
| 20:29 | <qFox> | i believe, not sure, that 3.7a has some support? or was it webkit... |
| 20:29 | <Philip`> | but it'll be available sooner than <video>.getImageData would be :-) |
| 20:29 | <qFox> | hehe |
| 20:29 | <qFox> | ahwell. no matter |
| 21:00 | <AryehGregor> | You know, threaded e-mail clients can get really confusing if people are talking about related things in different threads and you're reading through several days later. |
| 21:01 | <Dashiva> | Like talking about h264 in a thread about window.print()? |
| 21:04 | <jgraham> | gsnedders: I'm not sure many things made the ES5 spec had previous implementations |
| 21:10 | <JonathanNeal> | TabAtkins, how we doin'? |
| 21:12 | <eighty4> | isn't there any background-opacity setting for image based backgrounds? |
| 21:12 | <eighty4> | surely there must be? |
| 21:12 | <eighty4> | >< |
| 21:14 | <Hixie> | someone just asked me if i could reply to some questions about html5 |
| 21:14 | <Hixie> | they want to phone me (i have no phone) |
| 21:14 | <Hixie> | they kindly provided the questions... in msword format |
| 21:14 | <Hixie> | and they want the reply by march 15th |
| 21:15 | <Hixie> | there are so many things wrong with this i don't even know where to begin |
| 21:16 | <MikeSmith> | Hixie: send your replies as a TeX file |
| 21:16 | <zcorpan> | Hixie: which year? |
| 21:16 | <Hixie> | no year specified |
| 21:17 | <Hixie> | in fact it just said "3/15" (mail was dated today) |
| 21:17 | <zcorpan> | well then send the replies 2022 |
| 21:17 | <AryehGregor> | Hixie, I guess that's what really happens when journalists say "Mr. Smith did not respond to our request for comment by press time." |
| 21:17 | <Hixie> | the date honestly was the least of the problems in that e-mail |
| 21:17 | <Hixie> | sending me questions in some microsoft format was far worse |
| 21:18 | <zcorpan> | Hixie: i think there's some Google product that can grok microsoft formats |
| 21:18 | <AryehGregor> | Normal people probably don't even realize that .doc is a proprietary format. |
| 21:18 | <AryehGregor> | Why would they? |
| 21:18 | <Philip`> | 'strings' can read .doc files |
| 21:18 | <Philip`> | .docx is much harder :-( |
| 21:18 | <Hixie> | zcorpan: i can grok plain text |
| 21:18 | <MikeSmith> | I think normal people don't even have much awareness of what "proprietary format" even means |
| 21:19 | <AryehGregor> | Yes, that too. |
| 21:19 | <franksalim> | I think normal people don't have any awareness of what "format" means |
| 21:19 | <AryehGregor> | . . . possibly, yeah. |
| 21:19 | <zcorpan> | i think normal people don't have any awareness |
| 21:20 | <MikeSmith> | Hixie: just reply with a message saying, "Here are some clarifying questions I have based on your request.." and then just write up append some semi-random questions |
| 21:20 | <zcorpan> | quote a random selection from the faq |
| 21:21 | <MikeSmith> | yeah |
| 21:21 | <MikeSmith> | you could write an e-mail bot to do it for you |
| 21:21 | <AryehGregor> | Philip`, strings '/home/aryeh/Documents/school/ccny/ENGL 10100 Essay 3.2a.doc' | less gives me output like: hZID?5=XwaWY8.@DJ]DCA96/+*/32;@DC |
| 21:21 | Hixie | often copies and pastes from replies he sent to other journalists :-P |
| 21:22 | <Philip`> | AryehGregor: You have to skip that bit and find the part where it stores chunks of text |
| 21:22 | <MikeSmith> | or just reply with, "Please direct your questions to <name>, who I prefer to vet all requests of this type", and give them somebody else's name and e-mail address |
| 21:22 | <Philip`> | If you edited the file a lot then I suppose they might be a bit muddled up |
| 21:23 | <AryehGregor> | Philip`, there are 1456 lines and I looked at all of them. |
| 21:24 | <Philip`> | Maybe you need 'strings -el'? |
| 21:25 | <Philip`> | Or maybe they changed the file format since I last looked at it, which was probably last millennium |
| 21:26 | <AryehGregor> | -el works, nice. |
| 21:27 | <AryehGregor> | I should use strings more. |
| 21:30 | <zcorpan> | MikeSmith: should i file a bug about preload? |
| 21:31 | <MikeSmith> | zcorpan: nope, I filed one already |
| 21:31 | <MikeSmith> | and fixed it |
| 21:31 | <MikeSmith> | in the schema |
| 21:31 | <zcorpan> | k |
| 21:31 | <MikeSmith> | I'm fixing it in the markup doc now |
| 21:31 | <MikeSmith> | thanks for catching it |
| 21:43 | <TabAtkins> | JonathanNeal: Back! And not scribing! |
| 21:43 | <JonathanNeal> | Yay! |
| 21:43 | <TabAtkins> | So I'm still listening to the meeting, but I can actually concentrate on something else if necessary. |
| 21:43 | <TabAtkins> | So, what's the question? |
| 21:43 | <annevk> | Hixie, oh I got that email too... |
| 21:43 | <annevk> | Hixie, mine missed the attachment |
| 21:44 | <annevk> | (or maybe my mail client strips formats I dislike automatically, I wouldn't know) |
| 21:44 | <Hixie> | heh |
| 21:49 | zcorpan | looks at http://s.validator.nu/html5/media.rnc and gets confused |
| 21:50 | <zcorpan> | MikeSmith: that's the url the UI claims to use but doesn't match blackbox testing |
| 21:50 | <MikeSmith> | zcorpan: yeah, that's due to some build hackery I need to revert |
| 21:51 | <zcorpan> | MikeSmith: where can i see the schema that's actually used? |
| 21:51 | <MikeSmith> | I had thought http://s.validator.nu/html5/media-vnu.rnc would work |
| 21:51 | <MikeSmith> | but it appears not to |
| 21:52 | <MikeSmith> | it may be that it's not accessible except by v.nu itself |
| 21:53 | <MikeSmith> | fwiw, the reason I did this was in an attempt to improve reporting for required-but-missing attributes |
| 21:53 | <MikeSmith> | but it was a misguided approach |
| 21:54 | <MikeSmith> | and what we need to do instead is to patch jing |
| 21:54 | <zcorpan> | the schema on s.v.nu seems to be from 2008 |
| 21:54 | <MikeSmith> | I guess the files at those URLs are not relevant to actual v.nu behavior |
| 21:55 | <MikeSmith> | v.nu uses an internal resolver to de-reference them to the schema it uses internally |
| 21:56 | <JonathanNeal_> | TabAtkins, you were going to tell me about selectors. |
| 21:57 | <TabAtkins> | I was? I just saw a little bit of what you were talking about, and noted that no one was able to answer you properly. |
| 21:57 | <TabAtkins> | Could you reiterate what the issue was? |
| 21:57 | <JonathanNeal> | In the rendering section of the HTML5 spec, you don't mention that h2-h6 should also have their font-size and margin adjusted, you were going to tell me why. |
| 21:57 | <JonathanNeal> | http://sandbox.thewikies.com/html5-browser-stylesheets/table.html --- also, how do you feel about this formatting for the big browser css chart? |
| 21:59 | <TabAtkins> | That formatting seems cool. |
| 21:59 | <TabAtkins> | Re: h2-h6, they *should*, ideally, have their font-size and margin adjusted. Problem is that doing it right is damn near impossible to express in CSS. |
| 21:59 | <Nick_G> | we need a CL wit MC and SC, Category List with Main Categorys and Sub Categories \o/ |
| 22:00 | <jgraham> | AryehGregor: What's wrong with <strong style="color:red">. That is clearer and easier than using <strong> together with <font> for the style |
| 22:01 | <JonathanNeal> | TabAtkins, yes, but shouldn't it at least mention in the spec that the other elements will be affected? |
| 22:01 | <jgraham> | Which suggests that @style is less bad than <font> (because it combines more naturally with also picking the right markup) |
| 22:01 | <TabAtkins> | JonathanNeal: Yeah, it probably should. |
| 22:02 | <jgraham> | And a validator could chose to warn about <div style> or <span style> |
| 22:02 | <TabAtkins> | Ideally, what it would be able to say is just ":heading(1) { foo }, :heading(2) { foo }, etc.", but we can't do that. |
| 22:02 | <zcorpan> | that'd lead to people use other elements instead while still not caring about semantics or correctness |
| 22:04 | <jgraham> | True |
| 22:05 | <annevk> | TabAtkins, we can once Selectors 4 introduces them and HTML5 defines their semantics |
| 22:06 | <annevk> | (and then uses them to define their initial style rules) |
| 22:06 | <TabAtkins> | annevk: Yup. |
| 22:09 | zcorpan | wonders how to access complete.html when whatwg.org is out of reach for him |
| 22:11 | <JonathanNeal> | And the second question I had before was, why show the rendering guidelines for elements not in the html5 spec? |
| 22:14 | <jgraham> | Because interoperable behaviour from UAs is still needed |
| 22:18 | <JonathanNeal> | TabAtkins, you were gonna share that stylesheet php? |
| 22:18 | <TabAtkins> | JonathanNeal: What's your email? |
| 22:20 | <JonathanNeal> | jonathan t neal at gmail dot com |
| 22:29 | <TabAtkins> | JonathanNeal: Sent. |
| 22:29 | <TabAtkins> | I presume those spaces were to be removed? |
| 22:31 | <JonathanNeal> | yes and the at becomes an @ |
| 22:32 | <JonathanNeal> | and the dot becomes .... the declaration of independence. |
| 22:33 | <zcorpan> | what does com become? |
| 22:35 | <JonathanNeal> | zcorpan, you don't even wanna know. |
| 22:39 | <TabAtkins> | zcorpan: Council Of Magisters. |
| 22:43 | <krijnh> | Did somebody clever in here already come up with a solution for the new elements in IE wrt print stylesheets? |
| 22:45 | <TabAtkins> | Does the js hack not work for print stylesheets? |
| 22:45 | <paul_irish> | miketaylr was working on one earlier but was defeated. |
| 22:46 | <krijnh> | TabAtkins: nope |
| 22:46 | <TabAtkins> | hrm. |
| 22:46 | <krijnh> | Hacking around with expression: doesn't seem to work either |
| 22:48 | <paul_irish> | i can tell you JonathanNeal found that documentfragments that contain the new elements need the hack applied to them as well. |
| 22:48 | <JonathanNeal> | it's true |
| 22:50 | <TabAtkins> | Yeah, and I know that the hack doesn't work on innerHTML'd content. |
| 22:51 | <TabAtkins> | (or maybe it needs to be reapplied?) |
| 22:51 | <JonathanNeal> | TabAtkins, I tried swapping the json with a file_get_contents inside the json_decode, but it returns null. I read it could be the line returns, so I removed them, but it still returns null |
| 22:51 | <TabAtkins> | Your latest files have a ; at their end. You need to remove that. |
| 22:51 | <JonathanNeal> | TabAtkins, it does, as long as it is writing innerHTML to a pre-hacked document. |
| 22:52 | <JonathanNeal> | Soweet, that worked. |
| 22:52 | <TabAtkins> | I removed the linebreaks just to make it easier to read. It's not necessary to remove them. |
| 22:52 | <JonathanNeal> | Yes, but $values->ie6 = json_decode(rawurldecode(preg_replace('/\n|\r|\t/', '', file_get_contents('ie-6.js')))); reads really easily for me. |
| 22:52 | <TabAtkins> | Well, you can drop the preg_replace. |
| 23:11 | <AryehGregor> | jgraham, <strong style="color: red"> is preferable to <strong><font color=red>. However, it is only aesthetically and pedagogically preferable, and I don't think that's good enough reason to say the latter is non-conforming. A warning that there's a better way to do it would be appropriate, as I say. |
| 23:15 | <AryehGregor> | Of course, you can always debate what should be author conformance requirements and what should be up to validator authors. But that doesn't excuse inconsistency in the spec -- and IMO, the treatment of style="" vs. other inline presentational markup is grossly inconsistent. |
| 23:16 | <AryehGregor> | style="" is clearly not *that* superior to other presentational markup -- empirical evidence strongly suggests that authors believe some other elements/attributes are better (or at least as good) in some cases. |
| 23:16 | <Hixie> | style="" is only in the spec because of the ridiculous amount of complains we got when we removed it |
| 23:17 | <Hixie> | complaints, even |
| 23:17 | <Hixie> | and <font> is out because people complained when it was in |
| 23:17 | <Hixie> | originally i wanted to have just <font style=""> and only allow it for wysiwyg editors |
| 23:18 | <AryehGregor> | Well, now I'm complaining that it's out! Maybe if you make it obsolete but conforming you'll generate the fewest complaints. :) |
| 23:18 | <AryehGregor> | Realistically, inline style is useful sometimes. Sometimes you only want to use a style once. |
| 23:18 | <Hixie> | right, that's why we have style="" |
| 23:18 | <paul_irish> | or animation. |
| 23:18 | <AryehGregor> | Also, depending on your workflow it might just make more sense -- e.g., if you use a template-based HTML processor, then it might be just as easy to maintain, and more convenient in other ways. |
| 23:18 | <AryehGregor> | So I don't get all the hate. |
| 23:19 | <AryehGregor> | At worst, it hurts the author who uses it. The thing to object to is non-semantic markup, not inline style. |
| 23:19 | <AryehGregor> | The two issues seem to be conflated. You can use semantic and presentational markup together. External CSS is no less presentational than inline CSS. |
| 23:19 | <Hixie> | the hate is because while there are a few authors who are competent enough to use it, the overwhelming majority take it as a sign that html is a presentation language |
| 23:20 | <Hixie> | same reason that we disallow <b><i></b></i> -- sure, some experts can use it correctly |
| 23:20 | <Hixie> | most can't |
| 23:20 | <AryehGregor> | Any HTML author these days knows that CSS is necessary for presentation. You can't do even basic layouts without it, unless you use tables, in which case you are freaking insane. |
| 23:21 | <AryehGregor> | I'm pretty sure that almost no sites made in the last ten years don't use CSS. |
| 23:21 | <Hixie> | "any" dramatically overstates your case |
| 23:21 | <Hixie> | imho |
| 23:22 | <AryehGregor> | I usually try to be very careful not to overestimate the savviness of normal authors, but I'm pretty sure that even authors with extremely basic HTML knowledge understand that most styling is only possible with CSS. |
| 23:22 | <AryehGregor> | HTML styling is extremely limited, because no new features are being added to it. |
| 23:22 | <Hixie> | well if it's limited, why bother keeping any of it? |
| 23:22 | <Hixie> | i don't understand the use case for <font>, <big>, bgcolor="", etc |
| 23:23 | <AryehGregor> | Because existing pages use them, and it's annoying to say that to be valid the author has to exert significant effort that has no user-visible effect. |
| 23:23 | <AryehGregor> | Like xmlns="" or <img /> or whatever. |
| 23:24 | <AryehGregor> | Doesn't hurt anything much, compared to equivalent inline style. Except pedagogically, so a warning is appropriate for those who care, but an error will just make people not want to validate. |
| 23:27 | <TabAtkins> | This can be solved equally well by just having validators separate errors into importance groups. |
| 23:27 | <Hixie> | it's exactly those existing uses whose authors are clearly not already using css |
| 23:28 | <Hixie> | and those pages are typically an accessibility nightmare |
| 23:28 | <Hixie> | i really see no value in supporting those pages as is |
| 23:28 | <Hixie> | afk bbiab |
| 23:28 | <AryehGregor> | TabAtkins, that's what warning vs. error *is*. |
| 23:28 | <TabAtkins> | Sure. So what change is needed? |
| 23:29 | <AryehGregor> | TabAtkins, making legacy presentational stuff a warning instead of an error. |
| 23:29 | <AryehGregor> | Hixie, you seem to be arguing that the markup itself isn't bad, it's just correlated strongly with bad stuff, so we should ban the detectable bad stuff so that the undetectable bad stuff is probably flagged too. But that seems like a weak argument. Correlations like this tend to disappear when you push at them; the best we could hope for from banning presentational HTML is pages switching to CSS but still being inaccessible. |
| 23:30 | <AryehGregor> | There's no reason to think people will make their pages accessible if they switch to CSS, they'll just resort to divitis. |
| 23:30 | <TabAtkins> | Do you think that, were an inaccessible presentational-using site to upgrade, they'll just use only <div style> and <span style>? |
| 23:30 | <roc> | that's probably the cheapest option, so yes |
| 23:31 | <AryehGregor> | Either that, or they'll switch to divs and spans with classes. |
| 23:31 | <AryehGregor> | Which still doesn't help. |
| 23:31 | <AryehGregor> | Or they'll use tags like <strong> but misuse them. |
| 23:31 | <TabAtkins> | That last one is standard wysiwyg practice, anyway. |
| 23:31 | <AryehGregor> | Like they'll just replace <strike> by <del> everywhere. |
| 23:31 | <TabAtkins> | Also misusing <strong>. |
| 23:31 | <AryehGregor> | Yep. |
| 23:32 | <AryehGregor> | You're not going to fix accessibility problems by mandating a logically unrelated thing, even if presently that happens to be correlated. |
| 23:32 | <AryehGregor> | Most authors will do accessibility when either it's effortless, or there's immediate benefit to them. |
| 23:32 | <AryehGregor> | The latter is unlikely, and the former is very hard to engineer. |
| 23:33 | <TabAtkins> | I think that @style has an intrinsic benefit over the equivalent presentational markup, which I brought up on the list. |
| 23:33 | <TabAtkins> | Namely, that it uses CSS, which at least *exposed* that level of authors to CSS. |
| 23:33 | <TabAtkins> | s/exposed/exposes/ |
| 23:33 | <AryehGregor> | Yes, that's absolutely a benefit. A warning is enough to give that benefit, provided authors actually validate at all. |
| 23:34 | <TabAtkins> | Do you think that that level of author validates? |
| 23:34 | <AryehGregor> | No. So it doesn't matter what the spec says at all. |
| 23:34 | <AryehGregor> | They'll ignore all author conformance requirements. |
| 23:34 | <TabAtkins> | Sure, so let's do what we want and strike them for fun! |
| 23:34 | <TabAtkins> | (And profit, if possible.) |
| 23:34 | <AryehGregor> | . . . |
| 23:35 | <AryehGregor> | What about authors who know about validation and might validate if it were useful, but not if it's spammed with noise about things that they know aren't actually a problem? |
| 23:35 | <TabAtkins> | I challenge you to find a significant set of authors that match what you just described. |
| 23:35 | <AryehGregor> | What about authors who care about validation, but not enough to rewrite entire bodies of legacy content? |
| 23:36 | <TabAtkins> | Wait, so for that last one, are you recommending we let their legacy content validate just to make them happy? |
| 23:36 | <AryehGregor> | That's what we do in lots of cases, isn't it? |
| 23:36 | <AryehGregor> | xmlns="", <img />, etc. |
| 23:36 | <AryehGregor> | It's basically harmless. |
| 23:36 | <annevk> | it's different from misuse though |
| 23:36 | <TabAtkins> | That really is harmless, though. <img /> doesn't point to likely accessibility problems as well. |
| 23:37 | <Philip`> | It seems more useful to focus on improving the creation of new content, not the upgrading of legacy content, because there's a finite amount of legacy content and an infinite amount of future content |
| 23:37 | <AryehGregor> | TabAtkins, so are you really arguing we should ban markup because it's *correlated* with bad practices? |
| 23:37 | <Philip`> | (and most legacy content never gets upgraded anyway) |
| 23:37 | <TabAtkins> | Not by itself, no. But that's a contributing reason, yes. |
| 23:37 | <AryehGregor> | annevk, <font> isn't misuse, it was allowed by a decade of HTML standards. |
| 23:37 | <AryehGregor> | Philip`, that argues for validators not complaining too loudly about legacy markup, or what? |
| 23:38 | <AryehGregor> | TabAtkins, why is it even a contributing reason? |
| 23:38 | <TabAtkins> | AryehGregor: The latter. We should gear complaints toward encouraging better markup for new content. |
| 23:38 | <Philip`> | AryehGregor: It argues for designing validators to help authors who are writing new content, not to help authors who are checking or upgrading old content |
| 23:38 | <JonathanNeal> | TabAtkins, http://sandbox.thewikies.com/html5-browser-stylesheets/table.php |
| 23:38 | <TabAtkins> | TabAtkins: Because it correlates with bad practices? I'm not sure how I can explain that further. |
| 23:39 | <AryehGregor> | Philip`, it's not always so easy to separate. Content is often partly new and partly old. |
| 23:39 | <AryehGregor> | In MediaWiki's case, for instance, we can't ban presentational stuff in new pages. That breaks copy-paste, etc. |
| 23:39 | <Philip`> | TabAtkins: Talking to yourself? |
| 23:39 | <TabAtkins> | JonathanNeal: darker table-cell borders, please. I can't see the bordrs currently. |
| 23:39 | <JonathanNeal> | ok |
| 23:39 | <TabAtkins> | TabAtkins: Yes. |
| 23:42 | <annevk> | AryehGregor, a decade of wrong |
| 23:43 | <annevk> | AryehGregor, also, transitional meant it was going out |
| 23:52 | <JonathanNeal> | It's darker now, TabAtkins |
| 23:52 | <TabAtkins> | JonathanNeal: Is it intended that <head> and <ruby> don't have cells for ie7 and ie8? |
| 23:53 | <JonathanNeal> | That's actually a bug |
| 23:53 | <JonathanNeal> | only ie8 should have the styles. |
| 23:53 | <TabAtkins> | Also: something's wrong with your coalescing code. IE8 is never coalescing with ie6 and 7, even when it has the same styles. See <strong>, frex. |
| 23:54 | <TabAtkins> | Well, sometimes ie8 coalesces with ie7. But never with ie6 for some reason. |
| 23:56 | <JonathanNeal> | TabAtkins, fixed. |
| 23:56 | <TabAtkins> | head/ruby still broken, but coalescing good. |
){kind=link}