IRC log of html-wg on 2007-04-23

Timestamps are in UTC.

00:03:59 [Hixie]
gsnedders: according to my research, about 0.0014% XHTML is served as XML
00:04:05 [Hixie]
(iirc)
00:15:59 [zcorpan]
is that counting text/html pages with known xhtml doctypes as "xhtml"?
00:16:53 [zcorpan]
or <html xmlns>?
00:18:59 [Lachy]
zcorpan, he said "served as XML", so it would seem that it doesn't include text/html pages
00:20:21 [zcorpan]
Lachy: he said 0.0014% of "xhtml" is served as xml
00:20:23 [Hixie]
that's just pages served with an XML MIME type, not text/htlm
00:20:24 [zcorpan]
what's the rest?
00:20:29 [zcorpan]
ah
00:20:35 [Hixie]
let me rephrase that
00:20:38 [Hixie]
it's not 0.0014% of xhtml
00:20:48 [zcorpan]
then 0.0014% of xml is xhtml
00:22:12 [Lachy]
I took it as meaning 0.0014% of pages on the web are served as XML
00:23:08 [karl]
what is |page on the Web|?
00:23:14 [xover]
gavin: I'm saying the attitude that they have the best solution already is what makes people reticent.
00:23:41 [karl]
family of XHTML + HTML ? (excluding RSS for example)
00:23:54 [Lachy]
that's what I assumed
00:32:44 [gavin_]
xover: ah, that I can understand. I don't think that is a concern unless people think that "they" are unreasonable and unable to objectively consider different opinions.
00:33:23 [karl]
http://krijnhoetmer.nl/irc-logs/html-wg/20070422#l-225
00:33:30 [karl]
big problem with this hack
00:33:48 [karl]
because it relies on a lack of strictness of a browser
00:34:06 [karl]
which means if/when the browser is fixed. the hack doesn't work anymore.
00:37:39 [zcorpan]
the page displays in ie but it's treated as generic xml, thus no default styles, no links, no extracted semantics or anything
00:41:51 [Lachy]
that hack of theirs doesn't even work in IE7
00:42:00 [Lachy]
only IE6
00:43:49 [gavin_]
gavin_ has joined #html-wg
00:43:59 [zcorpan]
so, if the url ends in .html and there's a <meta charset>, then ie6 will treat it as text/html? correct?
00:44:22 [Lachy]
somehow I'm not particularly surpirsed that the XHTML2 WG's conclusion isn't something like "IE doesn't support XHTML, we should provide an HTML alternative", but rather "IE doesn't support XHTML natively, what bugs can we exploit to work around it and maintain our illusion that XHTML can be used on the web?"
00:44:51 [anne5]
anne5 has joined #html-wg
00:48:26 [zcorpan]
can someone translate matthew's last email?
00:49:47 [Lachy]
the one that starts with "Dan who?"?
00:49:55 [anne5]
"important work by the SVG WG"?
00:50:00 [anne5]
guess they haven't published that yet
00:50:25 [zcorpan]
"Yeah, Dave Hyatt is just going to have to realize that because of his participation in the Conspiracy of Light back on Babylon 5, his career in the Earth Alliance military is over."
00:50:46 [zcorpan]
http://www.w3.org/mid/462C01C7.8070903@earthlink.net
00:51:16 [Lachy]
oh right, just received it
00:52:18 [Lachy]
I think it was supposed to be a joke
00:53:04 [zcorpan]
but i'll leave it at that
00:56:43 [zcorpan]
is the former intended to refer to whatwg, and the latter to apple/safari?
00:57:24 [Zeros]
Zeros has joined #html-wg
01:03:01 [Philip`]
I'm thinking it means 'because of his participation in the WHATWG, his career in the HTML WG is over' (since it was in a response to a comment that sort of (but not really) disagreed with having Dave due to his past WHATWG involvement). But I don't think it's the greatest example of clear communication
01:03:51 [zcorpan]
ah, right
01:04:07 [zcorpan]
and indeed
01:04:49 [anne5]
if that's a policy that should also go for all people who gave us HTML4 :p
01:05:45 [Lachy]
right, because we don't want people with actual experience working on this spec do we? :-)
01:06:59 [anne5]
ok, HTML4 might be a bad example
01:07:04 [anne5]
if you put it like that
01:08:04 [Lachy]
acutally, anne5, I was responding to the general idea of not having Dave work on the spec, not your comment about HTML4 editors
01:09:31 [anne5]
I don't really like the editor thread at all... People are just complaining a bit without actually finding proper solutions
01:10:12 [karl]
maybe, some people are expressing concerns because it is another browser persons for editing. Concerns are always interesting they express feelings from one part of the community.
01:10:16 [anne5]
Maybe I'm too practical
01:10:58 [Dashiva]
Because everyone knows xhtml2 is much more useful in the real world than quirks mode html
01:11:11 [anne5]
Because everyone uses e-mail which was specced by ...
01:11:39 [karl]
anne5, Lachy, there is something you keep forgetting. it is a question of community, or more exactly communities.
01:12:15 [karl]
being practical is a good way for doing work, not for juding, or you will hit the social interactions wall quite fast.
01:12:17 [anne5]
karl, I find it really hard to understand what you keep saying in this channel now and then
01:12:29 [Lachy]
right, and the WHATWG community is much larger and has more involvement from the community than many W3C specs
01:12:34 [anne5]
fwiw
01:12:36 [Hixie]
zcorpan: sorry, my battery ran out mid-conversation and i had to go home to get power again!
01:12:53 [anne5]
anyway, time to travel for 30-35 hours... yay
01:12:53 [Hixie]
zcorpan: it was 0.0014% of pages that I surveyed used an XML MIME type
01:12:57 [karl]
Lachy: the whatwg mailing list is one view.
01:13:14 [zcorpan]
Hixie: ok, thanks
01:13:41 [zcorpan]
so the amount of xhtml on the web is a subset of that
01:14:45 [karl]
anne5: :)
01:14:47 [Hixie]
yeah
01:15:11 [Hixie]
zcorpan: about 15% of pages had xmlns="...xhtml" attributes on the <html> element
01:15:32 [h3h]
wow, higher than I'd expect
01:15:53 [karl]
Hixie: did the sample contain the RSS feed? or just html/xhtml type (with the bias on what is a real html/xhtml)
01:16:00 [Hixie]
and about 50% had doctypes of any kind
01:16:07 [karl]
s/feed/feeds/
01:16:17 [Hixie]
karl: i believe i specifically excluded RSS, but i'd have to go to work to check
01:16:27 [karl]
ok thanks
01:16:29 [Hixie]
it's hard to tell what is one or the other, in practice
01:16:39 [Hixie]
(q.v. the algorithm in the html5 spec)
01:16:43 [karl]
yes it's what I thought too :/
01:17:28 [h3h]
google doesn't index feeds though, does it?
01:17:44 [h3h]
and even so, .0014% seems low if it includes feeds
01:18:09 [Hixie]
most feeds are served as text/plaoin or text/html
01:18:22 [h3h]
heh. nice
01:19:30 [h3h]
Hixie: how feasible is it to be hired into your "team" at Google?
01:20:34 [karl]
http://www.google.com/intl/en/jobs/index.html
01:20:55 [h3h]
yeh, no open req for "work with Hixie on HTML5"
01:21:03 [Hixie]
heh
01:21:05 [h3h]
and I sincerely doubt there ever will be
01:21:11 [h3h]
that's the kind of job you have to grease your way into
01:21:53 [karl]
h3h: if you have the desire to work for Google in the first place. But that's another topic ;)
01:22:06 [h3h]
oh I do indeed have that desire :)
01:22:10 [karl]
plus the fact that you can easily contribute publicly to this work
01:22:20 [h3h]
"easily" is relative
01:22:37 [h3h]
especially when working a more-than-full-time job
01:22:37 [zcorpan]
hi! html5 is teh coolest shit!! i want to work with hixie at google so i can make up tags
01:22:38 [Hixie]
yeah if you want to be paid by google to work on this stuff, i recommend going about it the way i did
01:22:41 [karl]
h3h: yes it takes time
01:23:00 [Hixie]
that is, spend years working with browser vendors, writing tests, working with working groups, etc
01:23:26 [h3h]
and start your own working group to fill the gaps in the web :)
01:23:32 [xover]
Or just send `em a resume; at the rate they're amassing employees... :-)
01:23:53 [h3h]
indeed
01:25:27 [Zeros]
That's just what we need... another WHATWG for every person seeking employment by Google
01:25:33 [h3h]
haha
01:27:56 [xover]
karl: You may want to point yod at mjs' <http://www.w3.org/mid/0D0B632E-9F51-4953-A87B-19A6F89DBE6F@apple.com>.
01:28:30 [Lachy]
I'm going about it exactly the way Hixie did... get a job at opera (trying to), work on specs, etc. :-)
01:29:37 [Hixie]
:-)
01:29:41 [karl]
xover: I'm looking at that. It is a day-off today in Keio SFC, but I will pass it.
01:29:54 [xover]
yod has days off? SInce when? :-)
01:29:55 [Lachy]
who wants to set up the IWAJAGWG (I want a job at Google working group) ;-)
01:30:13 [karl]
xover: well as you see ;) I'm here too and I should not :p
01:30:19 [xover]
heh heh
01:30:25 [xover]
Speaking of which...
01:30:38 [karl]
have a good night
01:33:52 [mjs]
xover: who is yod?
01:35:06 [karl]
mjs: yod on freenode:#validator is olivier on W3C channels
01:35:12 [karl]
aka Olivier Thereaux
01:35:42 [mjs]
ah, so he might be interested in helping with a test suite for conformance checkers?
01:36:27 [karl]
or at least to have access to the test and automate them for the validator. I think so.
01:37:07 [karl]
http://validator.w3.org/dev/tests/
01:48:30 [zcorpan]
i'll probably be working on tests at opera this summer, and i'll look into labeling each test as syntatically conforming/syntatically non-conforming, so they can be used as conformance checker tests as well as browser tests
01:51:30 [mjs]
Lachy: since you were discussing Safari's handling of <script /> earlier, we might make that a Dashboard-only quirk - we foolishly did it for Firefox compatibility, and then a huge number of Dashboard widgets started relying on it, and now Firefox no longer handles it as empty in HTML
01:52:02 [mjs]
zcorpan: maybe you can volunteer to be a test suite editor then
01:52:16 [Dashiva]
I need to make my client not highlight dashboard...
01:52:18 [zcorpan]
mjs: yeah
01:52:18 [Lachy]
mjs, I suspected that's what you were going to do
01:52:42 [mjs]
Lachy: I tried to get Apple to fix all the system widgets at least for the next release
01:54:30 [karl]
I would be happy to contribute for testing but I have the administration the WG is taking far too much time, still. But I will certainly do it.
01:54:46 [karl]
a first step would be to collect the test already done.
01:55:18 [mjs]
yeah, I know a lot of people have test cases around, I am hoping a few of them volunteer and we can give them a repository to start organizing them officially
01:55:37 [mjs]
(as soon as we have a spec of course - pointless to have tests w/ no spec)
01:56:51 [Lachy]
should we use CVS for the test suite? http://dev.w3.org/cvsweb/html5/
01:57:37 [mjs]
if the W3C had an official subversion repository I'd suggest that
01:57:47 [mjs]
in its absence, cvs should do
01:57:52 [Lachy]
I don't think they do have svn
01:58:23 [Lachy]
I have to go, cya
01:58:43 [mjs]
later
02:01:35 [Zeros]
mjs, Is Radar a custom issue tracker?
02:02:02 [mjs]
Zeros: it's the Apple internal bug-tracking system
02:02:40 [Zeros]
yeah
02:06:39 [heycam]
heycam has joined #html-wg
02:50:46 [gavin_]
gavin_ has joined #html-wg
04:58:08 [gavin_]
gavin_ has joined #html-wg
06:01:28 [loic]
loic has joined #html-wg
06:19:25 [hsivonen]
xover: see the context of saying "best solution already". It is quite possible that the WHATWG does not have the best solution for all issues. but it would be silly to assume that the solutions have to be changed just because they weren't reached within the W3C.
06:20:31 [hsivonen]
xover: that is, if the WHATWG already has the best solution for a given issue, reopening it just because of politics makes no sense
06:21:06 [xover]
hsivonen: I'm just reading mjs' latest and shaking my head in resignation.
06:22:01 [xover]
"So I am not sure why we would want to accommodate an opposing point of view."
06:22:34 [xover]
Really? Y'all are so sure you right and have thought of everything that you have no need of an opposing view?
06:23:39 [mjs]
xover: specifically on the issue of making changes to HTML that are not backwards compatible
06:23:59 [xover]
Sure. But that attitude keeps popping up.
06:24:16 [mjs]
xover: have I ever expressed it on any other point than that?
06:24:27 [mjs]
do you want to make incompatible changes to HTML?
06:24:33 [xover]
Yes.
06:25:10 [mjs]
why do you want to make them in HTML5 rather than XHTML2, when backwards compatibility is the biggest difference in goals between the two?
06:25:21 [hsivonen]
xover: considering that the new HTML WG is specifically not the XHTML 2.0 WG, do you think the new HTML WG should accommodate views that aspire to turn HTML5 into XHTML 2.0?
06:25:47 [xover]
And see what happens when I try to express an opposing point of view...
06:26:25 [mjs]
xover: people disagree with you?
06:26:27 [xover]
I get ganged up on by a pack of rabid WHATWG'ers throwing accusations of XHTML2'ness at me. :-)
06:27:32 [Hixie]
i don't see any ganging up, just some honest questions
06:27:48 [mjs]
my question is totally serious
06:28:06 [mjs]
I don't get why anyone would propose incompatible changes to HTML in HTML5, when XHTML2 exists as the venue for such things
06:28:52 [xover]
I would like to make evolutionary changes to HTML 4.01. I believe XHTML 2.0 is far too radical a change to be feasible in the real world in any reasonable timeframe.
06:29:48 [mjs]
I believe that any significantly incompatible change is far too radical a change to be feasible in the real world in any reasonable time frame
06:30:22 [hsivonen]
mjs: I do. If one assumes that browser vendors won't implement XHTML 2.0 but will implement HTML5, it makes sense to push whatever changes on the HTML5 side. However, this line of thinking misses the point *why* browser vendors would want to implement HTML5 and not XHTML 2.0.
06:30:37 [mjs]
that is why I want to work on a compatible evolutionary path, rather than arguing with the XHTML2 folks to break compat a little less
06:30:40 [mjs]
hsivonen: fair enough
06:31:07 [Hixie]
maybe it would help if xover gave concrete examples of things he wants to change that he doesn't think are backwards compatible
06:31:58 [xover]
Hell, how about things I /don't/ want changed? Y'all are radically redefining the entire language by no longer defining it in terms of SGML.
06:33:07 [mjs]
well, that goes to the question of what change and compatibility mean
06:33:20 [xover]
I'm still trying to figure out if mjs' really meant that "HTML5" redefines the meaning of all published documents (HTML 2.0, HTML 3.2, HTML 4.01, ISO-HTML).
06:33:28 [mjs]
browsers have never implemented SGML parsing for HTML, and now much content depends on this
06:33:40 [mjs]
including, for example, the ability to send XHTML as text/html
06:34:07 [Shunsuke]
Shunsuke has joined #html-wg
06:34:11 [hsivonen]
xover: well, the non-SGMLness is even in the charter. it is entirely unproductive to reopen that issue every week.
06:34:15 [xover]
mjs: Above I meant I wandet to do things like drop the transitional and frameset DTDs from html 4.01.
06:34:39 [mjs]
HTML5 goes one better by dropping all the DTDs
06:34:57 [xover]
Completely needlessly.
06:35:03 [hsivonen]
xover: embracing reality and insisting on SGML are the kind of opposing viewpoints that are mutually exclusive
06:35:21 [hsivonen]
xover: the WG cannot be productive if the issue is debated every week
06:35:38 [hsivonen]
xover: so by necessity, some people are not going to have their way
06:36:11 [Lachy]
xover, you're welcome to write a DTD for HTML5 if you wish
06:36:28 [Lachy]
it just won't be endorsed by the spec in any way (or be particularly useful)
06:40:09 [hsivonen]
xover: out of curiosity, why do you want a DTD when a RELAX NG schema exists and it is known that RELAX NG is more expressive than DTDs (or XSD for that matter)?
06:43:03 [xover]
I want a DTD so I can process it with DTD based tools. I also want a Schema of some sort, normative preferably, for other tasks.
06:43:59 [xover]
Let me ask; are browsers the only relevant consumers of web content?
06:44:26 [mjs]
no, but they are among the ones where interoperability is most important
06:44:52 [mjs]
since lack of interoperability there directly hurts all authors and end users (other than the rare HTML content that will never end up on the Web)
06:45:09 [xover]
Ok, so the browser vendors have some requirements, needs, they need the standard to accomodate.
06:46:25 [xover]
My requirements run along the lines of having the ability to process web content without needing to implement a MSIE-bugcompatible parsing engine.
06:47:06 [xover]
OpenSP was excellent in this regard. I doubt WebKit will provide the equivalent.
06:47:38 [mjs]
http://code.google.com/p/html5lib/
06:48:35 [mjs]
does OpenSP actually process web content?
06:48:49 [mjs]
which is to say, in a way that matches what the author intended, rather than by SGML rules?
06:48:50 [xover]
Yes. Very well.
06:49:15 [mjs]
then it must have a rougly MSIE-bugcompatible parsing engine already
06:49:22 [xover]
Uh-huh. But in order for the browsers not to have to change their parser engines dramatically, you require me to move from the well known and established SGML toolchains to some single Python hack.
06:49:46 [xover]
mjs: No, just different goals then which pixel to animate in what color.
06:50:10 [mjs]
xover: if it parses HTML as if it were an SGML application, then it will parse a lot of web content incorrectly
06:50:34 [mjs]
whatever HTML5 has to say about the matter, it is already not meeting your goals
06:50:41 [mjs]
unless you are only interested in a subset of web content
06:51:06 [xover]
Everyone is interested iun a subset of web content; the question is which subset.
06:51:55 [mjs]
HTML5 is interested in a very large subset
06:52:04 [xover]
The only valid one?
06:52:10 [mjs]
if you are interested in a smaller one, you should feel free to continue using your existing tools
06:52:54 [xover]
Ah, but in a previous message you implicated that HTML5 redefines all of text/html to _be_ HTML5.
06:53:02 [mjs]
I think asking for all browsers, most web content and most authoring tools to change so that your library can parse a bigger subset of web content is not a reasonable request
06:53:09 [xover]
Including, I can only assume, ISO-HTML.
06:53:43 [xover]
I'm asking that the spec at least /try/ to accomodate also the non-browser requirements.
06:54:36 [xover]
For instance, the non-SGML'ness of the charter was, IMO, a mistake, but the lack of focus on SGML in the actual spec is probably right and a good idea.
06:54:50 [mjs]
ISO-HTML differs from W3C HTML 4.01 and so is already invalid to send as text/html
06:55:49 [Hixie]
SGML tools simply can't process existing content
06:55:58 [Hixie]
e.g. <a href=http://damowmow.com/> test </a>
06:56:07 [Hixie]
...is radically different in SGML-land than in HTML
06:56:57 [Hixie]
i see no good reason to insist on using clearly inappropriate, fundamentally broken tools that handle a minute subset of the web when there exists the opportunity to handle so much more content
06:57:00 [xover]
mjs: Are you seriously suggesting ISO-HTML cannot be served on the web?
06:57:18 [xover]
Hixie: That's a very browser-oriented point of view.
06:57:30 [hsivonen]
xover: yes, basically the suggestion is that in order to accommodate browser reality, it would be a good idea to use an HTML5 parser instead of OpenSP at the start of your processing pipeline.
06:57:32 [Hixie]
especially since the opportunity has already generated real workable tools, parsers, and conformance checkers
06:57:33 [mjs]
well, no one can stop you, but serving it with the text/html MIME type does appear to violate the RFC registering text/html
06:57:37 [Hixie]
xover: no, i'm talking about data mining
06:57:43 [Hixie]
xover: and other tools
06:57:46 [Hixie]
xover: not browsers at all
06:58:04 [hsivonen]
xover: once HTML5 parsers are readily available under very permissive licenses, I don't see this as onerous
06:58:59 [xover]
Hixie: It's a "python hack" only because SGML tools have about 30 years of history and html5lib is brand new.
06:59:11 [Hixie]
ah
06:59:21 [Hixie]
so in 30 years, will it still be a python hack?
06:59:22 [hsivonen]
xover: ISO-HTML is not served on the Web often enough for it to matter for tool choices unless you have made a bilateral agreement with the provider of content
06:59:34 [xover]
Yes, as much as OpenSP is a C++ hack. :-)
06:59:36 [Hixie]
it seems strange to judge something on its age rather than its quality
06:59:47 [mjs]
software isn't wine
07:00:03 [Hixie]
even wine should be judged on its quality, not its age
07:00:10 [Hixie]
it's just that with wine the two tend to be correlated
07:00:19 [Hixie]
with software, i don't think there's a correlation at all
07:00:22 [hsivonen]
I'd say OpenSP has quality if you judge it against the SGML spec, but it is the wrong tool for parsing arbitrary text/html content available on the Web
07:00:30 [Hixie]
(neither a positive one nor an inverse one)
07:00:42 [Hixie]
hsivonen: right
07:00:51 [mjs]
well, software quality does take a minimum amount of time
07:01:17 [mjs]
but past a certain point (which I think is less than 30 years for even the most complex software) there's not much correlation left
07:01:30 [hsivonen]
xover: you are basically suggesting that the spec should accommodate an inappropriate non-browser tool used by few instead of accommodating browsers used by many
07:01:34 [xover]
Did anybody tell ISO that their specs don't matter and we don't want them on our web?
07:01:45 [xover]
hsivonen: Did I say "instead"?
07:02:11 [hsivonen]
xover: "instead" follows implicitly due to the nature of the issue
07:02:23 [xover]
hsivonen: I disagree.
07:02:28 [Hixie]
sgml processing and the syntax of pages on the web are fundamentally incompatible
07:02:31 [Hixie]
see the example i gave above
07:02:41 [hsivonen]
xover: perhaps no one bothered to tell ISO.
07:02:44 [Hixie]
<a href=http://damowmow.com/> test </a>
07:03:01 [Hixie]
...means something radically different in SGML-land than on the web
07:03:30 [hsivonen]
xover: see how many years it took them to make some of their specs available for gratis on the Web as zipped PDF when people have been saying for years that they should be available on the Web as Web pages
07:03:59 [xover]
So you rail about Microsoft's implementations of standards, but you want to redefine what the standard is so that your particular implementation of them is suddenly not only entirely conforming, but in fact /defiining/.
07:04:20 [hsivonen]
xover: ISO has been seriously out of touch with the Web, so why pretend that they matter just because they are official
07:05:15 [Hixie]
actually it's microsoft's implementation that we want to make conforming, basically
07:05:15 [xover]
See, this is what I don't like. The browsers and webdesigners point of view rules all; anything else is dismissed as irrelevant.
07:05:28 [Hixie]
(or as close as we can get without making it a non-tree)
07:05:45 [xover]
Hixie: Sorry, I may have been drowning in Matthew Raymonds rethoric a little much lately.
07:05:46 [Hixie]
xover: i'm talking about tools here. i really don't care about browsers in this conversation.
07:06:09 [gavin_]
gavin_ has joined #html-wg
07:07:29 [hsivonen]
xover: browsers are seriously important for the Web. the W3C begat the WHATWG when it ignored browsers
07:08:08 [xover]
hsivonen: There is a compromise position in between XHTML2 and WHATWG.
07:08:25 [xover]
They are both extremes of the scale in opposite directions.
07:08:40 [xover]
In fact, there's more than one axis to this scale.
07:09:06 [hsivonen]
xover: we should optimize for the good of the Web instead of finding political middle ground
07:09:24 [xover]
hsivonen: Who said anything about politics?
07:10:05 [hsivonen]
xover: compromising without technical reasons is politics
07:10:22 [hsivonen]
xover: it has been explained why it doesn't make sense to cater for OpenSP
07:10:27 [hsivonen]
technically
07:12:02 [xover]
See, this is why I don't want any of you lot as Editors. :-)
07:12:44 [hsivonen]
xover: btw, as far as old discussions go, we already had this discussion on the WHATWG list with Elliotte Harold, but that discussion had an XML parser in the role that OpenSP occupies here
07:13:27 [xover]
Yeah, that's why I gave up on the WHATWG in the early days. They didn't seem interested in accomodating my requirements.
07:15:47 [hsivonen]
xover: the fact that real Web content in the general case does not work with OpenSP is outside the control of the WHATWG. it is a contrained posed by the way the world is
07:16:30 [hsivonen]
xover: if your requirements are incompatible with the reality of the Web, you will indeed be frustrated with the WHATWG
07:16:35 [hsivonen]
xover: however
07:17:10 [hsivonen]
xover: if you want to use OpenSP and you are not interested in the general case, I have the same reply that applied to elharo's case
07:18:09 [hsivonen]
xover: if you can make and agreement with the content provider so that you have a bilateral agreement and the generalities of the Web don't apply, you can agree that the content provider provides conforming XHTML5 to you
07:18:37 [hsivonen]
xover: in which case you can consume it with OpenSP when you've loaded the XML compatibility SGML declaration
07:19:05 [xover]
It's entirely possibloe that I'll end up abandoning HTML5 as a lost cause, yes.
07:19:42 [hsivonen]
xover: OK, but please don't consider it the fault of the WHATWG but the fault of the way the Web is
07:19:59 [hsivonen]
xover: since the Web isn't SGML-compatible in general
07:20:33 [xover]
For the same reasons I abandoned the original HTML WG as a lost cause. They too were unwilling to listen to my requirements (or anybody else's requirements, for that matter).
07:21:30 [Hixie]
xover: can you state your requirements without reference to specific user agents? i'm not sure i understand them still.
07:21:34 [hsivonen]
xover: I have spent a good moment here listening and explaining why your requirements aren't workable on the Web scale
07:21:41 [hsivonen]
xover: this isn't about not listening
07:21:58 [Hixie]
also note that who is editor doesn't change what technical decisions get made, at least not if the editor is (like i am) trying to find solutions to everyone's problems
07:23:53 [mjs]
if your requirement is "make OpenSP handle arbitary web content correctly", then this is outside the power of any working group
07:25:05 [mjs]
if the requirement is "define conforming web content such that OpenSP can correctly handle all conforming content", then that is probably not achievable without breaking more popular use cases, like conforming XHTML-compatible syntax
07:25:13 [xover]
Hixie: On Editors, if they are too much in agreement and share too strongly the same point of view, then all their blinders will be the same and other voices will be lost or dismissed.
07:25:40 [xover]
Hixie: Conversely, if they disagree fundamentally but still manage to act impartially, then you avoid that problem.
07:26:07 [mjs]
I think editors disagreeing fundamentally is likely to lead to more fighting, more stress, and less work done
07:26:17 [mjs]
as opposed to more fairness or better results
07:26:25 [xover]
mjs: Perhaps. But the alternative is worse.
07:27:01 [Hixie]
xover: as an editor, i specifically try to treat my opinion as no more important than anyone else's
07:27:17 [Hixie]
xover: i believe i'm reasonablly good at this, based on the comments from others
07:27:25 [xover]
mjs: Forget OpenSP specifically. It's an example of using a general toolchain — be it SGML based or XML based — to process web content.
07:27:32 [Hixie]
xover: (there are several things in the spec i really disagree with)
07:28:04 [xover]
Hixie: That's a very good sign! :-)
07:28:07 [mjs]
the HTML5 solution of using a general toolchain to process web content is to put an HTML5 parser at the front of your pipeline
07:28:22 [heycam]
heycam has joined #html-wg
07:28:38 [sbuluf]
mjs, fast off topic question, if you can: 1) are you sort of *the* apple person for browsers? or at least know the code? and if so...is there anywhere where i could see an proximated list of lines of code per browser functionality? (like security, parsing, rendering, UI, whatever). feel free to answer later if busy, i do not wish to interrupt.
07:28:56 [mjs]
sbuluf: I am one of many apple persons for browsers
07:29:01 [mjs]
I do know the code
07:29:10 [sbuluf]
i see. enough for me
07:29:24 [mjs]
there is no breakdown like that readily available, and some of the things you ask for don't make sense because they are not on separate lines of code
07:29:26 [mjs]
like security
07:29:37 [mjs]
all code has to consider security issues
07:29:37 [sbuluf]
i feared so...
07:29:43 [sbuluf]
right
07:29:47 [mjs]
much like performance
07:29:57 [mjs]
but the source code to the whole engine is available
07:30:06 [mjs]
so you can do whatever approximation suits you yourself
07:30:11 [sbuluf]
not even a remote way to determine some sort of code composition?
07:30:13 [mjs]
http://webkit.org/
07:30:21 [mjs]
http://webkit.org/building/checkout.html
07:30:24 [sbuluf]
(i would not know even how to read it, i'm afraid)
07:30:44 [hsivonen]
xover: HTML5 has a solution to the toolchain issue. moreover, there is already enough implementation experience to believe that the solution works
07:30:54 [xover]
mjs: But all deployed web content is defined in terms of SGML and HTML5 retroactively changes the rules. The wealth of experience devloped over years with SGML tools is suddenly replaced with something brand new and extremely specific.
07:31:10 [Hixie]
xover: html5lib has already been used by several people as the frontend to an xml toolchain
07:31:16 [sbuluf]
(mjs, k, nevermind, and thanks)
07:31:17 [hsivonen]
xover: the solution is using XML tools except the XML parser and using an HTML5 parser that exposes an XML parser API in the place of the XML parser
07:31:26 [Hixie]
xover: several people have shown an interest in creating html5 parsers for xml toolchains in other languages
07:32:14 [mjs]
sbuluf: you might find people who can help you in #webkit on freenode, but there's a bunch of discussion there right now so probably best not to interrupt
07:32:33 [sbuluf]
mjs, tomorrow, then, and thanks =P
07:32:41 [mjs]
xover: using the SGML definition for deployed web content gives the wrong answer
07:33:04 [mjs]
seriously, it doesn't matter what the spec says, if you try to treat random web content as SGML your results will be wrong
07:33:09 [xover]
mjs: For cnn.com, yes. For my internal document archives, no.
07:33:31 [mjs]
well, you can keep parsing your internal document archives any way you want
07:33:41 [mjs]
if they work in browsers today, then HTML5 probably won't break them
07:33:57 [Hixie]
you don't need a spec for internal content
07:34:05 [Hixie]
you only need a spec for content that's going to have to interoperate
07:34:05 [xover]
In this context, I don't really care about what browsers do or do not support.
07:34:44 [hsivonen]
xover: the purpose of the spec is to establish common understanding between parties who don't have a priori bilateral agreements about the way of doing things
07:34:51 [Deeder]
Deeder has joined #html-wg
07:34:53 [xover]
Hixie: Internal content has much more need to interoperate, over decades and changes of systems.
07:35:07 [hsivonen]
xover: obviously, you can make agreements with yourself without a spec
07:35:55 [hsivonen]
xover: as I suggested, you can place a voluntary constraint on yourself to use XHTML5
07:45:42 [MikeSmith^]
MikeSmith^ has joined #html-wg
07:45:55 [xover]
hsivonen: What does your HTML5 checker do when fed, say, a HTML 3.2 document?
07:46:07 [ROBOd]
ROBOd has joined #html-wg
07:46:55 [hsivonen]
xover: now it says that there was an unsupported legacy doctype. once I upgrade the parser, it should complain but continue
07:47:30 [xover]
Processing it according to HTML5 rules I assume?
07:47:50 [hsivonen]
xover: once I upgrade the parser. the current parser predates HTML5 rules
07:48:11 [xover]
Hmm. Is this case discussed in your thesis?
07:48:54 [hsivonen]
xover: the fact that the proof of point parser does not implement the HTML5 parsing algorithm is discussed. legacy doctypes are not
07:50:02 [hsivonen]
xover: when I've put all this thesis stuff behind me, I my plan is to turn the parser into a real HTML5 parser (but no specific promises at this time)
07:50:14 [hsivonen]
s/I my/my/
07:53:03 [xover]
Hmm. I'm trying to wrap my head around what the implications of "HTML5" are for the body of documents that are actual honest to gosh SGML Valid HTML <=4.01 documents.
07:53:58 [hsivonen]
xover: SGML minimizations work as in browsers--not as in OpenSP
07:54:10 [hsivonen]
xover: comment parsing is browser-compatible
07:54:30 [hsivonen]
xover: you get a non-fatal (i.e. recoverable) parse error on doctype
07:54:31 [xover]
hsivonen: My main beef with the former HTML WG was that they refused to update the SGML Declaration to match what browsers actually implemented. :-)
07:54:34 [xover]
(btw)
07:55:08 [xover]
(on minimizations specifically, that is)
07:56:33 [xover]
Hmm. Ok, so it's possible that for some "edge" cases, processing legacy content with a HTML5 processor would render them non-conforming?
07:57:24 [hsivonen]
xover: non-conforming as far as HTML5 docement conformance goes, yes. however, they'd still be compatible processable as far as UA conformance goes
07:57:37 [xover]
Would this be the case if the document was not just DTD-valid but also conformant with the actual prose of the specs?
07:57:48 [hsivonen]
xover: yes
07:58:29 [xover]
Ok, so there are actually acknowledged incompatibilities between HTML5 and previous HTML standards?
07:59:00 [xover]
(again, completely ignoring what the world looks like from inside a browser here)
07:59:34 [hsivonen]
xover: to the extent the previous HTML standards don't match reality, yes
08:00:05 [hsivonen]
xover: for example, the definition of usemap is reality-compatible but different from what previous spec said.
08:00:46 [xover]
Are these considered bug fixes or necessary breaks with legacy (in general)?
08:01:01 [hsivonen]
xover: in WHATWG, compatibility is functional compatibility with deployed browsers and content--not preserving the requirements of previous specs
08:01:33 [hsivonen]
xover: when processing models change, bug fixes
08:01:45 [xover]
Sure. But I'm trying to figure out what that means for my areas of interest.
08:02:02 [hsivonen]
xover: when document conformance changes, some changes are motivated by aesthetics
08:02:23 [hsivonen]
xover: but those changes don't cause actual page breakage is UAs
08:02:33 [hsivonen]
xover: I mean bimorphic content models
08:03:20 [hsivonen]
xover: but even the bimorphic stuff is considered a bug fix where the bug was due to the limitations of DTDs
08:03:42 [hsivonen]
xover: bimorphic content model take either block or inline at a time but not a mix of them
08:04:57 [hsivonen]
xover: there's also the concept of structured inline to address that problem
08:05:39 [hsivonen]
xover: unfortunately though, legacy contraints limit the applicability of structured inline in the case where you'd want it the most
08:05:52 [hsivonen]
xover: that is, in <p> in text/html
08:07:53 [zdenko]
zdenko has joined #html-wg
08:08:03 [xover]
Ok, I think I'd need to see the output on a HTML5 conformance checker of legacy content on some sample set of documents to be able to asess the actual implications.
08:08:55 [hsivonen]
xover: please note that I haven't implemented the <font> stuff, because Hixie has indicated that it might not stand in the long run
08:09:02 [xover]
But I take it it's not in dispute that HTML5's backward compatibility is in terms of browser rendering and not general conformance.
08:09:23 [hsivonen]
right
08:09:39 [xover]
IOW, it's sort of a souped up Appendix C mode rather then a strict superset.
08:10:06 [xover]
(not meaning to attach the negative connotations of AppC here!)
08:11:57 [kazuhito]
kazuhito has joined #html-wg
08:12:48 [xover]
Anyways, I need to head off to work. Thank you (all) for your time and the interesting discussions!
08:13:30 [hsivonen]
you're welcome. see you
08:23:04 [Shunsuke]
Shunsuke has joined #html-wg
08:54:16 [Shunsuke]
Shunsuke has joined #html-wg
08:59:28 [Shunsuke]
Shunsuke has joined #html-wg
09:02:56 [xover]
xover has joined #html-wg
09:02:56 [Dashiva]
Dashiva has joined #html-wg
09:05:43 [Hixie]
Hixie has joined #html-wg
09:13:49 [gavin_]
gavin_ has joined #html-wg
09:23:23 [Shunsuke]
Shunsuke has joined #html-wg
09:29:12 [claudio]
claudio has joined #html-wg
10:05:00 [Shunsuke]
Shunsuke has joined #html-wg
10:29:24 [hasather]
hasather has joined #html-wg
10:35:24 [mjs]
mjs has joined #html-wg
10:54:41 [karl]
karl has joined #html-wg
11:21:44 [gavin_]
gavin_ has joined #html-wg
11:21:53 [kazuhito]
kazuhito has joined #html-wg
11:21:53 [Lachy]
Lachy has joined #html-wg
12:04:18 [mw22]
mw22 has joined #html-wg
12:07:05 [zcorpan]
zcorpan has joined #html-wg
12:28:53 [Shunsuke]
Shunsuke has joined #html-wg
12:53:24 [gsnedders]
gsnedders has joined #html-wg
12:54:42 [dfgdsfg]
dfgdsfg has joined #html-wg
12:55:09 [ManyMen]
Are there any new features in html 5?
12:57:01 [ManyMen]
Are there any new features in html 5?
12:58:33 [zcorpan]
ManyMen: yes, some of which are already implemented in browsers, see http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers
12:59:00 [ManyMen]
I found this page http://simon.html5.org/html5-elements.
12:59:06 [zcorpan]
ok
12:59:27 [ROBOd]
ROBOd has joined #html-wg
12:59:53 [ManyMen]
If it is right , then our knowledge in html will be useless
13:00:08 [zcorpan]
how so?
13:00:27 [ManyMen]
html 5 seems to be harder than the other versions
13:00:47 [hsivonen]
ManyMen: why?
13:01:00 [ManyMen]
there are more elements
13:01:08 [ManyMen]
and we must learn html again
13:01:15 [ManyMen]
from the beginnig
13:01:19 [ManyMen]
beginning
13:01:38 [hsivonen]
ManyMen: well, there wouldn't be any point in writing a new spec if it didn't offer anything new
13:01:53 [zcorpan]
ManyMen: no, you can continue with your current knowledge of html and just use any new feature you fancy
13:02:12 [zcorpan]
ManyMen: with html5, you *don't* need to relearn anything
13:02:39 [ManyMen]
actually you are right
13:03:09 [hsivonen]
zcorpan: in fairness, there are a couple of gotchas if one cares about document conformance
13:03:21 [hsivonen]
zcorpan: particularly the content model of <div>
13:03:23 [zcorpan]
hsivonen: yes, that's true
13:03:40 [ManyMen]
after html 5 there would be html 6 ?
13:03:47 [zcorpan]
probably
13:04:29 [ManyMen]
but some of the html 5 elements might not use in our browsers
13:04:51 [ManyMen]
might not work*
13:05:12 [zcorpan]
indeed, much is still not implemented
13:07:00 [ManyMen]
ok thanks very much
13:28:49 [gavin_]
gavin_ has joined #html-wg
13:33:41 [h3h]
h3h has joined #html-wg
13:37:52 [wilhelm]
wilhelm has joined #html-wg
13:57:24 [Deeder]
Deeder has joined #html-wg
14:00:27 [Lachy]
Tina is basically arguing that implementers (specifically Lynx, in this case) shouldn't try to implement HTML5 until it has a W3C logo
14:01:38 [Lachy]
she also disgrees with my statement that "HTML4 isn't anywhere near close to interoperable, or even fully implementable in the real world."
14:01:53 [Lachy]
I'm really interested to see her arguments against that
14:02:34 [Deeder]
Deeder has joined #html-wg
14:04:05 [xover]
Perhaps she does not see any fundamental reason why HTML4 isn't implementable in the real world?
14:11:15 [MikeSmith]
Lachy - not sure it's worth taking any time at all to care much about whether Lynx supports HTML5 or about what there they think about it
14:11:41 [MikeSmith]
does Lynx have any CSS support at all? or Javascript support?
14:12:15 [Lachy]
Lachy has joined #html-wg
14:13:11 [MikeSmith]
It seems to me a stretch to even use the term "Web browser" for a CSS-less or Javascript-less UA
14:13:21 [MikeSmith]
these days
14:13:45 [MikeSmith]
it's more like a pager that lets you read Web pages
14:13:58 [MikeSmith]
or like antiword(1) is to MS Word
14:14:46 [Philip`]
Hmm, the internet gets confusing when someone has the same name as you
14:28:29 [myakura]
myakura has joined #html-wg
14:33:12 [billmason]
billmason has joined #html-wg
14:35:16 [h3h]
h3h has joined #html-wg
14:37:15 [kazuhito]
kazuhito has joined #html-wg
15:01:33 [heycam]
heycam has joined #html-wg
15:05:45 [loic]
loic has joined #html-wg
15:07:37 [krijnh]
krijnh has joined #html-wg
15:09:10 [briansuda]
briansuda has joined #html-wg
15:10:28 [Shunsuke]
Shunsuke has joined #html-wg
15:14:26 [hsivonen]
MikeSmith: CSS is supposed to be optional and disabling scripting is legitimate.
15:15:11 [hsivonen]
MikeSmith: even though Lynx isn't as much of Web browser as Firefox, Opera, Safari and IE, it would still be good if Lynx supported HTML5
15:31:43 [zcorpan]
and the spec should be written in a way such that Lynx could be conforming (without CSS, scripting, images, video, etc), imho
15:31:53 [zcorpan]
(probably is already)
15:32:40 [zcorpan]
(the spec, that is)
15:32:45 [MikeSmith]
hsivonen - of course it would good. I just don't think it's going to be a terrific hardship for the world if it doesn't
15:34:00 [zcorpan]
lynx supports some html 3.0/html+ features, doesn't it?
15:35:58 [gavin_]
gavin_ has joined #html-wg
15:49:24 [briansuda]
briansuda has joined #html-wg
16:09:20 [Ashe]
Ashe has joined #html-wg
16:39:11 [Pemou]
Pemou has joined #html-wg
16:40:44 [Pemou]
Hello , i am very confused. I just read http://blog.whatwg.org/faq/#xhtml5 which is a page for html 5. HTML 5 or XHTML ? I do not know .
16:43:01 [olli-]
olli- has joined #html-wg
16:43:12 [gsnedders]
Pemou: for both
16:43:42 [Pemou]
No , i mean HTML or XHTML . Which one to use ?
16:43:53 [Pemou]
Everything is so confusing
16:44:08 [wilhelm]
That depends on your needs.
16:44:45 [Pemou]
Yes , but they are the same .
16:45:12 [zcorpan]
Pemou: you probably want to be using text/html. then if you use "html syntax" or "xhtml syntax" is mostly a matter of taste, personal preference or faith in markup gods :)
16:45:46 [wilhelm]
Yes and no. XHTML is parsed as XML, HTML is not. This is good or bad depending on your needs and requirements.
16:45:46 [Pemou]
they say that xhtml syntax is better
16:45:53 [gsnedders]
"they"?
16:46:06 [Pemou]
i generally speak
16:46:10 [Pemou]
someone
16:46:38 [Pemou]
w3schools.com for example
16:46:42 [wilhelm]
Unless you require XML features (easy to parse, draconian error handling makes it easy to spot errors), you should stick with HTML.
16:47:06 [Pemou]
Are there any errors in XHTML ?
16:47:14 [gsnedders]
yes, but none are fatal
16:47:18 [zcorpan]
Pemou: that is mostly misguided, the syntax doesn't give you any advantages, and what they usually list as advantages can be done in html as well (e.g. using css)
16:48:29 [Pemou]
Well , now i am thinking it better , a customer who wants to a site , he will not see the code but the appearance
16:48:42 [Pemou]
If i mix html and xhtml ?
16:49:44 [zcorpan]
Pemou: in any case, "xhtml syntax" is allowed in text/html-html5, so in practise you can use either (or a mix)
16:50:29 [Pemou]
In XHTML , document type declaration is necessary ?
16:50:42 [zcorpan]
depends on how you define "XHTML"
16:50:55 [zcorpan]
in text/html, you need one to not trigger quirks mode in browsers
16:51:00 [zcorpan]
in XML, no
16:52:04 [Pemou]
and when html 5 is ready ?
16:52:20 [wilhelm]
2010, perhaps?
16:52:36 [zcorpan]
depends on how you define "ready" :)
16:52:41 [Pemou]
3 years is a long time
16:53:07 [zcorpan]
Pemou: you can use new features from html5 when they are implemented in browsers
16:53:14 [olli-]
Pemou: it took ie 5 years to fix position:fixed.. 3 years isnt really that bad
16:53:34 [Pemou]
lol
16:54:22 [zcorpan]
Pemou: you can use http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers to keep track of what is implemented
16:54:34 [Pemou]
thanks
16:57:09 [Pemou]
Netscape navigator is a browser ?
16:59:52 [Pemou]
?
17:00:17 [zcorpan]
yes
17:03:43 [Pemou]
I have it , but it copies ie and ff
17:04:26 [Pemou]
ok thanks bye
17:04:28 [Pemou]
Pemou has left #html-wg
17:27:05 [Voluminous]
Voluminous has joined #html-wg
17:30:27 [Sander]
Sander has joined #html-wg
17:30:29 [zdenko]
zdenko has joined #html-wg
17:43:47 [gavin_]
gavin_ has joined #html-wg
17:53:32 [kingryan]
kingryan has joined #html-wg
18:03:42 [dbaron]
dbaron has joined #html-wg
18:06:00 [mjs]
mjs has joined #html-wg
18:45:04 [mjs]
mjs has joined #html-wg
18:57:51 [beowulf]
beowulf has joined #html-wg
19:51:26 [gavin_]
gavin_ has joined #html-wg
20:14:36 [Hixie]
heh, i wonder if people will no longer want hyatt as editor now that he's pointed out that he disagrees with me on versionning
20:18:01 [Dashiva]
Only if they think he's going to be a real editor, rather than a figurehead
20:52:07 [dbaron]
dbaron has joined #html-wg
21:12:30 [gsnedders]
it seems to be the major implementers v. everyone else when it comes to versioning in HTML5
21:13:29 [Hixie]
actually there are people from apple and mozilla pro versioning, and people from apple and mozilla anti-versioning
21:13:43 [hsivonen]
gsnedders: how so? dbaron argued against versioning and cwilso argued in favor
21:13:52 [Hixie]
from having spoken to them off-list, i get the feeling those in favour are those who haven't thought through the implications
21:13:59 [Hixie]
and we've only seen one microsoft opinion so far
21:14:18 [Hixie]
though microsoft tend to be more in unison at wg meetings
21:14:19 [gsnedders]
hsivonen: sure, there are exceptions, but it seems mostly that way
21:16:11 [gsnedders]
I think cwilso has had valid reasons for saying what he has said, but I also think all the modes need to be spec'd
21:17:09 [Hixie]
which basically doubles are workload, assuming one more version
21:17:32 [gsnedders]
we already need to spec quirks mode anyway
21:17:50 [Hixie]
most of quirks mode is in css
21:18:03 [Hixie]
and the csswg are blissfully ignoring it
21:34:56 [DanC]
DanC has joined #html-wg
21:35:00 [DanC]
RRSAgent, pointer?
21:35:00 [RRSAgent]
See http://www.w3.org/2007/04/23-html-wg-irc#T21-35-00
21:58:00 [gavin_]
gavin_ has joined #html-wg
22:02:37 [dbaron]
dbaron has joined #html-wg
22:10:51 [beowulf]
beowulf has joined #html-wg
22:13:52 [zcorpan]
Hixie: if all html quirks that are required to be implemented in order to render the web are specced in html5 (for both quirks mode and standards mode), then html handling will only have one mode
22:17:49 [jgraham]
zcorpan: Thats depends how you define "mode" surely? If the spec says "if the doctype is {some quirks mode doctype} do foo otherwise do bar" it's two modes but one spec, no?
22:19:07 [zcorpan]
jgraham: yes. i meant "always do foo, regardless of doctype"
22:19:33 [hasather]
hasather has left #html-wg
22:19:56 [zcorpan]
which might include <!--> and <p><table>
22:20:16 [jgraham]
Oh, OK. I didn't think it was possible to make the quirks/standards distinction go away and still render the web
22:20:33 [zcorpan]
not for css, no
22:20:48 [zcorpan]
for html, i hope
22:21:01 [hasather]
hasather has joined #html-wg
22:22:42 [Philip`]
Does <body bgcolor="bogus"> count as HTML? That appears to give different DOMs in quirks vs standards, so I guess it's an HTML parsing issue
22:23:46 [zcorpan]
Philip`: what happens in xhtml?
22:23:53 [zcorpan]
er
22:23:55 [zcorpan]
nm
22:24:45 [zcorpan]
but if it's parsing, then yes
22:27:34 [zcorpan]
if we don't want to reintroduce this quirk into standards mode, then html will need two modes
22:28:44 [Philip`]
XHTML seems to do the same as HTML-standards - getAttribute('bgcolor') in FF gives 'bogus', and in Opera gives ''
22:29:01 [zcorpan]
ok
22:29:03 [Philip`]
(whereas both give '#b00000' in quirks)
22:29:39 [zcorpan]
does any browser not do this in quirks? does any do it in standards?
22:30:39 [zcorpan]
(not asking you to do my homework, only curious if you've already tested :) )
22:31:56 [Philip`]
IE does #b00000 in both, and apparently Safari does too
22:32:29 [zcorpan]
then it wouldn't be too harmful to reintroduce the quirk in gecko and opera in standards mode also :)
22:34:16 [zcorpan]
still need to find out whether content on the web relies on this quirk, but i'm sure it does
22:35:10 [Philip`]
Okay, I suppose that's reasonable :-)
22:36:38 [Philip`]
Ooh, I didn't have access to IE when this was discussed yesterday, but now I do, and it explains my ancient confusion as to why <body bgcolor="grey"> went green - I always assumed it was matching the best prefix ("gre..."), but actually it's ignoring the non-hex characters and getting #00e000
22:37:27 [zcorpan]
yep
22:37:57 [Philip`]
(Opera and FF implement the CSS3/SVG colour name "grey" as #808080, in both modes; IE gives green in both)
22:39:07 [zcorpan]
prepending the "#" seems be be parsing too
22:39:52 [Philip`]
(I would hope that not many sites depend on that behaviour - if they wanted green, they'd type in "green", and if they accidentally typed in "grey" they'd have quickly noticed it wasn't quite the design they wanted and they should have fixed the spelling...)
22:40:38 [zcorpan]
grey == gray in other browsers
22:44:12 [h3h]
silly people. it's "gray"
22:45:48 [zcorpan]
h3h: i don't care about which spelling is correct, i care about knowing (and perhaps speccing) what browsers have to implement
22:45:56 [h3h]
hehe :)
22:46:04 [h3h]
both, to be safe
22:46:45 [zcorpan]
they're both css3 color keywords, so yeah
22:47:09 [zcorpan]
however introducing more keywords here might break stuff
22:47:23 [zcorpan]
so the list of keywords might not be the same as css3 keywords
22:47:32 [h3h]
you think apps depend on "grey" rendering as green in IE?
22:48:11 [zcorpan]
given the other browser treat it as a keywords, no
22:48:17 [h3h]
(not that it would matter anyway, because you'd have to opt in to really super extra ultra standards mode first)
22:48:33 [Philip`]
CSS3 says it got the colours from SVG, but SVG doesn't say where its list came from - does anyone know why SVG has both "grey" and "gray" variants?
22:49:09 [Hixie]
they come from the x11 rgb.txt file iirc
22:50:50 [Philip`]
Hmm, my rgb.txt has at least 202 extra grey values (gray0..gray100, grey0..grey100) so it's not just copying all of those
23:02:28 [DanC]
DanC has left #html-wg
23:18:31 [Zoffix]
Offtopic: I had problems subscribing to W3C mailing lists. I would send requests but get no answer. Bert took a look and it seems he fixed the issue. I am getting messages, but I've just sent one to the mailing list and did not receive it from the mailing list. Is that normal that I would not get my own messages?
23:19:03 [Hixie]
no
23:19:13 [Hixie]
the first time you post you should get a message asking if you mind being archived
23:20:29 [Zoffix]
I see. So I am not getting any, umm "system" messages still :\ Wonder what's going on, since I did try from an alternative e-mail address when I had that subscribing issue.
23:24:44 [Hixie]
maybe the messages are getting caught in a spam filter?
23:26:50 [Zoffix]
Thing is that I don't have any spam filters. At least I am not aware of any. And the subscription problems were on 2 addresses not related to each other in any way (except both have `zoffix` string)
23:27:24 [heycam]
heycam has joined #html-wg
23:29:17 [Hixie]
weird
23:30:16 [Zoffix]
Bert wrote: As far as I can see, our mailing list software got your requests and
23:30:16 [Zoffix]
sent you back a confirmation message with a numeric code. I don't know
23:30:16 [Zoffix]
why you didn't get it.
23:30:16 [Zoffix]
Anyway, I added <admin@zoffix.com> by hand. You should now start
23:30:16 [Zoffix]
receiving mail from the <www-style@w3.org> mailing list.
23:40:52 [h3h]
hooray, Sam Ruby joined representing IBM -- http://www.intertwingly.net/blog/2007/04/23/HTML-WG-me
23:58:04 [hasather]
hasather has left #html-wg