| 00:03 | <Philip`> | othermaciej: It seems the best existing hash functions are still only 'good enough' in terms of collision resistance, and nobody has come up with a theoretically perfect one that is still practical - SHA-256 is good enough for now, but it'll probably be warned against in ten years, and they'll have to come up with new ones to last a few more decades after that |
| 00:05 | <Philip`> | ...But I suppose I could be misreading "doesn't have even theoretical flaws" as being "doesn't have even the theoretical possibility of having any theoretical flaws", rather than "doesn't have any known theoretical flaws" (which current hash functions would satisfy) |
| 00:05 | <othermaciej> | yeah, I meant the latter |
| 00:06 | <othermaciej> | I am not sure it's possible to prove collision resistence in the sense that there is no way to beat the brute force attack |
| 00:06 | <Dashiva> | How about saying "Not flawed enough to be practically broken for the next five years" |
| 00:07 | <othermaciej> | that's impossible to predict |
| 00:08 | <Dashiva> | Well, assuming no quantum computers or other sudden major changes in computing power |
| 00:18 | <Philip`> | You could prove collision resistance in the sense that there's no better attack than brute force, and you can prove that for random oracles, and it seems to be a useful property (despite the unavoidable property that some inputs must collide); but no practical algorithm is (or ever will be?) that good, so it's not a very useful point :-) |
| 02:27 | <Hixie> | nickshanks: not many, and most that do have it have the blank value, iirc. but ask me again on friday if you want me to get you good numbers. |
| 02:28 | <Lachy> | good morning |
| 02:28 | <Hixie> | ih |
| 02:28 | <Hixie> | hi even |
| 02:28 | <nickshanks> | hixie: i will. what is happening between now and friday, another survey? |
| 02:30 | <Lachy> | Hixie, I found some broken things on your web site. These images are served as text/plain;charset=UTF-8, so not even content sniffing works |
| 02:30 | <Lachy> | http://ln.hixie.ch/media/diagrams/evolution/ |
| 02:37 | <Hixie> | nickshanks: no, csswg meeting, i won't be in my office until then |
| 02:37 | <Hixie> | Lachy: oops |
| 02:38 | <Hixie> | fixed. |
| 02:38 | <Lachy> | cool |
| 02:38 | <nickshanks> | oh, shame. I'd love to see an update of code.google.com/webstats |
| 02:38 | <Hixie> | yeah |
| 02:38 | <Hixie> | so would i |
| 02:38 | <Hixie> | but i'm too busy with whatwg and htmlwg to do something like that now |
| 02:39 | <nickshanks> | can you not just re-run the scripts from the first time, on some machine you're not using? |
| 02:39 | <nickshanks> | i'm sure there's a few eight-core intel Core 3's lying around GoogleHQ :) |
| 02:41 | <Lachy> | does anyone know if, in gmail, there's a way to delete thousands of e-mails all at once, instead of 20 at a time? |
| 02:42 | <othermaciej> | hello Hixie |
| 02:42 | <Hixie> | nickshanks: um. try to estimate how much time it would take to run a survey on a few billion documents. |
| 02:42 | <Hixie> | othermaciej: hi |
| 02:43 | <othermaciej> | Hixie: hyatt is definitely coming to the CSSWG meeting, I could come to part of one day if you think it would be useful |
| 02:43 | <Hixie> | it would be cool if you could come to hte tuesday dinner |
| 02:43 | <Hixie> | it's at zibibbo's, google is paying |
| 02:43 | <nickshanks> | hixie: yeah, i realise. maybe you could set up a CodeSurvey@Home project and farm it out to millions of internet zombies? |
| 02:43 | <othermaciej> | Hixie: I like free food |
| 02:44 | <Hixie> | nickshanks: be my guest :-) |
| 02:49 | <Hixie> | i really don't understand what problem is being solved by the version="" crap |
| 02:50 | <Lachy> | Hixie, there isn't any problem being solved, it's just a way for people to indicate they're using the latest and greatest standard. It's absolute nonsense |
| 02:51 | <webben> | or a testament to people's belief that future specs will break previous specs |
| 02:51 | <Lachy> | yeah, that too |
| 02:52 | <Lachy> | I suppose, XHTML 1 technically did that to HTML4 |
| 02:52 | <webben> | indeed |
| 02:52 | <Lachy> | and XHTML2 would have done that to XHTML1 |
| 02:52 | <othermaciej> | might be worth comparing to other document and programming languages, and whether they have a self-identification token |
| 02:52 | <othermaciej> | and if so whether it has been valuable or not |
| 02:52 | <webben> | programming languages aren't relevant i don't think |
| 02:52 | <webben> | document languages are |
| 02:52 | <Lachy> | DocBook does, but it doesn't seem valuable |
| 02:53 | <Hixie> | let's see... |
| 02:53 | <webben> | Word seems to be able to tell what version is being used. |
| 02:53 | <Hixie> | C++: no. Java: no. C: no. Pascal: no. Perl: no. Python: no. CSS: no. |
| 02:53 | <Hixie> | Word has versioning specifically to achieve something we're trying to avoid, vendor lock-in |
| 02:53 | <othermaciej> | C and C++ have version-based #defines, so you can check for a version from code |
| 02:53 | <Lachy> | JavaScript 1.2 and 1.5 are slightly incompatible |
| 02:54 | <othermaciej> | but there is no need or ability for code to declare its version |
| 02:54 | <webben> | i can see why programming langs would have no versioning and document langs would |
| 02:54 | <webben> | especially long-lasting, widely-distributed document langs |
| 02:54 | <Lachy> | FF checks for <script language=javascript1.2> |
| 02:54 | <Lachy> | or something like that |
| 02:54 | <Hixie> | othermaciej: really? language version, as opposed to UA version? |
| 02:55 | <othermaciej> | Hixie: calling a compiler a UA is kind of funny, but yes |
| 02:55 | <othermaciej> | you can tell if you are compiling as C89 or C99 |
| 02:55 | <Hixie> | Lachy: yeah and it's not in the script itself |
| 02:55 | <Hixie> | othermaciej: interesting. didn't know that. never seen anyone use it. (and yeah, a compiler is a user agent. :-) ) |
| 02:55 | <Lachy> | no, but it's in the HTML that uses the script, and there are many authors that don't know the differnece |
| 02:56 | <webben> | ODF has versioning |
| 02:56 | <othermaciej> | Hixie: if you want to analogize to the web architecture, it's more like a server-size processing step |
| 02:56 | <webben> | 2.1.2 of the ODF spec |
| 02:56 | <Hixie> | othermaciej: i guess |
| 02:56 | <webben> | http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office |
| 02:56 | <Hixie> | webben: i wouldn't use ODF as an example of a good spec either :-) |
| 02:57 | <webben> | rtf has versioning |
| 02:58 | <nickshanks> | hixie: do you at least have time to remove 'best viewed in FireFox 1.5' from code.google.com/webstats ? |
| 02:59 | <Hixie> | nickshanks: again, remind me friday |
| 02:59 | <Hixie> | (but doing that is a pain) |
| 02:59 | <webben> | i wish more of these specs were provided in a decent format like HTML |
| 03:00 | <Lachy> | does PDF have versions? |
| 03:00 | <Lachy> | I think it does, but not sure |
| 03:00 | <nickshanks> | SVG and XML have versions |
| 03:00 | <nickshanks> | as does apple PropertyList format |
| 03:00 | <Lachy> | XML shouldn't have versioning |
| 03:00 | <Hixie> | again, svg, not a language i'd use as an example of great design |
| 03:00 | <Hixie> | xml's versioning has already causd problems |
| 03:01 | <webben> | Lachy, I'm just downloading the giant PDF spec of PDF to check. |
| 03:01 | <webben> | (talk about putting the disadvantages of your format foot-forward) |
| 03:01 | <Lachy> | XML 1.1 is basically unusable, and future versions of XML should drop the version declaration |
| 03:01 | <othermaciej> | it's best to have a model for adding features in a backwards and forwards compatible way that does not require versioning |
| 03:02 | <nickshanks> | webben: that just shows up the UA's "download it all before you display the first page" lame PDF handling |
| 03:02 | <Hixie> | ok. looping. let's see. |
| 03:02 | <webben> | nickshanks, wouldn't be necessary if their plugin wasn't so crash-ready |
| 03:02 | <webben> | but i take your point |
| 03:03 | <webben> | othermaciej, Doing so is not necessarily incompatible with having versioning as a safeguard |
| 03:03 | <webben> | e.g. has any programming language managed to evolve in a 100% backwards compatible way? |
| 03:03 | <nickshanks> | if(random() < 5000) longjmp(NULL, 0); |
| 03:04 | <webben> | (VB until .NET maybe?) |
| 03:04 | <Hixie> | webben: pascal, through turbo pascal and then object pascal, did a pretty good job, 16bit to 32bit pointer migration notwithstanding |
| 03:05 | <webben> | Hixie, Ah. Neat. :) |
| 03:06 | <Hixie> | if current position=10, begin=5, end=9, loopbegin=6, loopend=8, and you call play(), what should happen? |
| 03:06 | <Hixie> | should it continue playing from t=10? |
| 03:06 | <Hixie> | seems like yes |
| 03:06 | <Hixie> | but then how do you start over at the start of the loop sequence? |
| 03:07 | <Hixie> | should we have a .restart() method or something? |
| 03:07 | <Hixie> | (called .loop() maybe?) |
| 03:07 | <nickshanks> | well in order to get to 10, it would have had to have received a seek() |
| 03:07 | <othermaciej> | Hixie: your position shouldn't be able to be outside the (begin, end) range |
| 03:07 | <nickshanks> | so it seems only reasonable that it would need another seek() to get abck |
| 03:08 | <othermaciej> | Hixie: think of it like clipping |
| 03:08 | <Hixie> | othermaciej: so if you dynamically set .end, and that puts .position outside the range, the playback has to stop and seek() to .end? |
| 03:08 | <othermaciej> | Hixie: I think that's the only sensible thing |
| 03:09 | <Hixie> | interesting |
| 03:09 | <Hixie> | still leaves the question of how you restart playback |
| 03:09 | <Hixie> | nickshanks: so you'd have media.seek(media.start); media.play();, with no shortcut for that? |
| 03:09 | <webben> | TEI has DTDs and so has versioning. |
| 03:10 | <webben> | Is there a document format without any versioning other than text/plain? |
| 03:10 | <nickshanks> | i don't think it really needs a shortcut, it's uite simple |
| 03:10 | <nickshanks> | *quite |
| 03:10 | <Hixie> | k |
| 03:10 | <Hixie> | webben: HTML5? :-) |
| 03:10 | <othermaciej> | Hixie: you would want to reset the current loop as well to totally restart playback |
| 03:10 | <Hixie> | yes |
| 03:11 | <Hixie> | media.currentLoop = 0; media.seek(media.start); media.play(); |
| 03:11 | <othermaciej> | Hixie: a co-worker of mine read the #whatwg IRC logs and pointed out a use case where you would want a controller to join an existing video element in arbitrary state |
| 03:11 | <Hixie> | oh? |
| 03:11 | <othermaciej> | (wildly changing topic) |
| 03:12 | <webben> | yeah that download finished. PDF has versioning too. |
| 03:12 | <othermaciej> | consider something like Keynote, where you may have a presentation slide with possibly several video objects embedded, and a floating "video info" window |
| 03:12 | <Hixie> | oh and you want to attach it to see why it failed to play? |
| 03:12 | <othermaciej> | web presentation progragms are certainly an obvious use case to think about, even though they go beyond just simple playback |
| 03:12 | <Hixie> | hm |
| 03:12 | <Hixie> | yeah |
| 03:12 | <Hixie> | you'd want more than just an error state then though |
| 03:13 | <Hixie> | you'd need error data too |
| 03:13 | <Hixie> | .lastError kind of thing |
| 03:13 | <othermaciej> | probably, yes, if the error event carries useful info |
| 03:13 | <Hixie> | i'll bear that in mind |
| 03:15 | <nickshanks> | it might be better to have a plugin that handles Content-URI: com.apple.keynote.presentation |
| 03:15 | <nickshanks> | rather than embedding it into HTML |
| 03:15 | <nickshanks> | oops, I mean UTI :-) |
| 03:16 | <Hixie> | he just meant if you implemented Keynote or something like that in HTML |
| 03:16 | <Hixie> | like s3 |
| 03:16 | <Hixie> | or s5 |
| 03:16 | <nickshanks> | oh right |
| 03:16 | <Hixie> | or whatever it's called |
| 03:16 | <Hixie> | othermaciej: so this makes updating these attributes difficult |
| 03:16 | <nickshanks> | meyerweb.com/eric/tools/s5/s5-intro.html |
| 03:17 | <Hixie> | othermaciej: you can't update all four of them at once if you're moving to a different part of the clip without checking which order to set them in |
| 03:17 | <Hixie> | othermaciej: unless we provide an interface for doing that |
| 03:17 | <Hixie> | like .setLoopParameters() |
| 03:17 | <othermaciej> | Hixie: ah, because end can't be before begin? |
| 03:17 | <Hixie> | yeah |
| 03:17 | <othermaciej> | you could allow that but treat it as an empty range |
| 03:18 | <Hixie> | hm, could do |
| 03:19 | <nickshanks> | what if i did seek(50); setEnd(30); setStart(10); |
| 03:19 | <Hixie> | you'd end up at position=30 |
| 03:19 | <Hixie> | assuming they were unset before |
| 03:20 | <othermaciej> | why is there even a seek method instead of position being read/write? |
| 03:20 | <nickshanks> | and play() would not do anything ? |
| 03:20 | <othermaciej> | hmm, seek appears to be relative if I am intepreting "offset" right |
| 03:20 | <Hixie> | seek isn't relaive |
| 03:21 | <Hixie> | it exists because originally i was going to have position only update once the seek had completed |
| 03:21 | <Hixie> | but since i changed that i guess now we can just remove seek() |
| 03:21 | <Hixie> | still, that doesn't affect this discussion |
| 03:21 | <othermaciej> | yeah, was just an aside |
| 03:21 | <nickshanks> | om has a point, you could use setPosition(int) for absolute, and advance(±int) for relative |
| 03:22 | <Hixie> | let's concentrate on these loop variables first |
| 03:22 | <Hixie> | so if currentLoop = 0, start <= position < loopEnd |
| 03:22 | <Hixie> | if 0 < currentLoop < loopCount, loopStart <= position < loopEnd |
| 03:23 | <Hixie> | if currentLoop == loopCount, loopStart <= position <= end |
| 03:23 | <Hixie> | right? |
| 03:23 | <othermaciej> | sounds about right |
| 03:23 | <Hixie> | and this needs to apply when seeking and when playback is occuring |
| 03:24 | <Hixie> | do we clamp on seek, or raise an exception? |
| 03:25 | <Hixie> | oh that was the other reason i had a method instead of a setter |
| 03:25 | <Hixie> | i didn't like the idea of invoking an event handler while in a setter |
| 03:25 | <Hixie> | i don't like heavy duty setters generally |
| 03:38 | <othermaciej> | DOM is full of them though |
| 03:40 | <Hixie> | yeah |
| 03:40 | <Hixie> | i try to learn from past mistakes :-P |
| 03:41 | <othermaciej> | well, getter / setter vs function is just a matter of syntax |
| 03:42 | <othermaciej> | I tend to find 0-arg getter functions and 1-arg setter functions to be unidiomatic in JS |
| 03:42 | <Hixie> | yeah |
| 03:44 | <othermaciej> | nearly the same to implement though, at least in our engine |
| 03:48 | <ericcarlson> | rewinding back to the discussion about what to do with play() when currentTime == duration: |
| 03:48 | <ericcarlson> | one option is to seek(startTime), emitting a timechanged event, before setting the rate |
| 03:50 | <ericcarlson> | FWIW this is what QuickTime has done since the dark ages (1991) |
| 03:51 | <nickshanks> | i would concur |
| 03:51 | <Hixie> | could you elaborate? |
| 03:51 | <Hixie> | i don't understand the proposal as described |
| 03:52 | <nickshanks> | when you're at the ned and you click play, it should go to the start and begin playing again |
| 03:52 | <nickshanks> | *ned -> end |
| 03:52 | <Hixie> | should it reset the loop count? |
| 03:53 | <ericcarlson> | good question |
| 03:53 | <Lachy> | yes, that's the behaviour a user would expect. |
| 03:53 | <nickshanks> | yeah, because in all likelyhood the loop count is at loopMax by this point anyway |
| 03:53 | <othermaciej> | if it's hit the max loop count, that would probably make sense |
| 03:54 | <Hixie> | i guess we could have 'play' act differently when ended==true than when ended==false, which is basically what you propose, right? |
| 03:54 | <Hixie> | that would work |
| 03:54 | <ericcarlson> | Yes |
| 03:54 | <Hixie> | ok |
| 03:54 | <othermaciej> | there's another relevant question here, which is whether position (or currentTime, which I personally like better) goes from startTime to endTime, or from 0 to (endTime - startTime) |
| 03:54 | <nickshanks> | play shouldn't act differently, no |
| 03:55 | <nickshanks> | oh, i see what you mean. i wa=s thinking you meant "lets play the movie differently the second time around" :-) |
| 03:55 | <ericcarlson> | startTime -> endTime because setting startTime doesn't change the media time line, |
| 03:56 | <ericcarlson> | only the point at which playback starts. |
| 03:56 | <nickshanks> | anyway, 4am here, going to sleep |
| 03:56 | <nickshanks> | night all |
| 03:57 | <othermaciej> | g'night nickshanks |
| 03:57 | <Hixie> | do end and loopend default to +INF or .duration? |
| 03:58 | <ericcarlson> | +INF so it is possible to detect that it has never been set. |
| 03:58 | <Hixie> | k |
| 13:07 | <hendry> | Lachy: i mentioned the two irc channels knowing of course we have two mailing lists. :) i wonder if we'll all settle on one. |
| 13:11 | <Lachy> | I'm sure there are some on the list who don't realise we have 2 lists, we seem to have a lot of newbies |
| 15:38 | <nickshanks> | hendry, Lachy: what is the other list and other channel? |
| 15:42 | <Lachy> | nickshanks, public-html and #html-wg on the W3C IRC server |
| 15:45 | <nickshanks> | there's more than one IRC server? nooooo freenode rules all! |
| 15:45 | <Lachy> | nickshanks, haven't you joined the HTMLWG? |
| 15:46 | <nickshanks> | irc://irc.w3.org/#html-wg |
| 15:46 | <Lachy> | that's the one |
| 15:46 | <nickshanks> | yes,m i did |
| 15:46 | <nickshanks> | (and i was just typing the link so i could click it |
| 15:46 | <nickshanks> | hmm, doesn't want to connect |
| 15:47 | <nickshanks> | is the port different? |
| 15:47 | <annevk> | yes |
| 15:47 | <annevk> | 6665 |
| 15:47 | <annevk> | iirc |
| 15:47 | <Lachy> | that's right |
| 15:47 | <annevk> | or just use 80 |
| 15:47 | <annevk> | that works as well |
| 15:48 | <Lachy> | is 6667 for W3C members only? |
| 15:48 | <annevk> | for the Team |
| 15:55 | <met_> | http://dbaron.org/log/2007-03#e20070325a |
| 15:55 | <annevk> | heh, <acronym> bugs are marked as spam already |
| 15:55 | <annevk> | s/bugs/mails/ |
| 15:56 | <annevk> | nickshanks, why bother implementing longdesc? |
| 15:56 | <annevk> | nickshanks, it's dropped from HTML5... |
| 15:57 | <webben> | what's the barrier to implementing longdesc? |
| 15:57 | <nickshanks> | well, first i wanted to add img[longdesc]:after { content: "Description: " attr(longdesc); } to my default CSS |
| 15:57 | <nickshanks> | then i discovered that :before and :aftrer don't work for replaced elements |
| 15:57 | <nickshanks> | so i went to look why |
| 15:58 | <webben> | or is the idea that <a> is a better solution? |
| 15:58 | <annevk> | attr(longdesc) seems pretty wrong |
| 15:58 | <webben> | and if so, how is <a> linked to the image as a longdesc? |
| 15:58 | <nickshanks> | and spotted a bug that safari wasn't treating longdesc as a url (i.e. it ignored <base href> and other things) |
| 15:58 | <annevk> | (longdesc is a URI iirc) |
| 15:59 | <nickshanks> | so i fixed that, and went on to see if i could add a contextual menu item to open the description in a new tab |
| 15:59 | <nickshanks> | anne: yes it's not a good solution at all, but I use it for blockquote[cite] too |
| 16:00 | <webben> | nickshanks: while you're at it, maybe you could do the same for cite? |
| 16:00 | <webben> | (ins, del, q, blockquote) |
| 16:00 | <nickshanks> | webben: you mean contextual menus? |
| 16:00 | annevk | thinks every browser should just drop support for longdesc |
| 16:00 | <nickshanks> | well i could, yes |
| 16:00 | <webben> | yeah, it works well as a context menu item |
| 16:00 | <annevk> | including the attribute etc. |
| 16:00 | <nickshanks> | anne: wikipedia uses it on every image |
| 16:00 | <annevk> | DOM attribute* |
| 16:01 | <annevk> | nickshanks, they also provide a link, no? |
| 16:01 | <nickshanks> | yep |
| 16:01 | <annevk> | which people actually use |
| 16:01 | <annevk> | as opposed to the longdesc thingie... |
| 16:01 | <nickshanks> | because longdesc is broken in 99% of UAs |
| 16:01 | <webben> | i wonder if Google indexes the longdesc links from Wikipedia for its image search |
| 16:01 | <annevk> | I don't think adding a contextmenu entry fixes it... |
| 16:02 | <webben> | annevk: Why? |
| 16:02 | <webben> | (well actually more important is exposing the longdesc to accessibility frameworks) |
| 16:02 | <nickshanks> | anne: the entry would only show up for images that had a description, it wouldn't be intrusive, and it would both improve accessibility and not harm backwards compatibility |
| 16:03 | <nickshanks> | webben: anything in the DOM is accessible to UI frameworks, is it not? |
| 16:04 | <annevk> | I don't think having hidden metadata improves the situation much. |
| 16:04 | <nickshanks> | my point is if it's there we might as well make use of it |
| 16:04 | <webben> | nickshanks: not really, no. A lot of the problems with screen readers relate to browsers exposing DOMs very partially to the accessibility frameworks. |
| 16:04 | <annevk> | we could add lots of attributes to elements that trigger contextmenu thingies, but I don't see that necessarily improving accessibility or something |
| 16:04 | <nickshanks> | whether it *ought* to be there or avaialble via another mechanism is a different discussian |
| 16:04 | <nickshanks> | on |
| 16:04 | <webben> | Mozilla is working on better exposure, which should translate into more advancing screen reading. |
| 16:05 | <webben> | (but even that is problematic; e.g. Mozilla dropping speech CSS so that Fire Vox has to reparse the CSS file to extract the relevant properties) |
| 16:07 | <nickshanks> | IIRC WebKit has to re-parse CSS for print and lay the page out again |
| 16:07 | <nickshanks> | even though it supports that nativly :( |
| 16:07 | <webben> | well that at least makes more sense |
| 16:08 | <annevk> | it doesn't |
| 16:08 | annevk | wonders why Hixie introduced content attributes with uppercase letters |
| 16:08 | <webben> | window-eyes supports longdesc: http://www.gwmicro.com/window-eyes/manual/html/index.html?19_10longdesc.htm |
| 16:08 | annevk | assumes it's an oversight |
| 16:09 | <webben> | JAWS supports longdesc: http://www.wats.ca/show.php?contentid=48 |
| 16:09 | <nickshanks> | JAWS is horrible :) |
| 16:10 | <webben> | nickshanks: Well sure. But IE is horrible and we run circles round that. |
| 16:10 | <annevk> | IE is actually used |
| 16:10 | <webben> | JAWS is (probably) the most popular screen reader |
| 16:10 | <nickshanks> | Actually I think VoiceOver is shitty too, but then it's only a 1.0 product |
| 16:11 | <nickshanks> | s/popular/common/ |
| 16:11 | <webben> | replacement accepted :) |
| 16:12 | <webben> | but i think we probably shouldn't ditch accessibility features supported by the most popular screen readers |
| 16:12 | annevk | isn't sure DOM2HTML is internally consistent |
| 16:12 | <webben> | or the most common ones either |
| 16:12 | <annevk> | .hreflang for instance |
| 16:13 | <annevk> | or .className versus .htmlFor |
| 16:17 | <nickshanks> | anne: btw I apologise if my recent emails to you have seemed a bit strong or disrespectful, that was not intentional |
| 16:19 | annevk | didn't really notice it... |
| 16:19 | <nickshanks> | cool :-) |
| 16:23 | <webben> | FS provide documentation in *.exe format. How very helpful. |
| 16:24 | <nickshanks> | heh: from the window-eyes web page on <abbr> and <acronym>: |
| 16:24 | <nickshanks> | <p><span style="font-family: 'Arial';">The Acronym and Abbreviation elements allow web page authors to indicate occurrences of abbreviations and acronyms. Acronyms are words formed from the first letters of each of the parts of the term (i.e. NATO, radar). Abbreviations are shortened forms of words (i.e. amt, lb).</span></p> |
| 16:25 | <nickshanks> | they don't even use the elements in the exact places they are supposed to be used :/ |
| 16:26 | <webben> | heh |
| 16:27 | <webben> | have you seen FS's markup? |
| 16:27 | <webben> | it's something else... |
| 16:27 | <nickshanks> | fs? |
| 16:27 | <webben> | sorry Freedom Scientific |
| 16:27 | <webben> | (they make JAWS) |
| 16:28 | <nickshanks> | i won't comment on their use of span and font-family… |
| 16:36 | annevk | wonders what the usecase is for loopStart |
| 16:36 | <annevk> | and if something like that is really needed, should it accept an array instead? |
| 16:38 | <nickshanks> | perhaps an int or array of length ≤ loopCount |
| 16:39 | <annevk> | if overloading works i suppose the feature isn't needed right away |
| 16:39 | <annevk> | also, I think it would be nice (as suggested in the minutes here) to replace .seek() with .position = x |
| 16:40 | <annevk> | that also allows you to skip with 20s using .position += 20 |
| 18:22 | <Hixie> | can XSLT really not output arbitrary text? |
| 18:22 | <Hixie> | i thought it could |
| 18:40 | <zcorpan> | <!doctype html public "html"> triggers quirks mode in at least gecko |
| 18:41 | <hasather> | Hixie: yes |
| 18:43 | <zcorpan> | <xsl:text disable-output-escaping="yes"><doctype html></xsl:text> i think |
| 18:43 | <hasather> | yea, that should do it |
| 18:44 | zcorpan | replies |
| 18:54 | <Hixie> | that's what i thought |
| 18:54 | <Hixie> | ok |
| 18:54 | <Hixie> | good |
| 18:54 | <Hixie> | glad we sorted that out |
| 18:54 | <Hixie> | http://www.w3.org/mid/A9925841-9449-4E5C-B149-EF07E1598735⊙if is the best anti-versioning e-mail i've seen this week |
| 18:55 | <zcorpan> | indeed |
| 18:55 | <hasather> | yep :) |
| 18:55 | <zcorpan> | i've del.icio.used it |
| 18:56 | <hasather> | BTW, I think Jirka meant that you can't output <!doctype html> with xsl:ouput, but that was not what he wrote |
| 18:56 | <hasather> | *xsl:output |
| 18:58 | <zcorpan> | then xslt should be updated so that it is possible to emit <!doctype html> with xsl:output. meanwhile there |
| 18:58 | <zcorpan> | 's a simple workaround |
| 18:58 | <hasather> | agreed |
| 18:58 | <zcorpan> | enter and ' are too close to eachother :( |
| 18:59 | <hasather> | agreed too |
| 19:09 | <met_> | tested <xsl:text disable-output-escaping="yes"><doctype html></xsl:text> in Saxon it works, but is nasty in XSLT world |
| 19:11 | <zcorpan> | allowing a public identifier in html5 because of *some* xslt processors not being able to emit <!doctype html> is nasty in html world |
| 19:11 | <met_> | some or better say all? |
| 19:12 | <zcorpan> | you said it worked in Saxon. julian said it didn't work in all xslt processors (being an optional feature, apparently) |
| 19:12 | met_ | oks |
| 19:14 | <zcorpan> | if you want to use xsl:output you can just emit the html4 strict doctype and be done with it |
| 19:19 | <met_> | but it's invalid HTML5, isn't? Although I suppose it will work in browsers. |
| 19:19 | <zcorpan> | yes and yes |