Anne van Kesteren wrote:
output value=barfoo/output
Legacy UAs show foo where WF2 UAs show bar.
This is not consistent with textarea. I think they should behave the
same. output is effectively a read-only textarea.
-dean
Matthew Raymond wrote:
Dean Edwards wrote:
Matthew Raymond wrote:
I did a quick test, and using li in a dl produces a bullet on
Firefox, IE and Opera, whereas di and the complete lack of a parent
element did not. So, li didn't break anything, but it really didn't
have the desired rendering
I've never known this group to be in such agreement! Jim? ;-)
-dean
James Graham wrote:
Olav Junker Kjær wrote:
Ian Hickson wrote:
Ok, would anyone object to us changing it to type=url? I don't feel
strongly about this.
Consistency with CSS is a very good point. URL is more widely known
and
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
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
There are some scripting tweaks I'd like to see in WA1. Apologies if
these have been covered already:
1) Mozilla's DOMContentLoaded event is very handy. It fires when a
node's content has been loaded and parsed (the DOM has been
constructed). This is much better than the standard onload event
Ian Hickson wrote:
On Wed, 20 Apr 2005, Dean Edwards wrote:
So you'd submit to a hidden iframe and then disable the main page?
Yep. The iframe then unlocks the page when submission is complete.
Forgetting about iframes for a minute. This is analogous to disabling
the entire application
Brad Fults wrote:
On 4/20/05, Dean Edwards [EMAIL PROTECTED] wrote:
Yes, but as I said initially, that creates a closure. This is not always
the most efficient solution. Your code won't work anyway because i is
variable. The closure would need to be more complicated to work properly.
Talking about
Brad Neuberg wrote:
* Right now most people directly access an elements className property,
without realizing that they might be clobbering multi-classed elements
(i.e. something with class=class1 class2). I usually have to create
wrapper methods to ensure that this doesn't happen, such as
dolphinling wrote:
+1
I would ask what semantics canvas has. ol means the content is an
ordered list, em means the content is emphasized, span and div mean the
content is different, but in a way not associated with any element. Even
img and object mean the content is external, (usually) with
Ian,
I'm not sure that Section 2 of WA1 belongs in the spec. None of it seems
to have much to do with web applications and it makes up 50% of the
document.
I know I've said this before but shouldn't this be a separate document?
Wasn't that the plan for the other bits and pieces of HTML5
Rob Mientjes wrote:
On 4/22/05, Jim Ley [EMAIL PROTECTED] wrote:
It has the semantics of a rendering context to which scripts can draw.
So it only has presentational semantics, so should be in a rendering
language like CSS?
That's the endless quandry. 'CSS can only do so much!' 'Markup should
be
Ian Hickson wrote:
On Mon, 9 May 2005, Ben Meadowcroft wrote:
Discoverability would be left to the user agents.
Unless someone can come up with a way to make discoverability
practical and usable, there is no point us having this feature.
It is not all about user agents. I once had to build
Sjoerd Visscher wrote:
Charles Iliya Krempeaux wrote:
IMO, it would be better to a have solution to this built into the API.
Maybe with some kind of drawing transaction.
(A draw transaction is a little higher level than double
buffering, and allows you use other systems for this, other than
Hallvord R M Steen wrote:
Dear list,
often a page needs to interact with a plugin and tell it to load
another file. Today this is of course done with JavaScript, which is
difficult because most plugins have different JS interfaces, and there
are also differences between the plugins' ActiveX
Charles Iliya Krempeaux wrote:
From what I undestood (from what Sjoerd Visscher was saying), is that
there is no need for drawing transactions because of the way things
are done with JavaScript and the DOM.
Thanks for the very good explanation of drawing transaction. I wasn't
entirely
Sjoerd Visscher wrote:
They are applied immediately (internally in some kind of buffer), but
not visible.
About when script is done, most cases are easy. But as always with
HTML there are hard edge cases.
Script from a script block is done when the last statement in that block
has been
Charles Iliya Krempeaux wrote:
To be honest, the think the idea of drawing transactions is better.
Here are the reasons:
#1: It makes it so, if the develop wants it, that they can have things
that are drawn show up immediately. (I.e., they aren't forced to
use double buffering [or whatever].)
Olav Junker Kjær wrote:
I agree that free-form input is quite nice, eg. if you have to enter
your own birth date, its much faster to type than to pick.
I really would like to see date widgets allow direct keyboard entry.
It's a very important feature for data entry systems.
-dean
Mikko Rantalainen wrote:
- Clicking outside the calendar popup dismisses the popup and uses
the current values in the popup as the new date value.
This isn't good. How do I cancel? At least, put OK and Cancel
buttons in the popup.
Look at how a select works. Clicking outside the
Olav Junker Kjær wrote:
Dean Edwards wrote:
IE has some nice onbeforeprint/onafterprint events. Can we add these too?
Arent these event mostly used to transform the view before printing it?
I think this is better handled by a print-specific style-sheet today.
If I set
Ian Hickson wrote:
On Mon, 18 Jul 2005, Dean Edwards wrote:
OK. Forget CSS for a moment (although this is still a consideration for
me). What if I want to suspend a timer while the page is being printed?
Printing is (supposedly) instantaneous. Why would you suspend a timer?
(And why would
Matthew Raymond wrote:
The common use of onbeforeprint/onafterprint is to add content to a
document that is only relevant to printed media, this is something
that cannot be done with CSS, since CSS is optional, so if we just
hide content with CSS, we're stuck with the situation that users
Ian Hickson wrote:
On Tue, 19 Jul 2005, Dean Edwards wrote:
The point is, I can do all sorts of things using script. Alter styles,
create elements etc. But when I switch media, I have no programmatic way
to alter those effects. Please specify I means to do this.
You don't switch media
Matthew Raymond wrote:
For instance, such events could be combined with AJAX to force people
into a pay-to-print scenario.
What's wrong with paying to print a high quality version of an image? If
you ask me this is a great example of why we should allow these events.
-dean
Matthew Raymond wrote:
| if (documentchanged) {
| printClone = document.clone();
| prepareForPrinting(printClone);
| }
|
| printClone.print();
This seems less practical than print events. It is also very difficult
to detect changes to the document. What do you mean by changes? Style
I know this has been suggested before, and was rejected, but I would
quite like to see a pattern hint attribute added to Web Forms 2.0.
With more complex input controls we should spare a thought for the poor
user.
I've been trying to think of ways to feedback pattern mismatch help info
but
fantasai wrote:
Dean Edwards wrote:
I know this has been suggested before, and was rejected, but I would
quite
like to see a pattern hint attribute added to Web Forms 2.0. With more
complex input controls we should spare a thought for the poor user.
http://www.whatwg.org/specs/web-forms
Dean Edwards wrote:
Matthew Raymond wrote:
Lachlan Hunt wrote:
Dean Edwards wrote:
fantasai wrote:
Dean Edwards wrote:
http://www.whatwg.org/specs/web-forms/current-work/#the-pattern
That is not enough. I wouldn't put something so complex in a
tooltip. It would frighten my users
Ian Hickson wrote:
On Thu, 4 Aug 2005, Dean Edwards wrote:
Actually, the way the spec is written now, the UA _can_ assume that the
title attribute is going to help. In fact it is encouraged.
Assume that your proposal (hint) is spelt title and implement it like
that. (Including the little
Ian Hickson wrote:
On Tue, 6 Sep 2005, Dean Edwards wrote:
That's right. We are defining HTML5 and the DOM extensions to support
it. If other languages want to add different class name delimiters, let
them. My hunch is that they will follow suit. This is a good opportunity
to make it clear
For the last few weeks four programmers (myself, Erik Arvidsson, Dimitri
Glazkov and Olav Junker Kjær) have been building an IE implementation of
Web Forms 2.0 for Internet Explorer.
We now have a working version available for testing. Because we are
programmers we are rubbish at testing
32 matches
Mail list logo
