Re: [whatwg] (was Support Existing Content)

Adrian Sutton wrote: That said, by default our editor outputs the span tag version because we like to follow standards and I recommend using our styles menu to apply CSS classes and appropriate structural markup (headings etc). We did however have to go back and add an option to output font tags

Re: [whatwg] Saying +1 or -1 is not useful on this mailing list

David Hyatt wrote: (ducks) +1 It is best to duck sometimes. Seems like I read that somewhere. If I could just remember it, now. Is there a special dispensation somewhere for those who would like to help write specs who are cursed with *really* bad memories? Oh and thanks for ducking. I

Re: [whatwg] Cue points in media elements

Hearing about cue points in media elements. Just sorta reminds me of keyTimes in SMIL. I know SMIL seems funky to some people, but I do really love it! It is so way cool! So far as I know it doesn't do quite what you're talking about here, but it does similar stuff including non-linear distort

Re: [whatwg] (was Support Existing Content)

On 2/5/07 11:40 AM, "Jon Barnett" <[EMAIL PROTECTED]> wrote: >> Embedded and inline editors would include the textarea tag, which is clearly >> not WYSIWYG for HTML (but is for plain text) so both are poor terms. > > Embedded, inline editors would include "contenteditable" areas and documents > wi

Re: [whatwg] (was Support Existing Content)

Embedded and inline editors would include the textarea tag, which is clearly not WYSIWYG for HTML (but is for plain text) so both are poor terms. Embedded, inline editors would include "contenteditable" areas and documents with "designMode" on, like the box I'm typing in right now in Gmail. Qu

Re: [whatwg] (was Support Existing Content)

On 2/5/07 1:28 AM, "Sander Tekelenburg" <[EMAIL PROTECTED]> wrote: > That's one, yes. But also plenty of people don't even distinguish between the > editor embedded within a publishing tool, and the publishing tool as a whole. > So as it is phrased now in WebApps 1.0, I wouldn't be surprised if it

Re: [whatwg] Issues concerning the element and xml:base

Ian Hickson wrote: On Sun, 11 Feb 2007, Geoffrey Sneddon wrote: Safari 2.0.4/419.3: (1) Inserted in DOM (in the innerHTML location). Firefox 2.0.0.1: (3) Inserted in DOM (in the innerHTML location). IE/Mac 5.2.3: (2) (anyway to view the DOM tree?) Opera 9.10: (1) DOM Snapshot for some reason isn

Re: [whatwg] element

Maciej Stachowiak wrote: On Apr 27, 2007, at 3:36 AM, Jonas Sicking wrote: Martin Atkins wrote: Christian Schmidt wrote: In practice, the result effect is often achieved by wrapping your include file in a document.write() and including this using script a

Re: [whatwg]

At 12:47 -0500 UTC, on 2007-05-01, Jon Barnett wrote: [...] > the only attribute specifically allowed on is the "style" attribute. Whoops. Somehow I overlooked that. My bad. But given that, I *really* don't see the point of anymore. I've searched the archive at

Re: [whatwg] additional empty elements

On 5/1/07, Brenton Strine <[EMAIL PROTECTED]> wrote: If all HTML tags imply some meaning, then you are advocating the elimination of presentation, not it's separation. An HTML document ought to make semantic sense, without regard to presentational information. The very definition of the separa

Re: [whatwg] Cue points in media elements

On May 1, 2007, at 1:05 PM, Kevin Calhoun wrote: I believe that a cue point is "reached" if its time is traversed during playback. What does "traversed" mean in terms of (a) seeking across the cue point (b) playing in reverse (rewinding) and (c) the media stalling an restarting at a later

Re: [whatwg] Cue points in media elements

On Apr 30, 2007, at 7:15 PM, Ralph Giles wrote: Thanks for adding to the discussion. We're very interested in implementing support for presentations as well, so it's good to hear from someone with experience. Thanks for responding, I'm glad to hear your input. On Sun, Apr 29, 2007 at 03:14:2

Re: [whatwg] additional empty elements

> HTML is a language for markup meaningful by itself, not just as a hook for CSS. > doesn't mean anything. That doesn't seem very practical to me. If all HTML tags imply some meaning, then you are advocating the elimination of presentation, not it's separation. If there weren't any CSS hooks, wou

Re: [whatwg] additional empty elements

If you're marking up stuff as a tree, the markup should probably look like a tree: First group Second Group Third Group if what you want it a tree, that structure is better, so the CSS would simply say: #tree, #tree div { margin-left: 5em; } If you want to style each level differently, that's

Re: [whatwg] additional empty elements

On Tue, 01 May 2007 21:21:20 +0200, Brenton Strine <[EMAIL PROTECTED]> wrote: A nice solution would be the addition of a few div tags. (e.g. , , and .) Then you could do something like this: HTML is a language for markup meaningful by itself, not just as a hook for CSS. doesn't mean anyt

[whatwg] additional empty elements

I would like to know what other people think about creating more empty elements in HTML5. Say, for example, you have a website which has sections of content that are indented variously. It would be easy to accomplish the different styles using classes: This text isn't indented at all! Thi

Re: [whatwg] (was Support Existing Content)

On 5/1/07, Smylers <[EMAIL PROTECTED]> wrote: Jon Barnett writes: > If is allowed, then could be allowed, because a > server-side script could more easily find and replace it > with . Why would that be a correct thing to do? If somebody has made text large for emphasis or other effect, the

Re: [whatwg] (was Support Existing Content)

Jon Barnett writes: > If is allowed, then could be allowed, because a > server-side script could more easily find and replace it > with . Why would that be a correct thing to do? If somebody has made text large for emphasis or other effect, then labelling it as a heading would be wrong, surel

Re: [whatwg] (was Support Existing Content)

The current phrasing doesn't restrict this to span. It allows "WYSIWYG editors" to produce blah where blah is appropriate. If I understand correctly, even that wouldn't be correct, because the only attribute specifically allowed on is the "style" attribute. I don't personally know of any

Re: [whatwg] Cue points in media elements

On Apr 30, 2007, at 4:15 PM, Ralph Giles wrote: [On Apr 29, 2007, at 12:14 AM, Brian Campbell wrote:[ If video playback freezes for a second, and so misses a cue point, is that considered to have been "reached"? As I read it, cue point

Re: [whatwg] (was Support Existing Content)

At 12:48 +1000 UTC, on 2007-05-01, Adrian Sutton wrote: [...] > The only debate about what a WYSIWYG editor is on the web is between a very > strict interpretation (it must look precisely like what you get) and the > What You See Is What You Mean editors. That's one, yes. But also plenty of peop

Re: [whatwg] classList.toggle()

On May 1, 2007, at 12:05 AM, Martin Atkins wrote: Maciej Stachowiak wrote: How about about adding a toggle() operation to classList? Adds the token if not present, removes it if present. This would be useful for script code that dynamically manipulates classes to cause style changes. It

Re: [whatwg] Cue points in media elements

On 4/29/07, Brian Campbell <[EMAIL PROTECTED]> wrote: For the sort of content that we produce, cue points are incredibly important. Most of our content consists of a video or voiceover playing while bullet points appear, animations play, and graphics are revealed, all in sync with the video. We

Re: [whatwg] classList.toggle()

Maciej Stachowiak wrote: How about about adding a toggle() operation to classList? Adds the token if not present, removes it if present. This would be useful for script code that dynamically manipulates classes to cause style changes. It's been my experience that toggles are troublesome.