Re: [whatwg] Web Forms 2.0 Feedback

[fantasai]

Ian Hickson wrote:
Another criteria is "could the presentation be changed without losing its 
meaning?". For example, with  clearly you can change the presentation 
without losing the fact that it is emphasis: whether it is bigger or 
italics doesn't make much difference. But with  I don't think you 
can. If you change the presentation of  you _do_ change the perceived 
meaning of the rendered content.
Subscripts can be marked with brackets when subscripting isn't available.
Superscripts can likewise be done with ^. But it's not ideal.
~fantasai

Re: [whatwg] Web Forms 2.0 Feedback

[Christoph Päper]

*Ian Hickson <[EMAIL PROTECTED]>*:
   Mlle
   x2
I'm not sure how to deal with the chemistry case. We don't really have an
element for anything like chemical formulas.
Stretching its semantics really far, one could use 'code' for formulas¹
and 'abbr' for isotopes etc.
¹ The molecular sequencers ("replicators") from Star Trek are (hypothetic)
computers that need some kind of source code.
P.S.: Sorry, Ian, for sending this off-list at first.

Re: [whatwg] Web Forms 2.0 Feedback

[Ian Hickson]

On Fri, 7 Jan 2005, dolphinling wrote:
> 
> "green" is just as meaningful as "subscript"--they're both purely 
> presentational, and we as people have attached meanings to certain 
> presentations. The semantics of "subscript" are completely different 
> from the semantics of "there are two of the (chemical) element that 
> immediately preceded this", but we have attached one to the other.

There are some differences:

 * The semantic of / can often be deduced from context 
   (especially if we define some specific contexts, like "sub inside var
   means it's the variable's subscript, as in the part of its name that
   identifies the specific variable in a family of variables").

 * There are rarely, if ever, any semantics associated with a colour
   that can be understood without an explanation in the same document.
   Sometimes some content is coloured so that it can be differentiated,
   as in making test results red or green for different results, but
   that is always explained in the same document (if it is to be
   understood, anyway) and is rarely the only aspect of the document
   that indicates the difference (e.g. typically in such an example it
   would be the words "pass" and "fail" that were coloured).

I would love to be able to unambiguously have the semantic for the "2" in 
"H2O". I don't see how to do it (at least not without 
introducing a ridiculous number of elements to HTML). I consider  to 
be an acceptable (semantic) compromise. It does affect media other than 
visual media, which (as previously mentioned) is the criteria I usually 
use for working out if something is semantic or presentational.

Another criteria is "could the presentation be changed without losing its 
meaning?". For example, with  clearly you can change the presentation 
without losing the fact that it is emphasis: whether it is bigger or 
italics doesn't make much difference. But with  I don't think you 
can. If you change the presentation of  you _do_ change the perceived 
meaning of the rendered content.

-- 
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

[Ian Hickson]

On Fri, 7 Jan 2005, James Graham wrote:

> Because that happens to be a convenient umbrella for specific 
> constructions in documents that need to be treated in a particular way 
> by UAs. Indeed I would be more than happy if Web Apps "clarified" the 
> situation with  and  so that purely presentational uses like 
> LATEX were forbidden as these uses undermine the 
> ability to UAs to provide an appropriate rendering in the case where the 
> presence of "superscripts" or "subscripts" in a sequence of charcters is 
> important information that needs to be passed on to the user.

I shall include that example as something not to do; good idea.

Thanks,
-- 
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

[Ian Hickson]

On Fri, 7 Jan 2005, Rimantas Liubertas wrote:
> 
> I cannot agree. We should not mix typographical presentation for 
> presentation sake and typographical presentation for semantic reason. 
> While it may be not a big deal in chemistry, it is not so in math.

This may be a good way of putting it in the spec: "typographical 
conventions with specific meanings (as opposed to typographical 
presentation for presentation's sake)".

> Or is E=mc2 same as E=mc2?
> Do log4nm and log4nm differ?

Good examples, I'll use this in the spec (assuming that's ok with you!).

Thanks,
-- 
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

[Ian Hickson]

(I hope y'all don't mind me replying to all your e-mails out of order. I'm 
basically going down the spec one element at a time and when I come across 
one that someone has discussed in the past, I reply to those e-mails.)

On Fri, 7 Jan 2005, Matthew Thomas wrote:
> On 7 Jan, 2005, at 5:58 AM, Ian Hickson wrote:
> > ...
> > For , the ideal aural rendering depends on the context, but humans
> > are adept at interpreting things based on context and you could probably get
> > away with rendering sub by simply prefixing its contents with the syllable
> > "sub", as in "H sub-two O" for "H2O".
> > ...
> > the fact that you can use the element to sensibly change the aural rendering
> > suggests to be that it is semantic enough to be kept in HTML.
> 
> Except that "sub" is merely (an abbreviation of) a description of the
> typographical presentation! You might just as well say that H color="green">2O is semantic because it could be pronounced as "H
> green-two O".

But it wouldn't be, and that's rather my point. I rarely hear people 
calling out the fact that something is bold or italics or red when they 
are reading text out. I _do_ hear them say "sub-" this and "super-" that.


> > It's not ideal, and for a better aural rendering you would use a 
> > speech-capable UA that supported ChemML, MathML, or another more 
> > appropriate standard language natively, and pass content to it using 
> > the appropriate domain-specific language.
> 
> FWIW, in the case of ChemML that wouldn't help -- as far as I know 
> (having just consulted the household science teacher), there is no 
> standard way of pronouncing chemical formulas so as to distinguish 
> subscripts even from normal numbers. So using aural rendering to decide 
> whether an element is semantic wouldn't work in that case.

There's no standard rendering, but there are conventions that a UA author 
can use.


There are several use cases I can see for  and  that I consider 
to be semantic and not presentational. However, it seems very much to be 
on the fine line between the two, and I am interested in hearing of ideas 
that would more clearly move / or new elements into the semantic 
camp.

Use cases:

   In french, parts of words (abbreviations, usually) are always 
   superscripted. For example, the "lle" in "Mlle".

   In chemistry, number of atoms, atomic weights, charge, etc, are
   superscripted and subscripted.

   In variables names parts are often subscripted to indicate a specific 
   variable in a family of variables.

   In maths, superscripts are used for powers.

And of course in lots of other fields there are specific uses for them 
too. I propose to try to address as many of possible of these use cases in 
specific ways. For example, "Mlle" would be:

   Mlle

...and variable subscripts would be:

   x2

I'm not sure how to deal with the chemistry case. We don't really have an 
element for anything like chemical formulas. For maths, MathML comes to 
mind, although only for the XML serialisation.

Any other cases? Any suggestions?

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

Issues (was: Re: [whatwg] Web Forms 2.0 Feedback)

[Anne van Kesteren]

Ian Hickson wrote:
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.
The other issue - about the form content model - has been solved as well 
IMHO.

(And I personally think the first mentioned issue - about fallback - 
isn't really one either.)

--
 Anne van Kesteren
 

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: 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: Re: Re: [whatwg] Web Forms 2.0 Feedback

[Csaba Gabor]

ouldn't this connection be maintained for quite a while?

What I'm proposing is a replace="continual" where values can
continue to come in until the server closes the response or the
UA ends it (In this instance it might make sense not to have
the progress bar constantly showing).  If the server sends back
the same control/value multiple times then it is updated each time
that control and value are received.

So, unless I miss something, for a relatively minor enhancement
to this spec, you gain a huge utility.  (This functionality can
already be simulated, of course, by refreshing an IFrame or other
silliness, and having an onload, but it is not so robust, and
just not the right thing to do.  My understanding is that you can
do this in Flash too.)  It just makes sense to have this as a
native ability.

But it's late and I indulge my fantasy and am thinking off the
cuff, a dangerous combination.  I want more.  Whether the above
eventually makes it in or not, it seems eminently reasonable.
This next part however, is questionable...  but would unleash
a whole new era of connectedness.  I don't know if it makes sense
or is feasible, but I offer it as possible future idea...

Let's presume that we can do this live update business
(replace="continual").  That means the UA has declared that it
is willing to keep an open connection and receive input from
the server as it happens.  Now let's suppose a second UA does
the same thing with the same server.  So if UA1 sends a piece
of info to the server, UA2 could instantly be notified of
this change (this I have already done with current technology
as alluded to above.  Nothing new here).

Here's what I'm thinking/wondering.  That request from a UA
for data went out to the server, which could redirect it.  At
the same time, UA2 has issued a similar request.  Couldn't
the server cut itself out of the loop?!?  After all, both
parties are asking something from it.  Could the request of
one be construed as the answer to the other.  OK, what I'm
really asking is can we turn a UA into a mini or simulated
server where the intermediate 'trusted' agent, the server,
is the one that makes the arrangement.

Again, this kind of thing is already possible on a simulated
basis?  How would one formalize it in a reasonable way.


7.  Finally, a curiosity question.  SELECT elements are lacking
in this spec.  Now, back in the summer it was pointed out to me
(Ian) that Hierachical menus will be available in Web Apps 1.0
What I don't understand is why they are not part of this spec.
Isn't this their natural resting place?


Best Regards,
Csaba Gabor from Vienna


--- Ian Hickson <[EMAIL PROTECTED]> wrote:

> Date: Fri, 12 Nov 2004 11:14:30 + (UTC)
> From: Ian Hickson <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> Subject: Re: Re: [whatwg] Web Forms 2.0 Feedback
> 
> On Sun, 29 Aug 2004, Csaba Gabor wrote:
> >
> > First, I'd like to thank you for your response.  It's rare that I 
> > encounter anyone that can even appreciate these points.  And your 
> > succinct direct addressing of the issues is also appreciated.
> 
> My pleasure.
> 
> 
> > You've (implied or) asked for clarification on a few issues (points 1, 
> > 2, 4, 5, 8), hence my response (interspersed on those points.
> 
> Thanks!
> 
> 
> > In addition, there's one other point that I'd mention even though it 
> > doesn't have to do with forms (but at least I'll get it off my chest).  
> > That is, that I'd like to see a height specifiable in terms of number of 
> > lines of text.  It's always struck me as strange that this isn't 
> > standard.  For example, I might want all my TD elements to display at 
> > most two lines of text.  I could try to set this in terms of em but if 
> > there is a font change (or a size change in opera, say), I am sunk.  
> > It's such a natural unit - why isn't it this part of the CSS standard?
> 
> You can, to some degree, do this using the "em" unit, as in:
> 
>height: 2em;
> 
> The problem is that what you really want is a unit dependent on the 
> line height, and the line height can change based on what is on the line, 
> which makes this quite complicated.
> 
> However, I shall forward your request to the CSS working group. It's not 
> the first time people have asked for this.
> 
> 
> > > This sounds like what you are really requesting is a way for setting the 
> > > coordinate when you call click(), so you would do, e.g.:
> > > 
> > >image.click(2, 5);
> > > 
> > > Is that right? If so, that seems relatively simple to add.
> > 
> > Perfect:
> > arbitraryHTML