| 00:08 | <Philip`> | jgraham_: Indeed, that's fairly easy to find |
| 00:09 | <Philip`> | I see 1104K <img>s with missing alt, 531K with alt="", 12K with whitespace alt, 703K with non-whitespace alt |
| 01:20 | Hixie | laughs at Philip`'s e-mail |
| 01:24 | Philip` | just hopes nobody complains that the four percentages add up to 101% |
| 01:28 | <Hixie> | my dreamhost imap server is starting to be unbelievably slow |
| 01:28 | <Hixie> | maybe it is time for me to run my own imap server |
| 01:28 | <Philip`> | Maybe you have too many emails |
| 01:29 | <Hixie> | i've been getting rid of e-mails |
| 01:29 | <Hixie> | it has not helped |
| 01:29 | <Hixie> | it has gotten worse |
| 01:29 | <Philip`> | Maybe you have too few emails |
| 01:30 | <Hixie> | that seems unlikely as well |
| 01:37 | <Dashiva> | Maybe the server has started to pity you and seeks to shield you from further noise mail :) |
| 01:37 | <Lachy> | Hixie, since I moved to dreamhost, my IMAP has been incredibly slow too |
| 01:39 | <Lachy> | I assumed it was because of the trouble they were having with the "blingy" cluster that I'm on. It's improved a bit, but still slower than I'd like. |
| 01:39 | <Hixie> | i'm on looney |
| 01:39 | <Hixie> | i'm not affected by blingy |
| 01:39 | <Hixie> | i have sent a support request |
| 01:39 | <Hixie> | it certainly didn't use to be this slow |
| 02:07 | <Dashiva> | "Taking out the alt requirement will remove any pressure on flikr to fix this." -- because four years is such a short time |
| 02:18 | <Philip`> | http://philip.html5.org/data/alt-lengths.svg - the ylabel on that is now quite horribly long, but I can't think of anything conciser or less confusing :-/ |
| 02:19 | <Hixie> | heh |
| 02:20 | <Philip`> | Oh, the label falls off the top of the screen in Firefox - hooray for unpredictable text layout |
| 02:20 | <Hixie> | bit like the title of chapter 11 in the html5 spec |
| 02:21 | <Dashiva> | Philip`: What if you inverted the axes? |
| 02:21 | <Philip`> | Also the SVG fails to render most of its lines in Safari 3.0.something in Wine |
| 02:22 | <Philip`> | Dashiva: Then the curve would point upwards, which would be ugly, so I don't want to do that |
| 02:22 | <Dashiva> | Details :) |
| 02:22 | <Philip`> | and it wouldn't make the label text any shorter |
| 02:22 | <Philip`> | or any less confusing |
| 02:24 | <Dashiva> | Well, make it "Images with alt text at most this length" and explain which images are considered in a sentence below the graph? |
| 02:24 | <Philip`> | Um, I'm not quite sure how to add sentences below the graph |
| 02:24 | <Philip`> | (in Gnuplot) |
| 02:25 | <Hixie> | use html |
| 02:25 | <Dashiva> | Well, it could also be a box inside the plot, since it's mostly whitespace |
| 02:25 | <Dashiva> | And you might want to bring out the old logarithmic y scale, like you did for content-type. It's awfully close to 100% most of the time :) |
| 02:25 | <Philip`> | Hixie: Then I'd need at least two files, because I can't put SVG inline in HTML, and it would become a Big Project instead of just throwing up a file generated by the tool |
| 02:26 | <Philip`> | Dashiva: Putting a box inside the plot sounds even harder :-p |
| 02:26 | <Philip`> | I'd have to read the documentation, which is never easy |
| 02:27 | <Dashiva> | Philip`: How about generating it without the box and adding the box by hand? Just a textbox should be not too hard |
| 02:27 | <Hixie> | xhtml baby |
| 02:27 | <Philip`> | Dashiva: It's meant to be close to 100% all the time, since it's just indicating that pretty much all alt text is below that length, and nobody really cares about the details of precisely how many pages use 128 vs 256 characters of alt text |
| 02:28 | <Philip`> | or at least that's my excuse |
| 02:28 | <Philip`> | Also log scales going up to 100 are ugly, because 100 doesn't have nice roots |
| 02:28 | <Philip`> | (A 0,10,100 scale would be rubbish, and anything else will have fractions) |
| 02:28 | <Dashiva> | You do the inverse, 100 - x |
| 02:29 | <Philip`> | Anyway, I'm too lazy to even rename my file from charsets.gnuplot to alt-length.gnuplot, so I don't entirely feel like bothering with it too much :-p |
| 02:30 | <Philip`> | Dashiva: Adding things by hand is a pain because I'd have to re-add them by hand every time I regenerated the graph |
| 02:31 | <Philip`> | and also I'd have to read the SVG documentation to work out how to do it |
| 02:31 | <Dashiva> | Just google for svg text box, and make a script to sed the code block into the result file |
| 02:31 | <Dashiva> | Yeah, yeah, I know. Not going to happen :) |
| 02:31 | <Philip`> | Dashiva: That sounds suspiciously like hard work ;-) |
| 02:33 | <Philip`> | s/0,10,100/1,10,100/ |
| 02:34 | <othermaciej> | log scales should obviously be marked with powers of 2 |
| 02:34 | Philip` | hopes everybody's monitor is the same size as his, else the graph won't fit very well |
| 02:34 | <othermaciej> | what kind of loser would want powers of 10? |
| 02:34 | <othermaciej> | maybe a physicist or something |
| 02:35 | <othermaciej> | but we are computer scientists here |
| 02:35 | <Philip`> | othermaciej: When the range is 0..100, it's ugly if the scale doesn't end on 100 |
| 02:35 | <Philip`> | and 2 doesn't divide into 100 much |
| 02:36 | <othermaciej> | 128 is close enough |
| 02:36 | <othermaciej> | gotta quit for a bit, brb |
| 02:36 | <Philip`> | Makes it impossible for people to see that the curve flattens out at very nearly 100%, if the only markings are 64 and 128 |
| 02:37 | <Philip`> | and I can't add a horizontal line at 100% because I'd have to learn more Gnuplot |
| 02:42 | <Lachy> | given all this discussion about how trivial it is to perform history theft using :visited with various techniques, does anyone know if a real site has ever exploited it? |
| 02:47 | <roc> | I don't know of any such case |
| 04:40 | <Hixie> | Lachy: http://damowmow.com/playground/backups/CSS%20Tests/DOM/isVisited.html |
| 07:40 | <annevk> | Hixie, yeah, loading all backgrounds could work, but that's pretty bad on some sites |
| 07:41 | <Hixie> | so is rendering the site twice |
| 07:41 | <Hixie> | but opera did that! |
| 07:43 | <MikeSmith> | I think the rendering-twice thing is also something that Android Webkit does |
| 07:44 | <MikeSmith> | they call it "two-pass layout" |
| 07:44 | <MikeSmith> | I think there may be other browsers on mobile devices that still do that |
| 07:46 | <annevk> | Hixie, yeah, silly |
| 07:46 | <othermaciej> | that's totally different |
| 07:47 | <othermaciej> | Android doesn't build two versions of the layout at once |
| 07:47 | <othermaciej> | they force early layout before loading subresources, to show unstyled partial content as fast as possible |
| 07:47 | <othermaciej> | that's kind of similar to normal incremental layout during loading |
| 07:47 | <othermaciej> | dbaron's set of restrictions is the only thing I heard that is even close to working |
| 07:48 | <MikeSmith> | ah, Ok |
| 07:48 | <othermaciej> | and the background-color aspect seems so crippled as to be useless |
| 07:48 | <othermaciej> | and the color aspect might still be usable for timing attacks |
| 07:48 | <othermaciej> | trying to solve this problem is a pretty quixotic mission |
| 07:48 | <annevk> | om my god, why am i involved in a debate that's discussing fundamentally changing the way text/html works |
| 07:48 | <othermaciej> | also I am sick of Microsoft people saying "we have a way to do this" without saying how |
| 07:49 | <othermaciej> | annevk: well, at least initially, it was reasonable to assume the guy might not know the reasons that is not feasible |
| 07:49 | <annevk> | and of their: "We'll review it by next week!" |
| 07:49 | <othermaciej> | now that he knows, and is still arguing, I am not sure you need to continue |
| 07:49 | <annevk> | yeah, it seems other people took over anyway |
| 07:52 | <annevk> | hmm, SVG WG is starting from scratch again with SVG in text/html |
| 07:53 | <othermaciej> | awesome |
| 07:53 | <othermaciej> | I hope they will be able to bring their expertise in HTML parsing to bear |
| 07:53 | <heycam> | annevk, i want people to lay out their requirements/arguments so that it's clear where people are coming from |
| 07:57 | <Hixie> | i'm looking forward to seeing detailed proposals that fit in our constraints |
| 07:57 | <Hixie> | because frankly, if anyone can come up with something better, that would be awesome |
| 07:58 | <heycam> | Hixie, well i hope so. obviously you know much more about html parsing than anyone on the svg wg, though, and there'll be constraints that we're unaware of. |
| 07:59 | <Hixie> | iirc my reply to the svgwg covered the most salient ones |
| 07:59 | <heycam> | which reply? |
| 07:59 | <heycam> | the massive mail? |
| 08:00 | <Hixie> | http://lists.w3.org/Archives/Public/public-html/2008Apr/0407.html |
| 08:00 | <Hixie> | hm i guess i didn't give examples |
| 08:01 | <heycam> | yeah |
| 08:01 | <Hixie> | the massive mail gave more detail, including a bunch of urls worth studying |
| 08:01 | <Hixie> | my two favourites being: |
| 08:01 | <Hixie> | http://www.cocopahrv.com/map.html |
| 08:01 | <Hixie> | http://www.laroseweb.com/calcs/fans.php |
| 08:02 | <heycam> | that cocopahrv one is awesome, using an <img> inside the <svg> there :) |
| 08:04 | <heycam> | ok, so you would say that the tightest constraint is existing weirdo documents that use svg element names and expect their behaviour not to change |
| 08:04 | <heycam> | ? |
| 08:04 | <Hixie> | my favourite page of all time though is this one: |
| 08:04 | <Hixie> | http://puysl.com/view.htm |
| 08:04 | <Hixie> | that page is the epitomy of fail |
| 08:04 | <Hixie> | heycam: or at least, not to be significantly worse, yeah |
| 08:05 | <Hixie> | heycam: i put up with "shows a new blank space" |
| 08:05 | <Hixie> | heycam: in my proposal |
| 08:05 | <heycam> | given the resources you have in searching existing pages which we don't have, i expect that you'll have to knock back things we suggest with "but this'll break so-and-so page". |
| 08:06 | <Hixie> | yeah |
| 08:06 | <Hixie> | unfortunately doing those searches isn't exactly trivial |
| 08:06 | <hsivonen> | Hixie: your DOM link visitedness checker claims everything is visited in Firefox 3 |
| 08:06 | <Hixie> | hsivonen: oops |
| 08:06 | <Hixie> | hsivonen: well i haven't touched it since what, 2001? |
| 08:06 | <Hixie> | hsivonen: i just found it earlier today |
| 08:06 | <Hixie> | hsivonen: the url should be a giveaway as to its crustiness :-) |
| 08:08 | <Hixie> | i think i should print the source of http://puysl.com/view.htm and frame it |
| 08:08 | <hsivonen> | jf seems to be fixated on enforcement and placing the blame instead of improving accessibility |
| 08:08 | <othermaciej> | hsivonen: why are you so opposed to human rights? |
| 08:08 | <Hixie> | http://albren.blogspot.com/2007/02/l05-traductor.html is pretty awesome too |
| 08:09 | <othermaciej> | heycam: I'm curious if the SVG WG has identified specific problems with the approach that was in the spec |
| 08:09 | <othermaciej> | or if they plan to review it and identify specific problems |
| 08:11 | <heycam> | othermaciej, i do want to review the approach that was in the spec, and i don't know if the other WG members have looked at those parser changes, but i think mostly are reacting to high level summaries of the changes |
| 08:12 | <heycam> | i will make hixie's mega-mail required reading :) |
| 08:13 | <heycam> | i have a feeling that much of it comes down to "i don't want svg to have two syntaxes" vs "having an html-like syntax for svg as well is no problem" |
| 08:13 | <heycam> | (where that first claim is rooted in worries about existing tools) |
| 08:13 | <heycam> | (existing tools supporting on the XML syntax, that is) |
| 08:15 | <hsivonen> | heycam: I think the two syntaxes argument is totally misguided, since putting SVG in a text/html wrapper defeats existing tool ingest anyway |
| 08:15 | <hsivonen> | heycam: if you want to round trip your own stuff by copy and paste, you can |
| 08:15 | <heycam> | hsivonen, your own stuff, yes. the concern seems to be arbitrary svg-in-html content that you want to grab out and edit in inkscape, for example. |
| 08:15 | <heycam> | so not round tripping per se |
| 08:16 | <hsivonen> | heycam: if you want to extract someone else's content by copy and paste, doing it from the source instead of doing it from a reserialization isn't going to work |
| 08:16 | <Hixie> | if we put svg in text/html, and we allow that the pages cited above must continue to work, we are basically forced to conclude that we have to have non-draconian error recovery in the parser for the svg in text/html |
| 08:16 | <Hixie> | at which point, we have a new syntax |
| 08:16 | <Hixie> | i don't see any way around that |
| 08:16 | <hsivonen> | because a single well-formedness error would amount to copy protection |
| 08:16 | <Hixie> | so i don't see how to prevent their from being two syntaxes |
| 08:16 | <Hixie> | but like i said |
| 08:16 | <heycam> | hsivonen, that is obviously true, if the svg-in-html syntax isn't also xml syntax |
| 08:16 | <Hixie> | if the svgwg can come up with some magical way to do that, i'm all ears! |
| 08:17 | <hsivonen> | heycam: it won't be XML out there if text/html is non-Draconian |
| 08:17 | <hsivonen> | heycam: and text/html (even parts of it) cannot become Draconian without Breaking the Web |
| 08:17 | <hsivonen> | and having to Break the Web is a pretty serious deterrent from browser implementations |
| 08:17 | <Hixie> | we _already_ have svg in text/html that isn't parsable as image/svg+xml |
| 08:17 | <heycam> | hsivonen, only if it's defined that way. ok, the "breaking the web" part might stop that, though. |
| 08:18 | <Hixie> | that battle has already been lost, and it hasn't even begun |
| 08:18 | <heycam> | Hixie, but pages rely on that not rendering as svg, right? |
| 08:19 | <hsivonen> | so to me it seems that the SVG WG is either seeking to make its mark (bad) or hasn't come to terms with the Breaking the Web aspect of trying to put Draconian islands in text/html (bad as well) |
| 08:19 | <Hixie> | heycam: well, right now they do, yeah, though those i looked at could deal with them being rendered as 300x150 blank spaces (which is what would happen for most of them in my proposal) |
| 08:19 | <othermaciej> | adding draconian error handling that would break existing pages is indeed kryptonite for implementors |
| 08:19 | <heycam> | the issue would then be: if there's svg in text/html that IS parseable as image/svg+xml, and pages rely on that not rendering, then you have a problem in defining the svg-in-html syntax as xml. |
| 08:19 | <Hixie> | heycam: but anything that doesn't look like true svg isn't going to be svg either |
| 08:19 | <Hixie> | heycam: i don't follow what you just said |
| 08:20 | <heycam> | hsivonen, it could be that the "not breaking the web" requirement isn't properly understood by the wg |
| 08:20 | <heycam> | certainly i don't understand all of the constraints that hixie alluded to earlier, though the general problem i get |
| 08:22 | <Hixie> | well the constraints boil down to the pages i listed not breaking (where i accept some extra spacing, but not, say, an error message, or dropping half the page) |
| 08:22 | <heycam> | Hixie, is that list complete/representative? |
| 08:22 | <heycam> | of the problems that any workable solution would need to avoid? |
| 08:22 | <Hixie> | (oh that and ideally we should use the same mechanism for mathml and svg, and there are text/html pages out there that have raw mathml in them that would look great in the current proposal) |
| 08:23 | <Hixie> | heycam: certainly not complete |
| 08:23 | <Hixie> | heycam: probably representative, though, yeah |
| 08:23 | <heycam> | Hixie, ok. i hope that can reduce the number of iterations then. |
| 08:23 | <Hixie> | heycam: or at least, probably shows the extreme cases that, if dealt with, will mean the proposal is likely sound |
| 08:26 | <annevk> | I'd expect Doug to push for his <container> <fallback /> <svg /> </container> thingie |
| 08:27 | <Hixie> | the fallback idea doesn't work |
| 08:27 | <heycam> | annevk, the issue with that proposal is that it doesn't fall back in current UAs, yes? |
| 08:27 | <Hixie> | and <container> breaks in the copy/paste case |
| 08:27 | <heycam> | Hixie, why? |
| 08:27 | <Hixie> | heycam: two other constraints that are probably relevant: |
| 08:28 | <heycam> | (why can't the copy-and-paster just grab out the <svg> fragment from inside the <container>, that is?) |
| 08:28 | <Hixie> | first one is the one i mentioned earlier, namely that i'd like mathml and svg to use the same model, and there are pages out there that are basically text/html with mathml inline that would work great, so there's a strong motivation to use compatible syntax |
| 08:28 | <Hixie> | the other (and this is the answer to hte copy/paste thing) is more complex |
| 08:29 | <Hixie> | authors have, for some reason i haven't understood but which i have seen a _lot_ on the web, a weird way of working |
| 08:29 | <Hixie> | which consists of, sometimes, copying seemingly random chunks of pages |
| 08:29 | <Hixie> | and pasting them into their own |
| 08:30 | <hsivonen> | heycam: <container> sucks big time when there's a start tag near the top of the page and no end tag |
| 08:30 | <hsivonen> | <container> is also awful language design when we already have a solution without such cruft |
| 08:30 | <othermaciej> | is <container> supposed to be an island of draconian XML parsing? |
| 08:30 | <Hixie> | they will even copy stuff from pages where the stuff does something in one browser (e.g. firefox when that page is sent as xml), and paste them into their page where it does nothing (e.g. they're using IE) |
| 08:30 | <annevk> | othermaciej, I think so, yes |
| 08:31 | <Hixie> | for example, look at http://www.cocopahrv.com/map.html |
| 08:31 | <othermaciej> | well, I suppose if he finds a tagname that is actually for practical purposes unused, that might avoid breaking existing content |
| 08:31 | <Hixie> | or http://www.laroseweb.com/calcs/fans.php |
| 08:31 | <othermaciej> | but introducing draconianness to text/html misses the point of using text/html in the first place |
| 08:32 | <heycam> | othermaciej, so yeah... if the syntax can't be draconian in text/html, then the syntax must be different from xml. and if it's different, then it's impossible to make it always copy-and-pastable to inkscape. |
| 08:32 | <heycam> | so the requirements clash |
| 08:33 | <Hixie> | othermaciej: it doesn't work. even if the tag is unused now, in the time between UA 1 implementing the feature (and leading edge users using it) nad UA 4 implementing the feature (and thus all users having it) there will be millions of crackpot authors who copy and paste content from good authors targetting UA1 and expose that content to UA4 |
| 08:33 | <Hixie> | thus creating a pile of "legacy" content _after_ we define the syntax |
| 08:33 | <heycam> | Hixie, so why doesn't that apply to any solution that's though up? or any new html5 feature? |
| 08:33 | <Hixie> | this has already happened with svg and mathml in text/html, e.g. http://www.cocopahrv.com/map.html and http://www.laroseweb.com/calcs/fans.php |
| 08:34 | <othermaciej> | Hixie: well, I'm not a huge fan of draconianness independent of the Suport Existing Content constraint |
| 08:34 | <Hixie> | heycam: my proposal bails out of the new parse mode when it sees an html tag |
| 08:34 | <othermaciej> | heycam: I guess I don't understand the goal of putting SVG in text/html if draconian parsing is then required |
| 08:34 | <heycam> | othermaciej, ok |
| 08:34 | <Hixie> | heycam: and for the other new features, the features are simple enough that if this becomes a problem we can fix it relatively cheaply |
| 08:34 | <othermaciej> | if you want draconian parsing, you may as well use application/xhtml+xml |
| 08:35 | <othermaciej> | that will work fine in all current UAs that support SVG |
| 08:35 | <annevk> | (If the motivation for text/html in part is because of it's non-draconian nature having draconian handling for <foreignObject> blocks for instance doesn't make sense.) |
| 08:35 | <othermaciej> | and in the UA that doesn't, you won't get the draconian parsing in text/html with any more likelihood than you will get SVG |
| 08:36 | <heycam> | i wonder if there is a subset of authors who like the non-draconianness of html but are happy with svg syntax |
| 08:36 | <Hixie> | i do agree with othermaciej's point about not wanting draconian parsing in text/html on principle |
| 08:36 | <Hixie> | but it effectively doesn't matter given the technical problem with having draconian parsing in text/html |
| 08:36 | <heycam> | Hixie, what's the technical problem? |
| 08:36 | <othermaciej> | authors who would want draconian SVG parsing inside non-draconian HTML? |
| 08:37 | <heycam> | avoiding losing the rest of the page? (for existing content that opens an <svg> and doesn't close it, say?) |
| 08:37 | <othermaciej> | heycam: Hixie is right that crazy authors blindly copy random things |
| 08:37 | <othermaciej> | and test them only in browsers where they have no effect, but keep them anyway |
| 08:37 | <Hixie> | heycam: the one i described to you above from "the other (and" to "using IE)" and then explained to othermaciej again from "it doesn't work" to "this has already happened". |
| 08:38 | <heycam> | so basically because of that (authors randomally copying things), any syntax added to html MUST be non-draconian? |
| 08:38 | <hsivonen> | heycam: yes |
| 08:38 | <Hixie> | pretty much |
| 08:38 | <Hixie> | as far as i can tell |
| 08:38 | <Hixie> | i haven't formally proved that one implies the other, but i can't think of a solution where that's not the case |
| 08:38 | <othermaciej> | I'm not sure that phenomenon is quite as strong as Hixie thinks it is, but he has more knowledge on this subject and better judgment than me on such matters most of the time |
| 08:39 | <Hixie> | well, like i said, there are examples of this already today for both svg and mathml in text/html, and we haven't even shipped the first UA that supports that yet |
| 08:39 | <Hixie> | so |
| 08:39 | <othermaciej> | notwithstanding that, I can't think of anyone who would have a good reason to want draconian SVG in tolerant HTML |
| 08:39 | <hsivonen> | aaargh. William Hammond is suggesting the reparse with another parser approach |
| 08:39 | <othermaciej> | hsivonen: that's an old chestnut :-) |
| 08:39 | <Hixie> | hsivonen: if you reply please take whatwg off the cc list |
| 08:39 | <hsivonen> | we should have so kind of list of old bad ideas |
| 08:40 | <heycam> | othermaciej, i don't know that they would necessarily want the draconian svg, but they may want to avoid creating a second syntax |
| 08:40 | <hsivonen> | s/so/some/ |
| 08:40 | <Hixie> | i'm annoyed at half the thread being cc'ed to the whatwg list and the other half being caught in the moderation queue |
| 08:40 | <othermaciej> | heycam: they can already get the first syntax by using SVG only in XHTML |
| 08:40 | <heycam> | hsivonen, what's the issue with reparsing? that it blocks loading the whole rest of the page? |
| 08:41 | <othermaciej> | If they want to deny other people the ability to use a second syntax, I think the only solution is not to add SVG to HTML, because adding draconian SVG to HTML would defeat the use case of the people who want it pretty strongly |
| 08:41 | <heycam> | othermaciej, right, but they may be arguing against the non-draconian syntax in html to avoid creating a second syntax |
| 08:41 | <Hixie> | heycam: as i said at the start of this conversation, i see no way to include svg in text/html that doesn't forceably imply a new syntax, even in my wildest dreams |
| 08:41 | <heycam> | othermaciej, yeah |
| 08:41 | <othermaciej> | as one of the people who wants SVG in HTML, this makes me sad |
| 08:42 | <hsivonen> | heycam: it causes (potentially) scripts to run differently, you can't back out the side effects of scripts that already ran, it makes a small error cause non-obvious behavior totally elsewhere, it makes the prospective new browser slower than the legacy it is competing with |
| 08:42 | <othermaciej> | especially since the only syntax difference of substance is error handling |
| 08:42 | <heycam> | othermaciej, what makes you sad? the current solution being removed from the spec? or that a second syntax is needed? |
| 08:42 | <heycam> | hsivonen, ok |
| 08:43 | <othermaciej> | no, it makes me sad that some people want to deny me the ability to use a different syntax for SVG |
| 08:43 | <heycam> | othermaciej, ah |
| 08:43 | <othermaciej> | I wonder if the SVG WG has contacted the Efficient XML WG yet |
| 08:43 | <heycam> | :) |
| 08:43 | <annevk> | hmm, list of bad ideas: reparsing, href= on every element, draconian parser in text/html, namespaces in text/html |
| 08:43 | <othermaciej> | since they too have created a different syntax for SVG (a binary one, at that) |
| 08:44 | <heycam> | othermaciej, except nobody on the web uses that binary stuff |
| 08:44 | <heycam> | whereas this svg-in-html syntax would be used on the web |
| 08:44 | <annevk> | To be fair, Efficient XML doesn't constrain SVG |
| 08:44 | <othermaciej> | ah, so only a syntax that people might actually be *used* is a worry |
| 08:44 | <heycam> | othermaciej, i think so (if one's argument is that a second syntax is harmful) |
| 08:45 | <othermaciej> | then let's make the syntax bad enough that no one will want to use or implement it |
| 08:45 | <annevk> | Then again, using namespaces in HTML was already not possible and using <font> seems not necessary for small embedded graphics. (I hope people are not going to embed mebibytes of SVG!) |
| 08:45 | othermaciej | twitches at the mention of SVG fonts |
| 08:45 | <heycam> | annevk, what was the reason for <font> not working? |
| 08:46 | <annevk> | heycam, <font> is one of the HTML elements that lets you escape from the foreign lands |
| 08:46 | <annevk> | (with a parse error, alas) |
| 08:46 | <othermaciej> | annevk: my impression is that the concern is more about the additional looseness, not the additional constraints |
| 08:46 | <heycam> | so there were pages that used <font> in the html sense inside an <svg>-like fragment? |
| 08:46 | <othermaciej> | (that HTML documents might have inline SVG that you can't copy and paste into an SVG-only tool) |
| 08:46 | <Hixie> | any page using <font> in text/html today is using it in the html sense |
| 08:47 | <Hixie> | by definition |
| 08:47 | <heycam> | Hixie, right |
| 08:47 | <heycam> | because it would act like an html <font> |
| 08:47 | <heycam> | so there were pages that did have a <font> inside an svg fragment? |
| 08:47 | <heycam> | in your studies? |
| 08:47 | <annevk> | Hixie, well, the same could be said about <style> or <script>... |
| 08:47 | <Hixie> | yeah |
| 08:47 | <Hixie> | it was one of the highest occurances |
| 08:47 | <heycam> | annevk, at least style/script aren't too different though |
| 08:47 | <Hixie> | annevk: yeah but i didn't find any of those iirc |
| 08:48 | <annevk> | heycam, true, though I'm not entirely sure whether I like the different parsing model for them when used inside <svg> (or <math> for that matter) |
| 08:48 | <Hixie> | oh actually it looks like i did find some script and style |
| 08:48 | <Hixie> | i just decided to ignore those after looking at a sample of them |
| 08:48 | <heycam> | annevk, difference being CDATA 'n stuff? |
| 08:48 | <Hixie> | and deciding it would work either way |
| 08:48 | <Hixie> | i agree that it's a bit dodgy |
| 08:49 | <Hixie> | but we need impl experience for that one |
| 08:49 | <Hixie> | <font> iirc was very common (relatively speaking) |
| 08:49 | <annevk> | heycam, yes, <svg><script> alert("<foo/>") </scrip></svg> for instance... |
| 08:49 | <heycam> | annevk, ah |
| 08:49 | <othermaciej> | <script src> wouldn't work if treated as an svg script |
| 08:49 | <Hixie> | i should look for just that |
| 08:49 | <heycam> | othermaciej, ah right i forgot about src vs xlink:href |
| 08:50 | <Hixie> | i do find it annoying that svg did things differently to html |
| 08:50 | annevk | wonders when the SVG finally kills xlink:href |
| 08:50 | <Hixie> | the whole evt vs event thing for example |
| 08:50 | <Hixie> | or reusing tag names |
| 08:50 | <othermaciej> | well, SVG 1.2 semi-quasi fixed evt vs event |
| 08:50 | <Hixie> | the mathml wg did an amazing job of avoiding tag name clashes |
| 08:51 | <heycam> | Hixie, probably the idea that svg was in a different namespace quelled concerns about clashes with html |
| 08:51 | <Hixie> | out of their hundreds of tag names, they had one clash, and that one was with a non-existent tag name most people don't know about (<image>) and they've already offered to fix it |
| 08:51 | <othermaciej> | I think that was done out of ignorance, not willful creation of conflict |
| 08:51 | <Hixie> | othermaciej: sure, but at least one other group went out of its way not to do that |
| 08:51 | <othermaciej> | actually they even thought evt was mandated for some weird imaginary reason |
| 08:51 | <annevk> | Hixie, yes, but <image> is not a problem as it's not on the list of HTML elements... |
| 08:51 | <heycam> | othermaciej, right i'd imagine so. if the design up front was to have svg inline in html, well, things might've been different. |
| 08:51 | <annevk> | Hixie, or was that an oversight? |
| 08:51 | <othermaciej> | SVG WG could have actively tried to align with HTML from earlier on |
| 08:52 | <othermaciej> | I give them some credit for being more open to doing so now |
| 08:52 | <heycam> | i don't think any new svg element names have been minted since the new html wg has been around |
| 08:52 | <Hixie> | annevk: actually i have no idea if it's a problem, my parser does the image->img thing so i have no data on it :-/ |
| 08:53 | <Hixie> | yeah the htmlwg has been the one creating clashes |
| 08:53 | <Hixie> | with <video>, e.g. |
| 08:53 | <Hixie> | go me |
| 08:53 | <heycam> | :) |
| 08:54 | <othermaciej> | you could rename them hvideo and haudio |
| 08:54 | <Hixie> | i could... |
| 08:54 | <othermaciej> | I would hate you if you did |
| 08:54 | <othermaciej> | but you could do it |
| 08:54 | <Hixie> | not gonna :-) |
| 08:56 | <heycam> | <font> is non-conforming, yes? |
| 08:57 | <annevk> | it is currently |
| 08:58 | <hsivonen> | huh? <font> became non-conforming? |
| 08:59 | <hsivonen> | http://www.whatwg.org/specs/web-apps/current-work/#the-font |
| 08:59 | <annevk> | "Conformance checkers must consider this element to be non-conforming if it is used on a page lacking the WYSIWYG signature." |
| 09:01 | <othermaciej> | it's conformance status is not super relevant to the SVG-in-HTML issue |
| 09:01 | <heycam> | othermaciej, no |
| 09:02 | <heycam> | i just wanted to say something like "despite it being non-conforming, blah blah" |
| 09:04 | <hsivonen> | Hixie: can I assume that if you spec meta content-language, it will only apply if in "the head element"? |
| 09:04 | <Hixie> | how do you mean? |
| 09:05 | <Hixie> | heycam: <font>'s conforming status is up in the air, much like style=""'s |
| 09:05 | <Hixie> | heycam: i might just keep <font> around as a hook for style="" as separate from <span> |
| 09:05 | <hsivonen> | Hixie: presumably meta content-language would insert a language tag between HTTP and the root element lang in the language inheritance chain |
| 09:05 | heycam | likes style="", and doesn't think it's any worse than introducing a new CSS class just to handle that element's styling |
| 09:05 | <hsivonen> | Hixie: like base inserts the base URI between HTTP and the root element xml:base |
| 09:06 | <Hixie> | hsivonen: presumably, yes |
| 09:06 | <hsivonen> | Hixie: thanks |
| 09:06 | <Hixie> | hsivonen: though the content-language header takes multiple languages and has semantics that aren't really the same as lang="" and xml:lang="". |
| 09:06 | <Hixie> | hsivonen: so it's unclear what it should really do |
| 09:06 | <hsivonen> | ouch |
| 09:07 | <Hixie> | heycam: it's not especially worse. that's still bad. :-) |
| 09:07 | <hsivonen> | when it does have a single value, it seems to be used as an attempt to declare the main language of the document, though |
| 09:07 | <Hixie> | that does appear to be the practice, yes |
| 09:07 | <hsivonen> | IIRC, FrontPage stores the spell checker language there |
| 09:07 | <Hixie> | which is mostly (though not entirely) compatible with its defined meaning |
| 09:08 | <hsivonen> | the FrontPage behavior is good in the sense that the metadata has a visible effect |
| 09:09 | heycam | goes to have some dinner, is convinced that there's no solution to the svg-in-html issue that handles everyone's (conflicting) requirements |
| 09:10 | <Hixie> | did someone just blog about acid3 |
| 09:10 | <Hixie> | heycam: join the club :-) |
| 09:13 | <heycam> | Hixie's spidey-sense^Wgoogle-sense just tingled... |
| 09:14 | heycam | really /aways... |
| 09:17 | <Hixie> | oh i just asked that because my server's status page just swamped with acid3-related requests and my server's usage spiked painfully |
| 09:17 | <othermaciej> | I just saw a blog post that may indicate time travel |
| 09:17 | <othermaciej> | because apparently Apple just release Safari 1.1.1 |
| 09:23 | <hsivonen> | Hixie: you need to host your site in an elastic cloud :-) |
| 09:24 | <Hixie> | seems china just discovered acid3 |
| 09:25 | <Hixie> | oh i see |
| 09:25 | <Hixie> | the wasp thinks webkit and opera pass acid3 |
| 09:25 | <annevk> | it penetrated the big firewall? :) |
| 09:25 | <Hixie> | sigh |
| 09:28 | <annevk> | seems plenty of people pointed that out already |
| 09:30 | <annevk> | Damn't, i want my edit attribute! |
| 09:32 | hsivonen | hopes annevk was being sarcastic about XSD describing semantics |
| 09:32 | <Hixie> | who knows |
| 09:32 | <Hixie> | he was young back then |
| 09:32 | <Hixie> | :-D |
| 09:33 | <Hixie> | speaking of sarcasm, the forms task force sure is making a lot of progress |
| 09:35 | <Hixie> | i wish all of these folders could be dealt with as easily as ins/del |
| 09:37 | <sydbarrett74> | hi could someone tell me what channel is for libxml discussions? |
| 09:39 | <hsivonen> | Hixie: I presume the first content-language will count |
| 09:39 | <Hixie> | no idea |
| 09:39 | <hsivonen> | Hixie: but will the absence of the content attribute make the tag count as a failed attempt? |
| 09:39 | <Hixie> | no idea either |
| 09:40 | <Hixie> | however, your suggestions gain a lot of likelihood of turning into reality if you're the first one to suggest them on the list :-) |
| 09:40 | <Hixie> | ok bed time now |
| 09:40 | <Hixie> | nn |
| 09:40 | <hsivonen> | nn |
| 09:46 | <hsivonen> | Philip`: can I get http-equiv values out of http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/attr/http-equiv somehow? |
| 09:47 | <Philip`> | hsivonen: No |
| 09:47 | <Philip`> | hsivonen: though I can get the values easily from my ~130K pages |
| 09:48 | <annevk> | hsivonen, I have this book on XML Schema... so, not sure |
| 09:52 | <hsivonen> | Philip`: I was mainly looking for data about how common content-language is |
| 09:52 | <hsivonen> | that is, should the WG believe it is worth caring about |
| 09:53 | <hsivonen> | how does SVG text deal with RTL? |
| 09:54 | <hsivonen> | hmm. I see a direction attribute... |
| 09:54 | hsivonen | is really annoyed that the svg spec is split into many HTML files |
| 09:56 | <hsivonen> | hmm. SVG seems to treat direction as style rather that a datum tightly coupled with the text content |
| 10:00 | <Philip`> | hsivonen: Oh, it seems I've already done http://philip.html5.org/data/meta-http-equiv.txt |
| 10:01 | <Philip`> | which is hopefully good enough for this |
| 10:01 | <hsivonen> | Philip`: thanks |
| 10:45 | <hsivonen> | somehow I'm skeptical about RDF improving the online safety of children |
| 10:51 | <Lachy> | hsivonen, who claimed it would? |
| 10:52 | <annevk> | hsivonen, hmm, Firefox 3 does observe content-language for :lang() matching iirc... |
| 10:56 | <hsivonen> | Lachy: no one as far as I can tell. but it matters depending on whether POWDER is meant to improve safety for children or whether it is meant as a placebo to keep the FCC at bay |
| 10:58 | <Philip`> | A lot of people use <meta name=language> - is that meant to do anything? |
| 11:01 | <Philip`> | ("A lot" = half as many as use <meta http-equiv=content-language>) |
| 11:03 | <Philip`> | hsivonen: http://philip.html5.org/data/meta-http-equiv-content-language-values.txt might be relevant to something |
| 11:06 | <hsivonen> | Philip`: thanks |
| 11:08 | <hsivonen> | fr, be, ca, lu, ch |
| 11:09 | <hsivonen> | I used to joke that I was learning Belgian at school... |
| 11:12 | <Lachy> | Philip`, a lot of people use meta elements to provide useless meta data that does nothing in practice. |
| 11:13 | <hsivonen> | so HTML has dir=rtl and SVG has direction=rtl |
| 11:13 | <hsivonen> | does MathML have something equivalent? |
| 11:14 | <Lachy> | hsivonen, I wouldn't expect it too, since, AIUI, maths is supposed to be universal. So all cultures would write maths in the same way. |
| 11:15 | <hsivonen> | including mtext? |
| 11:15 | <Lachy> | I don't know |
| 11:15 | <Lachy> | I'm not an expert on mathml |
| 11:15 | <hsivonen> | though I suppose the directionality belongs on the enclosing XHTML paragraph |
| 11:18 | <hsivonen> | <foreignObject direction=rtl><p>Is this RTL?</p></foreignObject>? |
| 11:18 | <hsivonen> | (my guess is yes) |
| 11:18 | <Philip`> | Equations often have words in them (like long names of variables), and it doesn't seem impossible that people would write some in their native language, and would mix them with others written in English |
| 11:18 | <hsivonen> | Philip`: math text has commas and periods, though. |
| 11:19 | <Philip`> | (though I'd be surprised if LaTeX was any good at Hebrew or Arabic, so I don't know what people do in practice) |
| 11:50 | <hsivonen> | nice Mail.app crashing email on www-validator |
| 11:52 | <othermaciej> | yeah I noticed that |
| 11:52 | <othermaciej> | that'll be fun |
| 11:57 | <hsivonen> | soo, since CSS keywords are case-insensitive, is SVG direction attribute value case-insensitive? |
| 13:29 | <annevk> | Mathematics is not universal for at least number notation and all, I recently learned |
| 13:29 | <annevk> | (For some reason I thought that was standardized somehow internationally) |
| 13:30 | <Philip`> | http://www.google.com/gwt/n?u=http://philip.html5.org/misc/chars.html - even Google can't produce well-formed XML |
| 13:30 | <Philip`> | annevk: Even if it was standardised, it wouldn't be universal unless everyone actually followed the standard |
| 13:30 | <annevk> | hsivonen, http://www.w3.org/TR/MathML2/chapter3.html#presm.bidi |
| 13:33 | <Lachy> | annevk, I'm aware there are different number systems, but don't mathemeticians, physicists and other academics all use the same system now? |
| 13:37 | <annevk> | I don't know |
| 13:38 | <annevk> | hsivonen, reading further, "Right-to-left layout of mathematical formulas may be addressed in a future version of MathML." |
| 13:39 | <Philip`> | http://www.google.com/gwt/n?u=http%3A%2F%2Fcanvex.lazyilluminati.com%2Flatest_nocache - hmm, the ]> indicates that the XHTML-outputting Google proxy doesn't actually parse application/xhtml+xml pages as XML |
| 13:39 | <annevk> | hsivonen, though for the textual elements Unicode rules are followed |
| 13:40 | <annevk> | hsivonen, also, "The major additions in MathML 3 are support for bidirectional layout, ..." |
| 13:41 | <Philip`> | (Also http://www.google.com/gwt/n?u=%0c http://www.google.com/gwt/n?u=%ef%bf%bf ) |
| 13:42 | <annevk> | hsivonen, MathML 3 has a dir attribute compatible with HTML though it only applies to <math> and textual elements |
| 13:42 | <annevk> | hsivonen, http://www.w3.org/TR/MathML3/chapter3.html#presm.bidi |
| 15:21 | <annevk> | hmm, this ECMAScript "strict mode" seems kind of scary; are strict modes really useful in a language like ECMAScript or are they just introducing a flaw? |
| 15:21 | <annevk> | http://wiki.ecmascript.org/doku.php?id=meetings:minutes_apr_15_2008 |
| 15:23 | <Philip`> | Firefox has a "strict" JS mode that just (I think) causes warnings in some cases, like uses of undeclared global variables |
| 15:23 | <Philip`> | but it sounds like they're suggesting something different |
| 16:12 | <annevk> | Can anyone tell me if http://video.google.com/videoplay?docid=6204903272262158881 maps to "The Lost Levels" in some way? |
| 16:12 | <annevk> | Because that'd be crappy as I can't get that game on my Wii for some silly unspecified reason |
| 16:12 | <hsivonen> | annevk: thanks for the MathML pointer |
| 16:43 | zcorpan | ponders about role='dialog' and <dialog> |
| 16:43 | <zcorpan> | surely that's going to be confusing |
| 16:44 | <hsivonen> | I'd like to have pointers to Hebrew or Arabic pages with alt text that has punctuation |
| 16:45 | hsivonen | checks wikipedia |
| 16:47 | <Philip`> | hsivonen: http://www.lira.co.il http://www.biogal.co.il http://www.ntt.co.il/ http://www.madas.co.il http://www.volt.co.il http://www.taburit.co.il |
| 16:47 | <hsivonen> | Philip`: thanks |
| 16:48 | <hsivonen> | I tried obvious Israeli newspapers first, but the HTML was too terrible |
| 16:48 | Philip` | wonders what domain names have Arabic text |
| 16:49 | <hsivonen> | .sa, IIRC |
| 16:49 | <Philip`> | There's only one .sa page in my list |
| 16:50 | <Philip`> | http://www.fayoum.gov.eg/ sort of has punctuation |
| 16:52 | <Philip`> | http://www.sheikhmohammed.ae/ sort of has too |
| 16:53 | <Philip`> | I think dmoz.org is quite biased against Arabic :-( |
| 16:54 | <hsivonen> | I find an alarming proportion of iconic images not having width and height attributes |
| 16:54 | <hsivonen> | seems like a bad idea for incremental rendering |
| 16:55 | <krijnh> | annevk: thanks, will check it out |
| 16:57 | <zcorpan> | hsivonen: it appears that most authors don't care about good incremental rendering, or at least not enough to bother making it better |
| 16:58 | <Philip`> | The cost of adding width and height attributes to all images, and maintaining them for the rest of eternity, is too high |
| 18:12 | <Dashiva> | I wonder if there are people actively trying to make validation impractical so as to make it less used... that would be some conspiracy |
| 18:14 | <Philip`> | If half the people who currently validate give up because the validator complains too much, and the other half make their pages slightly better (e.g. by adding summary attributes) to please the validator, is that necessarily bad? |
| 18:16 | <Dashiva> | No, but it's unrealistic |
| 18:17 | <Dashiva> | The validation-based quality of sites is a slope, so there would be many sites who just manage to validate now who no longer bother, whereas the "very validating" sites would probably already have made the changes |
| 18:42 | <takkaria> | does no-one else find mail addressed to "IE8 Core AJAX SWAT Team" amusing? |
| 18:45 | <andersca> | Hixie? |
| 18:45 | annevk | feels sorry for Boris |
| 18:45 | annevk | is planning to address XHR comments after the LC deadline |
| 18:47 | <Hixie> | andersca: yo |
| 18:49 | <Philip`> | takkaria: I hope they have cool outfits |
| 18:57 | <andersca> | Hixie: hey |
| 18:57 | <andersca> | Hixie: so I think an exception should be raised when you call ApplicationCache.add with an invalid URL |
| 18:58 | <Hixie> | makes sense |
| 18:58 | <Hixie> | does the spec cover that case? |
| 19:00 | <annevk> | (Brawl is not available in The Netherlands, fwiw. Maybe Kam and all imported it? Seems weird for Norway to have it first...) |
| 19:00 | annevk | does own Mario Kart now |
| 19:01 | <andersca> | Hixie: no |
| 19:01 | <Hixie> | andersca: then yeah, raise an exception and mail the list, that should be a no-brained to fix |
| 19:01 | <Hixie> | no brainer even |
| 19:01 | <Hixie> | annevk: seems likely |
| 19:01 | <annevk> | please raise a SYNTAX_ERR |
| 19:02 | <Hixie> | annevk: there's an import games store in oslo |
| 19:02 | <annevk> | (that'd be compatible with XMLHttpRequest, anyway) |
| 19:02 | <annevk> | Hixie, ah right |
| 19:03 | <andersca> | annevk: yeah, that's what I"m doing |
| 19:09 | <annevk> | I wonder what "invalid" means though for URIs... User agents apply quite a bit of preprocessing on things that take URIs... |
| 19:09 | <annevk> | Guess we'll cover that eventually in URL5 |
| 19:10 | <andersca> | lol |
| 19:12 | <gsnedders> | How realistic are LEIRIs? |
| 19:12 | <Dashiva> | annevk: What about uri and iri? |
| 19:13 | <annevk> | Yeah, maybe it's better to adopt URI as term and encourage URL for whenever a technology needs to use the term (such as type="url" and url() in CSS)... |
| 19:14 | <annevk> | Dashiva, IRIs are covered by preprocessing as I understand it. They're simply syntactic sugar. |
| 19:21 | <hsivonen> | Philip`: Mediawiki should maintain the dimensions automatically on the Hebrew Wikipedia front page! |
| 20:35 | <Philip`> | http://webkit.org/blog/176/css-canvas-drawing/ |
| 20:51 | <virtuelv> | Hixie: re your mail to public webapi |
| 20:52 | <virtuelv> | has anyone made the author aware that mousewheel mostly works these days? |
| 20:53 | <virtuelv> | nevermind, gotta learn to read all of top-posted mails |
| 20:55 | <Hixie> | it might work |
| 20:55 | <Hixie> | it's not really specced yet |
| 20:55 | <virtuelv> | but with regard to the wheelDelta, that really needs to be standardized |
| 20:55 | <Hixie> | there's some work in that area, but i'm not sure if it's backwards compatible with legacy |
| 20:55 | <Hixie> | is it just me or did http://lists.w3.org/Archives/Public/public-html/2008Apr/0565.html miss the point utterly |
| 20:55 | <virtuelv> | my research so far suggests that the sane path to go is to normalize the wheel delta to +-1 |
| 20:59 | <annevk> | Hixie, I had the same feeling |
| 21:00 | <hsivonen> | Hixie: it's not just you |
| 21:02 | <hober> | yup, pretty much |
| 21:03 | <gsnedders> | +1 |
| 21:03 | <Philip`> | I'll disagree, just to make the discussion more balanced |
| 21:05 | <gsnedders> | Philip`: Good reasoning. |
| 21:05 | <Hixie> | ok good |
| 21:39 | <annevk> | Hixie, Opera at least expands unknown entities to "&" + entityname + ";" |
| 21:39 | <annevk> | Hixie, data:text/xml,<!DOCTYPE test PUBLIC "test" ""><test>&test;</test> |
| 21:41 | <Hixie> | the part of hte spec i changed is just talking about EntityReference nodes |
| 21:42 | <Hixie> | if the DOM doesn't end up with entity references nodes, then it doesn't apply |
| 21:43 | <annevk> | ah ok |
| 21:43 | <Hixie> | (at least that's my intent) |
| 21:43 | <annevk> | we make it a Text node during parsing it seems |
| 21:43 | <Hixie> | parsing unknown entities into text nodes that say &foo; seems a bit dubious from an xml compliance point of view |
| 21:43 | <annevk> | I don't think we support EntityReference nodes |
| 21:43 | <Hixie> | yeah no-one does |
| 21:43 | <Hixie> | it should be dropped in Web DOM 4 |
| 21:44 | <annevk> | The XML specification doesn't really cover that case really well I think... |
| 21:44 | <Hixie> | conveniently that's not my problem :-D |
| 21:45 | <annevk> | My XML5 alpha impl currently agrees with Opera as it seems reasonable fallback |
| 21:47 | <Hixie> | did dan and ben just suggest leaving the definitions of html elements to another working group |
| 21:47 | <jgraham__> | Yes. |
| 21:48 | <hober> | ayup |
| 21:48 | <hober> | the mind boggles |
| 21:49 | gsnedders | sighs: <http://twitter.com/mollydotcom/statuses/791366032>; |
| 21:49 | <jgraham__> | If we can get the SVG folks to define our parsing model, the a11y people to define all our elements then we just need to foist anything DOM-related off onto web-api and Hixie's out of a job |
| 21:49 | <hober> | yeah, sweet |
| 21:49 | <hober> | we can wrap up and go home |
| 21:50 | <Hixie> | that would be nice |
| 21:50 | <Hixie> | i could get back to css3 lists |
| 21:50 | <annevk> | Dan would say we could focus on tests ;) |
| 21:50 | <Hixie> | ok does anyone have any suggestion as to where i should define document.fgColor |
| 21:50 | <gsnedders> | But if the SVG folks are defining the parsing model, isn't that their job? |
| 21:50 | <Hixie> | should i put it in the Document IDL? |
| 21:50 | <Hixie> | or should i put it in some other section somewhere |
| 21:51 | <gsnedders> | Document IDL seems right. |
| 21:52 | <Hixie> | seems bad to be defining APIs we want everyone to ignore right there at the top of the spec though |
| 21:52 | <annevk> | Hixie, it depends on who the IDL is intended for... I thought they were for implementors but you argued otherwise... |
| 21:53 | <Hixie> | well i mean the idl and the definitions |
| 21:53 | <Hixie> | the whole kaboodle |
| 21:56 | <annevk> | some thoughts: each affected IDL/section gets a UA-only subsection || each affected IDL gets a "// UA-only" part with pointers to the rendering section || IDLs are duplicated in the "rendering" section |
| 21:56 | <annevk> | the first is useful for user agents but might not be good for authors |
| 21:57 | <annevk> | the second affects authors less and the last has some amount of duplication / complexity for UAs |
| 21:59 | <Hixie> | well we're going to have a way to say that one idl should be merged into another anyway |
| 21:59 | <annevk> | unless you pick option 1 or 2 |
| 21:59 | <annevk> | in which case they're already merged |
| 22:00 | <Hixie> | no i mean webidl is going to have a keyword or something that says "this idl should be merged into that one" |
| 22:00 | <Hixie> | so we can handle Command and the setTimeout idl |
| 22:01 | <annevk> | oops, sorry |
| 22:01 | <annevk> | i guess i prefer the last option as it makes it very clear they're not part of the language, at all |
| 22:02 | <Hixie> | that's what i'm doing |
| 22:02 | <Hixie> | just renamed "rendering" to "rendering and user agent behaviour" or some such |
| 22:03 | <annevk> | be careful with that, people might request you split everything up :) |
| 22:06 | <Hixie> | the great thing about the way the whatwg is set up |
| 22:07 | <Hixie> | is that saying "no" is an option |
| 22:09 | <annevk> | interesting, fgColor and bgColor simply reflect an attribute value |
| 22:09 | <hsivonen> | http://lists.w3.org/Archives/Public/www-archive/2008Apr/0056.html |
| 22:11 | <Hixie> | hsivonen: what about it? |
| 22:11 | <hsivonen> | from my point of view, the longest paragraph is true alone but seems to be written about the wrong person |
| 22:13 | <Hixie> | i'd like to point out how right i was in that quoted irc snippet, btw |
| 22:14 | <hsivonen> | indeed |
| 22:14 | <annevk> | it's unfortunate though that they see it as intentionally starting a flame war |
| 22:16 | <hober> | Given their inability to understand Hixie's intentions, is it any wonder they want to remove conformance requirements that hinge on the author's intent? |
| 22:20 | <Hixie> | personally i think if http://lists.w3.org/Archives/Public/public-html/2008Apr/0538.html represents the opinion of all the anti-missing-alt crowd, the discussion is doomed |
| 22:20 | <Hixie> | but it's not clear to me if that's just jf's opinion or if the others agree |
| 22:20 | <othermaciej> | I find the appeal to authority distasteful |
| 22:20 | <othermaciej> | notwithstanding the merits of the argument |
| 22:21 | <hsivonen> | I don't like appeal to authority, either |
| 22:22 | <gsnedders> | I mean, when it comes to accessibility, there are few I actually listen to. All the "experts" don't really know what it is like to use the AT day after day. For that reason, T.V. Ramen is one of the few I actually listen to on things like this. |
| 22:22 | <annevk> | Hixie, "user agent" and "user-agent" are both used |
| 22:23 | gsnedders | heads off before he's flamed to death for saying that |
| 22:23 | <billmason> | Someone's already probably blogging it. |
| 22:24 | <Hixie> | annevk: yes, "user agent" should be used when it is used as a known and "user-agent" when it is used as an adjective (roughly speaking) |
| 22:24 | <annevk> | s/known/noun/ ? |
| 22:24 | <Hixie> | er |
| 22:24 | <Hixie> | yes |
| 22:24 | <Hixie> | wtf is "known" doing there |
| 22:24 | <Hixie> | i didn't type that i swear |
| 22:25 | <annevk> | heh |
| 22:27 | <annevk> | Hixie, linkColor tries to point to link which obviously fails |
| 22:29 | <annevk> | " |
| 22:29 | <annevk> | If a reflecting DOM attribute is a DOMString but doesn't fall into any of the above categories, then the getting and setting must be done in a transparent, case-preserving manner." doesn't really cover what happens when the attribute is not there (or the element on which the attribute is supposedly specified) |
| 22:32 | <Hixie> | not sure what you mean about link |
| 22:33 | <annevk> | the IDL says linkColor but the attribute definition says link |
| 22:33 | <Hixie> | oh |
| 22:33 | <Hixie> | oops |
| 22:34 | <Hixie> | fixed |
| 22:34 | <annevk> | Hixie, maybe the part after XXX should be in <span> |
| 22:34 | <annevk> | XXX=<span>HTMLDocument</span> |
| 22:37 | <hsivonen> | oops. what made me think that people don't declare dimensions was a bug in my code... |
| 22:46 | <hsivonen> | Philip`: thanks for the Hebrew and Arabic pointers. I think I have RTL covered now. Those pages had some pretty bad markup. |
| 22:47 | <Philip`> | hsivonen: Pages with bad markup? It's shocking :-( |
| 22:49 | <annevk> | Hixie, elementFromPoint is http://dev.w3.org/csswg/cssom-view/#documentview-elementfrompoint |
| 22:49 | <Hixie> | oh awesome |
| 22:50 | <annevk> | though hit testing is not :) |
| 22:50 | <Hixie> | hm? |
| 22:50 | <othermaciej> | annevk: would you consider also adding a rangeFromPoint (gives collapsed range) or nodeAndOffsetFromPoint (maybe returns a two-element array or something) |
| 22:50 | <annevk> | elementFromPoint depends on hit testing, which I left undefined for now |
| 22:51 | <Hixie> | oh i see |
| 22:51 | <othermaciej> | annevk: we've had requests for hit testing for individual character offsets from a point |
| 22:51 | <othermaciej> | annevk: and I'd rather not just invent an API |
| 22:51 | <othermaciej> | (we have elementFromPoint already) |
| 22:51 | <annevk> | i like rangeFromPoint |
| 22:51 | <othermaciej> | Mozilla provides this info on events |
| 22:51 | <othermaciej> | but an API for it seems more useful and cleaner to me |
| 22:52 | <roc> | yeah |
| 22:52 | <roc> | elementFromPoint should really have taken floats |
| 22:52 | <roc> | oh well |
| 22:52 | <Hixie> | annevk: i have a big open issue on event transparency |
| 22:52 | <Hixie> | roc: the whole platform screws that up |
| 22:52 | <othermaciej> | is there a reason elementFromPoint can't take floats? |
| 22:52 | <Hixie> | roc: we use integers for coordinates throughout |
| 22:52 | <othermaciej> | implementations that don't do float layout could just round |
| 22:52 | <roc> | not in getBoundingClientRect |
| 22:52 | <Hixie> | roc: e.g. you can't even get a float out of the event that gives you the mouse coords |
| 22:53 | <roc> | othermaciej: maybe, if IE doesn't barf if you pass it floats |
| 22:53 | <Hixie> | annevk: which will also depend on hit testing |
| 22:53 | <Hixie> | annevk: in a ridiculously complicated way |
| 22:53 | <annevk> | Hixie, i've seen that IE stuff |
| 22:53 | <annevk> | and it kind of makes sense for authors, but it's indeed something I rather not specified as part of that draft :) |
| 22:54 | <roc> | I like rangeFromPoint too |
| 22:54 | annevk | checks if IE7 allows floats |
| 22:54 | <roc> | although it's a little counterintuitive |
| 22:54 | <roc> | maybe it should give you the character cell that contains the float |
| 22:55 | <roc> | so a range from (node, index) to (node, index+1) if you're over a character |
| 22:55 | <roc> | or even (index+n) if you're over a cluster |
| 22:56 | <annevk> | seems we can change elementFromPoint to take floats |
| 22:56 | <roc> | we provide character offset information in events? News to me |
| 22:57 | roc | wonders if he can get that change into Gecko at this stage |
| 22:58 | <Hixie> | hm? |
| 22:58 | <roc> | hm what? |
| 22:59 | <annevk> | would rangeFromPoint always return the empty range? also if there's some selection at the specified location? |
| 22:59 | <Hixie> | who provides character offset information in events? |
| 23:00 | <annevk> | Gecko per othermaciej |
| 23:00 | <Hixie> | oh, i see |
| 23:00 | <Hixie> | huh |
| 23:00 | <Hixie> | didn't know that |
| 23:00 | <roc> | I think Maciej said we do. I don't think so, although I could be wrong |
| 23:00 | <Hixie> | annevk: i like roc's idea of returning the smallest range that contains the pixel (typically one character) |
| 23:02 | <annevk> | and the empty string when there's no character present I suppose? |
| 23:03 | <roc> | hmm? |
| 23:03 | <roc> | what do you mean "no character present"? |
| 23:03 | <roc> | I think we always return the document element at least |
| 23:04 | <annevk> | yeah, but that's not a range :) |
| 23:04 | <roc> | but you can return a range containing the document element |
| 23:04 | annevk | was still discussing rangeFromPoint |
| 23:04 | <annevk> | I see |
| 23:06 | <Hixie> | or maybe it would be more useful to return a range that represents where you'd put the caret if you were an editor |
| 23:06 | <Hixie> | i'm not sure what the use cases are |
| 23:07 | <Hixie> | bbl |
| 23:08 | <othermaciej> | roc: someone from Google told me so, but I could be wrong |
| 23:08 | <roc> | when you're doing drag selection, for example, you sometimes want to put the caret after the character (cluster) under the mouse, sometimes before |
| 23:08 | <roc> | so providing the range actually is best, because you can choose which end to put the caret at |
| 23:08 | <othermaciej> | googling for mozilla event.rangeParent finds some hits |
| 23:08 | <roc> | although it gets messy with RTL |
| 23:09 | <othermaciej> | (I forget what the corresponding offset property was named) |
| 23:09 | <roc> | othermaciej: ah! |
| 23:09 | <roc> | rangeOffset |
| 23:09 | <roc> | thanks |
| 23:10 | <roc> | I guess you can figure out the actual directionality of things using range.getClientRects |
| 23:11 | <annevk> | IE has TextRange.moveToPoint() |
| 23:11 | <othermaciej> | I think it would be nice not to depend on TextRange |
| 23:11 | <othermaciej> | since implementing TextRange may actually be a compatibility hazard |
| 23:11 | <annevk> | well, we could have Range.moveToPoint() |
| 23:11 | <othermaciej> | because editing libraries feature-test for it |
| 23:12 | <othermaciej> | I think rangeFromPoint is a better API design |
| 23:12 | <annevk> | does make sense given elementFromPoint |
| 23:13 | <annevk> | (though both are IE inventions :) ) |
| 23:14 | <othermaciej> | in a way it would make more sense for hit testing to be on the Window rather than Document (since it is the view object) but the DOM isn't really that good about model-view separation and adding global functions sucks |
| 23:15 | <othermaciej> | but certainly it makes more sense to say you are hit testing against a document than for hit testing to be a feature of ranges that happens to work against the implied document associated with the range |
| 23:15 | <annevk> | the DOM actually might be, but all the proprietary stuff isn't (and is more convenient now and then, consider getComputedStyle versus currentStyle) |
| 23:16 | <annevk> | ok, the question that remains is how to define it properly |
| 23:16 | <roc> | the model-view separation blew up some time ago |
| 23:17 | <roc> | consider, oh, getBoundingClientRect |
| 23:17 | <roc> | and its evil ancestors |
| 23:18 | <othermaciej> | rangeFromPoint could give a collapsed range when you aren't in text, and a one-char range if you are |
| 23:18 | <othermaciej> | (not sure which of these categories applies to clicking in, say, the margin of a paragraph left of a line) |
| 23:18 | <annevk> | selecting the element seems fine too (as far as I'm concerned) |
| 23:18 | <othermaciej> | or you could just give a collapsed range for nearest char boundary |
| 23:19 | <othermaciej> | selecting the whole element? even if it has text contents? |
| 23:19 | <roc> | hmm |
| 23:19 | <othermaciej> | that defeats the use case for this API |
| 23:19 | <othermaciej> | which is hit testing down to a char offset |
| 23:19 | <annevk> | well, what's selected depends on the target node |
| 23:19 | <roc> | that's a good point |
| 23:20 | <roc> | I'm not sure how to spec what you want though |
| 23:20 | <othermaciej> | people want to use this for things like processing a click on non-editable text, getting the position where the caret would have gone had the text been editable, and then replacing the text with a contentEditable area or textarea or designMode iframe |
| 23:20 | <othermaciej> | and then place the caret in the right spot in the new thing |
| 23:20 | <annevk> | i guess if the target node is a text node you do magic and otherwise you create a range for the target element... |
| 23:21 | <roc> | also things like "find the word that you clicked on and do something with it" |
| 23:22 | <othermaciej> | nick om_afk |
| 23:22 | <othermaciej> | dammit |
| 23:22 | <roc> | I think Maciej wants the ability to detect a click in the left margin and find the text at the start of the adjacent line |
| 23:25 | <annevk> | that seems kind of tricky |
| 23:25 | <annevk> | that would not just be hit testing, but also involve layout calculations |
| 23:26 | <bkardell> | Hey - I was curious about this: The whatwg faq says "HTML 5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript. " |
| 23:27 | <annevk> | i guess that's the case Hixie brought up |
| 23:27 | <bkardell> | can someone clarrify that? Is the idea to use like some pseudo xbl implementation? |
| 23:28 | <annevk> | bkardell, not XBL per se, script libraries that implement features in IE, such as IECanvas, count |
| 23:28 | <bkardell> | how would you simulate <canvas> for example in ie? via script? plugin? |
| 23:28 | <Philip`> | bkardell: http://excanvas.sourceforge.net/ |
| 23:28 | <Philip`> | which uses script to produce VML which IE can render |
| 23:28 | <annevk> | (I just said: _script_ libraries :) ) |
| 23:30 | <bkardell> | yeah - so followup question on that... |
| 23:31 | <bkardell> | has anyone considered introducing some way of making those kinds of things any easier? |
| 23:31 | <Philip`> | Making it easier to write script libraries that emulate features in IE? |
| 23:31 | <hsivonen> | I started a new UI text wiki page: http://wiki.whatwg.org/wiki/Validator.nu_alt_advice |
| 23:31 | <bkardell> | especially given history and IE's particular ability to prevent really widespread adoption by just controlling too much marketshare |
| 23:32 | <hsivonen> | it will be hard to write good advice that fits in the UI |
| 23:32 | <Philip`> | I'm not sure how that would work - every case seems to be sufficiently different that it's not worth trying to make a common framework for all the cases |
| 23:32 | <bkardell> | it could really be any vendor though - not limited exclusively to ie |
| 23:33 | <bkardell> | let me give an _extremely_ simple example of what I'm talking about |
| 23:34 | <annevk> | So I'm not going to define rangeFromPoint in a few minutes after all it seems :) There seem to be two ideas so far: 1) nearest char or otherwise element. 2) the place you'd insert the cursor if the document was editable |
| 23:34 | <annevk> | I guess the 2 covers more use cases |
| 23:34 | <annevk> | 2nd* |
| 23:35 | <bkardell> | pretty much every vendor agrees to how events are registered -- except ie |
| 23:35 | <bkardell> | so people have to write it both ways |
| 23:37 | <bkardell> | has there been any discussion or thought on how to remedy that? Other than to say "ie violates the rec" - which appears to not bother them too much |
| 23:37 | <annevk> | they've stated that they'll fix that in due course |
| 23:37 | <bkardell> | lol |
| 23:38 | <bkardell> | (literally I _am_ laughing out loud) |
| 23:38 | <annevk> | anyway, again, there are libraries |
| 23:38 | <bkardell> | even within the realm of following the rec - sometimes there are admittedly different implementations which do more or less follow the spec |
| 23:39 | <bkardell> | again - every script has to make the same accomodations |
| 23:39 | <bkardell> | yes - there are libraries |
| 23:40 | <bkardell> | that's what I'm asking I guess... the idea would be that in the meantime you'll have to pick a good library? |
| 23:41 | <annevk> | basically |
| 23:41 | <Philip`> | You could always pick a bad library instead |
| 23:41 | <bkardell> | nice! |
| 23:42 | <bkardell> | good idea phillip! I picked a bad browser might as well pick a bad library too ;) |
| 23:44 | <roc> | annevk: the IE team stated they'll do DOM2 events? |
| 23:46 | <annevk> | they said as much during some Web API telcon yes, but they didn't give specifics so I guess not for IE8 |
| 23:46 | <roc> | I saw a post from one of their people about DOM2 events so I thought they might be interested |
| 23:46 | <roc> | I guess I'd like to know if it's for IE8 :-) |
| 23:47 | <roc> | supporting both event models would not be fun for them |
| 23:47 | <Philip`> | They can solve that by using the incompatibility switch |
| 23:48 | <roc> | I guess but internally, it's going to suck |
| 23:49 | <Philip`> | It's a web browser, so I'd guess they're used to that |
| 23:49 | <roc> | there's levels of suck :-) |
