00:00
<annevk>
browsers should follow that roughly (with the caveats mentioned earlier)
00:01
<annevk>
when that's integrated with HTML5 it will be more detailed I suspect although it's pretty clear already
01:30
<zcorpan_>
"It adds semantic richness, and that's valuable for its own sake" -- http://www.sitepoint.com/forums/showthread.php?p=3413761#post3413761
01:33
<Philip`>
The unquoted second part of that sentence doesn't seem to agree with the first part, since it talks about adding semantic richness for the sake of enhanced behaviour from future UAs instead of just for its own sake
01:34
<zcorpan_>
yeah
01:34
<zcorpan_>
indeed
01:34
<Philip`>
That's still a kind of tenuous theoretical sake, though
01:35
<om_food>
rel vs. rev is so brain-hurtingly confusing
01:37
<Philip`>
Need to work on a Brain 5, to fix the problems that today's legacy brains have with understanding really complex things
01:38
<zcorpan_>
Brain 5 must be backwards compatible, otherwise it won't be adopted
01:43
<karlUshi>
om_food: what is the result of "7./2."?
01:45
<karlUshi>
there's a new apple member in the HTML WG. Adam Roben
01:45
<karlUshi>
http://www.w3.org/2000/09/dbwg/details?group=40318&public=1&order=org
01:45
<othermaciej>
karlUshi: 3.5?
01:46
<karlUshi>
yes othermaciej
01:47
<karlUshi>
:) my point is when we were at school, starting to learn division of rational numbers. It was hard. There was a learning curve.
01:47
<karlUshi>
HTML has very simple things (though markup languages are difficult for most people) and there are features a bit more complex and it just takes time to learn.
01:48
<Dashiva>
It used to be 3 1/2 for a few years, then it became 3.5
01:48
<karlUshi>
cf. <om_food> rel vs. rev is so brain-hurtingly confusing
01:51
<othermaciej>
karlUshi: rel vs. rev is more in the realm of path integrals than rational division
01:51
<othermaciej>
even experts have a hard time
01:51
<zcorpan_>
399 invited experts
01:52
<karlUshi>
othermaciej: yes, it takes time to learn things and be a *pro*
01:54
<karlUshi>
it reminds me of http://www.molly.com/2005/11/14/web-standards-and-the-new-professionalism/
03:07
<zcorpan_>
damn, it's hard to test <noscript> when the tools you have at your disposal to inspect the DOM is javascript
03:07
<zcorpan_>
s/tools/tool/
03:10
<Philip`>
Disable JS, load the page, reenable JS, click the scripted DOM-inspection button on the page?
03:10
Philip`
isn't sure exactly what happens when you toggle JS
03:12
<zcorpan_>
yeah. don't have such a button in ie7 though, and i can't figure out how to actually disable js in ie7 (i thought it was "Active Scripting")... and i don't trust the web dev toolbar in ie7
03:15
<zcorpan_>
oh, the setting doesn't apply to local files, apparently
03:18
<zcorpan>
input document: <!doctype html><head><noscript>X</noscript></head><body>Y</body>
03:18
<zcorpan>
.innerHTML on the root element: <HEAD><NOSCRIPT></HEAD>
03:18
<zcorpan>
<BODY>X</NOSCRIPT>Y</BODY>
03:19
<Philip`>
That looks nice and tree-like
03:22
<zcorpan>
i guess it makes sense to pop the noscript when it contains non-HEAD content, and then treat it as if it was found in HEAD
03:22
<zcorpan>
i.e., .innerHTML being <head><noscript></noscript></head><body>XY</body>
03:42
<zcorpan>
http://simon.html5.org/test/html/parsing/noscript-in-head/
04:57
<Hixie>
zcorpan: your proposal for parsing <noscript> wouldn't allow round-tripping of valid dacuments, which is a requirement
04:57
<Hixie>
oh wait
04:57
<Hixie>
actually
04:57
<Hixie>
it would
04:57
<Hixie>
well...
04:57
Hixie
ponders
04:57
<Hixie>
what you proposed probably wouldn't but there are ways around it i guess
04:57
<Hixie>
hm
05:00
<zcorpan>
Hixie: i don't follow, what is the problem?
05:01
<Hixie>
nothing
05:01
<Hixie>
just thinking out loud
05:01
<zcorpan>
oh, ok
05:01
<Hixie>
sorry :-)
05:01
<zcorpan>
no worries :)
09:52
<Jero>
I've been reading Lachy's article about the <b> and <i> elements and I can't help thinking "then what about <u>, <s>, <strike>, and <big>!?"
09:52
<Jero>
I know they're deprecated in HTML 4 and all, but the reason for keeping <b> and <i> would IMO also apply to those elements.
09:58
<othermaciej>
the official reasoning in the HTML5 spec for what elements are kept is that they can represent useful semantics associated with the given default presentation
09:59
<Jero>
then so can the <u> element, right?
10:01
<othermaciej>
<u> is not used for any common typographical conventions in typeset text
10:01
<othermaciej>
(underline rather)
10:03
<Jero>
but the underline also hints that the text somehow has a different meaning than the rest of the text
10:05
<hsivonen>
does Python come with a standard library that allows me to spider the Web Forms 2.0 test suite without invoking wget?
10:06
<virtuelv>
hsivonen: I can't think of anything offhand, but would http://cheeseshop.python.org/pypi/spider.py/0.5 help?
10:06
<hsivonen>
Jero: fwiw, I'd like to keep <u> for the use cases that <m> has been created for
10:07
<hsivonen>
virtuelv: thanks. the point of avoiding wget is avoiding any non-default stuff, though
10:12
hsivonen
hacks up something quick and dirty
10:15
<KevinMarks>
hsivonen: you can use urllib
10:15
<KevinMarks>
see diveintopython.org for examples
10:15
<hsivonen>
KevinMarks: thanks
10:16
hsivonen
didn't know urllib can spider
10:17
<KevinMarks>
well, depends what you mean by spider
10:17
<KevinMarks>
http://diveintopython.org/html_processing/index.html is an overview
10:18
<KevinMarks>
though if it's a hack and not some performance fest, use BeautifulSoup
10:20
<hsivonen>
KevinMarks: I only want to grab a local copy of Anne's Web Forms 2.0 test suite without invoking anything that users don't get by installing a vanilla *nix system and python
10:20
<hsivonen>
KevinMarks: the diveintopython stuff is what I need. thanks
10:20
<KevinMarks>
ah, right, no parsing
10:21
<KevinMarks>
http://diveintopython.org/http_web_services/index.html is the right place to start then
10:22
<KevinMarks>
http://diveintopython.org/http_web_services/review.html specifically ;)
10:24
<hsivonen>
KevinMarks: yeah, I have the single url download case covered already. need to traverse the directories, though
10:25
<hsivonen>
which is what the html_processing example shows
10:25
<virtuelv>
hsivonen: why do you want to avoid wget?
10:25
<KevinMarks>
markp++
10:25
<hsivonen>
virtuelv: Mac OS X doesn't have wget by default
10:25
<virtuelv>
ah
10:25
<virtuelv>
neither does windows, for that matter
10:35
<Jero>
hsivonen: yeah, keeping <u> instead of <m> seems reasonable
10:36
<Jero>
but still, keeping those presentational elements because the can represent useful semantics associated with the given default presentation still seems a bit odd to me
10:36
<Jero>
heck, even <blink> would fall under that
10:41
<MikeSmith>
kfish - PechaKuchaNight tonight in Tokyo
10:42
<MikeSmith>
http://www.tokyoartbeat.com/event/2007/EE5B
10:42
<MikeSmith>
volume 42
10:42
<kfish>
MikeSmith, sweet
10:43
<MikeSmith>
you should come up and do a web-designer-friendly 20x20 overview of Annodex some time
10:43
<kfish>
MikeSmith, sounds good :-)
10:46
<hsivonen>
hendry: did you see Ari Jaaksi's blog post from May 15th about Mobile Web being dead?
10:46
<virtuelv>
hsivonen: url?
10:47
<hsivonen>
virtuelv: http://jaaksi.blogspot.com/2007/05/mobile-is-dead.html
10:47
<virtuelv>
ty
10:48
<hendry>
hsivonen: no I haven't, will read.
11:05
<hendry>
hsivonen: i left a comment
11:29
<hendry>
hsivonen: do you anything about fonts?
11:29
<hendry>
:)
11:29
<hsivonen>
hendry: I know about fonts but I'm not doing anything about fonts
11:30
<hendry>
I was wondering how fonts like Dejavu and perhaps VeraSansYuanTi gets treated by CSS
11:30
<mikeday>
font-family: DejaVu Sans;
11:31
<hendry>
or how rather Firefox chooses the fonts
11:31
<hsivonen>
hendry: depends on the UA and the font back end I guess
11:31
<hendry>
as i don't expect Web authors to do a "font-family: DejaVu Sans;"
11:31
<hsivonen>
hendry: why not? without testing, I'd expecting Safari to support that
11:31
<mikeday>
use @font-face to map "sans-serif" to "DejaVu Sans" :)
11:31
<hendry>
aren't Web authors supposed to choose a family or something? instead of an actualy named font
11:32
<hsivonen>
hendry: DejaVu Sans is a font family in CSS terms
11:32
<hendry>
where can i read further about this? is the a CSS font doc I wonder
11:33
<hsivonen>
mikeday: speaking of CSS fonts and DejaVu: for some reason, prince didn't find the DejaVu fonts in /Library/Fonts. I had to install them in prince's own font dir and edit fonts.css
11:33
<mikeday>
there are the standard families: serif, sans-serif, cursive, monospace
11:34
<mikeday>
hsivonen, can other MacOS X apps see them?
11:35
<hendry>
i wonder if there is some firefox option to show all the registered fonts?
11:35
<hendry>
on the system.
11:36
<mikeday>
Font Book or \Windows\Fonts or whatever depending on platform
11:37
<mikeday>
it's not really a browser-specific thing
11:38
<hendry>
well, just to know what Firefox (on the system) sees when it comes to fonts, not so much the system
11:39
<hendry>
gosh, did that make any sense :)
11:39
<mikeday>
yeah, that makes sense
11:39
<mikeday>
when you run prince --debug it prints a list of all the fonts that it can see
11:39
<hendry>
mikeday: you wrote Prince?
11:39
<mikeday>
ie. all the fonts that show up when it asks the OS: "Which fonts are installed?"
11:40
<mikeday>
well, the easy bits :)
11:40
<mikeday>
(and the font system, which is a nasty bit, I guess)
11:40
<hendry>
mikeday: it's pretty cool. :)
11:41
<mikeday>
thank you, I'm glad you like it :)
11:45
<mikeday>
funny thing about the default font families is that you can't mix and match them
11:45
<mikeday>
eg. font-family: serif monospace;
11:46
<hendry>
mikeday: http://static.natalian.org/2007-05-30/fc-list_monty.txt http://static.natalian.org/2007-05-30/monty-fonts.txt
11:46
<mikeday>
the presence of serifs is orthogonal to monospacing
11:46
<hendry>
fc-list seems to pick up more. what is fc-list doing I wonder?
11:46
<hendry>
are the 'standard families' et al documented somewhere?
11:46
<mikeday>
it is probably including PostScript Type 1 fonts, which Prince doesn't support yet
11:47
<mikeday>
all the fonts that Prince lists should be TrueType fonts
11:47
<mikeday>
http://www.w3.org/TR/CSS21/fonts.html#generic-font-families
11:47
<hendry>
monty$ wc -l monty-fonts.txt fc-list_monty.txt
11:47
<hendry>
63 monty-fonts.txt
11:47
<hendry>
179 fc-list_monty.txt
11:48
<mikeday>
rather Latin-centric, the standard font families
11:48
<mikeday>
they might as well be named Times, Helvetica, and Courier; it'd be less typing
11:49
<hendry>
mikeday: dejavu isn't mentioned on http://www.w3.org/TR/CSS21/fonts.html#generic-font-families
11:49
<mikeday>
no, as DejaVu is an actual font, derived from Bitstream Vera
11:49
<mikeday>
not a generic abstract font family, as defined by CSS
11:50
<mikeday>
"sans-serif" is not a physical font, it's a placeholder for any number of actual fonts
11:50
<mikeday>
(that don't have serifs, hopefully)
11:50
<hendry>
this is a science ...
11:57
<mikeday>
possibly the most useless generic font family is "fantasy"
11:57
<mikeday>
useless because it doesn't map to any obvious Microsoft Core font :)
11:57
<hendry>
i find it confusing that actual font can be in font-family like "font-family: DejaVu Sans;"
11:58
<hendry>
mikeday: do you have exp with CJK fonts? esp. Chinese?
11:58
<mikeday>
a little
11:58
<mikeday>
I use the Arphic fonts
12:00
<hendry>
afaik there a four free chinese fonts ttf-arphic-ukai ttf-arphic-uming ttf-fireflysung xfonts-wqy
12:00
<mikeday>
the arphic font pack includes several fonts
12:00
<mikeday>
eg. traditional + simplified variants
12:01
<mikeday>
hmm, actually, they're each in separate packages now it seems
12:01
<hendry>
is it actually used out there? compared to proprietary simsun or VeraSansYuanTi?
12:01
<mikeday>
ttf-arphic-gbsn00lp, ttf-arphic-gkai00mp for the simplified ones
12:01
<mikeday>
I have no idea, but I would guess that most Chinese websites are designed for Microsoft fonts
12:02
<hendry>
damn, this is hard. :)
12:03
<mikeday>
what are you trying to do, actually?
12:03
<hendry>
build an OS http://webconverger.com/
12:03
<hendry>
that doesn't suck for the Chinese market :)
12:04
<hsivonen>
mikeday: yeah, Font Book saw them
12:04
<mikeday>
define OS?
12:04
<mikeday>
hsivonen, they are probably getting silently dropped by Prince for some reason
12:05
<mikeday>
Prince 6.0 rev 2 includes a fix for some font issues on MacOS X, and extra debug info
12:05
<mikeday>
(see Prince development roadmap http://www.princexml.com/roadmap/ )
12:05
<hsivonen>
mikeday: ok. I didn't know about --debug nor about a roadmap. thanks
12:06
<hsivonen>
mikeday: I'm on Mac OS X 10.4.9
12:06
<mikeday>
the roadmap is new, it's an experiment in being open to our users :)
12:06
<hendry>
mikeday: based on Debian. boots up kernel. detects hardware, launches X and Firefox (Webconverger)
12:06
<mikeday>
so it's like a distro for web kiosks
12:07
<mikeday>
and you're wondering what packages you need to include?
12:07
<hendry>
mikeday: http://flickr.com/photos/hendry/521334985/
12:07
<hendry>
mikeday: yes, exactly
12:07
<hendry>
mikeday: though I've lived out in CJK
12:08
<hendry>
and I know that they're really fussy about the fonts.
12:08
<mikeday>
hmm, sina.com.cn looks better than that when I load it here
12:08
<mikeday>
try installing all the arphic fonts
12:09
<hendry>
ok, though will Firefox use them I wonder.
12:09
<hendry>
I think that test rendering looks pretty bad myself :)
12:10
<mikeday>
it should use them if they are installed properly, otherwise might need some Fontconfig tweaking
12:13
<hendry>
mikeday: ok, i'll try a build out later. Webconverger is totally free software btw http://svn.debian.org/wsvn/debian-live/configs/webconverger-cn/config/chroot_local-packageslists/locale?op=file&rev=0&sc=0
12:13
<hendry>
mikeday: thanks for your help, I need to get busy on other stuff
12:13
mikeday
waves
12:56
hsivonen
tries to figure out the most robust way to track which files in the Opera test suite are expected to be conforming and which ones are expected to be non-conforming
15:29
<gsnedders>
markp: you see my email about having non ASCII superset encoded autodiscovery tests?
15:49
<markp>
gsnedders: no
15:49
<markp>
checking
15:50
<gsnedders>
markp: it was a while ago.
15:51
<markp>
doesn't mean anything
15:52
<gsnedders>
markp: what doesn't? the date? the email? something else?
15:52
<markp>
found it
15:52
<markp>
er, the fact that it was a while ago <-- doesn't mean anything
15:52
<markp>
i'm months behind on email
15:52
<gsnedders>
ah
15:52
<markp>
ah, from november?
15:53
<gsnedders>
markp: 20th Feb
15:53
<markp>
hmm
15:53
<markp>
aha
15:53
<markp>
found it
15:53
<gsnedders>
I talked to you about the nov one a while ago, probably in Jan or so
15:54
<gsnedders>
I was just thinking of something like UTF-16
15:54
<markp>
i can do utf-16
15:54
<gsnedders>
as I say, it'll break my implementation for one
15:54
<markp>
excellent
15:55
<gsnedders>
and that's part of the point of tests :P
15:56
<markp>
did you want the html or the xml in utf-16?
15:56
<markp>
or both?
15:56
<gsnedders>
the HTML
15:57
<gsnedders>
anything apart from plain ASCII XML I think should be in the Atom test case (and my implementation copes with that, just not the HTML)
15:57
<gsnedders>
my feeling is the XML should be kept as simple as possible, as it's really the ability to get the <link> in the HTML that's being tested
16:00
<markp>
bah
16:28
<markp>
http://diveintomark.org/tests/client/autodiscovery/html4-057.html
16:28
<markp>
i suppose i should add a whole bunch of tests for the new rel="feed" too
16:31
<virtuelv>
heh. I see lowsrc="" is making a return in the form of 'cite'
16:31
<virtuelv>
(yes, I realise that there's a difference)
16:40
<gsnedders>
markp: heh. what I didn't realise before is that we now can't actually find the <link rel="next> either now :P
16:41
<markp>
yeah, i had to fix that in my atomautodiscovery.py test harness too
16:42
<markp>
to make it easy for you, every html and xhtml file is guaranteed to have a content-type with a charset parameter
16:42
<markp>
so you can cheat a little
16:43
<gsnedders>
I don't think I'll get the fix in 1.0, as it requires changing quite a bit, and most of that stuff is already meant to go into 1.1
16:43
<gsnedders>
so unlikely to be fixed till the end of the year in a stable release
22:41
<Hixie>
i'm really quite amused by the way the headers="" discussion is still going on
23:05
<rxKaffee>
is there any data on html5 support in netscape?
23:06
<rxKaffee>
netscape 8 is based on firefox, so... maybe some support?
23:07
<jruderman>
i imagine it's the same as in whatever gecko version it uses
23:07
<gsnedders>
1.7.x, IIRC
23:07
<gsnedders>
which was what version of Fx? 1.0?
23:08
<zcorpan_>
gsnedders: yeah
23:09
<rxKaffee>
so you mean html5 was added to gecko in 1.7, and netscape uses geko 1.0?
23:10
<zcorpan_>
rxKaffee: what do you mean with "html5 was added"?
23:10
<zcorpan_>
rxKaffee: gsnedders said that netscape 8 uses gecko 1.7.x (the same as firefox 1.0)
23:10
<rxKaffee>
ah,ok
23:11
<gsnedders>
so it'll support as much as Firefox 1.0 does
23:12
<rxKaffee>
gecko/20070321 == gecko 1.7?
23:12
<zcorpan_>
rxKaffee: no
23:12
<rxKaffee>
oh, that is what netscape 8 reports
23:13
<rxKaffee>
20070321
23:13
<zcorpan_>
really?
23:13
<rxKaffee>
ummm, netscape 8.1.3 I mean
23:13
<rxKaffee>
mmm
23:13
<zcorpan_>
i didn't think gecko 1.7 was updated anymore
23:13
<rxKaffee>
it also says 1.7.5
23:15
<Philip`>
http://en.wikipedia.org/wiki/Netscape_Browser seems to indicate it was based on Firefox 1.0.x until that stopped being maintained, and now it's just (presumably updated) versions of Gecko 1.7.5
23:15
<gsnedders>
it'll just be updated versions of Gecko 1.7
23:15
<gsnedders>
whether the patches go upstream or not is another matter
23:20
<rxKaffee>
hmm, so prb ditch netscape
23:20
<rxKaffee>
ok, thanks guys :)
23:21
<gsnedders>
othermaciej: does Safari pay any attention to <ttl> in RSS feeds?
23:22
<othermaciej>
gsnedders: I don't know
23:23
<gsnedders>
othermaciej: can you find out easily, or not?
23:24
<othermaciej>
gsnedders: I can ask the people who implement the system framework that implements feed handling, or I can try to find the code somewhere in apple's source control
23:25
<gsnedders>
othermaciej: if you have any spare time, could you?
23:32
gsnedders
awaits the arrival of [3]markp
23:32
<gsnedders>
you aren't having a good day with web access, are you? :P
23:33
<othermaciej>
gsnedders: I actually don't have any spare time and a big backlog of tasks, so I can only really queue this one up if it is particularly important
23:33
<othermaciej>
gsnedders: on #webkit on FreeNode you may be able to find someone who knows
23:34
<gsnedders>
othermaciej: ah, don't worry then