00:41
<hober>
making a fair amount of progress on my ISSUE-27 CP today: http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-27
00:41
<hatrick>
I am having an FF only issue with image maps. On vertical resize of the browser it's seeming that with FF the <area> (coordinates) are dropping but the image is not. This is making me feel a z-index-like approach when it comes to the image and the map.... and I would want it to be more like a relative container to absolute child approacj.
00:41
<othermaciej>
hober: nice!
00:41
<hober>
feedback, as always, is very welcome
00:41
<hatrick>
its as if someone on the z-index level of the coordinates is making it drop, while on the other hand the image is safe from being pushed down.
00:42
<hober>
I've still got a bajillion open tabs related to it, so it will change significantly between now and Friday
01:22
<gsnedders>
http://rebuildingtheweb.com/en/html5-shortcomings/#c20101202172746
01:49
<oojacoboo>
hober: what's the intended use of the rel values from a UA perspective?
05:26
<hober>
oojacoboo: depends on the rel value
05:27
<oojacoboo>
hober: examples?
05:27
<hober>
oojacoboo: e.g., rel=stylesheet has a pretty clear intended use from a UA perspective
05:27
<karlcow>
the troll hunter http://www.youtube.com/watch?v=DdJxk6kO8HU
05:27
<oojacoboo>
hober: I guess I am more referring to anchors
05:27
<hober>
ok, here's another example: <a rel=nofollow>
05:27
<oojacoboo>
rel=colleague
05:28
<oojacoboo>
rel=lover
05:28
<hober>
oojacoboo: are you asking about specific rel values, or <a rel> in general?
05:30
<oojacoboo>
the specific values
05:30
<oojacoboo>
are there any intended uses for UAs with these
05:31
<oojacoboo>
I mostly see if for bot use
05:54
<hober>
oojacoboo: like i said, it depends on the value. the various XFN values, for instance, are generally not expected to have UA implications.
05:55
<oojacoboo>
hober: yea
08:11
<MikeSmith>
"The data model is a representation of the text. The text is not a serialization of the data model."
08:11
<MikeSmith>
hmm
14:50
<realDave>
hi
16:42
<Peter`>
hsivonen: validator.nu gets an Internal Error when I try to validate the following site: http://validator.nu/?doc=http://www.smallnetbuilder.com/content/view/29536/80/
17:05
<MikeSmith>
Peter`: i tried reproducing that with my validator installs, but can't reproduce it
19:01
<_bga>
brendaneich why `Date` constructor w/o `new` returns date string, but other build-in classes acts as with `new`?
19:04
<brendaneich>
not all other built-in classes (String, Number, Boolean convert to primitive if called instead of new'ed)
19:04
<brendaneich>
not sure there's a good answer to "why?"
19:04
<brendaneich>
avoiding an allocation to get a date string could have been done via date.nowString() or whatever
19:05
<brendaneich>
but this was 15 years ago
19:05
<brendaneich>
Date's not going to change
19:05
<brendaneich>
(avoiding an object allocation ^)
19:05
<_bga>
may be we can fix it in es6?
19:06
<brendaneich>
why?
19:06
<brendaneich>
more hidden porting tax
19:07
<brendaneich>
if we want people to opt into the new version we don't want very many runtime meaning shifts
19:07
<_bga>
one common style
19:07
<brendaneich>
one or two big ones that are worth the trouble but not lots of little ones that no one will remember or be able to scan for
19:07
<brendaneich>
this isn't about style
19:08
<_bga>
`new A` - create instance of class A, `A(b)` - cast
19:08
<brendaneich>
you're talking about taking old code into the new opt-in version, or writing new code while still maintaining old -- both Date() -> string and (under your proposal) Date() -> object would coexist and cause confusion
19:08
<brendaneich>
there is no cast meaning for non-primitiive-wrappers
19:09
<_bga>
i understand, old code will now works
19:10
<_bga>
but in c++ we have same common rules
19:10
<_bga>
`new A` and `A(b)`
19:10
<_bga>
its very readable and understandable
19:11
<_bga>
if we will have sugar for classes
19:11
<brendaneich>
that's not for sure
19:11
<_bga>
we can do not write `new ` keyword
19:16
<brendaneich>
all the classes as sugar proposals have been like that -- always construct, new is optional
19:21
<brendaneich>
note function proxies have independent call and construct traps
19:23
<_bga>
yes. main idea is `new` keyword is syntax noise for instance of class construction
19:31
<Peter`>
MikeSmith: hm ok, might be fixed already then
19:31
<Peter`>
I randomly ran in to it and figured I'd pass it along
20:23
<sqwk>
is there a way to differentiate between multiple nav tags? An extra attribute for the main nav?
20:34
<AryehGregor>
sqwk, class?
20:34
<sqwk>
i meant more in terms of semantics
20:35
<sqwk>
or would screenreaders figure the context out solely though the section tags?
20:36
<AryehGregor>
Based on what I've seen of screen readers, they'll probably treat all <nav>s the same as <div>.
20:36
<AryehGregor>
If you particularly want to support screen readers, you should go get one and test in it.
20:37
<AryehGregor>
Anyone who says semantic markup is necessary for the sake of screen readers has probably never even tried using one. There are some particular patterns that make them very unhappy (like bad alt text), but mostly they ignore the semantic value of elements.
20:37
<AryehGregor>
When I tried JAWS, it didn't even distinguish <strong> or <em> from <span>.
20:37
<AryehGregor>
Or <b> or <i> or <u> or <ins> or <del> or . . .
20:38
<AryehGregor>
But anyway, no, there's no special way to semantically designate different navs, beyond class and such.
23:52
<MikeSmith>
Peter`: It's definitely a problem -- I can reproduce it at validator.nu -- but I just can't reproduce it in my environment