00:00
<Hixie>
oh i don't know that it could be quantified
00:01
<othermaciej>
is there any way to show evidence for or against?
00:01
<Hixie>
but it certainly is clear to me that you can improve the quality of almost any document with <font>, style="", or <div>s-containing-inlines, whereas i don't think the same can be said of all documents that do not have those characteristics.
00:01
<Hixie>
objectively? i don't know
00:01
<Hixie>
i haven't looked at it in detail
00:02
<othermaciej>
obviously it's hard to argue against your proposal if it is based on an an unfalsifiable claim
00:03
<Hixie>
it's not really a proposal
00:03
<Hixie>
just an idea
00:03
<Hixie>
i don't think we can drop style="", <font>, and <div>s-containing-inlines altogether
00:03
<othermaciej>
ok, s/proposal/idea/
00:03
<Hixie>
but i do think that we should discourage their use in favour of the alternatives
00:03
<Philip`>
Could call it "Compatibility" instead of "Low quality", and have it provide the features that are compatible with implementations and content and forbid things that are likely to cause authors pain and not attempt to make subjective judgements of value
00:03
<othermaciej>
dropping all those would certainly make a lot of documents nonconforming for seemingly-gratuitous reasons
00:04
<Hixie>
Philip`: it's not really compatibility either, since if we were desigining the language from scratch, you'd still want these features
00:04
<othermaciej>
I just don't see any reason to discourage style="" if <style scoped> won't be similarly discouraged
00:04
<othermaciej>
the latter can be abused in all the same ways, the main difference is that it is more verbose
00:05
<Hixie>
othermaciej: i'm not even talking about legacy content, even for a brand new language with no content i think these features are necessary, e.g. for prototyping
00:05
<othermaciej>
and less compatible with compatible with existing UAs
00:05
<Hixie>
nor am i talking about abuse
00:05
<Hixie>
you can abuse <ins> and <del>
00:05
<Hixie>
and anything else
00:05
<Hixie>
i'm talking about completely conforming and correct uses
00:05
<othermaciej>
ok, let me put it this way
00:05
<othermaciej>
I don't think systematically replacing all style="" with <style scoped> would improve any documents
00:05
<Hixie>
i agree
00:06
<Hixie>
it's a case-by-case problem
00:06
<Hixie>
sometimes style="" has to be replaced with samething else, e.g. using a different element altogether
00:06
<othermaciej>
thus, creating an incentive to do so (badge-seeking behavior, etc) seems like a bad idea
00:07
<Hixie>
granted, but it seems better than giving the impression that a page that uses only <div>s and style="" is fine.
00:08
<Hixie>
bbl
00:16
<othermaciej>
I agree such documents are not great; just not sure how to make a good machine-checkable rule that detects bad style
00:40
<Hixie>
yeah
00:52
<zcorpan_>
Hixie: i think having different conformance levels is a bad idea. we should just allow style="" and <div>s containing inlines but perhaps discourage the former for authors
00:54
<Hixie>
how?
00:55
<zcorpan_>
by saying that they are conforming, and then having a note about why style="" can be harmful
00:56
<zcorpan_>
this way, badge hunters won't replace their style=""s with more verbose but no better alternatives, and people can cite the spec about why people shouldn't use style=""
00:57
<zcorpan_>
(i don't think <div>s containing inlines is harmful)
00:59
<Hixie>
there are pages that consist of nothing but <div>s and style=""s
00:59
<Hixie>
or even just <div>s and stylesheets
01:00
<zcorpan_>
indeed
01:01
<zcorpan_>
they are not going to disappear if we label them non-conforming, but some might be rewritten to use constructs that pass validation without increasing the quality or semantics
01:02
<zcorpan_>
i don't think labeling them non-conforming will result in them being rewritten to use semantic markup
01:04
<Hixie>
it might not affect _those_ pages, but i think it would help with people the same way that having "strict" vs "transitional" has helped some in terms of mindshare growth
01:05
<zcorpan_>
hmm, perhaps
01:07
<Philip`>
That seems to resulted in people choosing to use transitional twenty times more often than strict
03:40
<Lachy_>
<alt for=idref> is exactly the kind of explicit association that won't work in reality. I do not understand why some people have concluded explicit markup associations are the only way to solve the problem - they seem to be ignoring the expressiveness of natural language
06:56
<Hixie>
"Fine, so my comparison wasn't perfect. None ever are." is an interesting way of dismissing someone's counterargument that i hadn't seen before
09:46
<Dashiva>
Lachy_, Hixie: Grumbling in here is just going to spawn another formal objection, be careful ;)
09:47
<Lachy_>
Dashiva: we're still allowed to discuss issues in here
09:48
<gsnedders>
Lachy_: even though it's logged in the same place?
09:49
<Lachy>
gsnedders: the fact that it's logged doesn't matter
09:50
<Lachy>
as long as our comments focus on the issue and not attack anyone personally, it's fine
10:02
<hsivonen>
hmm. apparently the W3C survey system uses colons in ids
10:18
<Hixie>
i'll be damned if i'm going to let people stop me from chatting about html on irc
10:28
<ROBOd>
<hello world=all>
10:29
<ROBOd>
i have a question: is there any implementation of the outlining algorithm?
10:33
<krijnh>
Man, that Lachy is irritating me
10:33
<krijnh>
Ow, wait
10:33
<Lachy>
?
11:57
<Philip`>
ROBOd: Does the implementation in http://www.whatwg.org/specs/web-apps/current-work/#outlines count?
12:00
<zcorpan_>
re sam ruby's idea with cdata, isn't it better to hide the text with css than to use a specific syntactic construct?
12:00
<ROBOd>
Philip`: not really. i was thinking of some independent implementation
12:01
<ROBOd>
Philip`: one that also determines which heading and section applies to a particular node
12:01
<zcorpan_>
svg\:svg { display:none; } should do the trick, also for browsers that don't support declarative namespaces
12:01
<ROBOd>
using the given algorithm
12:02
<zcorpan_>
ROBOd: i don't know of any
12:02
<Philip`>
zcorpan_: You'd want to hide it from browsers that support namespaces but don't support SVG
12:03
<Philip`>
(Also svg\:svg would hide it from IE, which does support namespaces)
12:03
<zcorpan_>
Philip`: sam's proposal doesn't address that either
12:03
<zcorpan_>
(but it doesn't support svg, which is why he wanted to hide the text from ie)
12:04
<zcorpan_>
Philip`: however, other browsers already support svg, so that is a non-issue
12:05
<hsivonen>
hmm. I now see that the quality of English in my reply to Sam is really poor. fortunately, English doesn't use Draconian error handling.
12:06
<hsivonen>
my problem is that I don't see my own errors until I have flushed the writing flow from my head
12:06
<zcorpan_>
is error handling for English defined? :)
12:06
<zcorpan_>
hsivonen: try reading backwards, that sometimes helps finding errors
12:07
<zcorpan_>
but mostly just typos
12:09
<Philip`>
zcorpan_: I suppose SVG is already supported everywhere but if you used e.g. MathML then you wouldn't want non-MathML-supporting browsers showing all the raw textual content
12:09
<Philip`>
(but then you probably wouldn't want it to just show nothing at all)
12:10
<zcorpan_>
indeed. so don't do m\:math { display:none; } ... ;)
12:12
<zcorpan_>
i don't know of any good fallback story for inline mathml
12:13
<zcorpan_>
you either use mathml or GIF or html tables
12:31
<hsivonen>
it is interesting how people are complaining on www-validator about the validator now being more correct with XML
14:07
annevk
notices replies to ancient e-mails in his mailbox, directed to fora⊙an :-o
15:06
<gsnedders>
annevk: you were referencing a script by Bert Bos when discussing the formatting of the spec (pointlessly at this stage), is it available anywhere?
15:41
<zcorpan_>
wow http://www.w3.org/TR/pronunciation-lexicon/
16:04
<annevk>
gsnedders, if you're a W3C Member
16:12
<Lachy>
Hixie was right, Ratatouille is really good movie :-)
17:22
<gsnedders>
Ratatouille isn't out here till Oct :(