| 00:39 | <nessy> | Hixie: there is actually an interesting and relevant discussion around text audio descriptions on the a11y tf right now, too |
| 00:43 | <Hixie> | nessy: k |
| 00:43 | <Hixie> | nessy: re stopping playback, it seems it would be really bad to not stop playback if it means missing the first few captions each time |
| 00:44 | <nessy> | oh for a video from the start I have no issues with that |
| 00:44 | <nessy> | but I think it may be too disruptive when somebody turns on the captions while the video is playing back |
| 00:44 | <Hixie> | well if you've got the whole caption track at the start, then you'll never stall later, will you? |
| 00:44 | <Hixie> | or am i missing something |
| 00:44 | <Hixie> | how are you expecting stalling to happen? |
| 00:45 | <nessy> | for example you have a video that has a german, french and english subtitle track |
| 00:45 | <nessy> | you start the video without any subtitle track active, because you don't think you need it |
| 00:45 | <nessy> | after a few minutes your realize you want the french subtitle track turned on, go to the menu and select it |
| 00:45 | <Hixie> | ah, interesting... |
| 00:45 | <nessy> | now, because none was active before, none of the files were downloaded |
| 00:45 | <Hixie> | that would indeed be a simpler model |
| 00:46 | <Hixie> | so basically just check at the start before autoplaying |
| 00:46 | <Hixie> | and not stall for any other reason |
| 00:46 | <nessy> | yes, I'd say so |
| 00:46 | <nessy> | YouTube does it this way |
| 00:46 | <nessy> | also make sure that the active tracks are loaded before going to METADATA_LOADED state - that's all |
| 00:47 | <Hixie> | METADATA_LOADED? |
| 00:48 | <Hixie> | oh you mean HAVE_METADATA? |
| 00:48 | <Hixie> | why? |
| 00:49 | <Hixie> | i guess that would make the model simpler |
| 00:50 | <nessy> | ah sorry :) |
| 00:50 | <nessy> | but you would need a state on the track so ppl can decide to implement a different behaviour using javascript |
| 00:51 | <Hixie> | pausing before HAVE_METADATA until active tracks have loaded would work for me |
| 00:51 | <Hixie> | i.e. just during initial load |
| 00:52 | <nessy> | exactly |
| 00:52 | <nessy> | since text tracks usually load faster than video, it shouldn't introduce extra delays, but you never know |
| 00:54 | <nessy> | gah - just had a proposal to use SSML (Speech Synthesis Markup Language) as an externally associated text format |
| 00:55 | <nessy> | for audio descriptions... |
| 00:56 | <Hixie> | what's wrong with Speech CSS? |
| 00:56 | <nessy> | what's that? |
| 00:56 | nessy | goes checking it ou |
| 00:56 | <Hixie> | same as regular CSS, btu for aural media |
| 00:56 | <nessy> | cool |
| 00:57 | <nessy> | does it work with WebSRT ? |
| 00:57 | <Hixie> | it would work the same as screen css, sure |
| 00:57 | <nessy> | that might solve this issue! |
| 00:57 | <nessy> | thanks! |
| 00:58 | <Hixie> | i don't really understand the issue, but np! :-) |
| 00:58 | <nessy> | do web browser support speech css? |
| 00:58 | <Hixie> | no |
| 00:58 | <Hixie> | do they support SSML? |
| 00:58 | <nessy> | don't think so |
| 01:01 | <Hixie> | note that <video> supports changing the playback rate; this would also affect captions, naturally |
| 01:02 | <nessy> | well, I am trying to find a way that we can get away with only WebSRT as a format - but if there are richer formats for text audio descriptions than just SRT, then it might be difficult |
| 01:02 | <Hixie> | there are far reacher formats. .wav, say. |
| 01:02 | <nessy> | really? video supports changing the playback rate? is there an attribute? |
| 01:02 | <Hixie> | .playbackRate |
| 01:02 | <Hixie> | and .defaultPlaybackRate |
| 01:02 | <nessy> | gah, I missed that! |
| 01:03 | <Hixie> | s/reacher/richer/ |
| 01:09 | <nessy> | have browsers implemented the playbackRate attribute? |
| 01:10 | <nessy> | well, I'll go and find out :) |
| 01:12 | <annevk> | nessy, Opera hasn't |
| 01:19 | <AryehGregor> | Hixie, doesn't Opera support aural CSS? |
| 01:19 | <Hixie> | maybe |
| 02:03 | <AryehGregor> | Is WebKit planning on implementing MathML in the foreseeable future? |
| 02:03 | <othermaciej> | AryehGregor: there's an implementation in progress |
| 02:03 | <othermaciej> | so yes |
| 02:03 | <AryehGregor> | Oh, awesome. |
| 02:03 | <othermaciej> | it's off by default in the builds right now though |
| 02:03 | <AryehGregor> | We were just talking about math rendering in #mediawiki. |
| 02:04 | <AryehGregor> | So it will be a typical all-but-IE thing. Probably it would make sense to skip straight to MathML and not try intermediate solutions like jsMath, in that case. |
| 02:13 | <nessy> | Hixie: are volume and muted attributes of <video> that can be used by authors? |
| 02:14 | <nessy> | i.e. can they be used as in <video volume="0.5" muted> or are they just javascript interfaces? |
| 02:14 | <Hixie> | JS |
| 02:14 | <Hixie> | not sure what it would mean to have them be content attributes |
| 02:14 | <nessy> | ah cool - defaultPlaybackRate is a content attribute though? |
| 02:15 | <nessy> | well, it would mean to start a video muted and with a specific volume setting - but I am only documenting it, not wanting to introduce anything |
| 02:20 | <AryehGregor> | Content attributes are listed here: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video |
| 02:21 | <AryehGregor> | Global attributes, src, poster, preload, autoplay, loop, controls, width, height, that's it. |
| 02:38 | <nessy> | but the way that I read defaultPlaybackRate it is also a content attribute |
| 02:38 | <nessy> | that's what's been confusing me |
| 02:40 | <nessy> | http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#loading-the-media-resource says |
| 02:40 | <nessy> | "Set the playbackRate attribute to the value of the defaultPlaybackRate attribute." |
| 02:41 | <nessy> | in the media element loading algorithm |
| 02:43 | <Hixie> | should i ignore dynamic changes to <track src> made after the track has loaded? |
| 02:43 | <Hixie> | or should i support unloading a track and reloading it? |
| 02:43 | <boogyman> | latter |
| 02:43 | <Hixie> | what's the use case? |
| 02:44 | <boogyman> | what's the harm |
| 02:44 | <Hixie> | it's a big implementation and specification burden |
| 02:44 | <boogyman> | 'because it's hard' is generally not an acceptable 'excuse' |
| 02:44 | <Hixie> | sure it is |
| 02:45 | <jwm> | heh |
| 02:45 | <Hixie> | it's probably the main reason for not doing things |
| 02:45 | <jwm> | I don't like doing things unless they are hard |
| 02:45 | <nessy> | do we allow it for videos? |
| 02:45 | <boogyman> | so it's okay to do web dev with nested tables, because it's 'easy' ? |
| 02:45 | <boogyman> | :-s |
| 02:46 | <jwm> | nested tables made me millions |
| 02:46 | <Hixie> | boogyman: it's easier to use semantic markup than tables |
| 02:46 | <Hixie> | boogyman: so i don't buy that |
| 02:46 | <boogyman> | I agree, but new developers don't view it as such |
| 02:46 | <Hixie> | boogyman: but generally speaking, there are often cases where there are other even more important reasons to do something that override the "it's hard" reason not to do it |
| 02:46 | <nessy> | I think since we do it for videos, it would be inconsistent not to allow it for <track> |
| 02:47 | <Hixie> | boogyman: the question is here, what's the reason for doing it that overrides the reason not to do it? |
| 02:47 | <Hixie> | nessy: we don't do it for <source> |
| 02:47 | <nessy> | but for <video src> ? |
| 02:48 | <boogyman> | Hixie: I don't have a use-case, but I am sure that it would be greatly appreciated by developers to implement |
| 02:48 | <Hixie> | yes, for <video> src we do it, but there's a good reason to support that (how else would you change the video?) |
| 02:48 | <Hixie> | boogyman: i'm having trouble imagining when a dev would ever do it |
| 02:48 | <nessy> | if somebody changes the video's src half way through via JS, they would surely also need to change the <track src> that relate to that video |
| 02:48 | <Hixie> | surely they'd just blow away the <track>s and insert entirely new ones |
| 02:48 | <Hixie> | not mutate the existing ones |
| 02:49 | <nessy> | I see |
| 02:49 | <Hixie> | just like with <source> |
| 02:49 | <nessy> | yeah, I think that's fair enough |
| 02:49 | <Hixie> | i guess we can always change it later |
| 02:49 | <Hixie> | if there's a use case |
| 02:50 | <nessy> | Hixie: I am writing a book on html5 video and am currently documenting content attributes - is defaultPlaybackRate a content attribute? |
| 02:50 | <Hixie> | no |
| 02:50 | <Hixie> | the list of content attributes is in the spec in several places |
| 02:50 | <Hixie> | e.g. in the green box in the element's definition |
| 02:50 | <Hixie> | under "Content attributes:" |
| 02:50 | <Hixie> | or in the index at the bottom of the spec |
| 02:51 | <boogyman> | Ian, As a developer, I would be annoyed if I was required to destroy and create a new <track>, however I was able to just mutate a <video> |
| 02:51 | <nessy> | yeah, but that confuses me with the defaultPlaybackRate, since it would make sense to set it as content attribute and then use only playbackRate in JS |
| 02:52 | <boogyman> | plus as nessy pointed out, it's inconsistent |
| 02:52 | <Hixie> | nessy: defaultPlaybackRate is the rate of playback, playbackRate is the rate you'd use when ffwding or rewinding |
| 02:52 | <nessy> | it's as inconsistent as the <source> elements are |
| 02:52 | <Hixie> | boogyman: well, if we do support it... what happens to the TimedTrackCue objects? |
| 02:52 | <nessy> | ok, thanks |
| 02:53 | <Hixie> | boogyman: seems weird that we'd suddenly orphan all those objects... |
| 02:53 | <nessy> | kill them all ;) |
| 02:53 | <Hixie> | boogyman: i can't think of any time we do that currently |
| 02:53 | <Hixie> | boogyman: would their .track be reset so you could insert them into an API-created timed track? that'd be even weirder... |
| 02:54 | <Hixie> | boogyman: there's lots of cases where we don't react to changes like this, btw, e.g. if you change the <base href=""> base URL, we don't reload anything dynamically |
| 02:54 | <boogyman> | I'm not familiar with those objects, reference literature? |
| 02:54 | <Hixie> | boogyman: even though technically all the URLs in the doc changed |
| 02:54 | <Hixie> | boogyman: they're the new ones for the timed track API |
| 02:54 | <boogyman> | ack! enter spam :| |
| 02:56 | <Hixie> | btw, should i name these interfaces MediaTrack/MediaCue or TimedTrack/TimedTrackCue ? |
| 02:56 | <Hixie> | hm, gotta go for dinner, bbl to continue! |
| 02:57 | <nessy> | does a change to <video src> blow away all the <source> elements? |
| 02:58 | <nessy> | I like MediaTrack/MediaCue |
| 03:08 | <boogyman> | Hixie: After reading through the spec, I think it would be easier to just remove and recreate the <track>, both from a developer stand point, as well as UI implementation |
| 05:17 | <Hixie> | nessy: <video src> overrides <source> but doesn't affect the dom |
| 05:18 | <nessy> | what I meant was when you use JS to change the currentSrc |
| 05:18 | <Hixie> | currentSrc is readonly, no? |
| 05:18 | <Hixie> | boogyman: k :-) |
| 05:19 | <zcorpan> | Hixie: i would reuse existing <source> and <track>s if all my videos have the same pattern |
| 05:19 | <nessy> | sorry, when you change the @src attribute |
| 05:19 | <zcorpan> | Hixie: changing <souce> or blowing them away and inserting new ones requires a load() anyway |
| 05:19 | <Hixie> | :-/ |
| 05:20 | <Hixie> | having dynamic changes to src="" affect <track> is going to be a pain |
| 05:21 | <nessy> | what I expected was dynamic change to @src blows away <source> and <track> |
| 05:21 | <zcorpan> | my knee-jerk reaction is that we could ignore dynamic updates to <track src> and just reevaluate all <track>s in the media load algorithm |
| 05:21 | <Hixie> | changing src="" makes the <source> elements get ignored, but doesn't affect the DOM |
| 05:21 | <Hixie> | zcorpan: oh you want to wait until the media is loaded to load the subtitle tracks? hmm |
| 05:22 | <zcorpan> | Hixie: no |
| 05:22 | <zcorpan> | Hixie: the media load algorithm starts when the <video> tag is parsed |
| 05:23 | <Hixie> | yeah but it does nothing much the first time and is restarted when you set src="" or append a <source>, right? |
| 05:23 | <nessy> | I see - <source> is easier than <track>, since <source> isn't relevant any more … hmmm |
| 05:23 | <zcorpan> | it's restarted when you set <video src=""> but not when you append a <source> |
| 05:24 | <zcorpan> | appending a <source> just spins the resource selection algorithm if it sits waiting for another <source> |
| 05:24 | <Hixie> | either way it seems weird to link them |
| 05:26 | <nessy> | so when you set <video src=""> and the media load algorithm is restarted, then it should also re-load all active <text> elements, which could have been changed in the meantime |
| 05:27 | <zcorpan> | yeah |
| 05:27 | <Hixie> | the reason that's weird is that other changes to <track> still take effect, the way the system is set up so far |
| 05:27 | <Hixie> | it is kind of weird for <track label> to be live but <track src> not to be |
| 05:27 | <zcorpan> | i agree |
| 05:27 | <Hixie> | sigh... i should just bite the bullet and make src="" dynamic |
| 05:29 | <TabAtkins__> | Dashiva: Random question: What's the unicode shocked dude with the monocle? |
| 05:30 | <foucist> | Hixie: any thoughts about p2p or listening sockets with websockets? for browser2browser connectivity.. if people can have local-REST/local web services for their personal data and share it however they want.. |
| 05:30 | <foucist> | i know the docs mention p2p |
| 05:30 | <foucist> | just wondering what the motivation is etc |
| 05:36 | <Hixie> | video conferencing, that kind of thing |
| 05:37 | <foucist> | ah |
| 06:19 | <hsivonen> | U+0000 problem: https://bugzilla.mozilla.org/show_bug.cgi?id=563526 |
| 06:20 | hsivonen | wishes the routr UI developers were a little more careful |
| 06:25 | <Hixie> | it's failing to go into <frameset> because of a leading null? |
| 06:25 | <hsivonen> | right |
| 07:00 | <Hixie> | ok what should this format's MIME type be |
| 07:00 | <Hixie> | text/captions? |
| 07:00 | <Hixie> | text/subtitles? |
| 07:00 | <Hixie> | text/timed-track? |
| 07:00 | <Hixie> | text/cues? |
| 07:00 | <Hixie> | text/websrt? |
| 07:01 | GPHemsley | wonders if there is a discussion going on right now that he is unaware of |
| 07:01 | <Hixie> | GPHemsley: i'm going through the feedback on captions and subtitles to add timed tracks for <video> in HTML |
| 07:01 | <virtuelv> | Hixie: if you're thinking of anything for captioning, keep in mind that captioning with markup is in use on TV today |
| 07:01 | <Hixie> | GPHemsley: based on http://wiki.whatwg.org/wiki/Timed_tracks |
| 07:01 | <virtuelv> | not only with markup, but also with positioning data |
| 07:02 | <Hixie> | virtuelv: pretty much everything under the sun is in use somewhere :-) |
| 07:02 | <Hixie> | virtuelv: i mean, DVDs for example use just raw bitmaps :-) |
| 07:03 | <virtuelv> | Hixie: please tell me that is a joke |
| 07:03 | <Hixie> | i'm afraid not :-( |
| 07:03 | <Hixie> | not just DVDs, either |
| 07:04 | <Hixie> | CVD, DVB, SVCD, and XSUB are also image-based |
| 07:04 | <GPHemsley> | that would explain the quality |
| 07:05 | <doublec> | what does 'srt' stand for? Is it an acronym? |
| 07:05 | <GPHemsley> | well, Wikipedia calls them primiarly subtitles, but YouTube calls them captions |
| 07:05 | <Hixie> | doublec: SRT is the format SubRip used... I guess SubRip Text? |
| 07:05 | <Hixie> | SubRipTitles? |
| 07:05 | <Hixie> | dunno |
| 07:05 | <doublec> | If you call it websrt people are going to want to know :) |
| 07:06 | <Hixie> | yeah |
| 07:06 | <Hixie> | if we call it websrt we'd come up with a backronym |
| 07:06 | <Hixie> | Web Subtitle Resource Track or something |
| 07:08 | <Hixie> | the only reason i'd call it WebSRT is to give a hat tip to the existing SRT community |
| 07:10 | <GPHemsley> | "Most of the world does not distinguish captions from subtitles. In the United States and Canada, these terms do have different meanings, however: "subtitles" assume the viewer can hear but cannot understand the language or accent, or the speech is not entirely clear, so they only transcribe dialogue and some on-screen text. "Captions" aim to describe to the hearing-impaired all significant audio content—spoken dialogue and non-sp |
| 07:10 | <GPHemsley> | eech information such as the identity of speakers and, occasionally, their manner of speaking—along with music or sound effects using words or symbols." |
| 07:13 | <GPHemsley> | http://screenfont.ca/learn/ |
| 07:18 | <virtuelv> | the Norwegian terms for either variant is |
| 07:24 | <GPHemsley> | Hixie: Is ::cue a proposal? |
| 07:30 | <virtuelv> | "subtitled" |
| 07:31 | <virtuelv> | or "subtitled for the hearing-impaired" |
| 07:36 | <nessy> | text/websrt |
| 07:37 | <othermaciej> | that seems better than the other options |
| 07:37 | <nessy> | yeah, definitely |
| 07:37 | <Hixie> | GPHemsley: yes |
| 07:42 | <GPHemsley> | given the confusion between subtitles and captions, I would think that timed-track would be a good generic name |
| 07:42 | <GPHemsley> | but if you wanna backronym WebSRT, I guess that's OK |
| 07:42 | <GPHemsley> | I'm just kinda tired of WebXYZ |
| 07:43 | <GPHemsley> | makes me think of WebTV and WebDAV and whatever else, unnecessarily |
| 07:43 | <Hixie> | you'd rather we went back to Xfoo? :-) |
| 07:46 | <hsivonen> | text/websrt makes sense |
| 07:48 | <nessy> | if we call the format webSRT, then text/websrt makes sense - I wasn't aware we're still discussing the name of the format though |
| 07:49 | <othermaciej> | WebSRT is nice and pronouncable, XSRT not so much |
| 07:50 | <GPHemsley> | I was actually hoping for just calling it what it is |
| 07:51 | <GPHemsley> | (and I wasn't aware that the name WebSRT was already decided on) |
| 07:51 | <Hixie> | hmm |
| 07:53 | <Hixie> | if we want to make WebSRT compatible with legacy files and UAs, we can't have a magic string, huh |
| 07:53 | <Hixie> | bummer |
| 07:55 | <nessy> | magic string? |
| 07:56 | <Hixie> | a set of bytes guaranteed to be at the start of the file |
| 07:56 | <Hixie> | so that files can be recognised unambiguously |
| 07:56 | <Hixie> | like how cache manifests have to start with "CACHE MANIFEST" |
| 07:56 | <nessy> | ah, you wanted to add that at the beginning of WebSRT? |
| 07:56 | <Hixie> | ideally i'd like every format to have a magic string, but i don't see a way to do it with websrt |
| 07:56 | <Hixie> | so :-( |
| 07:57 | <nessy> | well, it won't be backwards compatible for most cases anyway |
| 07:57 | <Hixie> | why not? |
| 07:57 | <nessy> | I'd assume that most parsers have a problem with the extensions |
| 07:57 | <nessy> | but that is a wild guess - I haven't got any hard facts on that |
| 07:57 | <Hixie> | yeah but most extensions aren't going to be used most of the time |
| 07:57 | <hsivonen> | Hixie: did you test the extensions with mplayer, VLC, etc.? |
| 07:57 | <nessy> | should give it a shot ;) |
| 07:58 | <Hixie> | hsivonen: no |
| 07:58 | <nessy> | hsivonen: indeed, should give it a shot! |
| 07:58 | <Hixie> | i don't expect any UAs to handle the extensions well |
| 08:02 | <nessy> | in which case I wouldn't be too worried about adding things like the magic string |
| 08:03 | <nessy> | but I can see that it might be stepping over a line |
| 08:04 | <Hixie> | well it goes from making it possible to write compatible files to making it impossible |
| 08:04 | <nessy> | yeah, I can see that |
| 08:05 | <nessy> | incidentally - did you introduce a means for style sheets? |
| 08:05 | <Hixie> | there's a big difference between "if you avoid using the extensions it'll keep working" or "old SRT files will work with this", and "you can't make files that work with both web browsers and legacy video players" or "old SRT files won't work with web browsers" |
| 08:05 | <Hixie> | a new means? what's wrong with the existing means for style sheets? |
| 08:06 | <nessy> | I mean: to associate style sheets with WebSRT files? |
| 08:06 | <nessy> | not sure if that was the plan though |
| 08:06 | nessy | has some catching-up reading to do |
| 08:07 | <Hixie> | why would they be associated with WebSRT files? isn't it the <video> files that you'd want to style? |
| 08:07 | <Hixie> | s/<video> files/<video> elements/ |
| 08:07 | <nessy> | what if I want the styling in a non-web-browser? |
| 08:08 | <nessy> | video file + websrt file + style sheet for the cues |
| 08:08 | <nessy> | no |
| 08:08 | <nessy> | ups: no? |
| 08:09 | <Hixie> | how is the subtitle file being linked to the video file? |
| 08:09 | <nessy> | usually the video player just loads it as an external file |
| 08:09 | <nessy> | e.g. vlc: you load the video then you load the srt file |
| 08:10 | <nessy> | it's your knowledge that links the two ;) |
| 08:10 | <nessy> | or often file names |
| 08:10 | <Hixie> | well if they want to support CSS i guess they can just load the style sheet that way too :-) |
| 08:10 | <nessy> | hehe! |
| 08:10 | <nessy> | are there embedded styles? |
| 08:11 | <Hixie> | what's the use case? |
| 08:11 | <nessy> | well, all other richer caption formats allow to provide styling inside the caption file, so I wondered if websrt did that too |
| 08:12 | <Hixie> | i don't have a proposal to do that so far |
| 08:12 | <nessy> | things like background colour on cues |
| 08:12 | <nessy> | ok |
| 08:12 | <Hixie> | i considered inline formatting to be a feature to avoid when i was looking at formats though |
| 08:12 | <Hixie> | if there's a use case for it then i should restudy the formats :-) |
| 08:13 | <nessy> | not sure |
| 08:13 | <nessy> | it's different to how it is now, but then you could argue that it's nicer this way |
| 08:13 | <nessy> | at least you can pick your preferred style sheet and apply it to all captions that you receive |
| 08:14 | <Hixie> | personally i don't see why we'd want the authors to style the captions at all |
| 08:14 | <nessy> | and it's called websrt for a reason ;) |
| 08:14 | <Hixie> | but i'm willing to compromise with allowing the authors to put styling hints in CSS |
| 08:14 | <Hixie> | so long as i can turn it off |
| 08:15 | <nessy> | fair enough |
| 08:16 | <nessy> | the semantic markup, however, is what the author knows best, such as speaker names, what is emphasised, etc |
| 08:16 | <nessy> | but how that is styled is indeed a different matter |
| 08:16 | <Hixie> | voices, emphasis, etc, we should support, sure |
| 08:17 | <nessy> | am impressed by your progress, btw |
| 08:17 | <Hixie> | well once we'd figured out the use cases, the spec writing is just spec writing |
| 08:17 | <Hixie> | that's the easy part |
| 08:18 | <Hixie> | the hard part is working out what the requirements are and coming up with an idea to address them |
| 08:19 | <nessy> | and that was good work, too |
| 08:19 | <nessy> | anyway - gotta go shopping - l8r |
| 08:20 | <Hixie> | later |
| 09:08 | <mcarter> | Hixie, do you have any familiarity and/or biases for/against the sctp protocol? |
| 09:09 | <Hixie> | mcarter: nope |
| 09:11 | <mcarter> | Hixie, its a low-level transport-level protocol that lets you start multiple separate channels within a single session. those channels can either be reliable streams or unreliable/message-oriented |
| 09:12 | <mcarter> | Hixie, I'm looking into existing implementations to see how complicated they are; I think it could be a good choice for the post-handshake PeerConnection protocol |
| 09:14 | <Hixie> | cool |
| 09:15 | <Hixie> | i'm hoping i can not be involved at all with that level of the peer-to-peer stuff |
| 09:15 | <Hixie> | :-) |
| 10:22 | <boblet> | hey all |
| 10:23 | <boblet> | a bunch of Moz bugs being closed with “Fixed: HTML5 parser” — anyone know when it’s slated for release? 3.6.4? |
| 10:23 | boblet | crosses fingers |
| 10:24 | <zcorpan> | boblet: i think certainly not 3.6.x |
| 10:24 | <zcorpan> | boblet: 3.7 or later |
| 10:25 | <boblet> | zcorpan: aaw |
| 10:25 | <boblet> | do you have a rough timeline? |
| 10:25 | <zcorpan> | ask hsivonen |
| 10:25 | <boblet> | (I was led to believe it would not be soon tho) |
| 10:26 | <boblet> | hsivonen: yt? |
| 10:27 | <jgraham> | boblet: It either is on by default or has been temporarily backed out due to broken testcases. All being well I think it is expected to ship in firefox.next |
| 10:29 | <boblet> | jgraham: I was under the impression it was off by default atm due to said breakage. I would love to be wrong about this in the near future (was under the impression default-HTML5-parser Firefox.next was mid-term, not near-) |
| 10:30 | <boblet> | heh |
| 10:30 | <boblet> | adactio: hsivonen is afk, so it’s all rumor and hearsay atm ;-) |
| 10:31 | <jgraham> | boblet: It was turned on by default for a while but caused some problems with (unrelated aiui) tests |
| 10:31 | <Lachy> | boblet, it was apparently turned back off due to this bug https://bugzilla.mozilla.org/show_bug.cgi?id=562333 |
| 10:31 | <Lachy> | mentioned in commit message http://hg.mozilla.org/mozilla-central/rev/ccb50d524490 |
| 10:32 | <hsivonen> | boblet: I'm here |
| 10:32 | <boblet> | Lachy: thanks. woah, didn’t realise it was that recent |
| 10:32 | <jgraham> | Lachy: BTW, regarding solubility of washing power, the answer is "any chemistry textbook" |
| 10:32 | <hsivonen> | boblet: I don't comment on Firefox release schedule. Not my call. |
| 10:32 | <boblet> | hsivonen: we’re rumor-milling about the block-level link bug being closed with Fixed: HTML5 parser… |
| 10:32 | <boblet> | hehehe |
| 10:33 | <Lachy> | jgraham, let's not bring that silly discussion-list discussion about washing machines/powders out of the discussion list. |
| 10:33 | <hsivonen> | Lachy: and it has been turned back on again on Monday |
| 10:34 | <hsivonen> | this time without tweets in case it is turned back off again |
| 10:34 | <jgraham> | Lachy: It is way more annoying on the discussion list which I typically assosciate with vaugely-work-related discussion :) |
| 10:34 | <boblet> | hsivonen: that’s great news! |
| 10:34 | <zcorpan> | let's tweet! |
| 10:34 | <boblet> | already did :P |
| 10:35 | <jgraham> | Lachy: (often the emphasis is on "vaugely") |
| 10:35 | <boblet> | great to hear HTML5 parser is back on in trunk tho |
| 10:36 | hsivonen | still has about 200 old bugs to check in case they got FIXED |
| 10:36 | <boblet> | ouchies |
| 10:36 | <boblet> | sorry for my dupes! |
| 10:49 | <hsivonen> | boblet: while I don't comment on the timeline or the number of the major release after 3.6, I can say with good confidence that the HTML5 parser won't be on by default in 3.6.4. |
| 10:53 | <boblet> | hsivonen: thanks :) |
| 14:57 | <zcorpan> | my head explodes when trying to follow the algorithms for unloading documents |
| 14:57 | <gsnedders> | Mine normally just implodes. I guess we cancel each other out. |
| 14:58 | <zcorpan> | so if i navigate away from a document that has an open websocket, should it "discard the document"? |
| 15:01 | <jgraham> | zcorpan: Maybe we should remove all UI for navigating away from documents, force all new documents to be in their own tab and make closing old tabs impossible without closing the browser |
| 15:01 | <jgraham> | It would make our lives easier anyway |
| 15:06 | <Philip`> | jgraham: I suggest removing the UI for opening documents, too |
| 15:06 | <Philip`> | That would make your lives trivial |
| 15:07 | <jgraham> | zcorpan: Yes |
| 15:07 | <jgraham> | I think it should discard the document |
| 15:07 | <zcorpan> | yeah |
| 15:07 | <zcorpan> | now i wonder how to test it |
| 15:07 | <zcorpan> | assuming pageshow is not supported |
| 15:08 | <jgraham> | (recycle is false except in the document.open case and salvagable is false if a websocket had to be closed) |
| 15:09 | <jgraham> | Why does pageshow make a difference? |
| 15:10 | <zcorpan> | pageshow exposes whether the document was discarded |
| 15:11 | <jgraham> | Oh I see |
| 15:17 | <Philip`> | If you can't find a way to test it, doesn't that mean it's not observable behaviour and therefore does not need to be implemented how the spec says? |
| 15:19 | <zcorpan> | i think i found a way to test it |
| 15:19 | <zcorpan> | it's observable in various ways |
| 15:20 | <zcorpan> | scripts run again if it was discarded |
| 15:20 | <zcorpan> | timeouts are still active if it was not |
| 15:21 | <zcorpan> | i just need to store a value in sessionStorage to tell whether the script is running the first time or the second time |
| 15:37 | <zcorpan> | would be nice to have a list of things that cause a document to be discarded when navigated |
| 15:38 | <zcorpan> | and how to prevent it from being discarded |
| 15:38 | <zcorpan> | in the case of websockets, i assume you'd close() the websockets in the pagehide event |
| 15:41 | <jgraham> | zcorpan: It is almost a case of looking through the spec of things that set the salbageable state to false, no? |
| 15:41 | <jgraham> | *salvageable |
| 15:42 | <jgraham> | You can't really give a complete list because "Other specifications can define more." |
| 15:45 | <zcorpan> | jgraham: yeah, but i don't think browsers match the spec exactly |
| 15:46 | <zcorpan> | what i meant was it'd be nice to compile the real list by reverse engineering browsers |
| 18:49 | <TabAtkins> | XBL2 doesn't require XHTML, does it? It'll work fine with HTML, if I'm understanding things correctly. |
| 18:52 | <Hixie> | in what sense? |
| 18:52 | <Hixie> | XBL2 is serialised as XML, so any vocabularies used in its definitions have to be expressed as XML |
| 18:52 | <TabAtkins> | But the document using the binding can be HTML? |
| 18:57 | <sicking> | TabAtkins: yes |
| 19:01 | <TabAtkins> | Can shadow dom elements be parents of normal dom elements, after XBL2 rearranging? |
| 19:15 | <smaug> | TabAtkins: well, anonymous elements can be "binding parents" of normal dom elements |
| 19:16 | smaug | doesn't remember what terminology XBL2 spec uses |
| 19:16 | <TabAtkins> | Well, say you have a binding assigned to #foo. then you do #foo.appendChild(#bar) (pretend this is all valid syntax). Is that valid? |
| 19:16 | <smaug> | er |
| 19:16 | <smaug> | not binding parents, but insertion parents |
| 19:17 | <smaug> | TabAtkins: #foo is still just a DOM element |
| 19:18 | <smaug> | so it has appendChild works just like it works without xbl |
| 19:18 | <smaug> | I mean, appendChild does the same thing in DOM |
| 19:18 | <TabAtkins> | And so the #bar then moves to wherever it's supposed to in the shadow dom? |
| 19:18 | <smaug> | yeah |
| 19:18 | <TabAtkins> | kk, thought so. |
| 20:02 | <variable> | 1) Can anyone provide screenshots/images of what the progress and meter elements are supposed to be rendered as unstyled? I'm looking specifically for pictures that accentuate the difference between the two. |
| 20:02 | <variable> | 2) Who is in charge of the wiki? |
| 20:03 | <variable> | * I mean admin and such - not content |
| 20:05 | <Lachy> | variable, http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/XHIGControls/XHIGControls.html#//apple_ref/doc/uid/TP30000359-TPXREF106 |
| 20:06 | <Lachy> | see also Level Indicators further down that page |
| 20:06 | <variable> | Lachy: thanks - I found that link in a slightly different form on the mailing list but it kept redirecting me to the home page of that site |
| 20:07 | <Lachy> | yeah, Apple have moved the documents around, so the links in the mailing list are likely broken |
| 20:08 | <variable> | Is http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg a valid indeterminate progress element? |
| 20:09 | <Lachy> | Not really, because usually something like that has no way of indicating a determinate state. It's just a throbber that only indicates 2 states: in progress or not in progress |
| 20:10 | <variable> | Is there anything in the spec that would indicate something like that? |
| 20:11 | <AryehGregor> | variable, I'm probably the person to go to for wiki administration. |
| 20:12 | <variable> | AryehGregor: can I PM you ? |
| 20:12 | <AryehGregor> | variable, okay, although I have to run soon. |
| 20:12 | <Lachy> | oh, I didn't notice you asked about the wiki. |
| 20:12 | <Lachy> | AryehGregor and I both administer the wiki |
| 20:12 | <variable> | Ah ok |
| 20:13 | <variable> | so I'll talk to you instead ;) |
| 20:13 | <AryehGregor> | Yeah, Lachy does too, and I ask him or Hixie if I'm unsure about whether we want to do something. But I'm a MediaWiki developer, so I can do crazier stuff. \o/ |
| 20:13 | <variable> | AryehGregor: I don't that much crazy stuff ;) |
| 20:13 | <variable> | Lachy: is a PM ok ? |
| 20:14 | <variable> | 3) Is there anything in the spec that would indicate something like the throbber? |
| 20:14 | <Lachy> | sure, PM is generally fine with anyone in here |
| 20:15 | <variable> | still, netiquette ;) |
| 20:15 | <Lachy> | but if you don't want to ask public, then join #whatwg-cabal |
| 20:17 | <variable> | I'm in -cabal now |
| 20:22 | <variable> | 3) Is there anything in the spec that would indicate something like the throbber? |
| 20:22 | <Philip`> | krijnh needs to start logging #whatwg-cabal |
| 20:23 | <Lachy> | Philip`, there's not much point. No-one hangs out there |
| 20:23 | <variable> | Dashiva: cute ;) |
| 20:23 | <Lachy> | except me :-) |
| 20:24 | <Lachy> | it's where I go when I want to be alone for a while |
| 20:24 | <variable> | I've always used /dev/null for that |
| 20:38 | <Hixie> | that's all we need, rumours of a secret irc channel when we don't even have one :-P |
| 20:38 | <Dashiva> | #whatwg-secret-treehouse-no-patents-allowed never really took off |
| 20:43 | <variable> | Hixie: rumors? I havn't heard any rumors of such a channel |
| 20:43 | <Hixie> | I just meant Lachy's fooling around :-P |
| 20:45 | <variable> | heh |
| 20:45 | <variable> | 3) Is there anything in the spec that would indicate something like the throbber? |
| 20:46 | <Lachy> | <img src="throbber.gif" alt="In Progress..."> |
| 20:46 | <variable> | I see |
| 20:47 | <Hixie> | or <progress></progress> |
| 20:47 | <Hixie> | (with no progress) |
| 20:47 | <variable> | I see |
| 20:48 | <variable> | Hixie: feel free to announce the existence of the rationale page in the wiki - I don't like to see wiki pages edited by just one person ;) |
| 20:50 | <Hixie> | you should do that :-) |
| 20:50 | <Lachy> | if an indeterminate progress bar could be represented by a throbber, then I suppose you could style it with: progress { content: url(throbber.gif); } |
| 20:50 | <Hixie> | it's your page |
| 20:50 | <Hixie> | :-) |
| 20:50 | <Hixie> | you can post a blog post about it, if you like |
| 20:50 | <Hixie> | blog.whatwg.org |
| 20:51 | <Hixie> | (ask me or lachy to give you editor rights once it's written so you can post it) |
| 20:51 | <Lachy> | variable, if you post to the blog, let me know so I can moderate your post and give you editor rights |
| 20:51 | <variable> | Lachy: kk |
| 20:51 | <Hixie> | or you can twitter it, using the form on the front of the whatwg.org site -- PM me for the password |
| 20:51 | <Hixie> | or link to it from the whatwg.org front page |
| 20:51 | <Hixie> | or post about it to the list |
| 20:51 | <Hixie> | pretty much anything you want to do :-) |
| 20:51 | <variable> | Hixie: can you have a million dollars in cash mailed to me? |
| 20:52 | <Hixie> | sure |
| 20:52 | <Hixie> | hey, there's a problem with the mailing... i need, uh, money for the stamp |
| 20:52 | <Hixie> | could you... mail me a cheque first |
| 20:52 | <TabAtkins> | the stamp costs a million dollars. |
| 20:52 | <Hixie> | no no |
| 20:52 | <Hixie> | only like 10,000 |
| 20:53 | <Hixie> | dollars |
| 20:53 | <Hixie> | for now |
| 20:53 | <Hixie> | 1000? |
| 20:53 | <Hixie> | you know, however much you feel like sending really |
| 20:53 | <Hixie> | can't send you the million until then though |
| 20:54 | <Lachy> | Hixie, wow, your postage stamps are cheap. I'd need 1000 minimum, just for the deposit to get one. After that, I'd need monthly payments of $10,000 |
| 20:54 | <TabAtkins> | Hixie, can we say that <img> and other replaced elements are display:inline-block instead of inline? That's what they actually act like. |
| 20:54 | <Hixie> | they act like display:inline replaced elements |
| 20:55 | <Hixie> | if you make them display:inline-block, they break when the alt text is showing instead |
| 20:55 | <variable> | Hixie: I'll gladly send you a million in my prefered currency: http://tinyurl.com/248jalg |
| 20:55 | <TabAtkins> | Sure, but that's not a notion you can express in CSS. Whereas inline-block *is*, and acts identically. |
| 20:55 | <TabAtkins> | Hixie: Not in all browsers. In fact, I think everyone but Firefox treats them like an inline-block when alt is showing. |
| 20:55 | <Hixie> | TabAtkins: yeah, that's a bug |
| 20:56 | <Hixie> | TabAtkins: you can already express images in CSS... as display:inline. CSS handles it all already. |
| 20:57 | <variable> | 4) Is there a preferred way of marking http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_levelrating.gif up ?? |
| 20:57 | <Lachy> | variable, <meter> |
| 20:57 | <Lachy> | ah, depends. |
| 20:57 | <variable> | ok |
| 20:57 | <TabAtkins> | variable: That's either <img src=3stars.jpg alt="3/5"> or <meter>. |
| 20:57 | <Lachy> | are they interactive? |
| 20:58 | <Hixie> | <meter>, yeah |
| 20:58 | <Lachy> | could also be <input type=range> |
| 20:58 | <variable> | Lachy: what if yes? what if no? |
| 20:58 | <Hixie> | what lachy said |
| 20:58 | <variable> | ah, I see |
| 20:58 | <variable> | ok |
| 20:58 | <Hixie> | clearly i am superfluous here :-P |
| 20:58 | <variable> | meter is the result - input is the vote |
| 20:58 | Hixie | goes back to editing the spec :-) |
| 20:59 | <Lachy> | however, styling for <input type=range> would depend on the availability of XBL. I don't think there is a pure-CSS way of doing that (yet) |
| 20:59 | <TabAtkins> | There isn't. |
| 20:59 | <TabAtkins> | And I wouldn't want to *try* speccing up something for it in the absence of XBL. |
| 20:59 | <Lachy> | maybe we could have a new 'appearance' value, like appearance: stars; |
| 21:00 | <TabAtkins> | In CSS? |
| 21:00 | <Lachy> | yes |
| 21:00 | <TabAtkins> | I doubt that would come close to what people want for it. |
| 21:00 | <variable> | TabAtkins: appearance: url(...) would help with the rest |
| 21:00 | <variable> | think about the current <li> images |
| 21:00 | <variable> | Lachy: +1 in the appearance attribute. I'm surprised that such things don't exist yet |
| 21:00 | <TabAtkins> | appearance is a property in the CSSUI spec, variable. |
| 21:01 | <TabAtkins> | It's for things like "appearance:button" to get the default platform button appearance. |
| 21:03 | <Lachy> | the other alternative for styling it, which would give more control, although perhaps more complex, is to provide a range of pseudo-elements that are specific to the range control |
| 21:03 | <Lachy> | like those that were recently discussed for the meter and progress elements |
| 21:04 | <TabAtkins> | The problem is that the typical appearance of <input type=range>, and thus the default pseudoelems to be exposed, are geared towards a single grabber than moves around on top of the range control. |
| 21:04 | <variable> | lachy - I must have missed the pseudo elements for meter/progress - can you provide any links? |
| 21:04 | <TabAtkins> | Whereas the stars-rating concept is typically a set of gray stars, and you click somewhere to make all the star-area to the left of that yellow. |
| 21:05 | <Lachy> | yeah, it would certainly be complicated to get it right, especially since the range control can differ so much on different platforms |
| 21:05 | <Lachy> | variable, somewhere in the IRC logs |
| 21:05 | <TabAtkins> | Essentially the standard start-rating appearance is that of a meter. |
| 21:05 | <variable> | IMHO the opera implementation of range is ugly - but that is coming from a non UI/X developer ;) |
| 21:06 | <Lachy> | variable, the Opera implementation is close to the old Windows UI |
| 21:06 | <Lachy> | It's looks crap on any other platform |
| 21:06 | <Lachy> | but the ugliness of our form controls are well known, both internally and externally |
| 21:06 | <variable> | http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_relevanceindicatorspec.jpg --> meter -- correct? |
| 21:07 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/complete.html#websrt start of the websrt syntax spec |
| 21:07 | <variable> | Lachy: your an opera developer? |
| 21:07 | <Lachy> | Core QA and specs, actually |
| 21:07 | <TabAtkins> | variable: Yes, <meter>. Also yes, Lachy is. |
| 21:08 | <variable> | Lachy: ah ok. |
| 21:09 | <Lachy> | variable, that's one possibility. Though, I would expect the default to be more like this http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif |
| 21:13 | <variable> | kk |
| 21:13 | <Steve^> | Does Opera 10.5 Linux not support the new HTML5 elements? |
| 21:14 | <Lachy> | Steve^, no new HTML5 element support has been added beyond what we already had in 10.10 |
| 21:14 | <Steve^> | then, does 10.10 not support them? |
| 21:14 | <Steve^> | I thought it did, but I had to add display: block for them to display properly |
| 21:15 | <Lachy> | I think the only element support we've got is the new form controls |
| 21:15 | <variable> | Lachy: jw - why was that style chosen for type="range" ? |
| 21:15 | <Lachy> | oh, yeah, the elements will be parsed and added to the DOM |
| 21:15 | <Lachy> | so you can style them as display block |
| 21:15 | <variable> | is windows 9x commonly used by opera users? |
| 21:15 | <Steve^> | why no proper support yet? |
| 21:16 | <Lachy> | because that is dependant on numberous other issues, which have to be implemented first |
| 21:16 | <Lachy> | most importantly, proper HTML5 parsing |
| 21:16 | <Lachy> | I cannot say when that will happen, though |
| 21:17 | <Lachy> | s/numberous/numerous/ |
| 21:17 | <Steve^> | It could always add display: block by itself. But then maybe there is no point, as that style is needed for other browsers anyway |
| 21:18 | <Lachy> | There is a lot to do for the new elements, beyond just styling issues. |
| 21:19 | <variable> | any comments on http://wiki.whatwg.org/wiki/Rationale#Meter_and_Progress_.28are_not_the_same_thing.29 |
| 21:19 | <Lachy> | We need to support the Outline Algorithm, adjust the default styling for h1 based on section levels, correctly report the heading level to assistive technology, impelement new Element interfaces in the DOM, etc. |
| 21:22 | <Lachy> | variable, fix it so that the images are in their own paragraph |
| 21:22 | <Lachy> | also, for <progress>, show the normal progress bar image in addition to the throbber |
| 21:22 | <Hixie> | why do you need to support the outline algorithm? |
| 21:22 | <Hixie> | i thought i'd removed any need for UAs to do that unless they wanted to expose the outline |
| 21:22 | <variable> | Lachy: http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_indetermprogexample.jpg ? |
| 21:23 | <Lachy> | Hixie, don't the browsers expose the heading level to assistive technology? |
| 21:23 | <Lachy> | and also, I think we would need it for Opera's heading navigation keyboard shortcuts |
| 21:26 | <Lachy> | variable, re "why was that [windows 9x] style chosen for type="range" ?", probably because our desktop team focus a significant amount of effort on windows UI, and at least in the past, not so much on other platforms |
| 21:27 | <Steve^> | I didn't realise a h1 would actually be styled differently by the browser depending on section level |
| 21:27 | <Lachy> | but that stuff was done before I started at Opera |
| 21:27 | <Lachy> | Steve^, yeah, I expect many web develoeprs don't realise that |
| 21:28 | <Lachy> | I'm also expecting it to cause some pain when browsers do implement it, now that there are early adopters of the sectioning elements out there |
| 21:28 | <Steve^> | so when Opera starts doing that, any existing HTML 5 websites will start to look funky |
| 21:29 | <Steve^> | that kind goes against everyone saying that you can HTML 5 now |
| 21:29 | <Steve^> | (like Bruce, for instance) |
| 21:29 | <TabAtkins> | Steve^: That'll only happen if people are currently relying on <h1>s always looking huge at all times, which they almost certainly aren't. |
| 21:30 | <variable> | Lachy: I can't find a decent default progress element pic - any suggestions ? |
| 21:30 | <TabAtkins> | People style their headings, *particularly* if they're using <h1> everywhere with sectioning elements, and so they wont' be affected by new default styles. |
| 21:31 | <Lachy> | variable, http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg |
| 21:31 | <Steve^> | When I do h1 { font-size: 110%; }, is that percentage purely in relation to the font-size of the parent element? |
| 21:31 | <TabAtkins> | Yes. |
| 21:32 | <TabAtkins> | It obviously has to be, or else you'd be circular. ^_^ |
| 21:32 | <variable> | ah, I was looking for one that had the percentage in the middle ;) |
| 21:32 | <Lachy> | TabAtkins, it's possible that there are some sites out there that keep the default sizes for headings. |
| 21:32 | <Steve^> | then I guess that's ok then |
| 21:32 | <Steve^> | So what is the value of styling a nested h1 as a h2? |
| 21:33 | <TabAtkins> | Lachy: It's possible, sure. I just find it very unlikely. |
| 21:33 | <Lachy> | I know most sites do specify custom sizes, to fix the really bad defaults, but there's no guarantee |
| 21:33 | <TabAtkins> | Steve^: The value is that it then looks like a second-level heading, which it is. |
| 21:33 | <Steve^> | but if everyone styles it explicitly anyway? |
| 21:33 | <Steve^> | and they'll need to |
| 21:34 | <TabAtkins> | I don't often style the sizes of my headings (though I'll adjust other things). I just don't use purely <h1> yet, either. |
| 21:34 | <Steve^> | A nested h2 then comes a h3, what does a nested h6 become? |
| 21:34 | <variable> | Lachy: comments on the updated version? |
| 21:34 | <Lachy> | I'm sure it won't cause too much pain, regardless. If it does affect any sites, then the easy fix is for the author to specify a size |
| 21:35 | <TabAtkins> | Steve^: <h2-6> don't adjust their sizes based on heading. |
| 21:35 | <Steve^> | oh |
| 21:35 | <Lachy> | variable, you should probably not link to those images directly in case Apple moves them again. |
| 21:35 | <variable> | I would find it hilarious and sad at the same time if Hixie decided to be backward compatible with old "new" code and changed the spec to make thework |
| 21:35 | <Lachy> | Upload copies to the wiki |
| 21:35 | <TabAtkins> | Because it's too complex, and anyway if you're relying on sectioning elements you should just use <h1> everywhere. |
| 21:36 | <variable> | Lachy: I will - this is just for getting comment |
| 21:36 | <Steve^> | so if I have a nested <h1><h2> in my article, they'll start to look the same |
| 21:36 | <variable> | *comments |
| 21:36 | <Steve^> | that's a little weird |
| 21:36 | <TabAtkins> | Steve^: Possbly, yeah. |
| 21:36 | <TabAtkins> | If you're using sectioning elements, just use <h1>. |
| 21:37 | <Lachy> | Steve^, yes, it will be a little weird, especially when you have a situation where the <h1> represents a 3rd level heading and the h2 is its subheading. |
| 21:37 | <Lachy> | In that case, the h1 would default to being smaller than the h2 |
| 21:37 | <Steve^> | what's the advantage of that? |
| 21:37 | <Lachy> | so, the solution is to always specify font sizes for headings |
| 21:38 | <Lachy> | it's just the way it works, because there are no style changes for h2s based on section level |
| 21:38 | <Steve^> | you've decided it will work like that though |
| 21:38 | <TabAtkins> | Steve^: The advantage is that if you use <h1> and sectioning elements, it works. If you use <h1-6> and no sectioning elements, it works. |
| 21:38 | <Steve^> | You've create a problem, why? |
| 21:38 | <variable> | Lachy: other than the image uploading thing - any other comments |
| 21:38 | <TabAtkins> | You just can't combine them and rely on defaults working well. |
| 21:38 | <TabAtkins> | So if you combine them, you just set your sizes explicitly, which is common to do anyway. |
| 21:39 | <Lachy> | variable, I'll just make some quick edits |
| 21:39 | <Hixie> | Lachy: oh, you're right, it's needed for ARIA support. my bad. |
| 21:39 | <Steve^> | TabAtkins, so basically I can't make a blog's template with sections and have the content without sections |
| 21:39 | <variable> | Lachy: good - I hate being the only one editing a wiki page |
| 21:39 | <Steve^> | that's a huge flaw in my opinion |
| 21:40 | <Steve^> | I don't want content editors having to use the section element |
| 21:40 | <TabAtkins> | Steve^: Um, no. You just have to specify the sizes of the headings rather than relying on the defaults if you do that. |
| 21:40 | <Lachy> | variable, no need to use <p> markup in the wiki pages. Those are automatic. Just leave a blank line between paragraphs |
| 21:40 | <TabAtkins> | Which is common in any case, so it's not a burden. |
| 21:40 | <Steve^> | and we're back to having dodgy defaults so that everyone needs to do explicit styling |
| 21:40 | <variable> | Lachy: kk - useful to know |
| 21:40 | <Steve^> | that's isn't an improvement |
| 21:41 | <TabAtkins> | Steve^: Sigh. Sure, whatever. If you ignore everything else I've said this whole time, then you're right. |
| 21:41 | <variable> | Lachy: File uploads are disabled. |
| 21:44 | <Steve^> | TabAtkins, unfortunately if I'm wrong, you haven't said it in the right way to convince me otherwise |
| 21:45 | <TabAtkins> | There are 3 cases. 1) Traditional HTML4 document, with <h1-6> and no sectioning elements. This works fine with the defaults. 2) New HTML5 document, with <h1> and sectioning elements. This works fine with the defaults. 3) New HTML5 document, with <h1-6> and sectioning elements. This doesn't work great with the defaults. |
| 21:46 | <TabAtkins> | But in case 3, you're very likely to be styling the page anyway, and explicitly styling and sizing heading elements is very common, so it's not any extra burden on authors to "fix" that case. |
| 21:47 | <variable> | gnight all |
| 21:51 | <Steve^> | If I create my article in a way that it could be distributed, via RSS or on another website or something (which I believe is the point of article), does this not compromise the styling of it? |
| 21:51 | <Steve^> | I could not know if the site hosting my content was using sections or not |
| 21:51 | <Lachy> | Steve^, it would not be possible to adjust the styling of h2 to h6 elements in a reasonable way that would allow for their use as sub headings, while also retaining their backwards compatibility uses |
| 21:51 | <TabAtkins> | Onlyi if it's being displayed in an unstyled page within sectioned content. |
| 21:52 | <Lachy> | well, it might be possible, but it would be very difficult to get right, if it is |
| 21:52 | <Steve^> | So its farfetched, but possible |
| 21:52 | <TabAtkins> | Sure. It's just not a case I care about. |
| 21:53 | <Steve^> | An article would be very difficult to share in this way, as the hoster could have multiple sources, each using a different level of hx as the article heading |
| 21:53 | <Lachy> | actually, now that we have hgroup, coming up with better defaults for h2 to h6 might be easier than it was before we had that |
| 21:53 | <Steve^> | but maybe articles would never really be used in this way, so its not really important |
| 21:53 | <TabAtkins> | Steve^: That situation is equally difficult in purely HTML4 default styling. |
| 21:54 | <Lachy> | since subheadings will always be wrapped in hgroup, adjusting the defaults so that h2 to h6 are styled based on level in that context might work |
| 21:55 | <TabAtkins> | Lachy: You run out of font-size to use a few heading-levels in, though. When your headings are smaller than the default text size you've gone too far. |
| 21:55 | <Lachy> | TabAtkins, yes. there are certainly limits, and h5 and h6 already go beyond those limits |
| 21:56 | <TabAtkins> | I never use beyond <h3>, so I didn't realize that. ^_^ |
| 21:56 | <Steve^> | I think what I find uncomfortable is that the default styling and the outline don't exactly go hand in hand |
| 21:56 | <TabAtkins> | Lachy: Unrelated, but I just realized that XBL2 only allows a handful of pseudoelems to be defined. These don't appear to be sufficient for implementing bindings on, say, <input type=date>. |
| 21:59 | <Hixie> | we can change xbl2 |
| 21:59 | <Lachy> | TabAtkins, you would just use a <template> to replace the control completely |
| 22:00 | <TabAtkins> | Lachy: Ah, true. And just embed the styling in the <xbl>, right? |
| 22:00 | <Lachy> | yes |
| 22:00 | <TabAtkins> | That seems fine. |
| 22:00 | <Lachy> | IIRC, the pseudo-elements just allow the page styles to affect certain aspects of the XBL template |
| 22:02 | <Lachy> | but it's been so long since I've looked at XBL, I don't remember all the details. |
| 22:02 | <Lachy> | but Jonas told me he'll be working on it soon, so I might finally get a chance to play around with it |
| 22:03 | <TabAtkins> | Right, they're just for easy access to some of the shadow elements from page CSS. |
| 22:04 | <Steve^> | I don't mean to drag on, but I'm interesting - who is the default styling targeted towards? |
| 22:04 | <Lachy> | TabAtkins, according to the XBL draft, pseudos defined in future CSS specs can also be used in XBL. So if CSS does define new date control speciic pseudos, then the XBL template can include those and auhors can then style the shadow tree using their page styles |
| 22:05 | <TabAtkins> | Steve^: People who use just <h1> and sectioning elements. |
| 22:06 | <Lachy> | Hixie, has there been any thought about supporting annotations on videos, like those supported on YouTube? |
| 22:06 | <TabAtkins> | Lachy: Ah, right. I skipped over that line in 2.8, and was just looking at 4.7.4 |
| 22:06 | <Lachy> | None of the kinds supported by track seemed appropriate for that use case |
| 22:06 | <Hixie> | Lachy: natively? or via JS? |
| 22:07 | <Lachy> | natively |
| 22:07 | <Hixie> | Lachy: sure, just use SMIL/SVG |
| 22:07 | <Lachy> | linked to with a <track> element? |
| 22:08 | <Hixie> | no, as the main content of the <video> element |
| 22:08 | <Hixie> | or as an overlaid <video> element, once we do synchronised video playback |
| 22:08 | <Lachy> | ah, ok. So <video src="whatever.smil">, where the SMIL links to the the SVG and video content? |
| 22:08 | <Steve^> | or I can use sectioning as long as the h1 is my site header and my articles start at h2 |
| 22:09 | <Hixie> | yeah |
| 22:09 | <Hixie> | (@lachy) |
| 22:09 | <TabAtkins> | Steve^: Sure, that works too. |
| 22:10 | <Steve^> | I assume screen readers have some way of translating the level of a heading? |
| 22:10 | <TabAtkins> | The idea is that browsers will expose the correct heading level automatically (Lachy mentioned this earlier as something Opera has to do). |
| 22:10 | <Lachy> | Steve^, the default styling is really intended to help authors, especially when working on unstyled pages, to understand the structure of their documents |
| 22:11 | <Steve^> | TabAtkins, based solely on the outline? |
| 22:11 | <Hixie> | bbl |
| 22:12 | <Lachy> | Hixie, if SMIL can handle the annotation case, couldn't it also handle subtitles and captions too? Why then are we adding <track>? Is that just to make it easier for authors? |
| 22:12 | <TabAtkins> | Steve^: Yes. |
| 22:18 | <Steve^> | head, header, heading.. I think we're just missing headline |
| 22:51 | <Hixie> | Lachy: subtitles and captions don't require as much complexity as annotations, so we can handle them with far less authoring burden |
