Re: [whatwg] [html5] tags, elements and generated DOM

[Ian Hickson]

On Wed, 6 Apr 2005, Lachlan Hunt wrote:
> > > >
> > > > The  will always be implied, though.
> > > 
> > > Not in a conforming SGML parser...
> > 
> > Yeah, I meant in browsers, not per SGML.
> 
> Ok, fair enough.  But can you explain why Opera doesn't when in 
> standards- compliant mode, as I explained in my previous e-mail.  Is it 
> a bug or intentional?

Bug.


> Ok, if the spec is going to address this, then I think it should say 
> something like:
> 
>   "If a required element with an optional start-tag is entirely missing
>from the document, a user agent *may* imply it and include it within
>the DOM.  Missing elements with required start-tags *must not* be
>automatically implied.
> 
>   "Note: It is common for existing user agents to automatically imply
>both the head and body elements, even when those sections are omitted
>entirely from the document markup."

I'll investigate this in more detail when I write the section on how to 
parse HTML. Backwards-compatibility with the common subset of what is 
actually implemented is my top priority though.


> I used "may", because if "must" or "should" were used instead, it may 
> conflict with anything the SGML spec says on the matter and it would 
> make OpenSP, and thus the validator, non-conformant.  I would stick with 
> "may" because, as I showed previously, existing UAs don't do the same 
> for .

OpenSP is already non-conformant to HTML5. See:

   http://whatwg.org/specs/web-apps/current-work/#conformance

In any case, assuming I'm still the editor when the parsing section gets 
written, HTML5 will most likely stop the pretense of HTML being an SGML 
application.


> Also, while on the topic of handling invalid documents, is this spec 
> going to attempt to address the  problem?

Probably not, as there is no generally accepted solution. In fact there is 
no known solution (to my knowledge) that is entirely satisfactory.


> > since an HTML4 document without a  is invalid and thus parsing 
> > is undefined in HTML4.
> 
> Is it not defined by SGML either?  I really must get a copy of 
> Goldfarb's SGML Handbook later and check for sure.

SGML doesn't define error handling rules either as far as I recall from 
the last time I read Goldfarb. But either way, HTML4 overrides SGML in 
several places and explicitly states that handling of invalid HTML 
documents is undefined and UA-dependent. (Well, actually, it's about as 
vague about this as about everything else. But relative to how explicit it 
is about everything else, it's pretty clear about this.)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [html5] tags, elements and generated DOM

[Lachlan Hunt]

Ian Hickson wrote:
On Wed, 6 Apr 2005, Lachlan Hunt wrote:
The  will always be implied, though.
Not in a conforming SGML parser...
Yeah, I meant in browsers, not per SGML.
Ok, fair enough.  But can you explain why Opera doesn't when in 
standards-compliant mode, as I explained in my previous e-mail.  Is it a 
bug or intentional?

According to the HTML spec, the 
handling of the above is completely undefined since it is invalid. (Note 
that something being invalid or non-conformant does _not_ make the 
rendering undefined in most cases in Web Apps 1 / HTML5. That's one of the 
main things I'm making sure of.)
Ok, if the spec is going to address this, then I think it should say 
something like:

  "If a required element with an optional start-tag is entirely missing
   from the document, a user agent *may* imply it and include it within
   the DOM.  Missing elements with required start-tags *must not* be
   automatically implied.
  "Note: It is common for existing user agents to automatically imply
   both the head and body elements, even when those sections are omitted
   entirely from the document markup."
I used "may", because if "must" or "should" were used instead, it may 
conflict with anything the SGML spec says on the matter and it would 
make OpenSP, and thus the validator, non-conformant.  I would stick with 
"may" because, as I showed previously, existing UAs don't do the same 
for .

I included the part about start-tags because elements like  (which 
require a start-tag) do not be implied by existing UAs when they are 
missing.

Also, while on the topic of handling invalid documents, is this spec 
going to attempt to address the  problem?

However, if the  element were to be automatically implied 
regardless, then the same would be true of the  element...
Neither Mozilla or Opera implies the missing tbody element within 
, although IE does. However, OpenSP does not imply the 
missing elements in either case.
 is implied if there is a  there.
Yes, exactly, just like  is implied if there is a , , or 
other element/content there; but not if there isn't.

Opera and OpenSP correctly don't imply the missing head element.
I'm not sure what you mean by "correctly" here
Well, I read somewhere that OpenSP is "the reference implementation" of 
SGML, so I assumed that means what it does is correct.  In this case, 
Opera showed the same behaviour so I called it correct as well. 
However, if this behaviour is not defined in SGML at all, then I should 
not have said "correctly" either.

since an HTML4 document without a  is invalid and thus parsing
is undefined in HTML4.
Is it not defined by SGML either?  I really must get a copy of 
Goldfarb's SGML Handbook later and check for sure.

If there is a  then the  must be implied per SGML.
Agreed.
--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

Re: [whatwg] Web Forms 2.0

[Joe Gregorio]

On Apr 5, 2005 8:36 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Apr 2005, Joe Gregorio wrote:
> > > >
> > > > "If the specified method is not one of get, post,
> > > >  put, or delete then it is treated as *post* in the tables
> > > >  below."
> > >
> > > I agree. Sadly, doing this would break compatibility with existing
> > > implementations, which all treat unknown values as "get".
> >
> > Would that really 'break' anything? If that is the default behaviour
> > today then clients would expect not to be able to send a request body
> > with a method outside POST and PUT. Adding that capability won't break
> > their code, will it?
> 
> If anyone has a form that says:
> 
>
> 
> ...then at the moment it'll be treated as GET. If you change the default
> to "post", it'll no longer be treated as GET.

I knew there must be a case that I was over-looking. That makes sense.
 
> I really don't feel comfortable changing things that all browsers do. If
> all the browsers interoperate on something, we should celebrate that thing
> and leave it well alone... It's so rare...

I can't argue with that :)

Thanks,
-joe

-- 
Joe Gregoriohttp://bitworking.org

Re: [whatwg] Web Forms 2.0

[Ian Hickson]

On Tue, 5 Apr 2005, Joe Gregorio wrote:
> > >
> > > "If the specified method is not one of get, post,
> > >  put, or delete then it is treated as *post* in the tables 
> > >  below."
> > 
> > I agree. Sadly, doing this would break compatibility with existing 
> > implementations, which all treat unknown values as "get".
> 
> Would that really 'break' anything? If that is the default behaviour 
> today then clients would expect not to be able to send a request body 
> with a method outside POST and PUT. Adding that capability won't break 
> their code, will it?

If anyone has a form that says:

   

...then at the moment it'll be treated as GET. If you change the default 
to "post", it'll no longer be treated as GET.

I really don't feel comfortable changing things that all browsers do. If 
all the browsers interoperate on something, we should celebrate that thing 
and leave it well alone... It's so rare...

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Web Forms 2.0

[Joe Gregorio]

On Apr 5, 2005 6:50 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Sat, 26 Mar 2005, Joe Gregorio wrote:
> 
> > In the Web Forms 2.0 Working Draft dated 16 March 2005
> >
> >5.6. Submitting the encoded form data set
> >
> > "If the specified method is not one of get, post,
> >  put, or delete then it is treated as get in the tables below."
> >
> > It would be much better if just one word of that sentence was changed:
> >
> > "If the specified method is not one of get, post,
> >  put, or delete then it is treated as *post* in the tables below."
> 
> I agree. Sadly, doing this would break compatibility with existing
> implementations, which all treat unknown values as "get".

Would that really 'break' anything? If that is the default behaviour today
then clients would expect not to be able to send a request body with a
method outside POST and PUT. Adding that capability won't break their
code, will it?

   Thanks,
-joe

-- 
Joe Gregoriohttp://bitworking.org

Re: [whatwg] Web Forms 2.0 Feedback

[Ian Hickson]

On Tue, 5 Apr 2005, Dean Edwards wrote:
> > 
> > Yeah, several people have said that. We're thinking about removing it. 
> > On the other hand, several people have said that it is a godsend and 
> > that they are so happy it is there because they are fed up of rolling 
> > their own. At the moment it's about equally matched, in fact.
> > 
> > The model is pretty simple and relatively easy to implement, so I'm 
> > leaning towards keeping it.
> 
> Ian, I thought we'd sorted this out. We had exactly the same discussion 
> a few weeks back and nobody came up with any objections to the current 
> model.

Someone just did - Csaba. :-)


> I quite like Olav's idea to separate the Repetition Model from 
> the existing WF2 spec. This would give us time to discuss it a bit more 
> without impacting the rest of WF2. Maybe the Repetition Model should be 
> separate anyway? Personally, if I was considering using it on a site, 
> I'd prefer to print off a separate spec to read. But that's just me. I 
> /do/ recognise that this is a bit of an editorial headache however... 
> ;-)

There are basically three reasons for which I'd rather not split that bit 
out. First, as you say, it would be a pain to do. Second, it wouldn't be 
very clean. While the spec _looks_ like it's neatly organised and cutting 
it out would just mean cutting out section 3, it really isn't that simple. 
The repetition model is deeply embedded in the DOM sections and the form 
submission and seeding sections. (And rightfully so -- the repetition 
model integrates with those sections so as to provide the features that 
can't be easily provided if people implement it by hand.)

The third reason is that I don't see why we need "more time" to discuss 
it. We've had the last two months to discuss it and there's been nothing 
really said. If it was really being discussed and some deadline was coming 
up, then I would agree -- but unless that actually happens, then I don't 
see how a delay would help.

Anyway, I've removed the "open issue" in the status section about whether 
the repetition model should be kept. As you pointed out, the views in 
favour of keeping it are stronger than the views suggesting it be removed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Web Forms 2.0 Feedback

[Dean Edwards]

Ian Hickson wrote:
On Thu, 24 Mar 2005, Csaba Gabor wrote:
2.  Repetition model.
The Draft has a huge amount of space devoted to this,
but I haven't been able to think of a single compelling
argument for it.  Most of the control enhancements such
as validation are conveniences, after all, but what they
have going for them is that they are very compact.  This
repetition model is huge and messy and there are simple
javascript programming methods that allow you to do the
same thing.  This developer's opinion is that I would
far rather roll my own and not even have the possibility
of using this construct.

I'd be interested to know what your home-rolled solution would look 
like. If we can cater for your requirements then we have a flexible model.

Yes, there are already JavaScript alternatives but they are difficult to 
produce and become even more complex when trying for a cross-browser 
solution. What I like about the WF2 Repetition Model is that caters for 
99% of cases. There will always be edge cases but existing DOM methods, 
as you say, provide a means for building particular models already. In 
other words, if you feel that the Repetition Model is inadequate, please 
specify...

Yeah, several people have said that. We're thinking about removing it. On 
the other hand, several people have said that it is a godsend and that 
they are so happy it is there because they are fed up of rolling their 
own. At the moment it's about equally matched, in fact.

The model is pretty simple and relatively easy to implement, so I'm 
leaning towards keeping it.

Ian, I thought we'd sorted this out. We had exactly the same discussion 
a few weeks back and nobody came up with any objections to the current 
model. I quite like Olav's idea to separate the Repetition Model from 
the existing WF2 spec. This would give us time to discuss it a bit more 
without impacting the rest of WF2. Maybe the Repetition Model should be 
separate anyway? Personally, if I was considering using it on a site, 
I'd prefer to print off a separate spec to read. But that's just me. I 
/do/ recognise that this is a bit of an editorial headache however... ;-)

-dean

Re: [whatwg] Web Forms 2.0

[Ian Hickson]

On Sat, 26 Mar 2005, Joe Gregorio wrote:

> In the Web Forms 2.0 Working Draft dated 16 March 2005
> 
>5.6. Submitting the encoded form data set
> 
> "If the specified method is not one of get, post, 
>  put, or delete then it is treated as get in the tables below."
> 
> It would be much better if just one word of that sentence was changed:
> 
> "If the specified method is not one of get, post, 
>  put, or delete then it is treated as *post* in the tables below."

I agree. Sadly, doing this would break compatibility with existing 
implementations, which all treat unknown values as "get".

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [html5] tags, elements and generated DOM

[Ian Hickson]

On Tue, 5 Apr 2005, Anne van Kesteren wrote:
> Ian Hickson wrote:
> > > The head element seems to be implied by Mozilla and IE.
> > 
> > Even when there are no elements that imply a ? I meant, e.g.,
> > when parsing the empty string as HTML. My understanding was that no
> >  element was generated in that case.
> 
>  
> 
> ... generates both in Firefox 1.0 and in recent nightlies:
> 
>  HTML
>   HEAD
>   BODY

I stand corrected.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [html5] tags, elements and generated DOM

[Anne van Kesteren]

Ian Hickson wrote:
The head element seems to be implied by Mozilla and IE.
Even when there are no elements that imply a ? I meant, e.g.,
when parsing the empty string as HTML. My understanding was that no
 element was generated in that case.
 
... generates both in Firefox 1.0 and in recent nightlies:
 HTML
  HEAD
  BODY
... I haven't tested in other browsers.
--
 Anne van Kesteren
 

[whatwg] Re: why, e.g., input/@checked="checked" ?

[Jukka K. Korpela]

On Thu, 31 Mar 2005, fantasai wrote:

> What Jukka's trying to say is, attribute minimalization in SGML -- which
> lets you do things like
>
> doesn't let you leave out the name of the attribute -- it lets you leave
> out the *value*.

Of course, you meant just the opposite: the name can is omitted (in
"classic" HTML), when the value is one of the declared enumerated values
of an attribute and no other attribute has such a value that way.

> So, for example, I could use attribute minimalization to
> shorten the 'type="checkbox"' part like so:
>

Indeed, i.e. the attribute _names_ input and checked are omitted.
Of course, browsers won't grok this except for the latter, since they only
know a limited number of special cases. Similarly, , no matter
how valid in "classic" HTML, won't work in practice.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

[whatwg] WhatWG spec addition?

[UJS Contact US]

Title: Message



I just came across your work 
today - and I applaud your efforts!!!
 
I especially liked how you want 
to expand browsers fully into web applications from the original "document" 
oriented spec. I am sure that concept takes some heat from the 
"purists"...
 
 
I gave the specs a quick scan - specifically for one element 
which I have an interest in... that of the standard "select 
tag"...
 
I believe this list selector 
should be updated to provide columnar data formatting and enable properties 
that include: Greenbar (alternating colors - odd rows/even rows), header row, 
header column.
 
I have a very rough 
"whitepaper" on my website showing an example... Please take a look - it is a 
short read. 
 
http://www.aujsproduction.com/samples/wishlist/revampedselector.asp
 
 
Again - I applaud your efforts 
to bring web apps up to (or exceed) the level of abilities we have had in 
compiled apps since the DOS days...
 


I will take a closer look at 
the entire doc to see what else I might be able to 
"suggest".
 
John Burns
aUJSproduction.com
 
I appreciate your efforts 
to not share my e-mail address. I despise junk mail and work very hard to 
exclude it and to eradicate it. Please help me 
out.

[whatwg] ContextAgnosticXmlHttpRequest: an informal RFC

[Chris Holland]

Hi all :)

I was hoping some of you might be able to give me some feedback on an
informal RFC i put together on my blog:

http://chrisholland.blogspot.com/2005/03/contextagnosticxmlhttprequest-informal.html

I'm basically looking to enable some sort of cross-host *and*
cross-domain interoperability between documents via a modified clone
of the XmlHttpRequest object, while attempting to tread very carefully
on various security issues, such as Cookies and Basic-Auth
credentials. A "ContextAgnosticXmlHttpRequest" would be a new object
developers could use, beyond the traditional XmlHttpRequest.

i'm not crazy about the ContextAgnostic* prefix ... but that's all i
could come-up with so-far.
It would obviously have a very very limited use and would absolutely
not negate the usefulness of an XmlHttpRequest.

I would look to use such object with non-transactional RESTful services/APIs

thank you for your time :)

-- 
Chris Holland
http://chrisholland.blogspot.com/

[whatwg] Web Forms 2.0

[Joe Gregorio]

In the Web Forms 2.0 Working Draft dated 16 March 2005

   5.6. Submitting the encoded form data set[1]


"If the specified method is not one of get, post, 
 put, or delete then it is treated as get in the tables below."

It would be much better if just one word of that sentence was changed:

"If the specified method is not one of get, post, 
 put, or delete then it is treated as *post* in the tables below."

There are quite a few verbs defined for HTTP and many beyond
the standard 4 (GET, PUT, POST, and DELETE) take a 
request body. For example, in basic HTTP OPTIONS can have a request 
body. In addition WebDAV defines a raft of new HTTP methods
that have request bodies. The ability to support those and other methods using
Web Forms 2.0 would be possible if this is changed to *post*. Treating
all unknown methods as *get* would lock out any methods in the future
that required a request body, such as OPTIONS.

   Thanks,
   -joe

[1]  http://whatwg.org/specs/web-forms/current-work/#methodAndEnctypes

-- 
Joe Gregoriohttp://bitworking.org

Re: [whatwg] ContextAgnosticXmlHttpRequest: an informal RFC

[Hallvord Reiar Michaelsen Steen]

On 10 Mar 2005 at 0:24, Chris Holland wrote:

> When requesting a different host, we don't want the user agent to be
> sending along cookies pertaining to that domain. Same goes for any
> cached HTTP Basic Auth credentials.

Why not? Given that we add a mechanism for letting the third-party 
server control access to resources on a resource-by-resource basis, I 
don't see why we would want to prevent the third-party server from 
using sessions / cookies. Authentication is mostly a GUI problem (and 
GUI has always been ridiculous for HTTP auth anyway, with no way to 
terminate a session). It would not be a good thing if a JS request in 
the background could cause a HTTP authentication popup for a user 
name / password unrelated to the site you're browsing, so I agree 
with disallowing that. Am I missing anything regarding cookies?
-- 
Hallvord Reiar Michaelsen Steen
http://www.hallvord.com/

Note: mail to hallvors at online.no will still be read but you may 
want to start using 
hallvord at hallvord.com instead

Re: [whatwg] [html5] tags, elements and generated DOM

[Ian Hickson]

On Wed, 6 Apr 2005, Lachlan Hunt wrote:
> > >
> > > 
> > > Foo
> > > 
> > > ..?
> > 
> > If I am not mistaken:
> > 
> >
> >
> 
> I believe you are mistaken.  A conforming SGML parser will not imply the 
> body element without any content to make it do so.

I meant in existing UAs, not in the spec. According to the HTML spec, the 
handling of the above is completely undefined since it is invalid. (Note 
that something being invalid or non-conformant does _not_ make the 
rendering undefined in most cases in Web Apps 1 / HTML5. That's one of the 
main things I'm making sure of.)


> > > Is there a BODY element in this document (or, is there always a body
> > > element?):
> > > 
> > > 
> > >  body{ background:lime }
> > > 
> > > 
> > > ... or this:
> > > 
> > > Bar
> > 
> > The  will always be implied, though.
> 
> Not in a conforming SGML parser, though it seems to be in Mozilla, Opera and
> IE, as I checked using your DOM viewer [1].

Yeah, I meant in browsers, not per SGML.


> However, if the  element were to be automatically implied 
> regardless, then the same would be true of the  element since 
> both are required elements of  and , respectively, and both 
> have optional start- and end-tags,the rules for both must be the same. 
> Neither Mozilla or Opera implies the missing tbody element within 
> , although IE does. However, OpenSP does not imply the 
> missing elements in either case.

 is implied if there is a  there.

The history behind all these quirks is long and confused.  in 
particular has had an especially colourful past.


> > (For backwards compatibility with legacy parsers, the  probably 
> > won't be.)
> 
> The head element seems to be implied by Mozilla and IE.

Even when there are no elements that imply a ? I meant, e.g., when 
parsing the empty string as HTML. My understanding was that no  
element was generated in that case.


> Opera and OpenSP correctly don't imply the missing head element.

I'm not sure what you mean by "correctly" here since an HTML4 document 
without a  is invalid and thus parsing is undefined in HTML4. If 
there is a  then the  must be implied per SGML.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [html5] tags, elements and generated DOM

[Lachlan Hunt]

Ian Hickson wrote:
On Tue, 5 Apr 2005, Anne van Kesteren wrote:

Foo
..?
If I am not mistaken:
   
   
I believe you are mistaken.  A conforming SGML parser will not imply the 
body element without any content to make it do so.

Is there a BODY element in this document (or, is there always a body 
element?):


 body{ background:lime }

... or this:
Bar
The  will always be implied, though.
Not in a conforming SGML parser, though it seems to be in Mozilla, Opera 
and IE, as I checked using your DOM viewer [1].  Although Opera seems to 
have a bug in standards comliant mode (at least, according to the DOM 
viewer script) because neither the head or body elements appeared in the 
DOM using this markup:

http://www.w3.org/TR/html4/strict.dtd";>
Foo

However, if the  element were to be automatically implied 
regardless, then the same would be true of the  element since 
both are required elements of  and , respectively, and both 
have optional start- and end-tags,the rules for both must be the same. 
Neither Mozilla or Opera implies the missing tbody element within 
, although IE does.  However, OpenSP does not imply the 
missing elements in either case.

The only documentation I could find that supports this, given the short 
amount of time I have to look, is this paragraph from section 9.2.3 of 
Martin Bryan's SGML and HTML Explained [2] that was explaining how the 
associated example should be parsed.

| The start-tag can be omitted because the absence of this compulsory
| first embedded subelement could be implied by the parser from the
| content model... As soon as it sees a character other than a
| start-tag delimiter (<) it will recognize that the character should be
| preceded by [the start tag].
(For backwards compatibility with legacy parsers, the  probably won't be.)
The head element seems to be implied by Mozilla and IE.  Opera and 
OpenSP correctly don't imply the missing head element.

[1] http://www.hixie.ch/tests/adhoc/html/parsing/compat/viewer.html
[2] http://www.is-thought.co.uk/book/sgml-9.htm#Omitting
--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[whatwg] Re: and headings and other threads

[Ian Hickson]

Ok, the spec has been updated to define headings and sections:

   http://whatwg.org/specs/web-apps/current-work/#sectioning

(Only section 2.4 and its subsections; ignore sections from 2.5 onwards.)

Comments?


Below is my response to all the header-related feedback received so far.

On Sat, 13 Nov 2004, Laurens Holst wrote:
> >
> > Well,  wouldn't be backwards compatible at all. At least  would 
> > look like a heading of sorts.
> 
> I give you one abbreviation: CSS.

Lynx doesn't support CSS.


> > >  Foo
> > >  
> > >   Bar
> > >   Quuz
> > >  
> > > 
> > > Would be the same as H1, H2, H2, right?
> > 
> > Yes.

Actually in the model now in the spec that would be equivalent to three 
nested sections with H1, H2, H3 headers.


> Arbitrary heading elements (1 out of 6) are incredibly verbose to express in
> CSS, and you'd have to place h1|h2|h3|h4|h5|h6 in any XPath expression as
> well. So in practice, I don't think this is a good option.
> 
> section h1, section h2, section h3, section h4, section h5, section h6 {
>   font-size: xx-large;
> }
> section section h1, section section h2, section section h3, section section
> h4, section section h5, section section h6 {
>   font-size: xx-large;
> }
> 
> etc.
> 
> This should visually be the same as h1, h3, h6 and semantically the same as
> sections with weird headings inside.

I haven't looked into the styling solution yet but it is definitely by 
opinion that CSS should adapt to fit the markup and not the other way 
around. Since I'm on the CSSWG and an editor of the Selectors spec, I can 
work directly with the CSSWG on this. :-)


> > And if we don't redefine  (and  to ), then you end up with 
> > the weird situation of having six elements which could easily be used 
> > but end up with meaningless semantics. (And they would be inline 
> > elements in legacy UAs, which is even worse.)
> 
> XHTML 2.0 does this.

I disagree with many of XHTML2's design decisions.


> > e.g. at the moment, this:
> > 
> >
> > A
> > 
> >  A.1
> >  
> >   A.1.1
> >  
> > 
> >
> > 
> > ...makes sense, but if we say you have to use a new element for
> > headers, then the above is now meaningless and trying to make an
> > outline from it would not do anything useful.
> 
> That's just not true, or I'm missing your point.
> 
> Try making a tree view of a document based on h1...h6 headings.
> CSS: euh...
> XSLT: euh...

I can't speak for XSLT, but for CSS it would be something like:

   section { padding: 2em; border-left: 2px solid red; }

...which is in fact exactly what you wrote for the  version:

> Now try making a tree view based on h headings.
> CSS: section { padding: 2em; border-left: 2px solid red; }

I'm not sure what the problem is.


> >  3. It shouldn't be too easy to end up with meaningless markup when
> > doing either of the above. So a random  in the middle of an
> >  and an  has to be defined as meaning _something_.

Note that the current definitions do indeed define every possible use of 
 headers, I think.

> This is no different than the existing spec.

The existing spec is silent on this.

> This would mean a 4th level heading between a second- and a third-level 
> heading. Inside sections one could let the section level determine the 
> heading level and treat all headings the same, or use the highest level 
> of either the section or the heading. I don't see a need to define this 
> more specificly, as h1...h6 just don't go very well with sections. 
> That's the way it is, and it won't really harm anyone.

Except those trying to create outliners that interoperate. For example for 
documents contents pages, for jumping between sections (like PDF viewers), 
etc etc.


> I think [the spec proposals from back then are] needlessly complicated.
> 
> Note that for navigation XHTML 2.0 has  Navigation Lists, which would
> correspond to your  tag. A sidebar (which side? how is it
> different from navigation and why is navigation not a sidebar?) usually
> consists out of links, and on places where it doesn't it is conte. And
>  (content) is implied (everything not navigation). All in all this
> set of tags you proposed sounds too specific to me.

Please look at the current spec draft and let me know if you still have 
those concerns.

Note that the tags in the spec come directly from research I did into what 
markup people use for typical sites (especially looking into  abuse).


> > The other advantage of using the existing  elements is that 
> > Assistive Technologies will continue working, reporting the section 
> > headers, instead of saying there are no headers on the page.
> 
> Assistive Technologies don't work on pages using headers created with 
> font tags or styled divs either.

Those pages are broken.


> Assistive technologies can be updated. For technologies such as those, 
> section tags actually make much more sense than headings as they're 
> currently used.

I think the current definition (as of a fe

Re: [whatwg] [WF2] The element

[Ian Hickson]

To summarise my position:  solves some problems, and introduces 
others. Just like , it is not perfect. Since I do not consider the 
problems that it solves to be serious problems, and since I do not 
consider the problems it introduces to be any less important than the ones 
it sets out to solve, I do not see the advantage of introducing it.


On Tue, 29 Mar 2005, Matthew Raymond wrote:
> > 
> > If it uses scripting,  isn't needed.
> 
> Not true. See the jscalendar example. In that situation, it's far and 
> away easier to use  (formerly ) than it is to 
> modify the script, especially if the author knows little or nothing 
> about Javascript and is simply using someone else's work.

I wouldn't expect people to try to go from jscalendar to jscalendar + 
icomplex. I would expect them to go from jscalendar1 to jscalendar2, the 
second of which provides for WF2 UAs.


> > > Can you explain exactly why it's so difficult to create server-side 
> > > scripts to deal with this issue?
> > 
> > It's not, particularly; certainly no harder than supporting multiple 
> > date formats. The problem is mostly that it involves having multiple 
> > codepaths, which means more likelihood of errors (authors frequently 
> > only test in their UA), as well as opportunities for vulnerabilities 
> > (e.g. if the script doesn't expect to receive both date arguments at 
> > once).
> 
>Nonsense. Here's the pseudocode:
> 
> | if (exists(WF2_date_string)) {
> |   date1 = WF2_date_string;
> | } else {
> |   date1 = select_year + "-" + select_month + "-" + select_day;
> | }

Sure. I've also seen code like:

 if (exists(WF2_date_string))
   date1 = WF2_date_string;
 if (exists(select_year))
   date1 = select_year + "-" + select_month + "-" + select_day;

 // later in the script

 if (exists(select_year))
   date1 = select_year + "-" + select_month + "-" + select_day;
 if (exists(WF2_date_string))
   date1 = WF2_date_string;


> Then you just validate "date1" as if it where coming from a WF2 client. 
> This is the kind of problem they give programmers at a job interview for 
> people fresh out of college.

Many Web developers are self-employed, or employed by people who hired 
them based on the fact that the demo Web page they were shown has a cool 
 bit and funky use of . Sure, the professionals won't do 
this kind of mistake.


> > > > It doesn't solve the problem of the default (simplest authoring) 
> > > > being zero fallback for legacy UAs.
> > > 
> > > The simplest thing to author would be to use , so I don't see 
> > > your point.
> > 
> > My point is it would be possible (and therefore, by Murphy's law, 
> > common) for authors to do:
> > 
> > []
> 
> Exactly how would that work? In WF2-compliant HTML, nothing in the page 
> would show up after the  element. Are you saying it's a 
> problem because XHTML parsers allow the more compact form even when a 
> closing tag is *required*?

Eh? In XML,  and  are equivalent.


> > > The problem here was that supporting  is a huge pain in 
> > > the a$$, especially if you're a hand coder like myself. It involves 
> > > a massive amount of copying content and it's a pain to test because 
> > > you need a browser without frames support to check it. So most 
> > > people just said, "Screw it, let them get a browser that supports 
> > > frames!"
> > 
> > Frames, scripting, alt text on images, fallback on ,
> 
> All of which require additional effort on the part of the author.
> 
> > "best viewed at 800x600",
> 
> Additional effort required for testing on multiple devices and 
> resolutions.
> 
> > "optimized for IE",
> 
> The page may, in fact, use features that only exist in IE, or it may 
> have been designed before competing W3C standards were implemented on IE 
> and other browsers. It also indicates ignorance on the part of the 
> author regarding other methods.
>
> > "Your browser is not supported",
> 
> Nonspecific. I have no way of knowing the context of the message above.
> 
> > there are any number of examples of this mentality.
> 
> The mentality you describe is simply a matter of laziness. To drop 
> , an author has to learn CSS. To make a page work with multiple 
> screen sizes requires additional testing. If an author sees a sample 
> script that uses MS-proprietary stuff, they just stick it in and you get 
> "This site only works with IE".

Lazyness and ignorance, and copy-and-pasting from other sites, yes.


> The use of  over  represents more than laziness. It 
> represents a conscious choice to avoid providing fallback. Even if you 
> were to assume that people believed  had no 
> fallback (), it would be trivial, a simple cut and 
> paste job, to add textbox fallback:
> 
> | 
> |   
> | 
> 
> Can you come up with even one scenario that excludes all malicious 
> intent on that part of all parties involved?

One of my mottos is: don't blame on malice what can be blamed on 
incompetence. People who understand the specs will do the right thing, of 
course. But the majori

[whatwg] WhatWG spec addition?

[Ian Hickson]

UJS Contact US wrote:
> 
> I gave the specs a quick scan - specifically for one element which I have an
> interest in... that of the standard "select tag"...
>  
> I believe this list selector should be updated to provide columnar data
> formatting and enable properties that include: Greenbar (alternating colors
> - odd rows/even rows)...

This can be done using CSS and W3C Selector's :nth-child()
pseudo-class. As a presentational detail, it should be out of scope of
Web Forms.


> ...header row, header column.
>  
> I have a very rough "whitepaper" on my website showing an example... Please
> take a look - it is a short read. 
>  
> http://www.aujsproduction.com/samples/wishlist/revampedselector.asp

I agree that something like this is probably needed. We'll be looking
at things like this in the Web Apps draft.


> I will take a closer look at the entire doc to see what else I might be able
> to "suggest".

I look forward to it.

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Re: Re: [whatwg] Web Forms 2.0 Feedback

[Ian Hickson]

On Thu, 24 Mar 2005, Csaba Gabor wrote:
> >
> > [simulating img clicks]
> > What was your use case for wanting the event handler to trigger?
> 
> 1.  I had asked for the ability to simulate a REAL click complete with
> simulated coordinates.

Ah! You can do that by simply creating an event using the createEvent()
method and then dispatching it into the DOM via dispatchEvent(). That will 
work for any event.


> 2.  Repetition model.
> The Draft has a huge amount of space devoted to this,
> but I haven't been able to think of a single compelling
> argument for it.  Most of the control enhancements such
> as validation are conveniences, after all, but what they
> have going for them is that they are very compact.  This
> repetition model is huge and messy and there are simple
> javascript programming methods that allow you to do the
> same thing.  This developer's opinion is that I would
> far rather roll my own and not even have the possibility
> of using this construct.

Yeah, several people have said that. We're thinking about removing it. On 
the other hand, several people have said that it is a godsend and that 
they are so happy it is there because they are fed up of rolling their 
own. At the moment it's about equally matched, in fact.

The model is pretty simple and relatively easy to implement, so I'm 
leaning towards keeping it.


> B)  But I can't twist my mind about all this stuff with
> allowing/not allowing block level contents inside DIVs
> unless it's an odd numbered Tuesday of the month.  Could
> the document maybe provide some argument for this?

This is just allowing you to do:

   

 
  
 

   

...which would otherwise be illegal (it is illegal in HTML4). Currently 
you have to do:

   

 
  
 

   


> It states:
>
> The children of a form element must be block-level elements, unless one 
> of the ancestors of the form element is an element other than div whose 
> content model includes both block- and inline-level content, in which 
> case either block-level or inline-level content is allowed (but not 
> both). input elements of type hidden may be placed anywhere (both in 
> inline contexts and block contexts).
> 
> But isn't the ancestor of every form (in an html document)
> a body element (which is not a div element)?  And I'm pretty
> sure I've put both inline and block content into body elements.

 only accepts block-level content in HTML4 Strict.


> So now I can only have block or inline elements in my forms, but not 
> both (like I've gotten accustomed to doing)?  What happened to backwards 
> compatibility and why should spec developers even be concerned about 
> this one?  I just don't get it.

In HTML4 Strict you can only have block-level content in  elements. 
This is simply relaxing this to allow inline-level content as well in 
certain cases where that makes semantic sense.


> To my mind, a FORM element is a convenient way of saying, "unless 
> otherwise noted, every control within me will be submitted when I am 
> submitted."  As such, why should it have any interest in the bock/inline 
> types of its descendents?

I agree with you. The way it is defined in WF2 effectively makes  
transparent to all this, letting the ancestors and descendants figure it 
out between themselves.


> I have two points that are not explicitly adressed:
> A)  There is mentioned a maximum length of about 1K for this
> data type (in the RFC 2397).  Couldn't this be extended?

This will be extended in the Web Apps spec.


> B)  Security: Shouldn't it be mentioned that if the
> the destination window gets a page like this, it should be
> run in the context of the submitter?

In general it is best to leave security concerns of this nature out of the 
normative definitions of the spec, in case new problems arise that were 
not considered during the development of the spec. However, the concern 
you raise has indeed been considered and is what UAs implement, I believe.


> 5)  When I first read the replace attribute of a form I thought good, 
> that is a useful innovation.  Why destroy the document just to 
> repopulate a small section of it?  So section 8 of form submission tells 
> me I should go see the section on: seeding a form with initial values to 
> find out how this is done.  For a non XML person like me, that is scary 
> stuff there.  Trying to figure out how ultra long strings with seemingly 
> random digits might be applicable to me (What I'm saying is, the HTML 
> person is going to be scratching his head upon reading it).

Yeah, I expect we will need tutorials to make this understandable. The 
problem is the processing model as to be detailed, so the spec can't 
really be both simple for authors and implementors, and the latter take 
priority generally. :-)


> And then my eyes alight on section
> 6.2.4, 3rd paragraph, about image controls.
> It says:
> For image controls, instead of using the name given by the name attribute, 
> the field's nam

Re: [whatwg] [html5] tags, elements and generated DOM

[Ian Hickson]

On Tue, 5 Apr 2005, Anne van Kesteren wrote:
>
> I was wondering if HTML5 (WA1, at the moment) is going to define which 
> tags are optional and which elements are implied. (This is of course 
> only for text/html documents.)

Yes.


> For example, what is the resulting DOM of this document:
> 
>  Foo
>  
> 
> ... and this:
> 
>  
>  Foo
> 
> ..?

If I am not mistaken:

   
   


> Are both part of the implied HEAD element or is the SCRIPT element in 
> the first example perhaps part of the BODY element? I believe both are 
> possible.

This is not ambiguous in SGML, which defines this in detail.


> Is there a BODY element in this document (or, is there always a body 
> element?):
> 
>  
>   body{ background:lime }
>  
> 
> ... or this:
> 
>  Bar

In HTML4 those are invalid ( can't be empty). The  will always 
e implied, though. (For backwards compatibility with legacy parsers, the 
 probably won't be.)


> Is HTML5 going to list which start- and endtags are optional and how the 
> resulting DOM tree should look like in situations were there are 
> multiple options?

In HTML4 there are never multiple options, but the answer to your question 
is yes.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] to in

[Ian Hickson]

On Tue, 5 Apr 2005, Matthew Raymond wrote:
> > >
> > >   That said, this is how I would process the sample markup:
> > > 
> > >
> > > ...   
> > > A   1A (importance level 1)
> > 
> > I agree with most of what you said but the problem I have with the 
> > above is that it means almost every document will have an anonymous 
> > section at the top, and I don't think that makes sense.
> 
>If "..." were instead a list of hyperlinks to different 
> sections of the document, should that list be part of the first section? 
> If the paragraph inside the  element starts with "I'd like to thank 
> such-and-such for sticking by me while I wrote this...", is that part of 
> the first section?

If you maintain (as I do) that the first  is the document's title -- 
the same as the  element but without the requirement that it be 
phrased so that it can be quoted out of context -- then yes. The first 
section is the , the  is the document's content, and the spec 
currently says:

# The first heading in a sectioning element gives the header for that 
# section.

The content at the top of the  is part of the , and thus it is 
associated with the 's heading.

Why would you _not_ want the navigation links, or the byline, or the 
dedication, etc, to be associated with the document's first section? It 
seems correct to me.


> The way I see it, if a heading starts a section, it should always be the 
> start of a section. To do otherwise breaks consistency and may introduce 
> semantics that are not backwards compatible in some situations.

Do you have any examples? As far as I can tell we always want the first 
heading of a section (assuming it isn't preceeded by any subsections) to 
be the heading of the section.


> Better to use something like "[Top of the document]" that denotes that 
> describes the position of the content without naming it, and also 
> identifies that there is content before the first heading.

But this will be happening all over the place.

  
   Fox Publications Presents:
   The Big Newspaper
   
Flood in town

 Geography
 ...

   

The first  is clearly part of the same section as the first . The 
whitespace node before the two  elements are similarly obviously part 
of their , and the s clearly don't start a separate section 
that is independent of the  and  elements.


> > Even in the case of:
> > 
> >
> > ...
> > 
> > ...there's an anonymous section, because you have a whitespace text 
> > node before the element. That doesn't really work for me.
> 
> Why do outline generators need to worry about text nodes at the 
> beginning that contain only whitespace?

Because the spec is defined in terms of nodes, and introducing special 
rules for nodes that only contain space characters is a recipe for 
confusion and lack of interoperability (I'm talking from experience here).


> You're talking about content that won't be rendered, so for all intents 
> and purposes, the heading is the first item in the .

It might well be rendered (e.g. due to 'whitespace: pre').

> Such whitespace can simply be ignored by outliners. However, if you are 
> suggesting that such unrendered whitespace be associated with the first 
> section, I have no problem with that. ;)

I am suggesting that, and by extension, I'm suggesting that the first node 
(whatever it is) be associated with te first section, and that that be 
associated with the first heading.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [html5] tags, elements and generated DOM

[Anne van Kesteren]

Lachlan Hunt wrote:
No, there is no implied body element in either of those fragments.
I appreciate your comments but I was wondering if you have taken into 
account what existing user agents do. Since that, not some 
out-of-date-not-followed SGML standard, should be standardized in my 
humble opinion.

That also means that:
 
... generates:
 HTML
  HEAD
   STYLE
#text
  BODY
... whether you like it or not. Same for the other cases. I do not think 
it makes sense to say all current UAs are non-compliant as many pages 
may rely on the kind of DOM they generate.

--
 Anne van Kesteren
 

Re: [whatwg] [html5] tags, elements and generated DOM

[Lachlan Hunt]

Anne van Kesteren wrote:
I was wondering if HTML5 (WA1, at the moment) is going to define which 
tags are optional and which elements are implied. (This is of course 
only for text/html documents.)

For example, what is the resulting DOM of this document:
 Foo
 
For this, there is no implied body, as there is no element to imply it. 
 SGML rules apply here, as they are expressed in the DTD, and I don't 
think HTML 5 should change them.  The resulting DOM will be the same as 
that for an HTML 4 document, which is:
html
|
+-head
  |
  +-title
  +-script

 
 Foo
Same as above, with the title and script elements swapped.
..? Are both part of the implied HEAD element
Yes.
 or is the SCRIPT element in the first example perhaps part of the BODY element?
No.
I believe both are possible.
Both are possible, but since script is allowed within the content of the 
head element, its presence does not imply  and .  End tags 
are implied after encountering content which is not allowed within the 
element.

Is there a BODY element in this document (or, is there always a body 
element?):

 
  body{ background:lime }
 
... or this:
 Bar
No, there is no implied body element in either of those fragments.
Run all of your examples through the validator, with the the Show Parse 
Tree option selected and see for yourself.  The rules for an HTML 5 
document will be the same as HTML 4.

http://validator.w3.org/fragment-upload
--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[whatwg] [html5] tags, elements and generated DOM

[Anne van Kesteren]

I was wondering if HTML5 (WA1, at the moment) is going to define which 
tags are optional and which elements are implied. (This is of course 
only for text/html documents.)

For example, what is the resulting DOM of this document:
 Foo
 
... and this:
 
 Foo
..? Are both part of the implied HEAD element or is the SCRIPT element 
in the first example perhaps part of the BODY element? I believe both 
are possible.

Is there a BODY element in this document (or, is there always a body 
element?):

 
  body{ background:lime }
 
... or this:
 Bar
Is HTML5 going to list which start- and endtags are optional and how the 
resulting DOM tree should look like in situations were there are 
multiple options?

--
 Anne van Kesteren