00:07
<Von_Davidicus>
Is this statement accurate? "The biggest difference between HTML 4.01 and HTML5 is that HTML5 has more elements you can work with."
00:07
<zewt>
...
00:08
<Von_Davidicus>
Should I take that as a no?
00:08
<Philip`>
Perhaps the biggest difference is that HTML5 is defined
00:09
<Von_Davidicus>
That's... rather vague.
00:09
<zewt>
no. not being defined is vague
00:10
<jarek>
Philip`: really? I though that no one knows what "HTML5" actually means
00:12
<jarek>
I guess the current common definition is "everything shiny done with HTML/CSS/SVG/JS"
00:12
<Von_Davidicus>
It apparently means HTML that is defined--which means it's not vague--which means it's defined--which means it's not vague--which means I've no idea what either Phillip` or zewt are talking about.
00:12
<Von_Davidicus>
:)
00:13
<Philip`>
jarek: I meant that the thing which I mean by the term HTML5 is defined (not that the term HTML is defined)
00:14
<Philip`>
Von_Davidicus: Perhaps a less vague statement: Perhaps the biggest difference is that HTML4 is largely undefined
00:14
<Philip`>
(That is, the thing referred to as HTML4, not the term HTML4)
00:15
<Von_Davidicus>
No less vague, I'm afraid--what does "defined" mean in this case?
00:16
<jarek>
there is HTML4 spec, I guess this makes it "defined"
00:16
<Philip`>
I mean there is a proper definition of how the language's features behave and interact
00:17
<Philip`>
whereas HTML4 is mainly a high-level list of features and you have to figure out the details yourself
00:18
<Von_Davidicus>
Please remember--there are those of us who simply type the code. Some of us are better at it than others, but I'm one of those that start out with <?xml version="1.0" encoding="utf-8"?> (a pretentiousness habit, I know) and put the elements in order so I have something presentable to put on the web.
00:21
<Philip`>
(Random example: compare http://www.w3.org/TR/html4/types.html#h-6.5 vs http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#colors )
00:22
<Philip`>
(The features are basically comparable, but HTML5 unambiguously defines all the details you need to know whereas HTML4 doesn't bother)
00:23
<jcranmer>
another good example is encodings
00:23
<jcranmer>
HTML5 explains very clearly who wins out when attempting to figure out a document's encoding
00:26
<Von_Davidicus>
Okay, how about this statement: "Q: Will learning HTML 4.01 hamper learning HTML5? A: No. Even learning HTML 2.0 will do a world of good; the fundamentals haven't really changed, and most of the elements are still there."
03:04
<karlcow>
MikeSmith: ping?
03:04
<karlcow>
in case you are here
03:04
<karlcow>
http://dev.w3.org/html5/markup/table.html#table
03:04
<MikeSmith>
karlcow: yeah, I'm here
03:05
<karlcow>
I was reading this, because I didn't remember if a table could contain more than one thead
03:05
<karlcow>
"an optional caption element, followed by zero or more colgroup elements, followed by an optional thead element, followed by"
03:06
<karlcow>
and then I have an English grammar doubt
03:06
<Von_Davidicus>
... What the heck did the "rules" attribute on tables do?
03:06
<MikeSmith>
what's the grammar issue?
03:06
<karlcow>
is "an optional caption element" equivalent to "one optional caption element"
03:06
<MikeSmith>
Hixie: not updating because I need to flip the boilerplate back to ED
03:07
<MikeSmith>
karlcow: yes
03:07
<karlcow>
ok. So each time I see "an" I shoud consider "one"
03:07
<MikeSmith>
yes
03:07
<MikeSmith>
same for "a"
03:08
<karlcow>
yup
03:08
<karlcow>
thanks
03:08
<karlcow>
so there is only one head allowed.
03:08
<karlcow>
clarified.
03:08
<karlcow>
:)
03:08
<MikeSmith>
otherwise it always says "one or more" or "zero or one"
03:09
<karlcow>
yup understood. make sense.
03:12
<Von_Davidicus>
I have a question about HTML5, based on something I used to do. On occasion, I would type in a word, and the browser would interpret that as a colour. Later, I would find out that, say, "Blood" would result in #B000D0. Will that still work in HTML5? Or was that simply a bug in older versions of HTML?
05:37
<kennyluck>
foolip, regarding big5-uao, I got additional feedback from Chrome users: http://www.ptt.cc/bbs/Browsers/M.1334342552.A.FA8.html and http://www.ptt.cc/bbs/Browsers/M.1334375132.A.293.html . In summary, for the question "what do you do if you can't read these pages", two said "switch to IE (probably with the UAO package installed)" and one said "switch to Firefox". So, *shrug*.
05:38
<kennyluck>
People don't care. Really.
05:42
<Von_Davidicus>
I can see it just fine in Google Chrome--if I'm supposed to be looking at Chinese characters.
05:45
<kennyluck>
Von_Davidicus, oh these are the feedback from the users, not the test pages. foolip reads Chinese.
05:47
<Von_Davidicus>
Oh, okay.
05:47
<Von_Davidicus>
Question: Are server-side image maps a part of HTML5?
05:51
<Von_Davidicus>
Never mind, I found it. :)
06:50
<annevk>
hmm
06:50
<annevk>
decodeURI is only useful for pages that use utf-8 as encoding
08:00
<Von_Davidicus>
I am bewildered...
08:01
<Von_Davidicus>
What is wrong with "<meta http-equiv="Content-Type" content="application/xhtml+xml" />" ? The W3C validator's saying that I'm not supposed to use "Content-Type."
08:02
<Ms2ger>
It doesn't do anything
08:03
<Von_Davidicus>
That's not the point; what am I supposed to use there>?
08:04
<Ms2ger>
What are you trying to do?
08:04
<Von_Davidicus>
Create a valid XHTML5+SVG webpage.
08:04
<Ms2ger>
Just drop it
08:05
<annevk>
http://www.whatwg.org/C#attr-meta-http-equiv-content-type
08:05
<annevk>
read up on that Von_Davidicus
08:05
<annevk>
in particular "The Encoding declaration state may be used in HTML documents, but elements with an http-equiv attribute in that state must not be used in XML documents."
08:14
<Von_Davidicus>
*Mind goes sproing*
08:17
<Von_Davidicus>
You guys make it so hard to pile on the <meta> elements, you know that? :D
09:38
<annevk>
hmm
09:39
<annevk>
for code points -> bytes, browsers do not always use an index that is a strict conversion of the one used for bytes -> code points
09:39
<annevk>
that is, aside from additional code points for fallback mappings, the order is not consistent
09:40
<Von_Davidicus>
Is this for Numeric Character References?
09:40
<annevk>
although Opera appears to use reverse order (matters for duplicate code points), in Gecko and Chrome it's rather random
09:40
<annevk>
no shift_jis
09:40
<Von_Davidicus>
Oh, okay.
09:41
<annevk>
not really :)
09:42
<annevk>
but it seems more the result of internal reverse mapping scripts, rather than a conscious choice
10:01
<Philip`>
Von_Davidicus: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value does the blood->#b000d0 thing
10:01
<Philip`>
Von_Davidicus: It's not an intentional feature, it's just a weird implementation detail of early browsers that web pages started relying on
10:02
<Philip`>
Von_Davidicus: so now HTML5 specifies how to do it
10:03
<Von_Davidicus>
I actually came up with a bit of JavaScript that would set the "color" attribute of a <font> element to whatever I typed in, then check what the styling of that <font> element was and spit back the hex code. That's when I noticed the word-hex code connection.
10:03
<Von_Davidicus>
But that's rather cool.
10:07
<Von_Davidicus>
Am I right in my guess that a lot of the work in creating HTML5 is deciding how to actually *codify* all the weird stuff us amateurs did?
10:12
<Philip`>
Von_Davidicus: Yes, though the weirdest stuff is done by professionals :-)
10:12
<Von_Davidicus>
... hadn't thought about it that way.
10:18
<Philip`>
Von_Davidicus: Almost all web pages are invalid, so if you want to write a real-world web browser then you have to deal with invalid content in a way that makes those pages work, so HTML5 tried to define how you should deal with invalid content, to stop the situation where browsers have to reverse-engineer each other to copy behaviour
10:19
<Von_Davidicus>
Does that invalidate my advice in an essay I wrote that said "You should never confuse a browser or make it guess at what you want to do"?
10:21
<annevk>
yeah, http://www.whatwg.org/C#syntax-errors explains why you should care about syntax errors
10:22
<Philip`>
Von_Davidicus: As an author, you should try to avoid thing that you think might confuse browsers, because you'll probably confuse yourself and suffer from bugs
10:23
<Philip`>
Von_Davidicus: (though as a browser developer you have to deal with the reality that most authors ignore that advice)
10:23
<Von_Davidicus>
I was thinking inconsistent rendering of the page.
10:25
<Von_Davidicus>
I've been working on an HTML book for several years, even before XHTML 2.0 coughed and rolled over. Unfortunately, that means it focuses mostly on HTML 4.01 and XHTML 1.0
10:28
<Philip`>
You need to focus on newer buzzwords :-)
10:28
<Von_Davidicus>
Hey, when I started, XHTML WAS the buzzword.
10:29
<Von_Davidicus>
Anyways, a lot of the statements I've asked about accuracy on comes from that book.
10:29
<Philip`>
"HTML5" is the current buzzword, but it's probably going to become obsolete pretty soon, so you should try to come up with a new one you can popularize and then immediately publish a book about
10:30
<Von_Davidicus>
Hmmm... an alternative to JavaScript that at least SEEMS to make sense? :)
10:33
<Von_Davidicus>
I wouldn't want to call it COBOLscript, lest the readers get suspicious.
10:34
<annevk>
Von_Davidicus: http://html5forwebdesigners.com/history/index.html might be worth reading
10:37
<Von_Davidicus>
"If we had waited for every browser to completely support CSS 2.1 before we started using any of it, we would still be waiting." Heck, there's an aspect of HTML 4.01 that no browser I know of supports.
10:38
<Von_Davidicus>
Specifically, the "declare" attribute of the <object> element. I spent MONTHS trying to get it to work, finally asked for help, and discovered the truth.
10:38
<Ms2ger>
There's lots of nonsense in HTML4
10:39
<Von_Davidicus>
What comes to mind, Ms2ger?
10:40
<Ms2ger>
longdesc
10:40
<Ms2ger>
table summary
10:40
<Ms2ger>
SGML
10:42
<Von_Davidicus>
It seems the "axis" attribute in <td> got chucked.
10:45
<Von_Davidicus>
Kind of too bad; it was a nice "Dump javascript keywords in" attribute, since it did virtually nothing else. :)
10:47
<Philip`>
That sounds like a horrid abuse of semantics :-p
10:48
<Philip`>
(Nowadays you should use a data-* attribute)
10:49
<Von_Davidicus>
Let me tell you about abuse. Did you know if you put a <dd> start tag in front of a <p> element (<dd><p>[Content here]</p>), the paragraph will be indented?
10:49
<niloy>
can someone suggest me the best way to get cross-browser audio working?
10:49
<Von_Davidicus>
Guess who indented THAT way a decade or so ago? :p
12:05
<Ms2ger>
Fascinating how css3-background has normative references to HTML4 and XHTML1.1
12:08
<Von_Davidicus>
Oh?
12:46
<gsnedders>
Oh, for the html/body element special case?
12:47
<annevk>
yeah
12:47
<annevk>
CSS ought to depend on DOM instead and just do a few namespace checks instead
12:47
<annevk>
imo
12:49
<Ms2ger>
But you can use it for non-DOM trees!
12:51
<annevk>
there's so much wrong with that argument
13:04
<charlvn>
does anyone have an idea which is the right handling - firefox's or webkit's? https://gist.github.com/2384288
13:05
<Ms2ger>
No
13:06
<Ms2ger>
Maybe if you had a test case without jquery obfuscation
13:06
<charlvn>
Ms2ger: ok lemme write one
13:21
<Philip`>
charlvn: I thought the point of 'ready' is that it can (but doesn't have to) fire before all the resources have downloaded, and if an image hasn't been downloaded yet then it's reported as 0x0
13:21
<Philip`>
so both browsers are perfectly valid and sensible
13:22
<charlvn>
Philip`: yes exactly, according to me, webkit's handling is the most sensible
13:22
<charlvn>
firefox seems to only fire the event after the image has been loaded
13:22
<Philip`>
Maybe Firefox is faster at loading images from cache
13:23
<charlvn>
perhaps
13:24
<annevk>
hmm
13:24
<annevk>
so the JIS X 0212 encoder is never exposed
13:24
<annevk>
not even for iso-2022-jp
13:24
<annevk>
well, works for me
13:26
<charlvn>
something is weird with firefox - when i clear the cache and refresh i get 43x19 and then i refresh again without clearing the cache and get 844x598
13:26
<charlvn>
on window load i always get the latter
13:28
<Philip`>
charlvn: That might be the size of the alt text placeholder
13:28
<charlvn>
ah yes, makes sense
13:29
<charlvn>
Ms2ger: here is a better "clean" one: https://gist.github.com/2384482
13:55
<zewt>
more typed array bizarreness
13:55
<zewt>
The given byteOffset must be a multiple of the element size of the specific type, otherwise an exception is raised.
13:56
<zewt>
:|
13:59
<zewt>
but i've had so little success pointing out issues in typed arrays in the past that i don't think i can be bothered with this one
14:25
<annevk>
zewt: sounds quite weird
14:37
<Philip`>
Since the purpose of typed arrays is performance, it doesn't seem that unreasonable that they require correct alignment
15:13
<zewt>
sure it does; it should be fast if possible but always work
15:54
<FedorEmelianenko>
hi all
15:55
<FedorEmelianenko>
is it corret to put a <nav> into an <aside> ?
15:58
<FedorEmelianenko>
correct*
16:00
<charlvn>
FedorEmelianenko: it's in the examples on http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-aside-element
16:02
<FedorEmelianenko>
thanks charlvn
16:03
<charlvn>
np :)
17:23
<kennyluck>
Huh. The CSS parser in IE seems to have a buffer size of 128 for DIMENSION.
17:23
<kennyluck>
If you have a DIMENSION which is longer than that, it gets dropped it seems.
18:13
<Ms2ger>
gsnedders, ping
18:25
<Yuhong>
"<jarek> Philip`: really? I though that no one knows what "HTML5" actually means"
18:25
<Yuhong>
Yea, I am beginning to think that "HTML5" even as a buzzword is a misnomer.
18:26
<Yuhong>
For example, canvas dates back to 2005.
18:46
<gsnedders>
Ms2ger: pong
18:46
<gsnedders>
Yuhong: We were already calling it HTML5 then.
18:47
<Ms2ger>
gsnedders, in May last year, you said "I'll finish this off and push it soon." about http://code.google.com/p/html5lib/issues/detail?id=157 , did that happen? :)
18:48
<gsnedders>
Oh, that.
18:48
<gsnedders>
Heh.
18:48
<gsnedders>
Realized it was harder than I thought to do in a reasonably performant way without eating all of the memory.
18:49
<Ms2ger>
In that case, how about taking fantasai's patch instead? :)
18:50
<gsnedders>
No. I have fundemental issues to that. :)
18:50
<gsnedders>
It doesn't cope with the majority of "invisible" characters.
18:51
<Ms2ger>
And you're not interested in a "escape some invisible characters" option? :)
19:14
<wycats>
Philip`: back with some more html5lib questions
19:15
<wycats>
trying to figure out why &#0129; becomes a REPLACEMENT character?
19:18
<Philip`>
wycats: It should turn into U+0081, and as far as I can tell, it does
19:19
<wycats>
the test indicates it's a REPLACEMENT
19:19
<Philip`>
What test?
19:19
<wycats>
the one in html5lib
19:19
<Philip`>
Which one?
19:19
<wycats>
we've talked about it before, remember ;)
19:19
<wycats>
one sec
19:19
<Philip`>
Don't expect me to have a memory :-p
19:19
<wycats>
hahaha
19:19
<wycats>
{"description": "Windows-1252 REPLACEMENT CHAR numeric entity.", "input":"&#0129;", "output": ["ParseError", ["Character", "\u0081"]]},
19:19
<wycats>
that's the test
19:20
<wycats>
hmm
19:20
<wycats>
I was reading the test output wrong?
19:20
<Philip`>
That's outputting a U+0081
19:20
<wycats>
*I* was emitting a replacement ;)
19:20
<wycats>
lolololol
19:20
<Philip`>
plus a ParseError due to http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#table-charref-overrides
19:21
<wycats>
yeah
19:21
<wycats>
I misread my output:
19:21
<wycats>
expected: ["ParseError", ["Character", "\u0081"]]
19:21
<wycats>
got: ["ParseError", ["Character", "�"]] (using ==)
19:21
<wycats>
#fail
19:44
<wycats>
hell's yeah it's working now
21:10
<jgraham>
TabAtkins: Would you be able to read http://coremob.github.com/level-0/index.html#style and comment on which, if any, of those specs are not stable in a practical sense i.e. which couldn't be implemneted unprefixed today without a significant chance of getting burned by backward-incompatible changes in the future (ignoring the policy of not implementing non-CR specs unprefixed for the sake of argument)
21:10
<jgraham>
In an ideal world it would be great if you could send your response to the core mobile mailing list
21:11
<jgraham>
Otherwise if you could let me know that would be fine
21:11
<jgraham>
If you don't want to do it at all that's also fine ofc :)