Re: [whatwg] HTML5: New link-types regarding guideline 2.4 in WCAG 2.0

Henrik Lied wrote: In one of the comments in that post, it was proposed to use the LINK element with a REL attribute which relates to the different sections of the site. ... NAVIGATION Relates to the main site-navigation CONTENT Relates to the hea

Re: [whatwg] HTML5: New link-types regarding guideline 2.4 in WCAG 2.0

On Wed, 13 Apr 2005, Henrik Lied wrote: > > I would therefore propose that these link-types should be recommended in > the Web Applications 1.0 WD: > > NAVIGATION Relates to the main site-navigation > CONTENT Relates to the head of content > ADDI

Re: [whatwg] HTML5: Deprecate the SMALL element

On Wed, 13 Apr 2005, Henrik Lied wrote: > > The element SMALL should be deprecated, as it describes the appearance > of the content. Alternatively, a new name for the element could be > created. > > Since SMALL is usually used to describe copyright-notices and other > legal descriptions, my pro

[whatwg] HTML5: New link-types regarding guideline 2.4 in WCAG 2.0

In guideline 2.4 of the Web Content Accessibility Guidelines 2 (http://www.w3.org/TR/2004/WD-WCAG20-20041119/#navigation-mechanisms) it is recommended to add a visual skip link to jump to the different sections of a document. As Anne van Kesteren writes about in his post named 'Skip links should

Re: [whatwg] HTML5: Deprecate the SMALL element

Hey I like naming things! How about DEM for de-emphasise? -dean Henrik Lied wrote: The element SMALL should be deprecated, as it describes the appearance of the content. Alternatively, a new name for the element could be created. Since SMALL is usually used to describe copyright-notices and other

[whatwg] HTML5: Deprecate the SMALL element

The element SMALL should be deprecated, as it describes the appearance of the content. Alternatively, a new name for the element could be created. Since SMALL is usually used to describe copyright-notices and other legal descriptions, my proposal for a new name is DISCLAIMER or NOTES. -- --

Re: [whatwg] [html5] 2.6.1. The a element

On Tue, 12 Apr 2005, Christoph Päper wrote: > > > > So what does an element with no href="" represent? Nothing? Or I > > guess we could make the href="" attribute required. > > I frequently use and advice to do navigation lists like this: > > > Home > ... > Current page > ..

Re: [whatwg] [html5] 2.6.1. The a element

*Ian Hickson <[EMAIL PROTECTED]>*: So what does an element with no href="" represent? Nothing? Or I guess we could make the href="" attribute required. I frequently use and advice to do navigation lists like this: Home ... Current page ... Contact (I use 'map', because

Re: [whatwg] [wf2] broken diff links

On Tue, 12 Apr 2005, Anne van Kesteren wrote: > > The links to the diff files: > > ... are both broken. Yeah, I was having problems with the diff tool earlier and then my laptop had a hardwre crash and I forgot about it. I've restarted the diffin

Re: [whatwg] [html5] 2.6.4. The small element

On Tue, 12 Apr 2005, Anne van Kesteren wrote: > > It looks like the draft says that it does "de-emphasise" text and does > "de-important" text when such text does not have an ancestor EM or > STRONG element. If this is just a note to make sure people don't > misunderstand the element, make it a

[whatwg] [wf2] broken diff links

The links to the diff files: ... are both broken. -- Anne van Kesteren

[whatwg] [html5] 2.6.4. The small element

It looks like the draft says that it does "de-emphasise" text and does "de-important" text when such text does not have an ancestor EM or STRONG element. If this is just a note to make sure people don't misunderstand the element, make it a note. If you actually mean what I just wrote it might b

Re: [whatwg] [html5] 2.6.1. The a element

On Tue, 12 Apr 2005, Anne van Kesteren wrote: > > > > > > Shouldn't the XML model (and therefore the specification) allow > > > nested links? > > > > I don't know, what would it mean? What would the DOM events processing > > model be? > > Perhaps we could ask the XLink WG (or XML Core, or whate

Re: [whatwg] [html5] 2.6.1. The a element

Ian Hickson wrote: Shouldn't the XML model (and therefore the specification) allow nested links? I don't know, what would it mean? What would the DOM events processing model be? Perhaps we could ask the XLink WG (or XML Core, or whatever) and the HTML WG (XHTML 2)... Fair enough. So what does an

Re: [whatwg] [html5] 2.6.1. The a element

On Tue, 12 Apr 2005, Anne van Kesteren wrote: > > Shouldn't the XML model (and therefore the specification) allow nested > links? I don't know, what would it mean? What would the DOM events processing model be? > Also, I think this part should be removed: > > # Otherwise, it represents an anc

Call four comments 4 is out (Was: [whatwg] Web Forms 2.0 submission to W3C)

On Tue, 12 Apr 2005, Anne van Kesteren wrote: > > > > We'll be publishing another call for comments that takes into account > > the technical comments that W3C staff sent to us privately as very > > soon. > > I saw a call for comments has already been published but not yet > announced. Is that

[whatwg] [html5] 2.6.1. The a element

Shouldn't the XML model (and therefore the specification) allow nested links? Also, I think this part should be removed: # Otherwise, it represents an anchor: a possible end-point for other # hyperlinks. ... because every element represents an anchor. (Perhaps this should be added to the descripti

Re: [whatwg] elements containing other block-level elements

On Tue, 12 Apr 2005, Henri Sivonen wrote: On Apr 12, 2005, at 12:31, Ian Hickson wrote: Many people feel that a minor typo in their document should not cause their page to stop rendering altogether. I have spoken with a _lot_ of authors who really do not like XML's draconian error handling, includi

Re: [whatwg] Web Forms 2.0 submission to W3C

Also sprach Dean Jackson: > > Overall it seems like a good thing though. > > I think so. Like I said in the comment, the important point for us > is to build a single community for improving forms on the Web. I agree with this; I think we have rough consensus in the web community within reac

Re: [whatwg] Web Forms 2.0 submission to W3C

On 12 Apr 2005, at 20:31, Olav Junker Kjær wrote: Ian Hickson wrote: FYI, the W3C has just acknowledged receipt of the Web Forms 2.0 draft that Mozilla and Opera submitted (on behalf of the WHATWG). Is this good or bad news? The W3C does not seem very enthusiastic about the submission. I apologis

Re: [whatwg] Web Forms 2.0 submission to W3C

Also sprach Anne van Kesteren: > > FYI, the W3C has just acknowledged receipt of the Web Forms 2.0 draft that > > Mozilla and Opera submitted (on behalf of the WHATWG). > > Any reason Apple didn't participate? We tried to submit WF2 in time to be announced at the W3C Plenary meeting in Bost

Re: [whatwg] Web Forms 2.0 submission to W3C

On 12 Apr 2005, at 20:49, Anne van Kesteren wrote: Ian Hickson wrote: FYI, the W3C has just acknowledged receipt of the Web Forms 2.0 draft that Mozilla and Opera submitted (on behalf of the WHATWG). We'll be publishing another call for comments that takes into account the technical comments tha

Re: [whatwg] Web Forms 2.0 submission to W3C

Also sprach Olav Junker Kjær: > > It is the first step to working with the W3C to move the > > development of the WHATWG specifications into the W3C fold, while keeping > > the open nature of the WHATWG development process. > > Thats cool, but isn't this going to delay the spec for years?

Re: [whatwg] elements containing other block-level elements

On Tue, 12 Apr 2005, Lachlan Hunt wrote: > > > > > > To use like , one would have to style it with > > > > > > pre>code:only-child { display: block; } > > > > Hm? Why? > > Where this is the need to apply styles to block of code, such as a > background colour or border, but those styles don't

Re: [whatwg] elements containing other block-level elements

On Apr 12, 2005, at 12:31, Ian Hickson wrote: Many people feel that a minor typo in their document should not cause their page to stop rendering altogether. I have spoken with a _lot_ of authors who really do not like XML's draconian error handling, including many authors who are always ensuring t

Re: [whatwg] elements containing other block-level elements

Ian Hickson wrote: On Tue, 12 Apr 2005, Lachlan Hunt wrote: We haven't discussed it yet. I hadn't really thought about it but given: ... ... To use like , one would have to style it with pre>code:only-child { display: block; } Hm? Why? Oh, sorry. I assume your asking about why display: b

Re: [whatwg] elements containing other block-level elements

Matthew Thomas wrote: Lachlan Hunt wrote: ... I don't understand what's wrong with the XML error handling. I think it's great because errors should be caught and handled during the authoring process and by the CMS, which XML essentially forces.

Re: [whatwg] elements containing other block-level elements

Henri Sivonen wrote: Writing software that is guaranteed to emit well-formed XML is not particularly hard. The problem is people consider XML a lax text format that can be produced with ad hoc print statements. On the other hand, if

Re: [whatwg] elements containing other block-level elements

On Apr 12, 2005, at 13:02, Matthew Thomas wrote: Writing software that is guaranteed to emit well-formed XML is not particularly hard. The problem is people consider XML a lax text format that can be produced with ad hoc print state

Re: [whatwg] Web Forms 2.0 submission to W3C

Ian Hickson wrote: It is good news. Congratulations then! :-) It is the first step to working with the W3C to move the development of the WHATWG specifications into the W3C fold, while keeping the open nature of the WHATWG development process. Thats cool, but isn't this going to delay the spec f

Re: [whatwg] Web Forms 2.0 submission to W3C

Ian Hickson wrote: FYI, the W3C has just acknowledged receipt of the Web Forms 2.0 draft that Mozilla and Opera submitted (on behalf of the WHATWG). Any reason Apple didn't participate? We'll be publishing another call for comments that takes into account the technical comments that W3C staff se

Re: [whatwg] elements containing other block-level elements

On Tue, 12 Apr 2005, Anne van Kesteren wrote: > > > > Q is for quoting something that is part of a paragraph. BLOCKQUOTE is > > for quoting something that contains paragraphs. > > So BLOCKQUOTE doesn't fit inside a paragraph IMHO. So it also doesn't > fit inside the model of structured inline-c

Re: [whatwg] Web Forms 2.0 submission to W3C

On Tue, 12 Apr 2005, Olav Junker Kjær wrote: > Ian Hickson wrote: > > FYI, the W3C has just acknowledged receipt of the Web Forms 2.0 draft > > that Mozilla and Opera submitted (on behalf of the WHATWG). > > Is this good or bad news? The W3C does not seem very enthusiastic about > the submission

Re: [whatwg] elements containing other block-level elements

Ian Hickson wrote: You missed . Oops, yep. Added. Q is for quoting something that is part of a paragraph. BLOCKQUOTE is for quoting something that contains paragraphs. So BLOCKQUOTE doesn't fit inside a paragraph IMHO. So it also doesn't fit inside the model of structured inline-content. The who

Re: [whatwg] Web Forms 2.0 submission to W3C

Ian Hickson wrote: FYI, the W3C has just acknowledged receipt of the Web Forms 2.0 draft that Mozilla and Opera submitted (on behalf of the WHATWG). Is this good or bad news? The W3C does not seem very enthusiastic about the submission. How is this going to affect the development of the spec? Ol

Re: [whatwg] elements containing other block-level elements

Lachlan Hunt wrote: ... I don't understand what's wrong with the XML error handling. I think it's great because errors should be caught and handled during the authoring process and by the CMS, which XML essentially forces. I don't think user agents should have to gracefully handle errors when

Re: [whatwg] Image maps: should we drop ?

On Tue, 12 Apr 2005, Lachlan Hunt wrote: > > > > While it is definitely a better design than ,it isn't a > > substantially better design, > > How so? Although might have a slightly less presentational name > than , the semantics of both are identical when used for an image > map. It's a bet

Re: [whatwg] elements containing other block-level elements

On Tue, 12 Apr 2005, Anne van Kesteren wrote: > Ian Hickson wrote: > > > You missed . > > > > Oops, yep. Added. > > I could see the point with CODE versus PRE versus CODE as only child of > PRE as they have different kind of semantics. > > But what is the reason for BLOCKQUOTE? Clearly, Q is for

Re: [whatwg] elements containing other block-level elements

On Tue, 12 Apr 2005, Lachlan Hunt wrote: > > > > We haven't discussed it yet. I hadn't really thought about it but given: > > > > ... > > ... > > To use like , one would have to style it with > > pre>code:only-child { display: block; } Hm? Why? > > I think we'll probably be "stuc

Re: [whatwg] elements containing other block-level elements

Ian Hickson wrote: You missed . Oops, yep. Added. I could see the point with CODE versus PRE versus CODE as only child of PRE as they have different kind of semantics. But what is the reason for BLOCKQUOTE? Clearly, Q is for inline and you don't really need BLOCKQUOTE for that. (If you want to quot